金融・決済インフラのハイブリッド化と技術選択【GMO Developers Day 2023】

クラウドとオンプレミスを組み合わせたコンテナ構成

インフラに関する議論ですので、まず始めに、本年に特定のサービスで採用された新しいアーキテクチャの構成図をご紹介します。それはコンテナクラスタであり、コントロールプレーンをクラウドに配置し、コンピューティング部分をオンプレミスのデータセンターで運用するという形式を取りました。このアプローチは、既存のサービス群に新たな機能をアドオンとして導入する形でローンチされました。この新しい選択肢を採用した背景について、詳細をお話しします。

自己紹介

まずは自己紹介から始めさせていただきます。私の名前は駒井と申します。現在、GMOペイメントゲートウェイに勤務しており、加えて今年GMOインターネットグループのデベロッパーエキスパートに任命されました。このような立派な場で話しをさせていただけることを光栄に思います。 職業としては、Webサーバーサイドエンジニアリングを基礎としており、それに加えてシステムやオペレーション、事業全体のアーキテクチャ設計も行っています。プログラミング言語に関しては、典型的なエンタープライズサーバーサイドのスキルセットを持っています。

GMOペイメントゲートウェイって？

次に、GMOペイメントゲートウェイについてご紹介します。当社は決済代行を主軸に、マーケティング支援やファクタリング、レンディングなどの資金繰りサービスを提供し、お金の流れに関する総合的なサポートを行っています。

支える規模感

現在の当社規模については、2023年9月時点でのデータを基にしています。当社は9月に決算を迎えるため、前期の実績はこのような数字になります。自分自身のこととは言え、この数字を公の場で話す度に、その責任の重さに驚かされます。

では、改めてテーマに戻ります。

金融・決済分野におけるクラウド活用の変遷

このセッションでは、「決済インフラ2023のハイブリッド化の現在地」というテーマを扱います。私たちの会社は決済金融分野に属しており、この分野でクラウドを採用するか否かという議論は、もはや行われていないと考えています。

金融/決済分野のクラウド利用は当たり前

皆さんがご存知の主要な海外パブリッククラウド勢が日本で事業を開始したのは、2010年代前半から中盤です。金融決済分野でのコンプライアンスの厳しさを考慮した際に、クラウドが使用可能かどうかについては、2016年や2017年頃には感覚的に決着がついていたと思います。現在は、クラウドをどう活用していくかというフェーズに移行しています。

従来のクラウド選択はシステム・事業単位

それでも、クラウド導入前の時代からオンプレミスで資産を積み上げてきた事業者にとって、クラウドに取り組むことは、選択の粒度が大きな挑戦です。これは、「このシステムはオンプレミスに置いておこう、このシステムはクラウドで始めましょう」といった、大きな箱が2つあり、意思決定が大規模なサイズ、あるいは事業単位で行われるということです。

例えば、当社の事業で言えば、決済代行の中心部分はオンプレミスのデータセンターで全てをホワイトボックス化して私たちが責任を持って運用しています。一方で、インキュベーション的な事業については、クラウドで、技術選定を迅速に始めたいと考えています。

GMO-PGの決済インフラ変遷も同様

当社のインフラの変遷は、2018年頃までは、全てのサービスがオンプレミスのデータセンターで運用され、私たちがサーバーを入れて決済を行っていました。2018年から、決済の周辺サービスをフルクラウドで提供する試みが始まり、経験値が蓄積され、2020年からは中心事業である決済代行サービスをフルクラウドで行うことにしました。これが我々のインフラ構成の現在地です。

システム単位の併存とハイブリッド構成の違い

スライドに「ハイブリッド化」というタイトルを付けましたが、実際には、一部の事業がクラウドを使用し、他の事業がオンプレミスを採用しているだけでは、単にクラウドとオンプレミスの2つの「箱」が存在しているに過ぎません。事業全体を俯瞰するとハイブリッドの構成にはなりますが、システム構成としての変化に注目することが重要です。

技術選択のキーワード「高解像度化」

キーワードは、僕が勝手に考えましたが、「高解像度化」だと思っています。

事例1：オンプレミスとクラウドを組み合わせたコンテナ運用

事例1では、「わがままにコンテナ」と題し、新規サービスをコンテナクラスタで構築し、コントロールプレーンをクラウドに委ねる構成を紹介します。

コンテナクラスタをハイブリッドで構成

当社ではAWSを使用し、ECSウェアというサービスでコントロールプレーンを管理しています。

既存のオンプレミス（KVM）環境を拡張する要件

この構成に至った理由を説明しますが、出発点となった要件は、既存のオンプレミスデータセンター上のKVM群で運用されているアプリケーションとデータベースの構成に、事業拡張レベルの機能を追加したいというものでした。事業は同じで、データベースは既存のものと共有する必要がありました。2018年からクラウドに取り組んでおり、コンテナクラスタを使用することで、デプロイプロセスと構成管理が安定していて、また、クラウドではデプロイに関する事故が0になるなどが実感できました。 一方どうしてもオンプレミスでKVMホスト、ゲストをセルフマネージしていくとリソースが少しずつ余ってしまう状態になりがちです。

フルクラウドでコンテナ化を検討

コンテナクラスタをクラウドに委ねることにより、集積率をより高めることが可能です。このメリットは享受したい。従って、この機会に全ての既存事業をクラウドに移行することが良いのではないかとなりました。KVM部分からコンテナなため、アプリケーションそのままシフトとはいかず、この部分はシフトする、データベースはリフト。これはできないなどの制約がありました。

制約1：サービスを停止できない

今回の事業計画やプロジェクトのスケジュール上、サービスを停止するタイミングを設定することができませんでした。したがって、決済のように悲観的、同期的に更新を必要とするサービスを、稼働中にデータ移行することは、非常にリスクが高いことでした。例えば、アプリケーションからIDを基にデータベースへのアクセスを振り分けるプロキシレイヤを導入する必要があるなど、移行をワンタイムで実施することは合理性がある一方で、リスクが高いという問題がありました。

制約2：既存環境のコンテナ移行と経済合理性

もう一つの重要な点は、コンテナシフトの経済合理性に関するものです。プロジェクトにおいて、クラウド側で新たな価値を創出するこの"黒い箱"、すなわち新しいサービスを提供することが私たちの本来の目的であることを考慮すると、既存のKVM群をコンテナ化し、コンテナシフトを行うことは、直接的にトップラインを上げる要素には成りえません。これはあくまでボトム（基盤）の改善に過ぎず、その作業を行っているワークロードがある場合には、新しい事業を立ち上げ、より優れたものを提供することが望ましいです。これには経済合理性があると思います。

制約3：OSの自己管理負担を増やさない

そこで、KVM群をそのままの状態で維持し、OS、アプリケーションの構成を変更せずに、クラウドへの移行ではなくリフトアンドシフトを検討することになります。しかし、その場合、クラウド側でOSを管理する必要があり、セキュリティパッチの適用、ユーザー管理、監査などの運用に関わるコストが継続的に発生します。実は、新しいパターンをクラウドで作りたくないというのは、少しわがままかもしれません。

逆の発想（オンプレ＋コンテナ）は？

逆のアプローチを取り、オンプレミスのデータセンターでコンテナ技術を採用するという案についてですが、我々は実際に2018年頃にKubernetesを試験的に導入した経験があります。しかしながら、その時点でのKubernetesの成熟度は、エンタープライズ環境での運用要件を満たすには至っていませんでした。

エンタープライズ向けの運用を実現するためには、常に最新の状態に追従し、運用を継続するための専任のエンジニアチームを少なくとも2名配置する必要があることは明らかでした。そのため、採用しませんでした。

2023年に選択したハイブリッド構成

しかし、コンテナ技術のメリットを享受することには強い関心があります。 運用上の負担はクラウドサービスに委ねることで、リソースの集約やデプロイの安定性などのメリットを享受しつつ、既存事業への大きな変動リスクを避けることができるという結論に至りました。

まとめ:わがままにコンテナ

まとめとして、私たちはメリットを享受しつつ、運用上の負担をクラウドに任せたいと思っています。この選択をすることができたのは、2018年からクラウドに取り組んできた経験があり、クラウドとオンプレミスの違いを超えて、各要素の信頼性や注意すべき点に対する深い知識があるためです。

事例2：CDNとスロットリングによるトラフィック急増対策

次に、ある事例を紹介します。有事の頼りになりますが、あまり自慢はできないトラブル事例について話します。 特定のサービスでプロモーションセールが行われた際に、トラフィックが急増しました。この急増したトラフィックが原因で、当社のデータセンターのネットワーク入口部分に過負荷が生じ、サービスが停止する状況になりました。オンプレミスのデータセンターを運営する事業者であれば、共用ネットワーク機器でのトラブルが他のサービスへ影響を及ぼす可能性があることをご理解いただけるでしょう。これは残念ながら、我々にとって好ましくない状況でした。

お客様のセールで発生したトラフィック急増

この事例では、トラフィック急増により、当社のデータセンターのネットワーク入口でオーバーロードが発生し、結果としてサービスが停止する事態に至りました。オンプレミスのデータセンターを運営し、多様なサービスを提供する事業者の場合、共用ネットワーク機器でのトラブルは、原因となったサービスだけでなく、他のサービス利用者にも影響を及ぼす可能性があります。このような事態は、我々にとって非常に申し訳なく、かなり悪いケースでした。ではどのように解決していくのでしょうか。

一般的に、トラフィック急増に対処する方法として、CDNを利用してエッジレベルでトラフィックを分散させることが考えられます。しかし、決済システムのように中央集権的に管理されているサービスは、その性質上、分散が難しいのが現状です。もしブロックチェーンのような技術が広く普及していれば、異なる対応が可能だったかもしれません。しかし現在のところ、ECやWeb決済は中央集権的な管理が必須であり、エッジでの分散は困難です。

決済処理をCDNで分散することの難しさ

キャパシティ不足に直面した場合、単純にスケールアップする選択肢が考えられます。今回は幸いにも、トラフィック急増の引き金となったお客様がサービスの継続利用を決定し、次のセールが2週間後に予定されていることを連絡してくれました。

次のセールまで2週間という時間的制約

しかし、2週間の期間でデータセンターのネットワーク機器に手を加えることは現実的ではありません。データセンターの運用に携わる方ならご存知の通り、ネットワーク機器の入れ替えは大がかりなイベントとなります。そのため、2週間でのトラブル解決は困難です。

CDNとスロットリングで流入量を制御

この問題をどのように解決したかと言うと、CDNを使用してトラフィックを一旦受け、クラウド上でスロットリングスクリプトを適用し、トラフィックをシェービングしてオンプレミスのデータセンターが処理できる量に調整しました。 トラフィックのシェービングを行うことにより、例えば100や5といった数字を用いたイメージで説明すると、大量のトラフィックを効果的に処理し、オリジンのデータセンターへ適切に流すことが可能になります。このプロセスにおいて、処理できない95%のトラフィックはいわゆる「申し訳ありませんが、現在混雑しております」という応答によって処理されます。これにより、サービスがオーバーロードするリスクや、決済の整合性が取れているか不明な状態、そしてコントロール不能な状況を避けることができます。さらに、トラフィックを適切に管理することで、顧客のウェブサイトが過負荷で停止するという事態も防げます。

このスロットリングメカニズムは、我々のフルクラウドサービスにおいて基本的な機能として設置されています。フルクラウド環境では、バックエンドのオリジンがクラウドのコンテナクラスタなどになるため、スロットリング機能をフロントエンドから分離し、オンプレミスのデータセンターへ適用するための調整を行い、デプロイします。この意思決定から実装に至るプロセスは、実質的に約1週間で完了しました。金融決済の分野では、本番環境に何か新しいものを導入する決定から実装までを1週間で完了することは非常に困難ですが、我々はこの短期間で対応することが可能でした。

まとめ:有事の頼りに

まとめると、フルクラウドの構成、すなわち「大きな箱」の中から特定のコンポーネントが特定の課題を解決できること、または異なる課題が別のコンポーネントで解決可能であることが明らかになりました。これは、システムや事業全体だけでなく、特定の技術を用いて個々の課題に対処するという理解が深まったことを意味します。また、今回の事例ではトラブル対応がテーマであり、トラブル対応の過程で再度の失敗、すなわち「二重事故」を避けることが最も重要であるという認識が強調されました。この状況下でエンジニアチームが信頼できる解決策を見出し、成功の見込みを感じられるようになったことは、この事例の初論になるかなと思います。

さらに、この3つ目の事例では、意思決定から実装までが約1週間という短期間で完了しました。これは、既に確立されたアセット、例えばAWSのクラウドフォーメーションテンプレートなど、特定のコンポーネント技術が迅速に適用可能であることを示しています。これらのアセットが利用しやすく、他の目的にも応用可能な「手に馴染んだ道具」となっていることが、このプロセスの効率性を高めています。

技術選択の高解像度化がもたらす変化

改めて、キーワードは「高解像度化」になります。これは、技術選択の細分化が可能になってきたことを意味します。初めに見てきたように、システムや事業単位での大規模な意思決定、「オンプレミスで運用するか、クラウドで始めるか」という選択から、特定の課題に対して最適な技術選択が可能になってきた現状を指します。以前は、一度大きな方針を決めると、その後の様々な課題をその枠組み内で解決しなければならないという制約がありましたが、最近1、2年での技術理解の進展により、事業やシステム全体ではなく、個別の課題に対してより適切な選択が可能になっています。この変化は、特定の課題がクラウドで、別の課題はオンプレミスで解決できるというように、個々の問題に対して具体的な解決策を選べるようになったことを示しています。

現在は解決が難しいとされる個別の課題も、将来的にはAIによって解決できる可能性があります。しかし現時点では、決済のように精度が要求される分野にAIを適用することにはリスクが伴います。これは、生成AIがまだ不確実性を完全には払拭できないためですが、技術の進化により、AIが効果的に活用できる瞬間が訪れると考えられます。

個別最適とシステム全体の複雑性のバランス

しかし、注意しなければならないのは、個別の課題に対して最適な選択肢を選ぶことができるようになると、システム全体の複雑性が増加することです。例えば、クラウドで処理を受けてからオンプレミスのデータセンターで統計処理を行い、再びクラウドで処理するなど、システムを跨いだ複雑なフローが増えると、システム全体の管理やトラブルシューティングが難しくなります。このため、個別の最適解を追求する一方で、全体の複雑性を管理し、バランスを取ることが今後の課題です。システムが複雑化することによるメリットは少ないため、慎重に進める必要があります。

まとめ

まとめとして、過去1、2年で当社の決済インフラにおいて見られた変化は、オンプレミスとクラウドという二者択一の大枠からの脱却です。サービスや事業を開始する際に、この2つの選択肢から一方を選んで進むという時代は過ぎ去ったと考えています。現在は、システムや事業全体ではなく、具体的な課題に対して最適な解決策を選択できるようになりました。これは、私たちの経験に基づく選択です。しかし、システムの複雑化には注意が必要です。基本的に、システムやサービスのアーキテクチャは、できるだけシンプルであるべきです。理想的には、物理サーバーを購入し、仮想化されていない基本のOSにアプリケーションとデータベースを搭載して運用することが最も望ましいです。

しかしながら、私たちが直面している課題の複雑性を考慮すると、アーキテクチャの複雑化は避けられません。そのため、どの複雑化が必要であり、どのような複雑化を避けるべきかを慎重に判断する必要があります。この点に注意を払いながら、よりハイブリッドで、迅速かつ適切なソリューションをお客様に提供していくことが、私たちの今後の方向性です。

FAQ