Cloud Spannerクエリ並列度制御の深層：巨大分散データベースを限界まで使い倒す技術
こんにちは。テクニカルリードの私だ。
今日のコードレビュー、あるいは設計レビューで、こんなクエリを見かけなかったか？
SELECT
account_id,
SUM(transaction_amount)
FROM large_ledger
GROUP BY account_id;
一見、何の問題もない美しい集計クエリだ。しかし、このテーブルのレコード数が数億〜数千億オーダに達し、かつリージョン間・マルチリージョン構成であった場合、君はこのクエリがSpannerの内部でどう処理され、どれだけのCPUリソースを貪り食うか想像できているか？
「Spannerだから勝手に全ノードで並列実行されて速いんでしょ？」と思っているなら、今すぐその認識を改めよう。
Cloud Spannerの真価を引き出すには、スプリット（Split）の概念、そしてクエリ並列度（Query Parallelism）の動的制御メカニズムを解剖し、システム全体のCPU負荷とスループットのトレードオフを完璧にコントロールしなければならない。
今日は、Spannerのコアアーキテクチャの心臓部である「クエリ並列度制御」について、実務で即座に使える極限の知見を授けよう。
—
1. コアアーキテクチャ：Spannerはなぜ並列クエリをどう制御しているのか
Spannerの分散ストレージ層は、データをスプリット（Split）と呼ばれる連続したキー範囲の断片に分割し、複数の Paxos グループ（つまり複数のノード）に分散配置している。
巨大なテーブルに対する `SELECT` や `GROUP BY` が発行されたとき、Spannerの分散クエリエンジン（Distributed Query Engine）は、次のようなアーキテクチャで動く。
1. ルート・コーディネーター（Root Coordinator）:
クライアントからのクエリを受け付け、実行計画（Execution Plan）を生成する。
2. 分散スキャン（Distributed Scan）:
クエリは複数のスプリットに対して並行してプッシュダウン（Push-down）され、各ストレージノードがローカルのストレージからデータをスキャンする。
3. 動的並列度調整（Dynamic Parallelism Control）:
ここが今日の肝だ。Spannerは、単に「すべてのスプリットを同時に全開で叩く」わけではない。システム全体のCPU使用率、現在のQPS（Query Per Second）、メモリプレッシャー、そしてクエリの優先度をリアルタイムに監視し、クエリごとの並列度（Parallelism Degree）を動的に絞る、あるいは拡大する。
なぜ「全開」でスキャンしてはいけないのか？
極端な並列度は、単一の重い分析クエリが OLTP（トランザクション処理）のレイテンシを破壊する「リソース泥棒（Resource Starvation）」を引き起こす。
Spannerのクエリ並列度制御は、OLAP的な巨大スキャンと、ミリ秒を争うOLTPトランザクションの共存を担保するための防衛機構なのだ。
—
2. 現場で起きる悲劇：並列度制御の限界とアンチパターン
設計レビューでよくある失敗を挙げよう。
アンチパターン：非効率なキー設計による「並列度のボトルネック」
Spannerの並列スキャンは、基本的に スプリットの数 に依存する。
もし、テーブルの主キー設計が不適切で、データが特定のスプリットに偏って（ホットスポット化して）いたり、あるいはデータ量が少なすぎてスプリットが十分に分割されていない場合、クエリエンジンは並列度を上げたくても上げられない。
— 【悪手例】タイムスタンプを主キーの先頭にした時系列テーブル
CREATE TABLE sensor_metrics (
recorded_at TIMESTAMP,
sensor_id STRING(64),
metric_value FLOAT64,
) PRIMARY KEY(recorded_at, sensor_id);
この設計では、直近のデータ（同じタイムスタンプ帯）が特定のスプリットに集中するため、並列スキャンが効か直列化し、レイテンシが跳ね上がる。さらに、並列度が上がらない代わりに1つのノードのCPUが100%に張り付くという最悪の挙動を示す。
—
3. 堅牢な設計パターン：並列度を支配し、スループットを最大化する
では、大規模集計やバッチ処理において、Spannerの並列度制御を味方につけ、システムを安全かつ爆速で動かすにはどう設計すべきか。
パターンA: 適切な主キー設計による自然なスプリット分散
スプリットは自動的に分割・統合されるが、初期段階から均등に並列スキャンが発生するよう、インターリーブ（Interleave）構造やシャードキー（Hash Prefix）を導入せよ。
— 【推奨例】テナントIDやハッシュプレフィックスを主キーの第一要素に据える
CREATE TABLE tenants (
tenant_id INT64,
— …
) PRIMARY KEY(tenant_id);
CREATE TABLE tenant_events (
tenant_id INT64,
event_id INT64,
payload STRING(MAX),
) PRIMARY KEY(tenant_id, event_id),
INTERLEAVE IN PARENT tenants ON DELETE CASCADE;
これにより、クエリが `tenant_id` ごとに綺麗に並列化され、Spannerのクエリエンジンは各ノードへ安全かつ高並列にスキャンを分散させることができる。
パターンB: クエリヒントと優先度の制御（Stale Readの活用）
大量データをスキャンするバッチやレポーティングクエリにおいて、リアルタイム性は不要な場合が多い。その場合は Stale Read（古くなったデータの読み取り） を強制し、並列度制御のプライオリティを調整せよ。
— 1時間前のスナップショットを指定し、トランザクションロックの競合とリソース消費を最小化する
SELECT
tenant_id,
COUNT(1)
FROM tenant_events@{FOR SYSTEM_TIME_AS_OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)}
GROUP BY tenant_id;
これによって、Spannerの動的並列度制御器は「このクエリはリソースを逼迫させてもよい（あるいは裏で静かに実行すべき低優先度タスクだ）」と判断し、他のトランザクションへの影響を完全に排除しながら、最大限の並列スキャンリソースを割り当ててくれる。
—
4. パフォーマンス上の注意点とオブザーバビリティ
動的並列度制御が裏でどのように働いているか、それを観測できなければエンジニア失格だ。Cloud SpannerのコンソールやCloud Monitoringをどう見るべきか、実践的なチェックポイントを記す。
1. CPU Utilization (High Priority / Low Priority)
- Spannerのモニタリングでは、CPU使用率が「High Priority（OLTP用）」と「Low Priority（バッチ・クエリ用）」に分かれている。
- 大規模クエリ実行時に Low Priority のCPUが綺麗に使い切られていれば、動的並列度制御が正常に機能し、OLTP領域（High Priority）を保護できている証拠だ。
2. Query Stats (Query Inspector / Information Schema)
- `SPANNER_SYS.QUERY_STATS_TOP_` などのシステムテーブルを叩き、各クエリが消費したCPU時間や、スキャンした行数、そして利用された並列度を確認しろ。
- 想定よりもスキャン行数に対して実行時間が長い場合、並列度が頭打ちになっていないか（スプリット数が不足していないか）を疑うこと。
— 直近で最もCPUを消費したクエリの統計を抽出する例
SELECT
interval_end,
text,
cpu_seconds,
rows_scanned
FROM
SPANNER_SYS.QUERY_STATS_TOP_1H
ORDER BY
cpu_seconds DESC
LIMIT 10;
—
5. チーフアーキテクトからの総括
Cloud Spannerのクエリ並列度制御は、いわば「自律駆動する優秀な交通整理システム」だ。しかし、道路（＝主キー設計、スプリット配置）がガタガタであれば、どんなに優秀な交通整理も機能せず、大渋滞（レイテンシ悪化・CPU枯渇）を引き起こす。
君たちがコードレビューや設計レビューで行うべきことは明確だ。
- 「このテーブルのデータ量とアクセスパターンに対し、スプリットが健全に分散する主キーになっているか？」
- 「重い集計クエリに Stale Read や適切なプライオリティの考慮が入っているか？」
- 「モニタリングで Low Priority CPUが適切に活用されているか？」
この3点をロジカルに詰めること。それができれば、どんなにスケールするシステムであっても、Spannerは君たちの期待を裏切らず、圧倒的なパフォーマンスで応えてくれるはずだ。
さあ、エディタに戻り、今日の設計をもう一度見直そうか。
コメント