JJUG CCC Fall 2022 登壇レポート

• 
• 
• 
• 

はじめに

登壇者紹介

• GMOペイメントゲートウェイ株式会社
  システム本部IT戦略ビジネス統括部 プロセシング部 羽鳥 樹

羽鳥樹と申します。新卒でインターネット広告の営業としてキャリアをスタートしました。
仕事の中で広告配信システムに触る機会があり、当時はまだ珍しかったWebアプリケーションに感動し、こういうものを作れるようになりたいと一念発起し、転職してプログラマーのキャリアをスタートしました。
転職先はクレジットカード会社や金融業界を主なお客様としていたので、そこでクレジットカード業界の基本的な知識とシステム開発のノウハウを身につけました。
その後、2016年にGMOペイメントゲートウェイに入社しました。
前職の経験を生かし、今回お話しするシステムやクレジットカード会社様向けのシステムの開発に従事しております。一方で、これまで主に決済を処理するシステムに携わってきましたが、今後はいわゆるWebプリケーションの開発にも携われるよう、チャンスを探していこうと思っております。

会社概要

弊社は商取引において必ず発生する「決済」のインフラを、幅広い業界のお客様に提供させていただいております。
主力事業は決済代行事業で、インターネット上でビジネスをするお客様に向けて様々な決済手段を提供させていただいております。今回お話しするシステムも、決済代行事業のシステムとなります。
ほかに、後払い等の金融関連事業や、マーケティング支援サービス等の決済活性化事業も提供しております。

1.システム概要

まずはシステムの概要からお話しさせていただきます。
今回お話しするシステムは、弊社システムの中でクレジットカード決済を一手に引き受けているシステムとなります。カード決済基幹システムと呼ぶことにいたします。
お客様である加盟店会社は、弊社のサービスを決済フロントシステムのAPIを呼び出すことでご利用されています。
決済フロントシステムは、カード決済をはじめ、QRコード決済や電子マネー決済といった、様々な決済手段を提供しております。そのうちカード決済については、カード決済基幹システムのAPIを呼び出すことで実現しています。
カード決済と一言で言っても、弊社システムの先にはアクワイアラという加盟店管理を担うカード会社様や、カード会社様との窓口を提供するネットワーク会社様などがあり、それぞれ接続方式や電文フォーマットに差異があります。これらの差異をこのシステムは吸収しております。フロントシステムはこのシステムのAPIを呼び出すだけで、その背後にある複雑さを意識せずに、カード決済を実行することが可能です。カード業界では、FEPなどと呼ばれています。FEPはパッケージ製品を使うケースが多いですが、弊社はすべてJavaでスクラッチで開発しております。
2013年頃から稼働しておりますが、当時でも比較的古いとされる実装が多く残っているので、いわゆるレガシーシステムに分類されると思われます。

2.更改プロジェクトについて

更改プロジェクトは、2020年4月より開始しました。
当初はサーバーの保守期限切れのため、サーバーの更改のみが範囲でしたが、流通取引総額の拡大に伴い、その次の更改となる5年後の取引量を処理できないということが懸念されました。
この表は、当社グループ連結の流通総額となりますが、更改プロジェクト開始前の5年で年平均成長率は27％、更改プロジェクト開始から現在まででは、年平均成長率が35％となっており、取引件数も同様に成長しております。また、クレジットカード決済はその大部分を占めており、カード決済基幹システムに掛かる負荷も上がり続けていました。
当初案はサーバーのスケールアウトで対応することを検討しましたが、アプリケーションの保守運用をしている中で、ボトルネックと思われる個所がいくつか見つかっていました。それらを解消することでアプリケーションの処理性能を向上させることができると判断し、サーバーのスケールアウトは後回しにして、まずは改修を実施することにいたしました。

3.処理性能向上について

ボトルネックとして挙がったのは3点で、いずれもDBに関するものです。
まずはレガシーシステムにありがちな、必要以上に多いDBアクセスです。詳細は後ほど説明いたしますが、生存期間の短いデータをRDBで永続化しているというケースになります。
次は、SELECT FOR UPDATEによるレコードロック待ちです。
最後は、スケールに比例するSQL実行の長時間化となります。
いずれも、性能に大きく影響を及ぼすもので、また取引量の増加に伴い影響も大きくなるものでした。これらは影響が顕著になりシステムへの影響も見過ごせない段階になってから改修しようとしても、いずれも一朝一夕に改修できるものではありません。
こうした背景もあり、影響が顕著になる前であり、システム更改をプロジェクトとして行うこのタイミングでアプリケーションも改修を実施することになりました。
課題はすべてをRDBで解決するアーキテクチャに起因しているため、解決方法として挙がったのはインメモリDBの使用でした。DBへの負荷を分散し、スループットを向上させるのに適切と考えたからです。
インメモリDBとしては定番として名前が挙がり、社内でも使用実績があったRedisが候補として挙がりましたが、私自身がアプリケーションサーバーのPayara Microをほかのプロジェクトで使用した時に、その一部機能として使用した経験があったこと、また改修内容を検討する中でインメモリDB自体に業務処理を乗せて実行させるということが想定されました。このような理由から、Javaで作成したロジックを乗せられるインメモリDBとして、HAZELCASTを使用することに決定しました。

4.HAZELCAST

HAZELCASTは、Pure Javaで開発された、In Memory Data Gridの製品となります。IMDGと略したりします。IMDGの他の製品では、Apache GeodeやOracle Coherenceがあります。
HAZELCASTはアプリケーションサーバーのPayaraやVert.xなどで使用されています。In Memory Data Gridとは、クラスタリングされた複数のサーバーのメモリに分散してデータを保持することで、高速なデータへのアクセスとスケーラビリティを実現させる技術です。データアクセスするアプリケーションは、複数のサーバーにデータを保持されているにもかかわらず、あたかも1つのDBにアクセスしているように見えます。
続いて、こちらは基本的なHAZELCASTの使い方となります。
HAZELCASTのAPIを使用して、まずMapを取得します。取得した型はIMapという型で、こちらはConcurrentMapを継承しています。ConcurrentMapはjava.util.Mapを継承しているので、普段使い慣れているMapのput、Get、removeといったメソッドを使って操作することができます。また、Map同様にジェネリクスでKey、Valueの型を指定可能なので、任意のクラスを指定することも可能です。この例では、Customerというクラスを定義して、Valueにしています。
普段はネットワーク越しにデータをやりとりするので、独自クラスを定義する場合にはjava.io.Serializableを実装する必要があります。HAZELCASTのクラスタ内の各ノードのIPアドレスやポート、そのほかMapに関する各種設定は、hazelcast.xmlというファイルで定義します。

5.処理性能向上のための改修

▸ 処理性能向上のための改修①

まず、多過ぎるDBアクセスの解消を目指しました。
現行システムは加盟店単位の流量制御と、カード会社単位の流量制御をいずれもRDBで実現していました。取引処理中に流量の集計用テーブルにレコードをインサート、加盟店単位の流量をCOUNT()で集計し、流量のチェックを実施、さらに送信するカード会社を決定してレコードをアップデート、カード会社単位の流量を再びCOUNT()で集計し、チェック、処理の終わりにレコードの削除と、流量制御のために3回コミットが発生していました。
取引量×3回コミットが発生するので、取引量とともに増加していくコミット回数はDBの負荷を上げ、処理遅延に繋がっていました。
一方で処理におけるデータの生存期間は非常に短いため、そもそもRDBで処理するのは適当ではないと判断し、DBへの負荷軽減を目的にHAZELCASTに移行することに決定しました。
改修は、処理をすべてそのままHAZELCASTに移行しました。HAZELCASTではSQLを使用できることがわかったので、現行と同様の処理にできると判断しました。
具体的には、加盟店IDとカード会社コードでそれぞれ独自のクラスのフィールドに定義し、現行と同様に取引処理時にMapに登録、加盟店IDで集計してチェック、カード会社コードを決定したら反映、カード会社コードで集計してチェック、最後にMapから削除というふうに改修しました。
処理を移行するにあたり、カウンタを使うことも検討しました。HAZELCASTにはIAtomicLongというクラスも用意されていて、カウンタとして使用することもできますが、カウンタだとインクリメントしたあとにプロセスが停止するなどの理由でデクリメントされず、件数が戻らないというケースが懸念されました。HAZELCASTではMapにTime To Live値、いわゆる生存期間を指定できます。このため、Mapであれば万一そのようなことが起きても時間が経過すれば件数が戻るので、この方法がベターと判断しました。
通常、許容限度の流量はある程度余裕を持つので、カウントが戻らないことで大きな障害に繋がるというケースはまれだと思いますが、カウンタが戻らないということはあるべき形ではないと考え、このような修正としました。

こちらはコードの例です。左側が独自に定義したクラスです。フィールドに加盟店IDとカード会社コードを定義しています。右側は集計するSQLの例です。ちょうどSQLのWHERE句を書いています。valuesの引数にPredicates.sqlで指定した条件を与えると、条件に合致する値のコレクションを取得できます。このコレクションのサイズを件数として取得するようにしました。

▸ 処理性能向上のための改修②

次に、SELECT FOR UPDATEによるロック待ちの解消です。
カード決済基幹システムに接続するシステムごとに最大流量が決まっており、これを制御するための仕組みでSELECT FOR UPDATEを使用していました。先ほどカウンタについて少し触れましたが、この処理ではまさにRDBを使用してカウンタのインクリメント、デクリメントをしていました。
テーブルには接続システムごとのレコードが登録されており、カウンタがあります。このカウンタを複数スレッドがシーケンシャルに更新できるように、SELECT FOR UPDATEでレコードをロックしてからインクリメントして更新、チェックが終わったらSELECT FOR UPDATEで再びレコードロックしてからデクリメントして更新、というふうに処理をしていました。
システム単位で1レコードを使用するので、取引が集中すると複数のスレッドが同時にロックを試みるため、ロック待ちが発生していました。また負荷が上がるほどロック待ち時間が長くなるため、改修が必要と判断しました。
改修内容としては、前ページの改修と同じく、接続システム単位で現在の件数を集計して流量をチェックするようにしました。

▸ 処理性能向上のための改修③

最後に長時間SQLの解消です。
カード決済基幹システムには期限切れ取引の取消処理というものがあります。これは取引の処理後に一定の有効期限内に確定要求を送信元システムから受けないと、カード会社に取消要求を送信して取引自体なかったことにする機能です。送信元システムとの取引の整合性を明確に保つために、確定要求を受けない限りは取引を成立させないというものです。DBのトランザクションにおけるコミットのようなものと考えていただければと思います。
この処理は、取引発生時に取引期限管理用テーブルにレコードを登録し、確定要求を受けると確定の状態に更新。その後、取引期限完了テーブルから定期的に確定に更新されていないレコードを期限切れ取引として抽出して、カード会社に取消要求を送信していました。
この抽出時に発行していたSQLは、テーブル内のレコード全件を対象に検索していました。テーブルのレコードは1日以上は保持せずに削除していたため、検索対象は限られていたものの、1日の取引量が増えるにつれ、SQLが遅延することは目に見えていました。
取引の抽出はバッチ処理でやっておらず、決済処理用のプロセスの内部で、定期的にスレッドを起動、具体的にはScheduledExecutorServiceを使用していました。
このため、決済処理と同じコネクションプールを使用していたので、SQLの長時間化はコネクションを長時間保持してしまうので、コネクションプールの枯渇に繋がり、決済ができなくなるという事態に繋がることが懸念されました。このため、この処理もHAZELCASTに移行することにしました。
HAZELCASTでは、RDBのテーブルに相当するMapの追加や削除といったイベントに対してイベントリスナを登録、任意の処理を実行させることが可能です。この機能と、MapのTime To Live値を使用して改修を実現しました。
まず、取引発生時にHAZELCASTのMapに取引を登録、その後確定要求を受信したらMapから登録した取引を削除するように改修しました。MapにはTTLが設定されているので、一定の時間が過ぎたらエントリが期限切れとして削除されます。確定要求を受けない取引はリストに残り続け、期限切れとして削除されるので、このイベントに対してリスナを起動し、取引情報を使用してカード会社に取消要求を送信することにしました。
この改修により、SQLの発行自体をなくせたので、取引量の増加によりSQLが遅延するという懸念をなくすことができました。
こちらは具体的なコードの例です。左側がEntryExpiredListener、つまりエントリの有効期限切れに対するリスナです。引数のエントリイベントから削除されたエントリを取得することができます。ほかにも、追加時のリスナや削除時のリスナのインターフェースも定義されています。
作成したイベントリスナはhazelcast.xmlでどのMapに対するリスナなのかを定義することができます。なおhazelcast.xmlで設定する内容はプログラムでも設定することが可能です。イベントリスナのインターフェースはFunctionalInterface(関数型インターフェース)なので、ラムダで書いて登録することも可能です。

6.システム移行時の課題

▸ 新旧システムの並行稼働

ここまで改修してきて問題となったのは、新システムのリリースでした。
サービスへの影響を最小限にするために、カナリアリリースでリリースすることになりました。サービス停止はなしでリリースするので、ロードバランサに新システムを繋げて、新旧システムで取引を処理するのですが、旧システムはRDB、新システムはHAZELCASTを使用することになります。この時、別々のDBを見ているので、例えば新システムで取引を処理し、旧システムで確定要求を処理した場合はRDBには取引が存在せずエラーとなり、HAZELCASTに登録された取引は削除されずに残り続け、取消要求の送信対象となってしまいます。つまり、確定要求を受けているにもかかわらず取消をされてしまうので、加盟店様とカード会社様との間で取引の齟齬が発生する可能性があります。これは非常に問題なので、確実に影響を出さないようにリリースする方法を見つける必要がありました。
最終的に、並行稼働期間中、新システムはRDBとHAZELCASTの両方に処理を行うように改修し、その上でHAZELCASTから取消要求を送信する際にRDB側に同じ取引が存在するかを確認するようにしました。
この図の例だと、新システムで取引を処理した際に、RDBとHAZELCASTの両方に登録、確定要求を旧システムで受けたら、RDBの取引の状態を更新します。その後HAZELCASTに登録された取引は期限切れとなり取消要求送信の対象となりますが、送信前にRDBを参照し、レコードが存在する場合は処理を中断することで取消要求を発生させないようにしました。これで、取消要求の送信処理自体を旧システムに寄せることが可能となりました。
なお、HAZELCASTからRDBへの接続は、特にHAZELCASTでサポートされているわけではないので、独自に実装する必要がありました。当初発生したタイミングでDbConnectionを生成して接続することも考えましたが、同時に大量に取消要求が発生した場合、コネクション生成のオーバーヘッドが処理性能に影響を及ぼすことなどが懸念されたので、コネクションプールを使用することにしました。HAZELCASTには、起動時や停止時といったイベントに対してリスナを作成することができます。これを使用し、起動時にコネクションプールを生成、停止時に破棄するようにしました。なお、コネクションプールにはSpring Bootでも使用されているHikariCPを使用しました。

▸ 本番移行でヒヤリ

本番移行でヒヤリとした話ですが、こちらはちょっとした小話程度に聞いていただければと思います。
本番移行にあたってはリハーサルも実施して想定外の取消要求が発生しないことを確認した上で当日を迎えました。ですが、いざ新システムを稼働させ取引を処理させたら、新システムで大量の「対象の取引が存在しません」というログが発生し、即座に新システムをロードバランサから切り離すことになりました。
これは、旧システムで取引を処理し、新システムで確定要求を処理した場合は、HAZELCASTに削除対象が存在しないというのが原因でした。
移行期間中、新システムはRDBとHAZELCASTの両方に処理をするよう改修したので、確定要求を処理する時は、RDBの取引の状態を更新していました。このため、取消要求は発生せず、業務影響はありませんでした。
ただ、移行リハーサル中は想定外の取消要求が発生しない、エラーログが発生しないという点に集中していたので、WARNログが出るところまでは把握しておらず、本番で初めて知ることになりました。
結果として問題はなかったものの、移行当日はものすごく緊張していたのでほんとに肝を冷やしたのを覚えております。

7.まとめ

最後に、システム更改の成果と今後の課題です。
システム更改からは1年経過しましたが、既に最大秒間取引件数の7割程度まで処理しています。かなり想定より早いペースですが、現状特に処理遅延などを起こしたり、障害に繋がるといった問題は発生しておりません。更改前よりもずっと安定して稼働しているという印象です。
また、DB側のモニタリングで、更改前後で同程度の取引が発生した1日のDBの総アクセス時間を比較しましたが、更改前の約2/3程度まで低減させることができました。DBへの負荷は相当程度低減できたと思います。これが安定稼働に繋がっていると考えられます。
また、旧システムと比較し、新システムではシステム内部の処理時間を200ms程度削減することができました。
今後の課題ですが、運用に関する改修が必要と考えています。
ひとつは、システムの異常をプロアクティブに検知するための仕組み、具体的にはAPMやElasticsearchなどを使ったログ分析といったことが考えられます。そのための足場作りとして、システム更改のタイミングでログ集約の仕組みを導入しています。
また、CI/CD対応としてリリースの自動化とテスト自動化を予定しています。いずれも既に着手していますが、今後本格的に導入していく予定です。
それから開発効率化のために、フレームワークの導入を検討しています。実は、決済基幹システムはフレームワークを使用しておらず、JDKに含まれるクラスのみでほぼ作られています。このため開発効率に問題があると考えられているので、大胆なアプリケーションの改修となりますが、フレームワークの導入を考えております。今回の更改でも検討はしたのですが、ほかに優先させることが多かったので見送りとなりました。一部の機能で導入し始めていますが、いずれ大胆にアプリケーションを改修して導入したいと考えております。

おわりに

GMOペイメントゲートウェイではエンジニアを絶賛採用中です。
今日ご紹介したシステムも含め、当社にて構築運用をしている様々なサービスをより発展させていくために、様々なバックボーンをお持ちのエンジニアの皆様のお力をお貸しいただければ幸いです。
本日のイベントを聞いて興味が沸いた方はぜひ採用特設サイト（https://www.gmo-pg.com/corp/recruit/）をご覧ください。

Q&A

質問1．Hazelcastの運用で困ったことはありますか？

質問2．Hazelcastをputする度にネットワークI/Oのブロッキングは発生するのでしょうか？測定などされていましたか？

質問3．RDBとHazelcast両方に登録するとデュアルライトが発生すると思いますが、それはどうやって解消されたのですか？

質問4．Hazelcastを使っているならPayara Micro使うのがいいのでしょうか？

質問5．お話いただいた以外でハマったところなどあれば教えてください。

質問6．プロジェクトはどれぐらいの期間かかったのですか？

質問7．開発は何人ぐらいでされていましたか？

質問8．テスト中にHazelcastの特性上困ったことなどありましたか？

質問9．開発の効率化にあたってフレームワークの導入を進めているとのことですが、どんなものが候補に上がっていますか？

質問10．新システムと旧システムを並行稼動中に新システムが問題なく稼動してるのを確認する方法として、エラーが出てないこと以外に、データ整合性など見てらっしゃったポイントなどありますか？

質問11．最後に何かメッセージはありますか？

アーカイブ動画

ご視聴・ご参加いただき、誠にありがとうございました。
たくさんのご質問もいただき、重ねて御礼申し上げます。

映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。

ブログの著者欄

採用情報

関連記事

• 

  JJUG CCC 2024 Fallにスポンサーとして協賛決定！

  イベント

• 

  ［登壇レポート］GMO Developers Night#40 / 新BNPL（後払い決済）サービス「アトカラ」開発の裏側 ～入社3年目のメンバーも活躍する「アトカラ」チーム～​​

  技術情報

• 

  JJUG CCC Fall 2023 登壇レポート

  技術情報

• 

  技育CAMPアカデミア -Vol.04 登壇レポート

  技術情報

• 

  JJUG CCC 2023 Fallにトップスポンサーとして協賛決定！

  イベント

• 

  ［登壇レポート］GMO DevelopersNight#38 / エンジニア出身者が活躍するカスタマーサポート

  技術情報