WEBサーバがスタンドアローンコンプレックス-冷房壊れてアッチッチの巻
こんにちは。
AWSの東京リージョンで障害が発生しましたね。
冷却装置が故障したために、サーバが加熱されて〜ってのが原因らしいですね。
クラウド事業者で障害が発生するのは、人為的なオペレーションミスか、データセンターのファシリティ周りが主って印象があります。
(過去、北米のリージョンでは電源足りなくてダウンとかあったはず)
花金が潰れたエンジニアも大勢いるのではないでしょうか？ご愁傷様です。
私もソフトウェアエンジニアの端くれですので無傷とはいかなかったのですが、事業的にノーダメージの範疇でした。
ちなみに、シングルAZ構成です。
なぜシングルAZで運用するの？バカなの？
あんな、ElasticacheとWEBサーバを同じAZに寄せてな、少しでも通信レイテンシを減らしたいねん。
という事情のためです。
なお、RDSはmulti-az構成、Elasticacheもリードレプリカが別azにいる状態。
なので、Elasticacehのマスターのazで障害が起こったとしても、リードレプリカの方をマスターに昇格させて、そこのazでwebサーバを立ち上げればなんとかサービスを継続できる構成ではある。
まあ、今回の場合だとALB自体がおかしくなったケースもあるのらしいので、そう簡単にはいかないでしょうが。
今回起こった事象: Webサーバが1台だけボッチになった
Webサーバが1台だけ通信不能になりました。多分、インバウンド、アウトバウンド両方
他のwebサーバは確認した範囲では問題なかった。
Elasticache、RDS共に健在。
なんですが、ネットワーク周りでどんな影響があるか分からなかったため、サービスはメンテナンスモードに突入。
あとは、EBS周りでも障害が起こってたせいか、RDSの定期バックアップいつもどおりの時間で終わらなかったぐらいですかね。
軽微ですんで良かったです。マジで。
今回はAWSのコンソール自体に障害の影響が出てまともに表示されなかったりしたので、最初アラートが飛んできたときはあせりましたね。
マルチAZ、マルチリージョン、マルチクラウドにすべきか？
サービスに求められる可用性とお金との相談ですよね〜。
うちの場合は上記の通信レイテンシの事情を理解してもらった上で、「AWS自体の障害が発生したら天災と思って諦めてください」で握ってます。
普通のWebサービスでAWS上でのマルチAZまでならインフラのランニングコスト増だけで済むかと思うんですけど、マルチリージョン、マルチクラウドの構成となると、データレプリケーションとかで構築の難易度上がるし、きっとNetflixみたいにディザスタ・リカバリの訓練してないと、いざ障害が発生しても対応できないでしょうね。
結論
全部夏のせいだ
