Gmailの障害の教訓・・・クラウドにご用心

 

Gmailが3日半ダウン！

グーグルの電子メールサービスのGmailに、2月28日から3月3日にかけて障害が発生した。グーグルによる障害の第1報は日本時間の2月28日5時9分で、復旧が完了したとの通知は3月3日の15時51分である。その間、3日間と約11時間、つまり約83時間の間、一部のユーザーはGmailが使えなかった。

障害の詳細は不明だが、グーグルがその間に何回も “Apps Status”で公表した障害の状況や “Gmail back soon for everyone”というグーグルの副社長によるブログから判断すると、今回の障害はおおよそ次のようなものだったようだ。

グーグルは障害に備えて、データを格納するストレージを多重化し、それを複数のデータセンターに分散して設置しているという。ところがそのストレージを管理するソフトのバージョンアップ版にバグがあったため、Gmailの一部のユーザーの送受信データ、アドレス帳、アカウント情報などが消失してしまったという。

影響を受けたのはユーザーの0.02%ということだ。 “Tech 24 Hours”の統計によると2009年末のユーザー数は全世界で約1.8億人ということなので、影響を受けたのは4万人程度と思われる。

グーグルは別途磁気テープにバックアップを取っていて、これはバグの影響を受けなかったので、これを使って復旧を図ったという。ただし、最初の報告から22時間経過後には、あと12時間で復旧が完了する予定と言っていたが、実際にはその後61時間要した。当初の予定より復旧が大幅に遅れたが、その理由は不明である。

該当するユーザーは、メールのデータがなくなっただけでなく、この間の約20時間の間、メールの受信ができなかった可能性が大きいという。また、復旧作業中はメールのアカウントへのサインインもできなかったようだ。つまり、過去の送受信メールの閲覧だけでなく、新規にメールを送信することもできなかったようである。

障害対策にはピンからキリまで

今回のGmailの障害から我々は何を学ぶべきだろうか？

当たり前のことだが、ハードの故障やソフトのバグは絶対に根絶できない。これは、自前のシステムでも、Gmailのようなクラウドのサービスでも同じである。

したがって、ファイルの2重化やバックアップの取得など、障害対策が重要になるが、こういう障害対策機能の障害がしばしばたちが悪い事故を起こす。いわば、火災報知器や消火器が火を吹くようなものだ。したがって、これらの設置、運用には細心の注意が必要になる。

今回、不幸にしてGmailでこの種の事故が起きてしまったわけだが、こういう事故の根絶も不可能で、今回の事故も毎年全世界で数多く起きているこの種の事故の一つに過ぎない。予定より時間がかかったが、完全に復元できたことは不幸中の幸いである。

自前でシステムを構築する時は、事故が起きたときの社会的影響や経営上の影響の大きさに基づいて障害対策を講じる。

航空機や鉄道の運行制御、株式の売買、銀行口座の資金移動、有人ロケットの制御などに要求される信頼性をピンとすれば、個人の文書、写真、ビデオなどのファイル管理に要求される信頼性はキリだ。これらピンとキリの障害対策が同一レベルでいいわけはない。要求される信頼性が何桁も違い、したがって、かけるべき費用も何桁も変わる。

クラウドの信頼性の定量的開示が必要！

最近何にでもクラウドを使うことが流行している。しかし、クラウドの一つの問題は、その事業者が信頼性を開示してないことだ。

例えばグーグルは “Disaster Recovery by Google”に次のような趣旨のことを記している。「大企業は、データセンターの多重化など、障害対策に頭を悩ませている。しかし、グーグルのクラウドを使えば、ユーザーが作成してグーグルに預けたデータについて、このような心配はまったく不要になる。ユーザーは、データ量に関係なく、最高クラスの障害回復機能を無料で使える。」

ユーザーによって要求レベルが千差万別である信頼性について、一律に「お任せあれ！　心配ご無用！」と言っているのだ。表現は文学的、定性的で、定量的に信頼性を表示しようという姿勢は見られない。

クラウドは、もともと「機能」を提供するもので、その実現手段は問わない。電力会社が一般の需要家に発電方法を説明しないのと同じだ。したがって、クラウドの事業者はサービスの提供に使うハード、ソフトについて説明する必要はない。それはユーザーにとって「雲」の向こう側の話であって、いつどう変わっても、提供されるサービスだけ保証されればいいのだ。ハード、ソフトの基本構成から、細かいバージョンアップの適用まで、一切関知しなくていいところがクラウドの最大のメリットだ。

同じように、クラウドの事業者は、障害対策の手段についても開示の必要はない。ファイルを何重化しようが、バックアップセンターをどこに置こうが、ユーザーには関係ない。重要なのは、その結果どういう信頼性が実現されるかだ。年間の障害件数や、平均障害回復時間などは、クラウド事業者を選択する際の重要事項なので、これらの開示は不可欠である。文学的な謳い文句をいくら聞いても、何の意味もない。

クラウドを使う時は

クラウドの大きい問題は、ユーザーが要求する信頼性が千差万別なのに、提供するシステムの信頼性が一律なことである。そのため、クラウドを使う時はユーザー側で注意が必要だ。

まず、提供されるサービスの信頼性が、適用業務が要求する信頼性以上であることの確認が不可欠だ。

事業者によって、提供するサービスの信頼性には大差があるだろう。そして、前記のピン・クラスの信頼性が要求される業務にクラウドの採用を考える人はいないだろう。これは極端な例だが、小企業にとっても、ある日突然基幹業務のデータベースが消失したら企業活動が止まってしまう。いや、個人が使っているデータベースにしても、例えば保管してあった写真がすべて消えうせたら、嘆き悲しむ人が多いだろう。

そのため、安いからといって、いい加減なクラウドを使うのははなはだ危険である。ただし、クラウドはそれなりに障害回復手段を講じているはずなので、ろくに対策を講じてない自前のシステムに比べれば一般的には信頼性は高いはずだ。また、自前で同レベルの信頼性を実現するのに比べればクラウドは安くできるはずである。

いずれにしても、クラウド事業者が提供するサービスの信頼性には限界がある。致命的な事故を回避するためには、重要なデータベースは二つの事業者に預けるとか、データベースの更新記録は自社でも保管しておくとかの対策を検討する必要がある。

高信頼性はタダでは買えない。これはクラウドについても同じである。

［後記］

 本記事の懸念が現実に！　下記をご参照下さい。(2012/7/8)

　　「ファーストサーバがデータを消失！」　(2012/7/8)