ElastiCache Serverless の新機能「パブリックエンドポイント」のスループットを計測してみた
はじめに
2026-09-29 に、ElastiCache for Valkey Serverless がパブリックエンドポイントに対応しました。これまで VPC 内からしか接続できなかった Serverless キャッシュへ、VPC 外の Lambda などから接続が可能になりました。
どの程度の性能・スループットで Valkey を利用できるか確認するため、同じリージョンの EC2 からパブリックエンドポイントへ接続し、VPC 内の Serverless やノードベースのクラスターとレイテンシを比べます。
検証環境
クライアントは ap-northeast-1 の EC2（c8g.xlarge）で、valkey-glide 2.5.3（Python）の GlideClusterClient を使いました。接続先はすべて Valkey 9.0・クラスターモード有効で、次の 7 構成を用意しました。
| 構成 | 種別 | ノードタイプ | 経路 | TLS | 認証 |
|---|---|---|---|---|---|
| N1 | ノードベース | cache.t4g.small | VPC 直接 | なし | なし |
| N2 | ノードベース | cache.t4g.small | VPC 直接 | あり | なし |
| N3 | ノードベース | cache.m8g.large | VPC 直接 | なし | なし |
| N4 | ノードベース | cache.m8g.large | VPC 直接 | あり | なし |
| SV1 | Serverless | — | VPC 内（PrivateLink） | TLS 1.3 | なし |
| SV2 | Serverless | — | VPC 内（PrivateLink） | TLS 1.3 | IAM |
| SP1 | Serverless | — | パブリック（IGW） | TLS 1.3 | IAM |
パブリックエンドポイントを使うのは SP1 だけです。SV2 は TLS と IAM 認証の条件が SP1 と同じで経路だけが VPC 内なので、経路の差を見る比較相手になります。N1〜N4 はノードベースのクラスターで、ノードタイプと TLS の有無による違いを見るためのものです。
測定方法
各構成に対し、GET と SET を半々に発行する 2 つのモードで測りました。
- プールあり: 4 並列プロセスがそれぞれ 1 接続を持ち、20 秒間使い回す
- 都度接続: 1 操作ごとにクライアントを作成し、操作後に閉じる
この記事で「コネクションプール」と呼ぶのは前者の方式で、作成した接続を閉じずに使い回すことを指します。複数の接続を貸し出す本格的なプール実装ではありません。
ベンチマークの接続部分は次のとおりです。IAM 認証は ServerCredentials に IamAuthConfig を渡して設定します。t はエンドポイント、ポート、TLS の有無、IAM ユーザー名、キャッシュ名を持つ接続先の設定です。
def make_config(t):
creds = None
if t.get("iam"):
creds = ServerCredentials(
username=t["iam_user"],
iam_config=IamAuthConfig(
cluster_name=t["iam_cluster_name"],
service=ServiceType.ELASTICACHE,
region=REGION,
),
)
return GlideClusterClientConfiguration(
addresses=[NodeAddress(t["host"], t["port"])],
use_tls=t["tls"],
credentials=creds,
request_timeout=5000,
)
プールありはクライアントを 1 回だけ作成してループ内で使い回し、都度接続は操作ごとに作成と破棄を繰り返します。
if mode == "pool":
client = await GlideClusterClient.create(cfg)
if mode == "pool":
op = await one_op(client, rnd)
else:
c = await GlideClusterClient.create(cfg)
try:
op = await one_op(c, rnd)
finally:
await c.close()
パブリックエンドポイントを使うには、次の条件があります。
- Valkey 9.0 以降
- IAM 認証と TLS 1.3 が必須
- ConnectionType は作成時に決め、後から変更できない
- ユーザーグループのすべてのユーザーが IAM 認証であること
SP1 はこの条件を満たすよう、次のコマンドで作成しました。--connection-type は AWS CLI 2.37.6 以降で使えます（2.37.5 では未対応でした）。
パブリックエンドポイント付き Serverless キャッシュの作成コマンド
aws elasticache create-serverless-cache \
--region ap-northeast-1 \
--serverless-cache-name <CACHE_NAME> \
--engine valkey \
--major-engine-version 9 \
--cache-usage-limits 'DataStorage={Maximum=1,Unit=GB},ECPUPerSecond={Maximum=30000}' \
--user-group-id <IAM_USER_GROUP_ID> \
--connection-type public
<IAM_USER_GROUP_ID> には、すべてのユーザーが IAM 認証であるユーザーグループを指定します。
測定結果を読むうえでの制約は次の 2 点です。
- クライアントは AWS 内（同一リージョンの EC2）です。AWS 外からの接続は経路が長くなるため、ここでの数値より遅くなりえます。
- パブリックエンドポイントはクライアントと同じ AZ への接続が保証されません。今回の測定でクライアントと接続先の AZ が同じだったかは確認していないため、AZ をまたぐ環境では RTT が今回より大きくなる可能性があります。
測定結果
各構成・モードを 3 回ずつ実行しました。p50・p99・ops/s は 3 回の中央値、範囲は 3 回の最小〜最大、試行とエラーは 3 回の合計です。
プールありの結果です。エラーはどの構成でも 0 件でした。
| 構成 | p50 (µs) | p50 範囲 | p99 (µs) | p99 範囲 | ops/s | 試行 |
|---|---|---|---|---|---|---|
| N1 | 259 | 257–264 | 544 | 519–568 | 14,128 | 843,588 |
| N2 | 269 | 269–269 | 503 | 472–1,161 | 13,912 | 789,359 |
| N3 | 151 | 150–153 | 273 | 264–295 | 24,506 | 1,469,488 |
| N4 | 148 | 148–151 | 274 | 274–312 | 25,073 | 1,480,875 |
| SV1 | 474 | 451–550 | 793 | 735–798 | 7,940 | 468,205 |
| SV2 | 476 | 474–516 | 719 | 670–729 | 8,310 | 482,434 |
| SP1 | 549 | 411–571 | 3,827 | 3,744–3,833 | 2,624 | 168,359 |
都度接続の結果です。
| 構成 | p50 (µs) | p50 範囲 | p99 (µs) | p99 範囲 | ops/s | エラー / 試行 |
|---|---|---|---|---|---|---|
| N1 | 4,391 | 4,302–4,692 | 10,043 | 8,174–10,633 | 360 | 26 / 21,957 |
| N2 | 20,844 | 20,838–20,869 | 29,092 | 28,540–42,314 | 189 | 0 / 11,235 |
| N3 | 2,002 | 1,848–2,021 | 4,092 | 3,690–5,643 | 140 | 48 / 9,247 |
| N4 | 8,661 | 8,513–8,695 | 13,286 | 12,991–14,456 | 87 | 36 / 5,277 |
| SV1 | 13,170 | 13,100–13,364 | 20,596 | 20,106–5,011,883 | 50 | 20 / 2,757 |
| SV2 | 23,430 | 23,027–28,184 | 1,128,621 | 1,123,318–1,133,108 | 40 | 16 / 2,358 |
| SP1 | 111,719 | 109,367–126,695 | 1,052,986 | 995,786–1,158,488 | 18 | 0 / 1,129 |
都度接続のエラーは ClosingError: connection attempt timed out と RequestError: Connection in recovery で、エラー率はどの実行でも 1% 未満です。値には request_timeout（5,000 ms）でタイムアウトした操作の計測値も含まれています。ops/s はプールありの 1/39（N1）〜1/288（N4）に落ち、SP1 は 1/146 でした。
パブリックエンドポイントと VPC 内 Serverless の比較
SP1 と、認証条件が同じで経路だけが VPC 内の SV2 を、プールありの値で比べます。
| 指標 | SV2（VPC 内） | SP1（パブリック） | SP1 ÷ SV2 |
|---|---|---|---|
| p50 (µs) | 476 | 549 | 1.15 倍 |
| p99 (µs) | 719 | 3,827 | 5.32 倍 |
| ops/s | 8,310 | 2,624 | 0.32 倍 |
p50 はほぼ並びました。p99 では SP1 が 3 回とも約 3.8 ms と SV2 の約 5 倍で、この遅い操作に接続が占有される分、ops/s は約 1/3 に下がっています。
なお、SP1 で接続を使い回さない場合の p50 は 111,719 µs で、プールありの 203.5 倍でした。
接続確立にかかる時間の内訳
都度接続でどこに時間がかかるかを見るため、接続の各フェーズを順に計時するスクリプト（probe.py）で、1 プロセスから 200 回ずつ接続しました。値は中央値です。
| 構成 | DNS (µs) | TCP (µs) | TLS (µs) | AUTH (µs) | CLUSTER SLOTS (µs) | GET (µs) | 合計 (µs) |
|---|---|---|---|---|---|---|---|
| N1 | 164 | 256 | 0 | 0 | 354 | 223 | 1,014 |
| N2 | 411 | 284 | 6,968 | 0 | 373 | 245 | 8,405 |
| N3 | 162 | 120 | 0 | 0 | 188 | 125 | 587 |
| N4 | 406 | 134 | 5,417 | 0 | 190 | 115 | 6,274 |
| SV2 | 449 | 1,224 | 6,081 | 6,124 | 334 | 505 | 15,116 |
| SP1 | 461 | 2,496 | 7,507 | 5,463 | 1,929 | 3,620 | 21,736 |
接続確立の時間を占めるのは TLS ハンドシェイクと IAM の AUTH です。TLS ありの構成では TLS に 5〜7.5 ms、IAM 認証ありの SV2・SP1 ではさらに AUTH に 5〜6 ms かかりました。両方が必須の SP1 は合計約 22 ms で、そのうち約 13 ms がこの 2 つです。TLS も認証もない N1・N3 の接続確立は 1 ms 以下でした。接続を使い回せば、このコストを払うのは最初の 1 回だけです。
まとめ
今回の測定では、同一リージョンの EC2 から ElastiCache for Valkey Serverless を利用する場合、接続を使い回せば、パブリックエンドポイントでも同一 VPC と同等のレイテンシで、スループットの低下も少ないことが確認できました（SP1: 2,624 ops/s、SV2: 8,310 ops/s）。Lambda のペイロードなどで Valkey の接続を使い回せる場合には、VPC Lambda を採用しなくても十分な性能で利用できる可能性があります。
一方、都度接続で 1 操作ごとに TLS と IAM 認証をやり直す使い方では、レイテンシとスループットが低下します。VPC 内 Serverless（SV2）の都度接続が 40 ops/s であるのに対し、パブリックエンドポイント（SP1）は 18 ops/s でした。
都度接続を改善できないワークロードで Valkey Serverless のパブリックエンドポイントを採用する場合は、必要な性能が出るか事前に十分評価することをおすすめします。評価の結果によっては、同一 VPC 内での利用や、IAM 認証を省いたプロビジョニング済みの Valkey を同一 VPC 内に置き、セキュリティグループでアクセスを制御する構成もご検討ください。
