【実務・中級編】ノードと処理ユニット – Cloud Spanner

Cloud Spannerの心臓部：ノードと処理ユニット（PU）を支配する者が、システムのスケーラビリティを制す

Cloud Spannerを単なる「リレーショナルデータベース」だと考えているなら、それは大きな誤解だ。Spannerは、Googleがグローバル規模のサービスを維持するために鍛え上げた「分散コンピューティングエンジン」である。

多くのエンジニアが「ノード数を増やせば速くなる」と安易にスケールアウトを繰り返す。だが、真のアーキテクトは違う。彼らは、「処理ユニット（Processing Units: PU）」という最小単位をいかに正しく解釈し、ワークロードに合わせてリソースを切り出せるかに心血を注ぐ。

今日は、Spannerの計算リソースの本質と、実戦で後悔しないための設計哲学について深掘りする。

—

1. 概念の再定義：ノードとPUの解像度

Spannerにおいて、1ノードは正確には1,000 PU（Processing Units）と定義されている。かつてはノード単位での増減が基本だったが、現在は100 PU単位という極めて粒度の細かいスケールが可能になった。

100 PU = 0.1ノード: 小規模な開発環境や、読み取り専用の軽量なワークロード用。
1,000 PU = 1 ノード: 標準的な本番環境のベースライン。

ここで重要なのは、「ノード数はリソースの物理的上限を決めるものではなく、スループットの『枠』である」という認識だ。PUを増やすことは、単にCPUを増やすことではない。Spanner内部の「スプリット（Split）」を処理するワーカーのキャパシティを広げ、トランザクションの競合を許容するためのコンピュートパワーを拡張することに他ならない。

—

2. 「なぜPUを増やすのか」を見極める

パフォーマンスが落ちたからといって、無思考にPUを増やすのは悪手だ。Spannerにおいて、パフォーマンスボトルネックは以下の2つに大別される。

A. コンピュート制約（PU不足）

兆候: CPU使用率が常に高止まりしている。
対策: シンプルにPUを増やす。これで解決する。

B. データ制約（ホットスポット）

兆候: CPUは余っているのに、特定のトランザクションが遅延する。
真実: これはPU不足ではない。「キー設計の不備」である。単調増加する値や、特定のレコードにアクセスが集中する設計では、どんなにPUを増やしてもSpannerの分散処理能力を活かしきれない。

> Architect’s Insight:
> 負荷試験でCPU使用率が65%を超えたら、PUを増やすタイミングではない。「どのキーがホットになっているか」をインスペクション（Cloud Monitoring）で突き止めるべきだ。物理リソースで逃げる設計は、いずれコストと運用の限界を迎える。

—

3. 実務で活かす「オートスケーリング」の設計パターン

手動でのPU調整は、運用のオーバーヘッドになる。推奨されるのは、自動スケーラー（Autoscaler）の導入だ。

ただし、デフォルト設定をそのまま使うな。以下の指針を守れ。

1. CPU閾値は「60%」を目安にする: スパイクが発生した際、急激なスケールアウトが間に合わないリスクを排除するため、余裕を持たせる。
2. スケールダウンの「慣性」を持たせる: 負荷が下がった瞬間にPUを減らす設定にすると、瞬間的な再負荷でCPUが張り付き、レイテンシが悪化する。スケールダウンには少なくとも1時間の冷却期間を設けるのが「通」のやり方だ。

gcloudコマンドによるPU調整の例
本番環境で「エイッ！」と増やすのではなく、定義ファイルで管理せよ
gcloud spanner instances update [INSTANCE_ID] \
–processing-units=2000 # 2ノード相当へスケールアップ

—

4. パフォーマンス上の注意点：隠れた「壁」

最後に、ベテランでも見落としがちな落とし穴を共有しておく。

スプリットの移動コスト: PUを大幅に変更すると、Spanner内部でデータの再配置（スプリットの移動）が発生する。この際、一時的にパフォーマンスが揺らぐ可能性がある。急激な変更は避け、インクリメンタルな変更を心がけること。
マルチリージョン構成でのPU: マルチリージョンインスタンスでは、各リージョンにPUが割り当てられる。書き込みレイテンシを下げたいからといってPUを増やしても、物理的な距離（光速の壁）を超えることはできない。書き込みの重さは、リージョンの配置設計で解決するしかない。

—

結び：エンジニアへの提言

Cloud SpannerにおけるPUの管理は、単なるサーバー増設ではない。「データの配置」と「処理能力」の均衡を保つ調律である。

「リソースに余裕を持たせる」のは当たり前だ。その上で、「なぜそのPU数が必要なのか」を数字で説明できるか。スプリットの状況を理解し、ホットスポットを回避するキー設計を行えているか。

これらを自問自答し続けることこそが、Spannerを使いこなす唯一の近道だ。技術に振り回されるな。技術を支配し、システムを堅牢なものへと昇華させよ。

健闘を祈る。