【テクニカル・上級編】ノードスケーリング – Cloud Spanner

Cloud Spannerのノードスケーリング：その「深淵」と「真実」

Cloud Spannerを単なる「マネージドな分散RDB」と捉えているなら、それはあまりにも表層的な理解だ。Spannerの真価は、Paxosアルゴリズムによる強整合性と、それを支えるストレージ・コンピューティング分離アーキテクチャの極致にある。

特に「ノードスケーリング」という機能。多くのエンジニアはこれを「負荷に応じてポチポチと計算リソースを増やすボタン」程度に考えている。だが、内部で何が起きているのか。今回は、このスケーリングの裏側にある、コンピュートとステートの分離、そしてパフォーマンスの再配置という「深淵」について解説する。

—

1. スケーリングの正体は「タブレットの再配置」である

Spannerのデータは「スプリット」と呼ばれる単位で物理的に分割され、各ノード（サーバー）に分散して配置されている。ノードを追加するということは、単にCPUが8個から16個に増えるのではない。

「スプリットの再分配（Rebalancing）」が走る。

あなたがノード数を増やした瞬間、Spannerのコントロールプレーンは、現在のノード群と新しいノード群の間で、どのスプリットがどこに移動すべきかの計算を開始する。これはオンラインで行われる。なぜなら、各スプリットはPaxosグループとして独立しており、データ移動中も読み書きを止めないからだ。

ここで重要なのは、「スケーリングの速度は、データの物理的な移動量に依存する」という事実だ。ノードを追加した瞬間にCPUパワーが倍になるのではない。「移動が完了し、新しいノードがPaxosのリーダーシップを獲得した時点」で初めて、そのスプリットの処理能力がフルに発揮される。

2. メモリ最適化と「ウォームアップ」の教訓

熟練のアーキテクトなら理解しているはずだ。ノードを増やした直後、パフォーマンスが期待通りに出ないことがある。理由はシンプルだ。データキャッシュ（Block Cache）が空だからだ。

Spannerの各ノードは、頻繁にアクセスされるデータをメモリ上のキャッシュに載せている。スケーリングによって新しいノードにスプリットが移動すると、そのノードのキャッシュには何も入っていない。

コールドスタート問題: 新しいノードに割り当てられたスプリットは、最初はディスクからのI/Oを発生させる。
キャッシングの適応: ワークロードが実行されるにつれ、徐々にワーキングセットがメモリにロードされ、キャッシュヒット率が最適化される。

もし君がオートスケーラーを実装するなら、急激なスパイクが来る「10分前」にスケールアウトを完了させる必要がある。これこそが、Spanner運用における「レイテンシの真実」だ。

3. なぜ「ノード数」の指定が重要なのか

近年のSpannerには「プロセッシングユニット（PU）」という概念が導入された。これにより、ノード単位ではなく、より細かい粒度での調整が可能になったが、物理的な本質は変わらない。

ノード数を操作するということは、以下のようなスケーリングの制約を設計に取り込むことを意味する。

— Spannerのシステムテーブルから、現時点のタブレットの配置を推定するクエリの概念図
SELECT
table_name,
count() as split_count
FROM
SPANNER_SYS.TABLE_STATS_1HOUR
GROUP BY
table_name;
— スプリット数が多すぎれば、スケーリング時の再配置コスト（ネットワーク負荷）が増大する。
— 逆に少なすぎれば、特定ノードに「ホットスポット」が集中するリスクが高まる。

ノード数を増やすことは、ホットスポットの解消には有効だが、「スプリットの数」という設計上の制約が不適切であれば、いくらノードを増やしても解決しないという点に注意せよ。スケーリングは魔法ではない。アーキテクチャの不備を補うものではないのだ。

4. チーフアーキテクトからの提言

実務において、オートスケーラーを過信してはならない。

1. CPU使用率の閾値に踊らされるな: Spannerは90%以上のCPU使用率でも安定して動作するように設計されている。60%程度でスケールアウトをトリガーするのは、無駄なコストを生むだけだ。
2. Paxosリーダーの偏りを注視せよ: 特定のノードにリーダーが集中している場合、そのノードだけがCPUを激しく消費する。この場合、ノードを増やすよりも、キーの設計（主キーの単調増加などによる競合）を見直すのが先決だ。
3. スケーリングの履歴を記録せよ: スケーリング発生時のレイテンシ変動をモニタリングし、アプリケーションのコネクションプールが再確立される際のオーバーヘッドを計測せよ。

結論：限界を突破するために

Cloud Spannerのスケーリング機能は、分散データベースにおける「計算と状態の分離」という夢を実現した一つの到達点だ。しかし、それを操る我々エンジニアには、ブラックボックスの中にある「Paxosの合意形成」や「キャッシュのコールドスタート」といった物理的な制約を理解する知性が求められる。

ツールは、その本質を理解した者にだけ、真のパフォーマンスを差し出す。
明日の朝、君がオートスケーラーの閾値を設定する際、ぜひこの「再配置」と「メモリの温もり」を思い出してほしい。

それこそが、伝説への第一歩だ。