Amazon OpenSearch Serviceがクローンベースのアップグレードを追加：クローンクラスターで検証できるのは読み取りのみ、切り替え前は中止、切り替え後は自分で設定した保持期間内にロールバック可能。OpenSearch 1.1以降またはElasticsearch 7.10限定で5つのパス、検証中は2つのクラスターに課金

2026年11月10日、AWSはAmazon OpenSearch Serviceのクローンベースのアップグレードを発表しました。通知によると、新しいOpenSearchバージョンを現在のバージョンと並べて検証し、納得できたときだけ切り替えられるようになりました。問題が見つかれば、切り替え前に中止することも、切り替え後にロールバックすることもできます。本稿はこの通知と、手順、制限、料金を記したOpenSearch Service開発者ガイドのバージョン移行のページに基づきます。どちらのページにもクローンベースのアップグレードの所要時間はないため、クローンの構築がどれだけ速いかは扱いません。

従来の方法はインプレースアップグレードです。ガイドによると、これはドメインの既存クラスターをブルー/グリーンデプロイとしてアップグレードするもので、一時停止、中止、ロールバックはできません。OpenSearch 1.0以降、またはElasticsearch 5.1以降で利用できます。ガイドは、事前チェックが先に実行されるものの、アップグレードが完了するとすぐにアップグレード後のクラスターが引き継ぐこと、インプレースアップグレードには15分から数時間かかることがあり、その間OpenSearch Dashboardsが使えない場合があることを述べています。インプレースの後で以前のバージョンに戻すには、新しいドメインでスナップショットを復元するとガイドは述べています。

クローンベースのアップグレードは異なります。OpenSearch Serviceは目標バージョンで2つ目のクラスター、つまりクローンクラスターを作り、データをコピーします。ドメインがすでに動いているクラスターがプライマリクラスターで、トラフィックを処理し続けます。ガイドは6つのステップを挙げています。第1に事前チェックが実行されます。これはインプレースと同じもので、成功しなければ先に進みません。第2にスナップショットが取られ、これも成功しなければ進みません。第3にクローンクラスターが作られてデータがコピーされます。この間もドメインはプライマリクラスターから読み書きを処理し、クローンは同期を保ちます。第4に、アップグレードはあなたの検証を待ちます。通知は、両方のクラスターで同じ検索クエリを実行し、Amazon CloudWatchメトリクスで性能を比較できると述べ、ガイドは任意で読み取りトラフィックの一部をクローンに送れると補足しています。第5が切り替え、第6が任意の保持期間です。

見落としやすい条件がいくつかあります。検証は読み取りのみです。ガイドは、自分の読み取りリクエストでクローンクラスターを検証できると述べ、それ以上のことは書いていません。切り替えの間、OpenSearch Serviceは切り替えが完了するまで書き込みをブロックし、その間にクローンが追いついてトラフィックが移ります。ガイドによると、ドメインのエンドポイントは変わりません。ロールバックは切り替え後、かつ設定した保持期間内にのみ可能です。保持期間は切り替え完了時に始まります。保持期間を設定しない場合、ガイドは、OpenSearch Serviceが切り替え直後にプライマリクラスターを削除すると述べており、戻る先がなくなります。切り替え前に中止するとクローンクラスターが削除され、ドメインは元のままです。

対象条件は狭いです。通知によると、クローンベースのアップグレードは、OpenSearch 1.1以降またはElasticsearch 7.10を実行するドメインで、サービスが提供されているAWSの商用リージョンのうち、アジアパシフィック（ニュージーランド）、アジアパシフィック（台北）、アジアパシフィック（タイ）、メキシコ（中部）を除いて利用できます。ガイドは5つのサポート対象パスを挙げています。Elasticsearch 7.10からOpenSearch 1.3、OpenSearch 1.1から1.3、OpenSearch 1.3から2.19、OpenSearch 2.xから2.19、OpenSearch 2.19から3.xです。それ以外のパスにはインプレースを使うよう、ガイドは述べています。サポートされないドメインも挙げられています。OpenSearch Optimizedインスタンス（OR1またはOR2）、UltraWarmインスタンス、クロスクラスターレプリケーションを使うドメイン、カスタムまたはサードパーティのプラグインパッケージが関連付けられたドメイン、OpenSearch DashboardsにSAMLまたはAmazon Cognito認証を使うドメインです。アップグレード中にドメインの設定を変更することもできません。

料金のルールは明確です。インプレースアップグレードに追加料金はありません。クローンベースの場合は、他のノードと同様に、クローンのインスタンスとストレージに標準料金が適用されます。検証中はプライマリクラスターとクローンの両方に課金され、ロールバックのためにプライマリクラスターを残す場合は、保持期間が終わるまで両方に支払います。通知もガイドも金額は示していません。そのため、検証や保持期間が長いほど、2つのクラスターに支払う期間が長くなります。追加額は、自分で選ぶインスタンスとストレージ、そして標準料金によって決まります。

どのアップグレードでも、ガイドは事前に3つを求めています。以前のバージョンに戻したいときに新しいドメインで復元できる手動スナップショットを取ること、サポートされるアップグレードパスを確認すること、事前チェックを実行することです。また、Amazon Data FirehoseやAmazon CloudWatch LogsなどでOpenSearch Serviceにデータを流している場合は、移行前にそれらが新しいバージョンに対応しているか確認するよう警告しています。トラブルシューティングの表には、アップグレードを妨げる条件が挙がっており、1ノードあたりのシャードが1,000を超える、ディスク使用率が90%を超える、JVMメモリ圧迫が75%を超える、クラスターのステータスが赤、などです。これらのチェックは両方のアップグレード方式に適用されます。

この2つのページに書かれていないことは、計画にとって重要です。クローンの構築や追いつきにかかる時間の測定、切り替え中に書き込みがブロックされる時間の記述、クローンの性能が本番の性能をどこまで予測するかの根拠は示されていません。ガイドは検証が読み取りのみだとしているため、この検証段階では書き込みの挙動を直接確かめられません。以下は本稿の判断で、AWSの説明ではありません。書き込みの多いチームは、本番以外の環境での書き込みテストと切り替えのリハーサルを別に計画するべきです。この安全網を使いたいチームは、さらに本番以外のドメインで切り替えの所要時間を測り、プライマリクラスターをどれだけ保持するかを事前に決め、その間の2つのクラスターの費用を予算に入れるべきです。