このリファレンス アーキテクチャは、Google Distributed Cloud（GDC）エアギャップで高可用性の顧客管理型 MySQL 8.4 データベースをデプロイして運用するための概念フレームワークを提供します。これにより、エンタープライズのお客様と早期アクセスのお客様は、堅牢なマルチゾーン仮想マシン（VM）設定を使用して、重要なデータベース ワークロードを確実に維持できます。
GDC エアギャップではクロスゾーン Kubernetes ストレッチ クラスタがサポートされていないため、このアーキテクチャは、3 つのアベイラビリティ ゾーンにデプロイされた専用 VM に厳密に依存して、継続的なオペレーションを確保し、データ損失なしでゾーン全体の障害に耐えます。
特長と機能
- マルチゾーンの復元性: 3 つの異なるアベイラビリティ ゾーンにデプロイされた復元性の高い 3 ノード構成により、単一のインフラストラクチャ ゾーンの障害から保護します。
- 自動化された高可用性とコンセンサス: Paxos ベースのコンセンサス クラスタリングに グループ レプリケーションを使用し、スプリットブレイン シナリオなしで自動障害検出、ノード合意、グローバル データ同期を実現します。
- インテリジェントなトラフィック ルーティング: コロケーションされた MySQL Router インスタンスが接続ルーティングを管理します。ルーターは、書き込みオペレーション（ポート 6446 など）をアクティブなプライマリ ノードに厳密に転送し、読み取りオペレーション（ポート 6447 など）を同期されたレプリカ間で負荷分散します。
- グローバル ロードバランシング: 組み込みの GDC グローバル L4 ロードバランサと統合して、クライアント アプリケーションに単一の安定した仮想 IP（VIP）を提供し、基盤となるノード トポロジを抽象化します。
アーキテクチャの原則
- クォーラム ベースのコンセンサス: 厳密なデータ整合性を優先します。グループ レプリケーションは、過半数の合意を必要とする Paxos ベースのモデルを適用し、ネットワーク パーティション分割中のデータ損失やスプリットブレインのリスクを排除します。
- 関心の分離: データベース エンジンとコンセンサス レイヤ（グループ レプリケーション）をクライアント トラフィック ルーティング レイヤ（MySQL Router）から切り離し、MySQL Shell を使用してクラスタのライフサイクル管理を簡素化します。
- インフラストラクチャの最適化: エアギャップ環境向けに特別に設計されており、堅牢な VM を使用して現在の Kubernetes ネットワーキングの制限を回避します。
アーキテクチャ
コンセプトとテクノロジー
このセクションでは、マルチゾーン アーキテクチャ内の機能コンポーネントとその具体的な役割について詳しく説明します。
インフラストラクチャとプラットフォーム
- 仮想マシン（VM）: 3 つの専用 Compute インスタンス。それぞれが別のアベイラビリティ ゾーンにデプロイされ、障害ドメインの境界を形成します。
- GDC グローバル L4 ロードバランサ: プラットフォーム管理のネットワーキング構成。安定した内部 VIP を公開し、MySQL Router のヘルスチェックを自動的に評価して、インバウンド トラフィックをリダイレクトします。
サービスとロジック
- MySQL 8.4: コア リレーショナル データベース エンジン。
- グループ レプリケーション / InnoDB クラスタ: マルチマスター レプリケーションを担当し、Paxos を使用してノード クォーラムを検証する組み込みのクラスタリング フレームワーク。
- MySQL Shell: InnoDB クラスタ インスタンスの構成、プロビジョニング、管理に特化した統合コマンドライン インターフェース。
- MySQL Router: 各 VM のトラフィック ルーターとして機能します。クラスタ メタデータをリッスンしてトラフィックを転送するように動的に構成されます。書き込みにはアクティブ/バックアップ、読み取りにはラウンドロビンを使用します。
データフローとインターフェース
- アプリケーションは、データベース リクエストを GDC グローバル L4 ロードバランサ VIPに送信します。
- ロードバランサは、VM のいずれかの正常な MySQL Router インスタンスへの接続をプロキシします。
- リクエストされたポートに基づいて、MySQL Router はトラフィックを動的に転送します。 ポート 6446 は書き込み用のアクティブ ノードを厳密にターゲットとし、 ポート 6447 はクラスタ全体で読み取りを循環させます。
考慮事項
- パフォーマンスと整合性のトレードオフ: グループ レプリケーションはコンセンサスを適用するため、トランザクションにはクラスタピアからの確認応答が必要です。 パフォーマンスは、GDC 環境内のゾーン間ネットワーク レイテンシに直接相関します。
- リソース管理: データベース VM に MySQL Router を直接デプロイすると、ハードウェアの使用率が最適化されますが、接続プールのオーバーヘッドによってコア MySQL プロセスが不足しないように、リソースを慎重に調整する必要があります。
設計上の意思決定
- Kubernetes よりも仮想マシン: GDC エアギャップは、複数の物理ゾーンにまたがる Kubernetes クラスタをサポートしていません。別々のゾーンに専用 VM をデプロイすることが、真のマルチゾーン高可用性を実現し、ゾーン全体の障害を回避する唯一の方法であるため、VM ベースのアプローチが厳密に選択されました。
- InnoDB クラスタとオーケストレーターと ProxySQL: ProxySQL とオーケストレーターを組み合わせた従来のプライマリ/セカンダリ アーキテクチャが、実現可能な代替案として評価されました。ただし、組み込みの InnoDB クラスタ（グループ レプリケーション + MySQL Router + MySQL Shell）が選択されました。これにより、サードパーティのルーティング オーバーレイへの依存が解消され、コンセンサスを MySQL 内に直接保持することで、フェイルオーバーに関する運用上の複雑さが大幅に簡素化されます。
- プラットフォーム組み込みのグローバル ロードバランシング: 組み込みの GDC グローバル L4 ロードバランサを活用することで、VIP が GDC コントロール プレーンによって制御され、エントリ ポイントの復元力が維持され、クロスゾーン トラフィック配信が簡素化されます。
前提条件と制限事項
前提条件
- インフラストラクチャの可用性: お客様は、専用の適切なサイズの VM とグローバル ロードバランサを 3 つのアベイラビリティ ゾーンに均等にプロビジョニングするための十分なプロジェクト割り当てを持っています。
- 安全なネットワーキング: クラスタ内グループ レプリケーションの同期と MySQL Router トラフィックを許可するために、キーベースのアクセスと適切な ProjectNetworkPolicies（PNP）が確立されています。
制限事項
- Kubernetes はサポートされていません: コンテナ化された Kubernetes ベースのソリューションを厳密に求めているお客様は、プラットフォームでストレッチ クラスタが完全にサポートされるまで、マルチゾーン HA を実現できません。
- 手動アップグレードが必要: マネージド サービスとは異なり、このソリューションでは、ルーチン OS レベルのパッチ適用とデータベースのマイナー バージョン アップグレードの責任がすべてお客様にあります。
- ネットワーク レイテンシの影響を受けやすい: レプリケーションには、高品質で安定したネットワークが必要です。エアギャップ ゾーン間のネットワーク ジッターまたはレイテンシの急増は、MySQL クラスタ全体の書き込みオペレーションを比例的に遅延させます。
その他の教材
- ソリューション リファレンス実装（SRI）: GDC エアギャップの高可用性マルチゾーン MySQL 8 のソリューション リファレンス実装