# 레이턴시 영향 분석

> **범위**: VPC Lattice service/resource API와 AWS Gateway API Controller. 선택한 release와 설치 CRD를 확인합니다.
> **마지막 업데이트**: 2026년 9월 13일

## 이 문서에서 다루는 것

- Lattice 전환이 레이턴시를 악화시키는 요인과 개선시키는 요인이 **동시에** 존재하는 이유
- 어느 쪽이 이기는지는 환경에 따라 갈리며, 사전에 단정할 수 없다는 점
- 그래서 무엇을 어떻게 측정해야 답이 나오는가 — PoC 측정 매트릭스

## 먼저: 이 문서는 수치를 제시하지 않습니다

지연 변화는 워크로드마다 다릅니다. 프록시 처리·네트워크 경로·연결 재사용·서명·자격 증명 갱신·정책 평가가 모두 달라질 수 있습니다. **이 장에는 Lattice 지연 실측이 없으므로** 크기나 개선 방향을 보장하지 않습니다.

어느 쪽이 이기는지는 이런 것들에 달려 있습니다 — 현재 Envoy sidecar가 노드 CPU를 얼마나 먹고 있는지, 요청이 얼마나 짧은지(고정 오버헤드의 상대적 비중), keepalive를 쓰는지, IAM Auth를 켜는지, AZ를 넘는 비율이 얼마인지. 이 값들은 조직마다 다릅니다.

그래서 이 문서의 결론은 **"측정하라"이고, 이 문서의 본체는 "무엇을 측정해야 답이 나오는가"입니다.** 아래에서 요인들을 부호와 크기 대별로 정리한 뒤, 그 요인들을 분리해서 관측할 수 있는 측정 매트릭스를 제시합니다.

## 악화 요인

### 1. VPC 네트워크 경유가 추가된다

AS-IS에서 호출자 Envoy는 수신자 **Pod IP로 직접** 연결했습니다. 같은 노드의 Pod라면 veth 쌍만 지나고 NIC를 건드리지도 않았습니다. TO-BE에서는 목적지가 Lattice의 link-local 주소이고, 그 트래픽은 **VPC 안의 Lattice 인그레스 엔드포인트를 경유해** 최종 대상으로 갑니다.

이 차이가 가장 크게 드러나는 경우가 **같은 노드에 있던 Pod 간 통신**입니다. AS-IS에서 커널 안에서 끝났던 경로가 TO-BE에서는 노드를 나가서 Lattice를 거쳐 돌아옵니다. 참고 기준선으로, [Pod 네트워크 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/networking/06-pod-network-benchmark.md)에서 같은 노드 RTT는 0.040 ms, 같은 AZ 다른 노드는 0.339 ms, 다른 AZ는 0.544 ms였습니다. 같은 노드 최적화에 의존하고 있던 호출 경로가 있다면 그 경로가 가장 크게 영향받습니다.

### 2. SigV4 서명과 검증 오버헤드

IAM Auth를 켜면 요청마다 두 가지 연산이 추가됩니다.

- 호출 측 서명에는 canonicalization과 서명 계산이 추가됩니다. Lattice는 `UNSIGNED-PAYLOAD`를 요구하므로 일반 payload hashing을 필수 Lattice 서명 비용으로 측정하지 않습니다.
- Lattice의 검증과 활성 정책 평가도 작업을 추가합니다. 개별 연산 시간을 가정하지 말고 전체 경로를 측정합니다.

여기서 실질적인 비용은 암호 연산 자체보다 **credential 획득 경로**일 수 있습니다. 임시 credential은 설정한 provider가 캐시·갱신하며 IRSA는 STS, EKS Pod Identity는 node agent와 EKS Auth를 사용합니다. 획득이나 갱신을 기다리는 요청에는 그 지연이 포함될 수 있습니다. p50·p99 또는 더 드문 sample 중 어디에 나타날지는 갱신 빈도와 workload에 달려 있으므로 provider/cache 동작과 갱신 전후 지연 분포를 기록합니다([03번 문서](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/03-auth-flow.md) 참고).

egress proxy 방식으로 서명하는 경우에는 프록시 홉이 하나 더 늘어나는 비용도 추가됩니다.

### 3. Cross-AZ 경유 가능성

Lattice가 Target을 선택할 때 호출자와 같은 AZ의 Target을 고른다는 보장을 전제하면 안 됩니다. AS-IS에서 zone-aware routing이나 topology-aware hint로 같은 AZ에 붙이고 있었다면, 그 최적화가 유지되는지를 별도로 확인해야 합니다.

::: note 문서화된 AZ 동작
AWS는 client에 반환하는 service/resource 주소의 AZ affinity와 해당 AZ 장애 시 대안을 설명합니다. Backend target은 여러 AZ에 있을 수 있고 target-group 문서는 round-robin routing을 설명합니다. 같은 AZ backend를 보장하지는 않으므로 PoC에서 실제 target 배치를 측정합니다.

한편 **과금 관점에서는 Lattice 경유 트래픽에 별도의 inter-AZ 요금이 없습니다.** data processing 요금에 포함됩니다. 즉 Cross-AZ는 이 전환에서 **레이턴시 요인이지만 추가 과금 요인은 아닙니다.**
:::

### 4. TLS handshake 패턴의 변화

AS-IS에서 Envoy 사이의 mTLS 연결은 **길게 유지되는 connection**이었습니다. handshake 비용을 한 번 내고 그 위로 수많은 요청이 흘렀습니다.

TO-BE에서는 연결을 수립하는 지점과 빈도가 바뀝니다. 새 연결에는 수립 작업이 필요하고 TLS handshake 작업은 TLS를 사용할 때 적용됩니다. 인용한 HTTP Pod 벤치마크에서 keepalive를 끄면 p50이 같은 AZ 0.461 → 1.079 ms, 다른 AZ 0.704 → 1.517 ms로 늘었습니다. 이는 해당 설정의 연결 재사용 효과이며 TLS/Lattice 비용을 분리한 값이나 재사용 효과가 proxy hop보다 크다는 증명은 아닙니다.

전환 시 애플리케이션의 HTTP 클라이언트 설정(connection pool 크기, keepalive, idle timeout)을 반드시 점검해야 하는 이유입니다. 이것은 Lattice의 특성이 아니라 클라이언트 설정 문제인데, 프록시가 대신 연결을 관리해주던 구조가 사라지면서 드러나는 문제입니다.

## 개선 요인

### 1. 프록시 통과 횟수가 2회에서 1회로 줄어든다

AS-IS의 요청 하나는 프록시를 **두 번** 지납니다. 호출자 Pod의 Envoy에서 한 번(라우팅 결정, mTLS 개시, 메트릭 기록), 수신자 Pod의 Envoy에서 한 번(mTLS 종료, 인가 판단, 메트릭 기록). 각 통과마다 사용자 공간 프록시의 수신-처리-송신 사이클이 있습니다.

그림의 경로에서는 **고객이 관리하는 sidecar 통과 두 번**이 제거됩니다. Lattice 내부 구현·서명 프록시·네트워크 경로 변경 때문에 이것을 전체 지연 개선의 보장으로 볼 수는 없습니다.

### 2. Envoy sidecar의 CPU 경합이 해소된다

이 요인이 실무에서 가장 자주 과소평가됩니다.

Envoy sidecar는 Pod마다 하나씩 있고, 각각 노드의 CPU를 씁니다. 노드가 CPU 압박 상태이면 Envoy 프로세스가 스케줄링을 기다리게 되고, 그 대기 시간이 요청 지연에 그대로 더해집니다. 이 현상의 특징은 **평균에는 잘 안 나타나고 꼬리에 크게 나타난다**는 점입니다. 대부분의 요청은 즉시 스케줄되지만, 일부 요청이 수 밀리초에서 수십 밀리초를 기다립니다.

sidecar를 제거하면 이 경합 자체가 사라집니다. 그래서 **노드 밀도가 높고 CPU가 빡빡한 클러스터에서는 p99가 개선될 가능성이 있습니다.** 동시에 노드당 사용 가능한 CPU와 메모리가 늘어나므로 Pod 밀도를 높일 여지도 생깁니다.

### 3. 설정 수렴 경로가 달라짐

Lattice 데이터 평면은 AWS가 관리하지만 controller 조정·endpoint 등록·health check·정책 전파에는 여전히 시간이 걸립니다. AWS는 auth policy 갱신에 몇 분이 걸릴 수 있다고 명시합니다. 전파 지연이 없어진다고 가정하지 말고 수렴과 rollout을 측정합니다.

## 요인 정리 — 부호와 관측 위치

| 요인 | 부호 | 주로 나타나는 지표 | 영향이 큰 조건 |
|---|---|---|---|
| VPC 네트워크 경유 추가 | 악화 | p50, p99 모두 | 같은 노드/같은 AZ 통신 비중이 높을 때 |
| SigV4 서명·검증 | 악화 | p50 소폭, **p99** (credential 갱신) | IAM Auth 사용 시, 요청이 짧을 때 |
| Cross-AZ 경유 | 악화 | p50, p99 | AZ 인지 라우팅에 의존하고 있었을 때 |
| TLS handshake 패턴 변화 | 악화 | p50, p99 | keepalive 미사용, connection pool 미설정 |
| Sidecar 제거 | 개선 가능 | p50, p99 | 제거된 처리량·서명 경로·네트워크 구성에 따라 다름 |
| Envoy CPU 경합 해소 | **개선** | **p99** | 노드 CPU 압박이 있을 때 |
| 설정 수렴 | 측정 필요 | 변경 중 가용성·지연 | Controller·target health·정책 전파 |

이 표의 핵심은 **p50과 p99의 요인 구성이 다르다**는 점입니다. p50은 악화 요인(경로 추가)이 우세할 가능성이 높고, p99는 개선 요인(CPU 경합 해소)이 우세할 가능성이 있습니다. **평균만 보면 이 구조를 놓칩니다.**

## PoC 측정 매트릭스

위 요인들을 분리해서 관측하려면 축을 나눠 측정해야 합니다.

### 측정 축

| 축 또는 출력 | 값 | 목적과 한계 |
|---|---|---|
| **백분위** | p50, p99 | 중심·꼬리 지연을 설명하며 인과 요인 분리에는 추가 통제가 필요 |
| **AZ 배치** | 동일 AZ / Cross-AZ | 호출자·선택한 target 배치를 기록하며 설정한 경로 비교 |
| **IAM Auth** | 승인된 격리 시험에서 on/off | 서명·자격 증명·정책 평가의 결합 효과 |

AZ 배치와 auth mode는 구성 축이며 p50/p99는 각 실행의 두 출력값이지 독립 시험이 아닙니다. 조건을 맞춘 반복 실행과 가능한 실행 순서 무작위화를 사용하고 오류·처리량도 보고합니다.

### 측정 테이블 양식

| 구성 | 동일 AZ p50 | 동일 AZ p99 | Cross-AZ p50 | Cross-AZ p99 |
|---|---|---|---|---|
| AS-IS: App Mesh (기준선) | | | | |
| TO-BE: Lattice, IAM Auth **off** | | | | |
| TO-BE: Lattice, IAM Auth **on** | | | | |

Auth on/off 차이는 **해당 조건에서 서명·자격 증명 처리·활성 정책 평가가 합쳐진 효과**입니다. App Mesh/Lattice 차이에는 프록시·라우팅·TLS·기타 설정 변화가 포함됩니다. 추가 대조 없이 어느 차이도 단일 원인의 순수 비용을 나타내지 않습니다.

### 함께 기록해야 하는 조건

측정값만 기록하면 나중에 해석이 불가능합니다. 다음을 같이 남겨야 합니다.

| 항목 | 이유 |
|---|---|
| **keepalive 사용 여부와 connection pool 설정** | 앞서 봤듯 프록시 홉보다 영향이 클 수 있음. 이 값이 다르면 다른 셀과 비교 불가 |
| **요청·응답 payload 크기** | 고정 오버헤드의 상대적 비중이 달라짐. 짧은 요청에서 오버헤드가 크게 보임 |
| **부하 수준 (RPS)과 동시성** | quotas 근처에서 거동이 달라질 수 있음 |
| **노드 인스턴스 타입과 측정 중 노드 CPU 사용률** | CPU 경합 해소 효과를 해석하는 근거. AS-IS 측정 시 **Envoy 컨테이너의 CPU 사용량을 따로** 기록 |
| **AS-IS의 sidecar 리소스 request/limit** | throttling이 있었는지 판단 |
| **측정 도구와 설정** | `fortio`, `wrk2`, `k6` 등. 도구별로 백분위 계산 방식이 다름 |
| **측정 시각과 리전·AZ** | 재현 가능성 |

### 측정 설계에서 흔히 놓치는 것

**첫째, cold와 warm 조건을 별도로 기록합니다.** Credential이나 연결이 아직 캐시되지 않았다면 첫 요청에 credential 획득·연결 수립이 포함될 수 있습니다. 획득 경로는 provider에 달려 있고 TLS 수립은 TLS 연결에만 적용되므로, 모든 첫 요청이 직접 STS 호출과 TLS handshake를 하는 것은 아닙니다. 웜업 후 정상 상태를 측정하고 첫 요청 지연은 provider·cache·transport 상태와 함께 별도 기록합니다. Lambda나 스케일 아웃이 빈번한 서비스처럼 콜드 스타트가 잦은 workload에서는 둘 다 평가합니다.

**둘째, p99를 신뢰할 만큼 샘플을 모아야 합니다.** 요청 수가 적으면 p99는 노이즈입니다. 최소 수만 건 규모의 요청을 안정된 부하로 흘린 뒤의 값을 써야 합니다.

**셋째, 호출 체인 depth를 반영해야 합니다.** 단일 홉 측정은 요인을 분리하는 데 유용하지만, 실제 사용자 지연은 체인 전체의 합입니다. Lattice 홉이 하나 늘어날 때마다 오버헤드가 누적되므로, **가장 깊은 실제 호출 경로를 하나 골라 end-to-end로도 측정**해야 합니다. 이 관점은 과금과도 직결됩니다 ([06번 문서](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/06-constraints.md)).

**넷째, Lattice 구간을 직접 볼 방법이 제한적입니다.** Lattice는 trace span을 만들지 않으므로, 클라이언트 측 측정값과 Lattice access log를 대조하는 방식이 됩니다. 측정 계획에 **access log 활성화**를 반드시 포함하시기 바랍니다.

## 결론

- 이 장은 측정 설계를 제공하며 Lattice 지연 실측이나 개선 보장을 제공하지 않습니다.
- p50은 악화, p99는 개선 쪽으로 갈 가능성이 있습니다. 평균 하나로 판단하면 이 구조를 놓칩니다.
- keepalive와 connection pool 설정이 프록시 홉 변화보다 큰 영향을 줄 수 있습니다. 전환 시 클라이언트 설정 점검이 필수입니다.
- AZ/auth 구성을 조건이 같은 반복 실행으로 비교하고 실행별 p50/p99·실패·처리량을 보고합니다.

다음: [IAM 인증 절차 상세](https://www.atomai.click/kubernetes-docs/llms/ko/service-mesh/vpc-lattice/03-auth-flow.md)에서 SigV4 오버헤드의 실제 내용과 credential 의존성을 봅니다.

## 참고 자료

- [Pod 네트워크 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/networking/06-pod-network-benchmark.md) — 같은 노드/같은 AZ/다른 AZ RTT 및 keepalive 영향 실측
- [Amazon VPC Lattice 요금](https://aws.amazon.com/vpc/lattice/pricing/) — data processing에 inter-AZ 포함
- [Access logs for Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-access-logs.html)
- [Monitoring Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/monitoring-overview.html)


연결한 Pod benchmark는 별도 workload 기준선입니다. HTTP keepalive 수치는 TLS handshake나 Lattice 자체의 실측이 아닙니다.