このリファレンス アーキテクチャは、Google Distributed Cloud（GDC）エアギャップ環境に顧客管理の PostgreSQL データベースをデプロイして運用するためのコンセプト フレームワークを提供します。このソリューションを使用すると、仮想マシンにデプロイされた高可用性（HA）のマルチゾーン クラスタを活用して、重要なデータベース ワークロードを維持できます。
このアーキテクチャは、単一のゾーンまたはインフラストラクチャの障害が発生した場合でもデータベースの可用性を確保する、復元力のある 3 ノード構成に重点を置いています。自動プロビジョニングとネットワーキングから、高可用性、バックアップ、復元、オブザーバビリティなどの本番環境グレードの運用まで、ライフサイクル全体をカバーします。
特長と機能
このソリューションは、データベース管理のためのいくつかのコア機能コンポーネントを提供します。
- 自動高可用性: Patroni と etcd を使用して、リーダーの自動選出と フェイルオーバーを提供し、手動で 介入しなくてもデータベースが動作し続けるようにします。
- マルチゾーンの復元力: データベース ノードを 3 つの異なるアベイラビリティ ゾーンに分散して、局所的なハードウェアまたはインフラストラクチャの停止から保護します。
- 標準化された自動化: Autobase を使用して Ansible ベースの プレイブックでスタック全体をプロビジョニングし、再現性と一貫性のあるデプロイを 保証します。
- 接続プーリング: 統合された PgBouncer サービスにより、接続数の増加を管理し、データベース ノードのリソース消費を安定させます。
- グローバル ロード バランシング: プラットフォーム管理の グローバル L4 ロードバランサ を使用して、すべての ゾーンからアクセスできる単一の安定した仮想 IP（VIP）を提供します。
- エアギャップ対応: 切断された環境にデプロイするために必要なすべてのオペレーティング システムの依存関係とバイナリをパッケージ化する専用のワークフロー。
- データ保護: GDC ストレージ スナップショットとともに
pg_dumpやpg_basebackupなどの標準ツールを活用して、堅牢なバックアップと復元の戦略を維持します。
アーキテクチャ
このアーキテクチャは、3 つのアベイラビリティ ゾーンに分散された 3 つの VM 環境で構成され、サービスがコロケーションされたスタックを実行します。
アーキテクチャの原則
- 多数決ベースのコンセンサス: クォーラムベースのモデルを使用します。このモデルでは、ノードの過半数（3 つのうち 2 つ）がクラスタの状態に同意する必要があります。これにより、「スプリットブレイン」のシナリオを防ぎ、データの完全性を確保します。
- 懸念事項の分離: 各 VM は、コロケーションされた別個のサービス スタック（データベース、HA マネージャー、コンセンサス、プーラー）を実行して、自己完結型で復元力のあるノードを提供します。
- データベース対応のフェイルオーバー: Patroni の REST API を使用してデータベースのヘルス指標を優先し、プラットフォーム ロードバランサを介したトラフィックのリダイレクトを調整します。
- Infrastructure as Code: すべての構成タスクに自動化されたプレイブックを使用することで、デプロイとスケーリング中の人為的ミスのリスクを軽減します。
コンセプトとテクノロジー
このセクションでは、機能コンポーネント、その責任、システム内での通信方法について詳しく説明します。
インフラストラクチャとプラットフォーム
- 仮想マシン（VM）: ゾーンに分散された専用のコンピューティング インスタンスで、データベース スタックをホストします。
- グローバル L4 ロードバランサ: プラットフォーム管理のサービスで、現在のクラスタ リーダーにトラフィックをルーティングする安定した仮想 IP（VIP）を提供します。
- 永続ストレージ: コンセンサス レイヤの先行書き込みログの厳格なレイテンシ要件を満たすには、高性能の SSD ベースのストレージが必要です。
サービスとロジック
- PostgreSQL 17: データの永続性とクエリの実行を担当するコア リレーショナル データベース エンジン。
- Patroni: ローカル PostgreSQL プロセスをモニタリングし、etcd を使用してリーダー選出を調整する高可用性マネージャー。
- etcd: コンセンサス レイヤを提供し、クラスタの信頼できる状態を保持する分散構成ストア。
- PgBouncer: PostgreSQL の前に配置され、受信アプリケーション接続を効率的に処理する軽量の接続プーラー。
データフローとインターフェース
- PgBouncer（ポート 6432）: アプリケーション データベース トラフィックのプライマリ エントリ ポイント。
- Patroni API（ポート 8008）: ロードバランサがヘルスチェックを実行し、
/primaryエンドポイントを使用して現在のリーダーを識別するために使用する HTTPS REST インターフェース。 - etcd（ポート 2379）: コンセンサス クラスタが状態を維持し、選出を実行するための通信チャネル。
考慮事項
- スケーラビリティとパフォーマンス:
- データベース ノードはワークロードに基づいてサイズ設定する必要があります。最小構成は 2 つの vCPU と 8 GiB の RAM です。通常、本番環境ワークロードは 8 個の vCPU と 32 GiB から始まります。
- パフォーマンスは低レイテンシ ストレージに依存します。etcd が 10 ミリ秒未満でデータ同期を処理できるようにするには、SSD が必要です。
- 同期レプリケーション: 同期レプリケーションのオーバーヘッドは、ゾーン間のネットワーク レイテンシに直接依存します。データ損失ゼロ構成で最適なパフォーマンスを確保するには、ゾーン間のレイテンシを低くする必要があります。
- リソース管理とライセンス:
- このソリューションは、無料のオープンソース データベース コンポーネントに依存しています。
- Autobase は、HA スタックのインストールと構成を効率化するためのリファレンス 自動化ツールとして使用されます。ただし、このアーキテクチャは Autobase に限定されるものではなく、基盤となるオープンソース コンポーネントはカスタム パイプラインを使用して管理できます。
- 自動化パッケージの正式なサポートが必要な組織には、 サードパーティの有料サポートをご利用いただけます。
- PgBouncer を使用した接続プーリングは、ユーザー接続数の増加による CPU とメモリの枯渇を防ぐために不可欠です。
- 可用性と信頼性:
- 高可用性は 3 ノードのクォーラムによって実現されます。単一のノードまたはゾーンの障害が発生しても、サービスは中断されません。
- クラスタの安定性: 信頼性の高いクォーラムを維持するには、ノード間のネットワーク レイテンシを低くする必要があります。選出のタイムアウトとクラスタの不安定さを防ぐため、平均ラウンドトリップ時間（RTT）は 10 ミリ秒未満にすることをおすすめします。
- 運用管理:
- マイナー バージョンのパッチ適用やメジャー アップグレードなどの日常的なタスクは、引き続きお客様の運用チームが担当します。
- VM の
stdoutからの出力は、GDC エアギャップ モニタリング プラットフォームに自動的に取り込まれます。個々のコンポーネントの詳細なモニタリングを統合する方法については、今後のガイドで説明します。 - データベース ネイティブ ツールとプラットフォーム スナップショットを使用して、堅牢なバックアップ戦略を実装する必要があります。これらの手順の詳細なガイドは別途公開されます。
設計上の意思決定
このソリューションのアーキテクチャの選択により、マルチゾーン デプロイの復元力のあるパスが提供されます。
Kubernetes よりも仮想マシン
マルチゾーンの高可用性を実現するために、VM ベースのアプローチが選択されました。 GDC は、複数の物理ゾーンにまたがる Kubernetes クラスタをサポートしていません。そのため、堅牢なクロスゾーン アーキテクチャを実現するには、専用の VM を別々のゾーンにデプロイする必要があります。 この構成は、単一のインフラストラクチャ ゾーンの完全な障害にも対応できます。
プラットフォーム ネイティブのグローバル ロード バランシング
このアーキテクチャでは、VM 上のソフトウェア ベースのプロキシではなく、GDC グローバル L4 ロードバランサを活用します。このアプローチには、次のような利点があります。
- グローバルなリーチ: すべてのゾーンからアクセスできる安定した仮想 IP を提供します。
- プラットフォーム管理: VIP はプラットフォームのコントロール プレーンによって個別に管理されます。
- フェイルオーバーの簡素化: フェイルオーバーは、複雑なローカル ソフトウェア構成ではなく、標準のヘルスチェック プローブによって管理されます。
- 高可用性: ローカル プロキシへの依存をなくすことで、データベース トラフィックのエントリ ポイントの復元力を維持します。
前提条件と制限事項
前提条件
- 環境には、パッケージ化された OS の依存関係とバイナリをインポートするためのローカル レジストリまたはメカニズムがあります。
- Ansible ベースの自動化では、すべてのターゲット VM で鍵ベースの SSH アクセスが可能です。
- プロジェクトには、マルチゾーン VM とロードバランサのプロビジョニングに十分な割り当てがあります。
制限事項
- 手動メンテナンス: オペレーティング システムのパッチ適用と PostgreSQL バージョンのアップグレードは手動タスクであり、このソリューションでは自動化されません。
- ストレージの感度: コンセンサス レイヤ（etcd）はディスク レイテンシに非常に敏感です。ストレージの競合が継続的に発生すると、コンセンサス レイヤの安定性に影響する可能性があります。
- ネットワークの安定性: 高可用性マネージャーは、ゾーン間の低レイテンシのネットワーク接続に依存しています。遅延やネットワーク ジッターは、クラスタの調整とロールの移行のタイミングに影響する可能性があります。
その他の教材
- リファレンス自動化コード リポジトリ: GitHub の Autobase ソースコード
- PostgreSQL データベースのリファレンス実装