Azure Queue Storage は、大量のメッセージを格納および配布するためのサービスです。 Queue Storage は、一般に、作業のバックログを作成して非同期的に処理するために使われます。 疎結合アプリケーション アーキテクチャに信頼性の高いメッセージ配信を提供します。 キューの 1 つのメッセージの最大サイズは 64 KB で、1 つのキューには、ストレージ アカウントの合計容量の上限に達するまで、数百万のメッセージを格納できます。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな潜在的な障害や問題に対する Queue Storage の回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、Queue Storage サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
Note
Queue Storage は、Azure Storage プラットフォームの一部です。 Queue Storage の機能の一部は、多くの Azure Storage サービスで共通です。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境の場合:
Queue Storage リソースを含むストレージ アカウントに対してゾーン冗長ストレージ (ZRS) を有効にします。 ZRS では、プライマリ リージョン内の複数の可用性ゾーン間でデータが同期的にレプリケートされて、可用性が向上します。 可用性の向上は、可用性ゾーンの障害からストレージ アカウントを保護するのに役立ちます。
リージョンの停止に対する回復性が必要で、ストレージ アカウントのプライマリ リージョンがペアリングさている場合は、geo 冗長ストレージ (GRS) を有効にすることを検討します。 GRS は、ペアリングされたリージョンに非同期的にデータをレプリケートします。 サポートされているリージョンでは、geo ゾーン冗長ストレージ (GZRS) を使って、geo 冗長性とゾーン冗長性を組み合わせることができます。
高度なメッセージング要件については、Azure Service Bus の使用を検討してください。 Queue Storage と Service Bus の違いについては、Azure Storage キューと Service Bus キューの比較に関する記事をご覧ください。
信頼性アーキテクチャの概要
Queue Storage は、Azure Storage プラットフォーム インフラストラクチャ内の分散メッセージング サービスとして動作します。 このサービスは、キューとメッセージ データの複数のコピーを通じて冗長性を提供します。 特定の冗長性モデルは、ストレージ アカウントの構成に依存します。
ローカル冗長ストレージ (LRS) は、ストレージ アカウント内のデータを、ユーザーが選んだプライマリ リージョン内にある 1 つ以上の Azure 可用性ゾーンにレプリケートします。 優先する可用性ゾーンを選ぶことはできませんが、Azure はゾーン間で LRS アカウントを移動または拡張して、負荷分散を向上させることができます。 データがゾーン間で分散される保証はありません。 可用性ゾーンについて詳しくは、「可用性ゾーンとは」をご覧ください。
ゾーン冗長ストレージ (ZRS)、geo 冗長ストレージ (GRS)、geo ゾーン冗長ストレージ (GZRS) は、よりいっそうの保護を提供します。 この記事では、これらのオプションについて詳しく説明します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが、通常は影響を受けた要求の再試行により、一時的な障害を処理できるようになっていることが重要です。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
Queue Storage は、他のコンポーネントでの一時的な障害を処理するために、アプリケーションでよく使われます。 非同期メッセージングと Queue Storage などのサービスを使うと、アプリケーションは、メッセージを後で処理し直して、一時的な障害から復旧できます。 詳細については、「 非同期メッセージング入門」を参照してください。
Queue Storage サービス自体では、Azure Storage プラットフォームとクライアント ライブラリが提供するいくつかのメカニズムを使って、一時的な障害が自動的に処理されます。 このサービスは、インフラストラクチャの一時的な問題の間であっても回復性のあるメッセージ キュー機能を提供するように設計されています。
Queue Storage クライアント ライブラリに組み込まれている再試行ポリシーが、ネットワーク タイムアウト、サービスの一時的な利用不可 (HTTP 503)、応答のスロットリング (HTTP 429) などの一般的な一時的エラーを自動的に処理します。 アプリケーションでこれらの一時的な状況が発生すると、クライアント ライブラリはエクスポネンシャル バックオフ戦略を使って操作を自動的に再試行します。
Queue Storage を使って一時的な障害を効果的に管理するには、次の対策を取ることができます。
一時的な速度低下に対する回復性と応答性のバランスを取るために、Queue Storage クライアントで適切なタイムアウトを構成します。 通常、Azure Storage クライアント ライブラリの既定のタイムアウトは、ほとんどのシナリオに適しています。
アプリケーションでキューからのメッセージを処理するときに、サーキット ブレーカー パターンを実装します。 サーキット ブレーカー パターンにより、ダウンストリーム サービスで問題が発生した場合のカスケード エラーを防ぐことができます。
アプリケーションでメッセージを受信するときに、可視性タイムアウトを適切に使います。 可視性タイムアウトにより、アプリケーションで処理中に障害が発生した場合に、メッセージを確実に再試行できるようになります。
Azure Table Storage アーキテクチャの詳細と、回復性とスケールの高いアプリケーションを設計する方法については、 Queue Storage のパフォーマンスとスケーラビリティのチェックリストを参照してください。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
AZURE Queue Storage は、ZRS 構成を使用してデプロイされる場合、ゾーン冗長です。 LRS とは異なり、ZRS は Azure が複数の可用性ゾーン間でキュー データを同期的にレプリケートすることを保証します。 ZRS を使用すると、1 つのゾーンで障害が発生した場合でも、データへのアクセスが維持されます。 ZRS により、可用性ゾーン全体が使用できなくなった場合でも、キューにアクセスできます。 すべての書き込み操作は、完了する前に複数のゾーンで確認される必要があり、これによって厳密な整合性が保証されます。
ゾーン冗長はストレージ アカウント レベルで有効になり、そのアカウント内のすべての Queue Storage リソースに適用されます。 個々のキューを異なる冗長レベルで構成することはできません。 この設定は、ストレージ アカウント全体に適用されます。 可用性ゾーンで障害が発生すると、Azure Storage は、アプリケーションからの介入を必要とせずに、正常なゾーンに要求を自動的にルーティングします。
Requirements
- リージョンのサポート: ゾーン冗長 Azure Storage アカウントは、 可用性ゾーンをサポートする任意のリージョンにデプロイできます。
- ストレージ アカウントの種類: キュー ストレージの ZRS を有効にするには、Standard 汎用 v2 ストレージ アカウントを使用する必要があります。 Premium ストレージ アカウントでは、Queue Storage はサポートされていません。
Cost
ゾーン冗長ストレージ (ZRS) を有効にすると、レプリケーションとストレージのオーバーヘッドが増えるため、ローカル冗長ストレージ (LRS) とは異なるレートで課金されます。
価格について詳しくは、「Queue Storage の価格」をご覧ください。
可用性ゾーンのサポートを設定する
次の手順のようにして、ゾーン冗長ストレージ アカウントとキューを作成します。
ストレージ アカウントを作成し、アカウントの作成時に冗長性オプションとして ZRS、GZRS、または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) を選びます。
レプリケーションの種類を変更します。 既存のストレージ アカウントをゾーン冗長ストレージ (ZRS) に変更する方法および構成のオプションと要件については、「ストレージ アカウントがレプリケートされる方法を変更する」をご覧ください。
ゾーン冗長を無効にします。 同じ冗長性構成変更プロセスを使って、ZRS アカウントをローカル冗長ストレージ (LRS) などの非ゾーン構成に変換します。
すべてのゾーンが正常な場合の動作
このセクションでは、キュー ストレージ アカウントがゾーン冗長用に構成されていて、すべての可用性ゾーンが動作している場合に想定される内容について説明します。
ゾーン間のトラフィック ルーティング: ゾーン冗長ストレージ (ZRS) を使う Azure Storage では、複数の可用性ゾーン内のストレージ クラスター間に要求が自動的に分散されます。 トラフィックの分散はアプリケーションに対して透過的であり、クライアント側の構成は必要ありません。
ゾーン間のデータ レプリケーション: ZRS へのすべての書き込み操作は、そのリージョン内のすべての可用性ゾーンに同期的にレプリケートされます。 データをアップロードまたは変更する場合、すべての可用性ゾーンでデータが正常にレプリケートされるまで、操作は完了とは見なされません。 この同期レプリケーションにより、ゾーン障害時の強力な一貫性とデータ損失がゼロになります。
ゾーン障害時の動作
可用性ゾーンが使用できなくなると、Queue Storage は次のアクションを実行してフェールオーバー プロセスを自動的に処理します。
- 検出と応答: Microsoft は自動的にゾーンの障害を検出して復旧プロセスを開始します。 ゾーン冗長ストレージ (ZRS) アカウントに対して顧客の操作は必要ありません。ゾーンが使用できなくなった場合、Azure はドメイン ネーム システム (DNS) の再ポイントなどのネットワーク更新を実行します。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定することもできます。
アクティブな要求: 処理中の要求が復旧プロセスの間に破棄される可能性があり、再試行する必要があります。 アプリケーションでは、これらの一時的な中断を処理するための 再試行ロジックを実装 する必要があります。
予想されるデータ損失: 書き込み操作が完了する前に複数のゾーン間でデータが同期的にレプリケートされるため、ゾーンの障害時にデータ損失は発生しません。
予想されるダウンタイム: 自動復旧の間に、トラフィックが正常なゾーンにリダイレクトされるため、若干のダウンタイム (通常は数秒) が発生する可能性があります。 ZRS 用のアプリケーションを設計するときは、エクスポネンシャル バックオフを使用する再試行ポリシーの実装など、一時的な障害処理の手法に従ってください。
- トラフィックの再ルーティング。 ゾーンが使用できなくなった場合、Azure はドメイン ネーム システム (DNS) の再指定などのネットワーク更新を実行し、要求が残りの正常な可用性ゾーンに送信されるようにします。 サービスは、顧客の介入を必要とせず、存続ゾーンを使用して完全な機能を維持します。
ゾーンの回復
障害が発生した可用性ゾーンが復旧すると、Azure Storage は、すべての可用性ゾーンで通常の操作を自動的に復元します。 サービスは、停止期間中に発生したすべての操作を同期して、データの整合性を自動的に確保します。
ゾーンエラーのテスト
ゾーン冗長ストレージ (ZRS) を使うと、Azure Storage によってレプリケーション、トラフィック ルーティング、ゾーンダウンの応答が自動的に管理されます。 この機能は完全に管理されているため、可用性ゾーンの障害プロセスを開始または検証する必要はありません。
リージョン全体の障害に対する回復性
Azure Blob Storage、Azure Files、Azure Table Storage、Azure Queue Storage などの Azure Storage には、さまざまな要件に合わせて geo 冗長性とフェールオーバーの広範な機能が用意されています。
Important
geo 冗長ストレージ (GRS) は、Azure のペアリングされたリージョン内でのみ機能します。 ストレージ アカウントのリージョンがペアになっていない場合は、 回復性のためにカスタムマルチリージョン ソリューションを使用することを検討してください。
ペアになっているリージョンの GRS
ペアリングされたリージョンでは、Azure Storage によって複数の種類の GRS が提供されます。 どの種類の GRS を使っても、セカンダリ リージョン内のデータは常にローカル冗長ストレージ (LRS) を使ってレプリケートされます。 この方法により、セカンダリ リージョン内のハードウェア障害に対する保護が提供されます。
GRS では、プライマリ リージョンで障害が発生した場合に、Azure のペアリングされたリージョンへの計画的と計画外のフェールオーバーがサポートされます。 GRS は、プライマリ リージョンからペアのリージョンにデータを非同期的にレプリケートします。
geo ゾーン冗長ストレージ (GZRS) は、プライマリ リージョンの複数の可用性ゾーン内のデータを、ペアリングされたリージョンにレプリケートします。
- 読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) は geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) を拡張し、セカンダリ エンドポイントへの読み取りアクセスという利点が追加されます。 これらのオプションは、高可用性のビジネス クリティカルなアプリケーション向けに設計されたアプリケーションに最適です。 万一プライマリ エンドポイントで障害が発生した場合、セカンダリ リージョンへの読み取りアクセス用に構成されたアプリケーションは引き続き動作できます。
フェールオーバーの種類
Azure Storage では、さまざまなシナリオに対して 3 種類のフェールオーバーがサポートされています。
カスタマーマネージド計画外フェールオーバー: プライマリ リージョンでリージョン全体のストレージ障害が発生した場合、お客様が復旧を開始する責任があります。
カスタマー マネージドの計画されたフェールオーバー: ソリューションの別の部分でプライマリ リージョンに障害が発生し、ソリューション全体をセカンダリ リージョンに切り替える必要がある場合は、復旧を開始する必要があります。 プライマリ リージョンでストレージが引き続き動作するが、コンプライアンスと監査の要件を確保するために設計されたディザスター リカバリー訓練など、ソリューション全体をセカンダリ リージョンにフェールオーバーする必要がある場合は、計画されたフェールオーバーを使用します。
Microsoft マネージド フェールオーバー: 例外的な状況では、Microsoft がリージョン内のすべての geo 冗長ストレージ (GRS) アカウントのフェールオーバーを開始する場合があります。 ただし、Microsoft が管理するフェールオーバーは最後の手段であり、長期間の停止後にのみ実行される予定です。 Microsoft が管理するフェールオーバーに依存しないでください。
GRS アカウントでは、これらのフェールオーバーの種類のいずれでも使用できます。 フェールオーバーの種類を事前に使用するために、ストレージ アカウントを事前に構成する必要はありません。
Requirements
リージョンのサポート: Azure Storage geo 冗長構成では、セカンダリ リージョンのレプリケーションに Azure のペアになっている リージョンが使用されます。 セカンダリ リージョンは、プライマリ リージョンの選択に基づいて自動的に決定され、カスタマイズすることはできません。 Azure のペアになっているリージョンの完全な一覧については、 Azure リージョンの一覧を参照してください。
ストレージ アカウントのリージョンがペアになっていない場合は、 回復性のためにカスタムマルチリージョン ソリューションを使用することを検討してください。
- ストレージ アカウントの種類: geo 冗長ストレージ (GRS) と顧客が開始したフェールオーバーとフェールバックは、汎用 v2 Azure Storage アカウントをサポートするすべての Azure ペア リージョン で使用できます。
Considerations
複数リージョンの Queue Storage を実装するときは、次の重要な要素を考慮してください。
非同期レプリケーションの待ち時間: セカンダリ リージョンへのデータ レプリケーションは非同期です。つまり、データがプライマリ リージョンに書き込まれるときと、セカンダリ リージョンで使用できるようになるまでの間に時間差があります。 この時間差のため、最近のデータがレプリケートされる前にプライマリ リージョンで障害が発生した場合、データが失われる可能性があります。 データ損失は、回復ポイントの目標 (RPO) によって測定されます。 レプリケーションの時間差は 15 分未満と予想されますが、この時間は推定であり、保証されません。
最終同期時刻プロパティを調べて、ストレージ アカウントで計画外フェールオーバーが発生した場合に失われる可能性があるデータの量を把握できます。
セカンダリ リージョンのアクセス: geo 冗長ストレージ (GRS) と geo ゾーン冗長ストレージ (GZRS) の構成では、フェールオーバーが発生するまで、セカンダリ リージョンに読み取りアクセスすることはできません。
読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) の構成では、通常の操作中にセカンダリ リージョンに読み取りアクセスできますが、非同期レプリケーションの待ち時間のため、少し古いデータが返される可能性があります。
- 機能の制限: geo 冗長ストレージ (GRS) またはカスタマーマネージド フェールオーバーを使うと、Azure Storage の一部の機能がサポートされないか、制限されます。 geo 冗長を実装する前に、機能の互換性を確認してください。
Cost
複数リージョンの Azure ストレージ アカウント構成では、リージョン間のレプリケーションとセカンダリ リージョンでのストレージに対して追加のコストが発生します。 Azure リージョン間のデータ転送は、標準のリージョン間帯域幅レートに基づいて課金されます。
価格について詳しくは、「Queue Storage の価格」をご覧ください。
複数リージョンのサポートを構成する
- 新しい geo 冗長ストレージ (GRS) アカウントを作成します。 GRS アカウントの作成については、ストレージ アカウントの作成に関する記事をご覧ください。アカウントの作成の間に、GRS、読み取りアクセス geo 冗長ストレージ (RA-GRS)、geo ゾーン冗長ストレージ (GZRS)、または読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) を選びます。
既存のストレージ アカウントで geo 冗長を有効にします。 既存のストレージ アカウントを geo 冗長ストレージ (GRS) に変換するには、「 ストレージ アカウントのレプリケート方法を変更する」を参照してください。
Warning
アカウントが geo 冗長として再構成された後、新しいプライマリ リージョンの既存データが新しいセカンダリ リージョンに完全にコピーされるまで、かなりの時間がかかる場合があります。
大きなデータ損失を防ぐには、計画外フェールオーバーを始める前に、最終同期時刻プロパティの値を確認します。 データ損失の可能性を評価するには、最終同期時刻と、そのデータが新しいプライマリ リージョンに最後に書き込まれた時刻を比べます。
geo 冗長を無効にします。 同じ冗長構成変更プロセスを使って、GRS アカウントをローカル冗長ストレージ (LRS) やゾーン冗長ストレージ (ZRS) などの単一リージョン構成に戻します。
すべてのリージョンが正常な場合の動作
このセクションでは、ストレージ アカウントが geo 冗長用に構成されていて、すべてのリージョンが運用されている場合に想定される内容について説明します。
リージョン間のトラフィック ルーティング: Azure Storage では、すべての書き込み操作とほとんどの読み取り操作がプライマリ リージョンに転送されるアクティブ/パッシブ アプローチが使われます。
読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) 構成の場合、アプリケーションは必要に応じてセカンダリ エンドポイントにアクセスしてセカンダリ リージョンから読み取ることができます。 この方法ではアプリケーションを明示的に構成する必要があり、自動的には行われません。 また、非同期レプリケーションのラグにより、セカンダリ リージョンのデータが少し古くなっている可能性があります。
リージョン間のデータ レプリケーション: 書き込み操作は、次の構成済みの冗長性の種類を使って、最初にプライマリ リージョンにコミットされます。
- geo 冗長ストレージ (GRS) と RA-GRS の場合はローカル冗長ストレージ (LRS)
- geo ゾーン冗長ストレージ (GZRS) と RA-GZRS の場合はゾーン冗長ストレージ (ZRS)
プライマリ リージョンで正常に完了した後、データは LRS を使って格納されるセカンダリ リージョンに非同期的にレプリケートされます。
リージョン間レプリケーションの非同期的な性質は、通常、データがプライマリ リージョンに書き込まれてからセカンダリ リージョンで使用できるようになるまでに遅延時間があることを意味します。 レプリケーション時間は、最終同期時刻プロパティを使って監視できます。
リージョン障害時の動作
このセクションでは、ストレージ アカウントが geo 冗長用に構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
カスタマーマネージド フェールオーバー (計画外): プライマリ リージョンのストレージが使用できない場合は、計画外フェールオーバーを使います。
検出と応答: 万が一、プライマリ リージョンでストレージ アカウントが使用できない場合は、カスタマー マネージドの計画外フェールオーバーの開始を検討できます。 この決定を行うには、次の要因を考慮してください。
プライマリ リージョンのストレージ アカウントへのアクセスに関する問題が Azure Resource Health で示されるかどうか
別のリージョンへのフェールオーバーを実行するよう Microsoft が推奨するかどうか
Warning
計画外のフェールオーバーでは、 データが失われる可能性があります。 カスタマーマネージド フェールオーバーを始める前に、サービスの復元によってデータ損失のリスクが正当化されるかどうかを判断します。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
アクティブな要求: フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。 アクティブな要求はすべて削除される可能性があり、クライアント アプリケーションはフェールオーバーの完了後に再試行する必要があります。
予想されるデータ損失: 非同期レプリケーションの遅延により、最近の書き込みがレプリケートされない可能性があるため、計画外フェールオーバーでは一般にデータ損失が発生します。 最終同期時刻プロパティを調べて、計画外フェールオーバーの間に失われる可能性があるデータの量を把握できます。 予想されるデータ損失は、多くの場合、目標復旧ポイント (RPO) と呼ばれます。 通常、RPO は 15 分未満であると予想できますが、その時間は保証されません。
予想されるダウンタイム: 予想されるダウンタイムの量は、多くの場合、目標復旧時間 (RTO) と呼ばれます。 顧客が管理するフェールオーバーは、通常、アカウントのサイズと複雑さに応じて 60 分以内に完了します。
トラフィックの再ルーティング: フェールオーバーが完了すると、アプリケーションを再構成する必要がないように、Azure によってストレージ アカウント エンドポイントが自動的に更新されます。 アプリケーションがドメイン ネーム システム (DNS) のエントリをキャッシュに保持している場合、アプリケーションで新しいプライマリ リージョンにトラフィックを確実に送信するため、キャッシュのクリアが必要になる場合があります。
フェールオーバー後の構成: 計画外フェールオーバーが完了した後、フェールオーバー先のリージョンのストレージ アカウントではローカル冗長ストレージ (LRS) 層が使われます。 それを再び geo レプリケートする必要がある場合は、geo 冗長ストレージ (GRS) をもう一度有効にして、データが新しいセカンダリ リージョンにレプリケートされるのを待つ必要があります。
カスタマーマネージド フェールオーバーを始める方法について詳しくは、「カスタマーマネージド (計画外) フェールオーバーのしくみ」と「ストレージ アカウントのフェールオーバーを開始する」をご覧ください。
カスタマーマネージド フェールオーバー (計画的): プライマリ リージョンのストレージは動作しているものの、別の理由でソリューション全体をセカンダリ リージョンにフェールオーバーする必要がある場合は、計画フェールオーバーを使います。 たとえば、別の Azure サービスで問題が発生している可能性があり、ソリューション全体にセカンダリ リージョンを使用するように切り替える必要があります。 または、計画されたフェールオーバーを使用して、コンプライアンスと監査の目的でディザスター リカバリー (DR) 訓練を実施することもできます。
検出と応答: フェールオーバーを決定する責任があります。 通常、ストレージ アカウントが正常であっても、リージョン間でフェールオーバーする必要がある場合は、この決定を行います。 たとえば、プライマリ リージョンで復旧できない別のアプリケーション コンポーネントが大幅に停止した場合にフェールオーバーをトリガーできます。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
アクティブな要求: フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。 アクティブな要求はすべて削除される可能性があり、クライアント アプリケーションはフェールオーバーの完了後に再試行する必要があります。
予想されるデータ損失: フェールオーバー プロセスは、すべてのデータが同期された後にのみ完了し、RPO が 0 になるため、データ損失は発生しません。
予想されるダウンタイム: 通常、フェールオーバーは 60 分以内に完了します。つまり、アカウントのサイズと複雑さに応じて、予想される RTO は 60 分です。 フェールオーバー プロセス中に、プライマリとセカンダリの両方のストレージ アカウント エンドポイントが読み取りと書き込みの両方で一時的に使用できなくなります。
トラフィックの再ルーティング: フェールオーバーが完了すると、アプリケーションを再構成する必要がないように、Azure によってストレージ アカウント エンドポイントが自動的に更新されます。 アプリケーションが DNS のエントリをキャッシュに保持している場合、アプリケーションで新しいプライマリ リージョンにトラフィックを確実に送信するため、キャッシュのクリアが必要になる場合があります。
フェールオーバー後の構成: 計画されたフェールオーバーが完了した後も、移行先リージョンのストレージ アカウントは引き続き geo レプリケートされ、GRS レベルに残ります。
カスタマーマネージド フェールオーバーを始める方法について詳しくは、カスタマーマネージド (計画的) フェールオーバーのしくみに関する記事と「ストレージ アカウントのフェールオーバーを開始する」をご覧ください。
Microsoft マネージド フェールオーバー: プライマリ リージョンが永続的に回復不能であると Microsoft が判断する重大な災害が発生したまれな場合は、セカンダリ リージョンへの自動フェールオーバーが開始される可能性があります。 Microsoft はプロセス全体を処理し、顧客のアクションは必要ありません。 フェールオーバーが発生するまでの経過時間は、障害の重大度と状況の評価に必要な時間によって異なります。
通知: リージョンが停止しても、Microsoft から自動的に通知されることはありません。 しかし：
Azure Resource Health を使用して個々のリソースの正常性を監視したり、Resource Health アラートを設定して問題を通知することができます。
Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定できます。
Important
カスタマー マネージド フェールオーバー オプションを使用して、DR プランを開発、テスト、実装します。 Microsoft マネージド フェールオーバーに頼らないでください。これが使われる可能性があるのは、極端な状況のみです。 Microsoft マネージド フェールオーバーは、リージョン全体に対して開始される可能性があります。 個々のストレージ アカウント、サブスクリプション、または顧客に対して開始することはできません。 フェールオーバーは、Azure サービスごとに異なる時間に発生する可能性があります。 カスタマーマネージド フェールオーバーを使うことをお勧めします。
リージョンの復旧
フェールバック プロセスは、Microsoft マネージド フェールオーバーとカスタマーマネージド フェールオーバーのシナリオで大きく異なります。
カスタマーマネージド フェールオーバー (計画外): 計画外フェールオーバーの後では、ストレージ アカウントはローカル冗長ストレージ (LRS) で構成されます。 フェールバックするには、geo 冗長ストレージ (GRS) の関係を確立し直して、データがレプリケートされるのを待つ必要があります。
カスタマーマネージド フェールオーバー (計画的): 計画フェールオーバーの後では、ストレージ アカウントは引き続き geo レプリケートされます。 別のカスタマーマネージド フェールオーバーを始めて、元のプライマリ リージョンにフェールバックできます。 同じフェールオーバーに関する考慮事項が適用されます。
Microsoft マネージド フェールオーバー: Microsoft がフェールオーバーを開始するのは、おそらくプライマリ リージョンで重大な災害が発生した場合であり、プライマリ リージョンを復旧できない可能性があります。 タイムラインや復旧計画は、リージョンの災害と復旧作業の程度によって異なります。 詳細については、Azure Service Health 通信を監視する必要があります。
リージョン障害のテスト
リージョンの障害をシミュレートして、ディザスター リカバリー手順をテストできます。
計画フェールオーバーのテスト: geo 冗長ストレージ (GRS) アカウントの場合は、メンテナンス期間中に計画フェールオーバー操作を実行して、フェールオーバーとフェールバックの完全なプロセスをテストできます。 計画フェールオーバーではデータの損失は必要ありませんが、フェールオーバーとフェールバックの両方でダウンタイムが発生します。
セカンダリ エンドポイントのテスト: 読み取りアクセス geo 冗長ストレージ (RA-GRS) と読み取りアクセス geo ゾーン冗長ストレージ (RA-GZRS) 構成の場合は、セカンダリ エンドポイントに対する読み取り操作を定期的にテストして、アプリケーションがセカンダリ リージョンからデータを正常に読み取れることを確認します。
回復性のためのカスタム マルチリージョン ソリューション
次の理由により、Azure Storage のリージョン間フェールオーバー機能が不適切な場合があります。
ストレージ アカウントがペアになっていないリージョンにあります。
ビジネスアップタイムの目標は、組み込みのフェールオーバー オプションによって提供される復旧時間やデータ損失によって満たされません。
プライマリ リージョンのペアではないリージョンにフェールオーバーする必要があります。
Azure リージョン間でアクティブ/アクティブ構成が必要です。
このセクションでは、考慮すべきいくつかのアプローチの概要について説明します。 Azure Storage のマルチリージョン デプロイ トポロジの包括的な概要については、この記事の範囲外です。
Note
複数リージョンの要件が高度な場合は、代わりに Service Bus を使うことを検討します。これには、ペアリングされていないリージョンのサポートが含まれます。
リージョンごとに個別のストレージ アカウントを使って、複数のリージョンに Azure Storage をデプロイできます。 この方法では、リージョンを柔軟に選択し、ペアリングされていないリージョンを使い、レプリケーションのタイミングとデータの整合性をより細かく制御することができます。 リージョンをまたいで複数のストレージ アカウントを実装する場合は、リージョン間のデータ レプリケーションを構成し、負荷分散とフェールオーバーのポリシーを実装して、リージョン間のデータの整合性を確保する必要があります。
この方法では、メッセージの配布を管理し、さまざまなストレージ アカウント内のキュー間のデータ同期を処理し、カスタム フェールオーバー ロジックを実装する必要があります。
バックアップと復元
Queue Storage には、ポイントインタイム リストア (PITR) のような従来のバックアップ機能はありません。 これは、キューは長期的なデータの永続化ではなく、一時的なメッセージの格納用に設計されているためです。 通常、メッセージは、通常のアプリケーション操作中に処理され、キューから削除されます。
組み込みの冗長性オプションでは対応できないメッセージの持続性が必要なシナリオでは、Blob Storage や Azure SQL Database などの永続的なデータ ストアに、アプリケーション レベルで独自のメッセージ ログまたは永続化を実装することを検討してください。 この方法では、一時的なメッセージ バッファリングと処理調整の目的で Queue Storage を使用しながらメッセージ履歴を維持できます。
サービス水準合意書
Azure Storage のサービス レベル アグリーメント (SLA) では、サービスの予想される可用性と、その可用性の期待を達成するために満たす必要がある条件が記述されています。 適用される可用性 SLA は、使用するストレージ層とレプリケーションの種類によって異なります。 詳しくは、「オンライン サービスのサービス レベル アグリーメント (SLA)」をご覧ください。