AWS、マルチAZでも障害影響ありを認める
先週のAWS障害から一週間が経とうとしています。
特定のアベイラビリティーゾーンの特定データセンターにおける冷却機構の問題だったため、マルチAZ構成を組んでいたら障害は回避できたのだというのが第一報での論調でした。
しかし、いやいや、マルチAZ構成をせっかく組んでいたのに障害に巻き込まれたぞという話が巻き起こり当初の話と違うのではというところが現在地点です。
確かに、これだけたくさんの企業がシングルAZなはずはないよなと言う疑問は当初にありました。
この辺りのお話について、ITmediaがまとめてくれています。
一部のエンジニアからは、「複数のAZを利用してサービスを冗長化する『マルチAZ』構成だったら、サービスは継続できたのではないか」という声もあった。その一方で、「マルチAZでも障害対応に時間がかかった／AWS自体の復旧まで待たなければならなかった」という話も聞こえてきた。
AWSの障害に、各社はどのように対応したのか。ITmedia NEWS編集部では問題に直面した企業やエンジニアに聞き取り調査を行い、4例の回答を得た。どんな構成でどんな問題が起きたのか、実情が見えてきた。
一方で、AWS自らも、構成によってはマルチAZでも問題が起きたことを認めるレポートを出しました。
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。
この一連の流れを受けて、クラウドを今後どう利用していくべきか、考察します。
考察
一連の記事を読み、少なくともマルチAZの場合は3AZにすべきだということはわかりました。ロードバランサー（ELBないしはALB）は2AZ以上に設定しなければいけない。しかし通常2AZで冗長構成を組んでいると、片方の問題のあるAZを切り離せない。それはなるほどと思います。
現在の論調を受けて、いろいろな現場で2AZを3AZにする作業が進んでいくんだろうと思います。これは今回のAWS障害の知見となっていくでしょう。
一方で、ITmediaの下記まとめには少し違和感を持っています。
・3AZでのマルチAZ構成にする
・コンテナ化などでサービスを落としやすく立ち上げやすい環境にする
・可能ならFargateを使う（サーバレス化）
・「AWS Step Functions」で処理ステップを構成しビジュアライズする（処理の見通しが容易になる）
コンテナ／サーバーレス／FaaSへ移行せよとあります。
ただ、これは今回と全く同じ障害が発生した場合に対応できるというだけの話だと思います。
現在のモノリシックの構成からマイクロサービスへ、というのはトレンドの流れではあるものの、移行するにはコストがかかります。マイクロサービスに順応したITエンジニアを見つけるのも大変です。また、コンテナはまだしも、サーバーレスやFaaSとなると当該のクラウドサービスに依存した構成となってしまいます。AWSで構築したものをAzureやGCP、その他のクラウドには簡単に移せません。コンテナはどのKubernetesでも動くということを目指しているものの、まだ志半ばです。それぞれのクラウドサービスで細かい運用面の違いがあるのは否定できません。
大規模障害が起きると、その現象の解析と対策に視点が集中するのですが、残念ながら似たようなことはほとんど起きず、新規の新しい何かが起こることの可能性が高いのです。新しい仕組みが、その未知の障害にどれだけ耐えうるかは未知数でありかえってリスクにさらすという可能性すらあります。あるクラウドサービスに「ずぶずぶにのめり込む」構成は私は逆に、万が一他のクラウドに持っていけないリスクを高めるという意味で反対です。
ロードバランサーの障害に対応していたエンジニアA氏は、「結局はどこまでリスクを許容するかではないか。大規模災害など、東京リージョンの全てのAZが壊滅することを想定すればマルチリージョンや他社クラウドとの併用も考えられるが、自社のサービスは果たしてそこまでの継続性を必要とし、運用コストを払えるものなのか」と指摘する。
これはもうその通りです。大規模災害において、マルチクラウドならリスクヘッジできるかというと実は落とし穴もあります。実は近隣のデータセンターを使ってましたというオチです。またマルチリージョンであってもシングルクラウドなら問題は起こりうるということもあります。
今後の考え方
とりあえず、今回の問題に狭くフォーカスして物事を考えるのは、あまり得策ではありません。コストをかけて、何でもかんでもマイクロサービス化するというのは、気が付くと別のリスクになっていることに気が付くでしょう。
今の構成を変えないで、コストもかけないですぐできる対策を今は考えるべきだと思います。
そして、今回のようにシングルAZが倒れた場合だけではなく、
・クラウドサービスごと利用不能になったらどうするか
・リージョンごと利用不能になったらどうするか
を前もって検討して、万が一の場合に慌てないことこそ重要だと思います。
東京には複数のクラウドサービスが同居しているデータセンターもありそうですし、その場合はマルチクラウド同時障害だって起こりえます。
基本的に、集中＝同時障害リスク、と考えるのが良いと思います。単一のクラウドサービス、単一のリージョン、単一のＡＺ、それぞれ同時障害の原因となります。
ではどの程度分散するか。また分散するにあたって、マイクロサービスが良いのであればどんな運用設計にするか。そのマイクロサービス自体が大きく変動して急に使いずらくなったりしないか。それを使いこなせる人材が枯渇して将来困らないか。
メディアは新しい方へ寄せていく論調が多いとは思いますが、現場的にはコストや手間をかけず動けばいいのです。
私が今期待しているのは、VMwareの動向です。
vSphere上でネイティブにKubernetesが動くようになればもっとインフラエンジニアにとってコンテナが近くなるなあと思った次第です。vCenterの上でコンテナが見えるとか・・。そうすれば、複数のクラウドサービスでvSphereを立てていけばもっと便利になる。
どんどんこの世界は変わりゆくため、結論を出さないのが正解だと思います。ぜひ、「保守的」に動くべきだと思います。明日正解が出るかもしれないので。
