AWS障害があってもダウンしなかったサービスに学ぶ

AWS障害からエンジニア、担当者が学ぶことは、障害はいつでも、どこでも起きるということの再認識と、障害が起こりにくいサービスや知名度の低い安定したサービスの情報収集・研究をすること、日々のメンテナンスを怠らないことです。まともな所ならば既に全て日々やっていることでしょうから、その業務を維持、効率化するだけです。

 

AWS障害でも動き続けたサービスがある

影響を受けたサービス

AWS大規模障害で影響を受けたのは、マルチAZにしていても、2つしかAZを選んでいなかった所、東京リージョンだけで組んでいたといった当たりが共通点にあります。シングルAZではちょっとした障害やメンテナンスでも動かなくなりますが、今回のAWS障害の事例からAZが2つだけでもダメだということで、3つ~4つは選んだほうが良いでしょう。

 

可能なのであれば、日本だけでなく、シンガポールなど海外のリージョンのAZを選ぶのも良いでしょう。大阪ローカルリージョンでも多少はないよりは良いかもしれませんが、制限もあるので使えないサービスも出てくるでしょう。中国のリージョンが嫌だという場合は、多少遠くても北米のサーバーを頼るか、GCP、AzureなどAWS以外のクラウドサービスを利用するのがベストな選択です。

 

Spotinstで9分で復旧できた事例

AWS障害に関するメディア記事を見ていると、Spotinstというようなサービスを活用して、障害発生からすぐに復帰はできたという例もあったようです。これらはおそらくお金をかけて導入しておき、事前に備えていなければできなかったものでしょう。

 

現場によってはそこまで固定費をかけたくない、または、かけさせてもらえないこともあるため、現場の人間、現場のエンジニアよりは予算、上層部の理解度の問題となるでしょう。

 

お金と手間をかけられるならば、複数のクラウドサービスに分けてサービスを展開すればよく、AWSもGCPもAzureも使って分散すればよいだけです。ただし、そこまでしないといけないほどの大規模なグローバルサービスは日本にはないでしょう。

 

そのため、日頃から一つのクラウドサービスでも障害が起こりにくい限界の設定を作っておき、いざという時は迅速に復旧できるよう訓練とマニュアル化、複数の担当者への共有をしておくと良いでしょう。

 

エンジニアはどうすればよかったのか

多くのエンジニアはやっていたはずですが、こうした障害対策は日頃からの予防が全てで、脆弱だった部分は気づいていたはずで、上司への申立もしたでしょう。しかし、目に見えないものを理解する努力をせず、目に見えないものにお金をかけたがらない日本人上司が多くいるために、意見は通らなかったでしょう。

 

コストを最優先にして、サービスを脆弱にし、顧客を軽視し、サービス提供の責任感もなめてかかっていれば問題が起きて責任を取るのもその上司です。

 

エンジニアはこういう上司のもとではあまりできることはありません。難しい顔をして、どうしようもなかったと言い聞かせて言い訳し、もうAWSが問題を起こさないことを祈りつつ、細々と設定を見直すしかありません。

 

もし、理解がある人の元で働けているならばアドバイスも貰いながら、マルチ化に専念し、復旧訓練を行えるよう予算と時間をとってもらい、追加の保険的なサービスを頼れるようにしましょう。

 

マルチAZ導入で少しマシになる

シングルAZからマルチAZに

まずは、AWSでAZを2個から3~4個にしましょう。AZを3つ設定していたサービスは少し耐えていたという声も聞きましたので、AZは3つ以上が良いのでしょう。AZは日本国内であれば東京リージョンのものを選べば問題ないと思われますが、シンガポールや中国など海外のAZを入れておいたほうが障害耐性は高まります。

 

特に災害時に落とせないサービス、決済系のサービスでは国内のAZだけを頼るのはよくありません。国内で大災害や大きい規模の障害が起きたときにサービスを継続できなくなってしまっては意味がないので、大阪のローカルリージョンや海外を頼りながら障害耐性を高めましょう。

 

また、セキュリティの問題から、どこのAZを利用しているか、海外のAZを選んでしまって大丈夫か、その国、地域の特性も把握して運用しないといけません。検閲を行っているような場所では、国内の個人情報、口座情報、決済情報が盗まれますので、一部の地域や、その国の主義、政治の状況によっては信頼できない場所もあります。

 

再接続するフェイルオーバー(ロードバランサー)を設定

ELB、ALBと呼ばれるロードバランサーも複数用意して、安定して動いてくれる環境を整えましょう。これはサービスによって各自研究と調整が必要です。ロードバランサーはそれぞれ追加すればよいだけで、AWS利用者はそこまでこまかくいじれないですが、複数あって損はありません。

 

複数のクラウドサービスを利用しつつ、障害があった時にはほどよくそれぞれのサーバーを選んで負荷を分散してくれるような仕組みにできればより理想的です。このために各クラウドサービスをつなぐような工夫ができれば理想的ですが、IKEv2対応などに対応できる人材がいるかどうか、他にこうしたネットワーク設定や管理ができるエンジニアがいるかどうかも重要です。

 

余裕ある余剰メモリを維持する

メモリ最適化インスタンスあたりをいじって高速処理できるようにしつつ、負荷軽減をする必要があります。負荷軽減できれば課金される金額も最小限にできて、そのサービスの平常運用に必要なメモリも把握できて一石二鳥でしょう。

 

メモリ管理もクラウドサービスを安定させるには欠かせない工夫の一つですが、無駄に余裕をもたせすぎるとコストとの兼ね合いが悪くなることもあります。GCPやAWS、Azure、IBMクラウドでも無理にコストをかけて過剰なメモリ状況にするのは良くないので、社内、チーム内で話し合いながら決める必要があるでしょう。

 

Spotinstなどでさらに対策する

AWSだけに頼らず、クラウドサービスとして障害が起きてもすぐ復帰できるような支援サービスを活用しましょう。AWSだけで満足せず、GCPもAzureも合わせて学んでおき、疎開先としていつでも移行できるよう備えておきましょう。日頃の備えが安定したサービスの要です。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA