Topology Service 向け Cloud Spanner リージョン設定

Cells アーキテクチャの Topology Service には、強力な整合性保証を持つ高可用性データベースが必要です。Cloud Spanner はリージョナル構成とマルチリージョナル構成の両方を提供します。 私たちの実装では、パフォーマンス、災害復旧機能、コストのバランスが取れた最適な構成を決定する必要があります。

主な検討事項:

• クライアント側のレイテンシーの例: HTTP Router -> Topology Service
• サーバー側のレイテンシー: Paxos レプリケーションなどの Spanner 内部通信
• 災害復旧のニーズとリージョン障害に対する耐性
• 各構成のコストへの影響
• Google が提供する SLA

検討中のマルチリージョナル構成:

• nam3: 米国東部のリード/ライトレプリカと、ヨーロッパとアジアのオプションレプリカ
• nam11: 複数の北米リージョンにまたがるリード/ライトレプリカ
• nam-eur-asia3: 北米全体のリード/ライト、ヨーロッパとアジアのリードオンリー

クライアント側レイテンシーテスト

HTTP Router がグローバルからリクエストを送信できる本番環境を模倣するため、現在 us-east1/us-central1 にホストされている Topology Service と各 GCP リージョン間のレイテンシーをテストしました。 テストは GCP VM 上で k6 負荷テストツールを使用して実施し、リージョン間のレイテンシーパターンを示しています。

テスト VM は以下のリージョンに作成されました。

• asia-east1-a (n1-standard-4)
• europe-west1-b (n1-standard-4)
• us-east1 (n1-standard-4)
• us-central1 (n1-standard-4)

k6 テストスクリプトは、30 秒間 1 つの仮想ユーザーで Topology Service の /v1/classify エンドポイントへ POST リクエストを行いました。

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 1, // Number of virtual users
  duration: '30s', // Test duration
};

export default function() {
  const url = 'https://topology-rest.runway.gitlab.net/v1/classify';
  const payload = JSON.stringify({
    type: "CELL_ID",
    value: "2"
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
    },
  };

  const response = http.post(url, payload, params);

  // Check if the request was successful
  check(response, {
    'status is 200': (r) => r.status === 200,
  });
}

結果

ベースライン構成（us-east1/us-central1 デプロイ）:

マルチリージョナル構成（us-east1/us-central1/europe-west1/asia-east1 デプロイ）:

分析

レイテンシーテストにより、マルチリージョナルデプロイを使用した際の国際リージョンでの大幅な改善が明らかになりました。

• ヨーロッパのレイテンシー改善: 83% 削減（105.64ms → 17.64ms）
• アジアのレイテンシー改善: 94% 削減（184.43ms → 11.50ms）
• 米国東海岸: 分散ルーティングにより若干増加（11.63ms → 14.36ms）

これらの結果は、提案している nam11 構成が北米のユーザーには適しているものの、将来の EU またはアジアベースのデプロイに向けて nam-eur-asia3 に移行すると大幅なパフォーマンス向上が見込まれることを示しています。

サーバー側レイテンシー

Spanner はレプリケーションに Paxos を使用します。マルチリージョナルでは、書き込みの成功は両方のリージョンで完了したことを意味します。 書き込みを高速化するには、両リージョン間のレイテンシーを低く保つ必要があります。 以下の Performance Dashboard は、nam3 に対応するリージョンである us-east1 と us-east4 間のレイテンシーが最小であることを示しています。

ソース

決定事項

以下の変更を加えた nam3 をベースのインスタンス構成として採用します。

• プライマリとして us-east1（us-east4 の代わりに）: 私たちのプライマリリージョンは us-east1 です。
• 追加の読み取り専用レプリカ: HTTP Router はグローバルに分散されているため、分類のレイテンシーを改善するために Topology Service も同様にグローバルに分散させる必要があります。そのため追加の読み取り専用レプリカが必要です。

データの暗号化については、Customer-Managed Encryption Keys（CMEK）を実装するのではなく、自動的に有効になる Google のデフォルト暗号化（保存時）を使用します。

結果

Spanner のトポロジーを変更すると、インスタンスの移動がトリガーされます。 Terraform を使用するとインスタンスが再作成されてデータが失われる可能性がありますが、 レガシー Cell を Cells クラスターに追加する直前に読み取りレプリカを追加すれば、データの損失は発生しません。

利点

1. 必要になるまでのコスト削減: リード/ライトのトポロジーを変更せずに小さく始めて拡張できます。
2. 書き込みのサーバー側レイテンシーが最小化されます。
3. クライアント側レイテンシーのためにヨーロッパやアジアなど他のコンテンツへの拡張が可能です。
4. CMEK と比較して暗号化キーのメンテナンスオーバーヘッドが削減されます。

検討した代替案

代替案 1: nam-eur-asia3

コンテキスト: us-east1 と us-central1 でのリード/ライトと、すぐに使える読み取り専用リージョン。

決定: サーバー側レイテンシーに最適ではなく、リージョンの拡張性が低く、初期コストが高いため採用しません。

代替案 2: nam11

コンテキスト: us-east1 と us-central1 でのリード/ライトと、単一のオプション読み取り専用リージョン。

決定: サーバー側レイテンシーに最適ではなく、リージョンの拡張性が低いため採用しません。

コスト分析

この見積もりは以下に基づいています。

• コンピュート容量 5 ノード
• SSD ストレージ 1 TB
• 1 時間あたりの書き込み/変更データ 10 GB
• Enterprise Plus エディション

ページのソースコードを見る - ページの編集 - please contribute.