PGマルチペイメントサービスのマイクロサービス移行計画とAPIゲートウェイの役割

本日は10万店舗以上の加盟店様のオンライン決済を支えるPGマルチペイメントサービスのマイクロサービス移行計画についてお話いたします。

まず自己紹介です。佐久間と申します。
前職はSIerで勤務しておりました。入社時、決済については全くの未経験で、2016年JavaエンジニアとしてGMO-PGに入社しました。現在はSREエンジニアよりの仕事を行っております。

本日は以下についてお話しします。

• 「PGマルチペイメントサービス（マルペイ）」のご紹介
• システム更改前の課題
• 更改で取り組んだマイクロサービス移行計画

PGマルチペイメントサービスの仕組みと開発背景

マルペイとは加盟店様と決済事業者様との間に入り加盟店様の決済を弊社が代行する決済代行サービスとなります。
お客様が加盟店様のサイトで購入いたしますと、決済の情報がGMO-PGに流れてきます。GMO-PGではそれを受け取って決済事業者様に流す、といったサービスです。ECサイトでは複数の決済手段を導入する場合、個別に開発すると稼働までに工数も時間もかかると思います。そこで様々な決済事業者様に接続するWebAPIをGMO-PGが提供しています。
マルペイではこちらに掲載されているような決済を提供しております。

決済システムに求められる可用性とセキュリティ

お金を扱うミッションクリティカルなサービスのため、高い可用性で稼働し続けることが求められます。またクレジットカードなどセキュリティ対策が必要な重要情報を取り扱っておりますので厳重なセキュリティ要件が課されております。
そのためにオンプレで稼働しており、クラウド移行には高いハードルがあります。

また、トランザクション量は年々増加しております。例を挙げますと経営目標が営業利益毎年25％成長継続で、ありがたいことに毎年達成しているのですが、それに比例してトランザクション量も増えるため、5年で現在の4倍のトランザクション量を取り扱う計算となります。ということは、サービスもその成長に持ちこたえられるサービスにしないといけません。

内製開発と2019年のシステム更改

マルペイの初回リリースは10年以上前です。基本的に内製で開発しています。過去の大規模なコードリファクタリングはフレームワークのバージョンアップを行いました。
また、開発サイクルが短く、開発スピードも求められます。数か月で新規の決済手段や新規機能がどんどん増えていくといった状況です。そして、2019年にシステム更改を迎えました。その際、私はシステムアーキテクチャを検討する役割になりました。

モノリスの課題とマイクロサービス化の検討

システム更改前の構成はレガシーなシステムにありがちな、モノリシックなアプリでした。
1つのアプリケーションの中に機能が詰め込まれている、アプリケーションになります。更改前の課題は、レガシーでモノリシックですので技術的な負債がどんどん蓄積されていくというところにありました。局所的な問題がアプリ全体に波及していく状態です。

例えば、

• Aの決済でトラブルが起きた時に、他の決済にまで影響を及ぼしてしまう
• 複数案件の並行開発がしにくい
• Aという決済とCという決済を同時に開発していたところ、コードの競合が起きてしまって、なかなか上手く開発できない
• スケールアウトしにくい。実際集中するのはA決済のみだが、スケールアウトするにもアプリ全体をスケールアウトしないといけない

といった様々な課題を抱えておりました。

そんな時にWebで一般的なマイクロサービス化のメリットとしてこんなことが書いてありました。

• サービス間の依存が少ないので新しい技術を採用しやすい
• 障害耐性が高い。影響をサービス単位に局所化できる
• サービス単位でスケールアウトできる
• サービスごとに開発が進められる

ということで、課題はマイクロサービスで全部解決できるのでは？と考え、マイクロサービス化について検討しました。

機能単位の段階移行とAPIゲートウェイの実装

それでは、システム更改で取り組んだ「マイクロサービス移行計画」についてお話しいたします。最初に想像したマイクロサービスですが、このようなものを考えていました。

サービスがこのように沢山あり、サービス間の通信も沢山あるといったものを想像しました。そこで疑問が出ました。

• 今の開発状況でモノリスで実装されている機能を全部マイクロサービス化する開発力はあるのだろうか
• またできたとしても開発量が多すぎて品質が保てないのではないか
• サービス間の通信が増えるため、レイテンシが悪化しそう
• どこで障害が起きたのかわからなくなりそう

といった事が疑問としてあがりました。
この時点だと、実現するのが厳しい、というのが正直な感想でした。

そこで、「PG流のマイクロサービスの移行方針」としてこのようなことを考えました。

マイクロサービスの粒度は細かくしすぎず、機能単位でマイクロ化する。

• 機能単位であれば数か月くらいでコードをリライトでき、品質も担保できる開発規模である
• サービス間の通信も発生せず障害ポイントも増えない

ということでこのような粒度にしました。

次に、すべて一気にマイクロサービス化するのではなく、少しずつマイクロサービス化に取り組むということを考えました。新規開発案件がどんどん発生していきますので、並行して時間をかけてマイクロサービスに移行する方針です。
最後に、リリースによる顧客影響を最小限に抑える仕組みを導入しようということを考えました。マイクロサービス化によって機能全体を書きかえることになってしまうのですが、当社の都合によるもののため、そのリリースで加盟店様の決済に影響を出してはならない。ということで、このような方針があげられました。

そして更改後の構成はこのような形になります。

• モノリスは機能単位でマイクロサービスに少しずつ移行する
• 決済リクエストはフロントのAPIゲートウェイで適切なサービスに振り分ける
• A決済はモノリス、C決済はマイクロサービス

といったような構成をとりました。

それでは、マイクロサービスとAPIゲートウェイについてもう少しお話いたします。
マイクロサービスは決済単位でスプリングブートで実装しなおしました。
それによりトランザクション量に合わせてサービス単位でスケールアウトができるようになりました。

例えば、C決済についてトランザクション量が多いのであればC決済は多めにスケールアウトさせるけれど、E決済についてはあまりスケールアウトさせない形で、決済単位で適切なリソースを使えるようになりました。
また、スプリングブートで実装しますので従来のようなWebコンテナは不要になります。将来のコンテナ化ドッカーなどの、コンテナ化の布石にもなります。

次にAPIゲートウェイです。
こちらはマイクロ化した決済をモノリスからマイクロに振り分けし変更していって、新規決済は最初からマイクロで実装するといったものになります。下の絵を見ていただきたいのですが、

左の方ではC決済はモノリスの方に流れていました。右の方を見ていただくとマイクロサービスの方でC決済が実装されています。C決済が実装されましたので、APIゲートウェイでマイクロサービスに流します。
新規サービスについては最初からマイクロサービスで実装して、マイクロサービスの方に流すとこれを繰り返すことで、次はB決済、A決済ということを繰り返すことで少しずつマイクロサービスに移行し、最終的にモノリスがなくなるといったことを計画しました。
それでは、APIゲートウェイの機能を少しご紹介いたします。

APIゲートウェイはnginx（エンジンエックス）を使って実装いたしました。nginxは高速かつ大量処理に優れているWebサーバーです。用途としてみなさんがよくお使いになっているのは、リバースプロキシだと思います。インデックスページに書かれているのですが、それ以外にも用途としてAPIゲートウェイ、ロードバランサー、WAFなどの用途があります。単なるnginxもWEBサーバーではなくて実は色々なサーバーにできます。
Luaスクリプトという言語だったりとか、JavaScriptでロジックを実装することができます。
また、トラフィック管理のモジュールがあったり他にも調べてみると色々な機能がnginxには搭載されております。

APIゲートウェイで実装した機能を少しご紹介いたします。
まず、トラフィック管理です。Dos攻撃のような大量アクセスに備えて制限値以上の流量を制御する機能です。nginxの標準機能もあり、我々はlimit_connやlimit_reqと呼んでいるのですが、limit_connの方は同時接続数で制限する、limit_reqの方は時間あたりの処理数で制限する。それをオーバーするとバックエンドに流さずにそのまますぐにエラーを返すことで、Dos攻撃を防ぐことができるといったものになります。
さらにマルペイでは少々特殊なトラフィック管理を行っているのですが、特殊な制御はLuaスクリプトで+Redisで実装します。これにより、サービス性能/性質に合わせた流量制御が可能となります。

次にBlue-Greenデプロイになります。
旧バージョンとは別に新バージョンを本番環境に構築しまして、テストリクエストを流して新バージョンのテストを行います。新バージョンは問題ないとなった段階で、APIゲートウェイで新バージョンに流すといった手法です。

次にカナリアリリースです。
こちらはリクエストを少しずつ新バージョンに流すリリース手法で、旧バージョンをリリースしておきまして、少しだけ新バージョンに流します。
問題がなくなった段階で、全量新バージョンに流すといった機能になります。この全体のうちの少しというのは、何％特定のこのIPといったやりかたで流すことができます。

課題解決を起点にした段階移行の考え方

まとめです。
モノリスからマイクロサービスへの移行ですが、こちらまずは解決したい課題を整理するべきだと思います。マイクロサービスは目的ではなく手段なので、まずは課題を整理するといったことが大事だと思います。
実施するなら段階移行がおすすめです。新規サービスなら良いのですがレガシーからの移行は全部を一気に実行するのは心が折れます。段階移行できる仕組みを準備して段階的に移行するといったことがおすすめです。

APIゲートウェイはとても便利なので他サービスでも検討してみてください。マイクロサービス移行計画は現在も進行中です。
私からの発表は以上となります。ありがとうございました。

FAQ