クラウドを「分散/並列/スケールアウト」の観点から見るとよく分かる、という話

クラウドという言葉はバズワードではないかという話はよく聞くが、ここまで広く使われているのは当然ながら理由がある。

Web2.0の時もそうだったが、そのような言葉が頻繁に使われるということは、今、何か重要な変化が起きており、その変化がある方向に向かっているということなのだ。それを言い表す際に「クラウド」という言葉が便利に使われるのだろう。重要なのは、その「変化」を捉えることであり、クラウドという言葉の定義をすることではない。

クラウドという言葉はビジネスシーンでは「ネット上にサービスを置き、水道や電気のように必要な時に必要なだけ使えるようにする」というような文脈で語られることが多い。

しかし、我々技術者にとっては、クラウドとは「実用段階に入った分散/並列処理技術」であり、「スケーラビリティを確保する為の現実的な解」という、非常に具体的な意味を持つ。

分散、並列、スケーラビリティ（スケールアウト）という観点から見ると、「クラウド」というものの正体が見えてくる。今日はその観点からクラウドについて語ってみたい。尚、文中のリンクは、調べればすぐ分かる英語の公式サイトのURLではなく日本語の解説サイトやニュースなどにジャンプするようにした。

そもそもはGoogleが、自社のサービスの為に大量の安価なPCを使って巨大なデータセンターを作った事が注目され、そこから「ネットの向こうにあるコンピュータ・リソース」という意味で「クラウド」という言葉が使われ始めたと理解している。

そのGoogleが2003年に自社内の分散処理技術を論文にして発表したのが、最近良く名前を聞くGFS(Google File System)、BigTable、MapReduceと言った技術だ。

GFSは分散ファイルシステムであり、BigTableはkey-value型の分散データベース、MapReduceは、それらのストレージを使った分散・並列処理のアーキテクチャである。これらはGoogleのサービスを支える基盤技術となっている。

つまり、技術的な側面から「クラウド」を見るとき、我々は「ネットの向こうにコンピュータがある」という概念レベルの話ではなく、「分散・並列処理システムが実用化した」ということをしっかりと認識しなくてはならない。

そして、Googleのシステムを見る時に忘れてはならないのが、安価なPCを大量に並べてどんどん規模を拡大してゆく「スケールアウト」な仕組みである。

一般的に、コンピュータが1台から2台に増えたからといって処理能力が直ちに2倍になることはない。何故なら、コンピュータに与えられる処理は通常、逐次的（AをやってからBをやって、次にCという具合に）であり、2台以上のコンピュータが同時並行に処理を行う為にはそれなりの工夫が必要だからだ。

だから、これまでコンピュータの処理能力を上げるには、より高速なCPU、より高速かつ大容量なHDD、より大量のメモリなどが（ある意味安易に）利用されてきた。これならば、特にシステムのアーキテクチャを工夫せずとも単純に処理能力をアップできる。これらはスケールアウトではなく「スケールアップ」と呼ばれる手法である。

しかし、現代においてウェブ・サービスを提供するには、スケールアップという選択肢は取れない。ユーザー数がいつ爆発的に増えるかもしれず、その時にマシンのCPUやHDD入替などといった悠長な手段は取っていられない。そもそもスケールアップの手法には能力的な限界があり（最高のCPU、最大容量のHDDをつけたらそこで終わり）、どこまでも増えていく需要に対応するのは不可能だ。

Googleにはスケールアウトという方法しかなかった。安価なPCを大量に配置してコンピュータ・グリッドを作るという方法論は、何もそれがローコストだったからというのが唯一の理由ではなく、「コンピュータを追加していけば、その分だけリニアに処理能力が上がっていく」というスケールアウトの仕組みが彼らに取って重要だったのである。

かくしてGoogleは、スケールアウトが可能な分散・並列処理コンピュータを作り上げ、そのパワーを利用して様々なサービスを提供しているわけだが、ネット上のサービスを提供しているのは何もGoogleだけではない。例えば日本にも、Yahoo!Japanやmixi、楽天などの大規模なネットサービスを提供しているベンチャー企業が存在する。

彼らも当然、スケーラブルな分散・並列処理環境を必要としている。日々増える大量のユーザーからのトラフィックを捌くには、どうしてもそれらが必要なのだ。ネット系ベンチャーにとって「ネット上にサービスを置いて提供する」というクラウドの話は、スケーラビリティと分散・並列処理について考えることに他ならない。

この話は、データベースについて考えるとよりよく理解できる。
負荷分散のネックは常にデータベースだ。

例えば、静的なHTMLを配信するサービスだったら、スケーラビリティの確保は簡単だ。単にWebサーバを増やして、ロードバランサを介してラウンドロビンで各Webサーバへリクエストをディスパッチすれば良い。全Webサーバに同じHTMLを置いておけば、各Webサーバはどんなリクエストにも答えることができる。リクエストが増えたら単純にWebサーバを増やせばよい。

しかし、もしHTMLファイルではなく動画を配信しようとすると、「全Webサーバに全動画を置いておく」という事が非現実的になってくる。1サーバのHDD最大搭載容量を超えるからだ。いくつかのサーバへ分散して格納するしかない。そうすると、サーバ1にはある動画はあるがある動画は置いてない、という事が起こる。すると、ロードバランサは、単純にラウンドロビンでリクエストを割り振っている訳にはいかなくなってしまう。リクエストに応じた動画ファイルが存在するサーバを見つける、何らかの仕組みが必要だろう。単純な例ではこれは、ハッシュを用いて解決する。動画ファイルのIDに対するハッシュ値を計算し、その値から自動的にサーバIDが決定するようにすればいいのである。

これが動的なコンテンツを持つサービスになると、話がさらに難しくなる。
例えばこれがmixiで、そのユーザーがコミュニティのトピックにコメントを書いた場合、その更新は直ちに他のユーザーからも見えるようにならなければならない。つまり、負荷分散の為にトピック用のデータベースを各サーバーにコピーして置いておく、というだけではダメだ。あるサーバでは更新されているのにあるサーバから見たら更新されていないことになってしまう。それどころか、1番のコメントが2つ以上存在する、という状況にもなりかねない。コピーされたデータベースは、何らかの形で同期を取る必要があり、それがシステムのボトルネックとなる。

一般的には、読み出しはコピーされたデータベースから行い、書き込みはコピー元となるマスターデータベースに対して行って、その後コピー先へ変更を反映する、というような事が行われる。一時的に「更新されたのに他ユーザーから見えない」という状況は生まれるが、少なくとも同じ番号のコメントが2つ存在するような状態は回避できる。もちろん実際にはもっと複雑なことが行われる。突き詰めていけば、これは分散ファイルシステムや分散データベースというアーキテクチャに行き行く。

また、手元に集まった膨大なデータをバッチ処理する為には、並列処理という事を考えなくてはならない。Googleが大量のウェブ・ページをインデックス化する為にMapReduceというアーキテクチャを考案したように、彼らも日々、何らかの大規模バッチ処理をこなさなくてはならない。例えば日付切り替えに伴う処理であったり、不要なデータを定期的に削除するような処理だ。mixiで言うと、全日記の頻出キーワードを割り出したりするような処理は、1台のコンピュータでこなしていてはとても間に合わないはずだ。

そして最後にスケーラビリティ。日々徐々に増えるユーザーへの対応だけでなく、ある日突然爆発的にサーバ負荷が上がることはよくある。その際に手軽にサーバ処理能力を増減できるスケールアウトな仕組みを構築しておくことは、もはや企業としての生命線とも言える。

mixiやYahoo!Japan、楽天など、大量ユーザー・大量トラフィックを捌く日本のネット系ベンチャー企業（つまり、クラウド・ビジネスを行っている企業）が、分散処理やスケーラビリティに心血を注ぐのは当たり前なのである。

mixi Engineers’ Blog » Tokyo Tyrantによる耐高負荷DBの構築
http://alpha.mixi.co.jp/blog/?p=166

Hadoopで、かんたん分散処理 (Yahoo! JAPAN Tech Blog)
http://techblog.yahoo.co.jp/cat207/cat209/hadoop/

本を読む楽天でROMAとfairyの話を聞いてきた
http://emasaka.blog65.fc2.com/blog-entry-506.html

さて、ここまで読むと、「クラウドって、もう一般のエンジニアが立ち入れる領域じゃないんじゃないか？」と思われる方もいるだろう。また、「別に私はmixiみたいな大規模サービスを立ち上げる予定はないから関係ない」という方もいるかもしれない。

しかし、今やどんな小さなサービスだろうと、増え続けるトラフィックへの考慮は必須であるし、ビジネスがワールドワイドになっている昨今、サービスは世界中からのアクセスの可能性を考えなくてはならない。

「うちが作るシステムは、大量ユーザーを捌くこともできないし、トラフィックが増えてもスケールアウトできませんが、よろしいですか？」では話にならないのだ。

そしてもちろん、解決策は用意されている。決して一般のエンジニアに立ち入れない領域ではなくなっている。その代表が、Amazon Web Services(AWS)である。

クラウド・システムを構築するということは、当然、コンピュータを何台も用意するということだ。ネットワークに接続され、RAIDなどの高可用性対策を施し、バックアップ体制を完備したシステムを、いくつも準備する。これがかなり面倒くさい。最近だとブレードサーバ＆仮想化という選択肢もあるが、どちらにせよデータセンターを用意してそのセキュリティを作るとなると、もう、一般のエンジニアにはお手上げだろう。

しかし、Amazon Elastic Computer Cloud（Amazon EC2）を使えば、これらは瞬時に解決する。Amazon EC2は、ネット上で手続きを取れば、その場で利用できるサーバをネット上に用意してくれるサービスだ。100台だろうが一瞬。しかもその手続きはAPIで自動化できる。

これは単に「サーバを用意するのが簡単だ」というだけに留まらず、「負荷が高くなってきたらもう一台増やす」ということが、人間の手を介在せずとも自動化できるのである。

これ以外にも、データを保存する為のストレージも、Amazon Simple Storage Service（Amazon S3）やAmazon Elastic Block Store（Amazon EBS）を使えば簡単に用意できる。

もちろん、サーバやストレージをいくら動的に用意できるようになったところで、肝心のシステムがスケーラブルでなければ、意味がない。サーバを増やしても、リクエストをうまく分散できるシステムを一緒に用意する必要がある。それらの手段を用意できる技術者であれば、EC2/S3/EBSを使ってクラウドサービスを構築することができるが、そうでない技術者は、別の手段を取る必要がある。

Webサーバーは、さきほども書いたとおり、比較的スケールアウトが簡単だ。問題はデータベース・サーバーである。そしてこれに対するAmazonの回答が、Amazon SimpleDBだ。

Amazon SimpleDBは、簡単に言うと、自動でスケールするデータベースである。負荷が高まると自動的に処理能力を増強し、対応してくれる。但しこれはkey-valueストアと言われるタイプのDBで、RDBMSのようにテーブル同士を連結させたりといった複雑なクエリーは発行できない。とはいえ、ほとんどのケースではこれらは問題にならない。

Amazon SimpleDBを使えば、最も困難な部分である「スケーラブルなデータストア」を簡単に実現できる。後はWebサーバを負荷に応じて増減するだけで良い。

Amazonではこれ以外にも、サーバ同士をメッセージ・キューによって疎結合する為のAmazon Simple Queue Service（SQS）も用意している。スケールアウト可能なシステムの構築には、メッセージ・キューによる疎結合が有効と言われており、自前でクラウドを構築する際の強力な武器になるはずだ。

最近では、Amazonのコンピュータ資源を使ってGoogleのMapReduceを動かすAmazon Elastic MapReduceも公開された。内部的にはMapReduceのオープンソース実装であるHadoopを利用している。MapReduceは大量データのバッチ処理を複数のマシンで並列に行い高速化できるアーキテクチャだ。Amazon Elastic MapReduceが公開される前だが、米ニューヨーク・タイムズが、EC2とS3を使ってHadoopクラスタを構築し、自前のコンピュータなら14年はかかると思われた過去記事の全PDF化を24時間で完了させ、コストも240ドルしかかからなかった、という話が有名である。

このように、Amazon Web Servicesを使えば、個人であってもクラウド・サービスを構築することは十分に可能だ。クラウドの文脈でEC2などのAmazonのサービスが語られるのは、何もEC2自身がクラウド・サービスだからというだけではなく、それらを使って自分でクラウドを作る事が出来るからである。

また、SimpleDBなどを使わずとも、クラウドを構築する為の様々なオープンソース・コンポーネントがあるので、EC2などと組み合わせてそれを使うのも良いだろう（分散インメモリキャッシュ memcachedやmixiのkey-value型データベースTokyo Cabinetとそれをネットワーク越しに使うTokyo Tyrant、分散データベース Apache CouchDB、BigTableのオープンソース実装Hypertable、等など…）。オープンソース以外でも、分散インメモリキャッシュOracle Coherenceや今年前半期には登場すると言われているMicrosoftのVelocityなども使えるかもしれない。

しかし、これでもまだ、ちょっとハードルが高いと思われる方もいるに違いない。私なんかも結構そのクチだ。でも安心して欲しい。そういう人の為に、Google App Engineがある。

Google App Engine（GAE）は、そこへPythonで書いたウェブ・アプリケーションをアップロードすると、そのアプリケーションが自動的にスケーラブルになる、という、とんでもなく楽チンなクラウド・プラットフォームだ。

GAEで使われるデータベースはBigTableという分散データベースやGoogle Datastoreという分散データストアであり、Webサーバ自身も自動的に負荷分散を行ってくれる。多少の制約はあるが、その制約に従っている限り、開発者はスケーラビリティについて何も考えなくても良い。面倒なことは全部Googleが肩代わりしてくれるのだ。最近、GAEはPython以外にもJavaのサポートも開始し、クラウド・プラットフォームとしての魅力を増している。

また、SalesForceも、似たようなクラウド・プラットフォームを公開している。SalesForceは顧客管理サービスだが、そのプラットフォームをアプリケーション開発プラットフォームとして公開している。SalesForceプラットフォーム上で動作するアプリケーションを作ってデプロイすれば、直ちにスケーラブルになる。こちらはRDBMSも利用できる。

同様の流れとして、SNS最大手FacebookのFacebookプラットフォームや、それに対抗するGoogle他SNS陣営のOpenSocialも近い位置付けにある。

そして、もうすぐ登場予定のMicrosoftの切り札、Windows Azureという選択肢もある。Azureは、言ってしまえば、Amazon Web Servicesのようなクラウド・コンポーネントを一つのプラットフォームの上にまとめてしまった「クラウドOS」である。

Google App Engineのように、アプリケーションを作ってアップロードすれば、自動的にスケールするサービスが完成する。しかも制限の多いGAEとは違い、メッセージ・キュー・サービスなどを使ったかなり複雑なシステムも構築可能である。Azureでは、従来のWebサービス側に相当するWeb Roleと、ビジネスロジックに相当するWorker Roleという単位にサービスを分離し、それぞれをメッセージ・キュー・サービスで疎結合させる。そしてデータの受け渡しは分散データベースAzure SQL Data Service（Azure SDS）やAzure Storage Serviceを介して行われる。これらによってスケーラビリティを保証するのである。

Windows Azureのようなプラットフォームでは、アプリケーションの作り方がこれまでとはかなり違ってくる。分散/並列処理やスケーラビリティについて自分で一から構築する必要はなくとも、それに合わせたシステム設計というのは必ず必要になる。このような「お任せタイプ」のクラウド・プラットフォームを利用した場合であっても、クラウドについて何も考えなくても良いというわけではない。そもそも、「どのクラウド・プラットフォームを使うのか」から考える必要すらある。

技術者にとっての「クラウド」が、いかに現実的かつ、重大なパラダイム・シフトかお分かり頂けただろうか。それは概念レベルの話ではなくプラットフォームそのものが変わる大きな変化の流れであり、既存の考え方がまるで通用しなくなる可能性を秘めている。

丸山不二夫氏によれば、クラウドはコンシューマからエンタープライズ用途へとフォーカスを移しつつあるという。のほほんとしている間に、システム設計もできない、設計書を見てもちんぷんかんぷん、というような事態にだけはならないようにしたい。

クラウド周辺の話題は、調べていけばもっとコアな情報がわんさか出てくる。この記事は単にネットなどに分散している情報を自分なりにまとめただけなので、漏れなどもたくさんあるだろう。興味を持った人はいろいろ調べて欲しい。

尚、クラウドについての日本語の情報としては現在、UNIX magazine 2009年4月号の総力特集「クラウドをつかむ」が最も詳しくまとまっているように思う。クラウドの技術的な側面の解説から、Google(Google App Engine, MapReduce), Amazon(EC2,S3,他), SalesForce, Oracle(Coherence), Microsoft(Windows Azure SDS)など、様々な企業のクラウドへの取り組みを、ソースコードを交えて解説している。クラウド時代のモデリング手法や設計上の課題などにも言及されている。今回のまとめも、ほとんどがそこから情報を得ている。既にネット書店では在庫切れになってしまったようだが、リアル書店を回ればまだ手に入ると思われる為、興味がある方はぜひ入手して欲しい（追記：2009年4月26日現在、在庫ありになった。増刷されたらしい）。さらに技術的な詳細については、「Googleを支える技術」や「24時間356日サーバ/インフラを支える技術」も良い教科書になるだろう。

【参考】

【追記】
この記事も非常に良い。技術者の視点でアプリケーション・プラットフォームとしてクラウドを体験してみるお話。ただ、他のクラウドが★４つや５つと高評価なのに対してWindows Azureだけ★が２つとやたら辛口で、その理由がまったく書かれていないのが謎。Azureだけソースもキャプチャもないし。追記とか欲しいところ。
クラウド体験記（前編）－＠IT
クラウド体験記（後編）－＠IT

【追記2009.05.20】
AWSがEC2向けクラウド管理機能を公開
http://jp.techcrunch.com/archives/20090518aws-rolls-out-cloud-management-and-scalability-features-for-ec2/

Amazon Web Servicesにて、「CloudWatch（負荷監視機能）」「Auto Scaling（自動スケーリング）」「Elastic Load Balancing（ロードバランシング）」の３つの機能が追加されたようです。（但し現在はUS向けのみ）
これらを使って、「負荷が高まってきたら自動的にEC2インスタンスを増やし、リクエストを自動的に分散させる」ということが簡単にできるようになります。

どんどん使い易くなっていきますねー。

【追記】
例のUNIX Magazineの内容に大幅加筆・修正を加えたムック本が出ていますのでご紹介します。中古で効果なバックナンバーを買うより、この本を買った方がいいですよ。