Cloud Spannerの計算資源：ノードとProcessing Units（PU）の深淵を読み解く
Cloud Spannerを単なる「SQLが使える分散DB」と定義しているうちは、その真価には辿り着けない。真のアーキテクトが向き合うべきは、論理的なテーブル構造の裏側で脈動する、計算資源の物理的割り当て――すなわち「ノード」と「Processing Units (PU)」の真実である。
今日は、ドキュメントの表面的な説明を排し、Spannerの計算資源管理の深淵にメスを入れる。
—
1. ノードとPU：抽象化された計算資源の正体
Spannerにおける「ノード」や「PU」は、単なる仮想マシンのスペックではない。これは、Colossus（分散ファイルシステム）上に配置されたデータフラグメント（スプリット）を処理するCPUおよびメモリ資源の「割り当て権」である。
- 1ノード = 1000 PUs
- 1 PU = 1/1000 ノードの計算能力
かつては1ノード単位でのスケーリングが強制されていたが、PUの導入により、我々は100単位という粒度でリソースを調整できるようになった。しかし、ここで勘違いしてはならない。PUを増やしたからといって、即座にクエリが高速化するわけではない。
PUが供給するのは「CPUサイクル」と「メモリバッファ」であり、I/Oのボトルネックを物理的に解消するものではないという点だ。
2. 内部メカニズム：なぜ「計算資源」が動的に再配置されるのか
Spannerの真髄は、動的なリバランシングにある。データは「スプリット」という単位で分割され、ノード間で移動する。ここでPUが果たす役割は、特定のノードに過大な負荷が集中した際、その負荷を「どの程度の計算資源で処理するか」の閾値を制御することだ。
熟練のアーキテクトが意識すべきは以下のサイクルである。
1. CPU使用率のスパイク: クエリがComplex Joinsを実行し、特定のノードでCPUが張り付く。
2. スプリットの分裂と移動: 負荷が高いスプリットが自動的に分割され、他のノードへと移動する。
3. PUの再配分: ここで、移動先ノードが十分なPUを保持していない場合、処理遅延（レイテンシ）が発生する。
つまり、PUの設定は「現在の負荷」に対する備えではなく、「将来的にスプリットが再配置された後のキャパシティ」を見越した設計でなければならない。
3. メモリ最適化とPU：カーネルレベルの視点
Spannerのノード内では、RocksDBをベースとしたストレージエンジンが稼働している。ここでPUが不足すると、何が起こるか？
- キャッシュヒット率の低下: PUが少ない＝割り当てられたメモリ領域が狭い。結果として、頻繁にアクセスされるインデックスやデータブロックがメモリに乗り切らず、ColossusへのリモートI/Oが発生する。
- コンテキストスイッチの増大: CPUリソースの枯渇は、クエリ実行エンジン内のタスクスケジューリングを悪化させ、最終的にはgRPCのキューイング遅延として現れる。
以下は、Spannerの負荷状況を監視する際、エンジニアが真っ先に見るべき観点である。
— システムテーブルを用いた負荷分析の指針
— CPU使用率とスプリットの相関を追跡する
SELECT
t.table_name,
s.cpu_usage_minutes,
s.read_request_count
FROM
SPANNER_SYS.TABLE_STATS_TOP_MINUTE AS t
JOIN
SPANNER_SYS.NODE_STATS AS s
ON
— ノードIDをキーに、PU割り当てと処理負荷の乖離を可視化する
t.interval_end = s.interval_end
ORDER BY
s.cpu_usage_minutes DESC;
— ここで見るべきは、”CPU使用率の平準化”ではなく、
— “ホットスポットがどの物理ノードに偏っているか”である。
4. アーキテクトへの提言：PUスケーリングの極意
「負荷が上がったからPUを増やす」というのは、ジュニアレベルの思考だ。真に熟練したエンジニアは、以下の原則を守る。
1. 書き込みと読み取りの分離: 読み取り専用レプリカを適切に構成し、プライマリノードのPUを「書き込みと強い整合性が必要なクエリ」だけに集中させる。
2. スプリット境界の最適化: PUを増やしても解決しない場合、それはスプリットの境界設定（キー設計）が悪い。特定のキー範囲に負荷が集中しているなら、PUをどれだけ積んでも、そのノードのCPUは飽和し続ける。
3. オートスケーリングの限界を知る: GCPのオートスケーラーは便利だが、急激なスパイクには追従できない。重要なイベントやバッチ処理が予測できるなら、事前に手動でPUを確保する（オーバープロビジョニング）のが、伝説的なエンジニアの流儀である。
結論
Cloud SpannerにおけるノードとPUは、単なる「数字」ではない。それは、データベースの心臓部を流れる血液の量であり、制御対象である。
システムが複雑になればなるほど、インフラの抽象化は進む。だが、その抽象化の向こう側にある「CPUの熱」と「メモリの配置」を想像できる人間だけが、真にスケーラブルなシステムを構築できる。
次は、クエリ実行計画（Query Plan）の深淵、特に`Distributed Union`と`Apply Join`がPU消費に与える影響について紐解くことにしよう。現場からは以上だ。
コメント