CIO分析:Amazonのクラウド障害の調査

Amazonの最近のWebサービスの停止により、Reddit、Foursquare、Quoraなど、多くの有名なWebサイトがダウンした。カバレッジ、推測、そしてこの状況を取り巻くFUDを考えると、私はCIOの視点が有用であると考えました。

Amazonによる詳細な死後分析は、何が起こったのかを記述する

先週EC2の顧客に影響を及ぼした問題は、米国East Region内の単一のAvailability ZoneにAmazon Elastic Block Store(EBS)ボリュームのサブセットが関与しており、読み書き操作に対応できなくなっていました。この文書では、これらを「スタック」ボリュームと呼びます。このため、これらの影響を受けたボリュームを使用して、読み込みまたは書き込みを試みたときに「スタック」したインスタンスが発生しました。これらのボリュームを復元し、可用性ゾーンでEBSクラスタを安定させるために、影響を受ける可用性ゾーン内のEBSのすべてのコントロールAPI(ボリュームの作成、ボリュームの接続、ボリュームの切り離し、スナップショットの作成など)を無効にしました。イベント。問題の最初の2日間は、劣化したEBSクラスタがEBS APIに影響を与え、米国東部地域全体でこれらのAPIへのEBSコールのエラー率と待ち時間が高かった。複雑な運用上の問題と同様に、これは相互に作用するいくつかの根本的な原因によって引き起こされたため、同じようなイベントが繰り返されることからサービスを保護する機会が多くあります。

それは詳細なテクノギークの議論ですが、英語では、Amazonのシステムは制御不能にカスケードしたローカル輻輳を経験し、可用性が欠けています。さらに悪いことに、Amazonは実際に顧客のデータを失いました。

コラボレーション:今日のデジタルワークプレイスの構成原理は何ですか; CXO; CIOには誰が影響しますか? CXO、ITエグゼクティブデッキをシャッフルするANZ銀行、データセンター、デルタがシステム停止に価格タグを付ける:税引前利益150百万ドル

CIOの観点からは、いくつかの点に留意する必要があります

1.空は落ちず、雲はここにあります。

この停止は、クラウドの採用に短期間の影響を与える可能性があります。一般的なビジネスの出版物として、エコノミストは、そのような停止

顧客がクラウドの背後にある基本的な考え方を本当に信頼できるかどうかという問題を提起しました。インターネットからコンピューティングサービスを購入することができます。

しかし、逸話的な証拠とCIOのマインドシェアは、クラウドコンピューティングとSaaSの重要性が増していることを示唆しています。コンピュータ経済学の最近の研究は、次の図に示すように、SaaSの成長と投資に関する実証的研究の光を照らしています

また、この問題についてFocus.comに興味深い記事があります。

2.クラウド・レバレッジは、友人または敵のいずれかになることができます。

集中化されたサービス機能は、クラウドコンピューティングとSaaSの中心的な教義です。 Amazonなどのクラウドベンダーは、多くの顧客のインフラストラクチャを「レンタル」で共有しています。これらの共有施設は、規模の経済を創出し、クラウドコンピューティングを経済的に魅力的にするためのレバレッジを促進します。

しかし、集中化にも暗い側面があります。中央の施設が故障すると、マイナスの拡大効果が発生します。昔は、すべての主要組織が独自のインフラストラクチャを維持していたため、多くの企業が単一障害点から同時にダウンするリスクが軽減されていました。従来のインフラストラクチャは高価で、非効率的で、冗長性がありますが、クラウドは事態が悪化した場合に、より広範な障害を発生させます。

それにもかかわらず、ほとんどの組織にとって、クラウドとSaaSは優れたビジネスケースと相まって多くの魅力的な経済的メリットを提供します。エコノミストの別の記事が述べているように

無数の個人や企業が、オンラインで行うことのメリットがリスクを大きく上回ることを発見しました。

それは、主要なコンポーネントやシステムがクラウドに集約され、それに応じて計画されているときに、スマートな組織がリスクを認識しているということです。 Gartnerのアナリスト、Lydia Leongは、この点についてセイジのコメントを提供しています

クラウドIaaS [サービスとしてのインフラ]には多くの可動部品があります。それらのいずれかが間違っているあなたのサイト/アプリケーション全体をborkすることができます。実際の問題は、インフラストラクチャーの冗長性によって引き起こされる複雑な問題や技術的な課題やコストに対して、適切なリスク軽減 – ダウンタイムとそれに伴う損失のリスクです。

3.雲はまだ成熟し、進化しています

ビジネスとテクノロジーの両方の観点から、クラウドの世界は時とともに変化し、進化しています。 Amazon自身は、より良い計画を立て、独自のシステムをより堅牢にする方法をまだ評価しています。

コンサルティングとアウトソーシングのエグゼクティブであるSadagopan Singamは、これを視点に入れます(強調)

ノードが使用できないという問題が発生した場合、Amazonはほとんどの場合、環境内でサービス拒否攻撃を受けるようになりました。 Amazonは今、危機に関連する行動のこの側面が正しいと主張しているが、他に何が与えることができるかを見るために次の停止まで待たなければならないかもしれないと主張している。 Amazonクラウドサービスは2008年に大きな打撃を受けました。故障パターンは診断時に多少似ています。

明らかに、システムは異なる状況下で異なった動作をする必要があります。ノードがストレージ/アクセス上の問題に複製し続けるのは正常ですが、システムは異なる性質の危機で異なる動作を示すべきです。パブリッククラウドサービスがますます普及するにつれ、確かに可用性と信頼性のためにさまざまな状況下でテストされます。すべてのビジネスおよびITユーザーは、ワークロードをクラウド上に移すことを検討するような質問に対する回答を求めます。

4.自立と適切な計画が重要です。

アウトソーシングは、企業バイヤーに自分の運命を管理する責任を免れません。クラウドコンピューティングでは、企業は災害復旧を計画している間に回復力のためにアプリケーションを設計する必要があります。

クラウドの自動化CTO George Reeseは、データセンターの中断からアプリケーションをある程度独立させるために、「障害の設計」を提案しています

障害モデルの設計では、ソフトウェアと管理ツールを組み合わせてアプリケーションの可用性を管理します。実際のインフラストラクチャの可用性は、アプリケーションの可用性とはまったく関係ありません。クラウドプロバイダが大規模なデータセンター全体の停止を行っている場合でも、100%の稼働時間を達成する必要があります。

従来のモデルの利点は、任意のアプリケーションをそのアプリケーションにデプロイし、その機能に適した冗長レベルを割り当てられることです。欠点は、伝統的なモデルが地理に大きく制約されていることです。このレベルのクラウドプロバイダー(パブリックまたはプライベート)の停止から生き残るのには役立ちませんでした。

「設計の失敗」モデルの利点は、アプリケーション開発者が、データモデルとボリュームのみが地理的な制約を課して可用性を完全に制御できることです。 「故障のための設計」モデルの欠点は、「故障のために設計」する必要があることです。

災害復旧は、クラウドなどの障害が発生した場合に重要なトピックになります。多くの組織では、ディザスタリカバリにリップサービスを提供していますが、停止が発生する前にシステムを完全にテストすることはありません。ベテラン技術者、Bob Warfieldは、クラウド環境で災害復旧計画を実施するための提案を提供しています

企業はオフサイトバックアップのクラウドに相当するものを必要とします。最低限、インフラストラクチャのバックアップにアクセスできることを確認する必要があります。すべてのAMIとデータを再起動する必要があります。ストレージは安いです。あなたが完全に不愉快な人ならば、テーブルを回して、バックアップインフラストラクチャだけで構成される独自のデータセンターにクラウドをバックアップしてください。少なくともあなたはいつもデータを持っています。はい、レイテンシの問題があり、そのデータは最大ではありません。しかし、起こったすべてを見てください。 2時間のデータを失った別の地域でスピンアップできたとします。良くない、まあまあです。しかし、それは本当に悪い24時間以上待っているか、あなたが緊急事態に2時間それをしていた可能性がある場合は今のところ祝福感じていますか?

これらは、災害復旧のために考えられるトレードオフの一種です。より弾力性のあるアーキテクチャが得られるまでは、チューインガムとワイヤリングが必要ですが、何も選択して待っていないのは確かです。

5.成功例から学ぶ

Amazonの顧客の中には、事故から比較的無傷のものがありました。あなたの組織がより良い準備をするのを助けるために彼らのレッスンから学びます。

死後のビデオ配信大手のNetflixは、

一部のウェブサイトに影響があったのはなぜですか? Netflixの場合、私たちのシステムはこれらの種類の障害に対して明示的に設計されています。私たちがクラウドのために再設計したとき、このAmazonの失敗はまさに私たちが回復したいと思っていた問題でした。私たちのアーキテクチャは、EBSを主なデータストレージサービスとして使用することを避け、私たちが依存しているSimpleDB、S3、およびCassandraサービスは、障害の影響を受けませんでした。

同様に、ジオロケーションの開発ベンダーであるSimpleGeoも害のない状態で生存しました。彼らのブログは、同社の関連する技術的なアーキテクチャー上の意思決定の根底にある哲学的見解を説明している

SimpleGeoの失敗はファーストクラスの市民です。デザインディスカッションでは多くのことを話しています。操作手順に影響を与えます。コーディングするときに考えて、昼食時にはそれについて冗談を言っています。私は、システム障害メカニズムを理解し、それらを公開することに重点を置いていることが、それらを扱う第一歩だと考えています。インフラストラクチャに新しいコンポーネントを導入する前に、必然的に失敗したときにどのように対処するのか計画しています。

CIOを紹介するアドバイス

多くの組織にとって、少なくとも一部のアプリやシステムをSaaSに移行させることは避けられません。問題は、どのアプリケーションを移動するか、いつ実行するか、どのように移行を実行するか、そして適切なスキルを内部的に開発するかどうかを決めることです。

アマゾンの状況は、クラウドの移行が何もない提案ではないことを示しています。この場合、より良い計画とアーキテクチャ設計を持つ組織は生き残り、他の組織はダウンしました。加えて、洗練された技術知識の重要性は過度に強調することはできません。

CIOは、組織がクラウドの投資/リスク曲線に適合する場所を決定する必要があります。他の事業分野と同様に、堅牢な設計への投資を増やすことで、オペレーショナル・リスクを削減することができますが、財務コストは高くなります。すべてのCIOは、投資、技術開発、リスクの適切なトレードオフを決定するために、自分の組織を評価する必要があります。

[Michael Krigsmanのクラウド写真]

今日のデジタルワークプレイスの構成原理は何ですか?

CIOには誰が影響しますか?ここではトップ20です

ANZ銀行、技術エグゼクティブデッキをシャッフル

デルタはシステム停止に価格タグを付ける:税引前利益150百万ドル