【MarkLogic Server】リバランスにおけるデータ転送量の観察

はじめに
========
MarkLogicに限ったことではありませんが、クラスタ内のホストは必ずしも同じ拠点にあるとは限らないため、
拠点間のネットワーク転送量がどのくらいか把握しておく必要があります。
今回はホスト間でリバランスを実施した場合のネットワーク転送量について確認してみました。

確認環境
========
MarkLogic環境はAWSでEC2インスタンスを作成し構築しました。

| 対象MarkLogicバージョン | 対象OS・バージョン | EC2インスタンスタイプ |CPUコア数|メモリ（GB）|
|---|---|---|---|---|
|8.0-6|Red Hat Enterprise Linux 7.3|m4.large|2|8|

確認方法
========
以下の方法でネットワーク転送量を確認しました。
１．2台構成のクラスタでフォレストをデータベースに1つアタッチします。
２．ファイルをMLCPでデータベースに投入します。
３．フォレストを1つアタッチしリバランスを開始します。
４．リバランス中のネットワーク転送量を確認します。

## 確認ファイル

確認したファイルは以下となります。
こちらのファイルはリバランス前に投入するファイルとなります。
ファイルサイズはロード前に確認しております。

|項目名|値|
|---|--:|
| 1ファイルあたりのXMLファイルサイズ | 200KB |
| ファイル件数 | 10,000件 |
| 全体のXMLファイルサイズ | 1,953MB |

## 事前準備

MarkLogicの構成が以下となるよう構築します。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/c8ea3cfb-029c-625d-f069-16544af99aa7.png)

・MarkLogicはホスト2台のクラスタ構成にします。
・各ホストにフォレストを１つずつ作成します。
・Forest01をDatabaseにアタッチします。Forest02はDatabaseにアタッチしません。

## XMLファイルの準備
MLCPでDatabaseにXMLファイルを投入します。
Forest01に全てのXMLファイルが格納されている状態となります。
Forest02はDatabaseにアタッチされていないのでXMLファイルは格納されておりません。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/aa43fb1c-b937-ab94-b76a-69fb4e3f0eae.png)

## 計測方法
・ネットワーク転送量を確認するため、Host1でiftopコマンドを利用できるようにします。
　※iftopコマンドは以下のコマンドで利用できるようになります。（参考：[https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-enable-epel/](https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-enable-epel/)）

```
# yum -y install wget
# wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-11.noarch.rpm
# rpm -ivh epel-release-7-11.noarch.rpm
# yum -y install --enablerepo=epel iftop
```

・データ転送先のフォレスト（Forest02）のサイズを1秒毎にduコマンドで確認できるようにします。

## 確認手順
以下の手順を実施し確認します。

１．Host1でiftopコマンド、Host2でduコマンドを実行します。また、コマンド実行と同時にForest02をDatabaseにアタッチします。
　　Forest02をアタッチすることで、自動でForest01からForest02にリバランスされます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/0abe9b74-a06f-91a3-57db-593a3e39204f.png)

２．Forest01からForest02へリバランスが完了するまで待機します。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/3a2a2240-f759-e883-9d6b-a940567e0592.png)

リバランス実行結果
========
10,000件のファイルが格納されているデータベースにフォレストを1つ追加した場合、リバランス開始から終了までのデータ転送量は以下の通りとなりました。

|項目名|値|
|---|--:|
|Host2のForest02に移動したファイル件数|4,989件|
|転送量|2,662.4MB|

![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/5669ece7-64a9-5095-0756-54db4b096716.png)

データ転送量は実際のファイルサイズよりも約2倍多いデータ量が転送されていることがわかりました。
また、Forest02のディスク使用量については以下の通りとなりました。

|項目名|値|
|---|--:|
|リバランス開始直後のディスク使用量|838.2MB|
|リバランス中の最大ディスク使用量|3,160.9MB|
|リバランス完了後のディスク使用量|2,015.1MB|

![image.png](https://qiita-image-store.s3.amazonaws.com/0/188643/5a27a0e5-0b4f-c688-e1a8-40a4cd6978f6.png)

グラフ中、一時的に増加している箇所がありますが、リバランス中は一時的にフォレストサイズが増加します。
通常、ディスク容量が逼迫しそうな時にディスクを増設しフォレストを追加することでディスク容量を確保します。
ただし、上記のグラフからわかるようにリバランス中は一時的にディスク容量が増加するため、ディスクの空き容量に余裕があるうちにフォレストを追加してリバランスさせましょう。

考察
========
リバランス時におけるネットワーク転送量を確認しました。
リバランス前のファイル全体のサイズが1,953MB、転送先のForest02に移動したファイルが4,989件のため、
200KB * 4,989件で約974MBがForest02に転送されることを想定しておりました。
しかし、実際の転送量は2,662.4MBと実ファイルサイズの約2.7倍転送されていることがわかりました。
そのため、クラスタを構成するネットワーク設計を行う場合は、実ファイルサイズの2～3倍の転送量を見込んだ方が良さそうです。

また、Forest02のディスク使用量がリバランス実施前後で2,015.1MB - 838.2MBで1176.9MBとなりました。
リバランス中にマージが発生していることから、単純に転送された実ファイルサイズ（約974MB）増加するとは限らないようです。

おわりに
========
リバランスは実ファイルサイズよりも多いデータ量が転送されることがわかりました。
そのため、拠点が異なるホスト間のリバランスを実施する場合は、ネットワークの帯域についても注意しましょう！

```math
\def\textsmall#1{%
  {\rm\scriptsize #1}
}
```

------------------------------------------------------------------------

**免責事項**

​​​​​$\textsmall{当ユーザ会は本文書及びその内容に関して、いかなる保証もするものではありません。}$
​​​​​$\textsmall{万一、本文書の内容に誤りがあった場合でも当ユーザ会は一切責任を負いかねます。}$
​​​​​$\textsmall{また、本文書に記載されている事項は予告なしに変更または削除されることがありますので、予めご了承ください。}$