AWS障害について考えてみた。

どうもこんにちは
最近親知らずを抜いた後の抜歯腔が気になるエンジニアのOです。

2021年2月20日の深夜にAWSの東京リージョンにて障害が発生しました。
障害の大部分の解消に発生から約5時間後に要しました。
その約5時間に気象庁やオンラインゲームなど様々なサービスに影響を与えました。

障害の原因はサーバの冷却システムの制御でうまくいかなかったということです。
今回のような障害は、おととし（2019年）の8月23日にも同様な障害が発生しています。

このような障害に備えて「ディザスタリカバリ」を考える必要あると思います。
ディザスタリカバリとは、端的にいうと別拠点を用意しておき、障害の際には本番環境を切り替えるというイメージです。

AWSにで再び障害起きた場合に、影響を最小限に抑えるための対策として、以下の対応が可能であるのではと考えました。

• 3つのAZで組むMulti-AZ構造あるいは別リージョンでのディザスタリカバリを取る
• Lambda等を利用したサーバレス化→Linuxベースでないと動かないシステムではシステム機能の不足が考えられます。
• 他クラウドサービスやオンプレミス等への移行→オンプレミスを用意するとクラウドの意味合いが薄くなるのでナンセンスですが。また、ほかのクラウドといっても知見がないと対応している場合に障害が復旧するかもしれません。
• 定期的なAMIイメージの作成とデプロイ計画

といった対策が上げられると思います。

オンプレミス時代から「ディザスタリカバリ」といって災害対策環境を設置する企業も多くありました（特に大企業）
しかしながら、メインの環境のほかにもう一つ環境を用意するということはかなりの労力を要します。
マシン、電気代、拠点間通信、2環境の保守。いざ障害が起きた際のリカバリ手順の作成とトレーニングなどです。特にコストは非常にかかかります。

AWSではクラウドの障害をわざと起こして稼働するアプリケーションの耐障害性を確かめるシミュレーター「AWS Fault Injection Simulator」が発表されました。

「AWS、クラウド障害をわざと起こす「AWS Fault Injection Simulator」発表　カオスエンジニアリングをマネージドサービスで」

https://www.itmedia.co.jp/news/articles/2012/16/news066.html

AWSに依存している場合、再び同じような障害が上がった場合を想定して訓練することで、AWSの復帰を待たずに自分で何とかするという柔軟な発想とトレーニングが必要と考えました。