Amazon OpenSearch Service の書き込み可能なウォームストレージでコストと運用負荷を削減

本記事は 2026 年 7 月 8 日 に公開された「Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service」を翻訳したものです。

ペタバイト規模の検索データを扱っていると、いつも悩ましい選択を迫られます。すべてを高速なまま持ち続けてコストをかけるか、安く抑える代わりに読み取り専用にするか。読み取り中心の履歴データには、UltraWarm という実績のある低コストな選択肢があります。ただ、ワークロードによっては履歴データを更新したい場面が出てきます。遅れて届いたデータの追記や、コンプライアンス対応の修正などです。従来の UltraWarm では、こうしたインデックスをいったんホットに戻し、更新してから、再びウォームに移す必要がありました。この往復をなくして、低コストなウォームストレージに直接書き込めるとしたらどうでしょうか。

本記事では、書き込み可能なウォームストレージ (writable warm) が、この手間のかかる移行サイクルをどうなくすのかを説明します。インフラコストを最大 48% 削減でき、履歴データの更新も数時間ではなく数秒で終わります。実際のワークロードを想定したコスト比較とパフォーマンスのベンチマークを見ながら、writable warm と UltraWarm のどちらを選ぶべきかを判断できるようにします。

階層型ストレージの課題

Amazon OpenSearch Service は、リアルタイムのログ分析やアプリケーション監視からセキュリティイベントの検知まで、データ量の多い検索・分析ワークロードを支えます。データ量がテラバイトからペタバイトへと増えていくと、必ずぶつかる問いがあります。直近のデータは高速に保ちつつ、古いデータのコストはどう抑えるか、という問いです。

OpenSearch Service はこの課題に、階層型ストレージのアーキテクチャで対応します。

• ホット – インスタンスに直結したストレージを使い、アクティブなインデックス作成と検索に最も高い性能を発揮する階層。
• UltraWarm – Amazon Simple Storage Service (Amazon S3) をバックエンドに、ローカルキャッシュを併用する低コストで読み取り専用の階層。クエリ頻度の低いデータ向け。
• コールド – クラスターから完全に切り離し、ほとんどアクセスしないデータを最も低いコストで保管する階層。コールドのインデックスは、読み書きする前に UltraWarm かホットに戻す必要がある。

変更のないログデータであれば、このモデルはうまく機能します。ところが、古いデータにときどき書き込む必要があるワークロードでは、読み取り専用という制約がボトルネックになります。

前提条件

writable warm を使うには、次の条件を満たす必要があります。

1. バージョン 3.3 以降で稼働している Amazon OpenSearch Service ドメイン。
2. 利用する AWS リージョンで OpenSearch Optimized (OI2) インスタンスファミリーがサポートされていること。
3. リフレッシュ間隔が最低 5 秒のワークロードであること。
4. データノードが OpenSearch Optimized インスタンスファミリーを使用していること (ホットは OR2、ウォームは OI2)。

注: writable warm は現時点でコールドストレージ階層に対応していません。

UltraWarm のボトルネック

UltraWarm では、たった 1 件のドキュメントを更新するだけでも、インデックスをホットに戻し、書き込みを行い、再びウォームに戻す必要があります。この往復には force merge (インデックスセグメントの統合)、スナップショットの作成、シャードの再配置がともないます。いずれもホットノードの CPU、メモリ、ディスク容量を大きく消費し、100 GB のインデックスあたり約 130 分かかります。この時間は、ホットノード 3 台 (r6g.2xlarge)、ウォームノード 3 台 (ultrawarm1.large)、専用リーダーノード 3 台 (バージニア北部リージョン) の構成で、レプリカ 1 個のシングルシャードインデックスを使って計測した値です。実際の所要時間は、ドメイン構成、シャード数、セグメント数、ホットノードの使用率、移行キューの深さによって変わります。こうした事情から、ホットノードを過剰にプロビジョニングしたり、複雑なパイプラインを組んだり、必要以上に長くデータをホットに置いたりすることになり、コストと運用の複雑さが増していきます。

書き込み可能なウォームストレージとは

OpenSearch Service に、OpenSearch Optimized (OI2) インスタンスを使う writable warm ノードが加わりました。OI2 は、ホットノードで Amazon S3 をバックエンドにした永続ストレージを支えているのと同じインスタンスファミリーです。データがすでに Amazon S3 に永続化されているため、階層間の移動はリソースを大量に消費する移行ではなく、軽量なシャードの再配置で済みます。OpenSearch の検索ライブラリである Lucene エンジンは、どちらの階層でもまったく同じように動きます。そのため writable warm ノードは、ホットノードと同じようにアクティブな書き込み、バックグラウンドでのマージ、定期的なリフレッシュに対応します。

これまでウォームからホット、そしてウォームへの往復が必要だった、遅れて届いたデータ、コンプライアンス対応のバックフィル、データの修正は、ウォームへの直接書き込みで数秒で片づきます。force merge もスナップショットもシャードの再配置も不要で、ホットノードのリソースを消費することもありません。

UltraWarm (従来) のデータフロー: データはホット階層 (SSD、読み書き可能) に取り込まれます。Index State Management (ISM) のポリシーがインデックスを UltraWarm (Amazon S3 バックエンド、読み取り専用) に移行します。更新するにはインデックスをいったんホットに戻し (破線の矢印)、書き込んでから、再び戻す必要があります。

writable warm (新しい) のデータフロー: 取り込みの経路はホット経由で同じで、ISM がインデックスを writable warm に移します。大きく違うのは、writable warm が読み取りと書き込みの両方に対応する点です。遅れて届いた更新はホットに戻さず、ウォームへ直接反映されます。どちらの階層も OpenSearch Optimized インスタンスを通じて Amazon S3 を永続ストレージとして使うため、階層間の移動はリソースを大量に消費する移行ではなく、軽量なシャードの再配置になります。

メリット: コスト、運用、柔軟性

writable warm には、コスト、運用のシンプルさ、柔軟性という 3 つのメリットがあります。

コスト

オンデマンド料金しか選べない UltraWarm と違い、OI2 インスタンスはリザーブドインスタンス (RI) 料金、つまり利用を約束する代わりに割引を受けられるモデルに対応します。1 年または 3 年の RI を契約すれば、UltraWarm ノードに比べて 31〜52% 節約できます。負荷が読みやすく長期間動かし続けるワークロードでは、writable warm のコスト効率が格段に高くなります。新たに登場した OpenSearch Service 向けの Database Savings Plan を使えば、UltraWarm インスタンスに対して約 22% 削減できます。どちらの階層も永続ストレージに Amazon S3 を使うため、ノードに障害が起きても一時的に使えなくなるだけで、データが失われることはありません。ノード復旧中の短いダウンタイムを許容できるコスト重視のワークロードなら、ウォームのインデックスをレプリカ 0 に設定して、さらにコストを下げられます。

実際のワークロードでのコスト比較

1 日あたり 2 TB を取り込み、保持期間は合計 210 日、更新はいつ発生するか分からないワークロードを考えてみます。UltraWarm は読み取り専用なので、ウォームに移す前にデータを 30 日間ホットに置いておく必要があります。writable warm ならウォーム上で直接更新できるため、ホットでの保持期間はわずか 7 日で済みます。

規模が小さいうちは、ホット階層を減らせる効果はそれほど大きくありません。それでも、ウォームのデータに書き込む必要がある、RI 料金を契約できる、あるいは移行パイプラインをなくして運用をシンプルにしたい、といった場合には writable warm にコスト面のメリットがあります。逆に、まったく変更しないデータを短期間だけ保持するなら、オンデマンドの UltraWarm のほうが安いこともあります。自分のシナリオは AWS Pricing Calculator で試算してみてください。

次の表は、バージニア北部リージョンにおける 2026 年 3 月時点の、オンデマンド料金と全額前払いリザーブドインスタンス (AURI) 料金での月額コストの概算です。最新の料金は AWS ウェブサイトの Amazon OpenSearch Service の料金を参照してください。

運用

ホットノードのキャパシティを取り戻せます。 ホットノードを過剰にプロビジョニングしがちな要因は主に 2 つあります。force merge のためにディスク容量の 35% を確保しておくことと、書き込みのためにデータを一時的にホットへ戻す予備の容量を持たせておくことです。writable warm はこの 2 つをなくします。ホット階層をより高い使用率で運用できるので、必要なホットノードの台数を減らせます。

移行がシンプルになります。 UltraWarm の移行は複数の手順 (force merge、スナップショット、シャードの再配置) からなり、トラフィックの少ない時間帯を狙った慎重なスケジューリングが必要なうえ、同時にキューに入れられるのは 10 件までです。writable warm ではこれが軽量なシャードの再配置だけになり、ISM ポリシーも書きやすく、スケジューリングの制約もありません。

柔軟性

UltraWarm のインスタンスサイズは、ultrawarm1.medium (1.5 TiB) と ultrawarm1.large (20 TiB) の 2 つしかありません。OI2 インスタンスを使う writable warm なら、oi2.large から oi2.16xlarge まで幅広く選べます。各サイズはローカルキャッシュの最大 5 倍までのデータを扱えるため、ワークロードに合わせてウォームの容量を細かく最適化できます。

検索パフォーマンス

NYC Taxis ワークロードを使い、writable warm (oi2.large) と UltraWarm ノードで検索レイテンシーを比較しました。数値はすべて P90 レイテンシーです。

NYC_TAXIS ベンチマークでは、writable warm が 7 種類のクエリのうち 6 種類で、P90 において UltraWarm と同等かそれ以上の結果を出しました。軽量なフィルター、範囲検索、ソート、時系列ヒストグラム集計などが含まれます。実運用で使われる検索パターンの多くで、writable warm は UltraWarm と同等以上の性能を発揮し、しかも階層に直接書き込めます。

検索パフォーマンス: writable warm と UltraWarm の比較

どちらを選ぶか

UltraWarm から writable warm に切り替えるべきでしょうか。それはワークロード次第です。

リソースのクリーンアップ

writable warm を評価するためにテスト用ドメインを作成した場合は、料金が発生し続けないように削除してください。OpenSearch Service コンソールで対象のドメインを選び、Delete を選択します。これでドメインのすべてのノードが削除され、Amazon S3 ストレージの課金も止まります。

まとめ

本記事では、UltraWarm の読み取り専用という制約が生む手間のかかる移行サイクルを、writable warm がどうなくすのかを説明しました。1 年のリザーブドインスタンスで最大 36% のコスト削減、より高速な検索パフォーマンス、そしてよりシンプルな運用モデルが得られます。writable warm は階層間のデータ移動もなくし、ウォームストレージで初めてリザーブドインスタンス料金が使えるようになります。

writable warm には、OI2 インスタンスを備えた OpenSearch Service バージョン 3.3 以降が必要です。コールド階層のサポートが必要な場合、それより前の OpenSearch Service バージョンを使う場合、あるいは最適化されていないインスタンスファミリーを使う場合は、引き続き UltraWarm が適しています。

次のステップ: まずは現在のホットとウォームの配分を見直してみてください。ときどき発生する更新に対応するためだけに、何日分のデータをホットに置いているでしょうか。AWS Pricing Calculator で削減できる金額を試算し、テスト用ドメインで writable warm を有効にしてみましょう。数分で試せます。本記事の執筆時点では、writable warm は OpenSearch Service バージョン 3.3 でサポートされています。手順は OpenSearch Service ドキュメントの Migrating to writable warm storage を参照してください。

writable warm を試してみましたか。使ってみた感想や質問があれば、ぜひコメントで教えてください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。