 |
|||||||
|
|
|
||||||||||
|
||||||||||
|
 |
|||||||||
|
||||||||||
|
||||||||||
|
||||||||||
|
| ||||||||||
|
見えない“雲の向こう側”－Amazon S3システム障害の教訓 |
||||||||||
|
||||||||||
|
|
||||||||||
|
| ||||||||||
|
AmazonのWebストレージサービス「Amazon Simple Storage Service（S3）」が2月15日、大規模な障害に見舞われ、復旧に3時間以上がかかるというトラブルが発生した。S3はSaaS、さらにはより大きな概念となる「クラウドコンピューティング」の代表的存在の1つであり、この障害は大きく取り上げられた。一番の問題な何だったのだろう。 S3は、ホスティング型のストレージサービスで、Webアプリケーションで利用するデータを保存できる。必要なだけ使える従量課金式である上、ストレージ容量1GBあたり月15セントという低価格（別途データ転送量に料金が必要）で、ベンチャー企業を中心に人気がある。TwitterなどのWeb 2.0企業からThe New York Timesなどの大手、さらには米航空宇宙局（NASA）のプロジェクトなどが利用しているという。Amazonは「Amazon Elastic Compute Cloud（EC2）」とともにクラウドコンピューティング戦略を持ち、S3はストレージ部分を担う重要部品だ。 問題の障害は米国時間の15日朝に発生。3時間以上続いて、多くの顧客が被害を受けた。Amazonでは原因について、認証リクエストが急増したため、と説明している。暗号技術を用いる認証リクエストは多くのリソースを食う。これがキャパシティを上回ったということのようだ。 Amazonが対応に手間取る間、Amazonの開発者フォーラム「Amazon Web Services Developer Connection」には、分刻みで書き込みが入っていった。ユーザーたちはこのなかで「ビジネスを閉鎖することになった」「信頼できない」と、不満を噴出させた。まさに、インフラを他者に依存するクラウドコンピューティングのデメリットを露呈してしまったといえる。 だが、このトラブルの最大の問題は技術ではなかったようだ。 もちろん、障害を発生させない技術的な対策が必要であることはいうまでもない。まして、Amazonは昨年10月から、S3でサービスレベル合意（SLA）を設けており、「アベイラビリティ99.9％を目指す」としているのだ。今回の障害発生の後にAmazonが対策として約束しているモニタリングには、多くの開発者が賛同している。また、The New York Timesのブログではバックアップシステムの完備も提案している。 しかし、Developer Connectionを見る限り、問題は対応状況の不透明さにあったようだ。障害が最初に報告されたのは太平洋標準時5時。Amazonのスタッフは11分後に「調査中」と個人名で書込みを入れたが、その次の報告までに1時間近くかかっている。復旧するまでの間、ユーザーからは、「どうなっている？」「状況をアップデートしてほしい」「ある程度の見通しは立たないのか？」「この沈黙は？」と、いらだって情報を求める声が次々と寄せられた。 Amazon側が3回目に報告したのは7時17分。同じスタッフが「問題を解決した。パフォーマンスは通常のレベルに戻りつつある」とだけ書き込んだ。だがその後も一部ユーザーからエラー報告が続いた。Amazonが“サービスチーム”として報告したのは、12時35分。発生は4時31分だったので、なんと8時間後ということになる。その後、20時56分に同チームは改めて詳細な原因と今後の対応を報告した。 システム障害の発生を完全に避けるのは至難だ。社内であれば、IT部門が従業員に説明し、従業員が顧客など外部に連絡することができる。 だがクラウドコンピューティングではそうはいかない。S3のユーザーは、外部であるAmazonに依存しており、Amazonからの状況の報告がなかったため、それぞれの顧客やユーザーに対する説明ができずにいた。これは、「ある程度の見通しは立てられないのか？」という書き込みが物語っている。また、あるユーザーはAmazonの説明に対し、「レベルが低すぎる」と批判した。 このトラブルを早くからブログで報告したNicholas Carr氏も「（障害は避けられない事態であり）サプライヤがどのように対応するか（つまり顧客への報告）が信頼を構築する上で不可欠だ」と、Amazon側のコミュニケーション不足を指摘している。 また、ZDNetでITプロジェクトの失敗を分析するブログ「IT Project Failures」を書いているMichael Krigsman氏は、Technoratiがそれ以前の障害発生時にとった迅速かつ透明性のある対応と比較して、「この事件はAmazonにとって大きい。顧客を失うだろう」と記している。 ユーザーフォーラムでは、問題を解決したAmazonチームに対する賞賛の声が多く寄せられている。ユーザーはこれまでのAmazonのサービスに満足しており、今回の障害での改善を求めている。とにかくクラウドコンピューティング戦略を成功させるためには、顧客の信頼が不可欠だ。Amazonはこれを大きな教訓として技術とコミュニケーションの両方を改善しなければならない。 サービスが“あちら側”に移るにしたがって、サプライヤの役割はこれまで以上に大きくなる。サプライヤはサービスや製品の質の向上だけでなく、顧客との良好な関係を重視しなければならない。もちろんこれは、「クラウドコンピューティング」だけでなくあらゆるビジネスに当てはまることなのだが―。 ■ ＵＲＬ Amazon S3 Service Level Agreement http://www.amazon.com/gp/browse.html?node=379654011 「Amazon Web Services Developer Connection」のスレッド http://developer.amazonwebservices.com/connect/thread.jspa?threadID=19714&start=0&tstart=0 Nicholas Carr氏のブログ http://www.roughtype.com/archives/2008/02/amazons_s3_util.php The New York Timesのブログ http://blogs.wsj.com/biztech/2008/02/15/is-amazons-small-crash-a-giant-crash-for-cloud-computing/?mod=googlenews_wsj Michael Krigsman氏のブログ「IT Project Failures」 http://blogs.zdnet.com/projectfailures/?p=602
（ 岡田陽子＝Infostand ）
|
