Elasticsearch の異なるバージョン間およびクラスター間でデータを移行する方法

Elasticsearchは初めてですか？Elasticsearchを使い始めるウェビナーに参加しましょう。無料のクラウドトライアルを始めるか、今すぐマシンでElasticを試すこともできます。

Elasticsearch クラスターをアップグレードする場合、新しい別のクラスターを作成し、古いクラスターから新しいクラスターにデータを転送する方が簡単な場合があります。これにより、ユーザーは、ダウンタイムやデータ損失のリスクなしに、すべてのアプリケーションを使用して新しいクラスター上のすべてのデータと構成をテストできるという利点が得られます。

このアプローチの欠点は、ハードウェアの重複が必要となり、すべてのデータをスムーズに転送および同期する際に困難が生じる可能性があることです。

アプリケーションをあるデータ センターから別のデータ センターに移行する必要がある場合にも、同様の手順を実行する必要がある場合があります。

この記事では、Elasticsearch クラスター間でデータを転送する 3 つの方法について詳しく説明します。

Elasticsearch クラスター間でデータを移行するにはどうすればよいですか?

Elasticsearch クラスター間でデータを転送する方法は 3 つあります。

1. リモートクラスタからの再インデックス
2. スナップショットを使用したデータ転送
3. Logstash を使用したデータ転送

通常、スナップショットを使用するのが、データを転送する最も高速かつ信頼性の高い方法です。ただし、スナップショットは同等以上のバージョンのクラスターにのみ復元でき、メジャー バージョンが 1 つ以上異なるクラスターには復元できないことに注意してください。つまり、6.x スナップショットを 7.x クラスターに復元することはできますが、8.x クラスターには復元できません。

メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。

ここで、Elasticsearch クラスター間でデータを転送するための 3 つのオプションをそれぞれ詳しく見ていきましょう。

1. リモートクラスタからのデータの再インデックス

再インデックスを開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、適切なマッピングを使用してインデックスを直接作成するか、インデックス テンプレートを使用する必要があります。

リモートからの再インデックス - 設定が必要

リモートから再インデックスを行うには、データを受信しているクラスターの elasticseearch.yml ファイルに以下の構成を追加する必要があります。Linux システムでは、このファイルは、通常、/etc/elasticsearch/elasticsearch.yml にあります。追加する構成は次のとおりです。

SSL を使用している場合は、各ノードに CA 証明書を追加し、elasticsearch.yml 内の各ノードのコマンドに以下を含める必要があります。

あるいは、SSL 検証を無効にするために、すべての Elasticsearch ノードに以下の行を追加することもできます。ただし、このアプローチは前のオプションほど安全ではないため、あまりお勧めできません。

すべてのノードでこれらの変更を行い、ローリング再起動を実行する必要があります。その方法の詳細については、ガイドをご覧ください。

再インデックスコマンド

elasticsearch.yml ファイルでリモート ホストを定義し、必要に応じて SSL 証明書を追加したら、以下のコマンドでデータの再インデックスを開始できます。

その際、タイムアウト エラーが発生する可能性があるため、デフォルトに頼るのではなく、タイムアウトに余裕を持った値を設定すると便利な場合があります。

ここで、リモートから再インデックスするときに発生する可能性のあるその他の一般的なエラーを見てみましょう。

リモートからの再インデックス時によくあるエラー

1. 再インデックスがホワイトリストに登録されていない

このエラーが発生した場合は、上記のように Elasticsearch でリモート ホストの IP アドレスまたはノード名 DNS を定義しなかったか、Elasticsearch サービスの再起動を忘れたことを示しています。

Elasticsearch クラスターでこの問題を修正するには、リモート ホストをすべての Elasticsearch ノードに追加し、Elasticsearch サービスを再起動する必要があります。

2. SSLハンドシェイク例外

このエラーは、上記のように elasticsearch.yml に reindex.ssl.certificate_authorities を追加するのを忘れたことを意味します。追加するには:

2. スナップショットを使用したデータ転送

前述のように、スナップショットは同等以上のバージョンのクラスタにのみ復元でき、1つ以上のメジャーバージョンの違いがあるクラスタには復元できないことに注意してください。

メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。

スナップショットを介してデータを転送するには、次の手順が必要です。

ステップ 1. 最初の Elasticsearch クラスターにリポジトリ プラグインを追加する – スナップショットを介してクラスター間でデータを転送するには、新しいクラスターと古いクラスターの両方からリポジトリにアクセスできることを確認する必要があります。通常、AWS、Google、Azure などのクラウド ストレージ リポジトリがこれに最適です。スナップショットを撮るには、ガイドを参照して、そこに記載されている手順に従ってください。

ステップ 2. Elasticsearch サービスを再起動します (ローリング再起動)。

ステップ 3. 最初の Elasticsearch クラスターのリポジトリを作成します。

ステップ 4 - リポジトリ プラグインを 2 番目の Elasticsearch クラスターに追加します。

ステップ 5 - リポジトリを 2 番目の Elasticsearch クラスターに読み取り専用として追加する - 最初の Elasticsearch クラスターを作成するときに実行したのと同じ手順を繰り返して、リポジトリを追加する必要があります。

重要な注意: 2 番目の Elasticsearch クラスターを同じ AWS S3 リポジトリに接続する場合は、リポジトリを読み取り専用リポジトリとして定義する必要があります。

これは、同じスナップショットリポジトリ内で Elasticsearch のバージョンが混在するリスクを回避するために重要です。

ステップ 6 - 2 番目の Elasticsearch クラスターへのデータの復元 - 上記の手順を実行した後、データを復元して新しいクラスターに転送できます。新しいクラスターにデータを復元するには、この記事に記載されている手順に従ってください。

3. Logstash を使用したデータ転送

logstash を使用してデータの転送を開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、インデックスを直接作成するか、インデックス テンプレートを使用する必要があります。

2 つの Elasticsearch クラスター間でデータを転送するには、一時的な Logstash サーバーをセットアップし、それを使用して 2 つのクラスター間でデータを転送できます。小規模なクラスターの場合、2GB の RAM インスタンスで十分です。より大規模なクラスターの場合は、8GB の RAM を搭載した 4 コア CPU を使用できます。

Logstash のインストールに関するガイダンスについては、こちらをご覧ください。

あるクラスターから別のクラスターにデータを転送するための Logstash 構成

クラスター A からクラスター B に単一のインデックスをコピーするための基本構成は次のとおりです。

セキュアな elasticsearch の場合は、以下の構成を使用できます。

インデックスメタデータ

上記のコマンドは、単一の名前付きインデックスに書き込みます。複数のインデックスを転送し、インデックス名を保持する場合は、Logstash 出力に次の行を追加する必要があります。

また、ドキュメントの元の ID を保持したい場合は、以下を追加する必要があります。

ドキュメント ID を設定するとデータ転送速度が大幅に低下することに注意してください。必要な場合にのみ元の ID を保持してください。

更新の同期

上記の方法はすべて比較的長い時間がかかり、プロセスが完了するまでに元のクラスターのデータが更新されている場合があります。

データ転送プロセス中に発生した可能性のある更新を同期できるようにするにはさまざまな戦略があり、そのプロセスを開始する前にこれらの問題について検討する必要があります。特に、次の点を考慮する必要があります。

• データ転送プロセスの開始以降に更新/追加されたデータを識別する方法は何ですか (例: データ内の「last_update_time」フィールド)?
• 最後のデータを転送するにはどのような方法を使用できますか?
• 記録が重複するリスクはありますか?通常は、使用している方法によって再インデックス中にドキュメント ID が既知の値に設定されない限り、存在します。

更新の同期を有効にするさまざまな方法について以下に説明します。

1. 待ち行列システムの使用

一部の取り込み/更新システムでは、過去 x 日間に受信したデータの変更を「再生」できるキューを使用します。これにより、実行された変更を同期する手段が提供される場合があります。

2. リモートから再インデックス

「last_update_time」が x 日前を超えるすべてのアイテムに対して、再インデックス処理を繰り返します。これを行うには、再インデックス リクエストに「クエリ」パラメータを追加します。

3. ログスタッシュ

Logstash 入力では、「last_update_time」が x 日前を超えるすべての項目をフィルターするクエリを追加できます。ただし、document_id を設定していない限り、このプロセスでは非時系列データに重複が発生します。

4. スナップショット

インデックスの一部だけを復元することはできないため、データ転送プロセスの実行以降に行われた変更を更新するには、上で説明した他のデータ転送方法のいずれか (またはスクリプト) を使用する必要があります。

ただし、スナップショットの復元は再インデックス/Logstash よりもはるかに高速なプロセスであるため、スナップショットの転送中に更新を短時間一時停止して、問題を完全に回避できる可能性があります。