Azure のゾーナル サービスとゾーン冗長サービス: アーキテクチャ選択の考え方
By Mirko Peters ·
Azure におけるゾーナル サービスとゾーン冗長サービスの違いを解説します。クラウド アーキテクチャに適した回復性モデルの選び方を紹介します。
Automatically translated with AI from the original post. Read the English original

Microsoft Azure で高可用性アーキテクチャを設計する際には、ゾーナル サービスとゾーン冗長サービスの違いを理解することが重要です。本記事では、Azure が可用性ゾーン間でワークロードをどのように分散するのか、運用管理の負荷の違い、本番環境に適した構成の選び方を解説します。
重要なポイント
- ゾーン冗長サービスは、複数の可用性ゾーンにデータとワークロードを自動的に複製し、障害が発生してもシームレスに対応します。
- ゾーナル サービスは、リソースを特定の 1 つのゾーンに固定します。通信頻度の高いワークロードに対して、最大のパフォーマンスと分離性を提供します。
- ゾーナルとゾーン冗長のどちらを選ぶかによって、フェイルオーバーを Azure が管理するか、自分で構築する必要があるかが決まります。
- すべての Azure サービスが両方のモデルをサポートしているわけではありません。手戻りの大きいアーキテクチャ変更を避けるため、構築前にドキュメントを確認することが重要です。
Azure のデプロイ モデルの理解
複数のデータセンター群を持つリージョンでリソースをプロビジョニングすると、アプリケーションの稼働時間に直接影響するアーキテクチャ上の選択肢に直面します。クラウド初心者の中には、ゾーンがあるリージョンにアプリをデプロイするだけで回復性が保証されると考える人も少なくありません。実際には、構成を行わない限り、Azure はリソースを自動的に分散配置しません。ここで、ゾーナル デプロイとゾーン冗長デプロイという中心的な設計上の違いが問題になります。
堅牢なクラウド環境を構築するには、複数ゾーンにまたがる複製をクラウド プラットフォームに任せるのか、仮想マシンやデータベースの物理的な配置を細かく制御するのかを決める必要があります。設計の初期段階で誤った選択をすると、ハードウェア障害やメンテナンス イベントの際に予期しないダウンタイムが発生するおそれがあります。
ゾーン冗長サービス: プラットフォームが管理する回復性
ゾーン冗長サービスは、運用上の負担を利用者から取り除くように設計されています。ゾーン冗長ストレージなどのゾーン冗長リソースをデプロイすると、Azure はデータを自動的にコピーし、ワークロードを複数の可用性ゾーンに同時に分散します。
このモデルでは、プラットフォームが各ゾーンの正常性を監視し、フェイルオーバーを自動的に処理します。ある可用性ゾーンで停電、冷却の問題、予期しないネットワーク障害が発生しても、利用者は残りの正常なゾーンにあるデータの複製に対して読み取りと書き込みを続けられます。カスタムのフェイルオーバー ロジックを作成したり、ゾーン間のデータ同期を自分で調整したりする必要はありません。ほとんどの本番ワークロードでは、まずゾーン冗長のオプションを選ぶことが Microsoft のベスト プラクティスとして推奨されています。
ゾーナル サービス: 配置の精密な制御
ゾーナル サービスは、これとまったく逆の方法で動作します。Azure に分散を任せるのではなく、特定の可用性ゾーンを明示的に選択すると、リソースはそのゾーンだけに配置されます。この構成は、他のゾーンで発生した障害から完全に分離される環境を提供し、機密性が高い、または密結合のアプリケーションにとって最適な選択になる場合があります。
たとえば、単一の仮想マシンやパブリック IP アドレスは、多くの場合ゾーン リソースとしてデプロイされます。これらは配置したゾーンに正確に存在します。この近接性により、データを頻繁にやり取りするチャティーなワークロードのレイテンシを抑えられる場合があります。ただし、トレードオフは明確です。その特定のゾーンで障害が発生すると、リソースも一緒にオフラインになります。復旧計画を実行するか、ワークロードを別のゾーンに移行する作業は、お客様の責任になります。
ワークロードに適したアーキテクチャの選択
ゾーン リソースとゾーン冗長構成のどちらを選ぶかは、目標復旧時点(RPO)と目標復旧時間(RTO)に大きく左右されます。想定外の停止が許されないミッションクリティカルなシステムでは、ゾーン冗長サービスとロード バランサーを組み合わせ、障害のあるインフラストラクチャからトラフィックを即座に切り離せるようにすべきです。
一方で、低レイテンシーの特殊なネットワークを必要とするワークロードを運用している場合や、アプリケーション層で独自のクラスタリング ソフトウェアを管理している場合は、明示的なゾーン リソースをデプロイすることで、必要な予測可能なパフォーマンスを確保できます。プロビジョニングの前に、必ず Azure の公式サービス ドキュメントを確認してください。デプロイ後にゾーン リソースからゾーン冗長モデルへ移行すると、不要な手間と複雑さが生じる可能性があるためです。
まとめ
Azure の耐障害性オプションを検討する際は、リージョンの選択だけでなく、個々のサービスがデータのレプリケーションとフェイルオーバーをどのように処理するかを確認することが重要です。プラットフォームが管理するゾーン冗長性を選ぶ場合でも、ゾーンを指定して配置する場合でも、アーキテクチャを組織の稼働時間要件に合わせることが、長期的なクラウド活用の成功に欠かせません。リージョン、可用性セット、SLA、クラウドの耐障害性戦略について包括的に解説したエピソードは、エピソード全編をお聴きいただき、Microsoft クラウド エコシステムに関する毎日のインサイトを得るためにポッドキャストを購読してください。
よくある質問
ゾーン リソースとゾーン冗長サービスの主な違いは何ですか?
ゾーン サービスは、選択した特定の単一の可用性ゾーンにリソースをデプロイします。一方、ゾーン冗長サービスは、Azure が管理する複数の可用性ゾーンにリソースを自動的に分散してレプリケートします。
ゾーン redundant ではなくゾーン サービスを選ぶのはなぜですか?
非常に頻繁にやり取りするワークロードや低レイテンシーのアプリケーションでは、ゾーン サービスを選ぶことがあります。コンポーネントを単一のデータセンター内に密に配置すると、ゾーンをまたぐネットワーク遅延を排除できるためです。
ゾーン全体に障害が発生した場合、Azure はゾーン サービスを自動的にフェイルオーバーしますか?
いいえ。ゾーン サービスの場合、リソースが配置されている特定のゾーンで障害が発生すると、リソースも一緒にダウンします。フェイルオーバーや復旧の処理は、手動で対応する必要があります。
すべての Azure サービスは、ゾーン リソースとゾーン冗長の両方の構成で利用できますか?
いいえ。サービスによってサポートされるデプロイ モデルは異なります。リージョン単位で提供されるサービスもあれば、ゾーン リソースとゾーン冗長デプロイのどちらかを明示的に選択できるサービスもあります。