AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず
AWS、東京リージョン23日午後の大規模障害について詳細を報告。冷却システムにバグ、フェイルセーフに失敗、手動操作に切り替えるも反応せず 報告によると直接の原因は東京リージョンのデータセンターで使用されている冷却制御システムにバグがあったこと。これにより、緊急時の手動操作にも冷却制御システムの一部が反応しないなどでサーバが過熱し、障害に至ったと説明されています。 8月23日午後に約6時間の障害。EC2だけでなくRDSも 報告によると、障害は日本時間2019年8月23日金曜日の昼過ぎに発生。影響範囲は仮想マシンを提供するAmazon EC2とブロックストレージを提供するAmazon EBSのそれぞれ一部。以下、AWSの報告を引用します。 日本時間 2019年8月23日 12:36 より、東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、... - Sooey
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。 一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。 Resolved: Widespread Application Outage Herokuを4年間運用してきて最大の障害 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム アプリケーションのデプロイについてはプラットフォームの広範囲にわ
2019/8/23のAWS東京リージョン大規模障害の経過と原因まとめ - Qiita
2019/8/23に発生したAWS東京リージョンの大規模障害の経過と、現在確認すべき内容、今後の教訓などをまとめてみました。 9/24 16:00更新: 今回の障害の経過を受け、記事を整理いたしました。 8/23 12:36頃より特定AZにおけるネットワークコネクティビティの障害が発生 8/23 20:18頃、EC2は大規模障害から回復との発表あり 8/23 22:19頃、RDSも22:05頃までに同様に回復との発表あり サービス障害発生時間は8/23 12:36〜22:05 (約9時間半) 8/24 14:00以降、本障害の影響でEBSボリュームが回復不能となったアカウントに対し、個別のメールやPersonal Health Dashboardで通知あり 8/25 8:00以降、本障害の影響でEBSボリュームが回復不能となったアカウントに対し、個別に続報あり 注: メールが来ていなくても
米国東部（バージニア北部、US-EAST-1）リージョンで発生した Amazon S3 サービス障害について
日本時間3月1日未明に米国東部（バージニア北部、US-EAST-1）リージョンにおいて発生いたしましたサービス障害に関する追加情報についてお伝えいたします。 この度、Amazon Simple Storage Service (S3) チームが S3 の請求システムの処理に通常よりも時間がかかるという問題のデバッグを進めておりました。 その過程におきまして、9:37AM PST(日本時間 2:37AM)に、適切に権限を与えられたS3チームメンバーが確立された手順に従い、S3 の請求システムが利用するS3サブシステムを構成する少数のサーバを削除するコマンドを実行いたしましたが、その際、コマンドへの入力が不適切であったため、想定よりも多くのサーバが削除される結果となりました。 今回誤って削除されたサーバは２つのS3サブシステムに関わるもので、１つは、Index（インデックス） サブシステムであ
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く
AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。 Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。 この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。 コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。 2月28日
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おゆ＠元営業の AWS テックリード on Twitter: "クラウドインフラ新人勢ですが、今回のAWS障害で厄介だったのが5点。 ・一部のEC2インスタンスでAuto Recoveryが失敗していた ・running状態なのにステータスチェックが0/2（実質死んでる） ・pendingか… https://t.co/Z0na7cesat"
AWS障害で本当に知っておくべきことと考慮すべきこと
/blog/2014/11/1040/