Amazonクラウドの大規模障害を経て、これからは「データセンターはいつか落ちる」ことがサービス設計の前提となる

2011年5月2日

4月21日に発生したAmazonクラウドの米国東海岸データセンターで起こった大規模障害により、Foursquare、Quora、Herokuなど多くのサービスに影響がありました。

Summary of the Amazon EC2 and Amazon RDS Service Disruption

すでに障害は復旧し、Amazonクラウドの運営チームからは詳細な報告と今後の対応策について記したドキュメント「Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region」が公開されています。公式な日本語訳「 米国東リージョンにおける Amazon EC2 と Amazon RDS のサービス障害 の概要 (参考和訳)」(pdf)も公開されました。

これによると、障害はネットワークの構成を間違えたことをきっかけにして、ストレージサービスの「Amazon Elastic Block Store(EBS)」やデータベースサービスの「Amazon Relational Database Service(RDS)」の障害へとつながったことが明らかにされています。

すでにAmazonクラウドは多くのサービスのインフラとなっていたため、その期間と影響の大きさにおいて、今回の障害はクラウドの短い歴史の中でも最大級のものでした。これまでクラウドに対してなんとなく期待されていた「大きな障害は起こらないだろう」「一部に障害が発生しても、全体としては動作し続けるだろう」といったことは、現実にそのように備えておかなければそうならないのだ、という事実を明白に突きつける結果となりました。

今後、クラウド上である程度以上の信頼性が必要なサービスを設計する場合には、下位レイヤのクラウドやデータセンターの信頼性に依存せず、「データセンターはいつか落ちる」ことを前提とし、それに対応できるアーキテクチャを検討することが必須となるでしょう。

つまり顧客から、「データセンターが落ちたらどうなるの?」という問いに答えられるようにしなければならない、ということです。

原因に関係なく、サービスベンダが障害の全責任を負う

Widespread Application Outage

Amazonクラウド上でサービスを提供していて今回の障害の影響を受けたHerokuは、障害を振り返ったドキュメント「Resolved: Widespread Application Outage」でこう書いています。

Failures at the IaaS layer will happen. It's Heroku's responsibility to shield our customers from this; part of our value proposition is to abstract away these concerns.

IaaSレイヤでの障害は今後も起こりえる。そうしたことから顧客を守ることがHerokuの責任なのだ。私たちのバリュープロポジションとは、そうした問題を抽象化するところにある。

サービス提供社にとって、どのような原因であれ顧客に対してサービス品質の全責任をとるのだ、という潔い姿勢が伝わってきます。そして、今回の件から次のようなことを学び、対応していくと書いています。

Spreading across multiple availability zones in single region does not provide as much partitioning as we thought.

一地域内での複数アベイラビリティゾーンへの分散は、私たちが考えているほど分離されているわけではなかった。

アベイラビリティゾーンとは、簡単にいえばデータセンター内の別々の区画のことです。基本的にアベイラビリティゾーンごとに独立しており、何らかの障害が起きてもアベイラビリティゾーンを超えて影響しないとされていました。

しかし今回は一部の影響が複数のアベイラビリティゾーンに起こったと報告されています。そのためHerokuは、地域分散による対策を検討するとしているのです。

Block storage is not a cloud-friendly technology.

ブロックストレージはクラウドに適した技術ではなかった。

Amazonクラウドの優秀なスタッフでさえ、取り扱いに失敗したのだから。いかにブロックストレージの依存を減らすか検討する、としています。

Continuous database backups for all.

継続的データベースバックアップをすべてに対して行う。

これまでは定時バックアップだったものを、今後はすべてのデータベースに対して継続的バックアップを展開していく。

複数のアベイラビリティゾーンへの分散が重要

クラウド上の運用管理サービスを提供しているRightScaleは、今回の障害についてまとめた「Amazon EC2 outage: summary and lessons learned」で次のように書いています。

A clear lesson for everyone is obviously that backup and replication have to be taken seriously (duh). In EC2 this means live replication across multiple availability zones and backups to S3 (and ideally elsewhere also).

明らかな教訓は、バックアップやレプリケーションは確実に重要だということだ。これはAmazon EC2では、複数のアベイラビリティゾーンにまたがったライブなレプリケーションと、S3へのバックアップを意味する。

また、NetflixのAdrian Cockcroftは今後の対策をつぎのようにまとめています。

Deploy in three AZ with no extra instances - target autoscale 30-60% util. You have 50% headroom for load spikes. Lose an AZ -> 90% util.less than a minute ago via web Favorite Retweet Reply

まずシステムを3つのアベイラビリティゾーンに展開しておき、それぞれのリソース利用率を30%から60%程度にしておく。これなら万が一、1つに障害が発生し、残り2つに負荷が集中したとしても、それぞれが90%程度の利用率に収まるため、処理速度が落ちることなく継続できるだろう、という目論見です。

地域分散のためのツールが浮上してくる

1つ前の記事「「クラウド女子会」が都内で開催。Amazonユーザー会とAzureユーザー会が合同で」で、マイクロソフトのクラウドエバンジェリスト砂金信一郎氏は、Windows Azureに対応した地域分散可能なシステムを開発中であるという発言もしており、今回のAmazonクラウドの障害を受けて、社内で開発の優先度を上げているとしています。

マイクロソフトだけでなく、これからは地球上の複数の地域に分散したデータセンターを利用しする分散システムのための、さまざまなアイデアやソフトウェアが、多くのベンダから登場することは間違いありません。

あわせて読みたい

AWS クラウド システム開発




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本