ゾーン レプリケーションを使用してデータを保護する

ドキュメントのバージョンを選択してください。

このページでは、AlloyDB Omni の拡張可用性リファレンス アーキテクチャについて説明します。このアーキテクチャは 1 つ以上のデータベース レプリカを同じリージョン内にデプロイすることで高可用性を実現し、ノードレベルまたはゾーンレベルの障害から保護します。

ユースケース

この可用性リファレンス アーキテクチャは、次のユースケースに適しています。

  • RTO と RPO の短縮が求められるビジネス クリティカルなアプリケーション。
  • データベースの高可用性を実現し、インスタンス、サーバー、ゾーンの障害から保護するレプリカを別のゾーンまたはノードにデプロイする。
  • ユーザーエラーやデータ破損から保護する（バックアップを使用）。

リファレンス アーキテクチャの仕組み

標準可用性が強化された拡張可用性のアーキテクチャでは、リージョン内にリードレプリカ インスタンスを追加することにより、高可用性（HA）を実現して目標復旧時間（RTO）を短縮します。このアプローチでは、トランザクションの変更をレプリカにストリーミングできるため、目標復旧時点（RPO）も短縮されます。

AlloyDB Omni の高可用性では、少なくとも 2 つのデータベース インスタンスが使用されます。1 つのインスタンスが、読み取り / 書き込みオペレーションを行えるプライマリ データベースとして機能します。残りのインスタンスは、読み取り専用モードで動作するリードレプリカとして機能します。

HA の重要なコンセプトは次のとおりです。

  • フェイルオーバーは、プライマリ インスタンスが故障する（または使用不可になる）という計画外の停止時に実行される手順です。このとき、スタンバイ レプリカがプライマリ（読み取り / 書き込み）モードでアクティブになります。このプロセスは「プロモーション」と呼ばれます。通常、このようなシナリオでは、プライマリ サーバーまたはデータベースがオンラインに戻ったときに、データベースを再構築してスタンバイとして機能させる必要があります。稼働時間を長くするために、フェイルオーバーを自動化するメカニズムが導入されています。
  • スイッチオーバー（ロール リバーサルとも呼ばれます）は、プライマリ データベースといずれかのスタンバイ データベースのモードを入れ替えるために使用される手順です。このとき、プライマリがスタンバイになり、スタンバイがプライマリになります。通常、スイッチオーバーは、ダウンタイムを許可してプライマリ データベースへのパッチ適用を行うなど、さまざまな理由で開始され、制御された適切な方法で行われます。スイッチオーバーが適切に行われれば後でスイッチバック（元に戻す処理）を行うことが可能であり、その際に新しいスタンバイやレプリケーション構成のその他の側面を再インスタンス化する必要はありません。

高可用性オプション

HA をサポートするために、AlloyDB Omni は次の方法でデプロイできます。

注: Patroni と HAProxy は、非商用のサードパーティ ツールであり、AlloyDB Omni に対応しています。

いずれかのスタンバイ データベースが失われてもクラスタの高可用性に影響が出ないよう、少なくとも 2 つのスタンバイ データベースを用意することをおすすめします。そうすれば、フェイルオーバーやノードの計画メンテナンスの際に少なくとも 1 つの HA ペアを確保できます。

AlloyDB Omni のデプロイのサイズと形状を計画するには、VM への AlloyDB Omni のインストールを計画するをご覧ください。

ロードバランサ

スイッチオーバーやフェイルオーバーのプロセスをスムーズにするもう一つの重要なメカニズムが、ロードバランサです。Kubernetes 以外のデプロイでは、HAProxy ソフトウェアがロード バランシングを提供します。HAProxy は、ネットワーク トラフィックを複数のサーバーに分散することでロード バランシングを提供します。また、ヘルスチェックを実行して、接続先のバックエンド サーバーを健全な状態に維持します。サーバーがヘルスチェックに失敗すると、HAProxy は、サーバーが再びヘルスチェックに合格するまで、そのサーバーへのトラフィックの送信を停止します。

Kubernetes オペレーターは、ユーザーがこれを意識しなくてもすむよう、同様に動作する独自のロードバランサをデプロイし、そのロードバランサを参照するサービスをデータベース用に作成します。

高可用性

リージョン内にデプロイされたリードレプリカ データベースにより、プライマリ データベースに障害が発生した場合の高可用性が提供されます。プライマリ データベースで障害が発生すると、スタンバイ データベースがプライマリ データベースにプロモートされるため、アプリケーションはほとんどまたはまったく停止せずに続行されます。

スイッチオーバーの方式で定期的に年 1 回または半年に 1 回のチェックを行い、これらのデータベースに依存するすべてのアプリケーションが適切な時間枠内で接続して応答することを確認するようにおすすめします。

どちらのデプロイでも、プライマリ データベースとは異なるアベイラビリティ ゾーンにスタンバイ リードレプリカの 1 つを配置することで、ゾーンレベルの保護を実現できます。

リードレプリカを使用するもう 1 つのメリットは、読み取り専用オペレーションをスタンバイ データベースにオフロードできることです。スタンバイ データベースは、最新のデータを使用してレポート データベースとして機能できます。このアプローチにより、読み取り / 書き込みを行うプライマリの負荷とオーバーヘッドが軽減されます。

バックアップと高可用性構成

リードレプリカは、高可用性を提供する複数のゾーンで設定できます。この構成では RTO と RPO は短くなりますが、論理データの破損（テーブルの誤削除やデータの誤更新など）などの特定の停止から保護することはできません。そのため、HA の設定に加えて定期的なバックアップを行う必要があります。詳細については、標準可用性アーキテクチャのドキュメントをご覧ください。

図 1 は、2 つの異なるアベイラビリティ ゾーンに 2 つのリードレプリカ スタンバイ データベースがある推奨の HA 構成を示しています。

バックアップと高可用性のオプションが構成された AlloyDB Omni

図 1: バックアップと高可用性のオプションが構成された AlloyDB Omni。

プライマリ インスタンスで障害が発生した場合にデータ損失を防ぐには、同期モードのレプリケーションを構成する必要があります。この方法ではデータ保護が強化されますが、すべての commit をプライマリ データベースとすべての同期済みスタンバイ データベースの両方に書き込む必要があるため、プライマリ データベースのパフォーマンスに影響する可能性があります。この設定では、データベース インスタンス間で低レイテンシのネットワーク接続が不可欠です。

Kubernetes での HA のデプロイ

Kubernetes でのデプロイの場合は、AlloyDB Omni デプロイ ファイルでいくつかの基本属性の変更や追加を行うことで、プライマリ データベースの障害に対応するフェイルオーバー スタンバイ レプリカまたはリードレプリカを追加できます。フェイルオーバー スタンバイ レプリカとリードレプリカを構成した後、オペレーターによってサービスのプロビジョニングと公開が行われます。また、オペレーターは、フェイルオーバー後のスタンバイ データベースの再構築や、AlloyDB Omni Kubernetes エンジンに組み込まれた修復メカニズムの適用など、多くの HA プロセスを自動化します。

Kubernetes でのデプロイでは、ノードや Pod の障害を処理する組み込みの Kubernetes 機能により、インフラストラクチャとアプリケーションの可用性が向上します。たとえば、次のような機能があります。

オペレーターは、組み込みの保護に加えて、障害が発生したプライマリまたはスタンバイの検出に影響を与える次のパラメータを公開します。

  • healthcheckPeriodSeconds: ヘルスチェックの間隔（デフォルトは 30 秒）
  • autoFailoverTriggerThreshold: フェイルオーバーが開始されるまでにヘルスチェックが連続して失敗する回数。デフォルトは 3 です。

詳細については、Kubernetes で高可用性を管理するをご覧ください。

Kubernetes 以外での HA のデプロイ

Kubernetes 以外でのスタンドアロン デプロイは手動構成であり、Kubernetes でのデプロイよりも設定とメンテナンスが複雑なサードパーティ ツールが必要です。

Kubernetes 以外でのデプロイの場合は、フェイルオーバーの検出方法と、プライマリが使用不可になってからフェイルオーバーが実行されるまでの時間に影響するパラメータがあります。これらのパラメータの概要は次のとおりです。

  • Ttl: フェイルオーバーが開始されるまでにプライマリ データベースのロックを取得するのにかかる最大時間。デフォルト値は 30 秒です。
  • Loop_wait: 再チェックするまでの待機時間。デフォルト値は 10 秒です。
  • Retry_timeout: ネットワーク障害によりプライマリ インスタンスをデモートするまでのタイムアウト。デフォルト値は 10 秒です。

詳細については、AlloyDB Omni for PostgreSQL の高可用性アーキテクチャをご覧ください。

実装

この可用性リファレンス アーキテクチャを選択する際は、以下の利点、制限事項、代替案を考慮してください。

利点

  • インスタンス障害から保護できます。
  • サーバー障害から保護できます。
  • ゾーン障害から保護できます。
  • RTO が標準可用性アーキテクチャより大幅に短縮されます。

制限事項

  • リージョン障害に対する追加の保護はありません。
  • 同期レプリケーションにより、プライマリのパフォーマンスが影響を受ける可能性があります。
  • 同期モードで PostgreSQL WAL ストリーミングを構成すると、通常のオペレーションまたは一般的なフェイルオーバーでデータ損失（RPO=0）が発生しません。ただし、このアプローチでは、すべてのスタンバイ インスタンスが失われたり、プライマリから到達不能になったりした直後にプライマリが再起動されるなど、特定の二重障害の状況でのデータ損失を防ぐことはできません。

別の方法

次のステップ