先週AWSサーバに障害が起きいくつかのサービスがストップする、
アクシデントがありました
15日のAWS東京リージョン障害、原因は「主電源と2次電源の遮断」
興味深いことに、同じサーバを使っていてもストップしたサービスと
そうでないサービスがあり、そこから安全なインフラ設計が浮き彫りとなっていました
結論
結論からいくと、この2点がAWSサーバ障害を見据えた設計となります
詳細は下で深堀していきます
・マルチAZの設計をせよ(3AZ以上)
・コンテナ化して、サービス復帰を早くする
詳細
マルチAZのサービスが落ちたのはなぜか?
マルチAZとは
サーバの構成に複数のデータセンタ(AZ: Availability Zone)を用いること
データアクセスの分散を図り、安定した通信をおこなうことができる
マルチAZの設計をせよと上で述べていますが、実はマルチAZのサービスでも
落ちていました
共通していたのは2AZで構成されていたサーバで、実は複数のAZのトラフィックを
分散するAWSの機能「ロードバランサー」(ELB)が最低でも2つ設定する必要があり、
2AZのうちの片方がダウンしたことでロードバランサーに障害が起きていました
2AZで構成することで片方がつぶれても安全かと思いきや、
その実1AZと変わらなかったという残念な結果に...
そのため3AZ以上にすることで、片方のAZが落ちてもロードバランサーダウンによる
サーバー落ちを防ぐことができます
コンテナ化していたサーバはなぜ復帰が早かったのか
サーバー復旧にかかる時間には、コンテナ化の有無が関わっていたようです
障害があったAZにインスタンスを固定していると、コンテナ化していなければ
バッチや実行環境を移すのに時間がかかってしまいます
しかしコンテナ化していれば、サーバを切り替えてコンテナを実行すれば
実行環境をうつすことができるため、復帰が早かったようです
また「AWS Fargate」で運用しているサービスは自動復帰することができたようです
Fargateはサーバ管理をAWSに任せてコンテナを実行できるサーバレスのサービスのため、
サーバを自動的に切り替えることができたのでしょう