Amazon Bedrock AgentCore Runtime V2 がリリースされたので試してみた
はじめに
Amazon Bedrock AgentCore Runtime に、新しいプラットフォームバージョン V2 が追加されました。V2 ではスナップショットから各セッションを復元するため、起動性能だけでなく、モジュールスコープで行う初期化にも影響します。
本記事では、東京リージョンで同じコンテナイメージを V1 と V2 で動かし、イメージサイズ別のコールドスタート時間を計測しました。あわせて、乱数や時刻など起動時に生成した値が、異なるセッションでどのように扱われるかを検証します。
V1 と V2 の違い
公式ブログによると、V1 は新規セッションごとにコンテナイメージを pull・展開します。一方 V2 はスナップショットから復元して起動するため、起動パスにイメージサイズが影響しません。起動が速い理由はここにあります。
検証環境
- リージョン：ap-northeast-1（東京）
- エージェント：arm64 の Flask アプリケーションをコンテナイメージにしたもの
- イメージ（いずれも圧縮後サイズ）：base（46 MB）、import 時に読み込まれないランダムデータを埋め込んで増量した pad-500m（335 MB）、pad-1g（859 MB）の 3 種類
計測方法
新規 Runtime を作成して READY 直後に invoke し、ap-northeast-1 内のクライアントで所要時間を計測しました。3 イメージ × V1/V2 の 6 Runtime を 0.5 秒ずらして並列作成しています。
CPU 情報の確認
コールドスタート時間を比較する前に、CPU 情報を確認しました。エージェントの初回 invoke で platform.machine() と /proc/cpuinfo の先頭プロセッサ情報を返すようにしています。
V2 の base、pad-500m、pad-1g で取得した値は、いずれも次のとおりでした。
| 項目 | 値 |
|---|---|
| machine | aarch64 |
| CPU implementer | 0x41 |
| CPU part | 0xd40 |
| CPU architecture | 8 |
V1 の base、pad-500m、pad-1g でも同じ値でした。
Runtime 作成時間
新規 Runtime を作成してから READY になるまでの時間です。各値は 1 回の測定です。
| イメージ | V1 Ready | V2 Ready |
|---|---|---|
| base (46MB) | 約5秒 | 約188秒 |
| pad-500m (335MB) | 約5秒 | 約188秒 |
| pad-1g (859MB) | 約5秒 | 約204秒 |
V2 は base と pad-500m で約 3 分（188 秒）、pad-1g で約 3 分半（204 秒）かかりました。
コールドスタートを V1/V2 で比較する
新規 Runtime 作成直後の初回 invoke にかかった時間です。各値は 1 回の測定です。
| イメージ | 圧縮サイズ | V1 コールドスタート | V2 コールドスタート |
|---|---|---|---|
| base | 46 MB | 3.4秒 | 2.1秒 |
| pad-500m | 335 MB | 5.5秒 | 2.2秒 |
| pad-1g | 859 MB | 13.6秒 | 1.8秒 |
V1 はイメージの pull と展開が起動パスに含まれるため、サイズが増えるほど初回応答が遅くなります。V2 はスナップショットからの復元です。import 時に読み込まれないデータで 859 MB まで膨らませたイメージでも、base と同程度の時間で応答が返りました。import 時に読み込まれる依存については、今回計測していません。
ウォーム時のレイテンシ
同一セッションで 5 回連続して invoke しました。各値は 1 回の測定です。1 回目は前節（新規 Runtime 作成直後の初回 invoke）とは別の計測です。既存 Runtime に新規セッションを作成したときの値になります。
| # | V1 | V2 |
|---|---|---|
| 1回目（既存 Runtime への新規セッション） | 0.611秒 | 1.912秒 |
| 2回目 | 0.167秒 | 0.210秒 |
| 3回目 | 0.191秒 | 0.177秒 |
| 4回目 | 0.151秒 | 0.193秒 |
| 5回目 | 0.154秒 | 0.180秒 |
1 回目は V2 が 1.912 秒、V1 が 0.611 秒で、この経路では V2 のほうが遅い結果でした。2 回目以降は、今回の base イメージでは大きな差は見られませんでした。
V2 のスナップショットで変わること
V2 は 1 つのスナップショットから各セッションのコンテナを復元します。モジュールのロード時（import 時）に実行したコードの結果は、同じスナップショットから復元されたセッション間で同一になります。つまり値はスナップショット取得時に決まります。モジュールスコープで乱数を記録するエージェントを用意し、別々のセッションから 2 回呼び出しました。
| 値 | V1 session1 | V1 session2 | 一致? | V2 session1 | V2 session2 | 一致? |
|---|---|---|---|---|---|---|
| random.random() | 0.257291 | 0.026107 | ✗ | 0.314435 | 0.314435 | ✓ |
| os.urandom(8).hex() | c80e2c1c... | 6a9f8409... | ✗ | f6e46eab... | f6e46eab... | ✓ |
OS の乱数源を使う os.urandom() でも、V2 では同じ値が返りました。これはモジュールスコープで生成した鍵・トークン・セッション ID が全セッション同一になることを意味します。乱数や認証情報の初期化はモジュールスコープに置かないでください。handler の中で実行する必要があります。
時刻も同じです。BOOT_TIME = time.time() はスナップショット取得時点の値で固定されます。そのため invoke 時刻との差は、セッション起動からの経過ではなくスナップショット取得からの経過を示します。
計測には、次のモジュールスコープのコードを使いました。
BOOT_TIME = time.time()
STARTUP_RANDOM_FLOAT = random.random()
STARTUP_RANDOM_HEX = os.urandom(8).hex()
まとめ
Amazon Bedrock AgentCore Runtime V2 では、コールドスタートが改善されていることを確認できました。イメージサイズが大きく、新規 Runtime の初回応答が課題になっている構成では、V2 を検討する価値があります。
一方、実行環境の CPU（Graviton 世代）は V1/V2 で同一でした。V2 は演算性能の向上を目的とするものではありません。また、スナップショットにはモジュールスコープで初期化した値が含まれるため、セッション固有の値や認証情報などの扱いに注意が必要です。課金も V1 から変わるため、切り替える際は自分のワークロードで十分に評価することをおすすめします。
