Azure Database for PostgreSQL - フレキシブル サーバーの geo レプリケーション
適用対象: 
Azure Database for PostgreSQL - フレキシブル サーバー
読み取りレプリカは、プライマリ サーバーと同じリージョン、または別の地理的リージョンに作成できます。 geo レプリケーションは、ディザスター リカバリー計画や、データをユーザーの所在地の近くに配置するなどのシナリオに役立ちます。
任意の Azure Database for PostgreSQL フレキシブル サーバー リージョンにプライマリ サーバーを作成できます。 プライマリ サーバーは、Azure Database for PostgreSQL フレキシブル サーバーをサポートする Azure の任意のグローバル リージョンにもレプリカを持つことができます。 さらに、特別なリージョン Azure Government と 21Vianet によって運営される Microsoft Azure もサポートされています。 現在サポートされている特別なリージョンは次のとおりです。
Azure Government リージョン:
- US Gov アリゾナ
- US Gov テキサス
- US Gov バージニア州
21Vianet によって運営される Microsoft Azure のリージョン:
- 中国北部 3
- 中国東部 3
- 中国北部 2
- 中国東部 2
ディザスター リカバリーのためにはペアのリージョン
サポートされている任意のリージョンでレプリカを作成することは可能ですが、特にディザスター リカバリーの目的で設計する場合は、ペアになっているリージョンのレプリカを選択すると顕著な利点があります。
リージョン復旧のシーケンス: 地理的な停止では、ペアになっているすべてのセットの 1 つのリージョンの復旧が優先され、ペアになっているリージョンのアプリケーションの復旧が常に迅速化されます。
順次更新: ペアになっているリージョンの更新は時間的にずらされているので、更新に関連する問題によるダウンタイムのリスクが最小限に抑えられます。
物理的分離: ペアのリージョンのデータ センター間では、最小距離 300 マイルが維持され、重大なイベントによる同時停止のリスクを軽減します。
データ所在地: いくつかの例外の除いて、ペア セット内のリージョンは同じ地域内に存在し、データ所在地の要件を満たします。
パフォーマンス: ペアになっているリージョンでは、通常、ネットワーク待機時間が短く、データのアクセシビリティとユーザー エクスペリエンスが向上しますが、常に待機時間が最も低い短いリージョンであるとは限りません。 ディザスター リカバリーを優先するのではなく、ユーザーにより近い場所でデータを提供することが主な目的である場合は、使用可能なすべてのリージョンについて待機時間を評価することが重要です。 場合によっては、ペアになっていないリージョンが最も短い待機時間を示すことがあります。 包括的に把握するために、Azure のラウンドトリップ待機時間の数値を参照して、情報に基づいた選択を行うことができます。
ペアになっているリージョンの利点の詳細については、リージョン間レプリケーションに関する Azure のドキュメントを参照してください。
リージョンの障害と復旧
さまざまなリージョンにある Azure の施設は、信頼性が高くなるように設計されています。 ただし、まれな状況では、ネットワーク障害から自然災害などの深刻なシナリオに至るまでの理由により、リージョン全体にアクセスできなくなる可能性があります。 Azure の機能を使用すると、複数のリージョンに分散されたアプリケーションを作成できるため、1 つのリージョンの障害が他のリージョンに影響を与えないようにすることができます。
リージョンの災害への備え
潜在的なリージョンの災害に備えることは、アプリケーションとサービスの運用が中断されないようにするために不可欠です。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスの堅牢なコンティンジェンシー計画を検討する場合の、主な手順と考慮事項を次に示します。
- geo レプリケートされた読み取りレプリカを確立する: プライマリとは別のリージョンに読み取りレプリカを設定することが不可欠です。 これにより、プライマリ リージョンで障害が発生した場合の継続性が確保されます。
- サーバーの対称性を確保する: リージョンの障害に対処するには、"プライマリ サーバーへの昇格" アクションが最も推奨されますが、これにはサーバーの対称性の要件が伴います。 つまり、プライマリとレプリカのサーバーの両方に、特定の設定の同じ構成が必要です。 このアクションを使用すると、次の利点があります。
- 仮想エンドポイントを使用する場合は、アプリケーション接続文字列を変更する必要はありません。
- 影響を受けたリージョンがオンラインに戻ると、元のプライマリ サーバーがその機能を (新しいレプリカ ロールで) 自動的に再開し、シームレスな復旧プロセスが実現します。
- 仮想エンドポイントを設定する: 仮想エンドポイントを使用すると、障害が発生した場合にアプリケーションを別のリージョンにスムーズに移行できます。 これにより、アプリケーションの接続文字列を変更する必要がなくなります。
- 読み取りレプリカを構成する: プライマリ サーバーのすべての設定が読み取りレプリカにレプリケートされるわけではありません。 必要なすべての構成と機能 (PgBouncer など) が読み取りレプリカに適切に設定されるようにすることが重要です。 詳細については、「構成管理」のセクションを参照してください。
- 高可用性 (HA) の準備: 高可用性が必要なセットアップの場合、昇格されたレプリカでは自動的に有効になりません。 昇格後にアクティブにする準備をしてください。 ダウンタイムを最小限に抑えるために、この手順を自動化することを検討してください。
- 定期的なテスト: リージョンの障害シナリオを定期的にシミュレートして、既存のしきい値、ターゲット、構成を検証します。 これらのテスト シナリオで、アプリケーションが期待どおりに応答することを確認してください。
- Azure の一般的なガイダンスに従う: Azure では、信頼性と災害への備えに関する包括的なガイダンスを用意しています。 これらのリソースを参照し、ベスト プラクティスを準備計画に統合することは非常に有益です。
リージョンの災害に対して積極的に、事前に準備することで、アプリケーションとデータの回復性と信頼性を確保できます。
停止が SLA に影響を与える場合
アプリケーションのサービス レベル アグリーメント (SLA) を脅かす、特定のリージョンでの Azure Database for PostgreSQL フレキシブル サーバーの長時間の停止が発生した場合は、以下で説明するいずれのアクションもサービス主導型ではない点に注意してください。 どちらにもユーザーの介入が必要です。 プロセス全体を可能な限り自動化し、堅牢な監視を行うことがベスト プラクティスとなります。 停止中に提供される情報の詳細については、「サービス停止」のページを参照してください。 リージョン ダウンのシナリオでは強制昇格のみが可能です。つまり、データ損失の量は、レプリカとプライマリの間の現在のラグとほぼ同じです。 そのため、ラグを監視することが重要です。 次の手順を検討してください。
プライマリ サーバーへの昇格
このオプションでは、仮想エンドポイントが構成されている場合、アプリケーション内の接続文字列を更新する必要はありません。 アクティブにすると、ライター エンドポイントは別のリージョンの新しいプライマリに再ポイントされ、Azure portal の [レプリケーション状態] 列に "再構成" と表示されます。 影響を受けるリージョンが復元されると、以前のプライマリ サーバーは自動的に再開されますが、レプリカ ロールになります。
独立したサーバーに昇格し、レプリケーションから削除する
その場合、これが唯一の実行可能なオプションです。 サーバーを昇格したら、アプリケーションの接続文字列を更新する必要があります。 元のリージョンが復元されると、古いプライマリが再びアクティブになる可能性があります。 不要なコストが発生しないように、必ず削除してください。 前のトポロジを維持する場合は、読み取りレプリカを再作成してください。