Amazon OpenSearch Service クラスターでインデックス作成のパフォーマンスを向上させるにはどうすればよいですか?

所要時間2分

Amazon OpenSearch Service のインデックス作成オペレーションを最適化し、取り込みスループットを最大化したいと考えています。どうすればよいですか?

解決方法

シャードが取り込み対象であるインデックスのデータノード間で均等に分散されていることを確認します

次の式を用いて、シャードが均等に分散されていることを確認します。

インデックスのシャード数 = k * (データノードの数) 。このとき、k はノードごとのシャード数を表します

例えば、インデックスに 24 個のシャードと 8 個のデータノードがある場合、OpenSearch Service は各ノードに 3 個のシャードを割り当てます。詳細については、Get started with Amazon OpenSearch Service: How many shards do I need? を参照してください。

refresh_interval を 60 秒以上に増やす

OpenSearch Service インデックスを更新して、ドキュメントを検索できるようにします。インデックスを更新するには、インデックス作成スレッドで使用されているのと同じリソースが必要です。

デフォルトの更新間隔は 1 秒に設定されています。更新間隔を長くすることで、データノードによる API コールの実行回数を少なくできます。更新間隔の長さによっては、更新間隔をより短く、または、より速くできます。429 エラーを防ぐには、更新間隔を長くすることがベストプラクティスです。

注: デフォルトの更新間隔は、過去 30 秒間に複数の検索リクエストを受信したインデックスの場合、1 秒です。更新されたデフォルトの間隔の詳細については、Elasticsearch ウェブサイトの _refresh API version 7.x を参照してください。

レプリカ数をゼロに変更する

負荷の高いインデックス作成が予想される場合は、index.number_of_replicas の値を「0」に設定することを検討してください。各レプリカはインデックス作成プロセスを複製します。その結果、レプリカを無効にすると、クラスターのパフォーマンスが向上します。負荷の高いインデックス作成が完了したら、レプリケートされたインデックスを再度アクティブ化します。

重要: レプリカが無効状態のときにノードが失敗すると、データが失われる可能性があります。短期間のデータ損失を許容できる場合にのみ、レプリカを無効にします。

最適な一括リクエストサイズを見つけるために試行する

5 MiB～15 MiB の一括リクエストサイズから開始します。その後、インデックス作成のパフォーマンスに改善が見られなくなるまで、徐々にリクエストサイズを増やしていきます。詳細については、Elasticsearch ウェブサイトの Using and sizing bulk requests をご参照ください。

注: 一部のインスタンスタイプでは、一括リクエストに 10 MiB の制限があります。詳細については、ネットワークの制限を参照してください。

SSD インスタンスストアボリュームがあるインスタンスタイプを使用する (I3 など)

I3 インスタンスは、ローカルで高速な Memory Express (NVMe) ストレージを提供します。I3 インスタンスでは、汎用 SSD (gp2) Amazon Elastic Block Store (Amazon EBS) ボリュームを使用するインスタンスと比較して、より優れた取り込みパフォーマンスを実現しています。詳細については、「Amazon OpenSearch Service 用ペタバイトスケール」を参照してください。

レスポンスサイズを縮小する

OpenSearch Service のレスポンスのサイズを小さくするには、filter_path パラメータを使用して不要なフィールドを除外します。失敗したリクエストの特定または再試行を行う際に必要となるフィールドを除外しないように注意してください。これらのフィールドは、クライアントごとに異なる場合があります。

次の例では、index-name、type-name、および took のフィールドがレスポンスから除外されています。

curl -XPOST "es-endpoint/index-name/type-name/_bulk?pretty&filter_path=-took,-items.index._index,-items.index._type" -H 'Content-Type: application/json' -d'
{ "index" : { "_index" : "test2", "_id" : "1" } }
{ "user" : "testuser" }
{ "update" : {"_id" : "1", "_index" : "test2"} }
{ "doc" : {"user" : "example"} }

詳細については、「レスポンスサイズの削減」を参照してください。

index.translog.flush_threshold_size の値を大きくする

デフォルトでは、 index.translog.flush_threshold_size は 512 MB に設定されています。つまり、トランスログは、512 MB に達するとフラッシュされることを意味します。インデックス作成ロードの重みによって、トランスログの頻度が決まります。index.translog.flush_threshold_size の値を増やすことで、トランスログオペレーションをノードが実行する頻度を低くできます。OpenSearch Service フラッシュはリソースを大量に使用するオペレーションであるため、トランスログの頻度を減らすと、インデックス作成のパフォーマンスが向上します。フラッシュしきい値サイズを増やすことで、OpenSearch Service クラスターは (複数の小さいセグメントではなく) より少ない数の大きなセグメントを作成します。大きなセグメントはマージされる頻度が低く、マージの代わりにインデックス作成により多くのスレッドが使用されます。

注: index.translog.flush_threshold_size が大きくなると、トランスログが完了するまでにかかる時間も長くなる可能性があります。シャードに障害が発生すると、トランスログが大きくなるため、リカバリに時間がかかります。

index.translog.flush_threshold_size の値を大きくする前に、次の API オペレーションを呼び出して、最新のフラッシュオペレーションの統計を取得します。

curl -XPOST "os-endpoint/index-name/_stats/flush?pretty"

os-endpoint と index-name をそれぞれの変数に置き換えます。

出力に表示されるフラッシュの数と合計時間を記録しておきます。次の出力例は、124 個のフラッシュがあり、これには 17,690 ミリ秒かかったことを示しています。

{
     "flush": {
          "total": 124,
          "total_time_in_millis": 17690
     }
}

フラッシュのしきい値サイズを大きくするには、次の API オペレーションを呼び出します。

$ curl -XPUT "os-endpoint/index-name/_settings?pretty" -d "{"index":{"translog.flush_threshold_size" : "1024MB"}}"

この例でのフラッシュのしきい値サイズは、メモリが 32 GB を超えるインスタンスに最適な 1024 MB に設定されています。

注: OpenSearch Service ドメインに適したしきい値サイズを選択してください。

_stats API オペレーションを再度実行して、フラッシュアクティビティが変更されたかどうかを確認します。

$ curl _XGET "os-endpoint/index-name/_stats/flush?pretty"

注意: ベストプラクティスとして、始めは稼働中のインデックスについてのみ index.translog.flush_threshold_size を増やします。結果を確認したら、インデックステンプレートに変更を適用します。