Couchbase Server アーキテクチャ解説: クラスターマネージャー

# はじめに

本記事では、Couchbase Serverのクラスターマネージャー（Cluster Manager）について解説します。

Couchbase Serverの（分散システムとしての）アーキテクチャーを理解することは、Couchbase Server管理者にとって必要であるばかりでなく、分散データプラットフォームの検討において、適切なテクノロジーを選択する上でも重要です。

# クラスターマネージャー概説

Couchbase Serverのクラスターマネージャーは、クラスターを構成する全てのノード上に存在します。
他の分散アーキテクチャーで見られるマスター/スレーブ（マスター/ワーカー）構成のような、管理するノードと管理されるノードからなる構成とは異なっています。
（後に詳しく触れますが）全てのノードに存在するクラスターマネージャー（インスタンス）の中から、マスターサービスとしてのクラスターマネージャー（インスタンス）が選出されます。

# クラスターマネージャーを構成するプロセス

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176567/d86316b4-cd52-adbf-10f3-7745a2a81433.png)

クラスターマネージャーは次の2つのプロセスで構成されています。

- babysitter
- ns-server

## babysitter
babysitterは、CouchbaseServerの様々なプロセスの保守を担当します。
（保守の対象には、クラスターマネージャーのもう一つのプロセスであるns-serverを含みます。）

- プロセスを監視し、監視ログ出力をbabysitter.logに記録します。
- プロセスのいずれかが停止した場合、そのプロセスを起動します。

babysitterの位置づけとして特徴的なのは、babysitterは、クラスターの概念とは独立しており（クラスターの一部であることが意識される役割を持っているわけではなく）、純粋に、そのノードで稼働しているサービスの保守を行っているということです。

## ns-server

クラスターマネージャーの中心となるプロセスはns-serverであり、その構成は次のとおりです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/176567/c5ae4863-de31-16a2-ec2d-4d5effd44ba6.png)

### 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管理者の方だけでなく、分散データプラットフォームを検討されている方にも、活用いただけるようであれば幸いです。

一つの記事で、全体を敷衍することは不可能であるため、分からない用語などが登場しているかもしれませんが、その際には、下記の関連情報を参考としていただきますよう、お願いします。

# 関連情報

[NoSQL/JSONデータベースCouchbase理解・活用へのロードマップ](https://qiita.com/yoshiyuki_kono/items/4c9cd1115efc5807b49f)