JitsiMeetインストールしたオンプレサーバをPrometheusでリソースモニタしてみる

# はじめに
## 対象読者
* [Jitsi Meet](https://meet.jit.si/) をオンプレ環境に構築してみたけれど、スペックの設定に悩んでいる人
* また、構築してみたいけれど、どれくらいリソース消費されるのか気になる人


## 前提
### Jitsi Meet サーバ構築時の記事
* [JitsiMeetをUbuntu20.04にインストール～動作検証までしてみる](https://qiita.com/Hi_Noguchi/items/4f29c68cf2d446489dc6)

### Jitsi Meet サーバのスペック
* ConoHa VPS
    * OS Ubuntu 20.04
    * CPU 3 Core
    * メモリ 2 GB
    * SSD 100 GB

### Jitsi Meet の設定
* 特に映像や音声のコンフィグは弄っておらず、デフォルトのままの状態

### クライアント側の動作について
* いずれの条件においても、クライアント側の動作に何らか支障が生じていたことは無かった
    * クライアント端末のメモリ不足等、クライアント由来による問題は除く

### 同時に立てる部屋の数
* 1 つのみ
* 同時複数部屋というのはやってみていません


# Prometheus の設定
## モニタする Prometheus サーバの用意
* 別途記事を書きましたので、以下を参考に用意してください
    * [Ubuntu20.04でPrometheusを用いてリソースモニタリング（環境構築編）](https://qiita.com/Hi_Noguchi/items/95e7d2b9a3f2857e9ff9)

## モニタされる側 ( Jitsi Meet サーバ ) の用意
* 以下記事で用意した Jitsi Meet サーバに、上記記事内で案内しているように node_exporter を導入してください
    * [JitsiMeetをUbuntu20.04にインストール～動作検証までしてみる](https://qiita.com/Hi_Noguchi/items/4f29c68cf2d446489dc6)



# モニタ結果
## モニタ項目とクエリの凡例
### メモリ使用量
```prometheus
node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes
```

### CPU ロードアベレージ
```prometheus
node_load1 / count(count(node_cpu_seconds_total) without (mode)) without (cpu)
```

### ネットワーク受信量
```prometheus
rate(node_network_receive_bytes_total[1m])
```

### ネットワーク送信量
```prometheus
rate(node_network_transmit_bytes_total[1m])
```


## 5 名 → 途中から疑似的に 9 名
### 条件
* 全員 PC
* 全員ビデオ ON
* 全員画質 HD
* 再生時間 1 時間 30 分 ほど

### 実用性
* 十分に堪えうる

### メモリ使用量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/6909319d-32fa-08aa-0523-06f79ff59758.png)

### CPU ロードアベレージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/e4d6c9a4-db24-4282-fcf5-3e898b4f6ef0.png)

### ネットワーク受信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/785d8280-7b85-e841-1bf2-86c8c88eea3b.png)

### ネットワーク送信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/ae06011f-04b2-f0cb-200f-487956b62a74.png)


## 11 名
### 条件
* 10 名 PC / 1 名 モバイル
* 8 ～ 10 名ビデオ ON / 1 ～ 3 名ビデオ OFF ( 途中で変動 )
* 全員画質 HD

### 実用性
* 十分に堪えうる

### メモリ使用量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/367daf90-6b34-5f5a-1b43-3a9cafd6bba0.png)

### CPU ロードアベレージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/d88a8b4b-acb2-b77e-456e-f66b859c1b69.png)

### ネットワーク受信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/30e39349-a3f7-d60c-189a-6032f01d90e2.png)

### ネットワーク送信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/31e24c33-9f60-61d1-4e45-7a2026cdb765.png)


## 30 名超
### 条件
* 30 名超 PC
* 4 ～ 5 名ビデオ ON / 他全員ビデオ OFF ( 途中で変動 )
* 全員画質 SD

### 実用性
* なし。ほとんどサーバダウンに近い状態になる

### メモリ使用量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/a2b20940-e340-153f-0c5f-66a752d7b4bb.png)

### CPU ロードアベレージ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/ca44fdf1-23b5-51db-1c0a-251e095c3f9b.png)

### ネットワーク受信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/d91dcf57-af15-00c5-0b09-328392ca9d0f.png)

### ネットワーク送信量
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/37739/43cfeef4-3aa7-9a64-85a8-aee7879ba222.png)


# おわりに
## まとめと感想
### メモリ
* メモリは人数が増えても大して使われなかった

### CPU
* 参加者 5 名のときはロードアベレージ 0.3 程度だったのが、参加者 11 名になると最大 0.6 くらいにまでなるので、人数比で結構 CPU 使用が激しくなる
* ましてや参加者 30 名超となると実用性ゼロになるので 20 名超くらいからスペックアップを考えた方が良さそう
* コストに制約があり CPU とメモリどちらを潤沢に積むべきかといえば CPU の方を優先したら良さそう

### ネットワーク
* 受信量より送信量の方が大きい
* 人数が増えれば増えるほど、受信量よりも送信量の多さが増していく

### その他
* 同時に複数の部屋数を立てたらどうなるのか？　というのも気にはなる


## 関連記事
* [JitsiMeetをUbuntu20.04にインストール～動作検証までしてみる](https://qiita.com/Hi_Noguchi/items/4f29c68cf2d446489dc6)
* [JitsiMeetをUbuntu20.04から完全削除する](https://qiita.com/Hi_Noguchi/items/686744f5190e1715e198)
* [JitsiMeetをセキュアに利用するためホスト／ゲストの認証設定](https://qiita.com/Hi_Noguchi/items/3f535e72e1a9fc1d1696)
* 音質検証について書く予定