AWS決済システムの開発と運用を支える設計とセキュリティ対策

継続課金の決済と払込票の電子化

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

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

GMO-PGの請求・決済誘導サービス

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

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

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

ECSとFargateを用いた決済システムの構成

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

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

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

データ保護と外部通信制御によるセキュリティ対策

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

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

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

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

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

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

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

AWSとオンプレミスのJP1を組み合わせたジョブ管理

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

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

CI/CDによるテストとデプロイの自動化

CICDまわりについても簡単にご説明させていただきます。 基本的には、CodePipeline・CodeBuild・CodeDeployを活用したシンプルなパイプラインで構成しています。 ビルド・UIテスト・デプロイとそれぞれフェーズ分けしており、ビルドフェーズではGitからソースを取得して、CodeBuild上でビルド、ECRでできあがったDockerイメージをpushするといった流れになっております。

少し目新しいのが、UIテストフェーズになります。ここでもCodeBuildが活躍しており、CodeBuild上にSeleniumであったりとかWebDriverであったり、自動テストツールをインストールしてサーバレスなテスト環境を作っております。 テストはここで自動的に実行されて、結果はSNSを通して運用者に送信されます。運用者側でテスト結果を見て、後続を進めるか、エラーが出たので中止するかといった判断が出来るようになっております。

デプロイフェーズは、AWSユーザーの方にはお馴染みかとは思いますが、Blue-Greenのデプロイの仕組みを使っておりまして、バックグラウンドで新環境の確認を行い、問題なければ切り替え、といった運用をしております。 基本的にはパイプラインを実行するだけで、一連のフローが実行されますので、手動でのオペレーションミスリスクといったものは軽減されており、時間効率を主に向上いたしました。

障害検知とメール・Teams・電話による通知

絶対気づく、すばやい初動という事で、障害検知に関してはサービス運用者にとって重要なテーマかと思います。 簡単に流れをご説明しますと、一番左側のECSの決済アプリでもしも障害が発生した場合。CloudWatchでそれを検知、SNSトピックを発行し、Lambdaが呼び出されるという流れになります。Lambdaではどのようなエラーが発生したのか、具体的なログ情報をCloudWatchから取得するようにプログラムしており、取得したログ情報をメール、MicrosoftのTeams、Amazon Connect（自動音声のサービス）、これらで運用者に通知されるという流れになります。 メールについては該当のエラー部分だけでなく、周辺行も含めたログをメールに添付しており、これによってわざわざ運用者がCloudWatchを見に行くということがなくなり調査のスピードがアップしております。 続いてTeamsについてはチャット形式で初動の対応のやり取りがスムーズになったという効果があります。 Amazon Connectについては電話に出ないと別の運用担当者にコールされるという、ローテーションで一生コールされるといった仕組みになっており、深夜帯にエラーが発生しても必ず誰かが起こされるといった構成になっております。

私からの発表は以上となります。最後までご清聴ありがとうございました。

よくある質問