「クラウドは飛行機」? Amazonの大規模障害で見えた企業の対応


 Amazonの子会社Amazon Web Services(AWS)のサービスに4月21日、障害が発生。これらのサービスを利用するQuoraやFoursquareなどのインターネットサービスが影響を受け、完全復旧までに4日を要するという大規模なトラブルとなった。メディアには「クラウドの死」「クラウドコンピューティングへの疑念」といった見出しが躍った。だが一方、企業のクラウドとのつきあい方にも変化が見えている。

 

4日間の大規模障害

 今回の障害は、北バージニアのデータセンターで起きたもので、「Amazon Elastic Compute Cloud(EC2)」「Amazon Relational Database Service(RDS)」のクラウドサービスがダウンし、Webアプリの作成・実装・運用の「AWS Elastic Beanstalk」のエラー率も上昇した。通常稼働に戻ったのは25日。まる4日間サービスの稼働率が落ちたことになる。

 Amazonはクラウド地域を分割しており、北バージニアのデータセンターは「US-EAST-1」と呼ばれている。EC2は障害対策として、地域内で独立したゾーン(Available Zone)を複数持つが、今回の障害では、複数のAvailable Zoneが同時にダウンした。原因についてAmazonは、ネットワーク障害が発生し、これが「US-EAST-1」の「Amazon Elastic Block Storages(EBS)」(外付けストレージサービス)のディスクボリュームの再ミラーリングを引き起こしたと説明している。ストレージ容量が不足となったりディスクボリュームの作成ができなくなったりするなど、さらなる障害につながったという。

 クラウドの障害は、過去にも何度か起きている。Amazonは2008年の「Amazon Simple Storage Service(S3)」の大規模障害を経験しているし、今年に入ってからは、Googleの「Gmail」の障害が報告された。

 今回、特徴的だったのは、EC2がIaaSであることから、クラウドを利用するインターネット企業がうけたサービスへの支障も大きく報じられたことだ。Quora、Foursquare、Reddit、Salesforce.comのHeroku、HootSuite、EScheduleなど、主にベンチャー企業が中心である。彼らが提供するサービスやアプリが利用できなくなったり、機能を制限したりするなどの影響を受けた。クラウドが広く利用されていることの現れでともいえる。

 

クラウドとどう付き合うか

 もう1つ特徴的だったのが、障害に対するユーザーやメディアの反応の変化だ。

 クラウド障害に際しての反応はこれまで、サービス事業者への非難や、クラウドコンピューティングへの疑問を投げかけるものが主だった。しかし、今回のAWSのサービス障害に対し、Amazonの対策不足を非難した声は少なかった。NetworkWorldのブロガーPaul McNamara氏が「Amazonは公式に謝罪していない」と非難したのと、透明性がないという指摘がいくつか出たぐらいだ。

 クラウドそのものについて、今後の方向性であることを否定する声は少ない。Wall Street Journalは「この障害によって、(クラウドに乗り気だった)企業は考え直し、クラウドベンダーから何を購入すべきかを学ぶだろう」というCapgeminiのコンサルタントのコメントを紹介しながら、「今回の汚点が、クラウド顧客のエンタープライズインフラへの全体の需要を損なうことは、まずないだろう」というGleacher&Coのアナリストの言葉を結論としている。そして、障害は「冗長性とバックアップの必要を強調するものだ」という教訓で締めくくっている。

 PC WorldのTony Bradley氏は、障害がクラウドのリスクを露呈したが、「リスクが高すぎるからクラウドにあるサーバーやストレージを利用しないほうが良いと考えるべきか? そうではない」と述べた上で、あわせて対策をとっておくことが必要と説く。

 

対策により支障を回避したNetflix

 実際、多くの企業でサービスに支障が出た一方で、オンラインDVDレンタルのNetflix、SmugMugなどいくつかの企業は影響を回避した。Wired.comは、Netflixが2010年12月に掲示した「AWSを利用して得た5つの教訓」というブログ記事を紹介している。それによると、NetflixはAWSのプロセス上で独自のスクリプトを走らせてシステムの稼働を継続するという対策を講じているという。

 SmugMugのCEO、Don MacAskill氏はブログで、Available Zone内のインスタンス、インスタンスグループのどちらがダウンしてもシステムの運行に支障がないように設計と運用を工夫していることを明かした。「各コンポーネントが、できる限りシステム全体に影響を与えない形でダウンできるようにしている」とMacAskill氏は言う。今回の障害で自社のサービスに影響を受けたHootSuiteが、システムの状況をブログで必死にアップデートしているのとは対照的だ。

 今回の障害では、複数のAvailable Zoneが同時にダウンしてしまった。PC WorldのBradley氏は、対応策の1つとして、複数のクラウドベンダーと契約して自社で冗長性を確保することを挙げる。クラウドは完全ではないが、自社のデータセンターと同様に、障害に備えた計画・設計を持つ必要があるというのだ。

 「クラウドが死んだ日」というタイトルを付けたForbesのCIO Networkコラムも、クラウドと付き合うためのポイントを挙げる識者のブログを紹介しつつ、適切なプランニングと設計が重要だとしている。

 Rackspaceの戦略担当トップはNew York Timesに対し、クラウドを飛行機にたとえる。飛行機の事故は大きく報じられるが、事故率としては自動車の方が高いというものだ。つまり、クラウドは、自社ですべて運行するよりも安全だということになる。Wired.comは「本当の失敗はAWSの支障ではなく、ユーザー企業にある」と断言する。

 同じクラウドでも使う企業により差が出る、というのが今回の障害で明らかになったことだろう。飛行機のように安全だが、やはりリスクもあるクラウドとどうつきあうか。担当社の腕の見せ所でもある。

関連情報