決済事業でサーバーレス/ツボを押したらコスト10分の1の衝撃

• 
• 
• 
• 

サマリ

私の勤めるGMOペイメントゲートウェイ株式会社では、決済領域で総合サービスを提供しています。決済領域と言えば、System of Recordの典型で、データインテグリティこそが価値の源泉です。従って、伝統的には悲観的・同期的なアーキテクチャが採用されます。そんな事業領域の中で、サーバーレスアーキテクチャでサービスを構築しました。どんな事業で、どのような基準でサーバーレスを選択し、何を成して何が課題なのか、顛末を記します。

本稿におけるサーバーレスを定義

本題の前に、本稿における”サーバーレス”を定義しておきます。

“アイドルリソースを小さくしてコスト構造を最適化するアーキテクチャ”

と定義します。焦点をコストに絞ります。

他にも要素あるんですが、発散してしまうのでこれだけで。

決済領域とサーバーレスのもどかしい相性

決済領域を支えてきた伝統的なシステムのアーキテクチャは、一般論としてサーバーレスとは相性があまり良いものではありません。なぜか？

厳密な同期性<->結果的整合性

冒頭記載した通り、決済はSystem of Recordの代表選手です。どの瞬間でも、データは同期的に整合性を保っていなければいけません。それは、1トランザクションの処理中におけるミリ秒のスケールだけではなく、与信・確定・取り消し・不正による払い戻し・・・等、数分から長いものでは1年(旅行業のお客様など)の時間軸に渡ってステートを厳密に管理する事が求められます。これを達成するために、RDBのACID特性をフル活用した同期的・悲観的な整合性を維持するアーキテクチャを選択する事になります。

一方サーバーレスでは、小さなUnit of Workで保たれたコンポーネントをメッセージで非同期に繋ぐことがほとんどです。ピ〇ゴラスイッチ的。このケースでは、可用性のためにメッセージの二重化などが行われ、短いタイムフレームでは整合性が担保できないか、担保するための実装がユーザーの責任になり、却って複雑性が増します。

事業の時間軸が長く、費用の柔軟性は不確実性にもなる

決済領域は、事業の時間軸が長いものです。一度お客様に提供を開始すれば、停止、改廃は社会的なインパクトが甚大です。そのため、当社では事業開始時に5年後のビジネスプランに基づくキャパシティ想定でインフラを調達します。これは、特に事業の初期においては過剰なリソースにコストを払っている事になります。

しかし、別の見方として、”5年分のインフラコストを、初期段階から確度高く計画的に執行可能”ともいえます。決済インフラを公開企業の立場で運用する当社の経営視点ではメリットです。その観点に立てば、サーバーレスによるオンデマンド、イベントドリブンなコスト構造はボラティリティが高く不安定である、という評価も成り立ちます。

従って、決済と周辺事業においては、サーバーレスで柔軟なコストは善であり、オンプレ/プロビジョンドによる固定化は悪である、という単純な二元論で選択できるものではありません。

ではなぜサーバーレスに取り組むの？

事業初期のコスト最適化の為です。

前段で述べた通り、決済事業は当社にとってノウハウがあり、向こう五年を精度高く計画する事ができます。しかし、市場において決済だけで価値を出すステージはとうに過ぎ去り、周辺に領域を広げて付加価値を提供していく必要性があります。

それらの領域は、決済の中核よりも不確実性が高く、(残念ながら)計画より事業の速度が上がらない、平たく言えば売れない、売り方に苦しむ可能性があります。この時期、まだ産声を上げたばかりの事業に、何も生まないアイドルリソースのコストを負わせたくない。事業の利益率が下がれば、若いサービスを維持する経済合理性が説明し辛くなります。事業責任者も辛くなる。新規事業を立ち上げる気勢もそがれるかもしれない。

まとめると、

決済よりも事業の不確実性が高い周辺領域で、

直接ユーザーのお金を扱わないサービスにおいて、

より低コストでサービスを開始したい

このような状況に対応するための技術オプションとして、サーバーレスを選択肢に入れてもよいだろう。そう感じて、トライする機会を探っていました。

そんな都合の良いサービスがあるの？

24年10月に立ち上げた Verifyサービス で、フルサーバーレスを採用しました。このサービスは、ログイン、会員登録などID・パスワード以外の要素認証が必要になる場面で、その仕組みを当社が提供する事でお客様に手軽に要素認証を実装していただけるサービスです。

何故このサービスだったの？

1.決済と比較して、トラフィックが疎である

プロビジョンドな固定リソース型のアーキテクチャにおいては、アイドル比率が高まり、コストの無駄が懸念されます。

2.長期的にわたる同期的なステート管理が求められない

認証はいわば揮発性のセッションであり、認証の認否を確実に記録しさえすれば役割は終了です。悲観的なステート管理を、RDBなどの重厚なリソースで長期にわたって維持管理し続ける必要性は低いです。

3.それぞれの処理が軽量である

SMSを飛ばす/PINの一致を見るなど、各コンポーネントの責任が軽量です。決済のように、テーブルに仕掛中のレコードを登録し、カード会社に与信を確認し、不正検出を行い、それを1回のリクエスト/レスポンスで返し・・・という重厚なUoWが発生しません。

→ここでやるしかない！

アーキテクチャ

こんな感じです。内部資料から公開可能な範囲に情報を落としているので、若干の密度の薄さはご容赦ください。

ポイントとしてはこんなところでしょうか。

• 全てのサーバーサイド(SPAバックエンドAPIと非同期push処理)はlambda
• UIはSPAで提供しており、S3+cloudfrontで提供
• API gatewayを利用して簡易的なリクエストマッピングと認証の枠組みを提供
• RDBレス。dynamoDBに全てのデータを集約

一つ一つを解説すると長いので、概要に留めます。ちなみに言語はTypeScript,SPAのフレームワークはReactです。

一つだけ説明するなら、dynamoDBである理由は、データに対する”面”の処理が不要である事も大きな理由です。決済であれば、月次など一定期間のデータをいくつかの条件で検索し集計、計算する処理が必ず発生します。いわゆる”締め”です。本サービスはこれが不要であったため、個々の認証セッションを点で処理すればよく、サーバーレスかつ”点”のパフォーマンスに優れたdynamoDBを採用しました。

実際のoutcomeは

1.プロダクションコストが10分の1以下に

何に対して10分の1以下かというと、同様の構成をECS/fargate + Aurora※ で構築した場合と比較して、です。(※当社のクラウドアーキテクチャのテンプレート）もちろん、同一サービスの別構成をプロダクションで実測する事は出来ないので、試算値ではあります。しかし、fargate+Auroraの構成で、一般論として最もコストの比重が高いfargateのコンピューティングとAuroraのインスタンス、この2点で費用が発生しないことで劇的にコストが圧縮されれおり、事前の計算通りに進んでいる状況です。

コストの実数をお見せしたいのですが、流石に会社から怒られてしまうので。。。もどかしくはありますが、桁が一つ下がった世界で推移しているのは事実です。

2.開発環境の維持コストを20%程度圧縮して+α

地味に嬉しいのは、開発環境の維持コストがかなり圧縮できているという点です。当社の(比較的大規模な)サービスについて、開発環境のクラウド費用はプロダクション比50-60%程度の費用で推移しています。比較して、Verifyサービスは40%程度と、20ポイント程度低い推移です。

クラウドの開発環境では、定刻の起動停止、コンピューティングサイズの縮退など費用圧縮を行います。しかし、定刻に起動したけどあまり使われないケースなど、実需に対して起動時間のマージンは大きくなりがちです。また、このマージンを小さくしようと努力すると、開発者体験が下がります。

“そうだ、このfeature試してみたい”→”今からaurora起動するから30分待って”

これ、開発者ならテンション下がりますよね。コストカットは大事ですが、それによって開発者の生産性をそいでは本末転倒。サーバーレスであれば、これを気にせず”使いたい時すぐ使える/使わなければ費用が発生しないだけ”の環境が維持できます。コスト圧縮という定量に加えて、付加価値的な効果があったと感じています。

3.デプロイ手法のより深い標準化

当初はあまり意図していなかった事ですが、サーバーレスアーキテクチャにすることで、様々なもののデプロイ手法が一本化されました。ほぼすべてのオペレーションは”クラウドのリソーススタックのデプロイ”です。APIロジックの機能追加も、非同期push処理のチューニングも、APIのスロットリング調整も、モニタリングの実装、この4種のリソースデプロイは1つの手順で済み、つまりオペレーションが75%合理化されました。(Verifyサービスはaws cdkを活用してます。)

サーバーレスを採用する事は、おそらくクラウド(当社はawsですが、googleなど他でも)のマネージドサービスの利用と不可分です。従ってクラウドが提供するリソース管理との結合度が高くなります。クラウドベンダにロックインされることと引き換えにはなりますが、クラウドが示すベストプラクティスに則って手順の標準化が進んだ事は、当初は期待していなかった思いがけないメリットと感じています。

今後の課題

パフォーマンスの安定化

いわゆるコールドスタート問題です。lambdaのオンデマンド起動は、都度OS起動してコードを展開して処理をしているようなものであり、起動時間が安定しません。

現状は、関連する複数の処理を1つのlambda関数に統合する事で、1回の認証フロー中において複数回のコールドスタートの発生を軽減する程度の施策に留めています。これはコストの観点です。しかし、サービスがより多く使われる状況になれば、ユーザー体験の向上としてプロビジョンドな関数を準備する(=リソースを固定化する)処置などが必要になるかもしれません。

いつか来るコストの損益分岐点とアーキテクチャの転換

この記事で述べてきたように、Verifyサービスにおけるサーバーレス採用を決定した最大の要因は”アイドルリソースに対するコストの抑制”です。従って、このサービスの利用が爆発的に広まりトラフィックが密になれば、リソースのアイドル時間が無視できる比率になり、この決定要因が小さくなります。

その状況になれば、サーバーレス故のリソース単価の高さ、コールドスタートによるパフォーマンス変動の幅などデメリットが目立ち、合理性が説明できなくなるかもしれません。

その時に、アーキテクチャを変えるのか？あるいは、サーバーレスによるアーキテクチャへの恩恵を取り、サーバーレスのままチューニングする方向が良いのか？現時点でいくつかのシナリオを想定していますが、いつか選択を迫られると思っています。

まとめ

決済関連の事業を提供する当社においても、サーバーレスを活用できる場面はありました。実績のないアーキテクチャを採用するにはそれなりの緊張もありましたが、実際に活用し実に明確な定量効果がでている手ごたえはあります。

決済の基幹(ブランドやネットワークへの接続)　→　オンプレミス

ユーザー寄りの業種特化したサービス　→　クラウド(コンテナ)

事業を問わず使えるコンポーネント的なサービス　→　クラウド(サーバーレス)

当社の技術スタックの中に、確実に新たなオプションを獲得できたと感じています。決済領域での信頼、安定を維持しつつ、その中で新しい挑戦をできるのはとてもエキサイティングな事です。一緒にやってくれる仲間も募集中です。

お時間ありがとうございました。おわり。

ブログの著者欄

採用情報

関連記事

• 

  第1回 プロダクトマネジメント勉強交流会 – 社内向けエンジニアイベント【開催レポート】

  技術情報

• 

  JPAAWG 7th General Meeting　参加レポート

  技術情報

• 

  被写体を切り抜いて、簡単に背景を簡単に変更・生成できるアプリケーションを作ってみた話

  技術情報

• 

  Hyper-V上での仮想マシンのエクスポートとインポート

  技術情報

• 

  生成AI開発に最適なNVIDIA H200 Tensor コア GPU超高速マルチクラスタ導入秘話

  技術情報

• 

  RPAを作りましょう　ハイブリッドフロー編　「リバース」

  技術情報