はじめに
本記事では、Couchbase Serverのクラスターマネージャー（Cluster Manager）について解説します。
Couchbase Serverの（分散システムとしての）アーキテクチャーを理解することは、Couchbase Server管理者にとって必要であるばかりでなく、分散データプラットフォームの検討において、適切なテクノロジーを選択する上でも重要です。
クラスターマネージャー概説
Couchbase Serverのクラスターマネージャーは、クラスターを構成する全てのノード上に存在します。
他の分散アーキテクチャーで見られるマスター/スレーブ（マスター/ワーカー）構成のような、管理するノードと管理されるノードからなる構成とは異なっています。
（後に詳しく触れますが）全てのノードに存在するクラスターマネージャー（インスタンス）の中から、マスターサービスとしてのクラスターマネージャー（インスタンス）が選出されます。
クラスターマネージャーを構成するプロセス
クラスターマネージャーは次の2つのプロセスで構成されています。
- babysitter
- ns-server
babysitter
babysitterは、CouchbaseServerの様々なプロセスの保守を担当します。
（保守の対象には、クラスターマネージャーのもう一つのプロセスであるns-serverを含みます。）
- プロセスを監視し、監視ログ出力をbabysitter.logに記録します。
- プロセスのいずれかが停止した場合、そのプロセスを起動します。
babysitterの位置づけとして特徴的なのは、babysitterは、クラスターの概念とは独立しており（クラスターの一部であることが意識される役割を持っているわけではなく）、純粋に、そのノードで稼働しているサービスの保守を行っているということです。
ns-server
クラスターマネージャーの中心となるプロセスはns-serverであり、その構成は次のとおりです。
REST管理（UIおよびCLI）：
REST APIによる管理機能を提供します。これは、Couchbase Webコンソールによって提供されるユーザーインターフェイスとCouchbaseコマンドラインインターフェイスの両方の基礎になっています。
認証（Authentication）
ロールベースのアクセス制御でノードのリソースを保護します。各ロールはさまざまなシステム権限に関連付けられています。資格情報（ユーザー名とパスワード）に基づいて、ロールが割り当てられます。
マスターサービス
フェイルオーバー、リバランス、バケットの追加と削除など、クラスター全体に影響を与える運用を管理します。
常に、クラスター上のノードの1つだけがマスターサービスの役割を担当します。マスターサービスは、ノード間でのネゴシエーションの上、決定されます。選出されたノードが使用できなくなった場合は、別のノードが引き継ぎます。
REST APIを使用して現在、アクティブなマスターサービスノードを取得することができます。
マスターサービスは、オーケストレーターと呼ばれることもあります。
マスターサービスの役割を大別すると下記の二つがあります。
サービス管理
ノードの現在の状態を管理し、そのプロセスとサービスの監視と再起動を処理します。
バケット管理
バケットレベルの操作を管理します。レプリケーション、フェイルオーバー、再起動、および統計収集をサポートします。
分散処理機能一般
ノードの検出、構成変更に関するメッセージングとアラート、レプリケーション、ハートビートの送信をサポートします。
ローカル機能一般
ローカルに提供される機能（ライブラリ、ワークキュー、ロギング、クロック、ID、およびイベント）をサポートします。
マスターサービスの役割
クラスターメンバー管理
選出されたマスターサービスは、クラスターのメンバー構成に責任があります。クラスターのトポロジーが変更されると、既存のワークロードの処理を継続しながら、一連の操作が実行され、クラスターの再構成が行われます。
ノードの追加
- マスターサービスは、既存のクラスタ構成を持つ新しいノードを更新します。
- マスターサービスは、リバランスを開始し、vBucketマップを再計算します。
- データを受信するノードは、各vBucketの既存のノードからDCPレプリケーションストリームを開始し、それらのvBucketの新しいコピーの作成を開始します。これは、新しいvBucketマップレイアウトに応じて、アクティブvBucketとレプリカvBucketの両方で発生します。
- 増分—新しいvBucketにデータが入力されるたびに、データが複製され、インデックスが更新されます—古いvBucketから新しいvBucketへのアトミックスイッチオーバーが発生します。
- 新しいノード上の新しいvBucketがアクティブになると、マスターサービスは、新しいvBucketマップとクラスタートポロジがすべてのノードとクライアントに通知されるようにします。このプロセスは、リバランスが完了するまで繰り返されます。
ノードの削除
Dataサービスノードを削除するプロセスは、追加するプロセスと似ています。維持されるノードで新たにvBucketsが作成され、削除されるノードのvBucketsからデータが移動されます。削除対象ノードから、vBucketがなくなった後に、そのノードはクラスターから削除されます。
Dataサービスをホストしないノードを追加または削除する場合、データは移動されません。したがって、ノードはデータ移管なしでクラスターに追加またはクラスターから削除されます。
ノード障害の検出
Couchbase Serverクラスター内のノードは、ハートビートメカニズムによってステータスが管理されます。ハートビートは、全てのノード（のクラスターマネージャー）から定期的に提供されます。各ハートビートには、ノードの状態を評価するために使用されるノードの基本的な統計が含まれています。
マスターサービスは、他のすべてのノードから受信したハートビートを追跡します。自動フェイルオーバーが有効になっていて、デフォルトのタイムアウト期間より長くノードからハートビートが受信されない場合、マスターサービスはノードをフェイルオーバーの対象としてマークします（あるいは自動フェールオーバーを行います）。
vBucketの配布
Couchbase Serverバケットは、理的に1024個のマスターvBucketファイルと、レプリカvBucketファイル（設定に応じ、0個〜）からなります。マスターサービスは可用性とリバランスのパフォーマンスを最大化するために、これらのvBucketsの配置をコントロールします。vBucketマップは、クラスタートポロジーが変更されるたびに、次のルールによって再計算されます。
- マスターとレプリカのvBucketは別々のノードに配置されます。
- ２個以上のレプリカ構成の場合、レプリカvBucketはそれぞれ別々のノードに配置されます。
- マスターvBucketに対してサーバーグループが定義されている場合、レプリカvBucketは別のグループに配置されます。
管理、統計、およびロギング
クラスターマネージャーは、構成管理、統計収集、およびロギングサービスを一元化し、管理を簡素化します。すべての構成変更はマスターサービスによって管理され、マスターサービスノードから他のノードにプッシュされます。
最後に
本記事の内容が、Couchbase Server管理者の方だけでなく、分散データプラットフォームを検討されている方にも、活用いただけるようであれば幸いです。
一つの記事で、全体を敷衍することは不可能であるため、分からない用語などが登場しているかもしれませんが、その際には、下記の関連情報を参考としていただきますよう、お願いします。