NoSQL徹底研究の特集、第5回は「Couchbase Server」です。第1回でNoSQLを利用する企業が増えていると紹介しましたが、実際にはどのような企業がどのような理由でNoSQLを採用しているのでしょうか？ ユースケースを軸に今回のテーマであるCouchbaseとリレーショナルデータベース（RDBMS）の違いを紹介したいと思います。
昨夏にKDDIが法人顧客向けに「KDDI Business ID」というサービスを開始しました。実はこのサービスの裏側で使われているデータベースがCouchbase Serverです。
KDDI Business IDは携帯電話への着信とコード入力によって安全な認証をする着信認証やワンタイムパスワードを採用したサービスです。「Google Apps for Work」「Office 365 with KDDI」などの各種クラウドサービスを利用する企業のユーザー情報を一元管理することで、セキュリティとIDの一元管理を実現することに成功しました。“安心・安全な認証”がキーワードとなるこのサービスですが、本来この分野はRDBMSのほうが得意であると考えられる方も多いのではないでしょうか？
なぜKDDIが馴染みのある従来のRDBMSではなく、法人向けの“安全”が重要とされるサービスでNoSQLのCouchbase Serverを選択されたのでしょうか？
柔軟なデータモデル
まず、第一の前提として、このプロジェクトではアジャイル開発の導入が決まっており、「優先度の高いストーリーを実行可能なサービス」を段階的に実装、リリースするサイクルを目標としていました。迅速かつ開発のステップごとに発生する変化への対応に、スキーマが堅牢なRDBMSではなかなか実現が難しいというのは容易に想像ができます。
そこでNoSQLの中でもJSONやバイナリデータを自由に格納できる柔軟なデータモデルを持つCouchbase Serverが候補として上がりました。
ドキュメント型NoSQLデータベースであるCouchbase Serverは、キーバリューストア（KVS）の延長線上に位置し、KVSのバリューの部分にJSONドキュメントを格納します。JSONドキュメント内の項目による検索や複数のJSONドキュメント内の値を利用して集計を行うことができます。
アジャイルという新しい開発スタイルの選択から、RDBMSは初めから選択肢から外れてしまいましたが、これだけが理由で「認証サービス」という要件の高いプロジェクトでCouchbase Serverが採用されたわけではありません。
高性能かつエンタープライズレベルの信頼性
次に焦点となったのが性能です。多くのRDBMSで採用されている、マスタ、スレーブ形式のアーキテクチャではデータ参照の負荷を分散できますが、データ更新についてはマスタが一手に引き受ける必要があります。レプリカへの参照で一貫性を保つ必要がある場合、レプリカも即座に更新する必要があるため、さらに更新時の性能が犠牲になります。
Couchbase Serverはデータを自動シャーディングし、水平分散するアーキテクチャです。更新も参照も均等に各サーバに分散でき、高いスループットが求められるシステムで力を発揮します。また、同一のキーへのアクセスは同一のサーバに対して行い、単一のサーバで10万～20万の秒間リクエストを処理できるため、性能を向上するためにレプリカを参照する必要がありません。強い一貫性を持ちデータの読み書きが可能です。
Couchbase Serverの内部ではドキュメントごとにキャッシュを管理しています。アプリケーションから保存したドキュメントは、まずメモリ上のキャッシュ領域に保存されます。この時点でアプリケーションには保存完了の応答を返し、ディスクへの永続化およびレプリケーションは非同期に行います。ディスクのI/O性能に依存することなく、高いスループットでデータの格納が可能です。
図1：データキャッシュ層と永続化層を単一の製品で統合（筆者作成）
とはいえ、性能を高めるために、ディスクへの永続化を非同期で行うことに抵抗を示す企業ユーザーも少なくありません。KDDI Business IDでも、データ更新時にディスクまで書き込まれることを保証する必要がありました。Couchbase Serverでは、前述のデフォルト動作に加え、データ更新時にアプリケーション側でディスクへの永続化やレプリカの作成完了を待つように指定できます。
