[翻訳] コールドスタート検索問題の理解と解決

本記事は OpenSearch Project Blog に投稿された以下の記事を日本語に翻訳したものです。

https://opensearch.org/blog/cold-start-search/

OpenSearch へのアップグレードには多くのメリットがありますが、予期しない課題が発生することもあります。古い Elasticsearch バージョンからのアップグレードを支援する中で遭遇した問題の 1 つが「コールドスタート検索」問題です。一定期間操作がなかった後の最初の検索が異常に遅くなる一方で、その後の検索は期待通りのパフォーマンスを発揮するという現象に気づくかもしれません。本記事では、この動作の根本原因を探り、ニーズに合わせた解決策を提案します。

コールドスタート検索問題の理解

Elasticsearch 6.x から OpenSearch (または後の Elasticsearch バージョン) にアップグレードした後、次のようなパターンが見られることがあります。一定期間操作がなかった後の最初の検索は遅いのに、その後の検索ははるかに高速に実行されます。再び一定期間アイドル状態になると、遅い検索が再発します。この問題は、本番環境ほど検索アクティビティが一定ではない非本番環境で特に顕著です。以下の画像は、この動作を示す典型的な検索レートメトリクスです。

一見すると、これはキャッシュウォーミングの問題のように見えるかもしれません。しかし、このパターンはキャッシュを使用しないクエリでも発生します。シンプルなクエリも複雑なクエリも同様に影響を受け、スローログではこれらを遅いクエリとして識別しません。つまり、キャッシュやクエリの複雑さが問題の原因ではないということです。

根本原因の解明

検索スローログとクエリプロファイリングを使用した詳細な調査により、根本原因を OpenSearch の 2 つの主要な設定に特定しました。

• refresh_interval: OpenSearch は新しくインデックスされたドキュメントをメモリにバッファリングし、リフレッシュ操作によって検索可能なセグメントに転送します。デフォルトでは、refresh_interval はニアリアルタイム (NRT) 検索のために 1 秒に設定されています。ただし、シャードがアイドル状態になると (index.search.idle.after の期間で判定)、検索リクエストがリフレッシュをトリガーするまで自動リフレッシュが停止します。
• index.search.idle.after: この設定は、シャードが自動リフレッシュを停止するまでのアイドル時間を定義します。デフォルト値は 30 秒です。これによりリフレッシュ頻度が減少してバルクインデックスのパフォーマンスが向上しますが、一定期間操作がなかった後の最初の検索に遅延が発生します。

Elasticsearch 6.x から OpenSearch または Elasticsearch 7.x にアップグレードすると、この動作により、長いアイドル期間後の最初の検索がリフレッシュの完了を待ってから実行されることがあります。古い Elasticsearch バージョンでは index.search.idle.after が存在しなかったため、この動作は見られませんでした。遅延の深刻さは、リフレッシュが必要なデータ量に依存し、それはアイドル期間中にどれだけのインデックス作成が行われたかによって決まります。

コールドスタート検索の実践的な解決策

この問題に対処する最善の方法は、ワークロードによって異なります。以下に一般的なシナリオと推奨される解決策を示します。

• 予測可能な営業時間とアイドル期間がある場合
  検索アクティビティが特定の時間帯 (例: 通常の 9 時〜17 時の営業時間) に集中し、インデックス作成が営業時間外に行われる場合は、デフォルト設定のままで構いません。繁忙期が始まる前、または夜間のインデックス作成が完了した直後に手動リフレッシュを実行してください。
• 書き込み負荷の高いユースケース (例: オブザーバビリティやログ分析): 検索レイテンシがそれほど重要でないワークロードでは、refresh_interval を 30 秒または 60 秒に増やすことでインデックスパフォーマンスを向上できます。refresh_interval を明示的に設定することで、index.search.idle.after の干渉を回避できます。
• 散発的な書き込みを伴う読み取り負荷の高いユースケース: refresh_interval を 1 秒に設定することで、NRT 検索を確保し、アイドルシャードによる遅延を排除できます。
• バランスの取れたワークロード (検索レイテンシ、インデックス作成、NRT 結果が同等に重要な場合): デフォルト設定を維持してください。本番システムは通常、より一貫した検索アクティビティがあるため、非本番システムでの動作に基づいて判断しないでください。
• 予測可能だが頻度の低い検索: 検索パターンが予測可能な場合は、index.search.idle.after を 5 分または 10 分に増やすことを検討してください。これにより、アクティブな期間中の応答性に影響を与えることなく、リフレッシュのオーバーヘッドを削減できます。

まとめ

コールドスタート検索問題に対処するには、特定のワークロードと優先事項を理解する必要があります。refresh_interval を明示的に設定するか、index.search.idle.after を調整することで対処できますが、各解決策にはトレードオフがあります。ほとんどの本番システムでは、継続的な検索アクティビティがあるため、この問題は発生しにくいです。

環境でこれらの設定をテストして、ニーズに合った適切なバランスを見つけてください。リフレッシュ間隔の最適化に関するその他のヒントについては、OpenSearch リフレッシュ間隔の最適化に関する記事を参照してください。