2019年8月23日のAWS障害に学びたい。

(2019/8/24)

2019/8/23にAWS東京リージョンで障害が発生した。多くの商用サービスに影響が出て様々な意見が飛び交っているけれど、技術部門としては障害原因と対策のみが重要なのであって、是非は無視して後学のためにこの件は詳細を追っていきたいと思う。

今のところ一番詳しいのは以下かもしれない。

https://www.serverworks.co.jp/news/20190823_aws_news.html

 

現状わかっている事は以下の2点だと思う。

・東京リージョンの特定AZで障害が発生した。

・発生個所はEC2とRDS。

だけど商用サービスのほとんどはマルチAZ構成をとっているはずなのに何故それほどの障害が発生するのかについて今後の情報を待ちたい。

 

(2019/8/27)

AWSは以下のように情報を公開した。

https://aws.amazon.com/jp/message/56489/

事象について要約すると、

・東京リージョン (AP-NORTHEAST-1) の単一のアベイラビリティゾーンで、オーバーヒートにより一定の割合の EC2 サーバの停止が発生した

・EC2 インスタンスと EBS ボリュームへの影響に加えて、EC2 RunInstances API にも影響が発生した。

・ EC2 インスタンスの起動、および冪等性トークン(複数のインスタンスを起動させる危険なく、インスタンスの起動をリトライする機能)を使用して RunInstances API を東京リージョンで実行した場合に、エラー率の上昇が発生した。

・その他の EC2 API や冪等性トークンを使用しない EC2 インスタンスの起動は正常に動作していた。この問題は、冪等性トークンを使用する Auto Scaling グループからのインスタンスの新規起動も阻害した。

・ EBS ボリュームのスナップショットの作成も、この期間にエラー率の上昇が発生した。

 

単純に考えると東京リージョンの単一AZのみで発生したのだから、機能的にも負荷的にも完全なマルチAZ構成のシステムは影響を受けなかったと読み取れる。

だがPayPayやユニクロ、大手オンラインゲームのサービスなどが軒並み影響を受けている。これらのシステムは本当にマルチAZ構成として不完全だったのだろうか。

 

 

(2019/9/17)

8/28に以下ページが更新された。

東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
https://aws.amazon.com/jp/message/56489/

AWSのサービスとして障害していたのはシングルAZの範囲。
ただし、冪等性トークンを使用したEC2 RunInstances APIにも影響があった。

8/28の報告では、Application Load Balancer を AWS Web Application Firewall や
スティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより
高い割合でリクエストが Internal Server Error を返す事象があったと報告されているが、
ELBスティッキーセッションはCookieを用いて同じクライアントのリクエストを同じサーバに分散するが、
対象サーバがヘルスチェックに失敗していれば違うサーバに振り分けることになる(はず)なので、
これがどう影響したのかはよくわからない。

クラウドは障害する。よって絶対に止められないサービスはマルチクラウドで、
かつ地理的にも別のリージョンにするという対策が必要なのははじめからわかっていた事だが、
いざ障害になってみるとサービス障害になるサービスが多くあった。それらが止まっても良い
システムだったのかどうかは、結局は採算との兼ね合いなので個々で今後見直しをするのだと思う。

ただ思うのはAZ障害によってトラフィックが輻輳してリージョン全体のAPIコールに影響を与える
という仕様は改善して欲しいと思う。