分散KVSの「使いにくさ」にわれわれがいったん順応してしまうと何が起きるかは、グーグルの各種サービスの成功例や、同社が提供するクラウドサービス「Google App Engine(以下、App Engine)」の圧倒的なコストの低さ(無償)を見れば明らかです。App Engineで実際にアプリケーションを作ってみたい読者は下記連載を参考にしてください。App EngineからのBigtableの操作の仕方なども分かります。
■利点その【1】負荷分散や可用性に悩まないでいい!負荷分散や可用性に悩まないでいい!
まず、実用上は制限のないスケーラビリティのおかげで、「負荷分散や可用性のことで悩んだりコストを掛けたりする必要があまりなくなる」ということです。
■利点その【2】データを効率よく集約できる!データを効率よく集約できる!
そしてもう1つの、かつ最も重要な利点は、「アプリケーションの分散化対応によって、クラウドによる全体最適のメリットを享受できる」ことです。
分散KVSの「使いにくさ」を受け入れると、クラウド側ではアプリケーションのデータをクラウドのどこにでも自由に配置・移動・分割でき、多数のアプリケーションのデータを極めて効率よく集約(コンソリデーション)できるようになります。
App Engineのように1台のサーバで多数のアプリケーションを収容するクラウドサービスでは、個々のアプリが1つの仮想マシンやOS、DBインスタンスを占有して多大なサーバリソースを消費することがありません。このようなアプリケーションの分散化対応によってクラウドの全体最適が達成され、個々のアプリケーションの運用コストが飛躍的に下がります。
これは例えるなら、独立した仮想マシンやOS、DBインスタンスを占有していた「一戸建て」の環境を捨て、100人くらいで1つの部屋を共有する「タコ部屋」に入居するようなものです。このタコ部屋では、分散KVSという使いにくい収納しかありません。
その代わり、賃料が2けたくらい安いうえに、この収納には荷物をいくらでも詰め込めます。また部屋が満杯になったり火事で焼失しても、すぐ別の部屋に移動できます。
このように考えると、分散KVSとは実は「クラウドによる全体最適のメリットを享受するための分散化のプラクティス」であることが分かります。分散KVSを使用するには、RDBのACID特性やテーブル結合、洗練された検索・集計機能の利用をあきらめ、アプリケーション側でそれらの不足を補うさまざまな工夫や追加のコーディングが必要になります。
しかし、そうした「分散化に避けて通れないプラクティス」を受け入れることで、個々のアプリケーションが単体のサーバや仮想マシン、OS、DBインスタンスを占有する無駄がなくなり、クラウドという一体化した巨大インフラへの究極のコンソリデーションが実現します。
これにより、スケーラビリティや負荷分散、高可用性に関する課題がほぼ解消され、同時にかつてないほどの低コストでアプリケーションの運用が可能になります。グーグルの成功やCAP定理は、クラウドコンピューティングの本質がそうしたパラダイムシフトであることを示しています。
最後に、このパラダイムシフトにぴったり当てはまる“セリフ”を、アニメ「エヴァンゲリオン」から引用したいと思います。
「出来損ないの群体として行き詰まった人類を、完全な単体生物へ人工進化させる」(エヴァンゲリオンの人類補完計画)
これを、次のようにいい換えると、いま「クラウドコンピューティング」によって起きていることをいい表せます。
「出来損ないの群体として行き詰まったITシステムを、完全な単体インフラへ人工進化させる」(クラウドによるIT補完計画)
群体だったITシステムが単体であるクラウドへと融合し、究極の全体最適を実現するうえで、分散化に対応できないRDBは足かせとなります。分散KVSというグーグルが見つけた“指輪”の正体は、この「クラウドへの進化」そのものといえるでしょう。
以上、今回は分散KVSとは何かを紹介し、それが意味するところを考えてみました。次回は、いよいよ分散KVSの本命であるグーグルのBigtableの内部構造に切り込んでいきたいと思います。
吉川 和巳(よしかわ かずみ)
スティルハウス
Adobe AIR/Flex、Ruby on Rails、Google App Engine for Javaを主軸とする開発業務に従事しています。App EngineおよびデータストアBigtableに関してより深く学びたい方は、スティルハウスのHPにてセミナーの開催を随時告知していますので、ぜひご参加ください。
Copyright © ITmedia, Inc. All Rights Reserved.