AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告
AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告 2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。 下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。 当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。 そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、 複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。 と説明されていました。 複数のアベイ
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ページを開く
