Couchbaseの掟1として、永続化、レプリケーション、フェールオーバーおよびダイナミックなクラスタ再構成といった要素を追加しながら、既存のmemcachedサーバと簡単に置換できるようにする必要があります。既存のアプリケーションはmemcachedクラスタの連携に、大半(99.999%)が古いmemcachedクライアントを利用しているでしょう。このクライアントはおそらく、直接サーバにドキュメントIDをマッピングするために一貫したハッシュアルゴリズムを使用することになります。
この作業を行うには、プロキシ機能が必要です。長い目で見れば、直接vBucketの概念を実装することができるクライアントがあれば、プロキシの必要性はなくなるでしょう(いくつかの環境ではプロキシのニーズは存続するでしょうが)。我々はvBucket対応のクライアントがすぐに出てくることを期待していません。
Couchbase TCPポート
Couchbaseは2つの設定可能なポート上でデータ操作を受け付けます: 11210と11211(これらはcouchbaseのデフォルトのポート番号です)です。どちらのポートもmemcachedの ASCIIとバイナリプロトコルをサポートしていて、"memcapable"です。
11211番ポート(標準的なmemcachedのポート)は、組み込みプロキシがリスンするポートです。このサーバで所有していないvBucketで管理されているドキュメントIDに対するデータ操作を受付け、正常に処理することができます。プロキシは適切なサーバへリクエストを転送し、クライアントへ結果を返します。
11210番ポートはcouchbaseのデータ操作サーバがリスンするポートです。サーバで所有していないvBucketsが管理しているドキュメントIDに対するデータ操作を拒否します。全てのリクエストで、ドキュメントIDのハッシュ値を計算し、vBucketを特定する必要があります。そしてvBucketはこのサーバが所有するvBucketのリストと比較されます。
最初のデプロイ構成は、11211番ポートを利用し、Couchbaseに埋め込まれたプロキシと通信することです。この構成をサポートすることは我々にとって最優先です。これによりcouchbaseをインストールし既存アプリケーションからmemcachedクライアント使ってcouchbaseの利用を始めることができます、他のプロキシソフトウェアをインストールする必要はありません。このアプローチの欠点はパフォーマンスです。私たちは、レイテンシとスループットの劣化を最小限に抑えるために実用的なことをすべて行う必要があります。
このデプロイ構成(以下に詳細に示されている)とmemcachedを比較すると、最悪のシナリオでは、サーバマッピングが2回発生し、余計なネットワークのラウンドトリップが発生してしまいます。(例えばクライアント側でketamaを使ったハッシュからサーバのリストを取得し、プロキシではvBucketのハッシュを使ってサーバをマッピングする)
3つのサーバ(A、BおよびC)、memcachedのクライアントを利用した既存のアプリケーションがあると仮定します。Couchbaseは、これらの3つのサーバそれぞれにmemcachedの代わりにインストールされています。
上図のように、アプリケーションがGet(ID)
したいとき、クライアントライブラリ内の関数を呼び出します。クライアントライブラリはHash(ID)
を計算し、サーバリストとハッシュ関数に基づき、サーバCを特定します。そのGet操作はサーバCの11211番ポートへ送信されます。それがcouchbase(今はプロキシポート)に到達すると、そのキーはvBucketとサーバマッピングを特定するために再びハッシュ化されます。今回は、サーバAになります。プロキシはサーバAの11210番ポートへ接続し、get操作が処理され、その結果がクライアントへ返却されます。
2番目のオプションは、実質的に組み込みプロキシと同一の方法を実行しますが、ネットワークのホップを排除する可能性を持つスタンドアロンのプロキシを、配置することです。クライアント側に配置されたスタンドアロンプロキシはコネクションプールのようなサービスも提供できるます。次の図は、アプリケーションサーバーにインストールされているスタンドアロンのプロキシの流れを示しています。
memcachedクライアントはサーバリストに唯一のサーバしか設定していません(localhost
)、よって全ての操作はプロキシが待ち受けるlocalhost:11211
に転送されます。
プロキシはキーをvBucketにハッシュ化し、vBucketテーブル内のホストサーバを探します、そして適切なcouchbaseサーバ(この例ではサーバA)の11210番ポートに操作を送信します。
最後のケースでは、プロキシはデータフローに登場しません。クライアントをアップデートし、vBucketメカニズムによって直接サーバーの選択を実行します。さらに、これらのクライアントは拡張されたcouchbaseプロトコルを利用し、例えば明示的に送信先のvBucketをエンコードするなど、付加的な情報を送信することができます。このデータは、システムのパフォーマンスを最適化するために使用することができます。
詳細な説明については、vBucketsも参照してください。