リソース使用率が高いままの場合やパフォーマンスが不足している場合は、ノードの追加、ノード仕様のアップグレード、ディスク容量の拡張、またはノードタイプの追加によって Elasticsearch (ES) クラスターをアップグレードします。
事前準備
アップグレードによって、サービスの遅延、設定の競合、請求の変更が発生する場合があります。続行する前に、以下の項目をご確認ください。
サービスの安定性
設定変更中のサービスの安定性：
クラスターの状態
サービスへの影響
推奨されるアクション
レプリカありの通常負荷
通常負荷：CPU ≤ 60%、ヒープメモリ ≤ 50%、負荷 < コア数。
サービスは利用可能なままです。軽微なパフォーマンス低下が発生する可能性があります。
アクションは不要です。
レプリカなしの高負荷
高負荷：アップグレード中に高い同時書き込みやクエリがあり、CPU > 60% またはヒープメモリ > 50%。
時折、アクセスタイムアウトが発生する場合があります。
クライアントで再試行メカニズムを有効にしてください。
アップグレード前にインデックスレプリカの数を増やしてください。
異常な状態での高負荷
時折、アクセスタイムアウトやサービスのジッターが発生する場合があります。
変更前にクラスターのヘルス状態を回復させてください。
メンテナンスウィンドウ：オフピーク時に操作を実行してください。
キャパシティプランニング
設定の制約
クラスター設定のアップグレード中に Elasticsearch のバージョンをアップグレードすることはできません。
1 回のアップグレード操作で変更できるノードタイプは 1 種類のみです。
V3 アーキテクチャ のクラスターでは、インテリジェントアップデート を無効にすることはできません。インスタンス設定を更新する API を呼び出し、
intelligentパラメーターをfalseに設定した場合、システムはその値をtrueに上書きします。V3 アーキテクチャクラスターのアップグレードページには、インテリジェントアップデートを無効にするオプションはなく、ノード仕様やディスクタイプのアップグレードでは常にブルー/グリーンアップデートが使用されます。
コストへの影響
一般的なシナリオでの推奨仕様
Elasticsearch クラスターをアップグレードする際、ワークロードタイプに基づいて適切な仕様ファミリーを選択することで、リソースを効率的に活用できます。次の表を使用して、シナリオに最適な仕様ファミリーを特定してください。
シナリオ | 推奨仕様ファミリー | 仕様例 | ユースケース |
CPU/書き込み集中型 | 1:2 コンピューティング最適化 | 8 vCPU 16 GiB | 高い CPU 使用率と書き込み集中型のワークロード |
メモリ集中型 | 1:4 汎用 | 8 vCPU 32 GiB | より大きなオフヒープメモリを必要とするシナリオ |
高いメモリ需要 | 1:8 メモリ最適化 | 8 vCPU 64 GiB | 深い集計と大規模なインデックスキャッシュ |
メモリをアップグレードすると、書き込みパフォーマンスがある程度向上する場合があります。ただし、実際の効果はワークロードとデータ量によって異なります。本番クラスターに変更を適用する前に、テスト環境で効果を検証してください。
本番環境 で 2 vCPU 4 GiB 以下のノード仕様を使用することは推奨しません。このような小規模な仕様のノードでは、システムプロセスとモニタリングインデックスのメンテナンスが限られたリソースの過大な割合を消費し、ビジネス負荷がない場合でも CPU 使用率が急上昇する可能性があります。本番環境では、最低でも 4 vCPU 8 GiB の仕様を使用することを推奨します。
クラスターに必要な仕様とストレージ容量の評価方法の詳細については、「仕様とストレージ容量の評価」をご参照ください。
アップグレード前のチェック
これらのチェックをスキップすると、クラスターのクラッシュ、データ損失、またはサービスが利用できなくなることにつながる可能性があります。
クラスターの健全性
GET _cluster/healthを実行して、クラスターのステータスが GREEN であることを確認してください。異常な場合は、「クラスター変更エラー - 異常なクラスター状態」を使用して問題を解決してください。負荷の安全性
GET _cat/nodes?vを実行してください。CPU 使用率は 60% 以下である必要があります。それより高い場合は、クライアント側の再試行を有効にし、インデックスレプリカを増やしてください。インデックスの準備状態
GET /_cat/indices?vを実行して、閉じられたインデックスを確認してください。続行する前にPOST /<index_name>/_openでインデックスを開いてください。閉じられたインデックスは、以下の理由により設定変更の失敗を引き起こすためです。閉じられたインデックスは、シャード割り当ての変更に必要なクラスターの GREEN ステータスへの到達を妨げます。
設定変更中、クラスターはシャードを再割り当てします。
閉じられたインデックスのシャードは再割り当てに参加できません。
GREEN ステータスを必要とする操作は失敗します。
クラスターはせいぜい YELLOW にしか到達できません。
ビジネス上の理由で閉じられたインデックスを開いたり削除したりできない場合でも、
GET _cluster/healthが正常なステータスを報告している場合でも、コンソールは異常なクラスター状態エラーでアップグレードをブロックします。これは、閉じられたインデックスによって引き起こされる予期された検証動作であり、シグナルが矛盾しているわけではありません。回避策として、アップグレードページで インテリジェントアップデート を無効にし、手動で [ローリングアップデート] を選択してアップグレードを続行してください。この更新方法は、データをコピーせずにノードのローリング再起動を実行し、ノードの IP アドレスを変更せず、所要時間も短いため、処理できない閉じられたインデックスを多数含むクラスターに適しています。この回避策は、インテリジェントアップデートを無効にできる V2 アーキテクチャ のクラスターにのみ適用されます。V3 アーキテクチャ のクラスターでは、インテリジェントアップデートは無効にできず、アップグレードページにはこのオプションは提供されず、ノード仕様やディスクタイプのアップグレードでは常に [ブルーグリーンアップデート] が使用されます。クラスターのアーキテクチャバージョンを特定するには、本トピックの「クラスターのアーキテクチャバージョンの判別」セクションをご参照ください。他のインプレースアップデートと同様に、リソース使用率が高い場合 (例：CPU > 60%) は注意して使用してください。GET _cat/indices?vを実行して、各インデックスに少なくとも 1 つのレプリカがあることを確認してください。マルチゾーンデプロイメントの場合、変更中はレプリカ数をゾーン数より少なく保ってください (推奨：1)。変更が完了した後にレプリカを増やしてください。
シャードのバランス
GET _cat/shards?vを実行して、不均衡なシャードがないか確認してください。重要シャードが不均衡だと、アップグレード後にパフォーマンスが低下したり、クラスターがクラッシュしたりする可能性があります。
prirep：レプリカシャード (r) がUNASSIGNEDになっていないか確認してください。state：シャードの移行が長時間RELOCATING状態でスタックしていないか確認してください。
これらの問題は、新しいノードがシャードを受け取るのを妨げ、クラスターが YELLOW または RED のままになります。「クラスター負荷の不均衡に対する解決策」を使用してこれらを解決してください。
クラスターのアーキテクチャバージョンの判別
ES クラスターは、v2 または v3 の 2 つのコントロールプレーンアーキテクチャのいずれかで実行されます。利用可能なアップグレード方法と推定所要時間はアーキテクチャによって異なります (本トピックの「方法 1：コンソール経由でのアップグレード」の更新方法の所要時間の詳細をご参照ください)。アップグレードを進める前に、クラスターのアーキテクチャバージョンを判別してください。
方法 1：コンソールでの確認
ES コンソールにログインし、インスタンスの 基本情報 ページに移動し、[コントロールプレーンデプロイメントモード] フィールドの値をチェックしてください。この値は、クラスターのアーキテクチャバージョンを示します。
方法 2：Elasticsearch バージョン番号による判別
アーキテクチャバージョン | 対応する Elasticsearch バージョン番号 |
v2 | 5.5.3、5.6.16、6.3.2、一部の 6.7.0、6.8.6、7.4.0、7.7.1、一部の 7.10.0、一部の 7.16.2 |
v3 | 一部の 6.7.0、6.8.23、一部の 7.10.0、一部の 7.16.2、8.x 以降 |
バージョン番号 6.7.0、7.10.0、および 7.16.2 については、v2 と v3 の両方のインスタンスが存在します。バージョン番号だけではアーキテクチャを一意に決定できません。コンソールの [基本情報] ページにある [コントロールプレーンデプロイメントモード] フィールドを確認してください。
方法 1：コンソール経由でのアップグレード
インスタンス ページで、アップグレード設定 をクリックします。
代替エントリポイント：インスタンスの 基本情報 ページで、 をクリックします。
[アップグレード/ダウングレード] ページで、ビジネス要件に基づいて設定パラメーターを調整してください。
重要利用可能なパラメーターは、クラスターのタイプとバージョンによって異なります。アップグレードページには、適用可能なオプションが表示されます。
アベイラビリティゾーンの変更：ゾーン内の仕様の在庫が不十分な場合は、まず ノードを移行 してください。
1 つのゾーンから 2 つまたは 3 つのゾーンに拡張できます。マルチゾーンクラスターを単一ゾーンに縮小することはサポートされていません。ゾーンの数を減らす必要がある場合は、必要なゾーン設定で新しいインスタンスを購入し、データを移行してから元のインスタンスを解放してください。
ノード仕様とストレージタイプ (パフォーマンスが低い順)：
旧世代のクラウドディスク：標準クラウドディスク → Ultra クラウドディスク → SSD クラウドディスク。
説明これらのディスクタイプは一部のリージョンで段階的に廃止されています。代わりに ESSD を使用してください。
ESSD：ESSD (エンタープライズ SSD) は 25 GbE ネットワークと RDMA を使用し、ディスクあたり最大 100 万 IOPS と低レイテンシーを実現します。
ローカルディスク
説明ローカルディスクは物理的な ECS ホストマシン上に存在します。高い I/O パフォーマンスやコスト効率の高い大容量ストレージを必要とするワークロードに適しています。
説明SSD から ESSD へのアップグレード時期：クラスターの IOUtil メトリックが一貫して高く、頻繁に 100% に達する場合は、I/O パフォーマンスを向上させるために SSD クラウドディスクから ESSD クラウドディスクへのアップグレードを検討してください。
説明ストレージアップグレードの制約：
ESSD PL0 の制限：既存の SSD クラウドディスクインスタンスを ESSD クラウドディスクにアップグレードする場合、PL0 は利用できません。PL1 以上のパフォーマンスレベルのみ選択できます。PL0 は、新しい ESSD インスタンスを作成する際には引き続き利用可能です。
強制アップデート：ディスクがいっぱいでクラスターの状態が異常になった場合は、不要なインデックスを削除するか、レプリカの数を減らして、アップグレード前にクラスターを GREEN ステータスに復元してください。そうしない場合は、アップグレードページの 強制アップデート を選択して容量拡張を強制することができますが、これにより再起動中にサービスが不安定になる可能性があります。アップグレードページには、[インテリジェントアップデート] オプション (デフォルトで有効) も提供されており、システムが変更の種類に合った更新方法を自動的に選択できます。
ローカルディスクの依存関係：クラスターがローカルディスクを使用している場合、ストレージ容量をアップグレードするには、ノード全体の仕様をアップグレードする必要があります。現在、新しいインスタンスを作成する際に利用できるのは [新世代クラウドディスク] ノードタイプのみです。ローカルディスクは既存のインスタンスでのみ利用可能です。
ストレージの自動スケーリングはサポートされていません：Elasticsearch は ApsaraDB RDS のようなストレージの自動スケーリング機能をサポートしていません。
重要組み合わせた変更に関する考慮事項：ノード仕様のアップグレード、ディスクタイプの変更、容量の拡張を同時に行う必要がある場合、ディスクタイプの変更はインプレースアップデートをサポートせず、ブルー/グリーンアップデートのみがサポートされることに注意してください。複数のデータ移行を避けるために、変更を別々のステップで実行してください：
まず、ノード仕様のアップグレードと容量の拡張を行ってください。これらの変更には、インテリジェントアップデートまたはインプレースアップデートを使用できます。
クラスターが回復した後、ブルー/グリーンアップデートを使用してディスクタイプを個別に変更してください。
ブルー/グリーンアップデートは、データ同期が完了した後のノード切り替えフェーズでのみ短い接続中断を引き起こす可能性があり、ビジネスへの影響を最小限に抑えます。
インテリジェントアップデート (デフォルトで有効)：システムが最適な更新方法を自動的に選択します。無効にして手動で選択することもできます：
更新方法
メカニズム
期間
サービスへの影響とユースケース
[ブルーグリーンアップデート]
新規ノードの追加 → データのコピー → シームレスな切り替え
長い
ノードの IP アドレスが変更されます。一時的なパフォーマンスの変動が発生する可能性があります。
更新速度よりも可用性が重要な場合に最適です。
[ローリングアップデート]
主にノードのローリング再起動 (データコピー不要)。
短い
ノードの IP アドレスは変更されません。一時的なパフォーマンスの変動が発生する可能性があります。
パフォーマンスのボトルネックを迅速に解決するのに最適です。
重要リソース使用率が高い場合 (CPU > 60%) は注意して使用してください。
V2 アーキテクチャインスタンスの推定所要時間 (ブルー/グリーンアップデート)
V2 アーキテクチャのクラスターの場合、データノード仕様または ES バージョンのアップグレードには ブルー/グリーンアップデート が使用されます。所要時間は次のように推定してください：
合計期間 = コントロールプレーン期間 + データ移行期間
コントロールプレーン期間 = ノード数 × 10 分 × 2。ブルー/グリーンアップデート では、まず新しいノードが追加され、次に古いノードが削除されるため、各ノードは約 10 分のラウンドで 2 回カウントされます。
データ移行期間 (時間) = 単一データノードの最大データ量 /
indices.recovery.max_bytes_per_sec/ 3600。indices.recovery.max_bytes_per_secのデフォルト値は 40 MB/s です。GET /_cluster/settings API を呼び出して現在の値を確認し、必要に応じて調整してください。
例：3 つのデータノードを持つ V2 クラスターの場合、コントロールプレーン期間は約 3 × 10 × 2 = 60 分 (約 1 時間) です。上記の式で計算されたデータ移行期間を加算して、推定合計期間を求めてください。
V3 アーキテクチャインスタンスの推定所要時間 (ブルー/グリーンアップデート)
V3 アーキテクチャのクラスターの場合、[ブルーグリーンアップデート] はコントロールプレーンフェーズとデータ移行フェーズで構成されます：
合計期間 = コントロールプレーン期間 + データ移行期間
コントロールプレーン期間：約 10～20 分。これは新しいノードの起動と古いノードの削除をカバーします。
データ移行期間 (時間) = 単一データノードの最大データ量 /
indices.recovery.max_bytes_per_sec/ 3600。indices.recovery.max_bytes_per_secのデフォルト値は 40 MB/s です。GET /_cluster/settings API を呼び出して現在の値を確認し、必要に応じて調整してください。
例：合計データ量 3 TB、
indices.recovery.max_bytes_per_secが 100 MB/s に設定されている 3 ノードクラスターの場合、単一データノードの最大データ量は約 1 TB です。データ移行期間は約 1 TB / 100 MB/s / 3600 ≈ 2.8 時間です。ブルー/グリーンアップデートの合計期間は約 10 分 + 2.8 時間です。説明すべてのインプレースアップデート操作がローリング再起動をトリガーするわけではありません。V3 アーキテクチャ のクラスターでは、サービスへの影響はアップグレードシナリオによって異なります：
ストレージ容量のアップグレード：オンライン拡張として実行されます。ノードの再起動はなく、変更中に実行中のタスクは影響を受けません。
水平スケーリング (データノードの追加)：既存のデータノードは再起動されません。変更が完了すると、クラスターは自動的にシャードをリバランスし、データ移行がクラスターリソースの一部を消費します。
ノード仕様またはディスクタイプのアップグレード：デフォルトで [ブルーグリーンアップデート] として実行されます。新しいノードが追加され、データが移行され、その後古いノードが削除されます。ビジネスリクエストは、変更の最後にノードの切り替え中に軽微な例外が発生する可能性があります。
V2 アーキテクチャのクラスターでは、ノード仕様の変更は依然としてノードを 1 つずつ再起動して更新を完了します。
[強制アップデート]：ヘルスチェックをスキップし、クラスターを強制的に再起動します。回復時間はデータ量に依存します。クラスターがすでに利用不能な場合の緊急スケーリングにのみ使用してください。
Terms of Service と Service Level Agreement をお読みください。同意する場合は、[今すぐ購入] をクリックしてください。請求は選択した方法に従います。
変更中、クラスターのステータスは 初期化中 に変わり、パフォーマンスの変動や一時的なリクエストの失敗が発生する可能性があります。完了後、ステータスは 正常 に戻ります。
方法 2：API 経由でのアップグレード
UpdateInstance API を呼び出します。
監視と検証
アップグレードが開始されたら、[Elasticsearch クラスター] コンソールの [基本情報] ページで進捗を確認してください：
詳細の表示 をクリックしてください：
アップグレード後、[基本情報] ページで新しい設定を検証してください：
クラスターのステータスがアクティブに戻ります。
アベイラビリティゾーン
ノード数とストレージ：新しいノードがクラスターに参加し、ストレージ仕様が正しいことを確認してください。
シャードのバランス：
GET _cat/allocation?vを実行してシャードの分布を確認してください。不均衡な場合は、「クラスター負荷の不均衡に対する解決策」を使用してください。
「初期化中」の状態でスタックしたアップグレードのトラブルシューティング
推定所要時間：ESSD クラウドディスクの拡張には通常 30 分から 1 時間かかります。アップグレードが 2 時間以上 初期化中 の状態のままの場合は、さらに調査してください。
V2 アーキテクチャクラスターでのシャード割り当ての確認：拡張中、シャード割り当てが自動的に無効になる (
cluster.routing.allocation.enableがnoneに設定される) ことがあり、これによりアップグレードがスタックしているように見えることがあります。Kibana Dev Tools で次のコマンドを実行して、シャード割り当てを再度有効にしてください：PUT /_cluster/settings { "transient" : { "cluster.routing.allocation.enable" : "all" } }データ移行の高速化：データ移行が遅い場合は、コンソールでノードのデータ転送帯域幅を 80 MB/s に増やして移行を高速化してください。
接続タイムアウトは想定内です：アップグレードまたはディスク拡張中のインスタンスの再起動は、ビジネス側で一時的な接続タイムアウトを引き起こす可能性があります。これは予期された動作です。これらのタイムアウトを処理するために、クライアントに再試行メカニズムを設定してください。
よくある質問
アップグレードとパフォーマンスメトリクス
Q：アップグレードは常にパフォーマンスを改善しますか？
A：必ずしもそうとは限りません。CPU、メモリ、またはディスクをアップグレードしても、すべての問題が解決するわけではありません。まず、特定のボトルネックを特定してください：
CPU ボトルネック：持続的に 80% を超える使用率 (一時的なスパイクではない)。
メモリボトルネック：頻繁な長時間のガベージコレクション (GC) 時間、メモリスワッピング、または OutOfMemory (OOM) エラー。
ディスクボトルネック：%util だけでなく、実際の I/O スループットを確認してください (下記参照)。
ネットワークボトルネック：ネットワーク帯域幅が一貫して飽和状態にあり、レイテンシーが著しく高い。
アップグレードする前にボトルネックを確認してください。リソースを追加するよりも、インデックス、クエリ、または設定を最適化する方が効果的な場合が多いです。
Q：%util が 100% なのにシステムが正常なのはなぜですか？
A：%util は iostat のメトリックであり、デバイスが I/O でビジーだった時間の割合を測定するもので、I/O 量ではありません。最新のディスクは複数の I/O リクエストを並行して処理するため、100% の %util はデバイスが飽和していることを意味しません。
たとえば、ディスクが 1 つの I/O リクエストを処理するのに 0.1 秒かかり、同時に 10 のリクエストを処理できるとします。
10 の I/O リクエストが順次送信された場合、完了までに 1 秒かかり、%util は 100% になります。
10 の I/O リクエストが一度に送信された場合、それらは並行して処理され、0.1 秒で完了します。1 秒間隔で測定すると、%util は 10% になります。
%util メトリックは、最新のストレージではほとんど無関係であり、これだけでアップグレードを決定すべきではありません。
Q：ディスクのボトルネックを示すメトリクスは何ですか？
A：%util の代わりに、これらのメトリクスに注目してください：
I/O スループット：要件に対する実際の読み取り/書き込みレート (MB/s)。
応答時間：クエリパフォーマンスに直接影響する I/O リクエストのレイテンシー。
IOPS：ワークロードパターンに対する秒間 I/O 操作数。
キューの深さ：保留中の I/O リクエストの数。
数時間持続しない 100% の %util は、通常は懸念事項ではありません。fio などのツールを使用して、実際の最大帯域幅と IOPS をベンチマークしてください。
Q：ディスクパフォーマンスのボトルネックを評価する方法は？
A：ディスクパフォーマンスを次のように評価してください：
ワークロードの分析：読み取り/書き込み比率、I/O サイズ、アクセスパターンを決定してください。
%util ではなく、要件に対する実際のスループットを比較してください。
fio でのベンチマーク：実際のワークロードをシミュレートして、実世界のディスクパフォーマンスをテストしてください。
クエリレイテンシーの評価：ES のクエリ応答時間が要件を満たしていることを確認してください。
ES メトリクスの監視：インデックス作成レイテンシーと検索レイテンシーを追跡してください。
単一のメトリックではなく、CPU 使用率、メモリ使用量、I/O スループット、クエリレイテンシーといった完全なメトリクスセットに基づいてアップグレードを決定してください。
Q：ビジネス負荷がない小規模仕様 (2 vCPU 4 GiB 以下) の ES ノードで、CPU 使用率が 90% を超えて急上昇し、ノードの切断を引き起こすのはなぜですか？ どのように解決すればよいですか？
A：これは通常、以下の 1 つまたは複数の原因によって引き起こされます：
不十分なリソース仕様：2 vCPU 4 GiB 以下のノードでは、システムプロセスがすでに限られているリソースの過大な割合を消費します。本番環境で 2 vCPU 4 GiB 以下の仕様を使用することは推奨しません。
高いヒープメモリのウォーターマーク：ヒープメモリ の使用率が 85% 以上で推移している場合、わずかな変動でもヒープが満杯になり、頻繁なフル GC サイクルがトリガーされて CPU スパイクを引き起こす可能性があります。
増幅された監視オーバーヘッド：低仕様のノードでは、監視インデックスの維持がリソースの過大な割合を消費します。
この問題を解決するには：
緊急緩和策：影響を受けたノードを再起動してリソースを解放してください。これは一時的な措置です。
恒久的な修正：ノード仕様を 4 vCPU 8 GiB 以上にアップグレードしてください。アップグレード手順については、本トピックの「方法 1：コンソール経由でのアップグレード」セクションをご参照ください。
アップグレード操作
Q：アップグレードやディスク拡張が有効になるタイミングをスケジュールできますか、それともすぐに実行されますか？
A：いいえ。クラスターのアップグレード (仕様の変更やノードの追加など) も、ディスク容量の拡張も、スケジュール実行をサポートしていません。どちらの操作も、送信して支払いが完了するとすぐに有効になります。システムはすぐに変更を開始し、アップグレードの場合は対応する再起動プロセスを開始します。どちらの操作についても、特定の実行時間をスケジュールすることはできません。
特定の時間 (たとえば、午前 3 時のオフピーク時) に変更を有効にしたい場合は、その時間にアップグレードまたはディスク拡張を送信して支払ってください。
Q：アップグレードやディスク拡張中に通常通り読み書きできますか？ 所要時間はどのくらいですか？
A：通常の条件下 — クラスターが健全 (GREEN) で、インデックスにレプリカがあり、リソース使用率が安全な範囲内にある場合 — アップグレードやディスク拡張中も読み書き操作は機能し続けます。ただし、多くの操作はノードのローリング再起動を伴うため、一時的なサービスのジッターやレイテンシーの増加を引き起こす可能性があります（V3アーキテクチャでのストレージ拡張など、一部の操作は再起動を伴いません）。これらの操作はオフピーク時に実行し、クライアント側で再試行メカニズムを設定することを推奨します。
V2 アーキテクチャインスタンスの推定所要時間：
更新方法 | 推定所要時間 | 注意 |
インプレース再起動 (データノード) | 約 60～90 分 | 所要時間はノード数とデータ量に依存します。 |
ブルー/グリーンアップデート | 約 15 時間 | デフォルトのデータ移行レートは 40 MB/s です。最大推奨レートは 100 MB/s です。 |
リバランスは再起動と同時に実行され、追加の時間はかかりません。
いずれかのインデックスにレプリカがない場合、強制的な変更や再起動により、時折アクセスタイムアウトが発生する可能性があります。続行する前に、すべてのインデックスにレプリカを追加することを推奨します。
Q：データノードを追加した後にインデックスを再構築する必要がありますか？
A：いいえ。データノードの追加はオンライン操作であり、インデックスを再構築する必要はありません。クラスターは、新しいノードを含むすべてのノードにわたってデータを自動的にリバランスおよび再配布します。既存のインデックス、データ、およびビジネスクエリは、このプロセス中に中断されません。
Q：クラスターのアップグレード中にビジネスの継続性を確保するにはどうすればよいですか？
A：アップグレードの前に、各インデックスに少なくとも 1 つのレプリカがあり、リソース使用率が正常なレベルに保たれていることを確認してください。アップグレード中に一時的なリクエストの中断が発生する可能性があります。アプリケーション側で再試行メカニズムを設定し、障害が発生した場合は速やかにトラフィックを切り替えてください。