このリファレンス アーキテクチャは、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 つの専用コンピューティング インスタンス。それぞれが個別の可用性ゾーンにデプロイされ、障害発生ドメインの境界を形成します。
- 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 環境内のゾーン間ネットワーク レイテンシに直接関連しています。
- リソース管理: MySQL Router をデータベース VM に直接デプロイすると、ハードウェアの使用率が最適化されますが、接続プーリングのオーバーヘッドによってコア MySQL プロセスが枯渇しないように、リソースを慎重に調整する必要があります。
設計上の意思決定
- Kubernetes 上の仮想マシン: GDC エアギャップは、複数の物理ゾーンにまたがる Kubernetes クラスタをサポートしていません。VM ベースのアプローチが厳密に選択されたのは、専用の VM を別々のゾーンにデプロイすることが、真のマルチゾーン高可用性を実現し、ゾーン全体の障害を回避するための唯一の実行可能な方法であるためです。
- InnoDB Cluster と Orchestrator および ProxySQL の比較: ProxySQL と Orchestrator を組み合わせた従来のプライマリ / セカンダリ アーキテクチャは、実現可能な代替手段として評価されました。しかし、代わりに組み込みの InnoDB クラスタ（Group Replication + MySQL Router + MySQL Shell）が選択されました。これは、サードパーティのルーティング オーバーレイへの依存を排除し、MySQL 内で直接コンセンサスを維持することで、フェイルオーバーに関する運用の複雑さを大幅に簡素化するためです。
- プラットフォーム組み込みのグローバル ロード バランシング: 組み込みの GDC グローバル L4 ロードバランサを活用することで、VIP が GDC コントロール プレーンによって制御され、エントリ ポイントの復元力が維持され、ゾーン間のトラフィック配信が簡素化されます。
前提条件と制限事項
前提条件
- インフラストラクチャの可用性: お客様は、3 つのアベイラビリティ ゾーンに均等に分散された、適切なサイズの専用 VM とグローバル ロードバランサをプロビジョニングするのに十分なプロジェクト割り当てを確保しています。
- 安全なネットワーキング: クラスタ内のグループ レプリケーションの同期と MySQL Router トラフィックを許可するために、鍵ベースのアクセスと適切な ProjectNetworkPolicies（PNP）が確立されます。
制限事項
- Kubernetes がサポートされていない: コンテナ化された Kubernetes ベースのソリューションを厳密に求めているお客様は、プラットフォームでストレッチ クラスタが完全にサポートされるまで、マルチゾーン HA を実現できません。
- 手動アップグレードが必要: マネージド サービスとは異なり、このソリューションでは、OS レベルの定期的なパッチ適用とデータベースのマイナー バージョンのアップグレードの責任がすべてお客様にあります。
- ネットワーク レイテンシの感度: レプリケーションには、高品質で安定したネットワークが必要です。エアギャップ ゾーン間のネットワーク ジッターやレイテンシの急増により、MySQL クラスタ全体の書き込みオペレーションが比例して遅延します。
その他の教材
- ソリューション リファレンス実装（SRI）: GDC エアギャップにおける高可用性マルチゾーン MySQL 8 のソリューション リファレンス実装