AWS、複数のアベイラビリティゾーンで稼働していたアプリケーションでも大規模障害の影響があったと説明を修正。東京リージョンの大規模障害で追加報告

2019年8月23日金曜日の午後に発生したAWS東京リージョンの大規模障害について、AWSは追加の報告を行い、複数のアベイラビリティゾーンで稼働していたアプリケーションでも障害の影響があったことを認めました。

下記は大規模障害の報告ページです。赤枠で囲った部分が、8月28日付けで追記されました。

当初の報告は、障害の原因が空調装置のバグであり、それが引き金となってサーバーのオーバーヒートが発生したことなどが説明されていました。

そして障害の影響範囲は単一のアベイラビリティゾーンに閉じており、

複数のアベイラビリティゾーンでアプリケーションを稼働させていたお客様は、事象発生中も可用性を確保できている状況でした。

と説明されていました。

複数のアベイラビリティゾーンでも障害の影響を受けた

今回追記された部分を見ていきましょう。

まず、当初報告されたAmazon EC2、Amazon EBS以外のサービスにも影響があったことが示されました。

この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。

そして、複数のアベイラビリティゾーンで稼働していたアプリケーションであっても障害の影響を受けたと、次のように説明しています。

お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご利用しているお客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す)があったことを AWS では確認しております。

複数アベイラビリティゾーンで稼働していたアプリケーションへの影響はあくまでも「お客様の一部で、想定されるより高い割合でリクエストが Internal Server Error を返す」といった程度であることには留意すべきですが、当初の「複数のアベイラビリティゾーンで～（中略）～事象発生中も可用性を確保できている」という説明を一部修正するものだといえます。

具体的にどの程度の割合でInternal Server Errorが発生したのか、そして何よりも、ではどうすればこの影響を防ぐことができたのか？ については、

AWS では、個別の問題についての詳細な情報を、影響を受けたお客様に直接、共有を行う予定です。

と、個別対応するという歯切れの悪い説明になっています。

これまでAWSは、障害が単一のアベイラビリティゾーンに閉じているかぎり、アプリケーションを複数のアベイラビリティゾーンに対応させれば可用性を確保できると説明してきました。

しかし今回、一部とはいえその説明が有効ではない事象が実際に東京リージョンで発生しました。ネット上では「どうすれば今回のような障害に対応できるシステムを設計し得るのか？」について、多くの議論や意見が表明されており、真剣なAWSユーザーであれば誰でも、そのオフィシャルな答えを求めています。

現在はまだAWS自身が調査中なのかもしれませんが、なぜ今回のような事象が起きたのか、今後可用性を確保するにはどのような対策をとるべきなのか、などについて、AWSは調査後にあらためて広く説明するべきではないでしょうか。