[Cloud NAT][운영] NAT allocation errors는 없는데 burst 직후 지연이 남을 때 min ports, max ports, dynamic allocation timeout을 어떤 순서로 다시 보나

IT 리서치 노트

[Cloud NAT][운영] NAT allocation errors는 없는데 burst 직후 지연이 남을 때 min ports, max ports, dynamic allocation timeout을 어떤 순서로 다시 보나

Cloud NAT 운영에서 NAT allocation errors가 0인데도 burst 직후 첫 요청 지연이 남는 상황이 꽤 까다롭다. 2026년 7월 15일 기준 Google Cloud 공식 문서를 다시 보면 dynamic port allocation은 필요에 따라 포트를 늘리지만, 그 과정에서 timeout이나 latency가 보일 수 있고, 관련 timeout과 최근 설정 변경도 결과에 영향을 준다. 이 글은 error가 없는데 지연만 남는 상황에서 무엇부터 다시 봐야 하는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 allocation errors가 0이어도 NAT를 바로 제외하면 안 된다. 먼저 per-VM port usage가 max 근처에서 반복되는지, dynamic allocation 관련 timeout이 권고 이하인지, 최근 NAT 설정 변경이 있었는지를 같은 순서로 분리해서 봐야 한다.

그다음에야 앱의 connection pooling이나 downstream retry를 본다. NAT와 앱을 한 번에 섞어 해석하면 min ports를 올렸는데도 지연이 남는 루프에 빠지기 쉽다.

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

이 케이스가 어려운 이유는 error metric이 조용하기 때문이다. packet drop 글처럼 allocation errors가 튀면 비교 기준이 분명하지만, 여기서는 지연만 남고 NAT error count는 0일 수 있다. 그러면 많은 팀이 NAT는 정상이라고 결론 내리고 앱 retry만 손대거나, 반대로 min ports만 올린다.

하지만 공식 문서는 dynamic allocation 동안 timeout이나 latency가 보일 수 있다고 적고, 관련 timeout도 일정 이상으로 두라고 권고한다. 여기에 설정 변경까지 겹치면 error 없이도 burst 직후 체감 지연이 생긴다.

• 증상: allocation errors는 0인데 burst 직후 첫 요청만 느리다.
• 실패: error가 0이라는 이유로 NAT를 바로 제외한다.
• 막힘: 최근 NAT 설정 변경 이력을 같은 타임라인에 안 붙인다.
• 누락: 앱의 연결 재사용 여부를 NAT 포트 수보다 뒤늦게 본다.

신호	먼저 볼 항목	의미
usage peak가 max 근처에서 급상승	min/max ports	allocation 확장 구간 지연일 수 있다
지연이 설정 변경 직후 시작	최근 NAT 수정	기존 연결이 재초기화됐을 수 있다
error는 0인데 연결 수가 폭증	앱 connection reuse	NAT보다 앱 패턴이 먼저일 수 있다

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

실무 순서는 다섯 단계다. 먼저 monitoring에서 port usage peak를 본다. 두 번째로 dynamic allocation 관련 timeout이 권고값 이상인지 본다. 세 번째로 최근 NAT 설정 변경이 있었는지 확인한다. 네 번째로 min/max ports를 본다. 마지막으로 앱 connection pooling과 retry를 점검한다.

1. port usage peak가 실제로 ceiling 근처를 치는지 확인한다.
2. dynamic allocation timeout 관련 권고를 먼저 맞춘다.
3. 최근 NAT 설정 변경과 배포 시각을 겹쳐 본다.
4. 그다음에 min/max ports 조정 여부를 판단한다.
5. 앱 연결 재사용과 downstream retry를 별도로 점검한다.

latency triage memo

allocation_errors=0
port_usage_peak=1980
max_ports_per_vm=2048
dynamic_allocation_timeout=10s
nat_config_changed_at=09:12
app_connection_pooling=disabled

이 순서를 쓰면 min ports를 올려야 하는지, timeout부터 고쳐야 하는지, 아예 앱 connection reuse가 먼저인지가 빨리 갈린다. error가 조용한 케이스일수록 숫자를 바꾸기 전에 타임라인을 붙여 보는 편이 안전하다.

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

아래 화면과 표에서는 highlighted 문구, timeout 값, monitoring 항목, 설정 변경 제한 설명을 순서대로 확인하면 된다.

첫 자료는 dynamic port allocation 설명이다. allocation error가 없어도 burst 직후 지연이 남는다면, 먼저 포트가 어떻게 단계적으로 늘어나는지를 이해해야 한다.

Cloud NAT는 dynamic port allocation에서 포트가 부족해질수록 VM별 포트를 단계적으로 더 할당한다.

즉 error가 없다는 사실만으로 NAT가 병목이 아니라고 결론 내리면 안 된다. 추가 포트가 붙는 과정 자체가 latency와 timeout 신호를 만들 수 있다.

두 번째 자료는 모니터링 가이드다. burst 직후 지연이 남는다면 allocation error count보다 먼저 per-VM port usage가 ceiling 근처에서 어떻게 움직였는지 봐야 한다.

모니터링 가이드는 port usage와 NAT allocation errors를 함께 보라고 안내한다.

특히 error가 0인데도 usage peak가 max 근처를 반복하면, 앱 retry나 short burst가 포트 확장 구간을 계속 건드리고 있을 수 있다.

세 번째 자료는 NAT 튜닝 문서의 timeout 권고다. 동적 포트 할당을 쓰면 특정 timeout은 15초 이상으로 두라고 경고한다.

Google Cloud는 dynamic port allocation 사용 시 관련 timeout을 15초 이상으로 두라고 권고한다.

이 값이 너무 낮으면 allocation error가 안 떠도 연결이 조기에 잘리고, 겉으로는 앱 레벨 지연처럼만 보일 수 있다. 그래서 min/max ports보다 timeout 확인이 먼저다.

네 번째 자료는 NAT 설정 변경 부작용이다. dynamic port allocation이 켜진 뒤 추가 설정 변경을 하면 기존 연결이 흔들릴 수 있다고 적는다.

Cloud NAT 문서는 dynamic port allocation 상태에서 추가 설정 변경이 기존 연결에 영향을 줄 수 있다고 설명한다.

따라서 지연 spike가 배포 직후나 NAT 수정 직후에만 나타난다면, 포트 수 자체보다 최근 변경이 allocation을 다시 minimum으로 되돌렸는지 먼저 봐야 한다.

다섯 번째 자료는 Cloud Run 네트워킹 best practices다. NAT 쪽을 의심하더라도 앱이 연결을 재사용하지 않는다면 burst 지연은 계속 남는다.

Cloud Run best practices는 connection pooling과 연결 재사용을 권장한다.

즉 error가 0인 상황에서는 NAT min/max ports만 볼 것이 아니라, 애플리케이션이 쓸데없이 새 연결을 많이 여는지 같이 봐야 한다.

마지막 자료는 allocation error가 없는데 지연이 남는 상황 전용 triage 표다. 이 표가 있으면 숫자를 올리기 전에 무엇을 먼저 분리해서 봐야 할지 빨라진다.

error가 0이어도 NAT와 앱을 함께 가르는 burst 지연 triage 표다.

이미 packet drop 시간축 비교 글을 읽었다면, 이번 표는 error가 0인 케이스만 따로 좁히는 후속편이다.

5. 주의사항과 리스크

가장 흔한 리스크는 error가 0이니 NAT는 무관하다고 단정하는 것이다. 공식 문서가 경고하듯 dynamic allocation은 추가 포트가 붙는 동안 timeout이나 latency를 만들 수 있고, 최근 설정 변경도 같은 패턴을 만든다.

반대로 NAT만 보고 앱 패턴을 안 보는 것도 위험하다. connection pooling이 없으면 min ports를 올려도 burst마다 새 연결이 쏟아져 같은 증상이 반복될 수 있다.

• 주의: allocation errors=0은 NAT 무관의 증거가 아니다.
• 주의: timeout 권고보다 낮은 설정은 지연을 앱 문제처럼 보이게 만든다.
• 주의: 최근 NAT 수정과 앱 배포 시각을 분리해서 기록해야 한다.

6. 결론

Cloud NAT에서 error가 0인데 burst 직후 지연이 남는다면, 먼저 usage peak와 timeout, 최근 설정 변경을 분리해서 본 뒤 그다음에 min/max ports와 앱 connection reuse를 판단하는 편이 맞다. 이렇게 해야 숫자를 올렸는데도 지연이 남는 루프를 줄일 수 있다.

관련 흐름으로는 packet drop 시간축 비교 글, min ports와 max ports 조정 글, EIM과 dynamic allocation 분기 글을 같이 보면 관찰, 설정, 선택 기준이 한 줄로 이어진다. 이어서 port_usage와 connection reuse 분기 글을 보면 error가 0인데도 왜 앱 동시성과 연결 재사용을 먼저 확인해야 하는지까지 한 단계 더 좁혀 볼 수 있다.

7. 참고 링크

1. https://docs.cloud.google.com/nat/docs/ports-and-addresses
2. https://docs.cloud.google.com/nat/docs/monitoring
3. https://docs.cloud.google.com/nat/docs/tune-nat-configuration
4. https://docs.cloud.google.com/nat/docs/set-up-manage-network-address-translation
5. https://docs.cloud.google.com/run/docs/configuring/networking-best-practices