はじめに
Amazon OpenSearch Serverlessは名前のとおりサーバーレスに使える検索基盤ですが、これまでは「Serverlessとはいいつつ、コンピューティングは常時課金」という印象が強いサービスでした。
特に個人開発やステージング環境のように、普段はほとんどアクセスがないのに、たまに検索やRAGの検証をしたいだけの用途だと、この常時課金が地味に痛いです。
2026年5月、OpenSearch ServerlessにNextGenアーキテクチャが登場し、ついにscale to zeroが可能になりました。
これはかなり大きいアップデートです。
なぜなら「使っていないときは0課金に近づける」という、ようやく名前どおりのサーバーレスらしい使い方ができるようになったからです。
本記事では、実際にscale to zeroを検証してみて、
- 本当に0まで落ちるのか
- コールドスタートはどれくらい発生するのか
- 実運用ではどう考えるべきか
を整理します。
NextGenアーキテクチャとは
AWSの発表では、NextGenアーキテクチャはOpenSearch Serverlessをエージェント時代向けに作り直した新しい基盤とされています。
いくつかの改善点がありますが、今回特に大きいと感じたのは次の2つです。
- scale to zeroによる真のサーバーレス課金
- 秒単位のオートスケーリングによるトラフィック急増への追従
参考：次世代のAmazon OpenSearch Serverless: エージェント向けにゼロから構築｜Amazon Web Servicesブログ
従来アーキテクチャとNextGenの違いをざっくりまとめると、次のようなイメージです。
- 従来：使っていなくても最低限のOCU（OpenSearch Compute Units）を持ち続ける
- NextGen：一定時間リクエストがなければコンピュートを解放して0まで落とせる
加えて、NextGenではOCUのスケーリング速度そのものも改善されています。
AWSの説明では、インデックス作成や検索の負荷に応じてOCUを秒単位で追加でき、以前のアーキテクチャと比べて最大20倍のスケール速度をうたっています。
これは単なるコスト改善だけではなく、
- 急なアクセス増加でもレスポンスを落としにくい
- 必要なときにすばやく増やし、不要になればすばやく減らす
という性能面の改善でもあります。
今回の検証では、AWSコンソールでCollection TypeとしてNextGenを選んでコレクションを作成しました。
また、コンソールからNextGenで作成したコレクションでは、後述する0 OCUとコールドスタートを確認できました。
何がうれしいのか
scale to zeroがうれしいのは、本番の高トラフィック用途というより、次のような「たまにしか使わない」環境です。
- 検証用のRAGベクトルストア
- ステージング環境の検索API
- 社内向けツール
- 個人開発の検索機能
こうした用途では、
- 使う頻度は低い
- でも完全に止めると毎回作り直しが面倒
- 常時課金は避けたい
ということがよくあります。
従来のOpenSearch Serverlessはこのユースケースと相性がよくありませんでした。
一方でNextGenは、まさにこの隙間にハマる機能だと感じました。
さらに、NextGenの価値はそれだけではありません。
秒単位のオートスケーリングが強化されたことで、利用頻度が低い環境だけでなく、アクセスの波が大きいワークロードにも向いています。
たとえば、
- 日中だけ急に検索トラフィックが増える業務システム
- イベント時だけアクセスが跳ねるアプリ
- エージェント実行のたびに検索負荷が偏るRAG基盤
のようなケースでは、常時大きめに張っておくよりも、必要なときだけ素早く伸びる基盤の方が相性が良い場面があります。
実験してみた
今回の検証環境は以下です。
- リージョン：
ap-northeast-1 - コレクション種別：
SEARCH - アーキテクチャ：
NextGen - 作成方法：AWSコンソール
Express createというサクッとcollectionを作る機能も一緒に追加されており今回それを利用しました。
まず、コレクションにテスト用のインデックスとドキュメントを投入しました。
その後、検索クエリを実行してwarm状態を作り、一定時間アクセスを止めたあと、再度検索してレイテンシーを計測しています。
検索に使ったPythonはだいたいこんな感じです。
import boto3
from opensearchpy import OpenSearch, RequestsHttpConnection, AWSV4SignerAuth
host = "****.aoss.ap-northeast-1.on.aws"
region = "ap-northeast-1"
auth = AWSV4SignerAuth(boto3.Session().get_credentials(), region, "aoss")
client = OpenSearch(
hosts=[{"host": host, "port": 443}],
http_auth=auth,
use_ssl=True,
verify_certs=True,
connection_class=RequestsHttpConnection,
timeout=120,
)
resp = client.search(
index="console-cold-start-demo",
body={
"query": {
"match": {
"title": "cold start"
}
},
"size": 5
}
)
SigV4署名が必要なので、素直にopensearch-pyを使うのが楽でした。
また、CloudWatchのAWS/AOSSメトリクスも合わせて確認しました。
SearchOCUIndexingOCU
これをcollection group単位で見ることで、実際に0 OCUまで落ちているかを確認できます。
コールドスタートはどれくらい発生するか？
結論から書くと、NextGenのscale to zero自体は確認できました。
ただし、コールドスタートはしっかり発生します。
今回の実測では次のようになりました。
- warm search 1回目：
0.136s - warm search 2回目：
0.130s - 約620秒アイドル後の1回目：
11.2s - 直後の2回目：
0.169s
つまり、
- アイドル前後の通常時はサブ秒
- コールド状態からの復帰時だけ10秒台
という挙動でした。
さらにCloudWatchメトリクスでは、同じ時間帯に以下のような変化を確認できました。
- アイドル時：
SearchOCU = 0,IndexingOCU = 0 - リクエスト再開後：
SearchOCU = 2,IndexingOCU = 1 - 再度アイドル後：再び
0
この結果から、
- NextGenでは実際に0まで落ちる
- その代わり最初の1クエリに約10秒の復帰コストがかかる
というトレードオフがかなり明確に見えました。
なお、コールド状態へ入るまでの無通信時間は、今回の観測では約620秒で再現できました。
公式にもidle timeout windowは10分と記載されています。少なくとも公開APIやCLIを見る限り、この時間自体をユーザーが変更する設定は見当たりませんでした。
使いどころはどこか
正直にいうと、検索が主役の本番Webアプリにはそのままでは使いにくいです。
初回検索に10秒以上かかると、
- 検索UI
- チャットUIのRAG
- 商品検索
- 管理画面の一覧検索
のような体験ではかなり厳しいです。
もし本番アプリで使うなら、例えば次のような工夫が必要になります。
- 営業時間中はkeep warmする
- 初回アクセス時にバックグラウンドでwarmupクエリを投げる
- 夜間だけscale to zeroを許可する
一方で、次の用途にはかなり相性が良いと感じました。
- ステージング環境
- 低頻度アクセスの社内ツール
- 個人開発
- 月に数回だけ触る検証基盤
これまでは「使っていなくてもなんだかんだで常時課金される」せいでOpenSearch Serverlessを置きづらかったケースでも、NextGenならかなり選択肢に入りやすくなります。
さいごに
OpenSearch ServerlessのNextGenアーキテクチャは、ようやく「真のサーバーレス」に近づいたアップデートだと感じました。
実験してみた結果はシンプルです。
- scale to zeroは本当に動く
- 0 OCUまで落ちることも確認できる
- ただし復帰時には約10秒のコールドスタートがある
このため、常時低レイテンシーが必要な検索基盤として見ると厳しい一方、低頻度利用の環境ではかなり魅力的です。
個人的には、特にステージング環境や個人開発での価値が大きいと感じました。
「たまにしか使わないのにOpenSearchを置いておきたい」というケースでは、ようやく本命になりそうです。
