Cloud Spannerの「99.999%」を疑え：HAの深淵と、エンジニアが背負うべき責務
「Cloud Spannerを使えば、可用性は自動的に99.999%になる」――そう信じているなら、今すぐその認識を改めたほうがいい。
確かにSpannerは、Googleが誇る分散データベースの金字塔だ。しかし、SLAの数字は「Googleが責任を持つインフラの稼働率」であって、「君たちが構築するシステムの可用性」ではない。
今回は、Spannerという最強の武器を手にしながら、足元をすくわれないための「HA（高可用性）の解剖学」を伝授する。
—
1. 「Paxos」という名の心臓部：自動フェイルオーバーの正体
SpannerのHAを支える根幹は、Paxosアルゴリズムを用いたコンセンサス・プロトコルだ。これを単なる「自動フェイルオーバー」と呼ぶのは、エンジニアとしてあまりに解像度が低い。
- 同期レプリケーションの原則: Spannerは書き込みに対して「過半数（Majority）」の合意を必須とする。つまり、ノードが1台落ちようが、データは一切失われないし、書き込みも止まらない。これが「真のHA」の正体だ。
- フェイルオーバーのレイテンシ: リーダーノードが消失した際、新しいリーダーが選出される（Leader Election）。この間、数秒の「微細な停止」が発生する。設計において重要なのは、この「数秒」をアプリケーション側でどうハンドリングするかだ。
実務上の教訓：リトライ戦略の最適化
アプリケーション層で、何も考えずにリトライを投げていないか？ Spannerがリーダー再選出中に出す `Aborted` エラーに対して、指数バックオフなしでリトライを繰り返せば、それは「自分たちで自分たちのシステムをDDoSする」行為に他ならない。
// 良いリトライパターンの例：バックオフを考慮する
// Spannerのトランザクションは「Aborted」を受け取ったら、
// 状態をリセットして最初からやり直すのが鉄則
err := client.ReadWriteTransaction(ctx, func(ctx context.Context, txn spanner.ReadWriteTransaction) error {
// データの読み込み、書き込み処理
return nil
})
if err != nil {
// 必要なバックオフ戦略（指数バックオフ）をここで実装する
// 単純な即時リトライは禁物だ
}
—
2. リージョン構成の選択：君のシステムの「痛み」はどこにある？
「マルチリージョン構成なら最強」という短絡的な思考は危険だ。コストと引き換えに得られるのは、リージョンレベルの災害に対する耐性だけではない。「レイテンシ」という代償を支払うことになる。
- 単一リージョン（Single Region）: 極めて高い可用性と低レイテンシ。通常のシステムならこれで十分だ。
- マルチリージョン（Multi-Region）: 物理的に離れたリージョン間でコンセンサスを取る。可用性は極限まで高まるが、書き込みの物理的な距離によるRTT（往復遅延）は物理法則として無視できない。
設計時の問い: 君のサービスは、特定のリージョンが消滅した時に「数秒〜数十秒の遅延」よりも「数分間の停止」の方が致命的か？ もしYESなら、迷わずマルチリージョンを選べ。そうでなければ、単一リージョン構成でリージョン内冗長化を信じるのが、最も経済的かつ高性能な設計だ。
—
3. アプリケーション設計における「やってはいけない」
HAを最大化するために、データベースのレイヤー以外でやってはいけないことがある。
① スキーマ設計の怠慢（ホットスポットの回避）
SpannerはHAを担保するためにデータを分割（Split）する。もし君が連番のIDやタイムスタンプを主キーの先頭に置いていたら、特定のノードにアクセスが集中し、そのノードがHA以前の問題としてパンクする。
- 対策: UUID v4やビット反転させた整数を主キーに使い、負荷を全ノードに均等に分散させろ。これがSpannerのHAを活かすための前提条件だ。
② クライアントライブラリのインスタンス生成
Spannerのクライアントは、重いリソースだ。リクエストのたびにインスタンスを生成するような愚行は避けろ。コネクションプールは維持し、ライブラリのベストプラクティス（`spanner.Client`の使い回し）を厳守すること。
—
4. 最後に：アーキテクトとしての心構え
Cloud Spannerは「何もしなくても壊れない」魔法の箱ではない。
- 監視すべきはスループットだけではない: リーダーの配置（Leader Placement）、CPU使用率のスパイク、そしてトランザクションの失敗率（Aborted rate）。これらをオブザーバビリティの指標として叩き込め。
- 障害訓練: 本番環境で「リーダーが死ぬ」状況を想定したカオスエンジニアリングを、少なくとも一度は実施しろ。それができない設計は、稼働しているだけで「事故待ち」の状態だ。
Spannerを使いこなすということは、分散システムの複雑性を理解し、その上で「制御可能な失敗」を設計に組み込むことだ。
君たちが設計するのは、ただのデータベースではない。止まらないビジネスそのものだ。その重みを理解して、コードを書いてほしい。
以上だ。設計レビューに戻ろう。質問があればいつでも聞く。
コメント