【入門編】スプリット分割アルゴリズム – Cloud Spanner

こんにちは！Cloud Spannerの世界へようこそ。
クラウドの底知れぬパワーを実感できるこのデータベース、なんだか難しそうに聞こえるかもしれませんね。でも大丈夫。今日は、Spannerの心臓部とも言える「スプリット分割アルゴリズム」について、専門用語をできるだけ使わずに、一緒に楽しく紐解いていきましょう。

ここをクリアすれば、Cloud Spannerが「なぜ世界中で愛され、ビクともしないのか」の基本はバッチリマスターできますよ。それでは、優しい先輩と一緒に、その仕組みを覗いてみましょう！

—

1. 想像してみてほしい：「超人気ラーメン店」の行列問題

あなたが大人気のラーメン店の店主だと想像してください。
このお店、最初はカウンターが5席だけの小さなお店でした。最初は順調だったのですが、SNSで大バズり！連日大行列ができるようになってしまいました。

問題発生： 5席のカウンターに、何百人ものお客さんが押し寄せる。
結果： 注文を聞くスタッフがパニックになり、ラーメンが出てくるまでに何時間もかかる。「もう帰る！」とお客さんが怒って帰ってしまう（＝システムの遅延やダウン）。

データベースの世界でも、これと全く同じことが起きます。これを「ホットスポット（特定の場所に負荷が集中すること）」と呼びます。例えば、秒単位で何万件もの「いいね！」が押されるシステムを作ったとき、データベースの特定の場所だけにアクセスが集中して、パンクしてしまうのです。

普通のデータベースなら、ここでサーバーの引っ越しをしたり、手動で設定を変えたりと大騒ぎになります。しかし、Cloud Spannerはこの問題を完全に自動で、しかもお店営業中（無停止）に解決してくれます。その秘密が「スプリット分割アルゴリズム」です。

—

2. Spannerの「スプリット分割アルゴリズム」とは？

Cloud Spannerは、データをただの巨大な箱にドカンと入れるのではなく、「スプリット（Split）」という小さめのダンボール箱に綺麗に小分けして保管しています。

ラーメン屋の例えに戻りましょう。

行列がすごすぎて1店舗では回らなくなったとき、Spanner（優秀な経営者）はこう判断します。
「よし、今すぐ隣のテナントを借りて、全く同じクオリティの『2号店』をパパッと作ろう！そして、並んでいるお客さんを半分ずつ誘導しよう！」

これがスプリット分割の正体です。

1. 監視： Spannerは常に「どのダンボール箱（スプリット）にデータがたくさん詰まっているか」「どちらの箱にアクセスが集中しているか（熱くなっているか）」を24時間体制で見張っています。
2. 判断： ある箱のデータ量が大きくなりすぎたり、アクセスが急増して「熱い！」と検知すると、自動的に「よし、ここを真っ二つに分けよう！」と決めます。
3. 分裂と引越し： 箱を綺麗に2つに割り、片方を別のサーバー（コンピューター）にシュッと引っ越させます。

これで、1つの場所に集中していた負荷が、自動的に2つのサーバーに分散されるわけです。もちろん、この一連の作業中も、システムを止める必要はありません。お客さんは並んだまま、勝手にお隣の空いているカウンターに案内されるようなものです。

—

3. なぜこれが「世界最高峰」と言われるのか？

初心者の方なら、「分割するって言っても、裏側で人間が設定してるんでしょ？」と思われるかもしれません。

いいえ、ここがCloud Spannerの真骨頂です。
この分割と負荷分散のすべてが、完全に「自動（オートマチック）」で行われます。

夜中に突然セールが始まってアクセスが100倍になっても、Spannerは慌てず騒がず、勝手にスプリットをどんどん増やして（分裂させて）受け皿を広げます。
セールが終わってアクセスが減ったら、今度は「おや、そんなに広くなくていいな」と、隣り合うスプリットをそっと合体させて整理整頓までしてくれます。

私たちはただ「こういうデータを保存したい！」とSpannerにお願いするだけで、データがどこにどう配置され、どうやって負荷が分散されているかを気にする必要が一切ないのです。これが、世界中のエンジニアがSpannerを信頼してやまない理由です。

—

4. 実務で活きる！Spannerを上手に使うためのワンポイント

スプリット分割の仕組みが分かると、Cloud Spannerを設計するときの「コツ」が見えてきます。

Spannerは非常に賢いですが、ほんの少しだけ「苦手なこと」があります。それは、「すべての人が、まったく同じ名前のボタンを同時に連打するような状況」です。

例えば、データの先頭にすべて「`2023-11-06`」という同じ日付をつけて保存してしまうと、Spannerは「おっと、すべてのデータがこの『2023-11-06』という1つのダンボール箱に集中しているぞ！」と勘違いしてしまい、うまくスプリットを分けられなくなることがあります（これをプライマリキーのアンチパターンと呼んだりします）。

そのため、実務でデータベースを設計するときは、以下のように少し工夫をしてあげます。

— 悪い例：日付がすべて同じだと、1つのスプリットに負荷が集中しがち
— CREATE TABLE UserActions (
— ActionDate STRING(10),
— UserId STRING(64),
— — …
— ) PRIMARY KEY (ActionDate, UserId);

— 良い例：先頭にランダムな文字列やIDを混ぜることで、スプリットが自然に分散する
CREATE TABLE UserActions (
ShardId INT64, — 0〜9などのランダムな数字を先頭にする
ActionDate STRING(10),
UserId STRING(64),
— …
) PRIMARY KEY (ShardId, ActionDate, UserId);

(※コードコメント：先頭に少しバラつきを持たせることで、Spannerが「あ、いろんな場所の箱にデータを入れればいいんだな！」と気づきやすくなり、スプリット分割が最高にスムーズに行われます)

このように、Spannerの「スプリットを分けたくなる気持ち（性質）」をちょっとだけ理解してあげると、システムは何億人規模のアクセスが来てもビクともしない、最強のインフラに変貌します。

—

おわりに

いかがでしたでしょうか？
Cloud Spannerのスプリット分割アルゴリズムは、一見すると難解な分散システムの技術ですが、要するに「大人気になったラーメン店が、お客さんをスムーズにさばくために、自動で店舗を増やして行列を分散させる仕組み」です。

この基本さえ押さえておけば、Spannerのドキュメントを読むときも、「あ、今スプリットの話をしているな」とスッと頭に入ってくるはずです。

ここをクリアしたあなたなら、もうCloud Spannerのコアな概念はバッチリマスターできていますよ！自信を持って、次のステップへ進んでいきましょう。最高のエンジニアライフを応援しています！