西田宗千佳のイマトミライ
第16回
AWSの大規模障害は本当に「クラウドの弱さを露呈した」のか
2019年8月26日 08:10
8月23日午後、日本国内で多数のネットサービスが同時多発的にトラブルに見舞われた。
原因は、クラウドインフラサービス事業者であるAmazon Web Services(AWS)の障害だ。同日夜には障害が解消され、各ウェブサービスも正常稼働に戻っていった。
障害を起こしたサービスがPayPayのような決済系からスマホゲームまで広範にわたるため、新聞紙上などでは「特定のクラウド事業者に依存するもろさが露呈した」などと書かれている。
大量の事業者が1社のトラブルでサービス停止を被った今回の件、「クラウドのもろさが露呈した」という分析に説得力があるように見えるかもしれない。しかし、情報を精査すると、今回の問題を「クラウドのもろさ」とシンプルに結論づけるのは無理があることも見えてくる。
今回のAWS大規模障害から見えてくる本当の課題とはなんなのだろうか?
AWSの大規模障害はなぜ起こったのか
まず問題になるのは、今回の障害がなぜ発生したのか、ということだ。
AWSが障害告知用のダッシュボードサイトで告知した情報によれば、障害を起こしたのは、AWSの東京リージョン(AP-NORTHEAST-1)に設置された、特定の「Availability Zone」と呼ばれる設備の中に設定された、EC2およびEBS(ストレージサービス)・RDS(データベースサービス)の一部。
この中で特に障害の影響が大きかったのはEC2で、こちらについては、「制御システムの障害による冷却システムの故障」によりシステムの一部がオーバーヒートしたことによるトラブル、と発表されている。
くわしい状況は推測になってしまうが、どうやら「設備の故障によって、東京のデータセンターの一部に障害が起きて、その影響を多数の事業者が受けた……ということのようだ。
ここで重要なのは、「AWS全体が落ちた」のでもないし、「AWSの東京データセンターが管理するネットワーク全体が落ちた」のではない、という点だ。
AWSは世界中にデータセンターを持っている。これを「リージョン」という。そして、リージョンの中に複数の分割された単位で設備を持っている。これを「アベイラビリティゾーン(AZ)」という。今回は、東京リージョンの中のAZの1つが障害を起こした、ということになる。
AWSでは、障害対策や負荷分散などの観点で複数のリージョンを同時に使ったり、複数のAZを使ったりすることができる。当然、複数のAZを使うと規模もコストも大きくなるし、複数のリージョンを使うということになるとさらに大規模になる。だが、単一のAZの負荷や障害には強くなる。そういう工夫ができるのもクラウドインフラの利点である。
だが、である。
「マルチAZ構成していれば今回の障害の影響は防げた」と単純に言えるのかどうか、微妙な点がある。マルチAZ構成で運用されていたサービスでも障害があった、という声は複数存在するからだ。
結局のところ、今回の障害の範囲と影響がどこまでので、どのような対策であれば防げたのか、という情報と知見が集まらないと、単純に結論を下すことはできない。
必要なのは「どのサービスは落ちてはいけないのか」の判断だ
機器の故障にしろ設定のトラブルにしろ、障害をゼロにするのは難しい。では、それにどう対処すればいいのだろうか。
特定のクラウド事業者に頼るのは問題がある、という論調もわかる。だが、では、単純に「クラウドに頼らない」「複数のクラウド事業者を使うようにシステムを構成する」形でいいのだろうか?
そもそも、クラウド事業者に頼らずオンプレミスなシステムにしたからといって、クラウド事業者以上の安定性を維持できるとは限らない。今回のような大規模障害は年に1度もない。そして、ほんの半日程度で回復している。設備の入った建物のメンテナンスがあろうが、周辺の通信設備や電力設備にメンテナンスがあろうが、その影響も受けずにサービスを提供するには、それなりの備えがいる。餅は餅屋だ。
「サービス事業者を分散して」といっても、そのシステム構築と運営には追加のコストが発生する。単一の事業者で構築するのにくらべ、システムの複雑化は避けられない。
重要なのは、「どのサービスがどのレベルの稼働率を維持しないといけないのか」という点だ。
世の中には、絶対に落ちては困るサービスがある。消えては困るデータもある。
一方で、費用対効果を考えると、数年に一度あるかないかの大規模障害に備える必然性はない、というサービスもあるはずだ。
決済サービスとゲームで同じレベルを維持するのは、一般論でいって過剰だ。また同じサービスの中でも、課金やデータの保持に関わる部分と、告知に関わる部分、クーポンなどの提供に関わる部分とでは、必要な稼働率も異なるはずだ。
クラウドを使うか使わないか、クラウドを使うとしてマルチリージョンやマルチAZなどの対策をどう使うかは、まさにシステム構築のポリシーとビジネス設計に関わる部分だ。そこを均質に語るのは現実的ではないし、そうすべきでもない。
むしろ今回の件で注目すべきは、「落ちるべきではないサービスも障害で落ちている」点である。決済系や認証系サービスは、そうしたものの中に含まれるのではないか。落ちるとしても、「なぜ落ちているかをユーザーが理解できる」「重要性の低い部分は落ちているがコアな認証や支払いなどは落ちづらい」という仕組みが必要になる。
「障害をわざと起こして、大きな障害を防ぐ」試みも
冒頭でも挙げたが、「落ちないシステム」などない。だから、各社とも、いかにサービスを落とさないかに知恵を絞っている。
AWSの大規模障害からはちょっとずれるが、筆者が面白い発想だと思った技術をご紹介しておきたい。
すべての領域で常に障害が起きない、ということはありえない。ならば、自動復旧システムを用意し、わざとエンジニアがいる時間帯に障害を細かく「起こし続け」て、対処を継続していくことで、自動復旧システムの稼働状態を確認・維持し、エンジニアがいない時間帯にトラブルが起きた時にも、自動復旧が可能にしておくのだ。
こうした仕組みを「カオスエンジニアリング」と呼ぶ。実はこの考え方、NetflixがAWSを使った配信システムを落とさずにメンテナンスし続けるためにはどうしたらいいか、という課題への対策として導入したことから広がったもので、同社が作ったカオスエンジニアリングのための仕組みである「Chaos Monkey」「Chaos Kong」は、オープンソース化されている。アメリカの銀行機関など多数の企業で使われている。日本ではクックパッドが導入している。AWSもその手法を解説するセッションを開発者会議で設けているほどだ。
こうした手法が採れるのは、小さなサービスの組み合わせでサービス全体を構築している「マイクロサービス」アーキテクチャを使っているためでもある。大きな一つのサービスで全体を構築している場合には使えない。マイクロサービスは構築難易度の高さや効率的な運営の難しさといった課題もあるが、サービス全体が落ちづらくなる、という利点もあり、特に大規模サービスの構築手法として数年前から注目されている。
「クラウドのもろさ」など、クラウドサービスを使っている人々は100も承知だ。その上で、「では安定させるにはどうしたらいいか」「障害が大規模・長期化しないようにするのはどうしたらいいのか」という発想が重要だ。先程も述べたように、「では自社のサービスはどれだけのダウンタイムを許容するのか」という判断も必須だ。
これはまさに「経営課題としてテクノロジーをどう判断するのか」という話である。ハッキング被害に遭いづらいセキュリティ対策と根は同じであり、だからこそ、技術的妥当性の判断できる経営層、もしくは経営層に技術的妥当性を提案できるポジションが必要、ということなのだ。