クラウドに欠かせないのがスケーラビリティ、つまり大量の処理への対応です。そのためには、大量のマシンに処理を分散させる「スケールアウト」の方法が使われます。扱うデータの形式も、分散処理にふさわしい「キー・バリュー（key-value）」が主流です。前回で解説した「MapReduce」もkeyとvalue形式でデータを扱いますし、データベースにも「分散キー・バリュー型データストア」（以下単にkey-valueストアと呼ぶ）という技術が採用されるようになりつつあります。Googleの「BigTable」もそうです。
特にデータベースの世界では従来、MySQLなどのリレーショナルデータベース（RDB）が一般に用いられていました。しかしRDBは、データの一貫性などを重視するために分散処理がしにくいという欠点があります。そのためGoogleやAmazon.comだけでなく、SNSを手がける企業などが続々といわゆる「NoSQL」という、RDBとは異なる新しい種類のデータベースに移行しています。key-valueストアもNoSQLの一つという位置づけです。
NoSQLについては、プログラム言語「Ruby」の開発者であるまつもと ゆきひろ氏に第9回で解説してもらうとして、こでは「key-valueストア」について、その概要を説明します。そして次回以降で具体的なソフトを導入して、少しだけどういうものなのか体験してみます。
keyで担当サーバーを分ける
key-valueストアは、キーと値（value）の組でデータを保存し、キーを指定して値を取り出せるようにする手法のことです。プログラムの経験がある人ならなじみがあると思いますが、プログラムで扱うハッシュ（連想配列）と同じデータ形式です。
このように単にkeyとvalueでデータを扱うだけならクラウドと関係ありませんが、従来RDBに保存していた巨大なデータをkey-value形式で複数のサーバーに分散して保存することでスケーラアップが可能です。ただ、RDBが重視していたデータの一貫性などは不得意なので、扱うデータ量がよほど大きく性能が大事な状況でない限りは、RDBに比べてデメリットが多いかもしれません。
key-valueストアのデータの保存先は、メモリーだったりハードディスクなどのストレージだっりします。後述するようにキャッシュとしてメモリーに保存する「memcached」というkey-valueストアもあります（図1）。RDBのキャッシュとしてkey-valueに保存することもできますし、RDBの代わりにkey-valueストアを使うということもできます。
key-valueストアを使って多数のサーバーにデータを分散する際には、keyごとに担当サーバーを決めるというのが基本です。通常は同じkeyを複数のサーバーに担当させることで冗長性を確保しています。どちらかのサーバーが故障したときにもう一方のサーバーから値を取り出せます。このようにしてスケールアウトをさせるわけです。
ただ、keyの値とデータの格納先サーバーとのマッピング（どのkeyをどのサーバーが担当するかということ）を決める必要が出てきます。前述したmemcachedは、単に1台のサーバーで稼働するデーモンに過ぎないので、もし複数のサーバーにデータを分散格納したい場合はそれぞれのサーバーにmemcachedを導入し、どのサーバーがどのkeyを担当しているのかをクライアント（となるアプリケーションプログラム）側で判断しなければなりません。一般には、クライアント側で用いるライブラリがその仕事をしてくれます。
key-valueストアのソフトによっては、keyとサーバーとのマッピング機能をソフト側で持たせているものもあります。key-valueストアのソフトが多数のサーバーにkey-valueデータをうまく分散配置してくれるので、ユーザーが、keyとサーバーの対応を知らずに済みます。第7回で解説するkumofsやGREEで使われている「Flare」といったkey-valueストアソフトが、こうした機能を備えています。これらは、背後で多数のを使っていながら、クライアントに対しては自分があたかも単一のmemcachedであるかのように振舞います。
