[ElasticSearch] 事例読み解き / 複数のElasticsearchクラスタの運用で消耗しないために
hassaku63複数の ES クラスタがある場合に問題となることは、以下の要素を把握することが難しいことだと感じている
- クラスタごとの設定の差異
- プラグイン構成
- 負荷のかかり方
プラグインツールは ansible で構成管理しているが、ちょっとした検証などで新しいプラグインを入れてそのまま放置してしまう...といったことがありえる。
こうした問題があるので管理ツールが欲しくなる。
既存では以下のようなものがある
- Kibaba
- cerebro (OSS)
- ElasticHQ (OSS)
ElasticHQ を使えば1つのクラスタを深く見ることはできる。しかし、複数クラスタを一覧することには向かない。
また、ES そのものの状態をモニタリングして、異常があった場合にきちんとアラートしてくれる機能がほしい。
Kibana などの OSS ツールはとても良い、良いが、詳しいメトリックが欲しい場合にそのままでは使えない。そして、ES 自体が過負荷になってしまうとダッシュボード自体が閲覧できないことも問題となる
各種のツールを比較検討したマトリックスが以下 (5:27)
| Multiple culseter? | Monitoring? | Alerting? | |
|---|---|---|---|
| Kibana | prtial suport | prtial support | OK |
| ElasticHQ | OK | prtial support | x |
| What we need | OK | OK | OK |
ほしい物がなかったので、LINE では内製した ("RUBBER BAND" という名前のツールキット)。
メタデータは専用 DB から、現在の状態は ES の API を叩いて表示する。再発明はしたくなかったため、1つのクラスタの詳細を見たい場合は既存のツール (Kibana, Cerebro など) にリンクするようにした。
hassaku63ES のモニタリングを考えると、2つあると考える。この両方を活用している。
- server metric
- HTTP API でいろいろ取れる (
/_cat/***,/_cluster/health,/_nodes/***)
- HTTP API でいろいろ取れる (
- client metric
- サーバーが高負荷になってしまったとき、client のクエリが原因なのかどうかが見えるようになる
一般ユーザーは、この clinet を介してアクセスしている
これらのメトリックをどうやってアラートするか？X-Pack Watcher という（有償の）ものが使える。
ただし、アラートするために取得するメトリック自体はすでに↑↑の仕組みで収拾できているため、LINE では自分たちで "Health watcher" を呼ばれるアラート用のコンポーネントを開発し、Slack に通知できる仕組みを作った。
（OSS として公開することも計画しているらしいと言及があったが、現在どうなったのかは未調査）
hassaku63所感。
ここの発表の内容（内製）をそのまま模倣できる会社は限られる & 管理ツール周辺の事情も2021年現在と当時では異なるはずなので、
- マルチクラスタにおける管理の悩み
- 何をモニタリングしようとしたか
このあたりを持ち帰るものとして見ると良さそう