「Amazon EC2」は、誤解されている。筆者は最近、そう強く思っている。あなたがもし「Amazon EC2は単なる仮想マシンサービス」と思っているなら、考え直してほしい。Amazon EC2の本当の価値とは、実はストレージサービスの「Amazon S3」にある。

　最近日本でも、Amazon EC2対抗をうたう仮想マシンサービスが増えている。Webサイトからの申し込みだけで利用でき、課金は1時間単位。Webベースの管理ツールから簡単に仮想マシンを起動できて、ロードバランサーなども手軽に設定できる。日本のサービスも、仮想マシンに関する機能面ではAmazon EC2に追いつき始めている。

　しかし、全く敵わないのが、ストレージサービスであるAmazon S3だ。

　Amazon EC2の最大の特徴は、利用者が様々な種類の仮想マシンを、管理ツール上でのクリック操作一つで、素早く展開できることだ。「Windows ServerとSQL Serverがインストールされた仮想マシン」であっても、「Red Hat Enterprise LinuxとMySQLがインストールされた仮想マシン」であっても、ほんの数分で起動できる。これが可能なのは、4000種類以上の「OS、ミドルウエアインストール済み仮想ディスクイメージ」が、Amazon S3に登録されているからにほかならない。

　Amazon EC2でプロビジョニング（サーバー展開）が自動化できるのも、バックアップが高速なのも、すべてはAmazon S3のお陰である。Amazon S3に相当する機能を、同等の価格で提供している日本のサービスに筆者はまだ出会っていない。Amazon S3の正体は、米Amazon Web Services（AWS）が独自に開発した大規模分散ストレージだ。ストレージ装置を外部から購入する必要がある一般のホスティング事業者では、コスト面でAmazon S3に対抗できない。

技術的にも凄いAmazon S3

　2006年3月に始まったAmazon S3は、2010年3月の時点で、1兆個を超えるオブジェクト（ファイル）を保存している。世界最大規模のストレージサービスだ。このAmazon S3の凄さを、筆者はこれまでうまく説明できていなかったように思う。グーグルの技術的特徴については「グーグルは“異形”のメーカー、ここが違う10個のポイント」という記事を書いたことがあるが、Amazon S3に関する同種の記事はまだ書いていない。

　理由ははっきりしている。Amazon S3の基盤技術に関する情報が、外部に公開されていないのだ。グーグルの基盤技術は、同社が公表する技術論文からうかがい知れる。「Googleを支える技術」という良書もある。だがAmazon関連はそうではない。ショッピングカートで利用されているキー・バリュー型データストア「Amazon Dynamo」の論文がある程度だ。

　ところが最近、筆者はAmazon S3の構造をうかがい知ることができる資料を「再発見」した。その資料とは、2008年7月にAmazon S3で発生した大規模障害に関する報告書だ。

　Amazon S3では2008年7月20日（米国時間）に、サービスが9時間にわたって利用できなくなるという障害が発生した。その原因を同社は、「Amazon S3 Availability Event: July 20, 2008」という報告書にまとめている。筆者は先日、あるセキュリティ関連の勉強会で、クラウドに関連するトラブルの歴史を振り返るというプレゼンテーションをすることになったので、この報告書を2年ぶりに読み返してみた。

　この報告書で驚いたのは、障害の原因が「ゴシップ（伝染）プロトコル」にあったことだ。ゴシッププロトコルとは、サーバー間における情報の伝播にかかわるプロトコルだが、それがAmazon S3にどう関連するのか、説明しよう。

　Amazon S3のような分散ストレージは、何十～何百台というサーバーで構成される。「どのデータをどのサーバーが管理している」という「ノード一覧表」がなければ、利用者はデータを読み出したり書き込んだりできない。

　ノードの数が少ない場合、ノード一覧表は1台のマスターサーバーが管理すればよい。しかしノードの数が増えるにつれて、ノード一覧表への問い合わせは膨大になる。マスターサーバーがシステムのボトルネックになったり、SPOF（Single Point of Failure、単一障害点）になったりする恐れがある。

　そこで大規模な分散ストレージでは、ノード一覧表を管理するマスターサーバーを複数台設置したり、いっそのことマスターサーバーを無くして全ノードがノード一覧表を持つP2P（ピア・ツー・ピア）の構成にしたりする。このようなシステムでは、複数のマスターサーバー間やノード間で、ノード一覧表を交換し合う必要がある。その手法の一つがゴシッププロトコルで、伝染病が広がる様を模していることから、そう呼ばれている。

　Amazon S3で2008年7月20日に発生した障害では、このゴシッププロトコルに障害が発生したため、どのデータがどのサーバーに保存されているのか、分からなくなってしまった。システム全体を再起動し、ノード一覧表を作り直す必要が生じたため、サービス停止時間が長期化してしまったようだ。

　なおゴシッププロトコルは、キー・バリュー型データストアのAmazon Dynamoでも利用されている。その詳細は、Amazon Dynamoの論文をベースにキー・バリュー型データストア「kai」を開発した井上武氏が技術評論社の「gihyo.jp」に寄稿しているので、ぜひご一読頂きたい。

学ぶともっと分かるクラウド

　実は筆者は、2008年7月の段階で、上記の障害報告書を読んでいた。しかし、当時はクラウドの特徴であるスケールアウト技術に関する知識が不足していたので、その「意味」を理解できなかった。Amazonは巨大なストレージサービスを実現するために、同社のデータセンター内に閉じたP2Pシステムを運用していた。クラウドを追いかけ続けることによって、何とか2年前の「最新情報」を読み解けた。

　クラウドは、学べば学ぶほど、その奥深さが見えてくる。明日から始まる大型連休中に、あなたもぜひ、クラウドの技術的特徴について学んでみてはいかがだろうか。きっと新しい発見があるはずだ。2年前に比べると、クラウド関連の技術情報はびっくりするほど増えた。学ぶなら、今がチャンスである。

　入門編としては、4月22日に発売した「クラウド大全 第2版」をお薦めしたい。総論部分やAmazon EC2パート、スケールアウト技術の総論パートは、筆者が担当した。もっと深く技術を学びたい方には、アスキー・メディアワークス刊行の「雲の世界の向こうをつかむ クラウドの技術」がよいだろう。日経Linuxが3月に発行した「みてわかるクラウドマガジンvol.1」も、表紙のイメージとは正反対の硬派な内容だ。

　学ぶ段階を脱して、システム構築の実践に移るなら、オライリージャパンの“象本”こと「Hadoop」は欠かせない。Hadoopは、Googleの大規模分散処理システム「Google File System」と「MapReduce」のオープンソース版だ。日経コンピュータ2010年4月28日号でも、日本におけるHadoopの導入事例（楽天、NTTデータ、三菱東京UFJ銀行など）を取り上げたので、ぜひご覧頂きたい。