OpenSearchCon North America 2024のセッション「Let your OpenSearch cluster monitor itself」を日本語でまとめます。 可能な限り正確に内容を拾えるようにリスニングに努めたつもりですが、もし誤りがあればご指摘ください。
OpenSearchCon とは？
イベントページ
各セッションはYouTubeで視聴可能
Let your OpenSearch cluster monitor itself
セッションリンクは以下.
スピーカー
- Sokratis Papadopoulos
- CERNで社内向けのOpenSearchを提供
- DevOpsエンジニア
.
CERNは素粒子物理学の研究を行う国際機関で、「宇宙は何でできているのか」「宇宙はどのように機能するのか」といった根本的な疑問に答えようとしている。そのために、世界最大の粒子加速器（27kmの環状加速器）を建設し、粒子を光速近くまで加速して衝突させる実験を行っている。
世界中から177,000人が協力し、科学技術の最前線を推し進め、人類の利益と好奇心に応えようとしている。
セッションまとめ
CERNが扱うデータ規模
CERNは毎秒1ペタバイトのデータを生成している。その中から有用なイベントをフィルタリングし、CERNのデータセンターに保存している。世界中の170センターで構成されるLHCコンピューティンググリッドの一部として、毎年約200ペタバイトのデータを分析・保存している。
CERNのOpenSearch
OpenSearchの用途
- ログ分析（実験データログ）
- 検索エンジン（ZenodoやInspireなど高エネルギー物理学コミュニティ向け）
- ITセキュリティ
- コンピューティンググリッドの監視
課題
クラスター数の増加に従って、不適切な使用パターンの検出が課題になった。
スピーカーはOpenSearchクラスタを払い出す役割であり、結果として理想的ではない使い方をされてしまうことがしばしばああった。
代表的なものとして、
- 大きすぎるシャード（0.5〜1TBのシャードは問題）
- データノードの容量超過（ユーザーが割り当て超過）
- 単一データノードに多すぎるシャード
これらの問題を監視し、即時に適切な担当者に通知する必要があった。
通知先のユーザーはそれぞれ独自の連絡ツールを使用しており、メールを好む人もいればSlackを好む人もいるなど多様である。そこで、AlertingとNotificationsプラグインを使ったシンプルなソリューションを構築し、すべてのクラスターが発生した問題を適切なチャンネルに通知できるようにした。
中央集権的な監視クラスタによるアプローチ
最初は中央集権的な１つの監視クラスターでこれを実現しようとした。Logstashを使用してすべてのクラスターにクエリを実行し、レスポンスを中央クラスターの異なるインデックスに保存し、その上にモニターを作成してレスポンスを分析し、各クラスター用の100の異なる通知チャンネル（各クラスターに1つ）のトリガーを作成して適切な人々に通知することを試みた。
しかし、各モニターは最大10のトリガーしか持てないという制限に直面した。また、スケーラビリティの観点でも課題があった。
非中央集権的な監視クラスタによるアプローチ
.
.
そこで、第二の試みとして分散型アプローチを採用した。
ブートストラップする各クラスターにはデフォルトのオブジェクトがいくつか付属しており、ユーザーの好みに基づいたデフォルトの通知チャンネルを見ることができる用になっている。Slack、メール、Webhook、サービスチケットなど。
加えて、いくつかのデフォルトのモニタリングオブジェクトが設定されており、一般的なOpenSearchの監視項目を分析し、閾値に達した場合に対応するチャンネルにアラートを送信する仕組みも備わっている。
.
このアプローチの長所と短所について。
長所は、単一障害点がなく、中央監視クラスターがダウンしてもアラートは各OpenSearchクラスターにローカルに存在するため、機能し続ける点が挙げられる。結果としてスケーラビリティが向上し、問題なく数千のクラスターまで拡張できる。
また、APIのレスポンスを保存する必要もないため、コストを節約できる。
加えて、OpenSearchにデフォルトで付属するネイティブのアラートと通知プラグインだけで実現可能で、追加のツールや依存性を必要としない。
短所としては、アラートテキストに誤字があった場合など、すべてのクラスター全体でこれらの監視オブジェクトを更新する必要がある。ただ、これは後で紹介するようなスクリプトを使えば比較的簡単に実現できる。
また、各クラスターがダウンした場合、これらのアラートは機能しないが、別途マシンレベル、OpenSearchプロセスレベルでの外部監視や、すべてのクラスターが実行されていることを確認するためのリモート監視機構も持っているため、それによってカバーできている。
クラスターブートストラップのスクリプト
.
すべてのクラスター設定はYAMLファイルにインストールされている。クラスター名、ユーザーが好む通知チャンネル、そしてクラスタごとの設定が管理されている。
プレースホルダー付きの12の監視テンプレートがあり、プレースホルダーにクラスター固有の値、例えばクラスター名などや、通知チャンネルなどを設定する。Pythonスクリプトでこれを読み込み、opensearch-pyライブラリを使用してクラスターのブートストラップ時にこれらのオブジェクトを簡単に作成できるようになっている。
.
モニター設定の例。簡単なクラスターヘルスチェックでは、簡単で便利な「per cluster metric」モニタータイプを使用する。
これらは基本的に定期的なAPI呼び出しを実行することを可能にする。このモニターはGET cluster/healthやGET node/statsを実行し、レスポンスに応じてそこにチャンネルへの送信を調整できるようになっている。
.
JSONの書き方のサンプル.
.
.
UIでの表示の例。対応するクラスターの通知チャンネルとモニターのリストが表示されている。これらはブートストラップする各OpenSearchクラスターに存在しており、各種APIとレスポンスを分析して、クラスタの健全性をチェックするのに使われる。
実際のアラートの例
.
実際のアラートの例を示す。これは単一のノードに過剰なシャードが配置されている場合の警告。
警告と合わせて、Slackの通知でユーザー向けにさまざまなガイダンスを提供できるようにしている。ドキュメントにリンクすることもでき、もちろん疑問がある場合はお問い合わせください、と誘導する。
- 「これらの数のシャードは多すぎるかもしれません。メモリのスペースを占有し、クラスターはこのようなパフォーマンスを達成する準備ができていません。これがあなたのデータノードで、これがデータノードあたりに保存するシャード数で、これがあなたに推奨する閾値です。それを超えるとパフォーマンスにペナルティがあるかもしれません」
- 「あなたが多すぎるデータを保持している場合、インデックスポリシーを確認したいかもしれません」
- 「小さすぎるシャードが多すぎる場合、この問題に取り組みたいかもしれません」
.
これは大きすぎるシャードに対する警告の例。私たちの場合、シャードが80GB以上になると少し苦労し始めるので、それに基づいたアラートがあり、シャードがそれを超えるとすぐに通知が送られ、インデックス名を示して「これは良くない、これを修正するために変更する必要があるインデックステンプレートです」と示すようにしている。
.
レプリカがゼロである場合の例。ユーザーがレプリカゼロでインデックスを作成すると、ハードウェア障害の場合にデータ損失のリスクがあり、私たちはそれを好まない。アラートでそれを説明し、「修正したい場合は、このコールを実行してレプリカの数を少なくとも1に設定してください。そしておそらくインデックステンプレートを確認したいかもしれません。デフォルトでレプリカをゼロに設定したくないでしょうから」と示している。
.
インデックスが作成されているのにドキュメントが入力されておらず、リソースを無駄にしている場合の例。シンプルに「これらは空のインデックスなので、このコマンドで削除してください。または必要と思われる場合は、リテンションが良くないかなど確認してください」と示す。
.
クラスターヘルスの警告例。クラスターが黄色で見つかった場合にアラートを送信でき、クラスターが赤のステータスで見つかった場合は別のアラートを送信し、正しいチャンネルに送られるようにしている。
まとめ
.
結果として、シンプルでスケーラブルな、良いソリューションを構築できたと考えている。
ただ、クラスターがダウンするとアラートも機能しないので、外部監視も重要であることは留意しなければならない。
ユーザーからはかなり肯定的な反応を受け取っている。ユーザーは情報量の多いアラートを受け取り、テキストを読むことでOpenSearchの仕組みをよりよく理解し、問題が大きくなる前に素早く修正するためのアクションを取れるようになっている。
そして、何か間違ったことをすれば、タイムリーなアラートが届き、「何か間違っていますよ、修正してください」と言ってくれると安心して運用できる。
私たちのメッセージは常に「最適な道を歩むか、アラートを受け取るかのどちらかです」である。
