クラウドサービスが安いか？

クラウドサービスが安いかという質問はかなり自分の頭の中に響いている。
実際はクラウド型ストレージ「Amazon S3」は安いか？それとも自社サーバ運用のほうが割安？と回答する記事が見つかった。
結論はどっちもない
似合うなら安い。似合わなければ高い。ということだ。

クラウド型ストレージ「Amazon S3」は安いか？自社サーバ運用のほうが割安？

2009/01/09

　Amazon S3は安いか高いかという議論を、この2日間で立て続けに3個所で耳（目）にした。

　1人はネットサービスベンチャーのCTOで、クラウドへの移行を検討しているものの、Amazon S3やEC2の実際の価格や使い勝手がよく分からないという話だった。コスト的に見合うなら、もうサーバ運用に煩わされたくないと漏らしていた。

　もう1つは、ベンチャーキャピタルとして知られるYコンビネーターの掲示板で見かけた「Does Amazon S3 really save money？」で始まる議論。1GB当たり1カ月で0.15ドルと聞くと安いようにも思えるが、1TBの月額は150ドル、2年にすると3600ドル（1ドル92円として約33万円）にもなる。しかも転送量に応じた課金もあるため、実際にはこれ以上になる。今や1TBのドライブ単価は1万円を割っていて、2年で3600ドルとは比較にもならない。「クラウドでコスト削減」というのはお題目でしかなく、ちっとも安くないじゃないかという。

　Amazon S3は安いのかどうかという議論で、私が目にした3つ目は、テックバイザージェイピー 栗原潔氏の「クラウドコンピューティングは安上がりではない」と題するブログエントリだ。栗原氏はクラウドを使っても必ずしもコストを下げられないことを、上に似た計算で示し、今後企業のIT部門ではクラウドとオンプレミス（自社所有）の使い分けポートフォリオが重要になってくると指摘している。

　栗原氏は計算で、単価の高いエンタープライズ・ストレージを想定している。さらに、TCOに占めるハードウェア価格は30％という経験則から逆算し、単なるハードウェア価格だけでなく保有コストを算出、オンプレミス型での1TB当たりのストレージ単価を60万円と概算している。これを5年で償却するとすれば月額1万円となる。つまり割高なエンタープライズレベルの製品を使い、運用コストまで含めても、まだAmazon S3より割安だという。

誰がAmazon S3を使っているのか？

　個人PCユーザーとしてAmazon S3をバックアップ用に使おうと考えたことがある。しかし、まったく非現実的な料金となることが、すぐに分かった。聞き慣れていないために「1GB15円」と聞いてもピンと来ないが、Amazon S3はストレージ容量単価だけから考えれば、ふつうに市場に買えるドライブに比べて非常に割高なサービスなのだ。

　Amazon S3が割高なことは、すぐ分かる。ではなぜ、Amazon S3を歓迎している人々がいるのだろうか？ いったい、どういう人々がクラウドサービスを利用しているのか。

　上述した掲示板の議論に登場した写真共有サービス「SmugMug」のCEOで"チーフ・ギーク"を名乗るドン・マカスキル（Don MacAskill）氏が、この疑問に答えてくれているので、彼の体験談を参考に、今後のAmazon S3の可能性を考えてみたい（マカスキル氏の主張は、掲示板からブログエントリや過去の講演用スライドなどをたどれるほか、業界紙のインタビューからもうかがえる）

数百TBのデータをAmazon S3に預ける写真共有サイト

smug01.png写真共有サービスのSmugMug

　2007年の講演資料によれば、SmugMugがユーザーから預かっている写真は1億4000万枚。その192TB分のデータをすべてAmazon S3に置いているという。データ量は年々倍増中というから、現在は300TBを超えている可能性もある。これは、月間7億枚の写真がアップロードされるというFacebookのようなマンモスサイトに比べると小さいが、それでも十分に大きい。

　同社は最初、Amazon S3をセカンダリのバックアップ用途として使い始め、その後に本番用として使うようになったという。プライマリとして使うようになった後も、レスポンスを上げるためにサーバパークの位置をアメリカの西海岸から東海岸に移してみたり（Amazon S3はアメリカに2つ、ヨーロッパに1つサーバパークが計3つある）、トラフィックを抑えて従量課金を安く済ませるためにアクセス頻度の高いデータ（写真）については自社サーバにキャッシュしたりといった工夫を加えていったという。

　独自ファイルシステムの実装によって、アクセス頻度の高いデータは手元の自社運用データセンターから出し、そうでないものはAmazon S3にあるデータを取ってきてから出す、という階層アーキテクチャにしたことで、自社ストレージの台数を95％削減できたという。アップロードされるほとんどの写真は、あまり参照されないため、自社ストレージに置くまでもないということだ。この階層化によりAmazon S3上に全データを保存、そのうちアクセスの多いものをキャッシュとして5％程度を自社サーバにキャッシュするという構成になっているわけだ。

　これはエンタープライズストレージベンダが階層化ストレージと呼ぶアーキテクチャに似ている。企業内のデータでも、ほとんどアクセスされない古いデータが多い。そうしたデータは安価で低速なストレージに（自動的に）落とし、ディスクの回転さえ止めてしまうことで容量単価や消費電力を下げられる。階層化ストレージの分野ではサン・マイクロシステムズがDRAM、SSD、HDDといった物理デバイスの違いを完全に階層化、抽象化する革新的なストレージ・アーキテクチャを昨年末に発表してもいる（参考記事：ZFSでNASアプライアンスをつくるとこうなる）

Amazon S3はIDC間のリアルタイムレプリケーションに相当

　マカスキル氏はコスト面で自社サーバのストレージより、Amazon S3に優位性があるという。冒頭に上げた容量単価の計算は、いくつかストレージ運用において重要なポイントを見逃しているため的外れな計算だと指摘する。

　1つはデータの冗長構成についてで、Amazonは地理的に離れた最低2つのデータセンターにまたがって3重の冗長度でデータを保持している。自前で同様のことをするには、RAID構成のストレージを2つのデータセンターに置き、それらの間でリアルタイムのレプリケーションを行う必要がある。

　事業継続性の観点からは最も望ましい形だが、非常にコストがかかるため、このような構成でITシステムを運用しているのは、大企業でも一部に限られるだろう。東京・大阪など2地点間でリアルタイムでデータを二重化するとなると、その帯域費用もかかる。

　Amazon S3のサービスと比較すべきなのは、秋葉原で売られているベアドライブではなく、エンタープライズ向けの中でも比較的贅沢な冗長構成で高可用性を実現するソリューションを組み合わせた"システム"だ。電気代、場所代、運用ソリューションのライセンス料、回線帯域の費用などがすべて含まれた上での価格だと考えればAmazon S3は高いものではない、というのがマカスキル氏の指摘だ。

　マカスキル氏が指摘するもう1つの論点は、時間による容量単価下落の影響だ。Amazon S3のようなサービスなら、ドライブの容量単価が年々下がるにつれて課金が下がっていくと期待できる。アマゾンは、そのときどきで新しいドライブを買い増すからだ。

　栗原氏は計算で、5年というライフサイクルを仮定しているが、例えば今から5年前、2004年1月のHDD価格を見ると、容量120GBのドライブが8000円程度となっている。過去5年で容量単価はざっと10分の1に下がっているわけだ。「18カ月で集積度が2倍になる」としたムーアの法則を当てはめると「2の（（5年×12カ月）／18）乗＝10.079」と、ムーアの法則が成立していることが分かる。

　5年で容量単価は10分の1に下がる。つまり、5年前の2004年に割安だった120GBのドライブの月賦を、2009年の今になっても同額で払い続けたいか、ということだ。マカスキル氏によれば、実際に過去アマゾンが安価なストレージを買い足した際に、SmugMugに対する請求額が大幅に下がったという（より詳しいAmazon S3のコスト構造の議論は、Amazon Webサービスチームのジェームス・ハミルトン氏が個人ブログで論じている）。

　アマゾンには、不当な利幅を確保できるほどロックインの力もない。いざとなればAmazon S3からデータを引き上げることもあり得るが、その引き上げコストをマカスキル氏は、おおよそ1カ月の課金に相当する程度だと指摘している。

　さらに同氏は、Amazon EC2のインスタンスからだとS3との転送課金が発生せず、両者の相性が良いことや（当然といえば当然だが）、キャッシュフローや税制面からも一度に費用が発生するハードウェア購入より、クラウドの従量課金のほうが有利であることも指摘している。

　これはもう指摘するまでもないことかもしれないが、容量設計が不要でスケールアップが容易という点も、クラウドのような従量課金サービスのメリットだ。特にスケールアップペースが読みづらく、しかも会社の規模の割に桁違いに大きな容量を扱うWeb系ベンチャーではそうだろう。

システム障害は起こるもの

　気になるのはサービス停止などのシステム障害だが、この点についてもマカスキル氏は体験談や考察を述べている（ここやここ）。

　2006年4月から2007年1月までの間に、Amazon S3で4度、大きな障害に遭遇したという。最初の2度はコアネットワークのスイッチが落ちるほどの致命的な障害でシステムは15分〜30分間完全に停止し、SmugMugもその影響を免れなかったという（当然SmugMugの有料アカウントユーザーは怒った）。しかしまた、その晩はAmazon.comが落ちていた。確証はないものの、マカスキル氏は、アマゾンは自社プロダクトを自社の本番サービスで使う、いわゆる"ドッグフードを自分で食べる"タイプの企業ではないかとしている。

　過去に4度あった大規模なAmazon S3の障害にうち、残りの2回はサービス停止ではなく、大幅な遅延の発生だった。そのうち1度についてはユーザーが気付くレベルの問題だったが、もう1回のほうは、すでに上に紹介した階層化アーキテクチャを採用していたためにほとんどのユーザーは気付かなかっただろうとしている。

　グーグルも落ちるし、アマゾンも落ちる。オンラインバンキングのようなサイトですら落ちる。100％のアップタイムを持った大規模でスケーラブルな分散システムは、誰が設計や運用をやっても今のところ実現不可能だ。ましてベンチャーの自分たちは、インフラのイノベーションを継続しつつ運用するなど不可能なわけで、「ダウンタイムはあるものだ」と割り切り、コストとバランスして考えるべきだというのがマカスキル氏の論理だ。写真共有サイトという本業に注力し、インフラは世界のトップレベルのグローバル・ネットワーク企業に任せる、という分業だ。

日本から使えるか？

　SmugMugのようなITベンチャーならいざ知らず、アマゾンがクラウドを作り出す試行錯誤に付き合い、それに適したアーキテクチャを設計・実装するようなことは、一般企業のIT部門ができることではないかもしれない（とはいえ、RESTでオブジェクトをGETするだけ。SmugMugがやっているのもオブジェクトのアクセス頻度でそれを場合分けするだけのこと）。この意味ではクラウドで総称される技術は、まだ企業にとってその動向を静観するべきものでしかない。中長期的に見れば、ストレージアプライアンスとして提供される階層化ストレージの一番下のレイヤーに、いつの間にかクラウド上のストレージサービスが加わっていた、という形で企業ユーザーには浸透していくのかもしれない。

　だから、まだアマゾンのクラウドは使いづらいというのは正しい。特に日本からとなれば、アマゾンがアジア向けサーバパークを上海辺りにでも開かない限り、Amazon S3もEC2も遅延が大きいために日本からは使いづらいだろう。ただ、2008年11月にアマゾンが開始したCDNサービス「Amazon CloudFront」（参考記事：アマゾンが従量課金CDNサービスを開始）は、東京にもエッジサーバがあるため、これをS3と組み合わせれば、すでにコスト、パフォーマンスの面で利用すべき用途があるかもしれない。例えば拠点数の多い企業が社内向けの動画配信のインフラとして利用するといったことも考えられるだろう（あまりにも新しいサービスのために、Amazon S3とAmazon CloudFrontの組み合わせの実用性はもちろん未知数だが）。

　Amazon S3に限った話ではないが、クラウドサービスにはプラスもマイナスもあり、冷静に検討すればまったく割に合わないケースも多いだろう。そうした意味で、当初クラウドという言葉を誰もが口にするようになった頃にバラ色の幻想が生まれたとすれば、それは一旦は棄却すべきだ。しかし、本当の意味でITを活用しようという利用者なら、そろそろ日本からでも実験を始めてもいい時期だ。