【Spannerの深層】夜間バッチで突発的レイテンシ悪化を防ぐ！Cloud Monitoring監視・アラート設計の極意
テックリードの私だ。設計レビューやコードレビューで「動けばいい」という甘いアーキテクチャを持ち込む者が後を絶たないが、Cloud Spannerというモンスターを扱う現場において、それは致命傷になり得る。
Spannerは、無限のスケールと厳密な外部整合性を約束してくれる最高のデータベースだ。しかし、その強大なパワーを適切に制御できなければ、ある日突然のホットスポットやレイテンシの跳ね上がりに足元をすくわれる。
今回は、実務の現場で「絶対に網羅すべきCloud Monitoringの監視指標と、真に意味のあるアラート設計」について、私の知見をすべて授けよう。教科書通りのメトリクス監視で満足しているなら、今すぐその思考をアップデートしてほしい。
—
1. なぜ「なんとなくCPU監視」ではシステムが死ぬのか？
多くのエンジニアは、CPU使用率が80%を超えたらアラート、というRDB時代の古い習慣を引きずっている。Spannerにおいて、これは全く意味がない。
Spannerのノードは複数かつ分散配置されている。全体（平均）のCPU使用率が30%であっても、特定の1ノード、あるいは特定のスプリット（Split）に負荷が集中している場合、そのスプリットを抱えるノードだけがCPU枯渇を起こし、全体のレイテンシが跳ね上がる。
つまり、Spannerのモニタリングにおける鉄則は、「マクロな平均値ではなく、ミクロな偏り（Hotspotting）を検知すること」だ。
—
2. 実務で直視すべき「4大重要メトリクス」と監視の急所
Cloud Monitoringにおいて、最低限トラッキングし、アラートの閾値を設けるべき4つのコアメトリクスを解説する。
① CPU使用率 (CPU Utilization)
- Metric: `serviceruntime.googleapis.com/api/server_cost` または `cloudspanner.googleapis.com/node/cpu/utilization`
- 実務の急所:
- 高優先度（High Priority）のCPU使用率を監視せよ。バックグラウンド処理（コンパクションやレプリケーション）を含むトータルのCPU使用率ではなく、クエリ処理やトランザクションに直結する高優先度CPUが70%を超えたらレッドゾーンだ。
- 「CPU使用率の分散（Standard Deviation）」を見るのがプロの技だ。各ノード間のCPU使用率のばらつきが大きい場合、それはスプリット設計の失敗、あるいは単調増加キー（UUID v1やタイムスタンプ）によるホットスポットの明確な兆候である。
② レイテンシ (Latency – 99th Percentile)
- Metric: `cloudspanner.googleapis.com/api/request_latencies`
- 実務の急所:
- 平均値（p50）を見る無能な監視は今すぐやめろ。ユーザー体験とシステム全体の整合性を守るためには、p99（99パーセンタイル）、あるいは高負荷時にはp99.9を監視対象にしろ。
- 読み取り（Read）と書き込み（Commit）のレイテンシは分けてアラートを設定すること。Commitレイテンシが悪化している場合、Paxosグループのリーダーノードの負荷、またはネットワーク遅延、トランザクションの競合（Lock Contention）が疑われる。
③ トランザクション数とアボート率 (Transaction Count & Abort Rate)
- Metric: `cloudspanner.googleapis.com/api/commit_request_count`, `cloudspanner.googleapis.com/api/aborted_tx_count`
- 実務の急所:
- トランザクションの「量」そのものよりも、アボート率（Abort Rate / 競合によるロールバック比率）の急増を監視しろ。
- 楽観的ロック制御を採用するSpannerでは、同一行への同時書き込みが集中するとトランザクションがアボートする。アボート率が全体の数%を超えた場合、アプリケーション側のリトライロジックが破綻し、雪崩式にレイテンシが悪化する悪夢（Thundering Herd Problem）を引き起こす。
④ スプリット負荷とストレージ使用量 (Split Load & Storage)
- Metric: `cloudspanner.googleapis.com/instance/storage/utilization`, スプリットごとのCPU使用状況
- 実務の急所:
- Spannerはデータ量やアクセス量に応じて自動的にデータを「スプリット」し、別ノードに負荷を分散させる。しかし、スプリットの分割が追いつかないほどの急激なトラフィック増（Traffic Spike）が発生すると、スプリットが機能する前にノードが息絶える。
- 特にデータ量ベースではなく、アクセス集中によるスプリット移動（Split Migration）の発生頻度や、単一スプリットへの負荷集中メトリクスを注視せよ。
—
3. 堅牢なアラート設計：Slack/PagerDutyを鳴らすべき条件
夜中に無駄なアラートでオンコールエンジニアを起こすな。しかし、本当の障害は見逃すな。私が現場で導入している「実用的なアラート設計パターン」を共有する。
パターンA：【緊急・P1】直ちにオンコールを叩き起こす条件
- 条件: 高優先度CPU使用率が 85%以上が5分間継続 ＋ p99レイテンシが 許容値（例: 200ms）の3倍を突破
- 理由: 単なる一時的なスパイクではなく、実害（レイテンシ悪化）を伴うリソース枯渇。人間による介入（手動スケーリング、あるいは悪質なクエリのKILL）が必要な状態だ。
パターンB：【警告・P2】翌朝の出社時に調査する条件
- 条件: アボート率が全コミット数の 5%を超過が15分継続
- 理由: 直ちにシステムが停止することはないが、アプリケーションのDBアクセスパターンに欠陥があるか、特定の熱いリソースが存在する証拠。放置すると連鎖障害につながる。
—
4. パフォーマンス上の注意点と「スプリット」を制する者
Cloud Spannerのパフォーマンスを語る上で避けて通れないのが「プライマリキーの設計」とそれに紐づくスプリットの挙動だ。
よくあるアンチパターンとして、`id` に生成順のタイムスタンプや、連番、UUID v1を採用するケースがある。これらはすべての新規書き込みが「最後のスプリット（一番右側の範囲）」に集中するため、自動スプリットが追いつかず、単一ノードのCPUが100%に張り付く。
対策としてのモニタリング活用
もし「ある特定のスプリットだけCPUが高い」というアラートを検知した場合、Cloud Monitoringのグラフから以下の初動をとれ：
1. スキーマのプライマリキーを見直す: ハッシュ化プレフィックス（Shard Key分散）が導入されているか確認。
2. ダッシュボードでQuery Insightsを叩く: どのクエリがそのスプリットのCPUを消耗させているかを特定し、即座にインデックスを追加するかクエリを書き換える。
—
チーフアーキテクトからの総括
Cloud Spannerは「魔法のデータベース」ではない。インフラストラクチャの挙動を正しく理解し、適切なメトリクスを監視してこそ、その真価を発揮する。
「平均値を見るな。偏りを見よ。」
「CPUを見るな。高優先度CPUとアボート率を見よ。」
この原則をあなたのチームの共通認識とし、明日の設計レビューからこの基準を適用してほしい。堅牢な監視なしに、プロダクション環境へのSpannerデプロイなどあり得ないのだから。
コメント