Amazonが失敗し、冗長/分散が実際に何を意味するかについて多くの記事を読んだ後、DNSが弱点のようです。たとえば、DNSがデータセンター間でラウンドロビンに設定されていて、データセンターの1つに障害が発生した場合、多くのブラウザがそのDNSをキャッシュし、障害が発生したノードにヒットし続けるようです。
Time-to-Live（TTL）は理解していますが、もちろんこれは長い時間に設定されている可能性があります。
だから私の質問は、ブラウザがIPから応答を受け取らない場合、別のノードにルーティングされることを期待してDNSを更新するのに十分賢いですか？
ラウンドロビン DNS は、ブラウザーごとのものです。これはモジラがそれを行う方法です:
1 つのホスト名が複数の IP アドレスに解決される場合があり、それぞれがルックアップの成功後に返されるホスト エンティティに格納されます。Netlib は、DNS サーバーが IP アドレスを返す順序を保持します。接続中の任意の時点で、ホスト名に現在使用されている IP アドレスが失敗した場合、netlib はホスト エンティティに格納されている次の IP アドレスを使用します。その 1 つが失敗した場合は、次のクエリが実行され、以降も同様です。利用可能な IP アドレスを介したこの進行は、NET_FinishConnect() 関数で行われます。接続が失敗したために URL の読み込みが完了したと見なされる前に、そのホスト エンティティは、指定されたホストに対して別の IP アドレスを試行する必要があるかどうかを判断するために調べられます。IP アドレスが失敗すると、キャッシュ内のホスト エンティティから削除されます。
Amazon の失敗に関しては、Amazon のダウンタイム中に DNS に問題はありませんでした。DNS サーバーは IP アドレスを正しく報告し、ブラウザはそれらの IP アドレスを使用しました。失敗はAmazon側にありました。彼らは、圧倒されたクラスターにトラフィックを再ルーティングしました。DNS は停止していましたが、クラスター自体はトラフィックの膨大な負荷を処理できませんでした。
EC2 は、リージョンとアベイラビリティーゾーンという 2 つの非常に重要な可用性構成要素を提供します。設計上、リージョンはインフラストラクチャの完全に独立したデプロイです。リージョンは互いに完全に分離されており、最高度の独立性を提供します。多くのユーザーは、複数の EC2 リージョンを利用して、非常に高いレベルのフォールト トレランスを実現しています。ただし、リージョン間でデータを移動する場合は、ユーザーに代わってリージョン間でデータをレプリケートしないため、アプリケーションを介して移動する必要があります。
言い換えれば、「私たちが持っていると言った高可用性のすべてを覚えていますか? はい、それは本当にあなた次第です.」彼ら自身の不調により、クラスター内のプライマリ ノードとセカンダリ ノードの両方が取り除かれ、フェイルオーバーするものは何も残っていませんでした。そして、すべてを元に戻すと、ノードが同時に同期を試みたため、突然「再ミラーリング ストーム」が発生し、サービス拒否がさらに発生しました。DNSはそれとは何の関係もありませんでした。