［速報］AWS、クラウド障害をわざと起こす「AWS Fault Injection Simulator」発表。カオスエンジニアリングをマネージドサービスで実現。AWS re:Invent 2020
Amazon Web Services（AWS）は、開催中のオンラインイベント「AWS re:Invent 2020」で、アプリケーションに対してクラウド障害のシミュレーションを行える新サービス「AWS Fault Injection Simulator」を発表しました。 クラウド上で稼働するアプリケーションの耐障害性などを高めるために実際にクラウド障害をわざと発生させて問題点をあぶりだす手法は、「Chaos Enginieering（カオスエンジニアリング）」と呼ばれています。 Netflixが2012年にカオスエンジニアリングのためのツール「Chaos Monkey」を公開したことで広く知られるようになりました。 参考：サービス障害を起こさないために、障害を起こし続ける。逆転の発想のツールChaos Monkeyを、Netflixがオープンソースで公開 今回発表された「AWS Faul
AWS大障害、冗長構成でも障害あったと公式に認める
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
AWS 東京リージョンで発生した大規模障害についてまとめてみた - piyolog
2019年8月23日 13時頃からAmazon AWS 東京リージョン でシステム障害が発生し、EC2インスタンスに接続できない等の影響が発生しています。ここでは関連する情報をまとめます。 AWSの障害報告 aws.amazon.com AWS障害の状況 障害発生時間（EC２） 約６時間 2019年8月23日 12時36分頃～18時30分頃（大部分の復旧） 障害発生時間（RDS） 約９時間半 2019年8月23日 12時36分頃～22時5分頃 障害原因（EC２） 一部EC2サーバーのオーバーヒートによる停止 制御システム障害により冷却システムが故障したことに起因 影響範囲 東京リージョン（AP-NORTHEAST-1）の単一のAZに存在する一部EC2、EBS、およびRDS。 発生リージョンは東京。東京近郊４データセンター群の内、1つで発生。 日本国内のAWSの契約先は数十万件とみられる。*
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS障害で本当に知っておくべきことと考慮すべきこと
