-
[Cloud NAT][운영] allocation error는 없는데 port_usage만 치솟을 때 connection reuse와 앱 동시성을 어떤 순서로 다시 보나카테고리 없음 2026. 7. 16. 09:13
IT 리서치 노트
[Cloud NAT][운영] allocation error는 없는데 port_usage만 치솟을 때 connection reuse와 앱 동시성을 어떤 순서로 다시 보나
Cloud NAT에서 allocation error는 안 보이는데 `compute.googleapis.com/nat/port_usage`만 빠르게 치솟는 상황은 의외로 자주 나온다. 2026년 7월 16일 기준 Google Cloud 공식 문서를 다시 보면 Cloud NAT 로그는 모든 패킷을 다 기록하지 않고, dynamic port allocation은 포트를 추가로 배정하는 동안 latency가 나타날 수 있으며, Cloud Run 쪽에서는 connection pooling과 reuse를 권장한다. 이 글은 error 로그가 조용한데 port_usage만 튈 때 NAT 설정과 애플리케이션 동시성을 어떤 순서로 다시 봐야 하는지 정리한 것이다.
1. 개요
결론부터 말하면 allocation error 0만 보고 NAT 문제를 배제하면 안 된다. port_usage가 급등하는데 에러 로그가 조용하면, 먼저 앱이 새 연결을 과하게 만들고 있는지와 Cloud Run 동시성이 burst를 키우는지부터 본 뒤, 그다음 minimum ports per VM과 목적지 분포를 보는 편이 빠르다.
즉 이번 증상은 NAT 설정 단독 문제보다 앱 연결 습관과 NAT 지표를 함께 읽는 문제다. connection pooling과 reuse가 부족하면 NAT가 동적으로 포트를 늘리고 있어도 burst 구간에서 port_usage만 빠르게 튈 수 있다.
2. 어디서 실제로 막히는가
실무에서 자주 겪는 증상은 세 가지다. 첫째, Cloud Monitoring에서 port_usage가 짧게 급등하는데 NAT allocation errors는 계속 0이다. 둘째, 지연은 보이는데 Cloud NAT 로그에 명확한 error가 적게 남는다. 셋째, Cloud Run revision을 늘리거나 fan-out 작업을 붙인 뒤 같은 목적지로 새 연결이 쏟아진다.
이 상황에서 많은 팀이 minimum ports만 바로 올리거나 NAT IP 수만 늘린다. 하지만 Cloud Run networking best practices는 같은 목적지에 높은 요청률을 보낼수록 connection pooling과 reuse를 먼저 보라고 설명한다. 즉 포트 압박의 출발점이 NAT가 아니라 앱의 연결 생성 패턴일 수 있다.
또 Cloud NAT monitoring 문서는 로그가 모든 패킷을 기록하지 않는다고 적고 있다. 따라서 error 로그가 조용하다고 해서 포트 배정 과정이나 재사용 대기 때문에 생긴 지연이 없었다고 단정하면 안 된다. port_usage 시계열, burst 시점, 동시성 설정, keepalive 여부를 같은 시간축에 놓아야 원인 분리가 된다.
- 증상: allocation error는 없는데 port_usage와 지연만 튄다.
- 실패: NAT 에러 로그가 없으니 앱은 정상이라고 가정한다.
- 막힘: connection pooling과 Cloud Run concurrency를 같이 보지 않는다.
- 누락: burst 시점과 목적지 연결 수를 같은 타임라인에 남기지 않는다.
증상 먼저 볼 곳 판단 기준 짧은 burst에서만 spike connection reuse, fan-out 새 연결이 한 번에 몰리는지 본다 장시간 port_usage 높음 minimum ports, 목적지 수 NAT 설정이 실제 트래픽 패턴보다 작은지 본다 에러 로그가 거의 없음 port_usage와 앱 로그 로그 부재를 정상 신호로 오해하지 않는다 3. 실무에서 적용하는 순서
가장 빠른 점검 순서는 다섯 단계다. 먼저 port_usage 급등 시점을 찾는다. 두 번째로 같은 시점의 Cloud Run concurrency, queue fan-out, batch dispatch 수를 본다. 세 번째로 애플리케이션이 keepalive와 connection pooling을 켰는지 확인한다. 네 번째로 그래도 장시간 높게 유지되면 minimum ports per VM과 목적지 분포를 다시 본다. 마지막으로 only-NAT 변경이 아니라 앱 설정과 NAT 설정을 같은 실험 메모로 남긴다.
- port_usage 급등 시점을 먼저 찾는다.
- 같은 시점의 앱 동시성과 fan-out 이벤트를 대조한다.
- connection pooling과 keepalive가 실제로 켜졌는지 확인한다.
- 장시간 압박이면 minimum ports와 NAT IP 구성을 다시 본다.
- 앱 변경과 NAT 변경을 같은 실험 표에 기록한다.
핵심은 설정 변경 순서다. connection reuse가 꺼져 있는데 NAT minimum ports부터 올리면 문제는 줄어들지 않고 비용만 늘 수 있다. 반대로 앱이 이미 연결을 잘 재사용하고 있는데도 장시간 port_usage가 높다면 그때는 NAT minimum ports와 목적지 분산 전략을 보는 편이 맞다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 Cloud NAT monitoring 문서다. 여기서는 로그가 모든 패킷을 다 남기지 않으며, 로그 부재를 사건 부재로 해석하면 안 된다고 분명히 적고 있다.
즉 allocation error가 안 보인다고 바로 NAT 설정을 배제하면 안 된다. port_usage는 치솟는데 로그는 조용한 상황이 실제로 생길 수 있고, 이때는 connection reuse와 동시성 패턴을 먼저 의심해야 한다.
두 번째 자료는 ports and addresses 문서다. dynamic port allocation은 필요에 따라 포트를 더 배정하지만, 그 사이에 latency나 timeout이 보일 수 있다고 적혀 있다.
이 문장은 allocation error가 0이어도 체감 지연이 남을 수 있는 이유를 설명한다. 결국 앱이 너무 빠르게 새 연결을 열고 있다면 NAT가 따라가도 port_usage는 크게 튈 수 있다.
세 번째 자료는 Cloud NAT troubleshooting 문서다. Google Cloud는 minimum ports per VM 판단에 `compute.googleapis.com/nat/port_usage`를 직접 보라고 안내한다.
즉 문제가 없다고 끝내는 지표가 아니라, 포트 압박이 조용히 쌓이는지 보는 지표가 port_usage다. 특히 burst 직후만 높게 치솟는다면 앱 레벨 연결 재사용 실패일 가능성이 커진다.
네 번째 자료는 Cloud Run networking best practices다. 여기서는 같은 목적지로 많은 요청을 보낼 때 connection pooling과 reuse를 쓰라고 직접 권장한다.
즉 NAT minimum ports만 올리기 전에 앱이 매 요청마다 새 소켓을 만드는지부터 봐야 한다. 포트 압박은 NAT 설정 문제처럼 보이지만, 실제 출발점이 애플리케이션 연결 습관인 경우가 많다.
실무에서는 NAT와 앱을 함께 보는 triage 표가 필요하다. allocation error 0이라는 한 줄만으로는 NAT 쪽인지 애플리케이션 쪽인지 설명이 안 된다.
이미 allocation errors는 없는데 burst 지연이 남는 글이 timeout 축을 다뤘다면, 이번 표는 connection reuse와 동시성 축을 먼저 나누는 버전이다.
마지막 자료는 운영 관찰 메모다. NAT 지표와 앱 설정을 한 줄로 묶어 두면 다음 장애 때 재현성이 좋아진다.
이 구조를 남겨 두면 packet drop과 allocation errors 시간축 글처럼 NAT 지표를 볼 때도 앱 레벨 동시성과 연결 재사용 상태를 같이 대조할 수 있다.
5. 주의사항과 리스크
첫 번째 리스크는 error 로그가 없으니 NAT는 정상이라고 단정하는 것이다. 두 번째 리스크는 connection pooling이 꺼진 채 NAT minimum ports만 계속 올리는 것이다. 세 번째 리스크는 Cloud Run 동시성과 batch fan-out이 port_usage에 미치는 영향을 별도 로그로 남기지 않는 것이다.
운영 전에는 같은 목적지로 가는 요청이 많은 코드 경로부터 connection reuse를 강제하는 편이 좋다. 그리고 NAT minimum ports 조정은 그다음 단계다. 그래야 앱 패턴과 NAT 패턴을 따로 검증할 수 있다.
- error 로그 부재는 원인 부재가 아니다.
- port_usage spike는 NAT와 앱 동시성을 함께 봐야 한다.
- connection reuse를 먼저 고정하고 NAT minimum ports를 조정한다.
6. 결론
allocation error가 없는데 port_usage만 치솟는 상황은 NAT보다 앱 연결 습관이 먼저 문제인 경우가 많다. port_usage 시계열과 Cloud Run 동시성, connection pooling 여부를 먼저 묶어 보고, 그다음 minimum ports per VM을 조정하면 훨씬 짧게 원인을 좁힐 수 있다.
관련 흐름으로는 packet drop과 allocation errors 시간축 글, EIM과 dynamic allocation 분기 글, allocation errors 없이 burst 지연이 남는 글을 같이 보면 NAT 설정과 앱 패턴이 한 사다리로 이어진다.
또 2026년 7월 16일 후속 글인 새 Cloud NAT gateway의 TCP TIME_WAIT 기본값이 30초로 바뀌는 롤아웃 구간 점검 글을 함께 보면, port_usage 해석 전에 gateway 생성 시점과 지역 롤아웃 차이부터 기록해야 하는 이유가 더 분명해진다.
7. 참고 링크
