私のブックマーク
ブックマークを追加
ブックマークを削除スケールでの変換作業
変換は、既存のElasticsearchインデックスを要約されたインデックスに変換し、新しい洞察や分析の機会を提供します。変換によって実行される検索およびインデックス操作は、標準のElasticsearch機能を使用するため、スケールでElasticsearchを操作する際の考慮事項は、しばしば変換にも適用されます。パフォーマンスの問題が発生した場合は、ボトルネックの領域（検索、インデックス作成、処理、またはストレージ）を特定し、このガイドの関連する考慮事項を確認してパフォーマンスを改善してください。また、変換が連続モードで実行されているかバッチで実行されているかによって異なる考慮事項が適用されるため、変換の動作を理解することも役立ちます。
このガイドでは、以下のことを学びます：
- 変換のパフォーマンスに対する設定オプションの影響を理解する。
前提条件：
これらのガイドラインは、調整したい変換があり、以下にすでに精通していることを前提としています：
以下の考慮事項は順序に従っていません - 数字はリスト項目間のナビゲーションを助けます; どの順序でも1つまたは複数の項目に対してアクションを取ることができます。ほとんどの推奨事項は、連続変換とバッチ変換の両方に適用されます。リスト項目が特定の変換タイプにのみ適用される場合、この例外は説明に強調表示されます。
各推奨タイトルの末尾にある括弧内のキーワードは、与えられた推奨に従うことで改善される可能性のあるボトルネック領域を示しています。
変換のパフォーマンスを測定する
変換のパフォーマンスを最適化するためには、最も作業が行われている領域を特定することから始めます。Kibanaの変換ページのStatsインターフェースには、インデックス作成、検索、処理時間の3つの主要な領域に関する情報が含まれています（代わりに、変換統計APIを使用することもできます）。たとえば、結果が検索に最も多くの時間が費やされていることを示している場合は、変換の検索クエリの最適化に優先的に取り組んでください。また、変換にはRallyサポートがあり、必要に応じて変換設定のパフォーマンスチェックを実行することが可能です。重要な要素を最適化してもパフォーマンスの問題が続く場合は、ハードウェアの改善を検討することもできます。
1. 周期を最適化する（インデックス）
連続変換では、frequency設定オプションがソースインデックスの変更をチェックする間隔を設定します。変更が検出されると、ソースデータが検索され、変更が宛先インデックスに適用されます。使用ケースに応じて、変更が適用される頻度を減らすことを検討するかもしれません。frequencyをより高い値に設定することで（最大は1時間）、最新のデータのコストをかけて作業負荷を時間に分散させることができます。
2. 宛先インデックスのシャード数を増やす（インデックス）
宛先インデックスのサイズに応じて、シャード数を増やすことを検討できます。変換は、宛先インデックスを作成する際にデフォルトで1つのシャードを使用します。インデックス設定を上書きするには、変換を開始する前に宛先インデックスを作成します。シャード数がスケーラビリティと耐障害性に与える影響についての詳細は、本番環境の計画を参照してください。
変換のプレビューを使用して、変換が宛先インデックスを作成するために使用する設定を確認します。これらをコピーして調整し、変換を開始する前に宛先インデックスを作成します。
3. 検索クエリをプロファイルし最適化する（検索）
変換ソースインデックスqueryを定義している場合は、それができるだけ効率的であることを確認してください。KibanaのDev Toolsの下にあるSearch Profilerを使用して、検索リクエスト内の個々のコンポーネントの実行に関する詳細なタイミング情報を取得します。代わりに、プロファイルを使用することもできます。結果は、検索リクエストが低レベルでどのように実行されるかについての洞察を提供し、特定のリクエストが遅い理由を理解し、それらを改善するための手段を講じることができます。
変換は標準のElasticsearch検索リクエストを実行します。Elasticsearchクエリを書く方法はいくつかあり、その中には他よりも効率的なものがあります。検索速度の調整を参照して、Elasticsearchのパフォーマンス調整について詳しく学んでください。
4. ソースクエリの範囲を制限する（検索）
連続変換がIPでグループ化し、bytes_sentの合計を計算するように設定されていると想像してください。各チェックポイントで、連続変換は前のチェックポイント以降のソースデータの変更を検出し、新しいデータが取り込まれたIPを特定します。次に、このIPのグループにフィルタリングされた2回目の検索を実行し、合計bytes_sentを計算します。この2回目の検索が多くのシャードに一致する場合、リソースを多く消費する可能性があります。ソースインデックスパターンとクエリが一致する範囲を制限することを検討してください。
どの履歴インデックスにアクセスするかを制限するには、特定のティアを除外します（たとえば、"must_not": { "terms": { "_tier": [ "data_frozen", "data_cold" ] } }）および/またはソースクエリで絶対時間値を日付範囲フィルタとして使用します（たとえば、2024-01-01T00:00:00より大きい）。相対時間値を使用する場合（たとえば、gte now-30d/d）、日付の丸めが適用され、クエリキャッシュを活用し、相対時間がfrequencyまたはtime.sync.delayの最大値よりもはるかに大きいことを確認してください。そうでないと、データが失われる可能性があります。日付フィルタを使用しないでください。日付値よりも小さい（たとえば、lt: より小さいまたはlte: 以下）と、各チェックポイント実行時に適用されるロジックと矛盾し、データが失われる可能性があります。
インデックス名に日付数学を使用して、クエリで解決するインデックスの数を減らすことを検討してください。日付パターン（たとえば、yyyy-MM-dd）をインデックス名に追加し、特定の日付にクエリを制限するために使用します。以下の例は、昨日と今日のインデックスのみをクエリします。
Js
"source": {"index": ["<mydata-{now/d-1d{yyyy-MM-dd}}*>","<mydata-{now/d{yyyy-MM-dd}}*>"]},
5. ソースインデックスのシャーディング戦略を最適化する（検索）
すべての環境に適したシャーディング戦略はありません。ある環境で機能する戦略が、別の環境ではスケールしない場合があります。良いシャーディング戦略は、インフラストラクチャ、使用ケース、およびパフォーマンスの期待を考慮する必要があります。
シャードが少なすぎると、作業負荷を分散する利点が得られない可能性がありますが、シャードが多すぎるとクラスターの健康に影響を与える可能性があります。シャードのサイズについて詳しく学ぶには、このガイドをお読みください。
6. max_page_search_sizeを調整する（検索）
max_page_search_size変換設定オプションは、各検索リクエストに対して返されるバケットの数を定義します。デフォルト値は500です。この値を増やすと、レイテンシとメモリ使用量が増加する代わりに、スループットが向上します。
このパラメータの理想的な値は、使用ケースに大きく依存します。変換がメモリ集約型の集計（たとえば、カーディナリティやパーセンタイル）を実行する場合、max_page_search_sizeを増やすには、より多くの利用可能なメモリが必要です。メモリ制限を超えると、サーキットブレーカー例外が発生します。
7. ソースインデックスでインデックスフィールドを使用する（検索）
ランタイムフィールドおよびスクリプトフィールドはインデックスフィールドではありません; それらの値は検索時にのみ抽出または計算されます。これらのフィールドはデータへのアクセス方法に柔軟性を提供しますが、検索時のパフォーマンスコストを増加させます。ランタイムフィールドまたはスクリプトフィールドを使用した変換のパフォーマンスが懸念される場合は、代わりにインデックスフィールドを使用することを検討してください。パフォーマンス上の理由から、連続変換を同期する時間フィールドとしてランタイムフィールドを使用することは推奨しません。
8. インデックスソートを使用する（検索、処理）
インデックスソートを使用すると、特定の順序でディスクにドキュメントを保存でき、クエリの効率を向上させることができます。理想的なソートロジックは使用ケースによって異なりますが、一般的なルールは、時間ベースのフィールドから始めて、フィールドを降順（高から低のカーディナリティ）でソートすることです。インデックスソートはインデックス作成時にのみ定義できます。ソースとして使用したいインデックスにすでにインデックスソートがない場合は、新しいソートされたインデックスに再インデックス化することを検討してください。
9. 宛先インデックスで_sourceフィールドを無効にする（ストレージ）
_sourceフィールドには、インデックス時に渡された元のJSONドキュメントの本文が含まれています。_sourceフィールド自体はインデックスされていない（したがって検索可能ではない）ですが、インデックスに保存され、ストレージオーバーヘッドが発生します。大きな宛先インデックスがある場合は、ストレージスペースを節約するために_sourceを無効にすることを検討してください。_sourceを無効にすることはインデックス作成時のみ可能です。
_sourceフィールドが無効にされると、いくつかの機能がサポートされなくなります。無効にする前に、_sourceフィールドの無効化を参照して、その結果を理解してください。
