B2B2C型Saasの新規開発に際するCloud Spannerの導入・活用事例

参考になった

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。

無料登録してアーキテクチャを見る

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

アソビュー株式会社 / h-nagatomo

メンバー / バックエンドエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2024/08/26投稿日2024/08/26

利用機能

ツールの利用規模

ツールの利用開始時期

事業形態

データベース機能、パフォーマンス監視機能

10名以下

2022年8月

B to B

B to C

利用機能	データベース機能、パフォーマンス監視機能
ツールの利用規模	10名以下
ツールの利用開始時期	2022年8月
事業形態	B to B B to C

アーキテクチャ

会員限定コンテンツ無料登録してアーキテクチャを見る

アーキテクチャの意図・工夫

フロントエンド

Next.jsによるSPAをCloud Front×S3で配信

バックエンド

アプリケーションはJavaとSpring Bootで構成されています。

Spring CloudによるApplication Gatewayが認証・セッション管理、API群へのルーティング、またその集約を行う
DDDの思想を取り入れて設計・実装されたAPI群
API群が発行するEventをKinesis Data Streamを介してSubscribeして動くWorker群
同じくEvent駆動型のlambda上で動くメール配信サービス
DynamoDB, Redis, Aurora(MySQL)などの既存のデータベース群
そして、ゲスト側、パートナーそれぞれからのアクセスに対する可用性分離の観点と業務関心領域を加味して5つに分割されたCloud Spannerのデータベース群

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

導入背景

ツール導入前の課題

現状DynamoDB + Auroraを利用しているチケット購入・アクティビティ予約サイトにおいて、事業の成長によって今後も踏まえて下記の課題が表面化しつつありました。

恒常的な注文数・トランザクションの増加
スパイクに対するスケールアウト
トランザクションの複雑化によるダブルブッキングへの懸念
特定の施設への負荷集中による影響が全体へ波及する懸念 ...etc

どのような状態を目指していたか

これらの課題に対して、チケット入稿・販売を提供するB2B2C型のSaasの新規開発に際しては下記の状態を目指していました。

無停止でのスケール(Read/Write双方)
部分障害(ホットスポット)は許容した上で特定施設への負荷が全体へ波及しづらい構成
注文トランザクションが増加していってもダブルブッキングなどが発生しない状態

比較検討したサービス

Amazon Aurora
Amazon DynamoDB
CockroachDB
YugabyteDB
TiDB
Vitess

比較した軸

スケーラビリティ
運用の容易性

選定理由

インターリーブなどを活用したパフォーマンスと可用性の両立が可能な点。
また、多数のサービスでの導入実績や信頼性の高いGoogle Cloudのフルマネージドサービスであること。

導入の成果

導入して間もない為、現状規模ではスケールや負荷についてSpannerのおかげで助かっていると実感しやすい場面は少ないです。
しかしながら、デフォルトとなっているSERIALIZABLE相当の強整合性によってダブルブッキングが生じず、
トランザクションが絡むことによるデータ不整合について比較的ナーバスにならずに開発を進められています。

また、管理コンソールの各種モニタリングが充実しており、CPUの負荷推移、ロック時間・ロック対象の監視、パフォーマンス懸念のあるクエリ検知などが容易で、特にローンチに向けた負荷テストでは大変重宝しました。

導入時の苦労・悩み

一般的なRDBMSと異なる分散型とRDBMS双方の要素を併せ持ったSpanner独自の特徴、注意点が多く、その点に対してチームで適応していくまでに時間を要しており、現在でも適応を模索している最中です。

具体的には下記のような点です。

ホットスポットを意識した主キー設計、ルール決め
- auto incrementするような主キーがアンチパターンとなる
- チームで主キー構成のルール設定をし、UUIDv4を導入
一般的なRDBMSとは異なるインデックス思想への理解と最適化
- インデックスのインターリーブ、STORING機能などの馴染みの無い機能
- インデックスとミューテーション上限(1トランザクションあたりの操作レコード数上限)の関係を意識
- 外部キーについて一般的なRDBMSよりパフォーマンス面での寄与に対して期待できないこと
インターリーブの活用や、読み取り・書き込みの双方を意識した上での最適なテーブル設計
- インターリーブを活用しなければパフォーマンスが出ない問題や、インデックスをとりあえず貼るだけでは解消できない課題が多々あること
- n対nのような関係のモデルに対しては非正規化的アプローチも最初から考えたほうが良いなど
トランザクション分離レベル=SERIALIZABLE相当であることへの諸注意
- アプリケーション上でのトランザクション境界の定め方を模索
- 強整合性によって生じる想定外のロックの監視と対策

導入に向けた社内への説明

上長・チームへの説明

上長に向けて

現状の課題については、すでにCTOとも認識を共有していました。その上で、課題解決に向けた取り組みとして、運用の容易さや信頼性を考慮し、競合サービスとの比較検討を行い、最終的に本サービスの導入を決定しました。

チームに向けて

社内実績のないデータベースの導入となるので、開発メンバー全体の理解度を上げることが重要であり、 Spannerの仕組みや特徴に対する勉強会の複数回実施、週次の定例で設計・開発をする上での現状課題を細かいものでも逐次共有・解決を図りました。

活用方法

よく使う機能

パフォーマンス監視機能
- 指定期間のCPU利用率, トランザクションレイテンシは負荷試験で重宝
- ロック分析情報, Query Insightsを週次などでチームで確認し問題のありそうなクエリ・機能の洗い出しに活用
クエリーコンソール
- 分かりやすくビジュアライズされた実行計画が出力できる点が実用性が高く、参照クエリの追加・修正を行う際はこの機能で問題がないか逐次確認

ツールの良い点

一般的なSQLのSyntaxをおおむねサポートしているため、RDBMS経験者のクエリに対する学習コストが低め
監視機能が充実し使いやすい管理コンソール
充実したサポート
高頻度のアップデートによる恩恵を受けやすい

ツールの課題点

総じてノウハウが他のRDBMSより出回っていない点、各ケースにおけるベストプラクティスの蓄積が少ない点が挙げられます。

JDBC系のツールと組み合わせて利用した際にいくつかハマりどころがあったこと
実行計画がこちらの意図とズレる場合が多く、一般的なRDBMSとは異なるクエリ戦略・ノウハウの蓄積が必要であること

ツールを検討されている方へ

検討時には、従来型のRDBやNoSQL、他の分散DBと比較することが重要です。特に、分散DB同士でも機能面や特性に差異があるため、システムの中心となるDBの選定は、サービスの生産性に大きな影響を与えます。ピーク時の負荷が高いサービスにおいては、分散DBの特徴を深く理解し、実際のサービスレベルでの検証をしっかりと行うことをおすすめします。