このページでは、高可用性とおすすめのツールについて説明します。
データの復元力について
データの復元力は、可用性、サービスの復元時間、データ損失の観点から考えることができます。可用性は通常、稼働時間で測定され、データベースが使用可能な時間の割合で表されます。たとえば、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 ノードクラスタの混合ソリューションを構成できます。