Google Cloud Next Tokyo ’24 にて行われたセッション「大規模決済中継システムにおける Cloud SQL から Spanner への移行と苦労」のレポートです。
Google Cloud Next Tokyo ’24 とは？
2024 年 8 月 1、2 日の 2 日間でパシフィコ横浜で開催されている、Google Cloud が主催する国内最大級規模のイベントです。
https://cloudonair.withgoogle.com/events/next-tokyo-24
登壇者
株式会社NTTデータ カード＆ペイメント事業部 主任
鳥海 克成 氏
株式会社NTTデータ カード＆ペイメント事業部
松井 僚太郎 氏
セッション内容
Omni Payment Gateway について
Omni Payment Gateway は決済中継、決済代行、申し込みや問い合わせなどのデジタルオペレーションが統一したプラットフォーム上で行えるサービスです。
導入することで、消費者には自由な購買体験を与え、加盟店は煩雑な決済業務からの解放を実現できることが特徴です。
また、開発には大規模アジャイルフレームワークの「SAFe」を利用しているとのことでした。
アーキテクチャ
アーキテクチャは以下となっています。
また、監視やコスト削減の仕組みなども紹介されていました。
例として、本番以外の環境のインスタンスは日中以外は自動で停止する仕組みなどが挙げられています。
移行の経緯
そもそも当初 Cloud SQL を利用していた背景は以下の通りでした。
しかし、メンテナンスによるサービス停止や可用性要件、今後 TPS が 50 倍となる見込みから移行に踏み切ったとのことです。
また、DB の選定もそういった面を考慮して Cloud Spanner を採用されていました。
気をつけたこと
移行前、移行中、移行後のそれぞれのフェーズで、気をつけたポイントが紹介されています。
移行前
移行前の段階では、 Spanner のパフォーマンスを活かすために以下の観点について検証を行われていました。
- テーブル構造
- ホットスポット回避
- セカンダリインデックス
- クエリ
- shardID による時系列データ検索
- Spanner での検索方針、BigQuery の利用
- 非機能観点
- コスト
- レイテンシー
移行中
移行中は、アプリケーション部分に負荷をかけないことやデータの不整合を防ぐ仕組みに注力されており、その結果ゼロダウンタイムでの移行を達成されています。
また、データ変換は大量のメモリを消費するため、最大インスタンスタイプをマシンタイプから選択できるという利点から Batch を選定されていました。
移行後
移行後は、リソース監視として以下を実施されています。
- Query Insights with Request tag
- クエリごとのタグ付け
- ダッシュボード
- ロックの分析情報
- トランザクションの分析情報
- システムの分析情報
- Key Visualizer
その他苦労点
その他にもポイントや工夫された点について語られていました。
- 予期せぬロック待機を発生させないためのポイント
- Spanner のセッションプールの設定
終わりに
Cloud SQL から Cloud Spanner への移行についてのセッションでした。
実際に行った手順やハマったポイントなどを具体的に紹介されていて、非常に勉強になりました。
