2019年8月23日に発生したAWS東京リージョンの障害に関してのご報告 - 株式会社サーバーワークス
2019年8月23日に発生いたしましたAWSの障害につきまして、2019年8月28日にAWSから続報が発表されましたので報告いたします。 - 今回東京リージョンの1つのアベイラビリティゾーン(AZ)の一部にで置きた障害の影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものであるが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響があった。 - 調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響があったことが確認された - AWS では、個別の問題についての詳細な情報を影響を受けたお客様に直接、共有を行う予定である 東京リージョ
AWS大障害、ユニクロ・楽天・PayPayなど30社以上に影響
米アマゾン ウェブ サービス（Amazon Web Services）のクラウドサービス「Amazon Web Services（AWS）」で2019年8月23日昼ごろに始まったシステム障害の影響により、多くのAWS利用企業でトラブルが発生した。 AWSは東京リージョンを構成する4つのアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）のうちの1つで、仮想マシンサービスの「Amazon EC2」とリレーショナルデータベース（RDB）サービスの「Amazon RDS」に障害が起こったとしている。EC2については同日午後6時すぎに大部分が復旧したという。 アクセスできないトラブル続出 日経 xTECHはAWS利用企業に緊急で聞き取り取材をし、数社から回答を得た。東急ハンズは「販促キャンペーン中のEC（電子商取引）サイトが同日昼ごろ一時的にアクセス不能になった」（広報）とする。その後A
AWS障害が発生した場合に確認するページやサイトまとめ - production.log
概要 2019年8月23日 13時頃からAWS EC2の接続ができなくなる障害が発生しました。 このような大規模障害は滅多にないので、障害の情報収拾する際に「どこみりゃいいんだ？」となるので、この機会にまとめることにしました。 この記事ではAWSで障害が発生した場合に確認するページやサイトをまとめます。 公式情報 公式の情報は正確性はあるものの、速報性には欠けます。 そのため、後述する非公式情報と並行して確認する必要があります。 公式情報からは、下記2つの情報が得られます。 何がなぜ障害に繋がっているのか いつ復旧する見込みなのか この情報から、障害を回避するための方法や、自サービスの復旧見込みのアナウンス*1に役立てることができます AWSサービス全体の障害情報 AWSサービス全体の障害情報はAWS Service Health Dashboardで確認することができます。 status
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ボリュームが回復不能となったアカウントに対し、個別に続報あり 注: メールが来ていなくても
AWS障害、大部分の復旧完了 原因は「サーバの過熱」
8月23日午後1時ごろに発生した、米Amazon Web Servicesのクラウドサービス「AWS」の東京リージョンでの障害について、同社は午後8時18分、クラウドサーバの復旧がほぼ完了したことを明らかにした。制御システムの障害により、サーバの温度が上がりすぎたことが原因だったという。 同社によると問題が起きたのは、「Amazon Elastic Compute Cloud」（EC2）の東京リージョンを構成する4つのデータセンター（アベイラビリティーゾーン、AZ）の内の1カ所。AZ内の制御システムに問題が発生し、複数の冗長化冷却システムに障害が起きたという。結果として、AZ内の少数のEC2サーバが過熱状態となり、障害として表面化したとしている。 冷却システムは午後3時21分に復旧。午後6時30分までに、ほぼ全てのストレージ（EBSボリューム）とインスタンスが復旧したという。 同社は、障害
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
AWSのAZ障害で影響を受けた・受けなかったの設計の違い。サーバレス最高！ - GS2 Blog
みなさん、こんにちは。GS2 の丹羽です。 今日は大事件が起こりました。Twittetなどでも話題になったので皆さん知っているのではないかと思います。 japanese.engadget.com こんなブログを見に来てる人ならみんな知ってると思いますが、AWSの東京リージョンには3カ所のデータセンターがあります。 そのうち1カ所のデータセンターが完全に利用できない状態になりました。 その影響で様々なゲームも影響を受けたようです。 gamebiz.jp なぜAZ障害が様々なサービスの障害につながったのか さて、なぜ今回のようにAZがダウンするとこのような大規模な障害が発生するのでしょうか。 1. シングルAZ サーバはどこかのデータセンターで動いていてるわけです。EC2を使ってサーバを起動するときにもどのAZに配置するかを選びます。 この時に、一つのAZに固めてサーバを配置していた。あるいは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
