このリファレンス アーキテクチャは、Google Distributed Cloud（GDC）エアギャップに、お客様が管理する PostgreSQL データベースをデプロイして運用するためのコンセプト フレームワークを提供します。このソリューションにより、組織は仮想マシンにデプロイされた高可用性（HA）マルチゾーン クラスタを活用して、重要なデータベース ワークロードを維持できます。
このアーキテクチャは、単一のゾーンまたはインフラストラクチャの障害が発生した場合でもデータベースの可用性を確保する、復元力のある 3 ノード構成に重点を置いています。自動プロビジョニングとネットワーキングから、高可用性、バックアップ、復元、オブザーバビリティなどの本番環境レベルの運用まで、ライフサイクル全体をカバーします。
特長と機能
このソリューションは、データベース管理用のいくつかのコア機能コンポーネントを提供します。
- 自動化された高可用性: Patroni と etcd を使用して、自動リーダー選出とフェイルオーバーを提供し、手動介入なしでデータベースの運用を継続できるようにします。
- マルチゾーンの復元性: データベース ノードを 3 つの異なるアベイラビリティ ゾーンに分散して、局所的なハードウェアやインフラストラクチャの停止から保護します。
- 標準化された自動化: Autobase で Ansible ベースのハンドブックを使用してスタック全体をプロビジョニングし、再現可能で一貫性のあるデプロイを実現します。
- 接続プーリング: 統合された PgBouncer サービスにより、多数の接続を管理し、データベース ノードのリソース消費を安定させます。
- グローバル ロード バランシング: プラットフォーム管理のグローバル L4 ロードバランサを使用して、すべてのゾーンからアクセス可能な単一の安定した仮想 IP（VIP）を提供します。
- エアギャップ対応: 必要なすべてのオペレーティング システムの依存関係とバイナリをパッケージ化し、切断された環境にデプロイするための専用ワークフロー。
- データ保護:
pg_dumpやpg_basebackupなどの標準ツールを GDC ストレージ スナップショットと併用して、堅牢なバックアップと復元戦略を維持します。
アーキテクチャ
このアーキテクチャは、3 つのアベイラビリティ ゾーンに分散された 3 つの VM 環境で構成され、コロケーションされたサービスのスタックを実行します。
アーキテクチャの原則
- 多数決ベースのコンセンサス: ノードの過半数（3 つのうち 2 つ）がクラスタの状態に同意する必要がある、クォーラムベースのモデルを使用します。これにより、「スプリット ブレイン」シナリオを防止し、データの完全性を確保します。
- 関心の分離: 各 VM は、同じ場所に配置された個別のサービス スタック（データベース、HA マネージャー、コンセンサス、プーラー）を実行して、自己完結型で復元力のあるノードを提供します。
- データベース対応フェイルオーバー: Patroni の REST API を使用してデータベースの健康指標を優先し、プラットフォーム ロードバランサを介してトラフィックのリダイレクトを調整します。
- Infrastructure as Code: すべての構成タスクを自動化されたハンドブックに依存することで、デプロイとスケーリング中の人的ミスのリスクを軽減します。
コンセプトとテクノロジー
このセクションでは、機能コンポーネント、その役割、システム内での通信方法について詳しく説明します。
インフラストラクチャとプラットフォーム
- 仮想マシン（VM）: データベース スタックをホストするためにゾーンに分散された専用のコンピューティング インスタンス。
- グローバル L4 ロードバランサ: 現在のクラスタ リーダーにトラフィックをルーティングする安定した仮想 IP（VIP）を提供する、プラットフォーム マネージド サービス。
- 永続ストレージ: コンセンサス レイヤの write-ahead log の厳格なレイテンシ要件を満たすには、高パフォーマンスの 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 データベースのリファレンス実装