「オンプレ勢がAWSで月300万件の決済システムを作った話」ということで、決済とAWSという観点で主にお話させていただければと思っております。

まず自己紹介です。略歴をご紹介させていただきますと、現在継続課金グループというチームに所属しており、今年で5年目になります。エンジニアとして自社の継続課金パッケージの開発であったり保守を担当しております。
これまでオンプレミスのシステムにしか触ってこなかったので、これからご説明するサービスの開発が初めてのAWSという経緯になります。

継続課金と決済

まず始めに、「継続課金とは何？」という方のためにご説明いたします。一言でいうとサービスの利用者に対し、定期的・自動的に課金を行う仕組みのことをいいます。
メジャーな継続課金サービスとして、例えば電気・ガス・水道などの光熱費であったり、家賃やローン、スマホやインターネット料金、テレビ・オンデマンド、保険商材などが代表的な事例です。
ライフラインということから景気にもほとんど左右されず、必ず利用するもののため、継続課金モデルのビジネスは安定感があるというのがひとつのポイントかなと思います。

続いて継続課金の決済についてですが、月一回、隔月のタイミングが一般的かなと思います。決済方法につきましては、口座振替、クレジットカード、コンビニ払込票、昔からこの三つが主流となっています。
払込票について、もう少し掘り下げますと、口座やクレジットカードをお持ちでない方や、持っているけど登録をしない方に対して発行するパターン、あるいは口座振替・クレジットカードで決済できなかった人に対して、督促として自宅に振込票を郵送するパターンがあるかなと思います。
未だに払込票の活用シーンは幅広く、発行数も非常に多いです。ただ、払込票に関しては昔からのアナログな方法になり、印刷代・郵送代など非常にコストが大きいというデメリットがあります。そのため電子化のニーズが非常に高まっていますが、特に公共性が高くて社会的なインパクトが大きいサービスに関しては、まだ十分に普及していない、という実情がございます。

GMO-PGのサービス

「GMO-PGとは？」というと、左側が当社の持つ配信ツールを表したもので、右側が現在取り扱っている決済手段になります。
流石に数が多いのでひとつひとつご説明はできませんが、当社の強みである、これらの配信方法と、決済手段を上手く活用していくことが、この継続課金の世界を改善していくための鍵になると考えております。
具体的には先ほどお話したような紙の払込票ですが、我々の持つこれらの配信方法と決済手段で、アナログかつコストの高い紙の払込票からどう脱却するかが、今回ご紹介するサービスのテーマとなります。

どんなサービスかというと、画にすると上図のようなシンプルなサービスになります。
左側が継続課金のサービスです。右側が利用者、つまりユーザーになります。間に当社のサービスがあります。
流れとしましては、左の継続課金のサービスから請求のご依頼をいただいて、それを請けて右のユーザーに当社から決済に誘導するための配信を行います。ユーザー側では、配信メッセージの中に決済ページへのリンクが貼られているので、そこから決済するという仕組みになっております。
特徴としましては、SMS、Eメール、モバイルアプリ、IVR（自動音声応答）等、我々が持つ配信ツールなど自由なツールで、ユーザーへ決済ページへの誘導ができます。マルチな配信機能を持っている点と、クレジットカード・スマホ決済・口座振替決済・スマホバーコード決済等、色々な決済に対応しているという点を売りにしています。

サービスを始めて数か月なんですが、既にタイトルにあります通り、約300万のユーザの料金の支払いに関してデジタル化を実現している、という状況になります。

システムについて

システムの説明になります。
いくつかアーキテクチャのポイントや運用の工夫をお話しできればと思っております。

全体の構成はこのようになっております。おおまかな構成なんですけれども、赤枠にしていますとおりDMZのゾーン、アプリケーションのゾーン、プロキシのゾーン、オンプレのゾーン、データのゾーンという5つのゾーンに分けております。

赤枠で囲っている部分がアプリケーション部分になりまして、全てECSコンテナプラスFargate（ファーゲート）で統一しております。
オンプレのようなホストやゲストのOS管理であったりミドルウェアの管理であったりというのが、Fargateを使うことによって基本的に不要となります。純粋に本業である決済のアプリケーションの開発に専念できているというところが一番大きなメリットかなと思っております。

セキュリティ対策

続きまして、セキュリティに関する対策としてご紹介させていただきます。データアクセスの制御を挙げております。
赤枠の中を見て頂くと、データAPIという暗号化されたデータでのみ通信できるアプリケーションがあります。必ずこのAPIを利用しないとデータベースにアクセスできない、という仕組みにしております。なぜわざわざこのようなAPIを用意しているかといいますと、セキュリティの強度を高めるための設計となります。
具体的な例でご説明させていただきます。

例えば、この構成の中のアプリケーションゾーンに、侵入された場合というのを想定します。この図のように、アプリケーションゾーンの決済アプリにOSに侵入された場合を考えてみます。
侵入者はデータを盗もうとするので、データベースに直接アクセスを試みますが、基本的にはデータベースに直接アクセスするという事はできないのでブロックされます。というのが下側の矢印の部分になります。
次にデータAPIを使ってアクセスしようとした場合でも、このAPIを使うためには認証用ワンタイムパラメータが必要となりますので、こちらに関しても同じくブロックされるという事になります。
これで対策としては十分かと思われますが、更に全てのデータを暗号化して管理するという構成にしております。

本来であればアプリケーション自体に侵入されることがあってはいけないのと、インバウンドの対策をするというのは当然のことなのですが、このように最悪の状況を想定して、仮に侵入されたとしてもデータを持ち出されない、持ち出せないようにするにはどうすればいいか、二重三重の対策を打つということも当社は同じくらい重視しております。

もうひとつセキュリティの対策としては、外部への通信を厳しく制御しております。
通常AWSを利用する場合、外部制御についてはセキュリティグループであったり、ACLを活用するという事が多いかと思いますが、今現在私の知る限り残念ながらAWSではドメイン単位でのアウトバウンド制御には対応していない、という理解でございます。
しかしながら、当社は様々な決済会社と繋がっており、ドメインしか開示してないという接続先も数多くございます。
そのため、外部へのデータアクセスをドメインレベルで制限するためには、別の仕組みが必要となります。それが赤枠の右下の部分となり、アウトバウンドを制限するためのプロキシを用意しております。
全ての外部通信はこのプロキシを経由する必要があり、ホワイトリストに登録されたURLのみ通過できるようになっております。

先ほどと同様に、決済アプリに侵入されてしまった場合を考えてみます。
更に思考を広げて、データAPIがクラッキングされてしまってデータが取得されてしまった、という場合を想定しています。

ここから打てる対策というと、データを外に持ち出させないということになります。
赤い矢印のところに関しては、アプリケーションゾーンから直接インターネットに出ようとしているフローとなりますが、アプリケーションゾーンはプロキシ以外のアウトバウンドはできないように制限しているので、ブロックされます。必ずプロキシを経由する必要がありますが、青の矢印のように加盟店様などのホワイトリスト管理されたURLだけしか通過できないように設定しておりますので、侵入者のもとにはデータは転送されないように対策しております。

こちらは繰り返しになりますけれど、まず第一に侵入させないこと、その上で万が一侵入されても重要データを取られない。さらに持ち出させないようにする事が当社のセキュリティに対する基本的な考え方となります。

ハイブリッドクラウド

ハイブリッドクラウドということで、赤枠の部分にご注目いただきたいのですが、ジョブの管理については、オンプレミスでJP1処理しております。継続課金の世界はオンラインというよりか、どちらかというとバッチが主役になるのですが、バッチとバッチの関連付けがとても複雑なため、普段から慣れ親しんでいるオンプレのJP1を使っております。
ジョブ管理をもしAWSのサービスだけでやろうとすると、Step FunctionsというAWSのサービスが真っ先に思い浮かびますが、Step FunctionsはJSONベースでジョブの定義をしていかなればならないので、AWS未経験者には恐らく敷居が高いだろうという判断で、JP1を選択いたしました。

というわけで、AWSのベストプラクティスに沿ってアーキテクチャを考えるということも勿論必要なことですが、このように誰がこのサービスを運用するのか、という事を考えて状況によってオンプレとAWSの製品を使い分けるという事が何より重要かな、と実感しております。

CICD

GMOペイメントゲートウェイでは、エンジニアを募集しています。募集概要は以下からご確認ください。

GMOペイメントゲートウェイ株式会社「採用情報」

（by あなたのとなりに、決済を編集チーム）

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。