Azure SQL Database でアプリケーションの回復性を実現する
geo レプリケーションと自動フェールオーバー グループはどちらも、可用性とディザスター リカバリーを強化するために Azure SQL Database で使用されるメカニズムですが、いくつかの重要な違いがあります。
アクティブ geo レプリケーションを理解する
Azure SQL Database の可用性を向上させる方法の 1 つは、アクティブ geo レプリケーションを使用することです。 アクティブ geo レプリケーションは、同じリージョンまたは別のリージョンのサーバー上に個々のデータベースの読み取り可能なセカンダリ データベースを作成できるようにするビジネス継続性ソリューションとして設計されています。 最大 4 つのセカンダリ レプリカがサポートされ、データベースごとに構成されます。
バックグラウンドで、Azure は 可用性グループ を使用してこの機能を提供します。 アクティブ geo レプリケーションを使用すると、大規模な災害時に、プログラムまたは手動でプライマリ データベースをセカンダリ リージョンにフェールオーバーできます。
レプリケーションのパフォーマンスに影響を与える可能性のある大規模な書き込みワークロードによるレプリケーション オーバーヘッドを回避するには、プライマリと同じサービス レベルとコンピューティング サイズで geo セカンダリを構成することをお勧めします。
データベース ページにアクセスし、[データ管理] セクションで [レプリカ] を選択することで、Azure SQL Database の geo レプリケーションを手動で構成できます。
セカンダリ レプリカが作成された後、フェールオーバーを手動で開始できます。 これによりロールが切り替わり、セカンダリが新しいプライマリになって、古いプライマリが新しいセカンダリになります。
geo レプリケーションは非同期であるため、プライマリ データベースとセカンダリ データベースの間にデータの遅延が生じる可能性があります。 また、フェールオーバー後にアプリケーションの接続文字列を更新する必要があります。
サブスクリプション間 geo レプリケーションの構成
シナリオによっては、プライマリ データベースとは異なるサブスクリプションでセカンダリ レプリカを構成する必要があります。 ここでサブスクリプション間 geo レプリケーションの出番です。 この機能を使用すると、別のサブスクリプションにセカンダリ レプリカを設定できるため、柔軟性が向上し、ディザスター リカバリー オプションが強化されます。 サブスクリプション間 geo レプリケーションを使用すると、1 つのサブスクリプションで問題が発生した場合でも、データが保護され、アクセスできることが保証されます。 このセットアップは、複数のサブスクリプションを持つ組織、または堅牢なビジネス継続性計画の実装を検討している組織に役立ちます。
サブスクリプション間の geo レプリケーションを構成するために必要な手順の詳細については、サブスクリプション 間 geo レプリケーションに関するページを参照してください。
自動フェールオーバー グループを有効にする
自動フェールオーバー グループは、Azure SQL Database と Azure SQL Managed Instance の両方で使用できる可用性機能です。 自動フェールオーバー グループにより、データベースを別のリージョンにレプリケートする方法を管理し、フェールオーバーがどのように開始されるかを管理できます。 自動フェールオーバー グループに割り当てられる名前は、*.database.windows.net ドメイン内で一意である必要があります。
自動フェールオーバー グループは、リスナーを通じて AG に似た機能を提供し、読み取り/書き込みと読み取り専用の両方のアクティビティを可能にします。 この機能は、アクティブ geo レプリケーションとは少し異なります。 リスナーには 2 種類あります。1 つは読み取り/書き込みトラフィック用で、もう 1 つは読み取り専用トラフィック用です。 フェールオーバー中、DNS の更新により、クライアントは追加の情報を必要とせずにリスナー名に接続できるようになります。 読み取り/書き込みコピーを持つデータベース サーバーがプライマリであり、プライマリからトランザクションを受信するサーバーがセカンダリです。
自動フェールオーバー グループには、構成できる 2 種類のポリシーがあります。
- カスタマー マネージド (推奨) - お客様は、フェールオーバー グループ内の 1 つ以上のデータベースに影響する予期しない停止を検出したときに、フェールオーバーを手動で開始できます。 この手動フェールオーバーは、PowerShell、Azure CLI、Rest API などのコマンド ライン ツールを使用して実行できます。
- Microsoft によって管理される - プライマリ リージョンに影響を与える大規模な障害が発生している際に、Microsoft によって自動的に開始されます。 この自動フェールオーバーは、フェールオーバー ポリシーが "Microsoft による管理" に設定されている、すべての影響を受けるフェールオーバー グループに適用されます。
セカンダリがプライマリと完全に同期されていないときに計画外のフェールオーバーが強制された場合、データ損失を引き起こす可能性があります。
GracePeriodWithDataLossHours の構成では、Azure がフェール オーバーするまでの待機時間を制御します。 既定値は 1 時間です。 RPO が厳格で、データ損失をあまり許容できない場合は、値を高く設定します。 Azure がフェールオーバーするまでの待機時間は長くなりますが、このアプローチでは、セカンダリがプライマリと完全に同期する時間が長くなるため、データ損失が少なくなる可能性があります。
さらに、自動フェールオーバー グループには、プライマリ サーバーとセカンダリ サーバーの両方で同じサイズとエディションの 1 つ以上のデータベースを含めることができます。 セカンダリ サーバー上のデータベースは、"シード処理" というプロセスを通じて自動的に作成されます。データベースのサイズによっては、時間がかかる場合があります。 それに応じて計画を立て、ネットワーク速度などの要素を考慮することが重要です。
選択する方法
geo レプリケーションは、複数の読み取り可能なレプリカが必要で、手動フェールオーバーが許容されるシナリオに適しています。一方、自動フェールオーバー グループは、データベースのグループに対して自動フェールオーバーと同期レプリケーションが必要なシナリオに最適です。
次の表は、geo レプリケーションと自動フェールオーバー グループの機能と、その他の関連する詳細を比較しています。
| 機能 | geo レプリケーション | 自動フェールオーバー グループ |
|---|---|---|
| レプリカの数 | 最大 4 つのセカンダリ レプリカをサポートします。 | セカンダリ レプリカを 1 つだけサポートします |
| 構成レベル | データベースごとに構成されます。 | データベースのグループに対して構成されます |
| レプリケーションの種類 | 非同期。プライマリ データベースとセカンダリ データベースの間にデータの遅延が生じる可能性があります | 同期。セカンダリ データベースが常にプライマリ データベースと同期していることが保証されます。 |
| フェールオーバー | 手動フェールオーバーが必要です。 フェールオーバー後にアプリケーションの接続文字列を更新する必要があります | 自動および手動フェールオーバーをサポートします。フェールオーバー後に接続文字列を変更する必要はありません |
| 可読性 | 読み取り可能なセカンダリ データベースを提供します。 | 読み取り可能なセカンダリ データベースを提供し、フェールオーバーのホット スタンバイとして機能します |
| ユースケース(事例) | 複数の読み取り可能なレプリカと手動フェールオーバーが必要なシナリオに適しています | データベースのグループに対して自動フェールオーバーと同期レプリケーションが必要なシナリオに最適 |