このページでは、高可用性と、使用をおすすめするツールについて説明します。
データの復元力について
データの復元力は、可用性、サービスの復元時間、データ損失の観点から考えることができます。可用性は通常、稼働時間で測定され、データベースが使用可能な時間の割合として表されます。たとえば、99.99% の可用性を実現するには、データベースのダウンタイムを年間 52.6 分（月間 4.38 分）未満にする必要があります。停止後にサービスを復元するまでの時間を目標復旧時間（RTO）といいます。停止による許容できるデータ損失量は、目標復旧時点（RPO）と呼ばれ、トランザクションが失われる時間として表されます。たとえば、RPO が 10 分の場合、障害が発生すると最大 10 分間のデータが失われる可能性があります。
可用性の目標、つまりサービスレベル目標（SLO）は、RTO と RPO の目標とともに設定するのが一般的です。たとえば、特定のワークロードに対して SLO を 99.99% に設定し、RPO を 0、障害が発生してもデータ損失がないこと、RTO を 30 秒に設定できます。別のワークロードの場合は、SLO を 99.9%、RPO を 5 分、RTO を 10 分に設定できます。
データベースのバックアップを使用して、基本的なデータベースの復元力を実装できます。AlloyDB Omni は pgBackRest を使用したバックアップをサポートし、データベースの Write-Ahead Log（WAL）ファイルをアーカイブしてデータ損失を最小限に抑えます。このアプローチでは、プライマリ データベースが停止した場合、データベースのサイズに応じて、RPO が数分、RTO が数分から数時間のバックアップから復元できます。
RPO と RTO の要件が厳しい場合は、Patroni を使用して AlloyDB Omni を高可用性構成で設定できます。このアーキテクチャには、プライマリ データベースと 2 つのスタンバイ（レプリカ）データベースがあります。標準の PostgreSQL ストリーミング レプリケーションを使用するように AlloyDB Omni を構成すると、プライマリで commit された各トランザクションが両方のスタンバイ データベースに同期的に複製されます。これにより、ほとんどの障害シナリオで RPO がゼロになり、RTO が 60 秒未満になります。
クラスタ構成によっては、同期レプリケーションがトランザクションのレスポンス時間に影響することがあります。また、少量のデータ損失のリスクを選択することもできます。たとえば、同期ではなく非同期レプリケーションで高可用性を実装することで、トランザクション レイテンシを低減し、RPO をゼロ以外に設定できます。同期レプリケーションがトランザクション レイテンシに与える影響が懸念されるため、高可用性アーキテクチャはほとんどの場合、単一のデータセンター内、または近接するデータセンター（数十 km 離れた / レイテンシが 10 ミリ秒未満）間で実装されます。ただし、このドキュメントでは、デフォルトで同期レプリケーションを使用しています。
障害復旧（データセンターの損失や、複数のデータセンターが密集しているリージョンの損失に対する保護）の場合、AlloyDB Omni は、プライマリ リージョンからセカンダリ リージョン（通常は数百または数千 km 離れているか、数十から数百ミリ秒離れている）への非同期ストリーミング レプリケーションで構成できます。この構成では、プライマリ リージョンは、リージョン内のプライマリ データベースとスタンバイ データベース間の同期ストリーミング レプリケーションで構成され、プライマリ リージョンから 1 つ以上のセカンダリ リージョンへの非同期ストリーミング レプリケーションが構成されます。AlloyDB Omni は、複数のデータベース インスタンスを使用してセカンダリ リージョンに構成し、プライマリ リージョンからのフェイルオーバー直後に保護されるようにできます。
高可用性の仕組み
データベースの高可用性を実装するために使用される特定のテクニックとツールは、データベース管理システムによって異なる場合があります。データベースの高可用性を実装する際に通常使用される手法とツールは次のとおりです。データベース管理システムによって異なる場合があります。
冗長性: 複数のサーバーまたは地理的リージョンにデータベースを複製すると、プライマリ インスタンスが停止した場合にフェイルオーバー オプションが提供されます。
自動フェイルオーバー: 障害を検出して正常なレプリカにシームレスに切り替え、ダウンタイムを最小限に抑えるメカニズム。クエリは、アプリケーション リクエストが新しいプライマリ ノードに到達するように転送されます。
データの継続性: 障害発生時のデータの完全性を保護するために、安全保護対策が実装されています。これには、レプリケーション手法とデータ整合性チェックが含まれます。
クラスタリング: クラスタリングでは、複数のデータベース サーバーをグループ化して、単一のシステムとして連携させます。これにより、クラスタ内のすべてのノードがアクティブになり、リクエストを処理してロード バランシングと冗長性を提供します。
フォールバック: フェイルオーバー前のプライマリ ノードとレプリカノードを元の容量で使用して、元のアーキテクチャにフォールバックする方法。
ロード バランシング: データベース リクエストを複数のインスタンスに分散することで、パフォーマンスが向上し、増加したトラフィックを処理できます。
モニタリングとアラート: モニタリング ツールは、サーバー障害、レイテンシの増加、リソースの枯渇、アラートのトリガー、自動フェイルオーバー プロシージャなどの問題を検出します。
バックアップと復元: バックアップを使用すると、データの破損や致命的な障害が発生した場合に、データベースを以前の状態に復元できます。
接続プーリング（省略可）: データベースとやり取りするアプリケーションのパフォーマンスとスケーラビリティを最適化します。
高可用性ツール
Patroni は、PostgreSQL クラスタの高可用性を管理して自動化するように設計された、PostgreSQL データベース用のオープンソース クラスタ管理ツールです。Patroni は、etcd、Consul、Zookeeper などのさまざまな分散コンセンサス システムを使用して、クラスタの状態を調整および管理します。Patroni の主な機能とコンポーネントには、自動フェイルオーバー、リーダー選出、レプリケーション、復元による高可用性などがあります。Patroni は、データベース サーバー インスタンスで PostgreSQL サービスとともに実行され、その状態、フェイルオーバー、レプリケーションを管理して、高可用性と信頼性を確保します。
Patroni は、分散コンセンサス システムを使用してメタデータを保存し、クラスタを管理します。このガイドでは、etcd という分散構成ストア（DCS）を使用します。etcd の用途の 1 つは、構成、ヘルス、現在のステータスなどの分散システム情報を保存して取得し、すべてのノード間で一貫した構成を確保することです。
高可用性プロキシ（HAProxy）は、TCP ベースと HTTP ベースのアプリケーションのロード バランシングとプロキシに使用されるオープンソース ソフトウェアです。受信リクエストを複数のサーバーに分散することで、ウェブ アプリケーションのパフォーマンスと信頼性を向上させます。HAProxy は、ネットワーク トラフィックを複数のサーバーに分散することでロード バランシングを提供します。また、HAProxy はヘルスチェックを実行して、接続するバックエンド サーバーのヘルス状態を維持します。サーバーがヘルスチェックに失敗すると、HAProxy は、サーバーが再びヘルスチェックに合格するまで、そのサーバーにトラフィックの送信を停止します。
同期レプリケーションと非同期レプリケーションに関する考慮事項
Patroni 管理の PostgreSQL クラスタでは、レプリケーションを同期モードと非同期モードの両方で構成できます。デフォルトでは、Patroni は非同期ストリーミング レプリケーションを使用します。RPO 要件が厳しい場合は、同期レプリケーションを使用することをおすすめします。
PostgreSQL の同期レプリケーションでは、トランザクションがプライマリと少なくとも 1 つの同期スタンバイの両方に書き込まれるのを待ってから commit することで、データの整合性が確保されます。同期レプリケーションにより、プライマリ障害が発生してもデータが失われることがなく、データの耐久性と整合性が確保されます。プライマリは同期スタンバイからの確認応答を待機します。これにより、ラウンドトリップ時間が長くなるため、レイテンシが増加し、スループットが低下する可能性があります。これにより、特に負荷が高い場合に、システム全体のスループットが低下する可能性があります。
非同期レプリケーションを使用すると、スタンバイ クラスタからの確認応答を待たずに、プライマリ クラスタでトランザクションを commit できます。プライマリは WAL レコードをスタンバイに送信し、スタンバイはレコードを非同期で適用します。この非同期アプローチでは、書き込みレイテンシが短縮され、パフォーマンスが向上しますが、スタンバイが追いつく前にプライマリに障害が発生した場合にデータが失われるリスクがあります。スタンバイがプライマリより遅れていると、フェイルオーバー中に不整合が発生する可能性があります。
Patroni クラスタで同期レプリケーションと非同期レプリケーションのどちらを使用するかは、データの耐久性、整合性、パフォーマンスの特定の要件によって異なります。データの整合性とデータ損失の最小化が重要なシナリオでは同期レプリケーションが適しています。一方、パフォーマンスと低レイテンシが優先される環境には非同期レプリケーションが適しています。リージョンの停止を防ぐために、同じリージョン内の近くのゾーンまたはデータセンターに同期スタンバイがあり、別のリージョンまたはより遠くのデータセンターに 2 番目の非同期スタンバイがある 3 ノード クラスタを含む混合ソリューションを構成できます。