Amazon OpenSearch Service のインデックス設定とマッピングを更新する方法

この記事は、 Patterns for updating Amazon OpenSearch Service index settings and mappings を翻訳したものです。

Amazon OpenSearch Service は、リアルタイムのアプリケーションモニタリング、ログ分析、大規模なウェブサイト検索など、幅広いユースケースで利用されています。ドメインが古くなり、コンシューマが追加されると、追加のストレージとコンピュートニーズを処理するためにドメインの構成を再評価し、変更する必要があります。このような変更を行う際には、ダウンタイムとパフォーマンスへの影響を最小限に抑えたいものです。

インデックスのメンテナンスを行うためのウィンドウを設けずにインデックス設定を変更したり、OpenSearch Service ドメインの全体的なパフォーマンスに影響を与えることなくインデックス設定を変更するためのベスト・プラクティスとパターンに関するガイダンスをお客様から求められます。これは 2 部構成の第 1 部で、データのプロデューサおよびコンシューマがアクティブなまま、ダウンタイムをほとんど発生させずに OpenSearch Service のインデックスに設定変更を行う方法を紹介します。

OpenSearch Service におけるインデックス

OpenSearch Service では、データを検索する前にインデックスを作成する必要があります。インデックスとは、検索エンジンが高速に検索できるようにデータを整理する方法です。こうしてできた構造をインデックスと呼びます。インデックスに対して行われるすべての操作は、インデックス APIs を介して行われます。また、各インデックスにはインデックスマッピングが含まれており、インデックス内のフィールド名とデータ型を定義している。データ作成者はインデックスに新しいフィールドとデータ型を追加することができます。インデックスのマッピングは、インデックスのライフサイクルを通して変更することはできません。

OpenSearch Service のインデックスには 2 種類の設定があり、ワークロードの状態が変化すると定期的に調整が必要になります:

動的 – インデックス上でいつでも変更可能な設定
静的 – インデックスの作成時にのみ定義でき、インデックスのライフサイクルを通じて変更できない設定

動的インデックスの設定は、設定更新 API を使用していつでも変更することができます。OpenSearch Service ドメインが動的インデックス設定に対して指示された操作を実行している間、インデックスはダウンタイムを必要としません。ほとんどの動的インデックス設定を変更しても、ドメインリソースの全体的な利用に影響を与えるバックグラウンドタスクは発生しません。しかし、index.number_of_replicas や index.auto_expand_replicas によるレプリカ数の増加など、ドメインの設定によっては、ドメインがレプリカを追加している間、一時的にリソースの使用率が増加することがあります。冗長性のために少なくとも1つのレプリカを維持し、高いクエリスループットを使用する場合は複数のレプリカを維持することを推奨します。

マッピングやシャード数などの静的インデックス設定は、インデックス作成時に定義され、インデックスのライフサイクルを通じて変更することはできません。この投稿では、シャード数の変更やインデックスマッピングの更新パターンなど、静的インデックス設定を扱うためのパターンとベストプラクティスに焦点を当てます。

この投稿で取り上げるすべての操作と手順は、OpenSearch REST API に直接、または OpenSearch Dashboards の Dev Tools を介して発行されます。

どのようなユースケースでもそうですが、考慮すべき解決策と制約のスペクトルがあります。私たちは、いくつかのシンプルな基本パターンから始めて、より多くの運用上の制約を持つユースケースや大規模なデータセットを扱うことを考慮しながら、それらを構築していきます。

ソリューション概要

OpenSearch Service のデフォルトのシャーディング戦略は 5:1 で、各インデックスは 5 つのプライマリシャードに分割されます。各インデックス内では、各プライマリシャードに対するレプリカも保持します。OpenSearch Service は自動的にプライマリシャードとレプリカシャードを別々のデータノードに割り当てます。

既存インデックスのプライマリシャード数を増やすことはできません。つまり、プライマリシャード数を増やしたい場合はインデックスを再作成する必要があります。

_reindex 操作は、シャードとマッピング設定を更新して目的とするインデックスを作成するのに適しています。_reindex 操作はリソースを消費します。number_of_replicas を 0 に設定してインデックスのレプリカを無効にし、再インデックス処理が完了したらレプリカを再度有効にすることをお勧めします。もし S3 など他のデータストアにデータがある場合、更新を一時停止し、ソースからインデックスを再作成するのが最もシンプルな方法です。しかし、それは常に可能というわけではありません。この投稿では、シャード数のような静的なインデックス設定も更新できるようにするいくつかの方法を紹介します。

_reindex 操作を使用する主な利点の1つは、ソースインデックスを読み取り専用モードにする必要がないことです。（データプロデューサは、再インデックス中もデータを書き込みを続けることができます）また、_reindex 操作は、部分的なドキュメントの再処理、変換、再インデックス、さらには複数のインデックスからのドキュメントの選択的な結合を可能にします。_reindex 操作では、クエリで選択したドキュメントのすべてまたは一部を別のインデックスにコピーすることができます。
最も基本的な形式では、_reindex 操作は、コピー元とコピー先のインデックス、および設定パラメータを指定する必要があります。

以下は、reindex API がサポートするユースケースの一部です:

すべてのドキュメントの再インデックス
クラスタ間でデータを転送する際にリモートクラスタからの再インデックス
検索クエリにマッチする一部のドキュメントの再インデックス
1つ以上のインデックスを結合
再インデックス作成中の文書の変換

シャード数を増やすには、新しいインデックスを作成し、number_of_shards を希望のプライマリシャード数に設定し、number_of_replicas を0に設定し、要件に基づいて新しいインデックス・マッピングを更新し、reindex API 操作を実行します。_reindex 操作が完了したら、作成したインデックスの設定の number_of_replicas を必要なレプリカシャード数に更新することをお勧めします。

下のセクションでは、reindex API 操作のウォークスルーを提供する。この投稿で紹介するパターンと手順は Amazon OpenSearch Service バージョン 1.3 で検証されていることに注意してください。

前提条件

_reindex 操作はソースドキュメントなしでは使用できないため、インデックス作成時に渡されたドキュメントがインデックスに格納されている必要があります。（マッピングの "_source" 設定が "enabled":true （デフォルト）に設定されている必要があります。）

目的のマッピング（フィールドやデータ型）で出力先インデックスを作成します。デモンストレーションのために、ソースインデックスには ratings という long として定義されたフィールドがあり、同じフィールドがディスティネーションインデックスでは float データ型を使用するようにします :

GET /source_index_name/mappings
{  
  "source_index_name": {
    "mappings" : {
      "properties" : {
        "ratings " : {
          "type" : "long"
        },
…
      }
    }
  }
}

PUT /destination_index_name
{
  "settings": {
    "index": {
      "number_of_shards": <DESIRED_NUMBER_OF_PRIMARY_SHARDS>,
      "number_of_replicas": 0
    }
  },
  "mappings": {
    "properties" : {
      "ratings" : {
          "type" : "float"
        },
…
    }
  }
}

各 Hot 層のデータノードに、新しいインデックスのプライマリシャードと、構成によってはレプリカシャードを格納するのに十分なディスク容量があることを確認します。ディスク容量が不足している場合は、OpenSearch Service ドメインで更新操作を行い、必要なストレージ容量を追加します。ストレージ要件によっては、OpenSearch Service ドメインを別のインスタンスタイプに移行する必要があるかもしれません。ノードには、各インスタンスタイプにマウントできる EBS ボリュームサイズに制約があるからです。次の操作を実行して、使用可能なディスク容量を確認します :

GET _cat/allocation?v

次のスクリーンショットは出力を示しています。

ホットストレージ層のノードの disk.avail メトリクスをチェックし、使用可能なディスク容量を確認します。

reindex API 操作の利用

_reindex オペレーションは、実行開始時にインデックスをスナップショットし、スナップショットに対して処理を実行することで、ソースインデックスへの影響を最小限に抑えます。ソースインデックスは引き続きデータの問い合わせや処理に使用できます。_reindex 処理は同期でも非同期でも実行できますが、非同期での実行を推奨します。_task 、_cancel 、_rethrottle 操作をそれぞれ使用することで、_reindex 操作の進捗を監視したり、実行をキャンセルしたり、実行を絞ったりすることができます。

_reindex 操作は、読み取り専用モードのソースインデックスを必要としないので、クエリとインデックス更新操作は自由に続けることができます。

以下のコマンドで reindex API を使用してください：

POST _reindex?wait_for_completion=false
{
  "source": {
    "index": "source_index_name"
  },
  "dest": {
    "index": "destination_index_name",
    "op_type" : "index"
  }
}

_reindex API 操作の一部であるソースインデックスは、ドキュメントの一部を再インデックスしてインデックス先に格納するためのクエリで補足することができます。インデックス再作成処理の進行状況は、tasks API 操作で確認することが監視することができます :

GET _tasks

_reindex 操作は、_rethrottle APIまたはパラメータとして渡される設定によってスロットルできます。また、_cancel 操作でタスクをキャンセルできます :

POST _tasks/TASK_ID/_cancel

次のスクリーンショットは、source_index_name から destination_index_name への再インデックスのための _reindex 操作の出力を示しています。
操作が完了すると、コンシューマとプロデューサが接続しているソースインデックス、もしくはエイリアスの向き先をディスティネーションインデックスに切り替える必要があり、最初の _reindex 操作が実行されている間にインデックス元で実行された作成、更新、または削除操作に追いつくために、同じ _reindex 操作を再度実行する必要があります。_reindex 操作はインデックスのスナップショット上で実行されているため、このステップが必要です。この時点で、欠落しているドキュメントやバージョン外のドキュメントを再調整ために、“op_type”:”create” で _reindex 操作を実行する必要があります。以下のAPIコマンドを参照してください :

POST _reindex?wait_for_completion=false
{
"conflicts":"proceed",
  "source": {
    "index": "source_index_name"
  },
  "dest": {
    "index": "destination_index_name",
    "op_type" : "create"
  }
}

操作が完了し、インデックス先のデータ整合性が確認されたら、ソースインデックスを削除してディスク領域を取り戻すことができます。

Split index APIを使用してインデックスシャード数を増やす

split index APIとshrink index APIは多くのユースケースをカバーし、ドメイン内のリソース使用率を低く抑えられます。しかし、これらのAPIは書き込み操作に対するインデックスを停止する必要があり、マッピング設定の変更を必要とするユースケースには対応していません。

OpenSearch Serviceでは、number_of_shards インデックス設定は変更不可であり、インデックス作成時に定義されます。しかし、この設定は変更不可ですが、明示的にインデックスを作成し直さなくても、インデックスのシャード数を増減できるパターンがいくつかあります。書き込み操作を中断できる環境では、split index API を使用してインデックスシャード数を増やすこともできます。split index API は、再インデックスをすることなく、異なるシャード設定で新しいインデックスを作成する簡便な方法を提供します。split index API は、読み込み専用インデックスをもとに新しいインデックスを作成します。

OpenSearch Service では、index alias は1つ以上のインデックスを指す仮想的なインデックス名です。アプリケーションでエイリアスを使用してインデックスを参照すると、インデックス名の変更を避けることができます。インデックスエイリアスは、インデックス API の分割操作が完了した後に、コンシューマやプロデューサに新しいインデックスを指し示すために使用されます。

ユースケースの大半は、データの増加により既存のインデックスのシャード数を増やすことですが、既存のインデックスのシャード数を減らす必要がある場合もあります。このようなケースは、実際のインデックスサイズがインデックス作成時に想定していたサイズよりも小さく、OpenSearch Service の運用上のベストプラクティスにおけるシャード戦略に合わせたい場合に発生することがあります。インデックスのシャード数を減らす必要がある場合、shrink index API を使用してこのタスクを達成することができます。

結論

この投稿では、OpenSearch Service の静的インデックス設定やマッピングを変更する際に、インデックスのダウンタイムをほとんど、あるいはまったく必要としないデータの再インデックスのベストプラクティスについて検討しました。また、インデックスを読み取り専用状態にすることができるユースケースのために、プライマリインデックスのシャード数を変更するための split index および shrink index API の使用についても説明しました。

次回の投稿では、OpenSearch Service ドメインに対する負荷とリソースの使用を軽減するリモートインデックスのパターンを探ります。

翻訳は Solutions Architect 川岸が担当しました。

Amazon Web Services ブログ