AWSにはアクセシビリティに関する2つの概念があります。リージョンとアベイラビリティーゾーン、アリゾナ州です。 5つの地域があります。2つは米国（西海岸と東海岸）、1つはヨーロッパ（アイルランド）、2つはアジア（東京、シンガポール）です。 各地域には、いくつかのAZが配置されていますが、自然災害または同様の規模のものを除き、相互に分離し、共通の障害点を持たないようにする必要があります。
AWSは、「個別のAZにインスタンスを設定することにより、特定の場所での障害からアプリケーションを保護できる」と述べています。 「場所」とは、「アクセシビリティゾーンが相互に物理的に独立していること 、および独立したインフラストラクチャ」を意味します。 どうやら、これらは別個のデータセンターです（ ただし、Amazonの説明から、これは明らかではありません-データセンター内の異なるフロア/部屋で、異なるチャネルを介した独立した電源と接続-約 ）。 地域全体をカバーする大惨事があった場合を除き、それらは同時に崩壊するべきではありません。
アベイラビリティーゾーンは、「同じリージョン内のアベイラビリティーゾーン間の低コストで低遅延の接続」も提供します。 一方、地域間接続はオープンなインターネットを経由し、比較的高価で、遅く、信頼性が低くなります。
これらは「ゲームのルール」です。 したがって、AWSのルールに従ってプレイし、マスター/スレーブMySQLデータベースを上げる（最も一般的な例を取り上げる）場合、論理的には、マスターとスレーブを同じリージョンに配置する必要がありますが、それらが異なるゾーンにあることを確認してください可用性。 それらを異なる地域に配置することはありません。そうしないと、地域間で低速で高価なチャネルを介してトラフィックを駆動する必要があり、データベースの同期に関してより多くの問題を抱えることになるでしょう。 たとえば、ハリケーンが東海岸に衝突してデータセンターを破壊した場合にのみリスクがありますが、これを除き、すべてが適切に行われるべきです-少なくともAWSの約束が守られている場合。
そのため、最終的に問題が発生しました。 昨日、東海岸地域ではいくつかのゾーンにアクセスできませんでした。 AWSは可用性障害シナリオの約束を破りました。 これは、AWSにある種の共通の障害点があることを意味します（複数の独立したインフラストラクチャへの同時物理的損傷のような絶対に信じられないシナリオが発生しなかったと仮定）。 まだダウンしているサイトは、「ゲームのルール」の条件を完全に満たしています。問題は、AWSが独自の仕様に従っていないことです。 これは、無能または不誠実、またはもっと言い訳ができるために起こりましたが、現時点ではわかりません。 しかし、Quora、Foursquare、Redditの開発者は非常に有能であり、彼らに告発を向けることは間違っています。
もちろん、壊滅的な障害（いくつかのアクセシビリティゾーン）からも自分を保護することは理論的には可能ですが、ほとんどのビジネスでは、これらの追加の開発コストと費用は価値がありません（または、システムを複雑にし、逆効果になることさえあります）。 現在ダウンしているすべてのサイトにバックアップがあると確信しています。 問題は、オンラインへの復帰が難しく、リスクが高いことです。実際には、すべてを別のリージョンに移動する必要があります。そうしないと、サーバー間のネットワーク遅延が大きくなりすぎます。 AWSでは、これは非常に困難です：異なる地域のサーバー-異なるオプションセット、異なるAMI識別子、予約済みインスタンスはデータセンター間でまったく移動できないと思います-実際には、制御を別の地域に移動することはほとんど不可能です。 おそらく、完全に異なるクラウドに移行する場合と同じくらいの労力が必要になります。これは、おそらく、このような災害からの回復に最適なオプションです。 私たちが知る限り、QuoraはこのプロセスをAWSがクラッシュした瞬間に開始し、今まで完了しませんでした-1日かかる場合があります。
要するに、ここでの責任はAWSだけであり、違反した条件を「保証」します。 間違いは起こりますが、これはまさにAWSエラーです。
これは、クラウドホスティング自体の誤りではありません。 このケースは、プロバイダーを慎重に選択する必要があることを示しています。 多くの人がAWSを支持して選択を再考すると思います。
さらにいくつかの考え：
- 東海岸地域で非常に多くのサイトがホストされている理由は、AWSが最初に新しい機能を導入したからです。 彼は最も安いです。 そして、これはおそらくトラフィックを提供するのに最適な地域です（北米では通常のパフォーマンス、ヨーロッパでは許容できるパフォーマンス）
- 失敗の理由は、実際にはEBS （Elastic Block Store）ディスクアレイであり、使用開始当初から信頼性の点で破滅的に証明されていました。 しかし、これはまったく異なる記事のトピックです！
- EBSアレイは1つのアベイラビリティゾーンにのみ存在でき、それらへのアクセスはこのゾーンからのみ可能です。 どうやら、Amazon RDS分散データベースは、他のゾーンからEBSにアクセスできるシークレットAPIを使用していますが、これらのインターフェイスはRDS以外の誰もアクセスできません（うーん...シークレットAPIを使用して競争上の優位性を得るシアトルの会社は、おなじみですか？）