[Cloud NAT][운영] Direct VPC egress burst 때 packet drop이 튈 때 port_usage와 NAT allocation errors를 어떤 시간축으로 먼저 비교하나

카테고리 없음 2026. 7. 15. 09:13

IT 리서치 노트

[Cloud NAT][운영] Direct VPC egress burst 때 packet drop이 튈 때 port_usage와 NAT allocation errors를 어떤 시간축으로 먼저 비교하나

Cloud Run Direct VPC egress 경로에서 outbound burst가 몰릴 때 첫 요청 지연과 packet drop이 같이 보이면 port 수를 더 주는 쪽으로 바로 달려가기 쉽다. 하지만 2026년 7월 15일 기준 Google Cloud 공식 문서를 다시 보면 Cloud NAT는 port usage, NAT allocation errors, dropped packets, logging을 서로 다른 관찰면으로 제공하고, dynamic port allocation 자체도 추가 포트 할당 구간에서 latency를 만들 수 있다. 이 글은 burst 시점 triage에서 어떤 시간축으로 지표를 먼저 겹쳐 볼지 정리한 것이다.

1. 개요

결론부터 말하면 burst triage는 port_usage peak와 NAT allocation errors를 같은 시간축에 겹쳐 보는 것부터 시작해야 한다. port usage만 높고 allocation error가 없으면 포트 압박은 있으나 즉시 drop으로 이어진 것은 아닐 수 있고, allocation error와 dropped packets가 함께 뛰면 실제 포트 부족이 먼저다.

또 dynamic port allocation은 포트 효율을 높이지만, 추가 할당 순간의 latency 가능성을 문서가 직접 경고한다. 따라서 지표를 볼 때는 평균보다 burst 구간과 설정 변경 시점을 같이 놓는 편이 더 실용적이다.

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

운영에서 자주 헷갈리는 것은 세 가지다. 첫째, latency spike가 보이자 port_usage만 보고 min ports를 바로 올린다. 둘째, allocation error 로그가 보였는데 그 시점이 배포 직후인지 평시인지 확인하지 않는다. 셋째, 설정 변경 직후 생긴 연결 흔들림을 단순 트래픽 증가로 오해한다.

Cloud NAT monitoring 문서는 Port usage, NAT allocation errors, Dropped sent packets rate를 अलग 대시보드로 둔다. tune 가이드는 min ports를 바꾸기 전에 per-VM port_usage peak를 먼저 보라고 하고, ports-and-addresses 문서는 dynamic allocation 중 추가 포트 할당 시 timeout이나 latency가 보일 수 있다고 적는다. 즉 같은 '느리다'는 증상이라도 포트 고갈, 추가 할당 지연, 설정 변경 영향이 서로 다른 면에서 나타난다.

특히 Direct VPC egress 경로는 Cloud Run 쪽 조정과 Cloud NAT 쪽 조정이 동시에 얽히기 쉽다. connection pooling, downstream retry, startup probe, NAT ports를 같은 시간축 없이 따로따로 보면 어느 층이 먼저 흔들렸는지 놓친다. 이때 먼저 해야 할 일은 수치 하나를 고치는 것이 아니라, burst 구간의 시계열을 맞추는 것이다.

증상: burst 직후 첫 요청 지연과 packet drop이 함께 보인다.
실패: 평균 usage만 보고 peak 시점을 놓친다.
막힘: allocation error와 dropped packet 로그를 같은 시간창에 안 맞춘다.
누락: 설정 변경 시각과 배포 시각을 지표 메모에 남기지 않는다.

관찰값	먼저 볼 곳	해석
usage peak만 높다	per-VM port usage	포트 압박이 있으나 drop까지 간 것은 아닐 수 있다
allocation errors와 dropped packets가 동반된다	Cloud NAT logging	실제 포트 부족이 outbound drop으로 이어진다
설정 변경 직후 지연만 커진다	변경 시각과 latency	동적 할당 재조정이나 연결 reset 영향일 수 있다

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

실무 순서는 다섯 단계가 가장 짧다. 먼저 배포 시각과 NAT 설정 변경 시각을 메모한다. 두 번째로 port_usage를 instance_id 기준 max로 본다. 세 번째로 같은 시간창에서 NAT allocation errors와 dropped sent packets rate를 겹친다. 네 번째로 error log가 실제로 찍혔는지 확인한다. 마지막으로 그 뒤에 min/max ports, connection pooling, timeout을 조정한다.

배포 시각과 NAT 설정 변경 시각을 먼저 적는다.
per-VM port_usage peak를 본다.
NAT allocation errors와 dropped packets를 같은 창으로 겹친다.
error log 존재 여부로 실제 포트 고갈을 확인한다.
그 뒤에 min/max ports와 앱 쪽 조정을 나눈다.

관찰 순서 메모

1. deploy_started_at 기록
2. port_usage peak 확인
3. nat_allocation_errors 겹쳐 보기
4. dropped packet error log 확인
5. 그 뒤에 min/max ports 또는 app retry 조정

이 순서를 지키면 포트 부족과 설정 변경 영향을 분리하기 쉽다. usage peak는 높지만 errors가 없으면 connection reuse나 앱 레벨 동시성부터 다시 볼 수 있고, errors가 즉시 뛰면 NAT 쪽 포트 범위와 burst 패턴을 먼저 조정하는 편이 맞다.

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

첫 자료는 Cloud NAT monitoring 문서의 predefined dashboard 구간이다. Google Cloud는 Port usage와 NAT allocation errors를 서로 다른 지표로 따로 보여 준다. 즉 burst 시점 triage는 포트 사용량 그래프 하나로 끝나지 않는다.

Cloud NAT 대시보드는 Port usage와 NAT allocation errors를 별도 지표로 분리해 보여 준다.

이 구분을 안 하면 peak port usage만 보고 min ports를 올리거나, 반대로 error 로그만 보고 포트 압박의 시간축을 놓치기 쉽다. 먼저 두 지표를 같은 창으로 겹쳐 봐야 한다.

두 번째 자료는 logging 설명이다. Cloud NAT는 NAT 포트가 없어서 패킷이 drop될 때 error log를 남길 수 있다고 문서에 적어 둔다. 즉 allocation error는 단순 경고가 아니라 실제 outbound drop과 이어질 수 있는 이벤트다.

Cloud NAT logging은 NAT용 포트가 없어서 drop된 outbound 패킷을 별도로 기록할 수 있다.

이 로그는 burst 직후 packet drop이 튀는 시점과 port usage 상승 시점이 얼마나 붙어 있는지 확인하는 데 중요하다. 로그가 없으면 지표만 보고는 실제 drop 구간을 좁히기 어렵다.

세 번째 자료는 tune NAT configuration의 port usage 설명이다. Google Cloud는 min ports를 조정하기 전에 per-VM port usage를 먼저 보라고 명시한다. 특히 past 30 days max 기준을 보라고 하는 이유는 순간 burst를 그냥 평균으로 덮지 않기 위해서다.

min ports를 바꾸기 전에는 per-VM port usage를 먼저 보고, peak usage를 기준으로 판단하라고 안내한다.

즉 burst triage에서 중요한 것은 평균 usage가 아니라 peak usage와 allocation error가 어느 시점에 겹쳤는지다. 시간축을 넓게 보면 만성 부족인지 특정 배포 구간의 spike인지도 갈린다.

네 번째 자료는 dynamic port allocation의 주의점이다. 문서는 포트를 추가 할당하는 동안 connection timeout이나 latency가 보일 수 있다고 적는다. 즉 packet drop이 없더라도 burst 직후 첫 요청 지연이 함께 튈 수 있다.

동적 포트 할당은 포트 부족을 줄이지만, 추가 할당 구간에서 timeout이나 latency가 보일 수 있다고 설명한다.

그래서 burst triage는 drop 유무만 보는 문제가 아니다. allocation error가 0이어도 port usage 급등과 첫 요청 지연이 같이 보이면 min/max 범위를 다시 잡아야 할 수 있다.

실무에서는 두 지표를 같은 시간축에 놓는 표가 가장 유용하다. port usage peak, allocation error count, dropped sent packets rate, 배포 시각을 한 줄에 놓으면 문제를 capacity 부족과 설정 변경 영향으로 분리하기 쉬워진다.

burst triage에서는 포트 사용량, allocation error, dropped packets를 같은 시간축으로 같이 봐야 한다.

이미 min ports와 max ports 조정 글을 봤다면, 이번 표는 값을 바꾸기 전에 어떤 관찰 순서로 시간을 겹쳐 볼지에 더 가깝다.

마지막 자료는 안전한 운영 메모 예시다. Cloud NAT 로그와 모니터링 지표를 묶을 때는 gateway 이름과 인스턴스 식별자, 배포 시각, dropped packet 로그 존재 여부를 같이 기록하는 편이 좋다.

포트 사용량과 allocation error를 비교할 때는 지표와 로그를 같은 메모 구조로 묶어야 한다.

이렇게 남겨 두면 NAT 지표 글이나 EIM과 dynamic allocation 분기 글처럼 설정 판단과 증상 관찰을 이어 읽기 쉽다.

5. 주의사항과 리스크

지표를 같은 시간축에 안 맞추면 원인 분리가 흔들린다. port_usage peak만 보고 min ports를 키웠는데 실제 문제는 설정 변경 직후의 연결 reset이었을 수 있고, 반대로 allocation error를 못 보고 앱 retry만 손대면 drop 구간이 그대로 남을 수 있다.

또 dynamic port allocation은 공짜 안정화 장치가 아니다. 문서가 경고하듯 추가 포트 할당 시 timeout이나 latency가 함께 보일 수 있기 때문에, burst 구간이 짧다고 해서 무조건 min ports를 낮게 두는 것도 위험하다.

주의: 평균 usage보다 peak와 error 시점이 더 중요하다.
주의: allocation error가 없으면 drop 원인이 NAT가 아닐 수도 있다.
주의: 설정 변경 직후 지연은 포트 부족과 다른 문제일 수 있다.

6. 결론

Direct VPC egress burst에서 packet drop이 튈 때는 port_usage, NAT allocation errors, dropped packet 로그를 같은 시간축으로 먼저 겹쳐 보는 편이 가장 빠르다. 그 뒤에야 min/max ports를 바꿀지, dynamic allocation의 영향인지, 앱 레벨 연결 패턴을 줄일지 판단이 선다.

관련 흐름으로는 Direct VPC와 포트 고갈 분기 글, min ports와 max ports 조정 글, EIM과 dynamic allocation 분기 글을 같이 보면 설정 선택과 지표 관찰이 한 줄로 이어진다. allocation errors가 0인데도 burst 직후 지연이 남는 케이스만 따로 보고 싶다면 후속편인 error 0 지연 분리 글로 바로 이어가면 된다.

ABOUT ME

FullStack Lab FullStack Lab