레이턴시 영향 분석
범위: 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 네트워크 실측 벤치마크에서 같은 노드 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번 문서 참고).
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번 문서).
넷째, Lattice 구간을 직접 볼 방법이 제한적입니다. Lattice는 trace span을 만들지 않으므로, 클라이언트 측 측정값과 Lattice access log를 대조하는 방식이 됩니다. 측정 계획에 access log 활성화를 반드시 포함하시기 바랍니다.
결론
- 이 장은 측정 설계를 제공하며 Lattice 지연 실측이나 개선 보장을 제공하지 않습니다.
- p50은 악화, p99는 개선 쪽으로 갈 가능성이 있습니다. 평균 하나로 판단하면 이 구조를 놓칩니다.
- keepalive와 connection pool 설정이 프록시 홉 변화보다 큰 영향을 줄 수 있습니다. 전환 시 클라이언트 설정 점검이 필수입니다.
- AZ/auth 구성을 조건이 같은 반복 실행으로 비교하고 실행별 p50/p99·실패·처리량을 보고합니다.
다음: IAM 인증 절차 상세에서 SigV4 오버헤드의 실제 내용과 credential 의존성을 봅니다.
참고 자료
- Pod 네트워크 실측 벤치마크 — 같은 노드/같은 AZ/다른 AZ RTT 및 keepalive 영향 실측
- Amazon VPC Lattice 요금 — data processing에 inter-AZ 포함
- Access logs for Amazon VPC Lattice
- Monitoring Amazon VPC Lattice
연결한 Pod benchmark는 별도 workload 기준선입니다. HTTP keepalive 수치는 TLS handshake나 Lattice 자체의 실측이 아닙니다.