読者です 読者をやめる 読者になる 読者になる

sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

S3 で発生した障害の影響はデカかった [cloudpack OSAKA blog]

ナスです。

米国時間 2/28 に発生した S3 の障害のニュースは、皆さん見られてるかと思います。日本時間で夜中だったので、実際に障害の影響に直面した方は偶然にも少なかったかもしれません。

jp.techcrunch.com

今回の件で初めて知りましたが、S3 っていろんな web サービスが使っているんですね。Business Insider や Slack も S3 を使っていたようで、サービス影響があったみたいです。私は寝てたので全く気がつきませんでした…

 

SLA とその考慮

S3 には SLA があって、月あたり 99.9% の使用可能時間が定義されています。
サービスレベルアグリーメント - Amazon S3 | AWS

SLA はあくまで SLA なので、当然障害などでこれを下回る可能性はあります。AWS の場合は、下回ったら返金かサービスクレジットがもらえるだけです。そんなバカな!って思った方は、もう一度 SLA と言う言葉の定義を再確認しましょう。

で、今回の障害では 4 時間くらい S3 が自由に使えなかったわけですが、これを AWS のせいにするのは簡単です。ですが、これを機に、本当に落ちたら困るサービスを設計する時は、何かのサービスやリソースに依存する設計はやめるように改めましょう。本当に数時間落ちたら困るシステムやサービスで実際に同時間落ちたら、それは設計が悪いってことです。

基本的には、使った分だけ支払うモデルなので、うまく使えば安く済みます。が、特定のものに依存して安く済ます=障害でサービスが多少落ちても許容する、ということを関係者全員で共有しておく必要があると思います。

 

オンプレミスでも同じです

今回の件で「やっぱりクラウドは〜〜」的な論調で話してたり SNS 等でコメントされている方もいらっしゃいますが、別にクラウドは関係なくて、オンプレミス環境でも起こりうることです。今回は 4 時間程度で済みましたが、これオンプレミスだと業者手配とかでもっとかかる可能性だってありますよね。

全てはシステムやサービスの設計、運用設計にかかっているわけです。

 

というわけで、全てを AWS のせいにせず、そのサービスの要件にあった設計を心がけましょう、というのを私も含め皆さんも再認識してもらえたらと思います。

 

って、うちの社内の人が言ってました。私は、へー、って思いながら話を聞いてました。