レイテンシへの影響分析
対象範囲: VPC Lattice のサービス／リソース API と AWS Gateway API Controller。選択したリリースとインストール済み CRD を確認してください。 最終更新日: 2026年9月13日
このドキュメントで扱う内容
- Lattice への移行で、レイテンシを悪化させる要因と改善させる要因が同時に加わる理由
- どちらが優勢になるかは環境によって異なり、事前には予測できない理由
- PoC 測定マトリクスで何をどのように測り、答えを得るか
はじめに: このドキュメントは数値を提示しない
レイテンシへの影響は、ワークロードによって異なります。プロキシ処理、ネットワーク経路、接続の再利用、署名、認証情報の更新、ポリシー評価によって変化します。この章では Lattice のレイテンシ測定値を提示していません。したがって、影響の大きさや、必ず増加／減少するという方向性も断定しません。
どちらが優勢になるかは、現在 Envoy サイドカーが消費しているノード CPU の量、リクエストの短さ（固定オーバーヘッドの相対的な比重）、keepalive の使用有無、IAM Auth の有効化、AZ をまたぐ呼び出しの割合などで変わります。これらの値は組織ごとに異なります。
つまり、このドキュメントの結論は「測定すること」であり、本文では「答えを得るために何を測定すべきか」を説明します。以下では要因を影響の符号と大きさで整理し、続いて各要因を切り分ける測定マトリクスを示します。
悪化させる要因
1. VPC ネットワークを通る経路が追加される
現状（AS-IS）では、呼び出し元の Envoy が受信側の Pod IP に直接接続していました。同じノード上の Pod であれば、veth ペアから外に出ず、NIC にも触れません。移行後（TO-BE）は、宛先が Lattice の link-local アドレスとなり、最終ターゲットに届く前にトラフィックがVPC 内の Lattice ingress エンドポイントを通ります。
この違いが最も大きいのは、以前は同一ノード内で完結していたPod 間通信です。AS-IS ではカーネル内で完了していた経路が、移行後はノードを出て Lattice を通過し、再び戻ります。比較の基準として、Pod ネットワークベンチマークでは、同一ノード RTT は0.040 ms、同一 AZ の別ノード間は0.339 ms、AZ 間は0.544 ms でした。同一ノード内の局所性に依存していた呼び出し経路があれば、その経路が最も大きく影響を受けます。
2. SigV4 の署名と検証のオーバーヘッド
IAM Auth を有効にすると、リクエストごとに2つの処理が追加されます。
- 呼び出し元側の署名で正規化と署名計算が追加されます。Lattice では
UNSIGNED-PAYLOADが必要です。一般的なペイロードのハッシュ計算を、Lattice 署名に必須の処理としてベンチマークしないでください。 - Lattice 側での検証と、有効化したポリシーの評価にも処理が加わります。操作ごとの所要時間を推定するのではなく、経路全体を測定してください。
実際のコストは、暗号処理自体よりも認証情報を取得する経路にある場合があります。一時的な認証情報では、設定済みのプロバイダーがキャッシュし、更新します。IRSA は STS を使い、EKS Pod Identity はノードエージェントと EKS Auth を使います。取得や更新を待つリクエストには、そのレイテンシが加わる可能性があります。p50、p99、さらに稀な値のどこに影響するかは、更新頻度とワークロードによって異なります。プロバイダー／キャッシュの動作と、更新前後のレイテンシ分布を記録してください（ドキュメント03を参照）。
送信プロキシ経由で署名する場合は、プロキシホップがもう1つ増えるコストも加わります。
3. AZ をまたぐ可能性
Lattice が呼び出し元と同じ AZ のターゲットを選択すると決めつけないでください。AS-IS で AZ 対応ルーティングやトポロジー対応ヒントを使って AZ 内にトラフィックを固定していた場合、その最適化が移行後も維持されるかを別途確認してください。
::: note 文書化されている AZ の動作 AWS の説明では、クライアントに返すサービス／リソースアドレスに AZ アフィニティが適用され、その AZ が利用できない場合は代替が使われます。バックエンドのターゲットは引き続き AZ 間に分散される場合があり、ターゲットグループのドキュメントではラウンドロビン方式のルーティングが説明されています。同一 AZ のバックエンドが保証されるわけではありません。PoC で実際のターゲット配置を測定してください。
これとは別に、請求上、Lattice 経由のトラフィックには AZ 間の追加料金がありません。 データ処理料金に含まれます。したがって、この移行では AZ 間通信はレイテンシ要因ですが、追加の課金要因ではありません。 :::
4. TLS ハンドシェイクのパターンが変わる
AS-IS では、Envoy 間の mTLS 接続は長時間維持される接続でした。ハンドシェイクのコストは一度だけで、その接続を通して多数のリクエストが流れます。
TO-BE では、接続の確立場所と頻度が変わります。新しい接続ではセットアップ処理が必要になり、TLS を使う場合には TLS ハンドシェイク処理も発生します。引用した HTTP Pod ベンチマークでは、keepalive を無効にすると p50 が同一 AZ で0.461 msから1.079 ms、AZ 間で0.704 msから1.517 msに上がりました。この測定が示すのは、その構成における接続再利用の効果です。TLS／Lattice 単独のコストを切り分けた測定でも、プロキシホップより接続再利用の方が重要だという証明でもありません。
そのため、移行時にアプリケーションの HTTP クライアント設定（接続プールのサイズ、keepalive、アイドルタイムアウト）を監査する必要があります。これは Lattice の特性ではなく、接続を管理していたプロキシがなくなったときに表面化するクライアント設定の問題です。
改善する要因
1. プロキシを通る回数が2回から1回に減る
AS-IS では、1つのリクエストがプロキシを2回通ります。呼び出し元側の Envoy では、ルーティング判断、mTLS の開始、メトリクス処理が行われます。受信側の Envoy では、mTLS の終端、認可、メトリクス処理が行われます。いずれもユーザー空間で受信、処理、送信を行う一連の処理です。
例示した経路では、顧客が管理するサイドカーを通る処理が2回なくなります。ただし、Lattice の内部実装、署名プロキシ、ネットワーク経路の変化があるため、これをエンドツーエンドレイテンシの確実な低下として扱うことはできません。
2. Envoy サイドカーとの CPU 競合がなくなる
実務上、最も過小評価されやすい要因です。
各 Pod には Envoy サイドカーがあり、それぞれノード CPU を消費します。ノードが CPU 圧迫状態にあると、Envoy プロセスがスケジュールされるまで待ち、その待ち時間がリクエストのレイテンシに直接加わります。この現象の特徴は、平均値にはほとんど現れず、テールで顕著になることです。多くのリクエストはすぐにスケジュールされますが、一部では数ミリ秒から数十ミリ秒待つことがあります。
サイドカーを削除すれば、その競合自体がなくなります。そのため、Pod 密度が高く CPU リソースに余裕がないクラスターでは、p99 が改善する可能性があります。 同時に、各ノードで利用可能な CPU とメモリが増え、Pod 密度を上げる余地が生まれます。
3. 設定の収束が変わる
Lattice のデータプレーンは AWS が管理しますが、コントローラーによる調整、エンドポイントの登録、ヘルスチェック、ポリシーの伝播には引き続き時間がかかります。AWS は、認証ポリシーの更新に数分かかる場合があると説明しています。伝播遅延がなくなると想定するのではなく、収束とロールアウト時の動作を測定してください。
要因のまとめ: 影響の符号と現れる場所
| 要因 | 影響 | 現れるメトリクス | 影響が大きくなる条件 |
|---|---|---|---|
| VPC ネットワーク経路の追加 | 悪化 | p50 と p99 の両方 | 同一ノード／同一 AZ のトラフィックが多い |
| SigV4 の署名／検証 | 悪化 | p50 では軽度、p99（認証情報の更新時） | IAM Auth が有効、リクエストが短い |
| AZ 間通信 | 悪化 | p50、p99 | AZ 対応ルーティングに依存していた |
| TLS ハンドシェイクのパターン変化 | 悪化 | p50、p99 | keepalive なし、接続プールが未調整 |
| サイドカーの削除 | 改善の可能性 | p50、p99 | 削除される処理、署名経路、ネットワークトポロジーによる |
| Envoy の CPU 競合解消 | 改善 | p99 | ノードに CPU 圧迫がある |
| 設定の収束 | 測定が必要 | 変更中の可用性／レイテンシ | コントローラー、ターゲットヘルス、ポリシーの伝播 |
この表の要点は、p50 と p99 では要因の組み合わせが異なることです。悪化要因（経路追加）は p50 に強く現れる可能性があります。改善要因（CPU 競合の解消）は p99 に強く現れる可能性があります。平均値だけを見ると、この構造が隠れます。
PoC 測定マトリクス
各要因を個別に観測するため、測定軸を分けてください。
測定軸
| 軸または出力 | 値 | 目的と制約 |
|---|---|---|
| パーセンタイル | p50、p99 | 中央とテールのレイテンシを表す。因果の特定には追加の制御が必要 |
| AZ 配置 | 同一 AZ／AZ 間 | 呼び出し元と選択されたターゲットの配置を記録しながら、設定した経路を比較する |
| IAM Auth | 承認済みの隔離テストで有効／無効 | 署名、認証情報、ポリシー評価を合わせた影響 |
AZ 配置と認証モードは設定の軸です。p50／p99 はそれぞれの実行から得られる2つの出力であり、独立した試行ではありません。条件を揃えて繰り返し実行し、可能なら順序を無作為化してください。レイテンシだけでなく、エラーとスループットも報告します。
測定表のテンプレート
| 構成 | 同一 AZ p50 | 同一 AZ p99 | AZ 間 p50 | AZ 間 p99 |
|---|---|---|---|---|
| AS-IS: App Mesh（ベースライン） | ||||
| TO-BE: Lattice、IAM Auth 無効 | ||||
| TO-BE: Lattice、IAM Auth 有効 |
認証の有効／無効による差分は、その条件における署名、認証情報処理、有効化されたポリシー評価の複合的な影響です。App Mesh／Lattice の差分には、プロキシ、ルーティング、TLS、その他の設定変更が含まれます。どちらの差分も、追加の制御なしに純粋な因果要因を特定するものではありません。
あわせて記録する条件
数値だけを記録すると、後で解釈できなくなります。次の項目も記録してください。
| 項目 | 理由 |
|---|---|
| keepalive の使用と接続プールの設定 | 例にあるように、プロキシホップの変更より影響する場合がある。測定区間間で異なれば比較できない |
| リクエスト／レスポンスのペイロードサイズ | 固定オーバーヘッドの相対的な比重が変わる。短いリクエストではオーバーヘッドが大きく見える |
| 負荷レベル（RPS）と同時実行数 | クォータ付近で動作が変わる場合がある |
| ノードのインスタンスタイプと実行中のノード CPU 使用率 | CPU 競合の影響を解釈する根拠。AS-IS の実行ではEnvoy コンテナの CPU 使用率を別途記録する |
| AS-IS のサイドカーのリソース requests／limits | スロットリングが発生していたかを確認する |
| 測定ツールと設定 | fortio、wrk2、k6 など。パーセンタイルの計算はツールによって異なる |
| タイムスタンプ、リージョン、AZ | 再現性 |
測定設計で見落としやすい点
まず、コールド状態とウォーム状態を分けて記録します。 認証情報や接続がまだキャッシュされていない場合、最初のリクエストには認証情報の取得と接続確立が含まれることがあります。取得経路はプロバイダーによって異なります。また、TLS のセットアップは TLS 接続に限られます。毎回の初回リクエストで直接 STS を呼び出したり、TLS ハンドシェイクを行ったりするわけではありません。ウォームアップ後の定常状態を測定し、初回リクエストのレイテンシも、プロバイダー、キャッシュ、トランスポートの状態とあわせて記録してください。Lambda や頻繁にスケールアウトするサービスなど、コールドスタートが多いワークロードでは両方を評価します。
次に、p99 を意味のある値にするための十分なサンプルを集めます。 リクエスト数が少ない場合、p99 はノイズになります。安定した負荷の下で、数万件のリクエストを経た値を使ってください。
3つ目に、呼び出しチェーンの深さを考慮します。 単一ホップの測定は要因を切り分けるのに有用ですが、実際のユーザーレイテンシはチェーン全体の合計です。Lattice のホップが追加されるたびにオーバーヘッドは累積するため、実際の最も深い呼び出し経路を選び、エンドツーエンドでも測定してください。 この観点は請求にも直接関係します（ドキュメント06）。
4つ目に、Lattice のホップを直接観測する手段には限界があります。 Lattice はトレーススパンを作成しないため、クライアント側の測定値を Lattice のアクセスログと関連付けます。アクセスログの有効化を測定計画に含めてください。
結論
- この章が示すのは測定の設計であり、実測された Lattice のレイテンシでも、改善の保証でもありません。
- p50 が悪化し、p99 が改善する場合があります。単一の平均値で判断すると、この構造を見落とします。
- keepalive と接続プールの設定は、プロキシホップの変更より大きく影響する場合があります。移行時にはクライアント設定の監査が必須です。
- AZ／認証の各構成を、条件を揃えた反復実行で比較してください。各実行の p50／p99、失敗、スループットを報告します。
次の詳細な IAM 認証フローでは、SigV4 のオーバーヘッドの内訳と、その背後にある認証情報の依存関係を説明します。
参考資料
- Pod ネットワークベンチマーク: 同一ノード／同一 AZ／AZ 間の RTT と keepalive の影響を測定
- Amazon VPC Lattice の料金: AZ 間通信はデータ処理に含まれる
- Amazon VPC Lattice のアクセスログ
- Amazon VPC Lattice のモニタリング
リンク先の Pod ベンチマークは、別のワークロードにおけるベースラインです。そこにある HTTP keepalive の数値は、TLS ハンドシェイクや Lattice 自体の測定値ではありません。