B2B型非同期メッセージングシステムのリアーキテクチャにおけるCloud Spanner活用

参考になった

レビュー投稿日の情報になります

Sansan株式会社 / Yusuke Fujiwara

テックリード / フルスタックエンジニア・プロダクトエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名

最終更新日2026/04/22投稿日2026/04/27

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
エンタープライズ	11名〜50名	2025年5月	B to B

導入の背景・解決したかった問題

元々Sansan Data HubというプロダクトをAzure上に実装しており、システムとしては以下の特性がありました。

ヘッドレスで多数のメッセージを並列バッチとして処理する必要がある。B2B向けなので、お客様の業務のサイクルに合わせてデータの流入量が変わる。そのため、スケーラビリティとエラスティネスが必要。逆に応答性やスケールの速さは求められない。
元々マネージドサービスを全面採用しており、チーム体制としてもインフラメンバーは少ない。

全社的なクラウド基盤の統一を伴うリアーキテクチャを実施するにあたり、以下の要件を満たすデータベースを探していました。

ACIDトランザクションが直感的に実行できること。移行元はCosmos DBであり、ACIDトランザクションはサポートされていましたが、固有の書き方が必要でした。
スケールアウト構成が自然ととれること。移行元のCosmos DBおよびAzure SQL Database Elasticpoolではシャーディングを行わずにスケールアウト構成が可能だったので、同様にシャーディングを行わずにスケールアウトできることが理想でした。
運用コストが低いこと。一般的にRDBMS系のDBaaSはエンジンのバージョンアップ作業が必要となるので、自動的にアップデートされるSQL Databaseからの移行では運用変更を考慮する必要がありました。

2024年12月から2025年1月時点にかけて以下を検討しました。

ACIDトランザクションのサポート、スケールアウト構成、フルマネージドサービスであり運用コストが低いという要件を満たせていたことに加え、

まだ既存システムの移行が始まったばかりですが、スケーラビリティは問題なく発揮されています。

分散データベースであるため、分散データベース固有の技術的な制約がある。なまじSQLが使えるばかりに、RDBMSと同じ感覚で設計しがちであり、性能問題が生じるという問題は表面化した。「SQLが使える分散データベース」であることには留意が必要。
単位当たりのコストが高いため、開発環境では最小限のサイズにするなど工夫をした。
エミュレーターで最新の機能がサポートされないことがあるので注意が必要。

チームからは以下の懸念が上がりました。

これらはもっともな懸念でしたが、システムの特性上、水平方向のスケーラビリティが求められる処理が大半であり、応答速度が重視されるケースはほとんどない。そのため、必要に応じて応答速度が重視される場合にのみ別のDBを採用する選択肢を残しつつ、Cloud Spannerを導入することとしました。

SQLが使えるが本質的には分散DBであり、適用個所は選ぶし、分散DB固有の性能特性や内部処理特性の理解は必須。特に純粋な応答性能が求められる部分には向かない。
テーブルのマイグレーションツールなどのエコシステムがどうしてもそのまま使えない部分があるので、初期導入にはハードルがある。
エミュレーターが常に最新の機能をサポートするとは限らない。
組み込みの統計情報の更新頻度が3日に1回なので注意が必要。
IAMのroleに癖があり、きめ細かなIAM設定をしたい場合はカスタムロールを作らないと不便（逆に言えばIAMで色々制御したくなるくらいにIAMとシームレスに統合されている）
SDK 細かい機能はドキュメント化されてない場合もあるので、GitHubでSDKのコードやそのコメントを見ると意外な発見もある。
Spanner backupを使う場合、バックアップ先もインスタンスを稼働させておく必要があるので課金計算時には注意。