史上最大のクラウドコンピューティング障害トップ10

企業がクラウド サービスの障害を回避できるように、NetworkWorld は、世界中の多くの Web サイトが経験した最も深刻なクラウド サービスの障害 10 件と、そこから学べる教訓をリストアップしました。

深刻なクラウド障害その 1: Amazon Web Services の障害。

面倒なネットワークメンテナンスから解放されることは、クラウドでビジネスを行う上での大きなセールスポイントです。しかし、このサービスの欠点は、クラウドベンダーが定期的に構成を変更してビジネスを中断した場合、ユーザーは無力になってしまうことです。

これは、今年 4 月に多くの Amazon Web Services ユーザーが経験したことです。当時、バージニア州北部にあるアマゾンのデータセンターは故障し、完全に利用不能になっていた。

ネットワークのアップグレード中に障害が発生しました。情報がバックアップとして組み込むために利用可能なデバイスを探している間、トラフィックの移動が誤ってルーティングされ、Amazon EBS (Elastic Block Storage) トラフィックのカスケードが再ミラーリング ストームに送り込まれました。これは異常な現象です。これにより一連の出来事が引き起こされ、最終的には米国東部の多くの Amazon サービスが停止する事態に至った。

停電は約4日間続きました。しかし、多くの企業が苦戦する中、Netflix などの企業は問題を解決することができました。生き残るための鍵？この種の障害を考慮してシステムを設計してください。

Netflix のエンジニアは、「Netflix における Amazon Web Services の停止から学んだ教訓」というタイトルのブログで、当社のアーキテクチャでは EBS を主要なデータ ストレージ サービスとして使用しないようにしていると述べています。私たちが依存している SimpleDB、S3、Cassandra サービスは、この停止による影響を受けませんでした。ステートレス サービスと、アベイラビリティ ゾーン全体にわたるデータの複数の冗長ホット コピーは、Amazon Web Services クラウドの障害から保護するための鍵となります。

安全を確保するには Netflix 規模の企業にならなければならないと思いますか?もう一度考えてみてください。開発者が Web アプリケーションと通信を統合するのを支援する Twilio は、コア インフラストラクチャをホストするために Amazon の EC2 サービスを使用しています。それでも、4月の停止は安定性にほとんど影響を与えなかった。

Twilioの共同創業者兼CTOのエヴァン・クック氏は、クラウドはネットワークに障害が発生することを前提に構築されたと語った。私たちは、ホストは失敗する可能性がある、そして失敗するだろうという考えに基づいてインフラストラクチャを構築しました。したがって、コア アーキテクチャ自体の単一のマシンまたはコンポーネントに依存することはありません。

深刻なクラウド障害その2: Sidekick がシャットダウン。

スマートフォンを使えば、外出先でも簡単にデータにアクセスできます。しかし、何かの名前に「スマート」という言葉が含まれているからといって、それが愚かではないということではありません。一例として、2009 年秋頃に発生した T-Mobile Sidekick の障害が挙げられます。

Microsoft が所有する Sidekick がほぼ 1 週間にわたってサービス停止に見舞われ、ユーザーが電子メール、カレンダー情報、その他の個人データにアクセスできなくなった大失態を覚えていますか?その後、マイクロソフトはクラウドに保存されていたデータが完全に失われ、回復できない可能性があることを認めた。どうやら Microsoft の人たちはバックアップを取るのを忘れたようです。

それ以来、技術は進化しているかもしれない。しかし、教訓は同じです。重要なデータに関しては、他の人が自動的に保護してくれると決して思い込まないでください。クラウド プロバイダーの災害復旧設定を必ず理解してください。重要なデータを独自にバックアップする計画を立てることが最善です。

アラートサイトの監視製品担当副社長ケン・ゴッドスキンド氏は、クラウドにも同じ運用ルールが適用されると述べた。クラウドを使用する組織は、クラウド内にあるからといって、ビジネス継続性計画の全責任がプロバイダーに課されていると単純に想定することはできません。

深刻なクラウド障害その3: Gmail 障害。

すべてのクラウド サービスの中で、Google の Gmail は、Microsoft が企業に導入しているオンプレミスの電子メール サービスの要塞に対する最大の脅威の 1 つです。メンテナンスに手間のかかる Exchange サーバーを、Postini を搭載した安価なスタンドアロンの電子メール サービスに置き換えます。違いは何ですか?

迷惑な中断が多数あります。最近の障害により、15万人のGmailユーザーがアカウントにログインしたが、空白のページしか表示されず、メールもフォルダもなく、実際に受信トレイを見ていることを示すものは何もなかった。名誉のために言っておくと、Google は定期的にアップデートを提供し、不具合を迅速に修正することを約束しています。しかし、影響を受けた一部のユーザーの場合、Google が問題を解決するのに 4 日かかりました。

「データのコピーが複数あると、どうしてこのようなことが起こるのでしょうか？」グーグルのエンジニアリング担当副社長ベン・トレイナー氏は当時、ブログ投稿でこう述べた。 「まれに、ソフトウェアのバグがデータの複数のコピーに影響を及ぼすことがあります。」ここで起こっているのはそういうことです。

Google は最終的に、データを回復するために物理的なテープ バックアップに切り替える必要がありました。最終的に、Google の多層的なデータ保護は機能しましたが、それでも数千人のユーザーが数日間メールにアクセスできない状態になりました。

失敗はクラウド接続のものを使用しない理由になりますか?おそらくそうではないでしょう。ただし、これは、緊急の必要性が生じる前に、自社のデータ保護を慎重に見直し、バックアップまたはオフライン アクセス ソリューションの構築を検討する必要がある理由です。

AlertSite の Ken Godskind 氏は、大まかな平均を見ると、クラウドの運用成功率は個々の運用成功率よりもはるかに高いと述べています。ただし、Web 規模になると、障害の影響がはるかに大きくなります。

大規模なクラウド障害その4: Hotmail が大混乱。

もちろん、Microsoft はクラウド サービスを宣伝するための最高の広告も提供しています。 Microsoft Hotmail は 2010 年末にデータベース エラーに見舞われ、新年を迎える頃には何万もの受信トレイが空になってしまいました。

マイクロソフト社は、この不具合はスクリプトエラーが原因だと述べた。これは、ダミーアカウントを削除するための自動テスト用に作成されたスクリプトです。このスクリプトにより、17,000 件の正規アカウントが誤って削除されました。

マイクロソフトがほとんどのユーザーのアカウントを復元するのに3日かかった。不運なユーザーの約 8% は、データの復元にさらに 3 日間待たなければなりませんでした。

大規模なクラウド障害第 5 回: Intuit が 2 回障害。

Intuit は昨年、大規模な障害に見舞われた。 TurboTax、Quicken、QuickBooksなどの人気プラットフォームを含む同社のクラウドベースのサービスは、1か月間に2回の停止に見舞われた。最悪の事件は昨年6月に発生した36時間にわたるインターネット障害だった。停電により重要な機器がバックアップ電源を使用するようになり、同社の主要システムとバックアップシステムは完全にオフラインになったようです。

さらに悪いことに、数週間後、再び停電が発生したようです。さらに、2 回目の停止は明らかに多くの悪用を引き起こしたようです。

当時、あるユーザーはWeibo上で、25時間にわたるインターネットの停止は耐え難いものだったと投稿した。 Intuit の受動的で不透明、そして受容性のないコミュニケーションは役に立たなかった。

実際のところ、絶対的な可用性が必要な場合、クラウドよりも優れたソリューションがある、とHPのセキュリティアドバンテージプログラムの主任ストラテジスト、クリス・ホワイトナー氏は語った。すべてをバックアップする必要はありませんが、追加の手順 (重要なデータのみを自分でバックアップするなど) を実行すると、大きな違いが生じる可能性があります。

#p#重大なクラウド障害 6: Microsoft BPOS (Business Office Online Suite) の障害。

クラウドベースのオフィススイートがダウンすると、生産性を維持するのは困難です。数週間前、Microsoft のビジネス クラウド サービスに依存している組織で、まさにそのようなことが起こりました。 5月10日頃、Microsoft BPOS サービスが断続的に動作し始めました。一部のユーザーは、電子メールの受信に 9 時間の遅延を経験しました。

2 日後、BPOS の問題が解決したように見えましたが、遅延が再発し、送信トラフィックがブロックされました。この事故だけでは不十分だったかのように、マイクロソフトはユーザーがウェブベースの Outlook ポータルにログインできなくなるという別の不具合も経験しました。

マイクロソフトのオンラインサービス部門の副社長はブログ投稿で、「今回の障害でご不便をおかけしたことについて、お客様とパートナーの皆様にお詫び申し上げます」と述べた。

大規模なクラウド障害その7: Salesforce サービスの停止。

1 時間のインターネット停止は大したことではないように思えるかもしれません。しかし、あなたの会社が何万もの企業のカスタマー サービス業務の鍵を握っている場合、それらの組織の多くは、その 60 分を一生分と見なすでしょう。

Salesforce.com は、昨年 1 月にデータ センターが閉鎖されたときに、この教訓を身をもって学びました。新年に入ってわずか 4 日後、Salesforce.com は、サービス、バックアップなどすべてが中断される大規模な障害が発生したと報告しました。

迷惑な？絶対に。驚きましたか？まったく驚くことではありません。

現実には、クラウドベースのデータセンターでも停止が発生することがある、とコニカミノルタの子会社である AllCovered の CIO である Tim Crawford 氏は言う。それが崩壊の原因であり、いつもそうなのです。これについては現実的に考えなければなりません。

クロフォード氏は、クラウド コンピューティングを成功させるには、従来のサーバー設定とは異なる考え方が必要だと述べた。企業のデータが時折発生するインターネットの停止に耐えられるかどうかは、自分で判断する必要があります。余裕がない場合は、ネットワークの停止を回避するために必要な復元力が構成に備わっていることを確認する必要があります。

クラウド プロバイダーを選択するときは、プロバイダーがこれらのサービスをどのように提供しているか、また、プロバイダーが独自に構築できるよりも高いレベルの冗長性を構築できるかどうかについて、事前に調べておく必要があります。答えが「いいえ」の場合、なぜこれらのクラウドプロバイダーを使用するのでしょうか?

深刻なクラウド障害第 8 回: クラウド プロバイダー Terremark にとって最悪の日。

おそらく最近の最大のニュースは、テレマーク社とベライゾン社の間の10億ドルの取引だろう。しかし、2010 年の初めに報じられた主なニュースは Terremark の停止でした。

2010年3月17日の聖パトリック祭の日、テレマークの運勢は悪くなり始めた。同社のvCloud Expressサービスはその日急降下し、マイアミのデータセンターは約7時間オフラインになった。この間、ユーザーはこのデータセンターに保存されているデータにアクセスできません。

冗長性はこれ以上得られません。ただし、これによってもたらされる冗長性の価値により、重要なデータを異なるデータ センター内の複数のサーバー、またはできれば異なる地域内の複数のサーバーに提供できるようになります。安全策として、データを複数のプロバイダーに分散するという追加の手順を実行することもできます。

IBM のクラウド セキュリティ戦略イニシアチブの最高技術責任者であるハロルド モス氏は、ワークロードをホストするベンダーを複数選択し、バックアップ用に 1 社または 2 社を選択し、主要プロバイダーとして 1 社のベンダーを選択できると述べています。その後、適切なセキュリティを備えた安全な方法でワークロードを実装し、回復力機能の導入を開始できます。

深刻なクラウド障害第 9 弾: PayPal がオフラインになりました。

広範囲にわたる深刻な結果をもたらすクラウドの停止を望みますか? PayPal を数時間オフラインにしてみるとその効果を実感できるでしょう。

これは仮説的な演習ではありません。2009 年夏の PayPal の停止は実際に発生し、世界中の何百万台ものマシンで商品の販売が停止しました。サービスは約 1 時間にわたって完全に利用できなくなり、その後も数時間にわたって断続的に利用できなくなりました。 PayPalは、この事故の原因はハードウェアの故障だと述べた。

もちろん、このような停止はまれです。しかし、この不幸な障害により、PayPal はクラウド コンピューティングの恥の殿堂入りを果たすことになった。

深刻なクラウド障害 #10: Rackspace にとって厳しい一年。

TechCrunch や JustinTimberlake のようなサイトにクラウド サービスを提供している場合、サーバーが機能しなくなると、人々が気付くのは当然です。

Rackspace は 2009 年にいくつかの教訓を得ました。このクラウド プロバイダーは 2009 年を通じて 4 回の大規模な障害に見舞われ、同社の顧客は数時間にわたってインターネットにアクセスできなくなりました。 Rackspace はユーザーに約 300 万ドルのサービス料を支払わなければなりませんでした。

ラックスペース社は今回の事件を「痛ましく、非常に残念」と呼び、今後も長期にわたり高水準のサービスを維持すると約束した。今のところ、同社は稼働時間に重点を置いていますが、クラウド サービスに伴う避けられない混乱に備えるための計画をユーザーが立てられるよう支援も行っています。

Rackspace の Lew Moorman 氏は、サーバーのクラスターを設定したり、地理的な冗長性を作成したりする場合、以前よりも簡単に実行できるようになったと述べています。しかし、これらの手順を実行する必要があります。以前に社内でこれを実行したことがある場合は、クラウドによって、発生する可能性のある脆弱性は発生しません。

すべての失敗を考慮すると、ここでの最大の教訓は、単一のサーバー、センター、またはサービスが 100% 信頼できるわけではないということです。もしあなたがこの考え方でビジネスを構築していないのであれば、あなたは非現実的なやり方で歩んでいることになります。