AWSの大規模障害からトレードオフを考える -

こんにちは、あのぶるです。

今回は8/23に発生したAWS大規模障害を下敷きに、サービスを提供するにあたってのトレードオフをどう考えるべきか、ということについて書きたいと思います。

AWSの大規模障害自体についてですが、すでに1ヶ月前の話ということもあり総括記事がいくつも出ています。ぜひそちらを眺めてみてください。当記事執筆にあたり参考にした記事を文末に掲載しています。
障害の内容を簡単に説明すると、AWSの東京リージョンに存在する4つのアベイラビリティゾーン(データセンターのグループのこと、以下AZ)のうちの1つが冷却システムの不具合によりオーバーヒートを起こし一部使用不可になり、そのAZを利用しているサービスが軒並み影響を受けた、というものです。
公式にAWS障害の影響を明らかにして発表されているだけでもかなりの数のサービスがあり、AWSがいかに浸透しているかがよく分かります。

まずお伝えしたいのは、今回の障害の影響を受けなかった方、特に他のクラウド/VPSサービスを利用している方もぜひ今回の情報を集め、「自分たちが運用している・しようとしているサービスで同じようなことがあったらどうするか、どんなことができるか」というのを検討したり、チーム内でディスカッションしてほしいということです。
ちなみに今回の件に関して周囲の複数方面の人と議論した結果、「マルチAZ(複数のAZにサーバを分散させること)構成にするなど現実的に取れる対策は取るべき。ただし、今回のケースに限って言えば利用者側としては山火事のようなもので、全く影響が出ないことを目指すのは困難」というのが概ね一致した見解でした。

……とだけ纏めてしまうと誤解を招きそうなので補足しますが、例えばあまり身近ではないですが「何があろうと絶対に止めてはいけないシステム」の端的な例のひとつとして軍事目的のシステムが挙げられます。システムが止まってしまったときに何が起こるかを(あまり考えたくはないですが)考えると、優秀なエンジニアを集め、専用の立派なデータセンターを複数建ててでも稼働率を上げる必要性があるということがよくわかると思います。
一方、世知辛いですが、一般的なサービスにおいて稼働率に限らず「どこまで手をかけられるか」を決めるのはお金です。
現在稼働率90%のシステムがあったとして、その稼働率を99%まで上げるのと、そこからさらに99.9%に上げるのとで同じくらいのお金がかかる、なんて言われたりもします。サービスの稼働率を上げるためにどこまで事業として投資すべきか、もしくは投資することができるか、それからその投資を最大限に活用するにはどのような設計にしたらよいか、ということを考える必要があります。
そのような観点で考えると多くのサービスにおいてマルチAZ、要件がハードでもマルチリージョン(複数のリージョンにサーバを分散させること)くらいまでが現実的な解なのではないかと思っています。海外にデータを置くのは機密保持などの観点で困難なことが多いので、早く大阪リージョンが気軽に使えるようになるといいですね。

また、今回の障害がコントロール不可能なところで発生したからと「だったらオンプレミス(自前でサーバマシンを用意すること)で運用しよう」と舵を切ることが現状有効なケースはあまり多くありません。
単純計算すると99.9%の稼働率を保証されていても年に8時間くらい、AWS(マルチAZの場合)の99.99%保証でも1時間近く全く動かないことを許容することになります。一見結構長時間動かないように見えますが、自前で運用しようとするとこれが急に「多くとも年に1営業日ぶんの時間しかサービス停止できない」という意味になるのです。このレベルのサービスを自前で実現しようとするとそれこそ専任のインフラエンジニアを集めてチームを組めるような規模にしないとコストの面でも厳しい、というのが現状かなと考えています。

もちろんどんなサービスも稼働率100%であるに越したことはないですし、どの開発チームも安定してサービスを提供するべく日々運用をしていることは間違いないはずです。それでも人はミスをする生き物ですし、機械はいつか故障するものです。取れる対策を取るのはもちろん大事ですが、今のところは障害が起きることを前提として、なるべく短時間で復旧できる設計やサービス運営を考える方が開発チームもお客さんも幸せになれると思っています。