[Cloud NAT][운영] Endpoint-Independent Mapping이 필요할 때 dynamic port allocation과 어떤 기준으로 먼저 갈라 보나

카테고리 없음 2026. 7. 14. 20:13

IT 리서치 노트

[Cloud NAT][운영] Endpoint-Independent Mapping이 필요할 때 dynamic port allocation과 어떤 기준으로 먼저 갈라 보나

Cloud NAT 운영에서 outbound 연결이 많아지면 dynamic port allocation이 먼저 떠오르지만, 일부 워크로드는 Endpoint-Independent Mapping 같은 매핑 일관성을 더 중시한다. 2026년 7월 14일 기준 Google Cloud 공식 문서를 다시 보면 이 두 기능은 같은 NAT gateway에서 함께 쓸 수 없고, 각각 해결하려는 문제가 다르다. 이 글은 EIM이 필요한 상황에서 dynamic port allocation과 어떤 기준으로 먼저 갈라 봐야 하는지 정리한 것이다.

1. 개요

결론부터 말하면 외부 시스템이 같은 NAT 매핑을 기대한다면 EIM을 먼저 검토하고, burst outbound 연결과 포트 효율이 우선이면 dynamic port allocation을 먼저 본다. 둘은 같은 문제를 푸는 옵션이 아니고, Google Cloud 문서 기준으로 같은 NAT gateway에서 동시에 켤 수 없기 때문이다.

따라서 운영 질문은 설정값을 미세 조정하는 문제가 아니라 워크로드 우선순위를 정하는 문제다. 어떤 연결은 포트 효율보다 매핑 일관성이 중요하고, 어떤 연결은 매핑 일관성보다 포트 부족과 latency spike가 더 큰 문제다.

2. 어디서 실제로 막히는가

현장에서 흔한 막힘은 세 가지다. 첫째, outbound 연결이 갑자기 많아지자 dynamic allocation을 켜려는데 EIM 요구사항이 나중에 드러난다. 둘째, 외부 시스템이 동일 NAT 매핑을 기대하는지 모른 채 포트 효율만 보고 dynamic allocation부터 적용한다. 셋째, Cloud Run 또는 VM이 burst traffic을 만들 때 보이는 latency와 외부 매핑 일관성 이슈를 같은 네트워크 문제로 묶어 버린다.

이 상황에서 가장 위험한 것은 두 옵션을 동시에 만족시킬 수 있다고 생각하는 것이다. 문서 기준으로 dynamic allocation은 사용량에 따라 포트 수를 조정하는 기능이고, EIM은 같은 내부 소스의 NAT 매핑을 목적지와 무관하게 유지하는 기능이다. 운영 목적부터 다르기 때문에 같은 체크리스트로 다루면 안 된다.

특히 Cloud Run Direct VPC egress 같이 burst가 잦은 경로에서는 dynamic allocation이 매우 매력적으로 보인다. 하지만 외부 파트너나 특정 프로토콜이 매핑 일관성을 요구한다면 먼저 EIM 요구를 확인해야 한다. 그렇지 않으면 포트 효율은 좋아졌는데 외부 세션이 불안정해지는 식의 역효과가 난다.

증상: 포트 부족과 외부 세션 불안정이 동시에 보인다.
실패: dynamic allocation과 EIM을 같은 손잡이로 생각한다.
막힘: 외부 시스템 요구보다 NAT 포트 효율만 먼저 본다.
누락: 변경 전 워크로드 특성과 연결 기대치를 문서로 남기지 않는다.

관찰값	먼저 볼 것	판단 기준
대량 outbound 연결이 burst로 튄다	port usage와 allocation	포트 효율 문제가 더 큰지 본다
외부 장비가 같은 매핑을 기대한다	EIM 요구 여부	매핑 일관성이 더 중요한지 본다
변경 뒤 latency와 세션 문제가 함께 생긴다	변경 기록과 연결 종류	포트 정책 변경과 매핑 기대가 충돌했는지 본다

3. 실무에서 적용하는 순서

가장 짧은 순서는 다섯 단계다. 먼저 외부 시스템이 동일 매핑을 요구하는지 확인한다. 두 번째로 현재 워크로드의 포트 사용량과 burst 패턴을 본다. 세 번째로 EIM 요구가 강하면 static allocation과 EIM 유지 쪽으로 먼저 설계한다. 네 번째로 포트 효율 문제가 더 크면 dynamic allocation과 min/max 튜닝으로 들어간다. 마지막으로 변경 기록에 연결 기대치와 NAT 설정을 함께 남긴다.

외부 시스템이 동일 매핑을 기대하는지 확인한다.
현재 포트 사용량과 burst 패턴을 본다.
EIM 요구가 강하면 static allocation을 먼저 택한다.
포트 효율이 더 중요하면 dynamic allocation으로 튜닝한다.
연결 기대치와 NAT 설정을 같은 변경 기록에 남긴다.

설정 전에 외부 시스템 요구를 확인한다.
로그에서 port usage와 timeout 시각을 확인한다.
변경 기록에 min ports, max ports, EIM 여부를 기록한다.
변경 후 latency, connection, retry 로그를 다시 확인한다.

콘솔에서 NAT gateway 설정을 열고 Dynamic port allocation 체크 여부를 확인한 뒤, Public NAT 고급 설정에서 EIM 요구가 있는지 확인한다. 이어서 로그를 보고 packet drop, timeout, retry 시각을 기록하고, 변경 후 같은 항목을 다시 비교해야 한다.

gcloud compute routers nats describe NAT_NAME \
  --router=ROUTER_NAME \
  --region=REGION

# 확인 포인트
# - enableEndpointIndependentMapping
# - enableDynamicPortAllocation
# - minPortsPerVm
# - maxPortsPerVm

Cloud Run 경로에서 같이 보는 포인트

Cloud Run Direct VPC egress 워크로드라면 first request latency, downstream connection reuse, NAT allocation 변화 시점을 함께 봐야 한다. 포트 효율만 보고 dynamic allocation을 켠 뒤 외부 연결 특성이 바뀌면 성능과 연결 안정성을 같이 잘못 읽을 수 있다.

반대로 외부 시스템이 EIM을 요구하지 않는데 burst 연결이 큰 편이라면 dynamic allocation과 min/max 튜닝이 더 실용적이다. 이 경우에는 min ports와 max ports 조정 글처럼 내부 튜닝 기준으로 더 깊게 들어가면 된다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Cloud NAT ports and addresses 문서의 dynamic port allocation 구간이다. 여기서 Google Cloud는 min ports per VM과 max ports per VM 사이에서 포트 수를 자동으로 늘리고 줄이는 방식을 설명한다. 즉 dynamic allocation은 포트 효율성과 burst 대응을 얻는 대신, 포트 배정 정책을 NAT가 런타임에 바꾼다는 뜻이다.

Cloud NAT 문서는 dynamic port allocation이 VM 사용량에 따라 포트 수를 자동으로 조정한다고 설명한다.

이 성질 때문에 포트 효율성이 필요한 워크로드에는 유리하지만, 외부가 보는 매핑 일관성을 더 중시하는 워크로드에는 다른 판단이 필요해진다.

두 번째 자료는 Public NAT 문서의 Endpoint-Independent Mapping 설명이다. EIM은 같은 내부 IP와 포트 쌍이 여러 목적지로 나가더라도 동일한 NAT IP와 포트 쌍을 유지하도록 설계된 동작이다. 즉 외부 관점의 매핑 일관성을 강조하는 기능이다.

Endpoint-Independent Mapping은 동일 내부 소스가 여러 목적지로 나갈 때 같은 NAT 매핑을 유지하도록 하는 기능이다.

이 개념은 포트 사용량을 탄력적으로 늘리는 dynamic allocation과 운영 목적이 다르다. 하나는 매핑 일관성이고, 다른 하나는 포트 효율성이다.

세 번째 자료는 NAT 설정 가이드다. 이 문서는 dynamic port allocation을 쓰는 NAT gateway에서는 Endpoint-Independent Mapping을 함께 켤 수 없다고 명시한다. 즉 운영 문제를 만났을 때 두 기능을 동시에 기대하면 안 된다.

Google Cloud는 dynamic port allocation과 Endpoint-Independent Mapping을 같은 NAT gateway에서 함께 켤 수 없다고 안내한다.

따라서 질문은 '둘 다 켜자'가 아니라 '이 워크로드는 어느 특성을 우선할 것인가'가 된다. 이 분기 기준이 없으면 설정 화면에서 바로 막히거나, 변경 후 기존 연결이 끊기는 이유를 이해하기 어렵다.

실무에서는 워크로드 성격별 분기표가 가장 먼저 필요하다. 대량 outbound 연결과 포트 효율이 중요한지, 외부 시스템이 같은 NAT 매핑을 기대하는지, Cloud Run이나 VM이 burst traffic을 얼마나 자주 만드는지를 한 표에서 같이 보면 결정이 빨라진다.

EIM 우선 워크로드와 dynamic allocation 우선 워크로드를 가르는 운영 분기표다.

이미 min ports와 max ports 조정 글이 dynamic allocation 안에서의 튜닝 순서를 다뤘다면, 이번 표는 그보다 한 단계 앞인 기능 선택 분기다.

마지막 자료는 설정 변경 예시다. 중요한 점은 dynamic allocation과 EIM을 한 NAT gateway에 동시에 기대하지 않는 것이다. 변경 전에는 현재 연결 영향과 min/max 값, EIM 요구 여부를 메모로 남겨 두는 편이 좋다.

Cloud NAT 설정 변경 전에는 EIM 요구 여부와 min/max 포트 값을 같은 변경 기록에 남기는 편이 안전하다.

이 기록이 있어야 Cloud Run Direct VPC egress 경로에서 first request latency가 바뀌었는지, 외부 시스템의 세션 기대치가 깨졌는지 나중에 비교할 수 있다.

5. 주의사항과 리스크

dynamic allocation으로 바꾸는 것은 단순 체크박스 변경이 아니다. 문서도 변경이 disruptive할 수 있다고 적는다. max 값을 너무 작게 잡거나 현재 연결 상태와 호환되지 않게 바꾸면 기존 연결에 영향이 갈 수 있다.

또 EIM 요구를 문서로 남기지 않으면 네트워크 팀과 애플리케이션 팀이 서로 다른 목표를 보고 변경하게 된다. 한쪽은 포트 부족을 줄였다고 보고하고, 다른 쪽은 외부 세션이 깨졌다고 느끼는 식이다.

주의: EIM과 dynamic allocation은 같은 NAT gateway에서 동시에 기대하지 않는다.
주의: 변경 전 연결 종류와 외부 기대치를 메모로 남긴다.
주의: Cloud Run 성능 문제와 외부 매핑 기대를 같은 지표 하나로 읽지 않는다.

6. 결론

Cloud NAT 운영에서 EIM과 dynamic allocation은 둘 중 하나를 더 우선해야 하는 선택이다. 외부가 같은 NAT 매핑을 기대하면 EIM과 static allocation을 먼저 보고, burst 연결과 포트 효율이 더 중요하면 dynamic allocation과 min/max 튜닝으로 가는 편이 맞다.

후속으로 더 세부 튜닝이 필요하다면 dynamic allocation min/max 순서 글과 NAT 지표와 first request latency 글을 함께 보면 Cloud Run 경로까지 자연스럽게 이어진다.

실제 burst 장애를 지표 시간축별로 더 세밀하게 비교하고 싶다면 Direct VPC egress burst 때 port_usage와 NAT allocation errors를 같은 창으로 비교하는 글도 바로 이어진다. 기능 선택 다음 단계에서 어떤 시점에 어떤 지표를 겹쳐 볼지까지 연결해 주기 때문이다.

ABOUT ME

FullStack Lab FullStack Lab