【実務・中級編】トランザクションパフォーマンスメトリクス – Cloud Spanner

Cloud Spannerの死角を突く：真のトランザクション・パフォーマンス・チューニング

「Spannerはスケールするから設計はどうでもいい」などという甘い幻想は、本番環境のスパイクで粉々に砕け散る。

確かにCloud Spannerは、分散トランザクションという現代の魔術を極限まで抽象化している。だが、その背後でPaxosが合意を取り、Lock Tableが激しく書き換わっているという事実を忘れてはならない。今日は、Cloud Monitoringのメトリクスを単なる「グラフ」としてではなく、システムの健康状態を示す「脈拍」として読み解く方法を伝授する。

—

1. レイテンシの正体を見極めろ：`Cloud Spanner/Transaction/Latency`

「レイテンシが高い」というアラートに対し、単にノード数を増やすのは素人のやり方だ。Spannerのレイテンシは大きく分けて「通信」「競合」「処理」の3つに分解できる。

監視の肝：P95/P99の乖離

平均値（Average）を見るのはやめろ。分散システムにおいて、平均値は最も無意味な数字だ。P99レイテンシが跳ねているなら、特定のホットスポットか、GC（ガベージコレクション）によるSTW（Stop-the-world）を疑え。

設計の鉄則:
読み取り専用トランザクション（ReadOnlyTransaction）を最大限活用せよ。強整合性を強要しない限り、Spannerは驚くほど軽く振る舞う。
`Staleness`（古いデータを許容する）を許容できる箇所では、積極的に `read_timestamp` を指定せよ。これにより、Paxosの合意形成をスキップできる。

—

2. ロック待機時間の真実：`Lock Wait Time`

`Lock Wait Time` が上昇している場合、それは「設計の敗北」を意味する。Spannerは行レベルロックを採用しているが、「書き込みの競合」はスループットを殺す最大の要因だ。

現場でよくあるアンチパターン

単一の「カウンタ」テーブルへの高頻度更新:

悲観ロックの奪い合いが起き、トランザクションが直列化される。

不適切なインデックス設計:

インデックスへの書き込みがロック競合のトリガーになる。

対策:
「カウンター」が必要なら、1行に集約するな。パーティションを分けて分散させるか、あるいはアプリケーション側で集約する設計に変更せよ。

—

3. 再試行（Retry）の波を制御せよ：`Transaction/Aborted Count`

Spannerは楽観的並行性制御（OCC）の側面も持つため、競合が発生すればトランザクションはアボートされる。「再試行が発生することは異常ではない」。だが、再試行率が10%を超えているなら、それは設計を見直すサインだ。

堅牢な再試行戦略

ライブラリのデフォルト再試行に頼るな。指数バックオフ（Exponential Backoff）を実装し、ジッター（Jitter）を必ず入れろ。

賢いエンジニアが実装する再試行のイメージ
from google.api_core import retry

競合によるアボートを検知して適切に再試行する設計
@retry.Retry(
predicate=retry.if_exception_type(exceptions.Aborted),
initial=0.1, # 100msから開始
multiplier=2.0, # 2倍ずつ増やす
maximum=10.0 # 最大10秒まで
)
def update_balance(transaction, user_id, amount):
# 読み取りと書き込みの範囲を最小化する
row = transaction.read_row(“Users”, user_id, [“balance”])
new_balance = row[“balance”] + amount
transaction.update(“Users”, …)

—

4. チーフアーキテクトからの「最後のアドバイス」

システムを設計する際、以下の3つの観点を常に自問自答せよ。

1. 「このクエリは本当に書き込みが必要か？」 → 必要ないならReadOnlyTransactionに逃げろ。
2. 「ロック範囲は最小か？」 → 巨大なトランザクションでテーブルを跨ぐな。
3. 「ホットスポットを作っていないか？」 → 主キー（Primary Key）に単調増加する値（タイムスタンプやシーケンシャルID）を使うのは、Spannerにおいては「自爆行為」だ。UUID v4などの分散キーを使え。

まとめ：メトリクスとの対話

Cloud Monitoringのグラフを眺める時、単に「数字が上がった・下がった」で終わらせるな。
「このスパイクは、先ほどのデプロイによるSQLの書き換えが原因ではないか？」「特定のノードにトラフィックが偏っていないか？」と仮説を立て、SQL実行計画（Query Plan）と突き合わせるんだ。

Spannerは強力な武器だが、使い手を選ぶ。この巨大な分散エンジンを飼いならし、真のパフォーマンスを引き出すのは、泥臭いメトリクスの分析を厭わない君たちエンジニアだ。

設計レビューで、「なぜこの主キーにしたのか？」と聞かれて言葉に詰まるな。すべての決定に論理的な裏付けを持て。それが、我々の流儀だ。