AWS障害、大部分の復旧完了 原因は「サーバの過熱」
コメント
注目のコメント
今日は色んなところでドタバタでした。原因はデータセンターの冷却システムに障害が起きてたということで、おそろしく熱いサーバールームになっていたと予想。
きちんとawsの報告読んだわけじゃないですが、記事によると単一のaz内での障害ということで、マルチazでクラスタリングできていない人を中心に被害にあったと思われます。てことで、これはクラウドが悪いというわけではなく、設計が良くなかったという結論になりそうですね。
また少し勘違いに繋がりそうなコメントがピックされていますので補足します。awsはSLAを定義しており、これを下回った場合、請求すれば後に使えるクレジットを受領することができます。
例えば一般的なサーバであるEC2の場合、99.99%をサービスコミットメントとしていて、利用している１つのリージョンが99.99%以上稼働しなければ、クレジットの提供対象になります。これは1ヶ月あたり約4分停止したら提供対象になることを意味します。
ただしややこしいのが、1つのリージョンの稼働であって、1つのazの稼働ではありません。なので今回のようにどれだけ1つのazで使えない時間が発生したところで、クレジットの提供対象にならないのです。
ここのルールがわかると理解できると思うのですが、awsとしてはリージョン全体でサービスの可用性を担保できるようにビジネスを展開しており、単一のazの可用性は担保していないです。そのためクラウド上に構築するサーバーに求められる設計としては、マルチなazに配置し、単一のazが倒れたときでも運用を続けられる設計が必要になる、という結論になります。
***
多くの注目が集まってしまったため追加で補足します。
今回の障害範囲は多岐にわたるので、ALBやRDSのレスポンスが返ってこなかったりと、マルチazにしていたからといって完全に防げた問題ではありません。なので今回落ちたサービスはシングルazだったのか、という訳ではないです。マルチazでもオートスケールをきちんと機能するようにできていなければ、負荷によってサービスは継続できない訳ですし、色んな状況があります。要はクラウドであっても、機械は必ず壊れるので、単一、az、リージョン、サービスと、壊れるスコープを定義して、サービス継続の重要性とコストを天秤にかけ、必要に応じて障害対策が必要ということです。AWSの東京に設置されたデータセンターは4つ。
そのうちの一つは近所にあるって話をamazonの
社員の方にしたら、社員ですら知らないのに！
と驚かれてました。
まぁWikiLeaksに載ってたんですけどね笑
もうひとつうちの近くにデータセンターありますが、
そちらはいつも屋根から水蒸気がもくもくと
まるで煙のように立ち昇っています。
気づいたら社内からサーバがなくなり、
忘れがちになりますが排熱処理って
きっと大変なんだろうなぁと、
この件の原因を知り再認識しました。復旧に携わったエンジニアの皆様，本当にありがとうございました。
今後はしっかり対策いただけるとありがたい，という気持ちも正直ないわけではないのですが，一方で，生命・身体に関わるような洒落にならないことでも起きなければ，どうこう言わずに「ドンマイドンマイ，お疲れ様」で済ませる寛容さが社会全体の空気として，もっとあっても良いのかなと思います。
（NPのコメントではお見掛けしませんが，かなり憤慨しているご意見もネット上では見られますね。迷惑を直接被っている場合には，もちろん，そりゃ腹が立つよなあとは思うところです)
・・私自身が完璧からはだいぶ遠い人間なので，社会に完璧を求めると結局自分が窮屈になるからっていうめっちゃ自分本位の考えではあるのですが・・
