TOP > IT・テクノロジー > AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず - Publickey

AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず - Publickey

108コメント 登録日時:2019-08-26 00:45 | Publickeyキャッシュ

2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは日本語での詳しい報告を公開しました。 報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。......

Twitterのコメント(108)

参考まで。🐶
AWS障害の報告書をしげしげと読んでたけど、PLCとか。何ぼAmazonでもそこの保守部隊を自前で抱えてるとは思えない箇所だよなぁ。
「やっぱAzureだな」とか言ってたら、同じようなトラブルを2年前に起こし済みだったという・・。 AWS、冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
ガンダムF91かバトルテックみたいだな。
物理的に分散できるといいんだけどね……災害対策にもなるし
そういえばナタンズのあの件も当初障害だと思われてたな、大丈夫?/
根本はSWバグ。論理から物理へ障害が移行していったわけですか。
バグで片付る?
試験した、なんの試験した?
って話になる
AWS大丈夫?
単一のAZだけだったって事でいいのかな。やっぱり可用性を求めるならマルチAZはしっかりやっておかないとですね。
空調を止めれる事が出来ればオーバーヒートしてシステムが再起動する。その隙に侵入すれば核を止められる。そうだろジョン? / …”
あの長い分かりづらい公式文書をたった一行のタイトルにまとめてる。素晴らしい >>
非常系の実動作確認は大事と。
該当AZのELB含んでるとマルチAZ構成のELBでも障害起きるって本当なの?マルチAZのRDSも死んでたって話も見かけるけど、公式な発表は見当たらないのはAWSが隠し事してるのかな?? / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェ…”
めも。内容を確認するだけで、胃痛が... (=_=;)
冗長設計とか当該機器納入した業者は、頃大変だと思うなぁ。(理不尽な突っ込みが無いことを祈りたい)
>AWS、東京リージョン23日午後の大規模障害について詳細を報告。-
障害が発生しないシステムは無いからね。どんなに可用性を高めたとしても、ね。
ボーイング737MAXみがある /
報告がこれだけの早さで当たり前のように上がっているのはすごいなぁと思う。
ソフト・ハード・ヒトが全部絡まった結構込み入った複合原因だったのね。冷却システムって素子によるものなのか空調だったのかはこの記事だけではよくわからなかったけど、元ネタには載ってるのかな。
アマゾンが燃えてたのは別のニュースなはずだろって(´;ω;`)… /
6時間やったか・・・ /
やはり熱中症だったか
>
ハード故障じゃなくてソフトバグとなー
直接は関係ないけれど、クラウドに大量のデータを保存するならば、異なる2つのサービスに同期的に保存しておくほうが安全かもしれないなと思った。
データセンターはAWS自前のものなんかな?
自前じゃなかったら冷却システムはデータセンターのもの?
知らない言葉が多くて頭に入ってこないw
AWSの障害、PLCの通信エラーが原因とか業界の話だった。
@hikasu


冷却制御システムのバグによってサーバがオーバーヒートとの事
先日のAWS障害、冷却制御システムのバグによるサーバのオーバーヒートとのこと。
自動ないし手動の復旧手段は3重に用意されてたが、PLCが単一故障点になったので全部失敗した、みたいな感じだろか
どうしようもねー感がすごい /
サマーウォーズでスパコン冷却用の氷が持ち去られて熱暴走したシーンを思い出したけどあんな感じかね?
Multi-AZにするってのが基本ですな。
世のサービスレベル目標とかリスク受容まわりで再考がおこるよいきっかけなのでは。
一方で、煽り言葉でバランスしないコスト増を進言するような向きがアレをナニするようなことがないと良いな、とも…
あまぞん日本の夏に負ける
かわいそう…
年中氷点下のAZが最強だな 石狩も夏は一応暑いんで
先週のAWSの障害の件,影響は一つのAZだけだったとのことだけど,PayPayみたいな決済サービスもシングルAZ構成だった?
そうかといって、北海道にサーバー基地を据えたら今度は『大規模停電』に見舞われたり(例・さくら)と、『負荷が掛かっても安定したデータストレージ』の確保への道は遠い…(-_-;) / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェ…”
該当AZでCloudfront + ALB + APIGateway + Fargate + Lambda + Auroraで組んでたシステムが死ななかったので、EC2とEBSが主っぽいな
こわい »
今回のAWSの大規模障害は、制御システムのバグから始まったようですが、まだバグの原因は調査中みたいですね。。
たしかにこういう計り知れないほど大きなシステムほど、どこか支障が出た場合に備えて利用側はリスクヘッジを考えないとですね😓
ちょっと気になるのが ”Amazon ELBでエラーが発生した、といった利用者の声も” というところで、ELBが気絶してたらMulti-AZ構成にしても意味なく無い? / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操…”
👉シェア👉 - B!
何段階も対応手段があったけど、全部失敗したという感じか。ここまでやっててもダメなときはダメなんだから、結びにもあるけど止まったときにどうするかを考えておかないとダメよね。
AWS、東京リージョン23日午後の大規模障害について詳細を報告。
これが素早く出てくるだけでもAWS使おうって思う
「障害の原因は冷却制御システムのバグによってサーバがオーバーヒートしたため」へぇ>
制御システムがバグってた上に非常時用の冷房最大化が機能しなくて、過熱で基盤破壊が起こったと。フェイルセーフって難しいですよね。
冷却システムのMulti-AZ化が必要そう /
意外と物理的なことが原因だったのか…
たかが冷却システムでこれなので、エヴァが制御不能がデフォなのはしょうがないな、という気持ちになった。
“障害を引き起こしたサーバのオーバーヒートの原因となったのは、データセンターの冷却制御システにバグがあったためだと説明”
Amazonの東京DCは建設中に燃え上がったり色々大変だな。DCは社会インフラの新たな脆弱性。エアコン故障するだけで社会基盤が止まる。恐ろしい恐ろしい / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作…”
とはいえ数時間で治るってのはとても大きい。オンプレだとこうはイカない。
「最悪の事故が起こるまで人は何をしていたのか」(草思社文庫)という本を読んでいたところ、AWSの事故が起きた。
再発防止のために、過去から学んで欲しい。

「AWS、東京リージョン23日午後の大規模障害について詳細を報告。」
ここまで手厚い多層防御のすべてを突破されたということは、逆に、1つ2つの層はしょっちゅう突破されているということだよな。オペレータはとても忙しそうだ / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手…”
単なる冷却システムの故障だけじゃなく、尽く耐障害の仕組みが稼働しなかったのかー。 /
金曜日はヒヤヒヤしました。/
作業者の人たいへんそう|
マルチAZは基本だなぁ。マルチリージョンや他のクラウドサービスに〜みたいな話でてくると、それはそれで辛い。/
"障害の原因は冷却制御システムのバグによってサーバがオーバーヒートしたため…障害発生から約3時間後の15時21分に復旧"
お疲れ様でしたという気持ちと、オンプレでここまで用意できないからこれからもついていきます!!という気持ち。
---
フェイルセーフも手動切り替えも準備していたけど作動せず。とのことだが、うーん。。。
この記事の時点では、ELBに関してAWSからの言及は出てないのか。
いざという時にBMCがつえない感じに似てるね(白目:
ハード制御を「直接または組み込みプログラマブルロジックコントローラ(PLC)」でやっているのか。
ロジック誤り、ループかな
なるほどなぁ。。。
自然には勝てないというのを感じた。 /
AWSに工場の設備データが乗っかる時代には、なんとも怖いニュースよな。DC運営での信頼性工学ってどの程度進んでるんだろ。
データセンターでも冷却システムやっぱ大事なのね。サマーウォーズの氷柱は正しかったと /
Azureが2年前に経験済みの障害だったのか…
こういう事故が起こったときに、インフラの裏に人の手の存在を実感したりもする(´・ω・`) どつかれさんです(´・ω・`) / - Publi…”
お、細かい情報が出てきたな
今日はこの影響調査からスタート/
マルチAZ前提にしていないと、障害が起きると説明に使える。/
実に興味深い

-
Microsoftも似たような事ありましたね。
「オンプレミスであってもクラウドであっても何らかの障害から逃れることはできません。」
これはわかりやすい。
冗長化してあれば大丈夫だったということだった。
してなかった場合、可用性は普通くらいになる。
映画だと手動操作で対応出来て復旧出来るんだけどね
あとで読む。
結局マルチazだったら大丈夫よ、って話なのか
Amazonのレポートが早くて詳細。ユーザー側の対策としては、AWSの設定で複数のアベイラビリティゾーンに冗長化させておくことを推奨。Amazon自身の対策としては、空調システムが非常時はPLCをバイパスして最大冷却モードに入れるように改修を施すとしています。わかりやすい。
ハード障害じゃなくてファームのバグだったんか -
idcfと違って、awsでapiの飽和やコンソール影響を障害報告しないってことは、aws側でそのレイヤーは監視報告の対象にしてないってことなのかな。
azureやgcpはどうなんだろう。
データセンターも原発も人間の心も冷却システムがバグるとやばい。
二重、三重の安全策に失敗だなんて運が無いと言うか何というか…
AWSでも対策で失敗するぐらいだから、カオスエンジニアリングの重要性を感じる。
報告出ました。「直接の原因は東京リージョンデータセンターで使用されている冷却制御システムにバグがあったこと」。◆
マルチAZで組んでもELBが正しく縮退しなかったケースが結構あるようだけど、どう設定していればこの規模の障害を乗り越えられるのかガイダンスが欲しいな / “AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動…”
>"マルチアベイラビリティゾーン構成にしておくことで可用性を保つことができた"
なるほどね?
冷却システムでしたか。
最大冷却システムモード! /
過去に無かったというソースが欲しい
---
また、今回のAWSの障害は東京リージョンにおけるはじめての大規模障害といえるでしょう。
昨日、用事帰りに担当案件でHWトラブルがおきて”クラウドだったら”なんて思っていたけど、これ見るとこっちもなかなか
結局multi-AZにしててもダメだった説は闇の中か……
これってBCP考えてなかったってことでは・・・ ないしはテストしてなかった>
単純な問題として東京暑けど、いずれにしても熱はダメよ。ダメダメ。
冷却システムにバクがあると日本のWebが止まる、ピタゴラスイッチ感
冷却システムの納品業者真っ青
単一AZの障害だったと。しかしAWSのバックエンド運用って興味あるわー。利用者側からさっぱり見えないブラックボックスでしょ?どうなってんだろう。絶対現場見てみたい(障害と関係ない >
そういう話じゃないってのは分かっているけど、うちも冷却やメンテはしっかりするようにしよう…… /
以上

記事本文: AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず - Publickey

関連記事