お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

スケールアウトからスケールアップへの回帰

2010/01/12 10:48
  • このエントリーをはてなブックマークに追加

これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。

年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。

ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。

では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。

それは、過去10年あまりで定着した、これまでの(そして今なお)Webアプリケーションの定番構成である、「ロードバランサ、アプリケーションサーバ、データベースをそれぞれ複数台で構成する」というモデルを設計・保守する労力、であると思う。

今から10年前、ウェブサーバのメインストリームな構成といえば、CPUがPentium3/600MHz、メモリ搭載量は128MBというものだった。当時、ウェブ・アプリケーションを処理する主環境であったPerlやJavaにとって、これはCPUやメモリがボトルネックになりやすい、ということを意味した。アクセスが少しでも増えたら、すぐにサーバを増強しないといけない。だから、サーバを増強しやすいシェアド・ナッシング方式があっというまに主流になった。つまり、データの一貫性保証はデータベースに一元化し、「アプリケーションサーバを買ってきて追加する」=「CPUとメモリをクラスタに追加する」という論理構成になるようにアーキテクチャを単純化し、保守をしやすくしてきたのである。

ところがいま、メインストリームなサーバのCPUはあれから30倍高速になり、コア数の主流は4だ。現在のマルチコア化のトレンドが続き、かつムーアの法則が健在だとすると、(かなり単純化していえば)今から1.5年でコア数は8になり、3年で16になる。搭載メモリの増加率はもっとドラスティックだ。今や4GB搭載はデスクトップでさえ珍しいものではなくなり、一般消費者向けOSを64ビットに移行させる圧力にさえなっている。

つまり、2000年代ならアプリケーションサーバを30台必要としたサービスが、今では1台のハードでさばけるようになっていて、3年後には過去に120台のマシンを必要としたサービスが1台でさばけるようになるかもしれないのである。このトレンドは、もはやアーキテクチャの存続条件を変えるところまで迫っているといえるだろう。

また、NIC帯域を主に消費するロードバランサ、CPUとメモリを主に消費するアプリケーションサーバ、メモリとディスクI/Oを主に消費するデータベース、それぞれリソース消費プロファイルがあまりかぶらないため、同居にあたっての相性も悪くない。1台に共存させることで遊ぶリソースが減ってバランスよく使われるため、ハード投資あたりの利得は大きくなるだろう。

だから、これから5-10年ぐらいかけて、「スケールアウトの時代からスケールアップの時代へ」の回帰が始まるだろうと思う。思えばITの歴史のなかで集中化と分散化は大きな周期で何度も繰り返されてきているのだが、そういう年寄りの与太話につきあわせるのは本意ではないので今回は触れないでおく。

ただ、「スケールアップの時代へ」の転換はそれほど簡単に起きることではない。ここにひとつ、2010年ならではの新しい要因が加わってくる。それが「クラウド」の存在だ。

従来、スケールアップよりもスケールアウトが好まれた理由のひとつが、既存の投資が無駄にならない、ということだった。つまり、スケールアップを実行するには、たとえば2コアの古いハードウェアを廃棄して、新しい4コアのマシンに載せ替えるというようなことを意味する。この際、スケールアップのアーキテクチャにおいては、古い2コアのハードは使い道がなく捨てるほかないのだ。一方でスケールアウトの場合、2コアの古いハードウェアはそのまま使いつつ、安くなった2コアのマシンを追加すれば、同じ性能を約半額の投資で実現できる。これではスケールアップには経済合理性がない、ということになってしまう。

もうひとつは、すべてを1台に集約し、冗長性が失われることによる SPOF (Single Point Of Failure) の存在だ。クリティカルなシステムでは、システムダウンの時間を最小化することが重要だ。そして、すべてのハードウェアは必ずいつか故障する。だから、ルータを冗長化し、ロードバランサを冗長化し、アプリケーションサーバを冗長化し、データベースを冗長化し、どのコンポーネントが死んでもサービスを継続できるようにしなければならない(ということになっているが、どういうわけかグーグルやアマゾンでさえ年間の稼働率は100%ではない、という事実はあまり語られない)。

ところが現在はクラウド百花繚乱の時代だ。サーバは月額いくら、時間いくらで借りることができ、その価格もこなれてきている。スケールアップをしたければ、古いサーバを解約し、新しい上位サーバを契約してそちらに移行すれば済むのだ。サーバの故障は、ベンダーが最小限の時間で復旧してくれる。データのバックアップさえちゃんととってあれば、少々のダウンタイムと、少し過去の時点まで戻ることが許されるなら、それほど大変なことではない。

つまり、クラウドの存在によって、スケールアップ型のアプローチが、かなり現実的になってきたのである。

一般に、クラウドといえばCAP定理などに象徴される、超大規模な分散ストレージについての話になりがちだが、そんな最先端の基礎理論が必要になるのはトップ1%のなかの1%ぐらいのサービスで、世の中のほぼすべてのサービス開発者にとって、むしろクラウドの恩恵というのは以上のように一見地味な進化の中にこそあるのである。

と、ここまでは理論上の話。

現実的には、もちろん、サービスの規模が大きくなってくるとボトルネックがあちこち移動するため、いずれスケールアップによる対処が合理的でなくなり、古き良き複数台構成に組み直すべき時期がくる。そこから先は、アプリケーションの負荷傾向によって十人十色のアプローチが必要となってくるだろう。

しかしたとえそうであっても、サービスの成長スピードを横目でみながら、たとえば1年後に必要と判断したら、そのときに複数台構成にあわせて設計を変えたほうが、1年前に実行するよりもいい。

1年後なら、より向上した新しい機材やソフトウェアが使えたり、クラウド・サービスの選択肢が増えていたり、ボトルネック箇所はもはや仮説ではなく実証されているし、何よりも、サービスのリリース初期にこそ、あれこれ試行錯誤したり軌道修正したりが欠かせないのであって、ヘビーデューティな運用環境は開発者からそういった機動性を奪う一番のお荷物となってしまう。

私の周囲をみても、そういった複数台構成の経験をひととおり積んだベテランのなかに、あえて最初からそういったヘビーな設計をしない、という選択をする人が次第に増えているようにおもう。リリースされたサービスの多くは不発で終わる、という当たり前の確率論も、「絶対に成功するんだ」という意気込みはともかく、心のどこかで冷静にライフサイクルの計算もしている。あるサービスに見切りをつけ、もう時間を投資しないと決めたあと、そのサービスの保守がどれだけ心理的なお荷物になるかの経験があるからこそ、なるべく運用をシンプルにしておくことの価値を理解しているのだと思う。「早すぎる最適化は諸悪の根源」というコンピュータ・サイエンスの格言を引用するまでもなく、これは、未来の不確実性に対する、経験から得られるセンスなのだと思う。

さて、そろそろ具体例を出そう。

たとえば、インフォテリア社の好意でドメインを譲り受け、個人プロジェクトとして復活したLingr(未正式公開)ではSlicehostというVPSを使っていて、あえて最小限ギリギリの構成がどんなものか実験したかったので、メモリが512MBで月38ドルのスライス1個だけというケチケチ構成で動かしてみているけれど、この半年以上、問題なく動いている。こんなに廉価なのに、CPUは4コアが使えるのでとても高速だ。最初の2ヶ月ぐらいは256MBのスライスで動かしている時期もあったけど、さすがにそれだとアプリケーションサーバ(thin)を2個上げるのが精一杯で、しかもすぐにスワップが始まるので512MBに移行した。今でも並列度は3しかないけど、月間10万ヒット程度の現状(訂正:10万というのはあくまでページロードの数字で、APIアクセスを勘定に入れると月40万ヒット、60秒周期で全クライアントがロングポールするCometアクセスを入れると月200万ヒットを超えていることが判明。つくづく、ページビュー数というのは当てにならない数字だ)ならスカスカで、ぜんぜん余裕。ものは試しでやってみたら、予想以上のいい結果が得られて、自分でも少し驚いた。

現在のLingrは、完全にフルスクラッチでゼロから書き直していて、1台の仮想マシン上に、nginxがロードバランサ、アプリケーションサーバ(Ruby on Rails)としてthinが3つ、それとは別に、Cometコネクションを管理するEventMachineベースの自作サーバが1つ、その後ろにMySQLがいるという構成になっている。MySQLからは毎晩バックアップをとり、外部のFTPサーバに転送し、直近7日分を保管している。たったこれだけ。

MySQLを冗長化させるかどうかは迷ったけれども、RAID化やレプリケーションによる可用性向上をどこまでやっても絶対にバックアップの必要性はなくならない(ヒューマンエラーに対する唯一の手段)から、サービス初期にあえて保守点数の増えるマスター=スレーブ構成はとらず、バックアップをきっちり実行することに集中した。

ケチケチ構成ではメモリ使用量が一番のボトルネックになるのだけど、このぐらいのケチ水準になると、OSが32bitか64bitかというのも効いてくる。Slicehostは64bitで、サービス起動直後のメモリ使用量が420MBなのだけど、同じ構成をZerigoLinodeの32bit環境上で再現したところ、メモリ使用量が260MBにまで減ったので、32bitに移行しようかどうか悩んでいるところだ。ここに挙げたどのVPSも、CPUは4コアまで使えるので、「2000年頃のサーバ30台分」に相当する。CPUよりも他の部分が先にボトルネックになるだろう。

では、性能が不足してきたらどうするか?ここまでの流れから明らかなように、次にぼくが取る手段は512MBから1GBへのアップグレード、その次には1GBから2GBへのアップグレードになるだろう。thinのインスタンス数を増やしてスループットを稼ぎ、MySQLのバッファプールに大きなメモリを割り当て、ディスクI/Oがネックにならないようにする。EventMachineはもともとイベント駆動のI/O多重化の仕組みなので、リソース消費傾向としてはロードバランサに近く、CPUもメモリもほとんど食わない。

だから、スケールアウトなアーキテクチャに移行するタイミングは、CPUがどうにも足りなくなってきたときだろう。そしてそれは、CPUの稼働率が2-3%というほぼゼロ水準である現状をみると、そんな未来はすぐにはやってはこなさそうだ。たとえば、1年後だろうか?そうかも知れない。でも、その頃には8コアのサーバが主流になっているだろうけどね!

まぁ、こんな零細事例をみてもあまり参考にならないかもしれないけど、いいたいことは伝わったのではないだろうか。

最後にもうひとつある。

クラウドというのは、装置産業だ。多くのユーザを収容するため、土地(データセンター)を確保し、ハードウェアを大量に購入し、それを貸し出すことによってレントをとる。だから、ハードウェアを購入したタイミングで、そのベンダーが提供できる価格性能比の水準は決まってしまう。つまり、価格に下方硬直性がある。

しかし、技術は日進月歩だから、翌年にはもっと価格性能比の高いベンダーが登場する。後発のほうが常に有利なのだ。この新規参入による競争と価格低下圧力は、技術が進化する限りずっと継続する。

先行するベンダーには先行者利得があり、強い財務体質があるが、一方で価格の下方硬直性による先行投資の負債化も同時に起こるのである。これらの要因が将来どのように効いてくるかは不透明だ。

だから、ユーザの立場でいうと、特定のクラウド・ベンダーに過剰にコミットしてロックインされてしまうことは、未来の不確実性に対する備えとして、あまり合理的ではない。

自衛策としては、なるべく特定のインフラ固有の知識を要するものを避け、オープンな技術だけを使っておくのがよいだろう。

その点、Google App EngineもAmazon EC2も独特の「クセ」があり、クラウド・コンピューティングの2大本命であるにもかかわらず、すべてのユーザにとって最適な選択肢とはいえないだろう。いずれも、プロプライエタリな知識を多く要求し、ユーザが意識しなければならない独自の技術コンポーネントが多数あり、作りこめば作り込むほど、将来登場するかもしれない、より優れたクラウドに移行するポータビリティが失われていく性質がある。また価格性能比もすでに最高水準にはなく、ブランド・プレミアムが付与されているといってよい。具体的には、Amazon EC2を含めて複数のベンダー間でパフォーマンスを比較したこの記事が参考になるだろう。

Google App EngineやAmazon EC2のメリットとしてよく言われるプロビジョニングの容易さは、マルチコア化のトレンドによって1台のマシンでやれる範囲が増えるにつれ、どんどん価値を希釈化されていくだろう。AmazonやGoogleにコミットする判断は、データセンターからハードウェアまでを自前で所有するのに比べればはるかに合理的だが、数年後の競争環境の変化まで見据えるならば、これらの点をよく考えておく必要があると思う。

極論を承知でいえば、2010年現在、小規模なサービスをブートストラップするのに最適なプラットフォームは、VPSだと思う。オープンソースのOSの上に、オープンソースの言語とフレームワークを用い、オープンソースのデータベースを使う。これらを運用することで得られる経験と知識は、今後の10年でも簡単に陳腐化することはないと断言できる。

たとえばSlicehostなら現在、最上位メニューで15.5GBのメモリを使えるので、スケールアップによる拡張性もかなりの水準まで行ける。またスケールアウトに関しても、多くのVPSでは各インスタンスにプライベートIPが振られており、同じデータセンター内ならクラスタリングも可能としているところが多い。このように、クラウド業界ではVPSというプレイヤーがコスト意識に敏感なユーザ層の心をつかんで破壊的イノベーションへと化けていく、台風の目となる可能性を秘めているのではないかと思う。

次の10年もいろいろと楽しめそうだ。

Chris Cornell / Mission 2000

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー