［登壇レポート］GMO DevelopersNight#37 / 公共料金における決済システムの裏側 / 開発者向けブログ・イベント

5月31日（水）にオンラインで開催された「GMO Developers Night #37」では、オンライン化・キャッシュレス化・DXなどを支援する決済を起点としたサービスを提供しているGMOペイメントゲートウェイ株式会社が登壇。
公共料金における決済システムに関して、その概要や裏側など幅広いトピックを紹介しました。

イベント告知：https://developers.gmo.jp/33096/

登壇者

GMOペイメントゲートウェイ株式会社システム本部プラットフォームサービス

統括部長　高島貞裕
開発部長　飯島清孝
開発課長　佐藤猛
開発担当　鈴木貴仁

決済関連の事業者で働くということ

イベント冒頭では、高島がGMOペイメントゲートウェイ（以下、GMO-PG）の会社概要を説明しました。

GMO-PGは、ネットショップや公共料金などの加盟店とクレジットカードやコンビニ決済といった決済手段を提供する決済会社とをつなぐサービスを展開しています。現在加盟店舗数は16万を超えており、年間決済処理件数は55億件、年間決済処理金額は13.2兆円という実績を誇ります。営業利益年25%成長を目標に掲げ、現在も取引量は増加しており、これに伴いシステム開発の規模も年々増大しています。

登壇者らが所属するシステム本部には約200名のメンバーが所属しており、毎年、新卒・中途を含め30名程度のエンジニアを採用しています。拠点は東京・渋谷オフィスに加え、福岡にも開発拠点があり、2拠点を連携しながら日々プロジェクトが進められています。

GMO-PGのような決済事業者で働くにあたり重要なポイントとして、高島はまず「ミッションクリティカル」をあげます。システムには、24時間365日の高可用性・高信頼性、不正取引・不正アクセスを防止する高セキュリティといった厳しい非機能要件が求められます。高島は「社会インフラであるという自負のもとサービスやその開発を追求しており、それをやりがいに感じているところがGMO-PGのエンジニアの特長」と語ります。

また高島は「マイサービス」、「フルスタック・フルフェーズ」もポイントだといいます。GMO-PGのサービスは完全内製で、要件定義からリリース、運用までのすべての工程を自社パートナー（社員）で担っています。マネージャーを含めコードを書けるメンバーが揃っており、コードでコミュニケーションできるのが組織の強みです。高島は「ドキュメントやソースについて必要なものを自分たちで考えて残していく文化がある」と説明していました。

「マルチビリングパッケージ」と「GMOデジタル請求サービス」

飯島は、公共料金における決済サービスの全体観について紹介しました。

GMO-PGは、2016年4月からの電力自由化のタイミングに合わせて、様々な決済手段を一括で導入できるオンライン総合決済サービス「PGマルチペイメントサービス」をベースとした電気・ガス・水道等向けパッケージ「マルチビリングパッケージ」をリリースしました。電気・ガス・水道等の公共料金は大きく分けて、払込票払い、クレジットカード決済、口座振替という3つの支払い手段があります。

マルチビリングパッケージを利用すると、電気・ガス・水道を提供している加盟店は統一されたインターフェイスで各支払い方法によってユーザーに請求を行うことができます。現在マルチビリングパッケージは、月間1000万件を処理するほどの規模となっています。

一方、紙での手続きが必要となっていた払込票のDXを目指したサービスが「GMOデジタル請求サービス」です。払込票に変わりSMSを利用して支払い用のURLをユーザーへ送付するというもので、PGマルチペイメントサービスに対応している多くの支払方法が可能となります。結果として、印紙代や郵送費を削減でき、ペーパーレス化を実現できます。SMSを利用するため、支払い忘れ防止のためのリマインド送付、削除してしまった場合の再発行、督促の案内なども可能となっています。月間約400万件、1日約20万件の処理に対応可能です。

また、マルチビリングパッケージとGMOデジタル請求サービスをあわせて利用することで、クレジットカードでの支払いをシームレスに継続払いへと切り替えることもできるようになっています。

マルチビリングパッケージ開発の裏側

佐藤は、マルチリビングパッケージ開発の裏側について紹介しました。

マルチリビングパッケージは、拡張性・安定性の2つを意識したサービスになっており、マイクロサービスの考え方を採用しているのが特長です。具体的には、下図のようにプレゼンテーション部分と共用ビジネスロジック部分を分離。プレゼンテーション部分は、会社ごとの要件に応じてUI・ファイルのインターフェイスを完全に分けています。共用ビジネスロジック部分は、支払方法、業務、会員処理、取引売上処理といった単位で分かれており、クレジットカード会社や外部の収納機関等と接続している部分でもあります。

こうした形でマイクロサービスを採用するメリットは、細かい単位で開発できる点にあり、佐藤は「担当しているお客さまごとにチームを編成しやすく、小さな規模感で開発を進められる」と説明します。また、障害ポイントを特定しやすいというメリットもあります。障害によってどれだけ影響が生じたのか調査範囲も限定しやすく、報告の際にも説明しやすくなります。リスクを取りやすいため新しい技術を積極的に試せる点、1つひとつのシステムのサイズが小さいため、ビルド・テスト・デリバリーといった一連の開発サイクルを高速に回せる点などもマイクロサービスのメリットになります。

一方で、リグレッションテストの強化は課題です。共用ビジネスロジック部分は共通要素を取り持つ部分になるため、万が一サービスの修正や変更時に十分なテストができないと、場合によってはシステム全体に影響が出てしまう可能性があります。佐藤によると、この対策として現在途上段階ではあるものの、特にビジネスロジック部分は、単体テスト、結合テストのレベルまで自動化することを社内標準としているといいます。

佐藤は、マイクロサービスについて「お客さま単位、会社単位で並行して開発を進めるスタイルと相性がよいアーキテクチャ。一方で、レイテンシーの問題やデータの一貫性が保たれないといった負の側面もある。（採用するかどうかは）それらをすべて理解したうえで判断したほうがよい」とコメントしていました。

マイクロサービス化に加え、拡張性・安定性を担保するためのもう1つの取り組みとして、等身大の分散化処理があります。

もっともボリュームがあるクレジットの一括請求処理を例に見ていきます。まずは、Job Controlサーバーで個社などのブロックごとにA、B、C……と分けています。こうして個社単位にしたブロックをマルチスレッドに分割して並列に処理します。データベースは、クエリ生成のオーバーヘッドが発生しないようBULK処理によって一斉に書き出しを行います。

このような構成にするメリットについて佐藤は、「マイクロサービスと同様、障害発生が特定のお客さまに限定される。イレギュラーな事態が起きた際に最小限で済むようにすることを強く意識している」と説明します。

クレジット処理という重要なシステムを扱うにあたって、ブラックボックスを排除するため、慣れ親しんだPure Javaですべて構築しているのも特長です。佐藤は「地味だが、安定的に運用するために重要な点」とします。顧客ごとに異なる性能要件に応じてリソースをチューニングしやすい点もメリットの1つです。佐藤は「お客さまによっては短期間で1000万件を超える処理が必要な場合もあり、ハードごと調達して専用サーバーを構えるといった判断もしやすくなる」と説明します。

マルチビリングパッケージ開発チームは、仕事をするうえで「現場を知る」「挑戦する」という2点を大切にしているといいます。「本当の意味でお客さまが望むデジタル化を果たすには、お客さまの業務やシステムを深く理解することが大事。また、システムの規模が大きくなるにつれ、リスクも増えていく。そうしたなかでユーザビリティ向上、品質確保、コスト削減をどう実現できるか、日々新しいことに挑戦して課題解決していく思考能力が求められている」（佐藤）

GMOデジタル請求サービスの裏側

鈴木は、GMOデジタル請求サービス開発の裏側について紹介しました。

GMOデジタル請求サービスのシステムは、AWS基盤をベースに構築しつつ、オンプレミスとも併用する形としています。2018年の開発当時、AWSを使ったサービスはGMO-PG内にはなかったといいますが、なぜAWSを選定したのでしょうか。鈴木は理由の1つとして、性能要件に柔軟に対応できる点を挙げています。「最初の加盟店では、月間400万件の請求依頼・処理が発生。1日あたり20万件となるが、24時間のうち均等にエンドユーザーが決済処理するわけではなく、SMSが送信された瞬間など決済が集中してしまう時間がある。クラウドは基盤性能を柔軟に変更できるので、このムラに対応できるのがメリットだった」（鈴木）

また、決済処理の根幹には既存のPGマルチペイメントサービスを利用することによって、AWS上にはカード番号を保持する必要がなくなった点も、AWS導入に踏み切れた理由の1つだったといいます。
当サービスの主なアプリは、エンドユーザーがブラウザ上で支払手続きする支払画面、加盟店の管理画面、加盟店のシステムから利用するAPI、業務バッチ群から成り立っており、AWSに構築しています。

一方、加盟店とのファイル連携およびジョブ管理の用途で一部オンプレ環境が利用されています。オンプレ環境でファイル連携する理由としては、既存加盟店に既存ルート・回線を使って当サービスを新たに導入してもらいやすい、加盟店とのファイル授受からジョブ管理までの処理を一気通貫で行える、といった点が挙げられます。ジョブ管理には別サービスのオンプレ環境で使っていたJP1を利用しており、そのノウハウが活かせる点も重要でした。

オンプレ環境のジョブ管理サーバーからAWS上のバッチジョブを実行する際や、ファイルをAWS～オンプレ環境間でやりとりする際にはDirect Connectという専用線を通して行います。

各アプリはDockerコンテナで稼働するようになっており、ECSというAWSのサービスによって全自動で管理されています。コンテナの実行環境であるデータプレーンにはFargateを利用しています。ECSやFargateを利用することでインフラ管理が不要となり、開発者はビジネスロジックの実装に専念することが可能となります。また、Fargateの読み取り専用化機能を有効にすることでアプリケーションの不正改ざん防止につながるなど、セキュリティ強化という面でもコンテナ化のメリットは大きいです。

プログラミング言語はJava、フレームワークとしてはSpring Bootを利用しています。コンテナはタスクという単位で実行されており、アプリケーションの負荷状況によってオートスケーリング機能で自動的に増減させています。この機能は、時間帯によってユーザーからのアクセス数が偏ってしまう当サービスの特性とも相性がよいといえます。また、マルチAZ構成にすることで可用性を高めています。

GMOデジタル請求サービスでは、今回取り上げていないAWSサービスも多く利用しており、鈴木はオンプレとAWSを適材適所で使い分けることで、支払い方法の拡充、SMS以外の通知方法の拡充など、今後もスピーディーに新機能を加盟店に提供していく考えを示しました。

エンジニア採用実施中！

GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用 HPをご覧ください。

また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。
https://www.gmo-pg.com/blog/feature/feature03/

さいごに

ご視聴・ご参加いただき、ありがとうございました。
参加いただいた方からは、どのようなサービスを提供しているのか･システム構成なのか、非常に参考になえいました、決済システムならではの考慮点など非常に勉強になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。

映像はアーカイブ公開しておりますので、
まだ見ていない方、もう一度見たい方は是非この機会にご視聴ください！