Spanner活用サービスローンチ前の必須作業 Pre-splittingで急増トラフィックに備える
メディア統括本部 サービスリライアビリティグループ（SRG）の松田正也（@mm_matsuda816）です。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、CyberAgent Group SRE Advent Calendar 2025 16日目の記事です。
今回は、Spannerのローンチ直後のレイテンシ悪化を防ぐ「Pre-splitting」機能について紹介します。設計指針から設定方法までを詳しく解説し、トラフィック急増時でもスムーズにサービスを開始するためのポイントをまとめました。
ローンチ直後の Spanner が「詰まる」現象Pre-splitting（split points）の仕組みと設計どのくらい分割すべきかどこで分割するかSplit Points の作成と検証1. Split Points の作成Split 数を計測する運用上の注意点レイテンシへの影響監視と Expire（期限切れ）ローンチ前チェックリスト
ローンチ直後の Spanner が「詰まる」現象
Google Cloud Spanner は、リレーショナルデータベースの整合性と NoSQL の水平スケーラビリティを兼ね備えた強力なデータベースです。
しかし、大規模なサービスローンチやキャンペーン開始直後に、期待したパフォーマンスが出ずにレイテンシが悪化する「詰まり」が発生することがあります。
この問題の多くは、Spanner のデータ分散の仕組みであるSplitの挙動に起因します。
Spanner は通常、データ量（サイズ）や負荷（ロード）を検知して自動的にデータを分割し、複数のノードに分散させます。
これを自動 Splitと本記事では呼びますが、負荷を検知してから分割が完了するまでにはタイムラグがあります。
つまり、ローンチ直後のような「0 から 100 へ」一気にトラフィックが跳ね上がるシナリオでは、自動 Split が追いつかず、特定のノードにアクセスが集中してホットスポット化してしまうのです。
Pre-splitting（split points）の仕組みと設計
Pre-splitting とは、トラフィックが来る前にあらかじめ手動で分割点（split points）を作成し、データを複数のノードに分散させておく機能です。
これにより、ローンチ直後のスパイクアクセスを最初から複数のノードで受け止めることが可能になります。
どのくらい分割すべきか
公式ドキュメントでは、分割数の目安として1 ノードあたり 10 split pointsとされています。
例えば、本番環境で 5 ノード構成のインスタンスを使用する場合、5 × 10 = 50 個程度の split points を作成するのが推奨されます。
また、小規模なインスタンスであれば自動 Split でも十分に追随できる場合があるため、必ずしも必須ではありませんが、大規模なトラフィックが予想される場合は実施すべきです。
どこで分割するか
分割する場所（キーの範囲）は、データのキー設計に依存します。
- キーが均等に分散する場合（UUID やハッシュ値など）
キー空間全体を均等に分割します。
例えば、キーが 〜 の範囲を取るなら、, , ... のように等間隔で分割点を入れます。
- 特定の範囲がホットになる場合
特定のユーザー ID やカテゴリにアクセスが集中することがわかっている場合は、その範囲を重点的に分割します。
また、テーブルだけでなく、アクセスが集中するインデックスに対しても split points を作成することが推奨されています。
Split Points の作成と検証
実際に split points を作成し、正しく適用されたかを確認する手順を解説します。
Google Cloud CLI (gcloud) を使用する方法が一般的です。
1. Split Points の作成
コマンドを使用します。
分割点を記述したファイルを用意するか、コマンドラインで指定します。
以下はコマンドのイメージです。
ここで重要なのが （有効期限）です。
split points は恒久的なものではなく、トラフィックが安定したら Spanner の自動管理に戻すべきものです。
デフォルトでは 10 日、最大で 30 日まで設定可能です。
Split 数を計測する
作成した split points が正しく反映されたかを確認します。
この出力を で行数カウントしたり、 を付与して コマンドで集計したりすることで、現在の分割数を確認できます。
運用上の注意点
レイテンシへの影響
分割数を増やせば増やすほど良いわけではありません。
分割しすぎると、1 つのトランザクションがまたぐノード数（Transaction Participants）が増加し、Read/Write のレイテンシが恒久的に悪化する可能性があります。
また、クエリのリソース使用量（Compute/Query usage）も増える可能性があります。
監視と Expire（期限切れ）
ローンチ後は、Cloud Console の「Latency Profile」や「Key Visualizer」を監視してください。
もし過剰な分割によってパフォーマンスが悪化している（ホットスポットではなく、全体的なレイテンシ増が見られるなど）場合は、設定した有効期限を待たずに手動で Expire（無効化）させて、Spanner の自動管理に戻す判断も必要です。
有効期限が切れると、split points は表示されなくなり、トラフィックの状況に応じて自動的にマージ（結合）される可能性があります。
これは正常な挙動であり、Spanner が自律Splitに移行したことを意味します。
ローンチ前チェックリスト
最後に、Spanner を採用したサービスのローンチ前に確認すべき項目をまとめました。
- ノード数の確保
Pre-splitting は容量を増やす機能ではありません。
まず前提として、想定トラフィックを処理できる十分なノード数がプロビジョニングされていることを確認してください。
- Split Points の数は適切か
「ノード数 × 10」を目安に設定されているか確認してください。
- Pre-Splittingの実施タイミングは適切か
公式の推奨は「ローンチの 7 日前 〜 12 時間前」です。
早すぎるとローンチ前に期限切れになるリスクがあり、直前すぎると反映が間に合わない可能性があります。
- 制限事項の確認
Search Index や Vector Index は Pre-splitting の対象外です。
これらに依存するワークロードの場合は、別の負荷対策が必要になる場合があります。
- ローンチ中の監視
Key Visualizer でホットスポットが発生していないか、あるいは分割過多によるレイテンシ悪化がないか監視し、必要に応じて設定を解除（Expire）する準備をしておいてください。
Spanner の性能を最大限に引き出し、スムーズなローンチを迎えるために、Pre-splitting を有効に活用しましょう。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。