素朴なBigtable、できること できないこと：分散Key-Valueストアの本命「Bigtable」（2）（1/2 ページ）

あまりにもRDBとは異質な「Bigtable」

　前回の「もう1つの、DBのかたち、分散Key-Valueストアとは」では、連載第1回目として、クラウドコンピューティングにおける新しい潮流である「リレーショナルデータベース（RDB）から分散Key-Valueストア（分散KVS）への移行」が、どのようなパラダイムシフトをもたらすのかを解説しました。今回からは、グーグルが運用する代表的な分散KVS「Bigtable」の内部構造を紹介し、クラウドの本質をより深く掘り下げます。

　前回も説明したとおり、Bigtableは、Google検索をはじめ、YouTubeやGoogleマップ、Google Earth、Google Analytics、Google App Engineなど、グーグルの70以上のプロジェクトの基盤として利用されています。合計で数Pbytes（ペタバイト）規模のデータを全世界に散らばる数十万台のサーバに格納した、「超」巨大な分散データストアです。

Google サービス一覧 via kwout

　Bigtableは、行と列からなる「テーブル」と呼ばれる構造を備えます。このテーブルは、簡単にいえば「Excelの表」のようなものです。個々の行は「キー」を用いて読み書きが可能です。さらに、テーブルのセルに当たる個々のデータは、履歴を残すことが可能です。

　例えば以下では、「com.cnn.www」というキーに基づいて、それに対応するコンテンツやリンク情報、さらにはそれらの履歴を保存しています。

図1　Bigtableのデータモデルの概念図（引用元：グーグル「Bigtable: A Distributed Storage System for Structured Data」）

Bigtable、3つの特長

　Bigtableは、以下の3つの特長を備えます。

1. 実用上、無制限のスケーラビリティ
2. サーバ冗長化による高可用性
3. 圧倒的なコストの低さ

【1】実用上、無制限のスケーラビリティ

　まずBigtableのテーブルには、実用上はスケーラビリティに上限がありません。テーブルの規模が100件でも、数千万件でも、個々の行の読み書きは数10ms（ミリ秒）程度で完了します。また、膨大な数のユーザーがBigtableに同時にアクセスしても、レスポンスの低下は発生しません。

　実際、グーグルの各種サービスを使う人なら「世界中のものすごい数のユーザーが同時にアクセスしているはずなのに、サーバが重くならないな」という疑問を持ったことがあるはずです。一般的なWebアプリケーションの大半では、RDBサーバがボトルネックとなってデータ量やアクセス件数の増加にともない、レスポンス時間が遅くなりますが、Bigtableを使ったWebアプリケーションでは、それが皆無です。

　この「まったく異なる次元のスケーラビリティ」こそ、「“Big”table」という名の由来となっています。

【2】サーバ冗長化による高可用性

　もう1つの特長は、可用性の高さです。Bigtableにデータを1件書き込むと、グーグル独自の分散ファイルシステム「Google File System（GFS）」を通じて、異なるラックに設置された3台以上のサーバにコピーされます。そのため、サーバ障害によってデータが失われる可能性は極めて低いうえに、いずれか1台のサーバが停止してもほかの2台のいずれかから同じデータを瞬時に取得できます。

クラウドで攻め通すグーグルの企業向け新戦略 ? ＠IT via kwout

　加えて、Bigtableのサービスを構成するサーバ群はすべてが冗長化されており、SPoF（Single Point of Failure）は排除されています。こうした冗長構成によって、Oracle RAC（Real Application Clusters）などのハイエンドのRDBクラスタに匹敵する高可用性を備えています。

多様化するクラスタ方式 via kwout

【3】圧倒的なコストの低さ

　Bigtableの3つめの特長は、圧倒的なコストの低さです。例えば、グーグルが提供するクラウド・サービスである「Google App Engine（以下、App Engine）」では、初期費用をまったく支払わずにBigtableを含むすべての機能を利用できます。これに対し、上述したようなハイエンドのRDBクラスタの構築には一般に数千万円規模のコストが掛かります。

　また利用開始後は、Bigtable上に保存したデータ量や消費したCPU時間に応じて従量課金となりますが、これは事実上「ほとんどタダ」で済みます。

　例えば、筆者が実際に担当した既存WebアプリケーションからApp Engineへの移行案件において、合計400万件程度（総容量11Gbytes）のデータをBigtable上に保存したところ、グーグルから請求された月額費用は4ドル程度でした（にわかには信じがたいと思いますので、以下のダッシュボード画面に表示されたコストをご確認ください）。

図2　Google App Engineの運用コストの例（ダッシュボード画面）

　つまり、よほど大量のデータやトラフィックを扱わない限り、大半のWebアプリケーションはほとんど無料で運用できます。

　次ページでは、Bigtableがケタ違いのスケーラビリティやコストパフォーマンスを実現できる理由や、Bigtableがどのようなシステム構成によって実装されているのかを見ていきます。