Azureのサービス停止を防ぐ設計|Azureの障害を防ぐ設計

最終更新日:2026年8月10日

この記事でわかること

はじめに

項目 Microsoft Azure AWS Google Cloud
シェア(国内) 約30% 約35% 約15%
強み Microsoft製品連携 サービス数・実績 データ分析・AI
無料枠 12ヶ月無料 12ヶ月無料 常時無料枠あり
主な資格 AZ-900 / AZ-104 CLF / SAA ACE / PCA

今や企業や団体に問わず個人でも利用されているAzure。今回はそんなAzureなどのクラウドサービスを使用して障害発生などでサービスが停止しないシステムを設計するにはどうすればいいのかを調べてみました。

クラウドについて

オンプレミス環境とクラウドの違いをしっかり押さえて、Azureなどのクラウドについて学んでいきましょう。障害の観点からいうと、オンプレミス環境でデータセンターが丸ごと運用不能になってしまうことは基本的にはありません。一方、クラウドではリージョン丸ごとの障害がAzureのみならずAWSなどのベンダーでも発生しています。AWSについては2019年の8月に約10時間に及び東京リージョンにてEC2やRDSへ接続できないといった障害が発生し、AWS上に構築されていた決済サービスやSNS、ECサイトなどが利用できなくなるなどの様々な被害が及びました。ちなみに原因は冷房をコントロールする制御システムを中心とする多重障害であり、サーバーの温度が異常に上がりすぎたことによる過熱とされています。今回はAWSについての事例ですが、Azureについても冷却装置の故障による過熱が原因の障害が発生しています。
このように、リージョン丸ごとの障害が発生する原因は、クラウドの運用が世界規模で自動化されており、1つの障害が影響を与える範囲が大きくなりがちであることに起因します。ですが、複数のリージョンが同時期に停止したり、1つのあるサービスがリージョンをまたがって複数のリージョンで障害により停止するという状況はまずありえません。その理由として、物理的にサーバー群が独立して運用するように設計されていることが挙げられます。例えば、東日本のリージョンで何かトラブルが発生したとしても、西日本のデータセンターでシステムが停止するような事態ができる限り発生しないように分離させる設計がなされています。先ほどのAWSの障害事例でも、影響は単一のアベイラビリティーゾーンにとどまっており、マルチAZ構成ではほとんど影響がないとのことでした。とはいえ、設計上の不備があるシステムで一部影響があった模様です。

サービス停止を未然に防ぐ設計ポイント

頻繁に障害が発生するなんて怖くて使えたものじゃないと思われがちですが、Azureなどのクラウドは適切に使用する限りSLAの下で安定してサービスを停止せずに利用できます。停止しないサービスの設計を行う上でのポイントを説明していきます。

マルチリージョン、マルチAZ構成にする

最初に考えられるのは、シングルリージョンによる設計ではなく、マルチリージョンあるいはマルチAZをベースにシステムを設計することです。そうすることで、リージョンに障害が発生したとしても、他のリージョンで補うことができ、結果的にサービスを継続することができます。設計の難易度や分離レベルの高さ、通信コストなどの考慮すべき点を踏まえ、どちらをベースに設計するかを選択してください。

1つのリージョンに固定化される設計を避ける

マルチリージョンを選択した場合に、システム自体は複数リージョンに配置しているのに、処理系を片方に寄せてしまうといった設計上の失敗がよくあります。オンプレミス環境での設計が長い方ほどこういった失敗に陥りやすい傾向にあります。複数のリージョンにシステムを構築しているのですから、きちんと両現用になるように設計することを心がけてください。でないと、1つ障害が発生した場合にサービス全体が停止してしまう事態に陥ってしまうのは言うまでもありません。

「リージョンなし」のサービスの対策

多くのクラウドサービスではリージョンに紐づいており、利用開始する際にリージョンを選択します。しかし、その一方で、サービスそのものがリージョンなしであるものがあります。Azureを例に挙げるならば、Azure AI services(旧称:Cognitive Services)の一部やTraffic Managerなどがそれにあたります。これらは1つのリージョンに依存しないので、仮に別のリージョンで障害が発生したとしても影響を受けないことを前提としています。一見得しかないように見えますが、リージョンなしサービスにはリージョンなしサービス特有のリスクを孕んでいます。そのリスクとは、そのサービスが全世界的に障害となる可能性がある、ということです。もしそうなった場合の対策を考えておくことが設計する上で重要となってきます。

【要注意】サービス名称の変更について
Microsoftは2023年に「Cognitive Services」を「Azure AI services」へ名称変更しています。また、旧来のクラシック管理者ロール(共同管理者・サービス管理者)は2024年8月31日に廃止・サポート終了し、2026年5月に完全廃止されています。権限管理は現在のAzure RBAC(所有者・共同作成者・閲覧者などのロール)を前提に設計してください。

以上の点に注意することで、大規模障害が発生しても停止しないサービスを構築することが可能となります。

押さえておきたいポイント

  • シングルリージョン構成はコストを抑えられる一方、リージョン障害が発生するとサービス全体が停止するリスクを常に抱えている。
  • マルチリージョン・マルチAZ構成を選ぶ場合は、処理系を片方に寄せず両現用(アクティブ・アクティブ)で設計しないと、障害耐性を活かしきれない。
  • 「リージョンなし」のグローバルサービスを利用する際は、そのサービス自体が全世界規模で障害となった場合の代替手段もあわせて検討しておく。

よくある質問

マルチリージョン構成にすると必ずコストは上がりますか?

基本的には利用するサーバーやリソースの台数が増えるため、シングルリージョン構成に比べてコストは高くなる傾向にあります。ただし、サービス停止による機会損失や信頼低下のリスクとコストを比較したうえで、必要な可用性レベルに応じて構成を選ぶことが重要です。

マルチAZとマルチリージョンはどちらを選ぶべきですか?

データセンター単位の局所的な障害への耐性を重視するならマルチAZ、大規模災害やリージョン全体の障害まで見据えるならマルチリージョンが適しています。通信コストや設計難易度、求められる可用性のレベルを踏まえて選択してください。

Azureの各種名称やロールが最新かどうかはどこで確認できますか?

クラウドサービスはサービス名称や管理体系が随時更新されるため、最新の情報はAzure公式サイトやMicrosoft Learnのドキュメントで確認することをおすすめします。

おわりに

AzureやAWSなどのクラウドのサービス停止を未然に防ぐ設計ポイントとして、マルチリージョン、マルチAZで構成するという方法を説明しましたが、利用するサーバーの台数などが増えてしまうため、必然的にシングルリージョン構成よりもコストが上がってしまいます。構成する際はよく考えて設計してください。特性を熟知し、適切に設計することで大規模障害が発生してもサービス停止しないシステムを構築することができます。
需要がどんどん上がっていくAzureやAWSについて学習したい方は、実際に利用してみるのが一番です。Azureでは無償試用版が用意されていますから、勉強にはもってこいです(提供内容・条件は変更される場合があるため、最新情報はAzure公式サイトでご確認ください)。この機会にぜひチャレンジしてみてはいかがでしょう。

▼ アクロビジョンについて

👔

一緒に働きましょう

一人ひとりのキャリアに向き合い、
活躍できる現場をご紹介します。

採用サイトを見る →
💻

システム開発のご依頼・ご相談

コンサルティングから運用保守まで、
ワンストップで対応します。

まずはお気軽にご相談ください →