AWS北バージニアのデータセンター障害 - 解決済み
(cnbc.com)- AWS は木曜夜から運用上の問題を報告しており、北バージニアの US-East-1 リージョンにあるデータセンターの過熱に関連した障害が、Coinbase や FanDuel のような取引プラットフォームに影響を与えた
- AWS は金曜午後3時29分（ET）の更新で、完全復旧にはなお数時間かかる見込みであり、復旧作業は以前の想定よりも遅れていると明らかにした
- AWS は、当該リージョンの 単一の Availability Zone で問題が発生しており、追加の冷却システム容量をオンライン化して残るハードウェアの復旧を進めていると説明した
- FanDuel は、ユーザーがプラットフォームにアクセスできない技術的問題を調査した後、より広範な AWS 障害に関連していると明らかにし、利用者はキャッシュアウトできずに賭けの損失が発生したと抗議した
- Coinbase は、複数の AWS アベイラビリティゾーンの障害が中核的な取引サービスの長時間の停止を引き起こしたと述べ、主要な問題は完全に解決したと投稿した
復旧の進捗
- AWS は金曜午前9時51分（ET）の更新で、「追加の冷却システム容量をオンライン化するために積極的に作業しており、これによって影響を受けたエリアの残るハードウェアを復旧できる」と述べた
- AWS は、仮想サーバー容量を提供する EC2 インスタンス の障害を解消している最中である
- AWS のヘルスダッシュボードは木曜午後8時25分（ET）に「インスタンス障害を調査中」と最初に掲載した
- AWS は追加コメントを出していない
サービスごとの影響
- FanDuel は木曜午後9時（ET）に X で、ユーザーがプラットフォームにアクセスできなくなる現在の技術的問題を認識しており、調査中だと明らかにした
- FanDuel は約2時間後、この問題がより広範な AWS 障害に関連していると更新した
- FanDuel の利用者は、プラットフォーム上でキャッシュアウトできず、賭けの損失が発生したと抗議した
- Coinbase も金曜に X で、複数の AWS アベイラビリティゾーンの障害が「中核的な取引サービスの長時間の停止」を引き起こしたと投稿した
- Coinbase はその投稿で、主要な問題は完全に解決したと述べた
クラウド市場の文脈
- AWS はクラウドインフラ技術市場のおよそ 3分の1 を占める
- AWS は数百万社にサービスを提供している
1件のコメント
Hacker News の反応
AWS US-East 1 は相変わらずインターネットのアキレス腱
複数リージョンやアベイラビリティゾーンにまたがって構築することはできるが、AWS は US-East 1 の問題がより広範な影響を及ぼす事故を繰り返しており、AWS がほのめかすほど冗長性や復元力が高くないように見える
中国以外のパブリッククラウドにおけるすべての識別・アクセス系サービス、つまり社員が「aws パーティション向け IAM」と呼ぶものは us-east-1 に集中している。アカウント、課金、権限を一貫して見るには、実際こうした集中化が必要になる
IAM も完全に独立したソフトウェアスタックではなく、DynamoDB などいくつかのサービスに依存しており、それらのサービスは逆に IAM に循環依存している
us-east-1 の障害中でも、他リージョンで既存の認証トークンやセッションを使い続けられることはあるが、新しいトークンを発行できないことがある。昔勤めていたときは、障害が終わるまで閉め出される可能性があるので、オンコール担当に SSH セッションや AWS コンソールのブラウザタブを閉じるなと言っていたのを覚えている
この 3 年ほぼずっとスタートアップを use-1 で運用してきたが、リージョン障害は 1 回だけで、それも部分障害だったので大半のインスタンスは影響を受けなかった
正直、顧客のものも全部 use-1 にあるので、障害が顧客と相関するという利点はある
幻想の魔法の国では、負荷は複数のクラウドプロバイダに均等に分散され、単一障害点 は存在しない
最初の彼女とも上手くいき、双子は英語と韓国語が堪能で、大規模サービスをデプロイするときに AWS 1 社だけに依存してはいけないことも分かっている
アメリカの医療費も払える。だが現実ではまた一日が過ぎ、AWS US-East 1 ひとつでインターネットの大半が倒れ得る
2 リージョンなら 2 倍の容量、3 リージョンなら 1.5 倍の容量を用意する必要があり、マルチリージョン構成ではマシンをあらかじめ動かしておかなければならない。障害中にインスタンスを立ち上げたり容量を確保できると期待してはいけないし、マルチリージョンホスティングの追加の複雑さにも対処しなければならない
複数リージョン／アベイラビリティゾーン構成がここまで露骨に見せかけっぽく見えるのに、みんなでクラウド宗教の教義みたいに信じているのは少し滑稽だ
こういう賭けは危険だ。AWS を落とせる社員のような人が 賭け をできてしまうから
こうした賭けは見た目ほど無害ではなく、賭けた人が結果に影響を与えたり変えたりできる場合が多い
全体として、こうした予測市場が インサイダー取引 やネガティブなシナリオを誘発し得るという主張には同意する。そういう状況を利用して利益を得る動機が生まれる
データセンターの冷却はほぼ事前に計画されていて、冷却できる以上のものは設置しないと思っていた
ここでは 冷却設備 が故障したのか、過熱に外部要因があったのか、それとも Amazon がデータセンターの冷却能力をオーバーブッキングしているのかが気になる
詳細な原因は教えてもらえなかったが、各階と屋上の間の配管は冗長化されていなかったようで、修理にはほぼ 24 時間かかった
データセンターの冷却は、他のあらゆるものと同じで 過剰 provision と 過少 provision が同時に存在する
大型の熱交換設備は N+1 で、非常に重要な小規模負荷施設では 2N/3N 構成になるので、過剰 provision だ。定期点検のために停止が必要で、従来のデータセンター部品より故障率が高く、専門人員と長い調達期間を要する機械修理が必要だからだ
大規模施設では N が大きくなるほど、冷却が N+3 以上になっていることも珍しくない。常に何かを整備しているか、もう存在しない部品を工場で新造する必要があり、設備総入れ替えより安いので、部品待ちの装置が出てくる
一方で、施設内のすべてのコンピューティング容量が平均電力使用量から突然 100% に跳ね上がると冷却能力を超えてしまうので、過少 provision でもある。電力や他の経路もよく過負荷になり、この業界の本質は過剰販売に近い
普通は大きな問題にならない。コンピューティング負荷が全容量の 100% まで跳ね上がることはまれだし、跳ね上がっても長続きせず、冷却や電力容量を綱渡りの状態で施設設計するわけでもないからだ
問題は、複数の出来事が重なるときに起きる。平均負荷の 200% を処理できるよう冷却システムを設計し、保守や障害に十分な余裕を持たせている
火曜日に修理業者が設備 1 台を見に来てベアリング不良を見つけ、別州から部品を持ってこなければならず、ファンアセンブリを壊すリスクを避けるため夜通し停止しておく
隣接する 2 台の冷却装置が少し強めに稼働し、そのうち 1 台には少しアンバランスなモーターか、緩んで発熱していたヒューズがあり、何年も持ちこたえていた部品が増えた稼働率のせいで飛ぶ
これで N+2 施設で 2 台失うが、平均負荷 200% 基準なのでまだ致命的ではない
最初に故障した装置の反対側にある 3 台目の装置でも、負荷が高まった状態で欠陥が表面化すると、N+2 施設で 3 台失う。それでも平均負荷 200% 設計なので、まだ大惨事ではない
だが午前 4 時なので現場オペレーターはこの欠陥を直せず、業者は 7 時に起きて 9 時に到着する。その間に負荷が上がり始める
こういうことはアメリカのどこかのデータセンターで毎日起きていて、おそらくどのデータセンターでも年に 1 回くらいは起きる
次に起きる出来事との合流がニュースになる部分だ。大口顧客の 1 社が、今こそ大規模なバッチ処理を始めるのにちょうどいい時間だと判断する。あるフィンテック企業が市場開始前に大きなモデルを回すとか、石油会社が新油田の高速分析を走らせる
VM を 10,000 台新規に立ち上げる。普段なら余剰容量があるので問題ない
だが冷却は平均冷却能力の 200% でしか計画されておらず、今回は適度に忙しいノードではなく、最適化された高負荷の数値計算を実行して最大電力を引き出し、最大の廃熱を出すノードだ
総マシン数ベースの負荷だけでなく、平均廃熱の影響も大きくなる。そこで連鎖障害が起き、冷却は N-4 になる
サーバーファンがさらに高速回転して電力を余計に消費し、冷却は N-5 になる。警報があちこちで鳴る
冷却装置の安全装置が、負荷と冷媒圧力の上昇に応じて次々に作動し、冷却は N-6、N-7、そして 0 になる
今年 EU では Hetzner のほうが AWS より稼働時間が良かったのか気になる
Hetzner の UI はかなり分かりにくく、管理しづらいと感じる
関連記事: AWS EC2 outage in use1-az4 (us-east-1)
https://news.ycombinator.com/item?id=48057294
いつも East 1 だ。冗談はさておき、east-1 が他リージョンと比べてなぜこんなに頻繁に落ちるのか理解できない
アーキテクチャ的には他リージョンとかなり似ているはずに思える
他リージョンより負荷が大きく、最初に作られたときは経験も少なかっただろうから、技術的負債やアーキテクチャ／エンジニアリング上の負債も多そうだ
記憶では IAM や一部の S3 設定のように、east-1 を単一障害点として依存しているサービスもある
Coinbase は複数のアベイラビリティゾーンが落ちたと言っていたが、AWS の発表では 単一アベイラビリティゾーン だけが影響を受けたという内容だった
もっと詳しい人がいるのか気になる
us-east-1 でシステムを動かしているが、事故中は az4 の外でも、これまで見たことのない説明しづらい断続的な接続問題が見えた
複数の環境のうちいくつかで、単一アベイラビリティゾーンの EBS ボリュームが少し悪化しただけで、明らかに単一アベイラビリティゾーン（use-az4）の問題だった
前に「友達なら友達に USE1 を使わせない」という言葉を見たことがあるが、Slack に USE1 とそこへデプロイしたものが全部壊れたというメッセージが流れたとき、その言葉を思い出した
ここのコメントには、us-east-1 は集中化されていて AWS の 単一障害点 だから直すべきだ、そこに載せるな、というお決まりの話が多い
今回の件は、マルチ AZ リージョン内の 1 つの AZ にある 1 つのデータセンターの問題だった
IAM や R53 などがそこに集中しており、それらのサービスを分散化してクロスリージョン構成にするのは良いことだ。しかし us-east-1 自体は、すでに 6 つの AZ があり、2026 年予定の 7 つ目の AZ まであるマルチ AZ リージョンで、AZ の中にも複数のデータセンターがある
記憶している限り、IAM のようなグローバルサービスが落ちるときは、「クロスリージョンだったら死ななかった」というより、実装や依存関係のバグであることのほうが多い
今回は AWS 全体のグローバルサービス障害ではなかった。より大きな影響を受けたように見えたのは MSK くらいで、それは AWS というより Kafka 側の問題である可能性が高い
なぜこういうものを海の近くに建てないのか気になる。原子力発電所のような、冷却能力 を多く必要とする施設もそうではないかと思う
熱交換器を置いた 2 ループ循環で熱を逃がせばいいように思える
1990 年代には世界のインターネットトラフィックの半分近くが MAE-East を通っており、その結果 AWS は最初のリージョンをそこに置いた。us-east-1 は eu-west-1 より 2 年、us-west-1 より 3 年早く始まっている
データセンターを建てられる人材や供給できる業者が集まるにつれ、Dulles Corridor は多くの企業のデータセンター主要ハブになった
AWS では us-east-1 が最初のリージョンなので、圧倒的に最も複雑で癖が強く、他の AWS サービスの多くの コントロールプレーン がここに依存するようになった。そのため他リージョンより頻繁に落ち、落ちるとスペインの eu-south-2 と違って全国ニュースになる
NoVA は工場ではなくデータセンターの事例にすぎず、Paul Krugman がノーベル経済学賞を受けた研究テーマと同種の経済クラスターだ
ひとつは Hosting.com の SOMA データセンターが熱くなりすぎて、屋上からホースで水をまいて冷やした事件で、もうひとつは Alibaba の Chai Wan データセンターが熱くなりすぎて、コントロールプレーンを含めそこで動いていたものがすべて落ちた事件だ
だから海に近いことが 緊急放熱 の面で追加の利点になるとは思わない。熱を外へ逃がす能力は決まっていて、海辺でも Nebraska のど真ん中でも、システム全体は一定の性能を満たすよう設計される必要がある
スライドにはデータセンターの立地決定に影響する要因が並んでいて、十分な用地や、そのデータセンターで働く 熟練人材 を確保できるかといった項目がいくつも含まれていた。次のデータセンターの場所選びに政治が絡むこともあると言っていた
海岸の土地ははるかに高く、逆に人里離れた海岸地帯まで行くと電力アクセスが悪い可能性が高い
海岸の用地はたいていより激しい気象現象にもさらされる
予測しにくいことも起きる。Diablo Canyon 原発では、漂流物やクラゲの移動によって 海水冷却取水口 が詰まる問題が起きた
https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
水は十分に深くなければならず、そうでないと表面温度まで温まってしまう。また、従来の蒸発冷却と価格競争できなければならない
この方式がうまくいく教科書的な事例は Toronto だ。海岸から比較的近い場所に深い 淡水湖 があり、都心は不動産が高くて従来方式が難しい
https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System