Elasticsearchのメモリーの管理とトラブルシューティング

Elastic Cloudは、Observability、Security、Searchなどのソリューションを提供することで、Elastic Cloudを使用するユーザーを、フルオペレーションチームだけでなく、データエンジニア、セキュリティチーム、コンサルタントにまで広げました。Elasticのサポート担当者として、さまざまなユーザーやユースケースと関わることができ、大変光栄に思っております。

このようなお客様の多様化に伴い、リソース割り当ての管理、特に割り当て状況のトラブルシューティングやサーキットブレーカーの回避に関するご質問が以前より多く寄せられるようになりました。お気持ちはわかります。私もElasticsearchを使い始めたとき、同じ疑問を持っていました。それがきっかけで、初めてJavaヒープと時系列データベースシャードの管理や、自身のインフラの拡張に挑みました。

Elasticに参加したてのころは、ドキュメントだけでなくブログやチュートリアルも用意されており、すぐに馴染めたことに感激したものです。しかし、最初の1か月は、ユーザーのみなさまからチケットでお寄せいただくエラーと、自分の頭の中の知識をすり合わせることがなかなかできませんでした。やがて、他のサポート担当者と同じように、報告されるエラーの大部分は割り当ての問題を示す症状であること、そしてお問い合わせいただいたユーザーのみなさまに特定のリンクを7個ほどご案内すれば、リソース割り当ての問題はあっという間に解決することに気がつきました。

サポート担当者として、ユーザーのみなさまによくお送りしている割り当て管理の理論へのリンク、頻繁に見られる症状、およびリソース割り当ての問題を解決するために更新をお願いしている設定についてご紹介します。

2. docker-composeElasticsearch環境変数として

3. ［Elastic Cloud Hosted］ > ［Deployment］（デプロイ） > ［Edit view］（ビューを編集）の順に進む。注：ドロップダウンによって物理メモリが割り当てられる（その約半分がヒープ向け）。

クラスターのパフォーマンスに問題が発生している場合、たいていは以下が原因であると考えられます。

• 構成の問題：マスターノードのサイズが小さく、ILMポリシーがない
• 発生量：リクエストの頻度または負荷が高すぎる、負荷の大きいクエリまたは書き込みが重複している

または、_cluster/healthに結びつけます。

いずれかのシャードでactive_shardsまたはactive_primary_shards以外の値が0より大きい場合は、パフォーマンスの問題を引き起こす原因を特定したことになります。

この問題が報告される場合、通常はunassigned_shards>0となります。これらのシャードがプライマリの場合、クラスターはstatus:redと報告し、レプリカのみの場合は status:yellowと報告します。（これがインデックスにレプリカを設定すること が重要な理由です。クラスターが問題に遭遇した場合、データ損失ではなく回復が可能になります。）単一の割り当てられていないシャードでstatus:yellowになっていると仮定しましょう。調査するには、_cat/shards を介してどのインデックスシャードに問題が発生しているかを確認します。

これは、レプリカシャードが割り当てられていない非システムインデックスログ用です。_cluster/allocation/explainを実行して、何が問題を引き起こしているのかを確認してみましょう。（ヒント：サポートにエスカレーションする際、まさにこの手順を実行します。）

GET _cluster/allocation/explain?pretty&filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.*

このエラーメッセージはdata_hot（インデックスライフサイクル管理（ILM）ポリシーの一部）を指しており、当社のILMポリシーが現在のインデックス設定と一致しないことを示しています。この場合、このエラーの原因は、指定されたホット・ウォームノードを持たずにホット・ウォームILMポリシーを設定したことにあります。（何らかのエラーが確実に発生するようにしたかったため、これは皆さんにエラー例を強制的に提示するものです。詳細についてはこのトラブルシューティング例の動画をご覧ください。）

未割り当てシャードが存在しない場合にこのコマンドを実行すると、報告する問題が存在しないため、400エラーとともに［unable to find any unassigned shards to explain］（問題の原因となる未割り当てシャードを見つけられませんでした）と表示されます。論理的でない原因（たとえば、割り当て中にノードがクラスターを離れたなどの一時的なネットワークエラー）が発生した場合は、Elasticの便利な_cluster/rerouteを使用できます。

このカスタマイズなしのリクエストの起点となる非同期のバックグラウンドプロセスでは、現在のすべてのstate:UNASSIGNEDシャードの割り当てを試みます（私のように、プロセスがすぐ終わると思って完了を待つのは止めましょう。問題があると思って開発チームに連絡したときには、自然に問題は解決していました）。詳細は、こちらの割り当ての健全性の監視用トラブルシューティング動画をご覧ください。

原因を探るには、heap.percentを調べます。そのためには、_cat/nodesを確認します。

または、Kibanaの［Stack Monitoring］（スタック監視）を確認します（この機能が有効になっている場合）。

メモリーのサーキットブレーカーが発動していることを確認できた場合は、調査の時間を確保するために、ヒープを一時的に増やすことをお勧めします。根本原因を調査する際は、監査ログ、スローログ、クラスタログ、またはelasticsearch.logを調べて、直前の連続したイベントを確認してください。以下について確認します。

• 負荷の高いクエリ。特に以下のもの：
  • 高負荷のバケットアグリゲーション
    • 個人的な失敗談として、検索のサイズやバケットのディメンションに基づいてクエリを実行する前に検索で特定のヒープのポートを一時的に割り当てており、設定が10,000,000であったために運用チームにストレスをかけたことがありました。
  • 最適化されていないマッピング
    • 同じく失敗談として、フラット化したデータよりも階層構造のレポートの方が検索のパフォーマンスが良くなると考えていた時期がありました（実際にはそうではありません）。
• リクエストのボリューム/ペース：主にバッチクエリまたは非同期クエリ

または、_nodes/statsの結果から計算することもできます。

定義：

この場合の症状としては、elasticsearch.logでガーベージコレクター（gc）イベントの頻度と実行時間が増すことが挙げられます。

このような状況が認められた場合は、クラスターの拡張、またはクラスターに対する要求の削減を検討する必要があります。以下の対応を調査、検討することをお勧めします。

• ヒープリソース（ヒープまたはノード、ノード数）を増やす
• シャードを減らす（不要または古いデータを削除する、ILMを使用してデータをWarmまたはColdストレージに移し縮小する、喪失しても問題のないデータについてレプリカを無効にする）

2021年4月27日初稿公開、2024年11月5日更新。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。