クラウドサービスで障害が発生するのは、決して珍しくない。むしろクラウドサービスの利用者は、クラウドで障害が発生することを「前提」だと捉えて、事前に障害に対して有効な手立てを準備しておくことが望ましい。前回紹介したアマゾン以外のクラウドも含めて、これまでどのような障害が発生してきたか、パターン化しながら紹介する。

写真1●米アマゾン・ウェブ・サービシズが提供する各種クラウドサービスの管理コンソール画面
写真1●米アマゾン・ウェブ・サービシズが提供する各種クラウドサービスの管理コンソール画面
画面上部のタブを切り替えることで、「Amazon EC2」や「Amazon S3」など複数サービスの稼働状況をチェックしたりできる。
[画像のクリックで拡大表示]

 前回詳しく見てきたように、2011年4月に仮想マシン貸しサービス「Amazon EC2」で発生した障害は、提供元の米アマゾン・ウェブ・サービシズ(AWS)にとって過去最大規模の障害だった(写真1)。しかし、こうした障害は珍しくはない。クラウドサービスでは、様々な大規模トラブルが発生している(表1)。


少なくないストレージのトラブル

表1●クラウドで発生した主なトラブルの例
表1●クラウドで発生した主なトラブルの例
[画像のクリックで拡大表示]

 EC2での障害の原因は、EC2と組み合わせて使う同社のストレージサービス「Amazon EBS」にあった。アマゾン・ウェブ・サービシズや米グーグルは、ストレージの可用性を上げるために独自の分散ストレージを開発している。そのストレージが弱点になることがある。

 例えばアマゾン・ウェブ・サービシズでは2008年に、EBSとは別のストレージサービス「Amazon S3」で、大規模な障害が2度発生している。S3は、AWSが独自に開発したピア・ツー・ピア(P2P)技術を採用した分散ストレージだ。2008年7月の障害では、P2Pのプロトコル部分でエラーが発生し、サービスが9時間ダウンした。

 グーグルがSaaS型のクラウドサービスとして提供する電子メール「Gmail」で2011年2月に発生した障害も、同社が独自に開発した分散ストレージに起因した。Gmailのストレージソフトは、メールデータを異なるデータセンター(DC)にコピーする仕組みだが、同ソフトを更新したところ、データが複製も含めて消えてしまったのだ。この障害でグーグルは、一部ユーザーのメールボックスを、万が一に備えて磁気テープにバックアップしてあったデータから復元した。

 ストレージに発生した障害を、完全には復旧できなかったクラウドサービスもある。

 米マイクロソフトの電子メールSaaS「Hotmail」で、2010年10月に発生した障害がその一つだ。日本のユーザー向けに日本で運用するサーバーでハード障害が発生した。一時的に9万4439人のユーザーがメールを利用できなくなったほか、159人のアカウントで一部のメールが消失してしまった。

 NTTPCコミュニケーションズが提供するIaaS型のクラウドサービス「Cloud9」は2011年5月、ストレージのトラブルが原因で全面停止した。仮想マシンが利用できなくなったのは5月8日のこと。その後、ユーザー企業のデータは復旧できたものの、10月上旬現在でも、まだサービスは再開していない。