Cloud Spanner

解決する課題

従来のリレーショナルDBは、書き込みを増やすと単一ノード（プライマリ）の上限に突き当たります。一方でNoSQLは水平スケールできても、強整合やSQL・トランザクションを犠牲にしがちです。Cloud Spanner はこの二者択一を解消し、SQL・スキーマ・強整合トランザクションを保ったまま、書き込みごと水平スケールすることを目的としています。

• 単一ノードの上限を超えて書き込みスループットを水平スケールしたい
• リージョンをまたいでも**強整合（外部整合性）**を保つグローバルDBが欲しい
• 計画停止のない高可用性（実質的に無停止のメンテナンス・自動フェイルオーバー）が必要
• スキーマ・SQL・ACIDトランザクションを捨てずに大規模化したい

AWS で近い位置づけなのは Amazon Aurora ですが、Aurora は基本的に単一ライター構成です。複数リージョンへの分散書き込みや無限に近い水平スケールが要件になると、Spanner 独自の領域になります。

主要概念と用語

• インスタンス: 計算リソースとストレージを束ねる最上位の単位。ノードまたは**プロセッシングユニット（PU）**で容量を指定する（おおよそ1ノードが1,000PUに相当）
• インスタンス構成（configuration）: データを配置する地理的トポロジ。1リージョンに閉じるリージョナルと、複数リージョンに分散するマルチリージョンがある
• スプリット（split）: テーブルを主キー範囲で分割した内部的な単位。負荷に応じて自動で分割・再配置され、これが水平スケールの実体
• TrueTime: GPSと原子時計に基づき、時刻の不確実性を区間つきで返すGoogle独自の時刻API。外部整合性の基盤
• 外部整合性（external consistency）: 分散環境でも、コミットの順序が実時間の順序と矛盾しないという最も強い整合性レベル
• インターリーブ（interleaving）: 親テーブルの行と子テーブルの行を物理的に近接配置し、結合や親子操作を高速化するスキーマ設計
• セカンダリインデックス: 主キー以外での検索を支えるインデックス。インデックス自体も分散配置される

仕様・制限・クォータ

• 容量モデル: ノードまたはPU単位でスケール。小規模用途はPUで細かく指定でき、必要に応じて増減できる
• ストレージ: 自動でスプリットに分割・シャーディングされ、容量に応じて拡張される。プロビジョニング不要
• SQL方言: GoogleSQL 方言に加え、PostgreSQL 互換インターフェースも選択できる
• 可用性: マルチリージョン構成では非常に高い可用性目標が設定されている（具体的なSLA値は構成により異なるため公式の最新値を確認）
• クォータ: ノード数・インスタンス数などはプロジェクト／リージョン単位の上限があり、引き上げ申請が可能
• 設計上の注意: 単調増加する主キー（タイムスタンプや連番）はホットスポットの原因になりやすく、回避が推奨される

具体的な料金・上限・SLAの数値は変動するため、本番設計時は公式ドキュメントの最新値を参照してください。

内部の仕組み

Spanner はデータをテーブルの主キー範囲でスプリットに分割し、各スプリットを複数のサーバへ分散します。各スプリットはPaxosによる合意で複数のレプリカに同期され、どれかのレプリカが落ちても処理を継続できます。書き込みはレプリカ群でのリーダー選出とコミットを経て確定し、読み取りは整合性を保ったまま近いレプリカから返せます。

この分散構成で強整合を実現する鍵が TrueTime です。TrueTime は時刻を「確実にこの区間内」という不確実性つきで返すため、Spanner はコミットの瞬間に区間の終わりまで待つ（commit-wait）ことで、グローバルにトランザクションの順序が実時間と矛盾しない外部整合性を保証します。負荷が偏ればスプリットを自動的に分割・移動するため、運用者が手動でシャーディングする必要はありません。

設計パターン / ベストプラクティス

• 主キーを分散させる: 単調増加する値を主キー先頭に置かない。ハッシュ化したプレフィックスや UUID 風の値で書き込みを散らす
• インターリーブで親子を近接配置: 強く関連する親子テーブル（注文と注文明細など）はインターリーブし、結合と一括操作を高速化する
• インデックスは目的を絞る: セカンダリインデックスも分散コストがかかるため、検索要件に必要なものだけ作る
• 適切な構成を選ぶ: 1リージョン内で十分ならリージョナル、地理冗長や低遅延の広域読み取りが要るならマルチリージョンを選ぶ
• 読み取りの整合性レベルを使い分ける: 厳密さが不要な参照には、わずかに過去の時刻で読むステイル読み取りを使うと負荷とレイテンシを抑えられる

運用・監視

• Cloud Monitoring / Cloud Logging で CPU 使用率・スループット・レイテンシ・ストレージ使用量を可視化する
• CPU 使用率を主要指標としてノード／PU をスケールする。高負荷が続くとレイテンシ悪化やスループット低下につながる
• Key Visualizer で主キー空間のアクセス分布をヒートマップ表示し、ホットスポットを特定する
• Query Insights などでスロークエリや実行計画を分析し、インデックスやスキーマを改善する
• バックアップ機能や特定時点へのリカバリ機能を活用し、復旧要件に合わせて保護する

コスト

課金の基本軸は「コンピュート（ノードまたはPU）＋ストレージ＋ネットワーク（リージョン間転送など）」です。マルチリージョン構成は配置するリージョン分のコンピュートが必要になり、リージョナルより高くなります。小さく始める場合はPU単位で細かく確保し、トラフィックに応じてスケールするのがコスト効率の基本です。

セキュリティ

• 保存データは既定で暗号化され、**Cloud KMS（CMEK）**による顧客管理鍵も利用できる
• アクセス制御は IAM で行い、インスタンス・データベース単位など細かい粒度で権限を付与できる
• VPC Service Controls でデータ持ち出しの境界を設け、限定公開接続（Private Google Access など）で経路を閉じる
• 監査は Cloud Audit Logs で記録し、誰がいつアクセスしたかを追跡する

Well-Architected の観点

• 信頼性（reliability）: Paxos によるレプリケーションと自動フェイルオーバー、計画停止のないメンテナンスにより、高可用性をマネージドで提供する。マルチリージョン構成でリージョン障害にも備えられる
• パフォーマンス効率（performance）: スプリットの自動分割・再配置で書き込みまで水平スケールし、TrueTime により強整合を保ったまま広域に分散できる。主キー設計とインデックス設計が性能の決め手になる

試験で問われるポイント

関連サービス・比較

GCP 内では、高性能 PostgreSQL の AlloyDB や手軽なマネージドRDB の Cloud SQL と棲み分けます。「もっと速い PostgreSQL」なら AlloyDB、「手軽な RDB」なら Cloud SQL、「水平な書き込みスケールとグローバル強整合」なら Spanner です。AWS で最も近いのは Aurora で、整合性と分散スケールの考え方を対比すると理解しやすくなります。

ハンズオン / CLI例

# Spanner インスタンスを作成（リージョナル構成、容量はPU指定）
gcloud spanner instances create my-spanner \
  --config=regional-asia-northeast1 \
  --description="demo instance" \
  --processing-units=1000

# データベースを作成し、スキーマ（DDL）を適用
gcloud spanner databases create my-db \
  --instance=my-spanner \
  --ddl="CREATE TABLE Users (UserId STRING(36) NOT NULL, Name STRING(MAX)) PRIMARY KEY (UserId)"

# データを1件挿入
gcloud spanner rows insert \
  --instance=my-spanner \
  --database=my-db \
  --table=Users \
  --data=UserId=abc-123,Name=Alice

# SQL で読み取り
gcloud spanner databases execute-sql my-db \
  --instance=my-spanner \
  --sql="SELECT UserId, Name FROM Users"