【入門編】ホットスポット検出 – Cloud Spanner

こんにちは！Cloud Spannerの深遠なる世界へようこそ。チーフアーキテクトの私です。

今回は、Cloud Spannerの心臓部とも言える「ホットスポット検出」と「データの分散」について、徹底的に噛み砕いて解説していきますね。

「Cloud Spannerって、自動でデータを分散してくれて無限にスケールするんでしょ？」
はい、その通りです。でも、「どうやってその分散が行われているのか」「一箇所にアクセスが集中したとき、裏側で何が起きているのか」をイメージできますか？

ここをクリアすれば、あなたはもうCloud Spannerの挙動を手に取るように理解できる、ワンランク上のエンジニアになれますよ。さあ、一緒に扉を開けていきましょう！

—

1. 巨大な本棚のたとえ：Cloud Spannerのデータ管理

まずは、Cloud Spannerがデータをどう持っているのかをイメージしてみましょう。

Cloud Spannerは、データを「キー（目印）」の順番にきれいに並べて保管します。これを例えるなら、世界一巨大な辞書や本棚のようなものです。

行（レコード）は、本棚に並んだ1冊1冊の本です。
プライマリキー（主キー）は、本の背表紙に書かれた「管理番号」や「タイトル」だと考えてください。

Cloud Spannerはこの巨大な本棚を、「スプリット」と呼ばれるいくつかの区画（ダンボール箱のイメージです）に切り分けて、世界中（正確にはGoogleのデータセンター内）のたくさんのコンピュータ（ノード）に分担して預けています。

—

2. 「ホットスポット」ってなに？（日常のトラブルに例えて）

さて、ここからが本題です。
もし、あなたが大人気アイドルグループのチケット販売サイトを作ったとしましょう。

販売がスタートした瞬間、世界中のファンが一斉にアクセスし、「一番若いメンバーの会員番号（例: `A-000001`）」のデータを読み書きしようと殺到しました。

現実の世界でどうなるでしょうか？
そのメンバーのチケットを発券する窓口の前にだけ、数万人の大行列ができてしまいますよね。他の窓口はガラガラなのに、1つの窓口だけがパンク状態です。

この状態を、コンピュータの世界では「ホットスポット（熱い場所）」と呼びます。

特定のキー範囲（特定のダンボール箱）にばかりアクセスが集中し、その箱を担当しているコンピュータのCPUやメモリが悲鳴を上げてしまう現象のことです。せっかく無限にスケールする仕組みを持っていても、これでは性能が出せなくなってしまいます。

—

3. スプリットの自動分割：Spannerの凄腕マネージャー

「じゃあ、大行列ができたらどうするの？システムがフリーズしちゃうの？」

いいえ、そこがCloud Spannerの真骨頂です。
Spannerの裏側には、「超優秀な現場マネージャー」が常駐しています。このマネージャーは、各ダンボール箱（スプリット）へのアクセスの熱量を常に監視しています。

マネージャーはある日、こう気づきます。
「おいおい、ダンボール箱『A-000000 〜 A-099999』のエリアだけ、やけに熱気（トラフィック）がすごいぞ！ CPU使用率が跳ね上がっている！」

すると、マネージャーは瞬時に次の行動を起こします。

1. 検出する（ホットスポット検出）
「どこにアクセスが集中しているか」をリアルタイムで特定します。
2. 箱を真っ二つに割る（スプリットの分割）
大混雑しているダンボール箱を、真ん中でパッカーンと2つに分けます（例: `A-000000 〜 A-049999` と `A-050000 〜 A-099999`）。
3. 別のコンピュータへお引越し（負荷分散）
分けた片方の箱を、今ヒマを持て余している別のコンピュータへそっと引っ越しさせます。

これで、行列が2つの窓口に分散され、再びシステム全体がスムーズに動き始めます。すごい仕組みだと思いませんか？

—

4. 実務で活かす知見：ホットスポットを防ぐデザインパターン

ここまで自動でやってくれるCloud Spannerですが、私たちエンジニア側でも、この「マネージャーの仕事」を少しだけ楽にしてあげる工夫（設計）ができます。

もっとも有名なのが、「キーの工夫（アンチパターンを避ける）」です。

❌ やってはいけない例（シーケンシャルなキー）

`1, 2, 3, 4, 5…` と連番でデータを追加する
`2023-10-24 12:00:01`, `2023-10-24 12:00:02` のように「現在時刻」をそのままキーの先頭にする

これだと、常に「一番新しい（一番数字が大きい）データ」の場所にしかアクセスや書き込みが集中しないため、マネージャーがいくら箱を割っても、新しい箱の取り合いになってしまいます。

⭕ 推奨される例（ハッシュ化やランダム化）

ユーザーIDの先頭に、ランダムなプレフィックス（文字や数字）を付与する
UUID（ランダムな文字列）をキーにする

— 良い例：ユーザーIDの前にランダムなハッシュを付与することで、
— データが本棚全体に綺麗に散らばり、ホットスポットを防ぎます。
CREATE TABLE Users (
ShardedUserId STRING(64), — 例: “3_user12345”, “7_user12346” のように散らす
UserId STRING(36),
UserName STRING(100),
) PRIMARY KEY(ShardedUserId);

このように、データをあらかじめ本棚全体に「パラパラと混ぜておく」ことで、アクセスが自然と分散され、Cloud Spannerのポテンシャルを100%引き出すことができるのです。

—

おわりに

今回は、Cloud Spannerの「ホットスポット検出」と「スプリット分割」の裏側を、日常のたとえを交えて解説しました。

アクセスが集中すると、Spannerは自動で熱いエリア（ホットスポット）を検知する。
混雑したダンボール箱（スプリット）を分割し、別のコンピュータへ荷物を逃がして負荷を散らす。
ただし、設計段階でキーを工夫（ランダム化）してあげると、この自動分散がよりスムーズに働く。

ここをクリアできれば、あなたはもうCloud Spannerの分散アーキテクチャの基本をマスターしたも同然です！
現場で設計する際は、ぜひ「このキーは本棚の1箇所に集中しないか？」という視点を忘れないようにしてくださいね。

それでは、次のステップでもっとディープなSpannerの世界を楽しみましょう！