Elasticsearch:オープンソース Elasticsearch に関するよくある質問

概要

• インデックスのスレッドプールサイズの設定方法

• メモリ不足 (OOM) が発生した場合の対処法

• シャードの手動管理方法

• Elasticsearch のキャッシュクリアポリシー

• インデックスシャードの再ルーティング方法

• インデックスのクエリ時に "statusCode: 500" エラーが発生する場合の対処法

• auto_create_index パラメーターの値の変更方法

• OSS に保存するスナップショットの作成にかかる時間

• インデックス作成時のシャード数の決定方法

• セルフマネージド Elasticsearch クラスターからの elasticsearch-repository-oss プラグインを使用したデータ移行時のエラー対処法

• Kibana コンソールでのデータ可視化タイムゾーンの変更方法

• Elasticsearch の Term クエリが実行可能なデータ型

• Elasticsearch でのエイリアス使用時の注意事項

• クエリ中に too_many_buckets_exception エラーが返された場合の対処法

• 複数インデックスの一括削除方法

• script.painless.regex.enabled パラメーターの値の変更可否

• インデックスのマッピング、プライマリシャード数、レプリカシャード数の変更方法

• フィールド値の保存方法

• フィールドの集計可否の制御方法

• Elasticsearch 設定時の "Unknown char_filter type [stop] for **" エラーの対処法

• Elasticsearch Ingest パイプラインが default_pipeline か final_pipeline かの判断方法

• Elasticsearch のスクロールクエリによる大規模データ取得方法

• Kibana でのロール管理エントリの検索またはインデックスマッピングの変更方法

インデックスのスレッドプールサイズの設定方法

スレッドプールサイズを変更する前に、書き込みスレッドプールに負荷がかかっているかどうかを確認します。確認するには、次のコマンドを実行します。

GET /_cat/thread_pool?v=true&h=id,name,queue,active,rejected,completed

書き込みスレッドプールで、completed タスク数に対する rejected タスク数の比率が高い場合は、キューサイズを増やす必要があります。

スレッドプールサイズを設定するには、クラスターの YAML 設定ファイルで thread_pool.write.queue_size パラメーターを設定します。詳細については、「Configure the YML file」をご参照ください。

メモリ不足 (OOM) が発生した場合の対処法

次のコマンドを実行してキャッシュをクリアします。その後、原因を分析し、Elasticsearch クラスターの構成をアップグレードするか、業務側の調整を行います。

curl -u elastic:<password> -XPOST "localhost:9200/<index_name>/_cache/clear?pretty"

アップグレード手順については、「Upgrade the configuration of a cluster」をご参照ください。

シャードの手動管理方法

reroute API または Cerebro を使用します。reroute API の詳細については、「Cluster reroute API」をご参照ください。

Elasticsearch のキャッシュクリアポリシー

Elasticsearch は、次の3つのキャッシュクリア範囲をサポートしています。

• すべてのインデックスのキャッシュをクリア：

  curl localhost:9200/_cache/clear?pretty

• 特定のインデックスのキャッシュをクリア：

  curl localhost:9200/<index_name>/_cache/clear?pretty

• 複数のインデックスのキャッシュを一括でクリア：

  curl localhost:9200/<index_name1>,<index_name2>,<index_name3>/_cache/clear?pretty

インデックスシャードの再ルーティング方法

シャードが失われたり、誤って割り当てられたりした場合は、次のコマンドを実行して移動または再割り当てします。

curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
    "commands" : [ {
        "move" :
            {
              "index" : "test", "shard" : 0,
              "from_node" : "node1", "to_node" : "node2"
            }
        },
        {
          "allocate" : {
              "index" : "test", "shard" : 1, "node" : "node3"
          }
        }
    ]
}'

インデックスのクエリ時に "statusCode: 500" エラーが発生する場合の対処法

Cerebro などのサードパーティ製ツールを使用して、同じインデックスをクエリします。

• Cerebro でクエリが成功する場合、インデックス名が無効である可能性があります。インデックス名を変更してください。インデックス名には、英小文字、アンダースコア (_)、数字のみ使用できます。

• Cerebro でクエリが失敗する場合、問題はインデックスまたはクラスター自体にあると考えられます。クラスターに対象インデックスが存在するか、またクラスターが正常に稼働しているかを確認してください。

auto_create_index パラメーターの値の変更方法

次のコマンドを実行します。

PUT /_cluster/settings
{
    "persistent" : {
        "action": {
          "auto_create_index": "false"
        }
    }
}

OSS に保存するスナップショットの作成にかかる時間

シャード数、メモリ使用量、ディスク使用量、CPU 使用率がいずれも正常なレベルの場合、80 GB のインデックスデータのスナップショット作成には約 30 分かかります。

インデックス作成時のシャード数の決定方法

総データサイズを各シャードのデータサイズで割ることで、シャード数を算出できます。各シャードのデータサイズは 30 GB 以内に制限することを推奨します。各シャードのデータサイズが 50 GB を超えると、クエリパフォーマンスに重大な影響があります。

インデックス作成を高速化するために、シャード数を適切に増やすことができます。シャード数が少なくても多くても、クエリパフォーマンスに影響が出ます。

• シャード数が多すぎる：ファイルハンドル数とノード間通信のオーバーヘッドが増え、クエリが遅くなります。

• シャード数が少なすぎる：各シャードが保持するデータ量が増え、クエリが遅くなります。

セルフマネージド Elasticsearch クラスターからの elasticsearch-repository-oss プラグインを使用したデータ移行時のエラー対処法

エラーメッセージ：

ERROR: This plugin was built with an older plugin structure. Contact the plugin author to remove the intermediate "elasticsearch" directory within the plugin zip.

解決策：ZIP パッケージの名前を elasticsearch から elasticsearch-repository-oss に変更し、plugins ディレクトリにコピーします。

Kibana コンソールでのデータ可視化タイムゾーンの変更方法

Kibana コンソールでタイムゾーンを直接変更できます。次の例では、Elasticsearch 6.7.0 クラスターを使用します。

次の図は、選択したタイムゾーンを示しています。

Elasticsearch の Term クエリが実行可能なデータ型

Term クエリは単語レベルのクエリであり、数値、日付、keyword フィールドなどの構造化データに対して機能します。テキストをトークンに分割せず、転置インデックスを直接検索します。

text フィールドにはフルテキストクエリを使用してください。フルテキストクエリは、検索前に入力をトークン化します。

Elasticsearch でのエイリアス使用時の注意事項

同じエイリアスを共有するすべてのインデックスにまたがるシャードの総数は、1,024 未満である必要があります。

クエリ中に too_many_buckets_exception エラーが返された場合の対処法

エラーメッセージ：

"type": "too_many_buckets_exception", "reason": "Trying to create too many buckets. Must be less than or equal to: [10000] but was [10001]"

バケット集計の size パラメーターを小さくして、10,000 バケットの上限内に収めてください。詳細については、「Limit the number of buckets that can be created in an aggregation」をご参照ください。また、「Increasing max_buckets for specific visualizations」で説明されている方法に従うこともできます。

複数インデックスの一括削除方法

デフォルトでは、Elasticsearch はインデックスの一括削除を許可していません。有効にするには、次のコマンドを実行します。

PUT /_cluster/settings
{
  "persistent": {
     "action.destructive_requires_name": false
  }
}

この設定が反映された後、ワイルドカードを使用して複数のインデックスを一括で削除できます。

script.painless.regex.enabled パラメーターの値の変更可否

デフォルト値は false です。Painless スクリプトでの正規表現は大量のリソースを消費するため、スクリプトで正規表現のサポートが明確に必要な場合を除き、この設定は無効のままにしてください。

正規表現を有効にするには、elasticsearch.yml 設定ファイルで script.painless.regex.enabled を true に設定します。

インデックスのマッピング、プライマリシャード数、レプリカシャード数の変更方法

マッピング設定

既存インデックスのマッピングを変更するには、再インデックスが必要です。サポートされているフィールド型については、「Data field type」をご参照ください。

プライマリシャード

プライマリシャード数は、インデックス作成後に変更できません。現在の数が要件を満たさなくなった場合は、reindex API を使用して、適切なシャード数を持つ新しいインデックスにデータを移行します。

レプリカシャード

各プライマリシャードのレプリカシャード数を変更するには、次のコマンドを実行します。

PUT test/_settings
{
  "number_of_replicas": 0
}

フィールド値の保存方法

デフォルトでは、Elasticsearch は個々のフィールド値を保存しません。保存されるのは _source フィールドのみで、元の JSON ドキュメント全体が含まれます。これにより、クエリ時に任意のフィールドを取得できます。

特定フィールドの値を個別に保存するには、フィールドのマッピングで store: true を設定します。

PUT /my_index
{
  "mappings": {
    "properties": {
      "my_field": {
        "type": "text",
        "store": true
      }
    }
  }
}

フィールドの集計可否の制御方法

フィールドを集計できるかどうかは、データ型と、基盤となるフィールドデータ (doc_values または fielddata) が有効かどうかによって決まります。

デフォルトで集計可能なフィールド

数値、日付、keyword フィールドは doc_values による集計をサポートします。doc_values は、ソート、集計、スクリプト向けに最適化された列指向のストレージモデルです。

text フィールド (デフォルトでは集計不可)

text フィールドを集計するには、マッピングで fielddata を有効にします。

PUT /my_index
{
  "mappings": {
    "properties": {
      "my_text_field": {
        "type": "text",
        "fielddata": true
      }
    }
  }
}

フィールドの集計の無効化

フィールドが集計されないようにするには、次のいずれかの方法があります。

• マッピングでフィールドに対して enabled: false を設定します。

• ドキュメントからフィールド自体を除外します。

Elasticsearch 設定時の "Unknown char_filter type [stop] for **" エラーの対処法

stop タイプはトークンフィルターであり、文字フィルターではないため、char_filter セクションに配置するとこのエラーが発生します。

stop 設定を char_filter からアナライザーの filter セクションに移動してください:

"settings": {
  "analysis": {
    "analyzer": {
      "my_custom_analyzer": {
        "type": "custom",
        "tokenizer": "standard",
        "filter": [
          "lowercase",
          "stop"
        ]
      }
    },
    "filter": {
      "stop": {
        "type": "stop",
        "stopwords": "_english_"
      }
    }
  }
}

また、char_filter、tokenizer、および filter で指定しているすべてのコンポーネントタイプが、有効な Elasticsearch のフィルタータイプであることを確認してください。

Elasticsearch Ingest パイプラインが default_pipeline か final_pipeline かの判断方法

Elasticsearch は、Ingest パイプラインを設定するためのインデックスレベルの設定を2つ提供しています：index.default_pipeline と index.final_pipeline です。これらの設定は、処理ステージと上書き動作が異なります。

default_pipeline

index.default_pipeline 設定は、パイプラインを明示的に指定していないインデックス作成リクエストに適用される Ingest パイプラインを指定します。リクエストに ?pipeline= パラメーターが含まれている場合、リクエストで指定したパイプラインがデフォルトパイプラインより優先されます。

final_pipeline

index.final_pipeline 設定は、常に最後に実行される Ingest パイプラインを指定します。このパイプラインは、デフォルトパイプラインおよびリクエスト指定パイプラインの両方の後に適用されます。デフォルトパイプラインとは異なり、final パイプラインはリクエストレベルのパラメーターでは上書きできません。

現在のパイプライン設定の確認

特定のインデックスに設定されている Ingest パイプラインを確認するには、次のコマンドを実行します。

GET /<index_name>/_settings?filter_path=*.settings.index.default_pipeline,*.settings.index.final_pipeline

レスポンス例：

{
  "<index_name>": {
    "settings": {
      "index": {
        "default_pipeline": "my_default_pipeline",
        "final_pipeline": "my_final_pipeline"
      }
    }
  }
}

レスポンスに default_pipeline と final_pipeline のいずれも返されない場合、そのインデックスには Ingest パイプラインが設定されていません。

Elasticsearch のスクロールクエリによる大規模データ取得方法

スクロール API は、1回の検索リクエストから大量の結果を取得します。通常の検索とは異なり、スクロールはポイントインタイムのスナップショットを維持するため、一括データエクスポートやバッチ処理に適しています。スクロールコンテキストはクラスターリソースを消費し、低レイテンシのクエリに最適化されていないため、リアルタイムのユーザー向け検索リクエストには、スクロールを使用しないでください。

POST /<index_name>/_search?scroll=1m
{
  "size": 1000,
  "query": {
    "match_all": {}
  }
}

POST /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "<scroll_id_from_previous_response>"
}

DELETE /_search/scroll
{
  "scroll_id": "<scroll_id>"
}

Kibana でのロール管理エントリの検索またはインデックスマッピングの変更方法