Elasticsearch:スライスのキャッシュのウォームアップ

ウォーミングは、パフォーマンスを最適化するためのオプションの機能です。データをウォームアップしない場合、クエリはオンデマンドでデータをロードします。ウォーミングはクエリ結果を変更せず、データがキャッシュに常駐する期間を保証するものではありません。データのバッチがウォームアップされた後は、すべてのクエリの前に再度ウォームアップするのではなく、直接クエリを実行してください。

事前準備

• ターゲットの Collection と Slice が存在します。_warm_slice は、存在しない Slice を作成しません。

• ウォームするデータは、あらかじめ検索可能である必要があります。ウォーミングはリフレッシュをトリガーしません。ウォーミングを行う前に、自動バックグラウンドリフレッシュによってデータが検索可能になるまで待機し、ウォーミングのために _refresh を手動で呼び出さないでください。

注意事項

すべてのウォーミングリクエストには、以下の制限と動作が適用されます。

• リクエスト範囲 — 各リクエストは、明示的に 1 つの Collection と 1 つの Slice のみを指定できます。_all はウォーミングアップリクエストでは使用できませんが、クエリリクエストは _slice=_all をサポートします。

• 重複リクエスト：同じクエリシャードレプリカとスライスに対する同時ウォーミングリクエストはマージされます。重複したリクエストを送信する必要はありません。

• データの範囲：ウォーミングは、リクエストが開始された時点ですでに検索可能なデータのみを処理します。後で検索可能になった新しいデータは、このウォーミング結果には含まれません。

• リソースへの影響：ウォーミングは、オブジェクトストレージの読み取り帯域幅とクエリノードのリソースを消費します。本番環境では、デフォルトの非同期メソッドを使用し、アプリケーションがクエリを実行する前にスライスをウォームアップし、同時にウォームアップされるスライスの数を制限してください。

• キューが満杯の場合：ウォーミングキューが満杯になると、サーバーは新しいリクエストを拒否することがあります。クライアントは、すべてのスライスを同時に即時リトライするのではなく、有界バックオフ再試行戦略を使用する必要があります。

ウォーミングモードの選択

_warm_slice は、デフォルトでウォーミングタスクを非同期に送信します。また、同期的にウォーミング結果を待機することもできます。

リクエストパラメーター

_warm_slice は、以下のクエリパラメーターを受け付けます。

非同期ウォーミングの開始

デフォルトでは、ウォーミングタスクは非同期に送信されます。

POST /knowledge-chunks/_warm_slice?_slice=tenant-a

リクエストは HTTP 200 を返します。レスポンスボディには status が ACCEPTED に設定され、このウォーミングタスクの ID が含まれます:

{
  "status": "ACCEPTED",
  "message": "cache warm hint accepted",
  "task": "<nodeId>:<taskId>"
}

実行中のタスクをクエリするには、次の操作を使用します。

GET /_tasks/<nodeId>:<taskId>

デフォルトでは、タスク完了後にタスク結果は保持されません。

ACCEPTED は、タスクが送信されたことのみを示します。ターゲット Slice が存在すること、またはウォーミングが成功したことを示すものではありません。結果を確認するには、タスクを送信する際に store_result=true を設定し、その後 Tasks API を使用して以下の項目を順番に確認します。

1. completed=true: タスクが終了したことを示します。値が false の場合、しばらく待ってから再度タスクをクエリします。

2. トップレベルに error がない: タスクがエラーで終了しなかったことを示します。存在しない Slice や、現在ウォーミングをサポートしていないアクティブなブランチなどの条件は、タスクが送信された後にのみエラーとして報告される場合があります。代わりに、同期リクエストは、存在しない Slice に対して HTTP 404 を返します。

3. response._shards.failed=0: 失敗したシャードはありません。 response._shards.total=0 の場合、以下の 同期結果の評価 の説明に従って、追加のチェックを実行してください。

アプリケーションが実際にクエリするスライスのみをウォームアップしてください。ウォーミングのためだけにすべてのスライスを列挙しないでください。

ウォーミング完了の待機

ウォーミング統計を直接取得するには、同期的に待機できます。

POST /knowledge-chunks/_warm_slice?_slice=tenant-a&wait_for_completion=true&timeout=60s

同期モードでは、存在しない Slice に対して HTTP 404 が返されます。リクエストが成功した後、トップレベルの _shards.failed=0 であることを確認してください。_shards.total=0 の場合、この結果を使用してクエリノードの準備が完了したと判断することはできません。検索可能なデータが存在すると予想される場合は、まずクエリシャードが利用可能であることを確認し、実際のクエリでデータの可視性を検証してから、必要に応じてウォーミングをリトライしてください。この結果だけから、データがない Slice のウォーミングが失敗したと結論付けないでください。

同期応答には、次の統計フィールドが含まれます。

ranges_skipped が 0 より大きい場合でも、必ずしもウォームアップが失敗したことを示すわけではありません。ウォームアップ中にファイルがマージまたは削除されると、対応する範囲はスキップされます。

クエリとウォーミングのアフィニティ

各クエリノードのローカルキャッシュは独立しています。同じシャードの異なる検索可能なレプリカが異なるノードに存在する場合、それらはキャッシュデータを直接共有できません。そのため、デフォルトでクエリとウォーミングのアフィニティが有効になっています。シャードルーティングが安定している場合、ウォーミングと後続のクエリは優先的に同じ検索可能なレプリカにアクセスします。これにより、そのレプリカが存在するクエリノードのローカルキャッシュが再利用され、オブジェクトストレージからの繰り返しのデータ読み取りが削減され、複数のレプリカが同じデータをキャッシュするのを防ぎます。

たとえば、ユーザーがクエリを実行する前に、クエリ頻度の低いナレッジベースをウォームアップし、ウォーミングが完了した後にクエリを実行します。本番環境では、ユーザーのクエリがウォーミングを待つ必要がないように、事前にデータを非同期でウォームアップします。次の同期の例は、呼び出しシーケンスを示しています。

POST /knowledge-chunks/_warm_slice?_slice=tenant-a&wait_for_completion=true&timeout=60s

ウォーミング結果を確認した後、クエリを実行します。

GET /knowledge-chunks/_search?_slice=tenant-a

アフィニティは、どのレプリカに優先的にアクセスするかにのみ影響し、クエリ結果を変更しません。アフィニティは以下に適用されます。

• GET、MGet、および Explain

• Search、Count、Search Template、Search Shards、Async Search、および Multi Search のコレクションサブリクエスト

• 単一のスライス、複数のスライス、および _slice=_all のクエリ

• Update By Query および Delete By Query

• _warm_slice

アフィニティは、Reindex のソース側読み取りや Validate Query には適用されません。Copy Slice は Reindex を使用してソースデータを読み取るため、Copy Slice もウォームアップされたばかりのレプリカのキャッシュが再利用されることを保証できません。

アフィニティが有効な場合 (デフォルト)、preference を設定する必要はありません。 リクエストで渡された preference の値は、アフィニティルールによって上書きされます。 ビジネスニーズで preference を使用してノード選択をコントロールする必要がある場合、クラスター管理者はアフィニティを無効にする必要があります。 たとえば、_local はローカルノードに優先的にアクセスし、_only_nodes は指定されたノードにのみアクセスします。

この設定はすべてのコレクションに対して有効になり、単一のコレクションでは変更できません。アフィニティが無効になると、preference を含まないウォーミングリクエストがターゲットシャードのすべての検索可能なレプリカを対象とするため、オブジェクトストレージの読み取りとローカルキャッシュの使用量が増加する可能性があります。設定を変更する前に、この影響を確認してください。アフィニティを無効にするには、次のリクエストを送信します。

PUT /_cluster/settings
{
  "persistent": {
    "apack.slice_collection.query_warm_affinity.enabled": false
  }
}

この設定は動的に有効になり、Collection を再構築する必要はありません。アフィニティが無効になると、リクエストの preference 値が再び有効になります。クエリがこのパラメーターを渡さない場合、元のレプリカ選択メソッドが使用されます。

アフィニティが有効かどうかにかかわらず、レプリカが移行または利用不可になった場合、またはリクエストがリトライされた場合に、実際にアクセスされるレプリカが変更される可能性があります。アフィニティは、リクエストが永続的にノードにバインドされることを保証するものではありません。