はじめに
こんにちは！hisanoyaです！
AWSでは12月にre:Inventがあり、盛り上がっているかと思います。Amazon OpenSearch Serviceに関してもre:Inventでは、GPU Accelerationと自動最適化ベクトルインデックスという機能が追加されました。
re:Inventが終わった後にも Amazon OpenSearch Service には重要なアップデートが追加されています。
2025年12月17日、OpenSearch Optimized Instances（OI2） を活用した 新しいマルチティアストレージ構成 が登場しました。
本記事では、このアップデートによって 何が変わったのか、何が嬉しいのか を、できるだけわかりやすく解説していきます。
それでは、どうぞ最後までお楽しみください！
OI2とは？何が新しくなった？
OI2（OpenSearch Optimized Instances）は、Amazon OpenSearch Service 専用に最適化された新しいインスタンスタイプです。前世代のOR2と同じアーキテクチャを採用しつつ、さらなるパフォーマンス向上を実現しています。
- 高いインデックス作成スループット: OR2と比較して最大9%、I8gと比較して最大33%の向上
- ハイブリッドストレージ: ローカルキャッシュ（第3世代 AWS Nitro SSD）とリモートストレージ（Amazon S3）を組み合わせ、高速アクセスと高い耐久性（99.9999999%）を両立
- Warm tierでの利用: OI2を新しくWarm tierとして利用ができ、アクセス頻度の低いデータをコスト効率よく保存することが可能
- Reserved Instanceの利用: 1年または3年契約で、オンデマンド価格と比較して大幅なコスト削減が可能
特に今回のアップデートでは、この OI2 を Warm tier に使えるようになった ことが最大のポイントになるかと思います。具体的にWarm tierで使うことにおける利点や従来との比較をしていきましょう！
従来との違いは？何が良くなった？
これまでの Warm tier（UltraWarm）
これまでの Amazon OpenSearch Service の Warm tier は、UltraWarm（UW） という仕組みで提供されていました。
UltraWarm は、
- 大量の過去データを
- Hot tier よりも安価に保持し
- 主に検索・参照用途で使う
ことを目的とした tier です。
そのため運用としては、
- 最新データは Hot tier に書き込む
- 一定期間が経過したインデックスを UltraWarm に移動
- UltraWarm にあるデータは基本的に更新しない
という使い方が一般的でした。
もし UltraWarm にあるデータを更新したい 場合は、
- 一度 Hot tier に戻す
- 更新・追記を行う
- 必要に応じて再び Warm に移す
といった手順を踏む必要があり、「Warm に置いたデータを少しだけ直したい」というケースでは、やや扱いづらい部分がありました。
新しい Warm tier：OI2で書き込み可能に
今回のアップデートにより、OI2を用いたWarm tier が 書き込み可能（Writable Warm） になりました。従来のUltraWarmは引き続き読み取り専用ですが、ウォームデータノードとしてOI2を選択することでWarm tierへの書き込みが可能になります
これによって、
- 過去データだが後から修正・追記が入るログ
- データ量が多く、Hot に置き続けるのはコスト的に厳しいデータ
- 完全な read-only にはできない長期データ
といったものを、Hot に戻さずそのまま Warm で扱える ようになります。
Warm tier が「保管専用」から、実運用で触れるデータの置き場 に進化した点が、今回のアップデートの本質です。
コスト感、RIが使える？！
今回のアップデートは、コスト面でもかなりインパクトがあります。こちらの章ではできるだけわかりやすくコスト感について説明していきますが、詳細についてはこちらをご参照ください
インスタンス価格の例（オンデマンド）
| Instance Type | 最大データ容量 | 価格（$/hour） |
|---|---|---|
| ultrawarm1.medium.search | 約1.6 TB (1.5TiB) | $0.279 |
| ultrawarm1.large.search | 約22 TB (20TiB) | $3.144 |
| oi2.large.search | 1.875 TB | $0.34272 |
| oi2.4xlarge.search | 15 TB | $2.74176 |
従来のUltraWarmでは、ultrawarm1.medium.searchとultrawarm1.large.searchの2種類のみでしたが、OI2ではlargeから8xlargeまでの幅広いサイズが選択可能です：
- oi2.large.search
- oi2.xlarge.search
- oi2.2xlarge.search
- oi2.4xlarge.search
- oi2.8xlarge.search
これにより、ワークロードの規模に応じて、より柔軟にWarm tierの容量を調整できるようになりました。
OI2はRIが使える
OI2 は Reserved Instance（RI）が利用できます。
例えば、
-
oi2.4xlarge
- 最大 15TB
- RI（1年・All Upfront）適用で $1.892 / hour
-
oi2.4xlarge
- 最大 30TB
- RI（1年・All Upfront）適用で $3.784 / hour
-
ultrawarm1.large はオンデマンドのみで $3.144 / hour
といった価格感になり、Warm tier で RI が使える という点は、長期運用では非常に大きなメリットです。
※ oi2.large は収容量がやや小さいため注意が必要
具体的なAPI操作のイメージ
今回のアップデートでは、新しい Tiering API が導入され、tier 間の移行がよりシンプルになりました。
ここでは、ドキュメントに記載されている例をもとに、新しい tiering API の中でも、特に重要なものだけを紹介します。
インデックスを Warm tier に移動
POST <index-name>/_tier/warm
インデックスを Hot tier に戻す
POST <index-name>/_tier/hot
インデックスの tier 状態を確認
GET <index-name>/_tier
レスポンス例
{
"tiering_status": {
"index": "index-name",
"state": "RUNNING_SHARD_RELOCATION",
"source": "HOT",
"target": "WARM",
"start_time": 1745836500563,
"shard_level_status": {
"running": 0,
"total": 100,
"pending": 100,
"succeeded": 0
}
}
}
これらの API を使うことで、
- 今どの tier にあるのか
- Hot ↔ Warm の移動が進行中か
といった状態を確認・制御できます。
実際の運用では、これらの操作を手動で行うというよりも、
「一定期間経過したら Warm に移す」といったルールを
Index State Management（ISM）で自動化するケースが多くなりそうです。
マネージメントコンソール上での設定方法
OI2をWarm tierとして利用するには、以下の手順で設定します。
1. データノードでOpenSearch最適化インスタンスを選択
まず、データノードのインスタンスファミリーで「OpenSearch 最適化」を選択します。
OpenSearch最適化インスタンスを選択すると、OR1、OR2、OM2、OI2のいずれかのインスタンスタイプが利用可能になります。この設定により、Warm tierでOI2インスタンスが選択できるようになります。
│ 重要: OpenSearch最適化インスタンスを選択しない場合、Warm tierでOI2を利用することができない。
2. Warm tierを有効化してOI2を選択
データノードの設定後、「ウォームデータストレージとコールドデータストレージ」セクションで、Warm tierを有効化します。
インスタンスタイプのドロップダウンに、oi2とultrawarm1の選択肢が表示されます。ここでOI2を選択します。
3. OI2の容量を確認
OI2を選択すると、以下の情報が表示されます。
- Cache size per node: ローカルキャッシュのサイズ（例：750 GB）
- Addressable warm storage per node: アクセス可能なWarmストレージ容量（例：3,750 GB）
Addressable warm storageは、Cache sizeの約5倍の容量となっており、S3ベースのストレージを活用した効率的なデータ管理が可能です。
│ 注意: 現時点では、OI2インスタンスではCold storageがサポートされていないので注意
注意点（導入前に押さえておきたいポイント）
様々な利点などを書いていきましたが、注意点もございますので導入前に再度ご確認ください。
- 新しいマルチティア構成はOpenSearch 3.3以降が必須
- Warm tier は OI2 インスタンスが必須
- Cold tier（より安価なアーカイブ層）はサポートされない
- Warm tier では一部のインデックス操作が利用不可
- 暗号化・HTTPS強制などのセキュリティ設定が必須
Warm に書き込みたい場合には非常に強力ですが、要件によっては従来の UltraWarm 構成の方が適するケースもあります。
まとめ
今回のアップデートは、Amazon OpenSearch Service におけるWarm tier の考え方そのものを変える 内容でした。公式ドキュメントはこちらをご参照ください
- OI2 の登場でインスタンス選択肢が拡張
- Warm tier が書き込み可能になり、運用の自由度が向上
- RI対応により、長期運用時のコスト最適化が可能
- ただし、設計上の注意点もあるため要件整理は重要
これまで「HotかWarmか」で悩んでいたデータ設計に、現実的で使いやすい新しい選択肢が加わったアップデートだと思います。ぜひ使ってみてください！
この Publication に投稿している記事は、アマゾン ウェブ サービス ジャパン合同会社または Amazon Web Services, Inc. 所属社員による個人の見解であり、所属する組織の公式見解ではありません。参加したい従業員の方は、Sugiyama Suguru までお知らせください。
Discussion