AmazonのAWS「S3」に障害が発生してネットは大混乱、復旧されるも影響は残っている模様

日本時間の2017年3月1日未明、Amazonが提供しているクラウドストレージサービスの「S3」で大規模な障害が発生しました。同サービスを使っているウェブサービスが多かったことからネット上では大混乱が生じていましたが、障害発生からおよそ3時間後に復旧しており、事態は収束に向かっています。

The Amazon S3 Outage Is What Happens When One Site Hosts Too Much of the Internet | WIRED
https://www.wired.com/2017/02/happens-one-site-hosts-entire-internet/

AWS S3で高いエラー率が確認されたのはアメリカの太平洋時間で2月28日午前のこと。日本だと3月1日未明～早朝にあたります。AWS公式Twitterアカウントは事象発生直後の日本時間3月1日4時17分(現地時間2月28日11時17分)に「S3で高いエラー率が発生中。復旧に向けて懸命に作業中」と報告。

40分後の4時57分、AWS公式が「S3に関して、根本的な原因を究明できたものと思われます。現在懸命に復旧中。今後、全サービスについてのアップデートはダッシュボード上に反映されます」とツイート。

記事作成時点でAWS Service Health Dashboardを確認すると、大部分のサービスは復旧が完了している状態です。

AWS Service Health Dashboard - Feb 28, 2017 PST

通常の状態にあるサービスは「Service is operating normally」と表示されていますが、障害が発生して復旧済みのサービスには「[RESOLVED] Increased Error Rates」([解決済み]エラー率の上昇)と表示されています。

不具合が続いているサービスには「Increased Error Rates」と表示され、「more」をクリックすると発生している問題と対処の詳細が表示されます。

今回の不具合では多くのウェブサービスが接続できなくなるという事態が引き起こされており、AWS S3への依存率の高さを垣間見ることができました。影響を受けたサービスとしては、Q&AサイトのQuora、ニュースサイトのBusiness Insider、Twitter・Facebook・Instagramなどへの一括投稿や予約投稿を可能にするBuffer、グループ内でカード感覚でタスク整理ができるTrello、60以上のウェブサービスを連携させて新たな機能を実現できるIFTTT、ジョギングやサイクリングなどのアクティビティロガーのStravaなど、多岐にわたっています。

Which sites are down because of S3 outage? | Hacker News

また、「IFTTTよりも高機能」ともいわれるZapierでも障害が発生。サイトでは、障害の原因を明確に「Amazon S3に起因する」と指摘しています。

Zapier Status - Issues With our Upstream Provider Causing Availability Issues

The root cause was our upstream provider's (AWS) very popular file storage system (S3) started failing - which caused many issues for numerous websites across the internet - Zapier included.

なお、Amazon S3の規定ではこのような事態に対しては「サービスクレジット」が発行されますが、返金はされない模様。

サービスレベルアグリーメント - Amazon S3 | AWS
https://aws.amazon.com/jp/s3/sla/

サービスクレジットは、サービス利用者が支払うこととされている将来の Amazon S3 の支払に対してのみ充当される。アマゾンの裁量により、アマゾンは、エラーが生じた請求期間の支払のためにサービス利用者が使用したクレジットカード に対して、サービスクレジットを発行することができるものとする。サービス利用者は、サービスクレジットによって、ＡＷＳ からの払戻しその他の支払を受ける権利を取得するものではない。

そしてこの措置に対しては、自分で請求する必要があります。

サービスクレジットを受領するには、サービス利用者は、AWS サポートセンターにケースを申請することで請求するものとする。また、受領資格を有するとされるためには、クレジットの請求は、事象が発生した翌々請求期間の末日までにアマゾンによって受領されなくてはならず、以下を含むものとする。

1．件名欄に「SLA クレジットの請求」という言葉、
2．サービス利用者が請求するエラー率がゼロでない各事象の日時、および
3．エラーを記録しサービス利用者が請求する停止時間を裏づける、サービス利用者のリクエストログ（該当するログにおける機密情報は削除するか、「＊」印に置き換えるものとする）を含まなければならない。

当該請求にかかる月間使用可能時間割合が適用サービスコミットメント未満であることをアマゾンが確認した場合には、アマゾンは、サービス利用者に対して、アマゾンがサービス利用者の請求を確認した日が属する月の次の請求期間中に、サービスクレジットを発行する。サービス利用者が上記要件を満たす請求およびその他の情報の提出をしない場合は、サービスクレジットを受領する資格を失うものとする。

また、「例外事由」として以下の条件が挙げられています。

Amazon S3 SLA 例外事由
Amazon S3 の使用不能、停止もしくは終了、またはその他の Amazon S3 の性能の問題が、以下によるものである場合には、サービスコミットメントは適用されない。(i)ＡＷＳ契約第 6.1 項に定めるサービス停止の結果であ る場合、(ii)不可抗力、Amazon S3 の責任分界点の範囲外のインターネットアクセスまたは関連する問題を含む、アマゾンの合理的な支配の及ばない要因によって生じたものである場合、 (iii)サービス利用者または第三者の作為もしくは不作為の結果である場合、(iv)サービス利用者の機器、ソフトウェアもしくはその他の技術、および ／または第三者の機器、ソフトウェアもしくはその他の技術（アマゾンの直接支配の範囲にある第三者の機器を除く）によって生じたものである場合、または (v)ＡＷＳ契約に従って Amazon S3 を利用するサービス利用者の権利をアマゾンが停止もしくは終了させた結果である場合（総称して、「Amazon S3 SLA 例外事由」という）。可用性が、エラー率の計算においてアマゾンが使用する要因以外の要因の影響を受けた場合には、アマゾンは、かかる要因を、アマ ゾンの裁量で考慮し、サービスクレジットを発行する場合がある。

なお、あくまでも経験則ということですが、「EC2 t2 ファミリーはクソ不安定」「インスタンスをまとめて起動すると同じホストに配置されがちで同時に死ぬ」「EBSはガチャ」「99%の障害はコンソールには何も表示されていない」というようなまとめも存在。いくつかは確かに実感があります。

AWSバッドノウハウ集 2017/02 - Qiita
http://qiita.com/yayugu/items/de23747b39ed58aeee8a