クラウドの障害とは？原因や事例、リアルタイムの確認方法を詳細に解説！
現在、多くの企業が提供するインターネット上のシステムやサービスで、クラウド環境が利用されています。高い拡張性や可用性など、クラウドサービスの利用は企業のビジネスにさまざまなメリットがあります。その一方で、課題となるのが障害の発生です。障害を完全に抑制することができないため、発生時の対策が必須とされています。
「クラウドで発生する障害ってどんなもの？」
「リアルタイムな障害情報を確認する方法はある？」
こういった疑問に答えるため、この記事ではクラウドで発生する障害の概要、障害の事例、リアルタイムの障害確認方法、障害復旧のポイント、支援サービスの利用について解説していきます。
クラウド上の障害は、広がり続けるクラウド利用の流れで避けて通ることのできない、企業にとっての経営課題です。クラウドを既に利用している、またはこれから利用する企業の方は、自社の環境に必要な対策を講じる参考にしてみましょう。
クラウドで起こる障害とは
なぜクラウド環境で起こる障害を避けることができないのでしょうか。
AWSやAzureなど、現在のクラウドサービスの多くでは高い可用性が保証されています。可用性とは「システムが継続して稼働できる度合い」を示しており、高い可用性は有事の際でも変わらず利用できることを示しています。
しかしどれだけ高い可用性を保証しているクラウドサービスでも、絶対に障害が発生しないわけではありません。障害発生率が0％となることは無く、必ず障害を前提としています。AWSの障害管理に関するドキュメントでも、冒頭で以下のように記述されています。
障害は発生するものであり、最終的にはすべてが時間の経過とともにフェイルオーバーします。つまり、ルーターからハードディスクまで、TCP パケットを破壊するオペレーティングシステムからメモリユニットまで、そして一時的なエラーから永続的な障害まで、どれもが対象となるのです。これは、最高品質のハードウェアを使用しているか、最低料金のコンポーネントを使用しているかにかかわらず、当たり前のことです – Werner Vogels、CTO – Amazon.com
障害発生率を0％にすることができない理由として、以下に示す障害の原因が挙げられます。原因の発生を無くすことができず、原因への対策を上回る規模の障害が起きる場合もあることから、クラウド環境で起こる障害を避けられないのが実状です。障害発生を完全に防ぐことができないからには、その原因を把握して発生率を下げると共に、障害を前提とした設計を心がける他ありません。
以下に障害発生の代表的な原因を紹介していきます。
障害の代表的な原因
障害が発生する原因について、代表的なものには以下のような原因が挙げられます。
人為的なミス
サーバーを管理する提供元か、サービスを利用する企業側のどちらかで、メンテナンス担当者が誤った操作を行った場合に発生します。入力したコマンドの誤りなどによってサーバーがダウンしたり、通信が正常でなくなったりすることで障害につながります。
想定外の過負荷
システムが想定していないレベルの過負荷にさらされた場合に障害が発生するパターンです。多くのサービスでは過負荷の対策が取られていますが、その許容量を超えた負荷がかかった場合に、システムが対応しきれず発生します。通信の中断やサーバーのダウンが引き起こされる可能性があります。
サーバー冷却装置の故障
データセンターでサーバーを冷却している装置が故障した場合に障害が発生するパターンです。高熱を発するサーバーを冷却できず、サーバーがオーバーヒートを起こすことでダウンし、障害に発展します。物理的な修理やオーバーヒートしたサーバーの点検などが必要になる場合があります。
天災
データセンターのある地域が豪雨や地震などの天災による被害を受けた場合に発生します。停電が起こるか、サーバー等のハードウェアが損壊することで、サーバーが正常に動作できず、アクセス不可になります。地域単位の災害による障害となるため、復旧に時間を要する場合がある点に注意が必要です。
過去にあった障害の事例
先述した障害の原因により、過去に大規模な障害が発生した事例があります。
ここでは、それらの事例の中から2つ紹介していきます。いずれも利用している企業の多いクラウドサービス上で発生した障害で、影響を受けた企業は少なくありません。実際の事例を知ることで、発生から解決の流れを把握して対策の参考にしましょう。
【AWS】2019年8月：空調設備システムの異常
世界中で数百万以上、日本でも数十万を超えるユーザーを持つAmazon Web Services（AWS）で発生した障害の事例です。またこの障害は、日本の東京リージョンで発生した、私たちに身近な事例でもあります。
2019年8月23日に東京リージョンの単一のアベイラビリティゾーンで、オーバーヒートにより一部のEC2サーバーが停止しました。原因は該当のアベイラビリティゾーンの空調設備管理システムの障害でした。冷却に使用する空調設備が機能せず、オーバーヒートにつながったと報告されています。
この障害では郵便局や一部のショッピングサイトの他、電子決済サービスなども利用システムが停止する事態となりました。
約3時間後に冷却装置が復旧し、障害発生から約6時間後に大部分のEC2インスタンスとEBSボリュームが復旧しました。
参考：東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
【Microsoft 365】2024年7月：サービスへの接続不可
世界中で約2.6億人が利用し、国内シェアでもNo.1のグループウェアとされているMicrosoft 365の事例です。
2024年7月30日にMicrosoft 365とAzureの一部サービスに障害が発生し、世界的に利用できない状態になりました。Microsoft 365管理センターやService Health Status ページへのアクセスができず、時間経過とともにAzureやMicrosoft 365のホームページなどでも問題が発生しました。原因は「予期しない使用料の急増」とされていましたが、その後DDoS攻撃と呼ばれるサイバー攻撃があったことが報告されています。
Microsoftのクラウドを経由したサービスや、ホームページに障害が発生し、企業がMicrosoft 365のOfficeソフトウェアを利用できないなどの影響がありました。
午前に障害が確認されてから、マイクロソフト側でネットワーク構成変更などの対応が行われ、夕方ごろには回復しました。
参考：Microsoft 365 と Azure の障害により複数のサービスが停止
リアルタイムの障害確認方法
障害が発生した可能性があるとき、利用しているサービスの状態をすぐに確認する必要があります。そのためには、リアルタイムに障害情報を確認する方法を把握しておかなくてはなりません。ここでは多くのクラウドサービスで利用できる、障害情報を確認する方法を紹介していきます。汎用的な確認方法を知っておくことで、確実な情報を獲得できるように準備しておきましょう。
クラウドサービスの公式サイトを確認する
各クラウドサービスの公式サポートサイトには、現在のサービス稼働状況が掲載されている場合があります。そのクラウドサービスにとって、最も確実な情報が発信される場所です。利用しているクラウドサービスがサポートサイトで情報を公開している場合は、普段から確認するようにしておくと良いでしょう。
またクラウドサービスによっては、同じページでその後のメンテナンス予定を掲載している場合もありますので、合わせて確認するのがおすすめです。メンテナンスによるサービス停止を障害と間違えないようにしましょう。
障害発生時に通知されるように設定する
クラウドサービスの中には、構築したシステムのデータを読み取って、障害の発生を検知できるサービスを提供しているものがあります。このサービスを利用すれば、障害発生時に自動的に検知した内容をメールなどで通知するよう、設定することが可能です。
この方法の最大のメリットは、必要な情報に関する通知だけに絞って送るよう任意に設定できることです。不要な通知を減らし、ビジネスにダメージのある障害に絞って設定することで、効率的な運用に利用することができます。
また、このようなサービスは「読み取ったデータの数値がしきい値を超過した場合に通知を出す」といった設定を行える場合があります。障害が発生する前にしきい値超過を知らせる通知を行うことで、障害を未然に防ぐ対策を行うことも可能です。
Downdetectorを使う
DowndetectorはOokla社が運営する障害情報確認ツールです。公式な情報を公開しているわけではないものの、世界中のインターネット上のサービス稼働状況を発信しています。複数のクラウドサービスを利用している場合や、公式の情報が未発表の段階で障害の情報を確認するのに適したツールです。
SNSと個人からの報告を自動的に収集することで障害を判断する仕組みとなっているため、迅速な情報が届く一方で誤検知が含まれる可能性があるのが欠点です。
障害復旧のポイント3選
障害発生時にシステムやサービスを提供している企業側に求められるのは、迅速な障害の復旧です。障害復旧には事前の準備と、障害に応じた臨機応変な対処が欠かせません。障害の内容によって変わる対処方法に柔軟に対応するために、どのような場合でも利用できる障害復旧のポイントを3つに分けて解説していきます。
以下に示すポイントを踏まえて障害復旧を想定した準備を行い、最小限の被害でシステムやサービスを維持できる体制を整えましょう。
事前に障害復旧計画を策定する
障害復旧計画とは、障害発生時にその原因や状態に関わらずシステムやサービスの機能とアクセスを回復させるための計画です。どのように復旧を進めるかを形式化、構造化して計画することで、迅速にビジネスを復旧することが可能になります。
クラウドサービスによっては、サービス側で障害があった場合の計画が提示されています。それらも参考に、自社が利用・提供する環境で障害があった場合、どのような復旧を行うのか定めておきましょう。クラウドの専門家が自社にいない場合などは、専門家の協力を得て復旧計画の策定を行うのがおすすめです。
復旧の手順を間違えない
障害の復旧を行う段階において重要なポイントは、復旧手順のミスを発生させないことです。障害を解消しようとする手順の中でミスがあった場合、既に発生している障害に加えて新たな問題や障害を起こしてしまう可能性があります。障害対応の時点で発生している工数に加えて新たな問題に対処する工数が発生すれば、復旧により時間がかかってしまいます。復旧が長引くことは、被害の拡大とコストの増大を生み出すため、避けなくてはなりません。ひとつの手順の間違いから大きな影響を及ぼさないように、復旧手順の作成とマニュアル化を慎重に行いましょう。
復旧後の経過に注意する
障害が復旧した後、一定の期間を経過観察期間として確保するようにしましょう。発生した障害が再発したり、復旧対応の影響が他の問題につながったりする場合があるためです。経過観察期間の具体的な対応としては、定期的なシステムやサービスのアクセス確認や、アラート有無の確認などが挙げられます。経過観察期間の長さはシステムの規模や、一日の稼働時間によっても異なります。
経過観察期間を過ぎても問題が何も発生しなければ、障害は完全に復旧したと判断して、平常の運用状態に戻すことができます。
障害対応支援サービスの利用
企業によっては、顧客に提供するサービスをベンダーに発注して提供している場合もあるでしょう。この場合、企業内にクラウド環境の専門的な知識を持った人材が不足しており、障害発生時の対応などが難しい可能性があります。
そういった企業の障害対応を支援するためのサービスが存在しています。これらの支援サービスはクラウドサービスの監視を行い、障害発生などの緊急時に復旧対応を代行します。企業に不足した専門的な人材を補う、アウトソーシングの手法として非常に有効です。サポート内容は支援サービスによって異なりますが、要件やシステムの規模に合わせて支援体制を設定できることが利点です。
専門的な人材が確保できない場合は、障害対応支援サービスを利用することも検討してみましょう。知識やノウハウを持った担当者に障害の原因究明と対処を任せられるうえ、システムやサービスの耐障害性を確保できます。
まとめ
クラウド環境の障害には場合によって回避できない原因があり、そのために障害を前提に対策や復旧の準備を行うことが必要です。システムやサービスを提供する企業にとって、障害の原因や過去の事例は、今後のビジネスを進めるうえで把握しておかねばならない要素となりつつあります。今回紹介した事例の他にも、実際に発生した障害が多く存在します。自社が利用するクラウドサービスで発生した障害を調べて、更に理解を深めるのもおすすめです。
本記事では、クラウドで発生する障害の概要、障害の事例、リアルタイムの障害確認方法、障害復旧のポイント、支援サービスの利用について解説してきました。
原因や過去の事例に加えて、ここで紹介・解説した障害確認方法や復旧のポイントを活用して、「復旧力」の高い運用体制を構築しましょう。
この記事をシェア
