GMOデジタル請求サービス

自己紹介

本題に入る前にまず自己紹介です。鈴木貴仁と申します。
経歴として前職ですが、2011年4月に国内系生命保険会社のシステム子会社に新卒入社いたしました。契約保全に関わる基幹業務システムを担当し、開発・運用保守を行っておりました。
前職の主な使用環境は、JSP/Servlet等のJ2EEやCOBOLといった比較的成熟した技術を使って開発をしておりました。
8年半勤めたのち2019年10月に弊社に中途入社しました。入社当初から3年半GMOデジタル請求サービスの開発・運用保守を担当しております。
現在の主な使用環境はAWS、SpringBootなど、前職と大きく環境が変わりCOBOLエンジニアからクラウドエンジニアに転身するという形になりました。
思い入れのエピソードは2020年10月の当サービスの稼働開始に立ち会えたことです。
当サービスの開発自体は2018年から行っていたので私は途中からプロジェクトに参画した形になりますが、1年間は稼働前の新サービスを開発していたことになり、サービスローンチに立ち会えたことは思い入れ深いです。

全体の構成

ではGMOデジタル請求サービスについてお話しさせていただきます。
GMOデジタル請求サービスは紙が必要となっていた払込票の代わりに、SMS（ショートメッセージサービス）を利用して支払いURLをユーザーへ送付し、クレジットカード、バーコード決済などでお支払いいただくサービスです。

こちらがGMOデジタル請求サービスのシステム的な全体構成図となります。オンプレミスとクラウドを併用する形としておりますが、大部分はAWSクラウド環境で構築しております。
実は2018年の開発スタート時は弊社でAWSを利用したサービスは存在していませんでした。そのような中なぜAWSを選択したのかですが、まず一点目としては性能要件に柔軟に対応できる点が挙げられます。

当サービスのファースト加盟店の処理想定件数として、月400万件の請求依頼と決済処理が発生する見込みでした。営業日で換算すると1日あたり約20万件となります。
24時間均等にエンドユーザー様が決済してくれれば問題ないのですが、夜間は決済する人が少ないですし、SMSを送信する午前中は決済する人が最も多く、時間帯ごとの処理量にムラが発生する見込みがありました。
クラウドは基盤性能を柔軟に変更できる特徴がありますので、このムラにも容易に対応することができ、AWSを選定した理由の1つとなります。

他の理由として、当サービスがクレジットカード番号を保持する必要がないという理由もあります。
弊社は決済代行会社としてクレジットカード番号を保持するサービスがいくつかありますが、当サービスの決済処理の根幹は赤枠で囲まれた既存のPGマルチペイメントサービスを利用することで、AWS上にカード番号を保持する必要がありません。
クレジットカード番号を保持する際にはPCIDSSという特殊な要件が必要となるのですが、カード番号を保持しない当サービスは特殊要件を必要としないため、弊社の中でもAWSに初挑戦するサービスとして最適でした。
その他の理由として、世間がクラウドシフトしていく中、エンジニアとして興味があるので単純にやってみたいという声も社内にありましたのでAWSを選定いたしました。

続いて、各アプリケーションについて簡単にご説明します。
2つ赤枠で囲まれたところがありますが当サービスの主なアプリケーションとして、エンドユーザー様がブラウザ上でお支払い手続きをする決済画面、加盟店様が利用する管理画面、加盟店様のシステムから利用されるAPIがあります。また、業務バッチとしてAWS上に構築しております。
決済画面に関しては通常版と、個社要望にカスタマイズした個社環境を用意しております。

当サービスの大部分はAWSで構築していますが、一部は弊社のデータセンターのオンプレミス環境を併用しています。
赤枠で囲まれたところですが、オンプレ環境は主に加盟店とのファイル連携やジョブ管理の用途で利用しています。
オンプレ環境でファイル連携する理由として、既存加盟店に既存ルートを使って当サービスを導入できるメリットがあるため、このような構成としています。
ジョブ管理の方は、加盟店とのファイル授受から業務バッチ処理まで、一気通貫で処理を行いたかったため、オンプレ環境に構築しました。
また、ジョブ管理はJP1という製品を使用していますが、オンプレで提供している弊社の他サービスでも使っておりノウハウが生かせることから、このような選択としました。
図の下の方の赤枠で囲まれたDirectConnectというところですが、オンプレのジョブ管理サーバーからAWS上の業務バッチを実行する時や、ファイルをAWSと送受信する際には、DirectConnectという専用線を通して行われます。

アプリケーションの構成

次に当サービスのアプリケーション構成に関しまして、もう少し掘り下げてご説明します。
アプリケーション構成に関しましてはどの機能も同じ形としておりますので、例として赤枠の決済画面ですね、こちらを例に構成の方を説明いたします。

こちらがアプリケーション構成の概要図となります。

赤枠で囲まれたところですが、各アプリケーションはDockerコンテナで稼働するようにしております。
そのコンテナを全自動で管理・調整してくれるのがECSというAWSサービスで、GMOデジタル請求サービスでも活用しております。
なお、コンテナの実行環境であるデータプレーンはFargateというサービスを利用しております。
ECSやFargateといったAWSサービスを利用することで、インフラストラクチャの管理が不要となり開発者はビジネスロジックの実装に専念できるのがメリットとなります。
また、例えばですがFargateの読み取り専用化を有効にすることで、不正アクセスによるアプリケーションの改ざんの防止効果があるなど、セキュリティ強化の面でコンテナ化にメリットがあったりします。
ちなみに、アプリケーションのプログラミング言語はJavaを使用しており、アプリケーションフレームワークとしてSpringBootを使用しています。

アプリケーションを乗せたコンテナは、赤枠のところでTaskという単位で実行されます。

Taskはアプリケーションの負荷状況に応じてAutoScalingにより自動的に増減することができます。
先ほどもお話ししましたが、当サービスではSMSを送信する午前中が一番、決済画面のアクセス数が増加する特性がありまして、AutoScalingの仕組みを重宝して性能を上げたり下げたりといったことをしております。

また、赤枠で囲まれたところですが、複数のAWSデータセンターで構成されるアベイラビリティゾーンをさらに複数使用するマルチAZ構成にすることで可用性を高めています。
どのタスクを使用するかは、記載を省略していますがアプリケーションロードバランサーによって自動的に振り分けされます。
アプリケーション回りの説明は以上となりまして、次はマルチビリングパッケージとの連携についてご説明します。

マルチビリングパッケージとの連携

先ほどの佐藤からご説明があった通り、マルチビリングパッケージは赤枠で囲ったオンプレ環境に構築しています。

そちらのマルチビリングパッケージの連携ですが、こちら冒頭の飯島の説明と重複するところもありますが、まず中央の赤枠で囲った決済画面にてクレジットカードで支払う際に継続払いの申し込みが行えます。
申し込みの情報をデータベースに保存しておき、赤い矢印のルートを通って、右下の業務バッチにてマルチビリングパッケージに申し込みファイルを作成し連携します。
これにより、お客様はGMOデジタル請求サービスによる毎月の支払い手続きを行う必要がなくなり、マルチビリングパッケージによる自動引き落としに移行できます。
加盟店様目線でも、自動引き落としであればお客様の支払い忘れが発生しないため、回収面でメリットがあります。
以上、簡単ではありますがGMOデジタル請求サービスのシステム構成の紹介を終わります。

実際にはこちらに記載のAWSサービスを中心に構築しており、今回ご紹介できなかった部分も実はたくさんあります。
今後についても、オンプレミスとAWSを適材適所で使い分け、支払方法の拡充やSMS以外を使った通知方法の拡充など、スピーディーに新機能を加盟店様に提供していきたいと考えております。

以上ご清聴いただきありがとうございました。