Azure Storage Actions の信頼性
この記事では、Azure Storage Actions の信頼性サポートについて説明し、可用性ゾーンによるリージョン内の回復性と、リージョン間のディザスター リカバリーおよび事業継続の両方を取り上げます。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。
Azure Storage Actions は、複数のストレージ アカウントにまたがる数百万ものオブジェクトに対して一般的なデータ操作を実行するために使用できるサーバーレス フレームワークです。 サービス自体はリージョン単位であり、可用性ゾーンの SKU またはサポートはありません。 ただし、サービスのコントロール プレーンはゾーン冗長を自動的にサポートします。 ストレージ アカウントがゾーン冗長構成で実行されているかどうかに応じて、データ プレーンが冗長性をサポートする場合もあります。
可用性ゾーンのサポート
Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。
障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。
Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。
Azure Storage Actions サービスはリージョン単位であり、SKU や可用性ゾーンを提供しませんが、ゾーン冗長はコントロール プレーンから、条件付きでデータ プレーンから使用できます。
サービスのコントロール プレーンはゾーン冗長です。 あるリージョンでゾーンがダウンしても、コントロール プレーンは引き続き使用できます。 ゾーンダウンのシナリオ中も、タスクの定義と割り当てを引き続き管理できます。
データ プレーン (タスク割り当ての実行) は、親ストレージ アカウントからゾーンのプロパティを継承します。 障害が発生したゾーンにストレージ アカウントがデプロイされている場合、そのアカウントは使用できなくなり、お客様の観点からは、データ プランを使用できなくなります。 ストレージ アカウントがゾーン冗長である場合、アカウントは引き続き使用可能であり、サービスはアカウントに対する操作を引き続き実行します。
ゾーン ダウン エクスペリエンス
ゾーン完了シナリオでは、ストレージ アクション サービスを引き続き使用できます。 タスクの進行状況は、その実行されているストレージ アカウントの可用性ゾーンのサポートによって異なります。 ダウンしたゾーンの影響をアカウントが受けない場合、タスクは続行されます。 それ以外の場合、タスクは失敗します。
ゾーン停止の準備と復旧
ストレージ アクション サービスはゾーン単位ではありませんが、ストレージ アカウントはそうです。 ストレージ アカウントがゾーン停止の影響を受けると、アカウントに割り当てられているストレージ タスクは失敗します。 ゾーンとストレージ アカウントが使用可能になると、スケジュールされたタスクはスケジュールに従って引き続き実行されます。 タスクが 1 回実行されるように構成されている場合、状況に応じてタスクをもう一度実行するようにスケジュールする必要があります。
リージョン間のディザスター リカバリーおよび事業継続
ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。
DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。
ストレージ アクションはリージョン単位のサービスであり、同じリージョン内のアカウントに対して実行されます。 リージョンがダウンすると、ストレージ アカウントとサービスの両方もダウンします。 このサービスは、リージョンをまたがるディザスター リカバリーをサポートしていません。 別のリージョンへのストレージ アカウントのフェールオーバーをトリガーした場合、元のリージョンにフェールバックするまで、ストレージ アカウントに対してストレージ タスクを実行できません。 そのため、ストレージ アカウントを復旧できたとしても、それに対してストレージ タスクを実行することはできません。
重要
ストレージ アカウントを GRS または GZRS プライマリ リージョンとセカンダリ リージョンとの間で移行する場合、ストレージ アカウントを対象としたストレージ タスクはトリガーされないため、既存のタスクの実行はいずれも失敗する可能性があります。
停止の検出、通知、管理
サービス自体に障害が発生しても、ストレージ タスクから通知は送信されません。 ストレージ タスクの状態を確認し、サービスまたはリージョンが復旧した後にタスクを再試行することが重要です。