OpenSearch Service ドメインのアップグレードに時間がかかるのはなぜですか？

簡単な説明

OpenSearch Service ドメインのバージョンをアップグレードすると、ブルー/グリーンデプロイメントプロセスを有効にする設定変更が行われます。ブルー/グリーンデプロイでは、2 つの実稼働環境が実行されます。1 つの環境は稼働中で、もう 1 つの環境はアイドル状態です。その後、ソフトウェアのアップグレードに応じて 2 つの実稼働環境が切り替わります。OpenSearch Service の場合、ドメインのアップグレード中に新しい環境が作成され、アップグレードが完了すると、ユーザーは新しい運用環境にルーティングされます。この動作により、ダウンタイムが最小限に抑えられ、デプロイが失敗した場合でも元の環境が維持されます。

OpenSearch Service のアップグレードプロセスには、アップグレード前の問題チェックと、アップグレードが失敗した場合にクラスターを復元するためのクラスタースナップショットが含まれます。

OpenSearch Service のアップグレードでは、以下の問題が発生する可能性があります。

• アップグレード前のチェック失敗
• アップグレードプロセスの完了に時間がかかりすぎる
• アップグレードは正常に完了したが、問題がある

詳細については、「Amazon OpenSearch Service ドメインのアップグレード」を参照してください。

解決方法

アップグレード前のチェック

アップグレードプロセスは元に戻せません。一時停止やキャンセルはできません。アップグレード中は、ドメインの設定を変更することはできません。アップグレードを開始する前に、適格性を再確認するのがベストプラクティスです。ドメインがアップグレードに適格でないか、アップグレードに失敗する可能性があります。

最も一般的なアップグレードの問題を確認するには、「アップグレードのトラブルシューティング」を参照してください。

スナップショットのステータスを確認

移行前に、OpenSearch Service は適格性テストに合格したクラスターの自動スナップショットを作成します。スナップショット中、進行状況が Null または 0% と表示されることがあります。OpenSearch Service がスナップショットを取得すると、パーセンテージ値が更新されます。スナップショットの完了にかかる時間は、ストレージ容量によって異なります。OpenSearch サービスはスナップショットを段階的に取得します。前回の自動スナップショットからデータに大きな変更が加えられた場合、スナップショットの完了までに時間がかかる場合があります。

次の _snapshot リクエストは、現在実行中のすべてのスナップショットを、詳細なステータス情報とともに取得します。

GET /_snapshot/_status

スナップショット API の詳細については、Elasticsearch ウェブサイトの「スナップショットの監視」を参照してください。

すべてのクラスタースナップショットとノード ID を取得

クラスターで現在実行中のすべてのスナップショットを取得するには、current パラメータを使用します。

GET /_snapshot/<snapshot-repository>/_current

すべてのデータノードの ID を取得するには、cat nodes API を実行します。

GET _cat/nodes

ノード ID を使用して、古いノードまたは新しいノードを識別できます。新しいノードでシャードの数が増えていることは、移行がスムーズであることを示しています。最終的に、すべてのシャードが新しいノードに移動し、古いノードは空になります。

ブルー/グリーンデプロイプロセスを監視

クラスターがブルー/グリーンデプロイプロセスに入ると、グリーンの環境の新しいノードが表示されます。その後、シャードはブルーの環境の古いノードから移行されます。データ移行またはシャードの再割り当てが完了すると、古いノードは終了します。

ブルー/グリーンデプロイプロセスは、新しいノード、データ移行、古いノードの削除という3つの段階で監視できます。

ステージ 1: 新しいノードの作成

Amazon CloudWatch でノードのクラスターメトリクスをモニタリングしてノード数を取得できます。または、cat nodes API を使用してクラスター内のすべてのノードを一覧表示することもできます。

GET /_cat/nodes?v&pretty

ブルー/グリーンデプロイプロセスのこの段階では、ノード数が増えるにつれて API 出力から新しいノードを確認できます。

ステージ 2: データ移行

最初の段階が完了するとすぐに、シャードの移行が開始されます。データ移行中、古いノードのシャード数は減少し、新しいノードのシャード数は増加します。(OpenSearch ウェブサイトから) cat/allocation API を使用すれば、各ノードに割り当てられているシャードの数を取得することができます。

GET /_cat/allocation

シャードのステータス（[開始]、[再配置中]、または [未割り当て]）を取得するには、次の API を実行します。

GET _cat/shards?h=index,shard,prirep,state,relocating.reason

クラスター内のシャードの(Elasticsearch ウェブサイトから) 復旧状況を確認するには、次の API を実行します。

GET _cat/recovery?active_only=true

この段階では、クラスターの過負荷、不均衡なシャード、またはバックエンドの問題が原因で、データ移行が完了するまでにさらに時間がかかる場合があります。

過負荷クラスタ

クラスタートラフィックが高くない場合は、必ずバージョンをアップグレードしてください。アップグレードを開始する前に CPUUtilization および JVMMemoryPressure cluster metrics をチェックし、これらのメトリクスが最適な値であるかどうかを確認してください。

詳細については、「Amazon OpenSearch Service クラスターで高い CPU 負荷をトラブルシューティングするにはどうすればよいですか？」を参照してください。

不均衡なシャード

デフォルトでは、Amazon OpenSearch Service は 5:1 のシャーディング戦略を採用しており、各インデックスは 5 つのプライマリシャードに分割されます。シャーディング戦略のサイズを設定して、それぞれが検索ワークロードの場合は 10～30 GiB、ログワークロードの場合は 30～50 GiB の間でシャーディングするようにします。

OpenSearch と Elasticsearch 7.x 以降では、ノードあたり 1,000 シャードに制限されています。Java ヒープの GiB あたりのシャードは 25 個以下にするのがベストプラクティスです。

詳細については、「Amazon OpenSearch Service クラスター内の不均一なシャード分布を再調整するにはどうすればよいですか？」を参照してください。

バックエンドの問題

この段階では、バックエンドの問題によりシャードの移行が滞ることがあります。移行が進まず、問題が自己解決しない場合は、AWS サポートに連絡してください。

ステージ 3: 古いノードの削除

すべてのシャードが新しいノードに移行されると、古いノードはクラスターから削除されます。その後、ノード数は、設定した元のノード数に戻ります。この段階で、ブルー/グリーンデプロイとアップデートのプロセスが完了しました。

アップグレードは正常に完了したが、問題がある

「アップグレードは正常に完了しましたが、問題が発生しました」というメッセージは、クラスターが受信する書き込みリクエストをブロックしているときに表示されます。OpenSearch Service ClusterIndexWritesBlocked メトリックを確認してください。値が 1 の場合は、クラスターが書き込み要求をブロックしていることを意味します。この問題を解決するには、ディスク容量を追加するか、クラスターをスケーリングしてください。

詳細については、Amazon OpenSearch Service 運用のベストプラクティスを参照してください。