【IT】AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗
■ このスレッドは過去ログ倉庫に格納されています
2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは日本語での詳しい報告を公開しました。
報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。
8月23日午後に約6時間の障害。EC2だけでなくRDSも
報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。
日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生しました。この結果、当該アベイラビリティゾーンの EC2 インスタンスへの影響及び EBS ボリュームのパフォーマンスの劣化が発生しました。
障害の原因は冷却制御システムのバグによってサーバがオーバーヒートしたため。その冷却制御システムは、障害発生から約3時間後の15時21分に復旧します。
冷却制御システムの復旧によってデータセンターの室温が低下し、影響を受けたEC2インスタンスとEBSボリュームの大部分が回復したのは、障害発生から6時間後の18時半頃。一部についてはさらに復旧に時間がかかっています。
日本時間 18:30 までに影響を受けた EC2 インスタンスと EBS ボリュームの大部分は回復しました。少数の EC2 インスタンスと EBS ボリュームは、電源の喪失と過大な熱量の影響を受けたハードウェアホスト上で動作していました。これらのインスタンスとボリュームの復旧には時間がかかり、一部につきましては基盤のハードウェアの障害によりリタイアが必要でした。
マネージドサービスのAmazon RDSも同時に障害
また、今回公開された報告には含まれていませんが、この障害はAmazon RDSにも影響していました。Amazon RDSでは障害発生のタイミングはほぼ同時ながら、解消まで約10時間かかっています。
下記情報は記事執筆時点でAWSヘルスダッシュボードのRSSの中に残っていますが、いずれ消えてしまうはずです。
日本時間 2019年8月23日 12:36 から 22:05 にかけて、東京リージョンの単一のアベイラビリティゾーンで一部の RDS インスタンスに接続性の問題が発生しました。現在、この問題は解消しており、サービスは正常稼働しております。詳細はこちらをご覧ください。
この障害の詳細情報へのリンク先も今回の大規模障害の報告ページになっています。
つまり8月23日金曜日の午後の大規模障害の範囲はAmazon EC2、EBSだけでなく、少なくともAWSがマネージドサービスで提供しているAmazon RDSにも広がっていたことになります。ただし障害の範囲は1つのアベイラビリティゾーン内だったとされています。
（ほかにもこの障害との関係は未確認ながら、同時間帯にAWSのマネージメントコンソールが利用できなくなった、Amazon ELBでエラーが発生した、といった利用者の声もあがっています）。
以下ソース
https://www.publickey1.jp/blog/19/aws23.html こんな時にQRコード決済があるから財布いらねーなんてやったら支払いできずに4ぬパターンだな
障害のせいで店でアプリが起動しなくてポイントをもらい損ねた まるでMr Robotの世界。
一流のデータサービスは冷却まで自前でプログラムを書いて制御するのかね。 そこらへんのアホマンコが持ってる携帯扇風機かき集めて冷却すれば良いじゃん SNSに投`稿した「スタイル抜群.の.体.」.現`実.の`姿は`これ（画像）
http://whophotoo.xmlfence.com/qqsc.html 何でマルチリージョンにしないの？バカなの？死ぬの？ 最近のデータセンターの冷却は機械学習・AIが流行ってるらしいが、これはどうだったんかな？ >>1
たった一ヶ所でシステム障害とか、データセンターと変わらない件 クラウドは落ちることがある と書き込んだらAWSは違うと主張し続けてきた5ｃｈ
腐れ在日5ｃｈは、アフィ料に尻尾振りすぎなんだよ ＞この度の事象発生時、異なるアベイラビリティゾーンの EC2 インスタンスや EBS ボリュームへの影響はございませんでした。
＞複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。
なんかMulti-AZにしてれば大丈夫だったみたいな説明をAmazonがしてるけど、
Multi-AZでもサービスに支障きたしてたとこがちらほらあったんでそ？ DQN鉄筋工が咥え煙草で燃やしたデータセンタだっけ
一族郎党で韓国に逃げ帰って賠償バックレ ジャップ設備屋のゴミ空調が故障しただけかよ
AWS自体は悪くないのに本当に足を引っ張るなあジャップ設備
これを機に空調すら海外製をそのまま持ってくる風潮が広まれば良いね
品質最低なジャップ設備をデータセンターから駆逐しよう 多分、安くあげようとして吉田製作所辺りに工事を発注したんだな（） 高額エンジニアを雇えば問題ないと思ってたけど、
設備の方も多重請負が酷いんだろうな
設備の方も多重請負を規制しろ ジャップが、Amazon様に迷惑かけただとぉ？
死んで詫びろ トラブルはどうしようもないとしても、
一ヶ所こけたら、みんなこけるんだね。 >>17
むしろＡＷＳは局所的にわりとよく落ちるんだけどクラウド故にサービスレベルが高く算出されるという手品。 サービスレベルに関して「クラウド ＞ オンプレ」は幻想 フェールセーフに失敗するなんて有り得ない。
それはそもそもはじめからフェールセーフではなかったということ。 ダイキンのエアコンをそのまま付けていれば良いものを。余計な事をしくさって >>33
そうね
だな、信頼性が命でデータセンターや運用スタッフを自前で持つ金融機関ならともかく
普通の企業は自前で持つコストを考えたらクラウドを選ぶよなあ 熱制御のバグでダウンまで分かったが、もっと分かりやすく原因と障害対策、
今後の見通しを説明しろや、変なカタカナ英語を除いた日本語で。 人件費削減のツケだね
圧縮できた分を冗長につかえばええのに >>37
たぶんだけどＩＤＣそれぞれの空調制御と>>1の冷却制御システムはまた別のシステムなんだよ。
で、急に涼しくなったからＩＤＣ側で空調の設定を変えたら>>1のバグが発生とかそんな感じかと。
ＡＷＳといってもＩＤＣは色々だろうからアマゾン側で繋ぎ込みに失敗してたんだろ。
例えばＩＤＣ側空調システムの温度設定が「ＡＵＴＯ」に設定された場合とかかな？ アベイラヴィリティーゾーンがインスタンスでヘルスダッシュボードね
だいたい分かった こういうの損害賠償求められないのか？
ドスパラとか土曜の稼ぎ時に全店営業停止とかシャレになんねーほど被害受けてるだろ？ これみるとマシンオペレーター常駐するが、プログラムエラーで冷却ファン停止→熱暴走で集団自決（アクシズ押しながらジム自爆）な感じ >>43
月額料金のうち、ダウンしてた時間分の金額が払われる。 エアコンを24時間稼働してれば良かった話
経費削減で冷却制御システムなんて稼働歴が短いものを動かしてたから障害に出くわした
ダイキンエアコンを動かしてろっつーの 経費削減なんてことばかりやってるからこういう目に遭う こんなの直接温度を測定してればダウン前に気付けるだろ
一瞬でオーバーヒートする訳じゃないし >>1
非ITの大手企業の部長みたいな人たちに限って「クラウド」って言葉を過信してる人多いと思う
たぶんよく分かってないけどクラウドって言っとけば今風と思ってる ドコモのサービス色々停止してるんだけど
AWSが原因らしい
ネットワークサービス企業がAWSつかうのは
なんだか情けない 日本のバカ経営らしいけど >>43
100%常にサービス提供するとは宣言してないし、防ぐためのインフラ構築手法があるからね(ただし今回それでも落ちてたという話がちらほらあるにはある)
ユーザー側が予算ケチるなってだけ 釧路あたりの寒冷地にデータセンター作れよ。
過疎化してるしちょうどいいだろ。 >>55
AWS教信者集団に任せるなんて怖すぎるわ
無能経営者を洗脳するのは上手いけどw 基盤おいてるデータセンター、損害賠償問題でてんやわんやしてそう >>53
azureも2年くらい前に同じようなことになってた
今年GWで障害も起こしてるし
どっちもどっち
障害は必ず起きるから前提でシステム設計しましょうねってだけ とりあえずインシデントに登録して、問題管理にエスカレーションして、
変更管理で冷却の仕様を改善したらもう起きないでしょ。 ■ このスレッドは過去ログ倉庫に格納されています
