Azure Database for PostgreSQL の信頼性

Azure Database for PostgreSQLは、データベース管理機能と構成設定をきめ細かく制御し、柔軟性を提供するフル マネージド データベース サービスです。 このサービスは、要件に基づいて高可用性とディザスター リカバリーの機能を提供します。

Azureを使用する場合、信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止、サービス メンテナンスなど、さまざまな潜在的な障害や問題に対するAzure Database for PostgreSQL回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Azure Database for PostgreSQLサービス レベル アグリーメント (SLA) に関する重要な情報を強調します。

運用環境のデプロイに関する推奨事項

ソリューションの信頼性要件をサポートするためにAzure Database for PostgreSQLをデプロイする方法、および信頼性がアーキテクチャの他の側面にどのように影響するかについては、「Azure Well-Architected Framework でのAzure Database for PostgreSQLのアーキテクチャのベスト プラクティス」を参照してください。

信頼性アーキテクチャの概要

このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。

論理アーキテクチャ

Azure Database for PostgreSQLを使用する場合は、サーバーをデプロイします。これは、サーバーにデプロイするデータベースをサポートするために必要なコンピューティング リソースとストレージ リソースを表します。

サーバーは、バースト可能、汎用、メモリ最適化の複数の コンピューティング レベルにデプロイできます。 各レベルは、 さまざまな種類のワークロードに合わせて最適化されています。 一部の Azure リージョンでは、 Azure Confidential Computing を使用してサーバーをデプロイできます。

一般的なサービス アーキテクチャとデプロイ モデルの詳細については、「Azure Database for PostgreSQLの概要」を参照してください。

物理アーキテクチャ

• コンピューティングとストレージの分離: Azure Database for PostgreSQL では、高可用性をサポートするためにコンピューティングとストレージの分離アーキテクチャが使用されます。 データベース エンジンは Linux 仮想マシン (VM) で実行されますが、Azure Storageはデータ ファイルを保持し、データの持続性を確保するためにデータベース ファイルの 3 つのローカル冗長同期コピーを保持します。

• 高可用性: サーバーで高可用性構成を有効にすることができます。 高可用性構成を有効にすると、サービスはウォーム スタンバイ サーバーをプロビジョニングして維持します。 プライマリ サーバーは、プライマリ サーバーの障害時にデータ損失をゼロにするために、データ変更を同期的にスタンバイ サーバーにレプリケートします。

  このアーキテクチャでは、コンピューティング レイヤーとストレージ レイヤーが分離されるため、サービスはさまざまな種類のエラーを適切に処理できます。 より高い回復性を実現するために、サーバーを可用性ゾーンに分散させることができます。

  

  Azure Database for PostgreSQLの高可用性アーキテクチャを示す図。 2 台のサーバーが並んでいる。 左側にはプライマリ サーバーというラベルの付いたボックスがあり、そのボックス内には仮想マシンとディスクがあります。 右側には、仮想マシンとディスクも含まれる、スタンバイ サーバーというラベルが付いた一致するボックスがあります。 左側のプライマリ サーバーから右側のスタンバイ サーバーを指す水平矢印、矢印にはストリーミング レプリケーションというラベルが付けられます。これは、プライマリ サーバーからスタンバイ サーバーにデータが変化する一方向の関係を示します。

  スタンバイ サーバーは、仮想コア、ストレージ、ネットワーク設定など、プライマリ サーバーと同じ VM 構成にデプロイされます。

  フェールオーバーを実行することで、サーバーを切り替えることができます。 2 種類のフェールオーバーが存在します。 強制フェールオーバーは、プライマリ サーバーで障害が発生したときに使用されます。 計画されたフェールオーバーは、一部のメンテナンス操作中に使用されます。また、フェールオーバー中にアプリケーションのダウンタイムを最小限に抑える必要があるその他のシナリオで使用されます。

  停止、開始、再起動などの操作を実行すると、プライマリ データベース サーバーとスタンバイ データベース サーバーの両方で同時に実行されます。 コンピューティングのスケーリングやストレージのスケーリングなどの計画的なイベントは、最初にスタンバイで発生し、次にプライマリ サーバーで発生します。 現時点では、これらの計画された操作に対してサーバーはフェールオーバーされません。

  詳細については、「 Azure Database for PostgreSQL の高可用性」を参照してください。

• バックアップ： Azure Database for PostgreSQL では、サーバー バックアップが自動的に作成されます。 詳細については、「 バックアップと復元」を参照してください。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。

アプリケーションは、メンテナンス、スケーリング操作、またはネットワークの中断中に発生する可能性のある一時的な接続エラーを処理する必要があります。 次の推奨事項に従ってください。

詳細については、「 Azure Database for PostgreSQL での一時的な接続エラーの処理」を参照してください。

可用性ゾーンの障害に対する回復性

可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

高可用性構成を使用して、可用性ゾーンのサポートの種類を選択します。 高可用性を有効にすると、サービスはプライマリ サーバーと共にスタンバイ サーバーをデプロイします。 この高可用性モデルは、コミットされたデータが障害時に失われないようにするのに役立ちます。 サーバーが使用する高可用性デプロイ モデルでは、プライマリ サーバーとスタンバイ サーバーの両方にデータが同期的にコミットされます。 プライマリ サーバーに中断が発生した場合、サーバーは自動的にスタンバイ サーバーにフェールオーバーします。

各可用性ゾーンは、データ ファイルと先書きログ (WAL) を Premium マネージド ディスクに格納し、各ゾーン内に 3 つのデータ コピーを自動的に格納するローカル冗長ストレージ (LRS) を使用します。

Azure Database for PostgreSQL では、高可用性を使用する場合、次の 2 種類の可用性ゾーン構成がサポートされます。

• ゾーン冗長高可用性: ゾーン冗長性は、1 つの可用性ゾーンにプライマリ サーバーをデプロイし、スタンバイ サーバーを別の可用性ゾーンにデプロイすることで、最高レベルのゾーンの回復性を実現します。 スタンバイ サーバーは、プライマリ サーバーと同様のコンピューティング、ストレージ、およびネットワーク構成を使用します。 ゾーン冗長構成では、プライマリ サーバーとスタンバイ サーバー間でスタック全体が物理的に分離されます。

  プライマリ サーバーとスタンバイ サーバーの可用性ゾーンを選択するか、Microsoft に選択させることができます。

  運用サーバーにはゾーン冗長展開をお勧めします。

  

  複数の可用性ゾーンにまたがる、ゾーン冗長の Azure Database for PostgreSQL 構成を示す図。 一番上には、可用性ゾーン 1、可用性ゾーン 2、可用性ゾーン 3 の 3 つのゾーンが表示されます。 可用性ゾーン 1 の下にはプライマリ サーバーというラベルが付いたボックスがあり、そのボックス内には仮想マシンとディスクがあり、プライマリ サーバーがコンピューティングとストレージで構成されていることを示します。 可用性ゾーン 2 の下には、仮想マシンとディスクも含まれる、スタンバイ サーバーというラベルが付いた一致するボックスがあります。 これら 2 つのサーバー ボックスの間には、ストリーミング レプリケーションというラベルが付いた右向きの矢印があり、左側のプライマリ サーバーから右側のスタンバイ サーバーにデータ変更が流れる様子が示されています。 レイアウトはゾーン間の回復性を伝えます。プライマリとスタンバイは 2 つの可用性ゾーン間で分離され、可用性ゾーン 3 は未使用のままです。

  書き込み操作では、サービスがスタンバイ サーバーにデータを同期的にレプリケートするため、コミット待機時間が少し増加する可能性があります。 影響は、ワークロード、選択した SKU、リージョンによって異なります。

• ゾーン (同じゾーン) の高可用性: プライマリ サーバーとスタンバイ サーバーは、同じ可用性ゾーンを使用します。 プライマリ サーバーに中断が発生しても、ゾーンがまだ正常な場合、サーバーは自動的にスタンバイ サーバーにフェールオーバーします。 ゾーン展開を使用すると、単一の可用性ゾーン内で高可用性を実現できます。 これにより、ノード レベルの障害から保護され、計画されたダウンタイムイベントや計画外のダウンタイム イベント中のアプリケーションのダウンタイムを削減するのにも役立ちます。 ただし、そのゾーンでの停止に対する保護はありません。

  

  単一の可用性ゾーンにおける、Azure Database for PostgreSQL のゾーン構成を示す図。 可用性ゾーン 1、可用性ゾーン 2、可用性ゾーン 3 の 3 つのゾーンが表示されます。 可用性ゾーン 1 には、2 つのボックスが並べて表示されます。 左側のボックスにはプライマリ サーバーというラベルが付いています。そのボックス内には仮想マシンとディスクがあります。 右側のボックスにはスタンバイ サーバーというラベルが付いています。そのボックス内には仮想マシンとディスクがあります。 これら 2 つのサーバー ボックスの間には、ストリーミング レプリケーションというラベルが付いた右向きの矢印があり、左側のプライマリ サーバーから右側のスタンバイ サーバーにデータ変更が流れる様子が示されています。 両方のサーバーが同じ可用性ゾーンに存在します。 可用性ゾーン 2 と可用性ゾーン 3 は使用されません。

  ゾーン (同じゾーン) の高可用性は、次の状況でのみ使用できます。

  • リージョンは可用性ゾーンをサポートしていません。 リージョンは実質的に 1 つのゾーンとして機能するため、選択できる高可用性構成は同じゾーンのみです。
  • リージョンにゾーン冗長デプロイに十分な容量がない場合、サービスは最初に両方のサーバーを同じ可用性ゾーンに配置し、容量が使用可能になったときに自動的に別のゾーンに移行できます。 このオプションは、Azure portal または Azure CLI を使用してサーバーをデプロイするときに使用できます。 詳細については、「 Business Critical (高可用性) オプションの構成」を参照してください。

  サーバーを同じゾーンに配置すると、同じゾーン内にデプロイするアプリケーションへの書き込み待機時間を短縮できます。

  サーバーが同じゾーンにある場合、同じゾーン内にデプロイするアプリケーションへの書き込み待機時間を短縮できます。

高可用性なしでサーバーを構成した場合、サーバーは 1 つのサーバーで実行されます。 そのサーバーまたはそのゾーンがダウンした場合、サーバーは使用できません。 詳細については、「 可用性ゾーンのない構成」を参照してください。

必要条件

• リージョンのサポート: Azure Database for PostgreSQLは、Azure リージョン間で異なる方法で可用性ゾーンの構成をサポートします。 リージョンの完全な一覧、可用性ゾーンのサポートの種類、および各リージョンの具体的な考慮事項については、Azureリージョンを参照してください。

• コンピューティング レベル: 次の表に、可用性ゾーンのサポートの種類ごとのコンピューティング レベルのサポートを示します。

  コンピューティング レベル	ゾーン冗長	ゾーン内（同一ゾーン）
  バースト可能	サポートしていません	サポートしていません
  General Purpose	サポートされている	サポートされている
  メモリ最適化	サポートされている	サポートされている

• サービス レベル: どちらの種類の高可用性でも、General Purpose レベルまたはメモリ最適化レベルが必要です。

考慮事項

リージョンの容量: リージョンにゾーン冗長デプロイに十分な容量がない場合、サービスは最初に両方のサーバーを同じ可用性ゾーンに配置し、容量が使用可能になったときに自動的に別のゾーンに移行できます。 このオプションは、Azure portal または Azure CLI を使用してサーバーをデプロイするときに使用できます。 詳細については、「 Business Critical (高可用性) オプションの構成」を参照してください。

Cost

高可用性を有効にすると、スタンバイ サーバーが作成され、プライマリ サーバーと同じレートで課金されます。 可用性ゾーンの構成はコストに影響しません。 可用性ゾーン内または可用性ゾーン間のデータ レプリケーションには料金はかかりません。 バックアップ ストレージ ボリュームによっては、バックアップ ストレージの請求が発生する場合もあります。 価格の詳細については、 Azure Database for PostgreSQL の価格に関するページを参照してください。

可用性ゾーンのサポートを設定する

サーバーの可用性ゾーンのサポートを構成するには、高可用性設定を構成します。

• ゾーン冗長サーバーを作成します。高可用性とゾーン冗長性を有効にしたサーバーを作成する方法については、「クイック スタート: Azure Database for PostgreSQL サーバーを作成する」を参照してください。

• 既存のサーバーの可用性ゾーンの構成を変更します 。高可用性設定を変更して、既存のサーバーの可用性ゾーンの構成を変更します。 詳細な手順については、「 既存のサーバーの高可用性を有効にする」を参照してください。

  プライマリ サーバーまたはスタンバイ サーバーに使用されるゾーンを変更することはできません。 サーバーをもう一度作成する必要があります。

  ヒント

  高可用性構成を変更する前に、サーバー アクティビティが低くなるまで待機することをお勧めします。

• 高可用性を無効にする: 高可用性を無効にすると、スタンバイ サーバーが削除されるため、サーバーは可用性ゾーンの停止に対する回復性がありません。 詳細については、「高可用性を 無効にする」を参照してください。

すべてのゾーンが正常な場合の動作

このセクションでは、高可用性と可用性ゾーンのサポートを使用してサーバーを構成し、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。

• ゾーン間操作: PostgreSQL クライアント アプリケーションは、データベース サーバー名を使用してプライマリ サーバーに接続します。 Azure Database for PostgreSQLでは、プライマリ可用性ゾーン内のプライマリ サーバーがすべてのデータベース接続とクエリを処理するアクティブ/パッシブ構成を使用します。 スタンバイ サーバーは、通常の操作中にクライアント トラフィックを処理しません。

• ゾーン間データ レプリケーション: プライマリ サーバーは、変更をスタンバイ サーバーに同期的にレプリケートします。 プライマリ サーバーとスタンバイ サーバーの両方が書き込みを確認するまで、トランザクションは完了と見なされません。

  アプリケーションがデータを書き込んでコミットすると、PostgreSQL は最初にプライマリ サーバー上の WAL の変更を記録します。 プライマリ サーバーは、PostgreSQL ストリーミング プロトコルを使用して、これらのログをスタンバイ サーバーにストリーミングします。 スタンバイ サーバーが WAL を永続的に格納した後、プライマリ サーバーは書き込みを確認します。 アプリケーションは、この受信確認の後にのみトランザクションをコミットします。 この確認プロセスでは、スタンバイ サーバーへのログの適用を待機しません。

  レプリケーションの効果は、サーバーが使用する可用性ゾーンの構成によって異なります。

  • ゾーン冗長: サーバーは別々のゾーンにあるため、この方法により、ゾーン障害時のデータ損失がゼロになります。 この状況は、ゾーン障害に対して目標復旧ポイント (RPO) を 0 に達成する場合とも呼ばれます。

    ただし、クロスゾーン レプリケーションでは、少量の余分な待機時間が発生する可能性があります。 待機時間の影響は、アプリケーションによって異なります。 ほとんどのアプリケーションでは、余分な待機時間はごくわずかです。

  • ゾーン: 両方のサーバーが同じゾーンにあるため、ゾーン間でトラフィックはレプリケートされません。

  注

  システムは、ログ データをスタンバイ サーバーにリアルタイムでレプリケートします。 テーブルの誤削除や不適切なデータ更新など、プライマリ サーバー上のユーザー エラーは、スタンバイ サーバーにレプリケートされます。 スタンバイを使用してこれらの種類のエラーから回復することはできません。また、バックアップから特定の時点への復元を実行する必要があります。 詳細については、「 バックアップと復元」を参照してください。

ゾーン障害時の動作

このセクションでは、高可用性と可用性ゾーンのサポートを使用してサーバーを構成し、可用性ゾーンの停止が発生した場合に想定される内容について説明します。

• 検出と応答: Azure では、プライマリ サーバーとスタンバイ サーバーの両方の正常性が定期的にチェックされます。 複数の ping を実行した後、正常性の監視でプライマリ サーバーに到達できないことが検出された場合、サービスはスタンバイ サーバーへの自動フェールオーバーを開始します。 正常性監視アルゴリズムは、誤検知の状況を回避するために複数のデータ ポイントを使用します。

  可用性ゾーンが失敗した場合、サーバーで使用される可用性ゾーンの構成によって動作が異なります。

  • ゾーン冗長: Azure Database for PostgreSQL は、可用性ゾーンの障害を自動的に検出します。 使用可能な高可用性状態の種類を表示するには、高可用性 (HA) の正常性状態の監視に関するページを参照してください。 ゾーンに障害が発生すると、Azure は、アクションを実行しなくても、スタンバイ サーバーへの 強制フェールオーバー を開始します。

  • ゾーン: ゾーン サーバーをホストする可用性ゾーンが利用できなくなった場合、プライマリ サーバーとスタンバイ サーバーの両方が利用できなくなります。 このシナリオでは、サービスは自動フェールオーバーを提供しません。 ゾーンの停止を検出し、別の可用性ゾーンまたはリージョン内の別のサーバーにゾーン冗長バックアップを復元するなど、復旧アクションを実行する必要があります。

• 通知：Azure Database for PostgreSQLでの高可用性の正常性状態の監視では、高可用性が有効なインスタンスの正常性と準備の継続的な概要が提供されます。 監視機能は Azure Resource Health に基づいて構築されており、データベースのフェールオーバーの準備状況や全体的な可用性に影響を与える可能性のある問題を検出してアラートを生成できます。 接続状態、フェールオーバー状態、データ レプリケーションの正常性などの主要なメトリックを評価して、プロアクティブなトラブルシューティングを可能にし、データベースのアップタイムとパフォーマンスを維持するのに役立ちます。

  HA の正常性状態の構成と解釈に関する詳細なガイドについては、 高可用性 (HA) の正常性状態の監視に関するページを参照してください。

• アクティブな要求: 可用性ゾーンが使用できなくなった場合、影響を受けるゾーン内のサーバーに対する進行中の要求が終了する可能性があります。 アプリケーションは、これらの要求を再試行する必要があります。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。

• 予想されるデータ損失: データ損失の量は、サーバーが使用する可用性ゾーンの構成によって異なります。

  • ゾーン冗長: 異なるゾーン内のプライマリ サーバーとスタンバイ サーバー間の同期レプリケーションにより、ゾーンのフェールオーバー中にデータ損失が発生しません。

  • 帯状： 影響を受けるゾーン内のサーバー上のデータは、ゾーンが回復するまで使用できません。

• 予想されるダウンタイム: ダウンタイムの量は、サーバーが使用する可用性ゾーンの構成によって異なります。

  • ゾーン冗長: 通常、フェールオーバーは 60 ~ 120 秒以内に完了します。 クライアントが短時間後に再試行することによって 一時的な障害 を適切に処理する場合、通常は重大な影響を回避します。

  • ゾーン: 影響を受けるゾーン内のサーバーは、可用性ゾーンが復旧するまで使用できません。

• 再 分配： トラフィックの再ルーティング動作は、サーバーが使用する可用性ゾーンの構成によって異なります。

  • ゾーン冗長: フェールオーバー後、以前のスタンバイ サーバーが新しいプライマリになり、新しい接続の受け入れが開始されます。 Azure では、復旧後、元のプライマリ ゾーンに新しいスタンバイ サーバーが自動的に確立されます。 詳細については、「 強制フェールオーバー」を参照してください。

  • ゾーン: ゾーンが使用できない場合、サーバーは使用できません。 別の可用性ゾーンまたはリージョンで事前に作成した別のサーバーがある場合は、そのサーバーへのトラフィックを再ルーティングする必要があります。

ゾーンの回復

ゾーンの回復動作は、サーバーが使用する可用性ゾーンの構成によって異なります。

• ゾーン冗長: 可用性ゾーンが復旧すると、Azure Database for PostgreSQL によって、復旧されたゾーン内のスタンバイ サーバーが自動的に再構築され、現在のプライマリと同期されます。 回復されたゾーンは、スタンバイの場所として機能します。 不要な中断を回避するために、サービスはプライマリ ロールを元のゾーンに自動的に戻しません。 プライマリを元のゾーンに戻す場合は、 計画されたフェールオーバーを手動で開始 できます。

• ゾーン: ゾーンが正常な状態になった後、そのゾーンのサーバーは再び利用可能になります。 ワークロードに必要なゾーン回復手順とデータ同期は、お客様が担当します。

ゾーンエラーのテスト

ゾーンの障害をテストするためのオプションは、インスタンスが使用する可用性ゾーンの構成によって異なります。

• ゾーン冗長:強制フェールオーバーを開始することで、フェールオーバーに対するアプリケーションの回復性をテストできます。 強制フェールオーバーを使用すると、ワークロードの実行中に計画外の停止シナリオをシミュレートし、アプリケーションのダウンタイムを観察できます。 非運用環境または静かな時間にシミュレーションを実行することをお勧めします。 詳細については、「 強制フェールオーバーの開始」を参照してください。

• ゾーン単位: ゾーン全体の障害を完全にシミュレートすることはできませんが、ゾーン障害に似た形でサーバーが利用不能になる状況をシミュレートすることはできます。 詳細については、「 サーバーのコンピューティングの停止」を参照してください。

リージョン全体の障害に対する回復性

Azure Database for PostgreSQL では リージョン間の読み取りレプリカがサポートされています。このレプリカを使用して、データベースの同期されたコピーを別のリージョンに保持し、復旧を高速化できます。

サポートされているリージョンで geo 冗長バックアップを使用して、リージョン間の復旧を提供することもできます。 ただし、バックアップには通常、レプリケーションよりも多くのダウンタイムとデータ損失が伴います。 詳細については、「 バックアップと復元」を参照してください。

リージョン間の読み取りレプリカ

読み取りレプリカをデプロイして、リージョン レベルの障害からデータベースを保護できます。 各読み取りレプリカは、個別の Azure Database for PostgreSQL サーバーです。 2 番目の Azure リージョンに読み取りレプリカを配置すると、データベース サーバーはリージョン全体の問題に対する回復性を提供できます。 最大 5 つの読み取りレプリカをデプロイできます。必要に応じて、異なる Azure リージョンに配置できます。 PostgreSQL の物理レプリケーション テクノロジは、読み取りレプリカを非同期的に更新します。プライマリに遅延が発生する可能性があります。 リージョン間の読み取りレプリカは、必要に応じて読み取り専用ワークロードを提供して、グローバル分散アプリケーションの待機時間を短縮したり、プライマリ サーバーから読み取りトラフィックをオフロードしたりできます。 読み取りレプリカの機能と考慮事項の詳細については、読み取りレプリカに関する記事をご覧ください。

仮想エンドポイントは 、読み取り/書き込みエンドポイントと読み取り専用エンドポイントを提供し、レプリカの昇格時にトラフィックを自動的にリダイレクトします。これにより、フェールオーバー イベント中のダウンタイムを最小限に抑えることができます。 アプリケーションの回復性を向上させるために、リージョン間の読み取りレプリカで仮想エンドポイントを使用することを強くお勧めします。 詳細については、「 Azure Database for PostgreSQL の読み取りレプリカの仮想エンドポイント」を参照してください。

プライマリ リージョンで障害が発生した場合は、セカンダリ レプリカがプライマリになるように 昇格 をトリガーできます。 読み取りレプリカの使用方法によっては、さまざまな種類のフェールオーバーが適している場合があります。 読み取りレプリカを使用してリージョンの障害に対する回復性を提供する場合は、通常、 プライマリ サーバーへの昇格 アプローチを使用して、仮想エンドポイントを更新します。 リージョンの停止中は、 強制的な昇格を実行する必要があります。その結果、変換されていないデータに対してデータが失われる可能性があります。 プライマリ リージョンが正常である計画的なシナリオでは、データ損失を回避するために計画的な昇格を実行することを選択できます。 詳細については、「Azure Database for PostgreSQL での読み取りレプリカの昇格」を参照してください。

必要条件

• リージョンのサポート: リージョン間の読み取りレプリカは、Azure Database for PostgreSQL をサポートする任意のリージョンに作成できます。 ペアになっているリージョンAzureに限定されません。

• コンピューティング レベル: General Purpose コンピューティング レベルとメモリ最適化コンピューティング レベルでは、読み取りレプリカがサポートされます。 バースト可能レベルでは、読み取りレプリカはサポートされていません。

考慮事項

• 構成の違い: 読み取りレプリカでは、プライマリ サーバーからすべての構成設定が継承されない場合があります。 フェールオーバー後に必要な設定を構成することを計画します。 プライマリ サーバーとレプリカは 対称である必要があります。つまり、一部の設定で同じレベル、ストレージ サイズ、値を持つ必要があります。 リージョンの障害時には、強制的な昇格に対して対称サーバー要件を免除できますが、予期しない問題を回避するために、可能な限り対称的な構成を行うことをお勧めします。 詳細については、「 構成管理」を参照してください。

• レプリケーションのラグの監視: 非同期レプリケーション プロセスにはレプリケーションの遅延が必要です。これは、多くの要因によって異なる場合があります。 レプリケーションのラグが大きい場合、サーバーで問題が発生する可能性があります。 問題がエスカレートする前に問題を軽減できるように、レプリケーションのラグを監視することが重要です。 詳細については、「 レプリケーションの監視」を参照してください。

• 高可用性: 読み取りレプリカでは高可用性を有効にすることはできず、昇格されるときにも高可用性は得られません。 レプリカの昇格後に高可用性を構成するのはあなたの責任です。

考慮すべき昇格プロセスに関するその他の要因については、「 考慮事項」を参照してください。

Cost

読み取りレプリカでは、コンピューティングとストレージのコストに加えて、レプリケーションのリージョン間データ転送料金が発生します。 価格の詳細については、 Azure Database for PostgreSQL の価格 と 帯域幅の価格に関するページを参照してください。

マルチリージョンのサポートを構成する

• 読み取りレプリカを作成します。 読み取りレプリカを作成する方法については、「読み取りレプリカ の作成」を参照してください。 プライマリ サーバーが実行され、アクセス可能である限り、プライマリ サーバーの作成後にレプリカを構成できます。

  仮想エンドポイントを作成するには、「 仮想エンドポイントの作成」を参照してください。

• 読み取りレプリカを削除します。 読み取りレプリカを削除する方法については、「読み取りレプリカ の削除」を参照してください。

すべてのリージョンが正常な場合の動作

このセクションでは、サーバーが別のリージョンと仮想エンドポイントの読み取りレプリカで構成されていて、すべてのリージョンが動作している場合に想定される内容について説明します。

• リージョン間のトラフィック ルーティング: 通常の操作では、仮想エンドポイントは読み取り/書き込みエンドポイントのトラフィックをプライマリ リージョンのプライマリ サーバーに転送します。 仮想エンドポイントの読み取り専用エンドポイントも使用すると、構成したレプリカにトラフィックが送信されます。

• リージョン間のデータ レプリケーション: リージョン間の読み取りレプリカでは、非同期レプリケーションを使用して、プライマリ サーバーのパフォーマンスへの影響を最小限に抑えます。 レプリケーションのラグの量は、書き込み負荷やプライマリ サーバーとレプリカ間の待機時間など、多くの要因によって異なります。 レプリケーションの遅延は通常、少なくとも数分ですが、長くなる可能性があります。 詳細については、「 レプリケーションの監視」を参照してください。

リージョン障害時の動作

このセクションでは、サーバーが別のリージョンと仮想エンドポイントの読み取りレプリカを使用して構成されていて、プライマリ リージョンで停止が発生した場合に想定される内容について説明します。

• 検出と応答: プライマリ リージョンでの停止を検出し、読み取りレプリカを新しいプライマリ サーバーに手動で昇格させる必要があります。 リージョンの停止中は、強制的な昇格処理を実行する必要があります。その結果、複製されていないデータが失われます。

  Important

  昇格をトリガーする責任はユーザーにあります。 リージョンが障害を起こしても、Azure は読み取りレプリカを自動的に昇進させません。

  昇格を開始する詳細な手順については、「 読み取りレプリカをプライマリに切り替える」を参照してください。

• 通知： リージョンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。

• アクティブな要求: 昇格プロセスは、プライマリ リージョンへのアクティブな接続をすべて削除します。 昇格プロセスが完了したら、アプリケーションは昇格されたレプリカへの接続を再試行する必要があります。

• 予想されるデータ損失: リージョンの停止中は、強制的な昇格を実行する必要があります。その結果、変換されていないデータが完全に失われます。

  データ損失の量は、障害発生時のレプリケーションのラグによって異なります。 レプリケーションの遅延は通常、少なくとも数分ですが、長くなる可能性があります。 詳細については、「 レプリケーションの監視」を参照してください。

• 予想されるダウンタイム: 強制昇格は通常、トリガーされてから 1 ~ 3 分以内に完了します。 アプリケーションは、正しいエンドポイントに再接続する必要がある場合もあります。 仮想エンドポイントは、強制昇格プロセスの一環として更新されます。 アプリケーションは、昇格が完了した後に適切なレプリカにすばやく再接続できるように、エンドポイントの DNS レコードの生存時間 (TTL) を遵守する必要があります。

• トラフィックの再ルーティング: サーバーの仮想エンドポイントは、アプリケーション トラフィックを新しいプライマリ レプリカに自動的にリダイレクトします。

  注

  読み取りレプリカがプライマリ サーバーに昇格されると、高可用性構成は有効になりません。 高可用性構成を手動で有効にするか、独自の自動化プロセスに追加する必要があります。

リージョンの復旧

仮想エンドポイントを使用すると、プライマリ リージョンが復旧した後、古いプライマリ サーバーが読み取りレプリカとして自動的に構成されます。 別の昇格を実行して、プライマリ操作を優先プライマリ リージョンに返すことができます。

リージョン障害のテスト

読み取りレプリカの昇格手順を定期的にテストして、プロセスが有効であること、および機能が目標復旧時間 (RTO) と目標復旧時点 (RPO) の要件を満たしていることを確認します。

すべてのリージョンが正常な場合でも、読み取りレプリカをいつでもプライマリ サーバーに昇格させることができます。 テストの場合:

• 強制昇格テストを実行できます。 データが失われる可能性があるため、非運用環境でこれらのテストを実行することをお勧めします。 強制昇格テストは、リージョンの停止中に表示される動作をシミュレートするのに役立ちます。
• 計画メンテナンス、またはデータ損失を回避するテスト シナリオの場合は、代わりに計画的な昇格を使用します。 ただし、計画された昇格は、リージョンの停止中の昇格とは異なるプロセスに従うので、実際のリージョンの停止中の動作が反映されない可能性があります。

詳細な手順については、「 読み取りレプリカをプライマリに切り替える」を参照してください。

ディザスター リカバリー戦略の一環として、完全復旧訓練を定期的に実行します。 これらのドリルには、データ検証、アプリケーション機能テスト、および文書化されたロールバック手順が含まれている必要があります。

バックアップと復元

Azure Database for PostgreSQLは自動的にデータをバックアップします。 これらのバックアップは、特定の時点の回復機能を提供し、偶発的な破損やデータの削除からユーザーを保護するのに役立ちます。 Microsoftバックアップを完全に管理します。 サーバーの可用性が中断されることはありません。また、完全バックアップとトランザクション ログ バックアップの両方が含まれます。

• バックアップ ストレージ: 可用性ゾーンがあるリージョンにサーバーをデプロイすると、サーバーの高可用性構成に関係なく、サービスはゾーン冗長ストレージ (ZRS) にバックアップを格納します。 可用性ゾーンのないリージョンにデプロイされたサーバーの場合、サービスはバックアップをローカル冗長ストレージ (LRS) に格納します。

  ペアのリージョンAzureでは、サーバー作成時に geo 冗長バックアップ ストレージを構成して、リージョンの障害に対する保護を強化するために、ペアになっているAzureリージョンにバックアップをレプリケートできます。 このサービスは、バックアップを非同期的にレプリケートします。

  既定のバックアップ保有期間は 7 日間ですが、リテンション期間は最大 35 日まで延長できます。 また、手動バックアップの長期保存に最大 10 年間 Azure Backup を使用することもできます。 すべてのバックアップが暗号化されます。

• 復元： ポイントインタイム リカバリーを使用すると、バックアップ保有期間内の任意の時点にデータベースを復元できます。 復元プロセスでは、ユーザーが指定した新しいサーバー名を持つ新しいデータベース サーバーが作成されます。 新しいサーバー as-is を使用することも、そこからデータをコピーすることもできます。

  geo 冗長バックアップを復元する場合は、ペアのリージョンに新しいサーバーを作成します。

  この機能は、偶発的なデータ変更、アプリケーション エラー、またはテスト シナリオからの復旧に役立ちます。

ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。

詳細については、「 Azure Database for PostgreSQL でのバックアップと復元」を参照してください。

サービス メンテナンスに対する回復性

Azure Database for PostgreSQLは、基になるハードウェア、オペレーティング システム、データベース エンジンの修正プログラムの適用など、重要なサービス タスクを自動的に処理します。 このサービスには、計画メンテナンスの一環として、セキュリティ更新プログラム、ソフトウェア更新プログラム、マイナー バージョンのアップグレードが含まれます。

メンテナンス期間中もサーバーを確実に使用できるようにするには、次の推奨事項に従います。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。

Azure Database for PostgreSQLでは、サーバーの構成に応じて、さまざまな可用性 SLA が提供されます。

• ゾーン冗長高可用性で構成されたサーバーは、アップタイム SLA として 99.99%を提供します。
• ゾーンの高可用性で構成されたサーバーは、99.95%のアップタイム SLA を提供します。
• 高可用性なしで構成されたサーバーは、99.9%のアップタイム SLA を提供します。

関連するコンテンツ

• Azure信頼性
• Azure Database for PostgreSQL のアーキテクチャのベスト プラクティス
• Azure Database for PostgreSQL でのビジネス継続性の概要
• Azure Database for PostgreSQL での地理的災害復旧
• 回復性と回復性の原則を実装するための Terraform スクリプト