2020年11月17日に開催されたウェビナー「キャッシュレスの裏側～年間トランザクション5.5兆円の決済システムを支えるGMOペイメントゲートウェイのエンジニア～」のレポートです。
私たちが当たり前のようにキャッシュレスでスムーズに決済できるのは、日々奮闘しているエンジニアの皆さんのおかげ。そこで今回は、電子商取引を中心とした事業者向けクレジットカード決済サービスを提供するGMOペイメントゲートウェイの現役エンジニアによるウェビナーの様子をお届け。決済システムを構築する上での重要なポイント、これからのエンジニアに求められるスキルなどをまとめました。
エンジニア環境はコロナ禍で大きく変わった
新型コロナウイルスの流行で、エンジニアの仕事環境は大きく変わりました。GMOペイメントゲートウェイのエンジニアの皆さんにとっても、コロナ禍がもたらした影響は少なくありません。
マイペースに生産性向上を求めるエンジニアもいれば、孤独を感じて仕事の効率が悪化したエンジニアも。二極化が進んだことが大きな変化だったそう。
話を伺っていて印象的だったのが、「雑談の重要性」。社内である程度の人間関係が構築されたエンジニアならまだしも、入社間もない新人エンジニアなどはコミュニケーションに苦労しているようでした。
｢PGマルチペイメントサービス」のシステム更改で取り組んだこと
システム本部でエンジニアを務める佐久間さんからは、PGマルチペイメントサービスの解説や歴史、今後の展望についてお話がありました。
PGマルチペイメントサービスは、加盟店決済を代行するサービス。個別開発に掛かる時間と工数を大幅に削減できる点が特徴です。
2019年のシステム更改まではレガシーでモノリシックなアプリケーションだったため、技術的負債がたまっていたそうです。また、複数案件と並行して開発やスケールアウトをしにくいのも課題でした。
そうした中、「マイクロサービス（複数の小さいサービスを連携させて管理・運営するソフトウェアのアーキテクチャ）」の存在を知り、抱えている課題が全て解決される可能性を信じて「マイクロサービス移行計画」をスタートさせました。
マイクロサービス化するにあたっての懸念点
- 現時点の開発状況でモノリス実装されている機能を、全てマイクロサービス化させる余力がない
- マイクロサービス化できた場合でも、開発量が多く品質が保てない
- 決済サービス間の通信量が増えて、レイテンシ※の悪化が懸念される
- 障害の発生場所の確認が難しくなる
※データ転送における指標のひとつ。転送要求を出してから実際にデータが送られてくるまでに生じる通信の遅延時間のこと。
これらの疑問を踏まえた上で、以下の移行方針をまとめました。
- 機能(決済手段)単位で粒度はあまり細かく設定しない
- 少しずつマイクロサービス化に取り組む
- リリースによる顧客影響を最小限に抑える
- モノリスは機能単位で少しずつマイクロサービスに移行
- 決済リクエストはフロントAPIゲートウェイで適切なサービスに振り分け
- APIゲートウェイは「nginx」で実装（nginxは高速で大量処理に優れているWebサーバーで、APIゲートウェイ、ロードバランサー、WAFなどにも利用可能）
こうして解決したい課題を整理したうえで移行をスタート。このように、マイクロサービス化に取り組む上では「課題の明確化」と「段階的な移行」が重要となります。
決して安くない学習コストを投じて取り組んだ「こんど払い」サービス
サービスアーキテクトの駒井さんからは、決済サービスをコンテナとクラウドで運用することについてお話をいただきました。
GMOペイメントゲートウェイは、2012年からオンプレミスDCでKVMのホストとゲストOS群1,500強の上で大小60強のサービスを提供。2020年からは3つのサービスをAWSのコンテナクラスタで展開しています。
さらに、2020年5月からは「こんど払い」サービスを開始。こんど払いとは、住所不要で電話番号やメールアドレス認証で利用できる後払い決済システムです。
こんど払いの「構成管理の安定」について
こんど払いの構成管理は以下の5つを意識して行われました。
- 「作って捨てる」
- テスト済みdockerイメージのマイグレーション&B/Gデプロイ
- 本番で稼働しているものを資産にしない
- chef/ansibleなどの構成管理は、良くできた組立図で作業
- コンテナイメージのポーティング⇒完成品の電源を入れる
オンプレ勢はクラウドリフトに迫られる可能性があり、オンプレのインフラ上でコンテナクラスタを運用する場合は、リソースを可用性・拡張性を維持して抽象化する必要がありました。
そのための学習コストは決して安いものではありませんでしたが、「金融や決済などはコンプライアンス強度とサービスの柔軟性の両立を求められるサービス。だからこそ、決して安くない学習コストを投じても取り組む価値はあった」と駒井さんは振り返ります。
最後に今後取り組みたいこととして、訪れるであろう「幻滅期」に対処すること、それから既存オンプレの資産移植に挑戦したいと述べました。
AWSで継続課金決済のトランスフォームに成功
継続課金グループの佐藤さんからは、継続課金やAWSをベースにした決済システムについて話がありました。
継続課金は、サービス利用者に対して定期的かつ自動的に課金を行うサービス。家賃や光熱費などの口座振替やクレジットカード、コンビニ払込みなどが主流です。
月1回や隔月が主な継続課金メニューで、払込票の電子化ニーズは高いといわれています。
AWSで継続課金決済をトランスフォーム
継続課金決済をトランスフォームさせるため、GMOペイメントゲートウェイでは「AWS」を活用しています。
AWSをベースにして、SMSやWeb配信、クレジットカード決済などマルチ決済機能を構築。スタートして数ヶ月ですが、約300万件の決済のデジタル化に成功しています。
システムは5つのゾーン(DMZ・アプリケーション・データ・プロキシ・オンプレ)で構成されています。ワンタイム認証やデータは全て暗号化されているのが特徴です。
今後は、codeシリーズの活用で「手動オペミスリスク解消」「大幅な時間効率」が向上すると予想されています。
使いやすく安定した決済サービスを実現するために
新規サービス提供に向けたシステム設計・開発・保守を担当している中村さんからは、「GMO Cashless Platform」「GMOどこでもキャッシュポイント」、これらの決済サービスを構築する際に押さえたポイントについてお話しいただきました。
「GMO Cashless Platform」は、実店舗向けQR・バーコード決済対応のマルチ決済サービス。〇〇Payといった、身近なキャッシュレス決済に大きく関わるプラットフォームです。
「GMOどこでもキャッシュポイント」は、自動精算機やATM等とスマホウォレットをつなぐQRコードインフラの構築支援。どんな場所でもカードレス・現金出入が可能なので、安心かつ便利にキャッシュレス決済ができるようになります。
新たな決済サービスを作る上でのポイント
新たな決済サービスを作るには、以下の3つのポイントがあると中村さんは述べました。
- ユーザーが使いやすく導入しやすい仕組み
- 今後予想されるサービス拡大に耐えられる仕組み
- スピーディーかつ安心・安定した仕組み
今後の決済サービスの拡大に期待が高まる
今回のウェビナーを受けて、これからも新しい決済サービスがどんどん登場し、ますます便利なキャッシュレス社会が実現していくことへの大きな期待を感じました。
キャッシュレス化が進行し、決済サービスがどんどん広がることで、トランザクション量も増えていくことが予想されます。同時に、今後システムのアップデートも求められるようになるでしょう。今回登壇いただいたエンジニアの皆さんは、時代に合わせてより良いシステムを提供できるように尽力されていました。今後の皆さんのご活躍を楽しみにしています。
なお、GMOペイメントゲートウェイのウェブサイトでは、本イベントの書き起こし記事を公開しています。セッション内容をより詳しく知りたい方は、ぜひご覧になってください！
