[Cloud Run][운영] connection pooling을 줄였는데도 latency spike가 남을 때 Direct VPC egress와 Cloud NAT 포트 고갈을 어떤 순서로 먼저 보나

IT 리서치 노트

[Cloud Run][운영] connection pooling을 줄였는데도 latency spike가 남을 때 Direct VPC egress와 Cloud NAT 포트 고갈을 어떤 순서로 먼저 보나

Cloud Run에서 connection pooling과 retry를 이미 손봤는데도 latency spike가 남으면 많은 팀이 다시 애플리케이션 안쪽 로그만 더 본다. 하지만 2026년 7월 13일 기준 Google Cloud 문서를 다시 보면 Direct VPC egress 경로, Cloud NAT 연결 수립 지연, source port 할당 구조가 남은 spike의 원인이 될 수 있다. 이 글은 pooling을 줄인 뒤에도 남는 지연을 기준으로 Direct VPC egress와 Cloud NAT 포트 고갈 신호를 어떤 순서로 먼저 확인하는 편이 실무적으로 맞는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 pooling 조정 뒤에도 latency spike가 남는다면 retry를 더 줄이기 전에 egress 경로를 먼저 본다. 첫 연결만 느리면 Direct VPC egress의 connection establishment delay를 의심하고, burst 때만 튀면 Cloud NAT port pressure와 connection churn을 먼저 본다. 애플리케이션 로그만으로 설명되지 않는 남은 지연은 네트워크 경로 층을 따로 분리해야 한다.

이미 pooling과 downstream retry 글이 애플리케이션 안쪽 우선순위를 다뤘다면, 이번 글은 그 다음 갈래인 egress 경로와 NAT 포트 진단이다. 내부와 외부 네트워크 층을 분리해 보는 후속편이라고 보면 된다. Direct VPC egress에서 startup probe를 egress 연결 확인으로 바꾼 뒤 어떤 NAT 지표를 같이 봐야 하는지는 후속 글로 이어진다.

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

현장에서 자주 생기는 착시는 세 가지다. 첫째, pooling을 줄였는데도 첫 요청이 유난히 느린 현상을 애플리케이션 warm-up만의 문제로 본다. 둘째, burst 구간에서만 spike가 생기는데도 downstream 서버 응답 속도만 재본다. 셋째, 새 연결 수와 NAT port pressure를 로그에 남기지 않아 retry, pooling, egress 경로 문제를 모두 p95 latency 하나로 읽는다.

Google Cloud 문서는 Direct VPC egress에서 Cloud NAT와 함께 쓸 경우 connection establishment delay가 길 수 있다고 경고하고, networking best practices에서는 실행 환경과 egress 경로가 성능에 영향을 준다고 설명한다. Cloud NAT 문서는 source port 할당 구조를 설명한다. 이 셋을 같이 읽으면 애플리케이션 안쪽 조정이 끝난 뒤에도 남는 지연이 네트워크 경로와 포트 할당 층에서 시작될 수 있다는 점이 분명해진다.

• 증상: pooling 조정 후에도 특정 시간대 spike가 남는다.
• 실패: 첫 연결 지연과 burst 지연을 같은 원인으로 본다.
• 막힘: new connection 수와 egress mode를 로그에 남기지 않는다.
• 누락: NAT 포트 압박 가능성을 trace 바깥으로 밀어 둔다.

관찰	먼저 볼 값	의미
cold-ish first request spike	egress mode, startup connectivity	Direct VPC path 지연일 수 있다
burst에서만 지연이 튄다	new connections, NAT port signals	포트 압박 또는 connection churn을 의심한다
전반적으로 고르게 느리다	downstream and app logs	네트워크 밖 원지연일 수 있다

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

실무에서 가장 덜 꼬이는 순서는 다섯 단계다. 먼저 request 로그에 pool acquire time과 new connection count를 분리해 남긴다. 두 번째로 egress mode가 Direct VPC인지, connector인지, public egress인지 고정한다. 세 번째로 첫 연결 지연이 두드러지면 startup connectivity probe나 destination-level check를 붙여 connection establishment delay를 확인한다. 네 번째로 burst spike라면 NAT port pressure와 connection churn 가설을 세우고 새 연결 수가 급증하는지 본다. 마지막으로 이 두 층이 아니라는 것이 확인된 뒤에만 retry나 timeout을 다시 조정한다.

1. pool acquire time과 new connection count를 같이 기록한다.
2. 실제 egress mode를 먼저 고정한다.
3. 첫 연결 지연이면 startup connectivity 경로를 확인한다.
4. burst spike면 NAT port pressure와 connection churn을 본다.
5. 그다음에만 retry나 timeout을 다시 만진다.

이 순서가 중요한 이유는 네트워크 경로 층을 빼놓고 retry만 줄이면 spike의 겉모양만 잠깐 바뀔 수 있기 때문이다. 예를 들어 새 연결이 많이 생기는 구조를 그대로 둔 채 backoff만 조정하면, 요청 실패 빈도는 바뀌어도 처음 연결 지연과 burst 지연은 남을 수 있다. 반대로 egress 경로와 port pressure를 먼저 보면 애플리케이션 안쪽에서 더 줄일 것이 남았는지 판단이 빨라진다.

관찰 체크리스트

- egress_mode fixed?
- first_connection_slow?
- burst_only_spike?
- new_connection_count rising?
- nat_signal seen before retry retune?

운영 문서에는 '애플리케이션 안쪽', 'egress path', 'NAT ports'를 따로 적는 편이 좋다. 그래야 팀이 p95 하나만 보고 모든 원인을 한데 묶는 실수를 줄일 수 있다.

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

첫 자료는 Cloud Run networking best practices의 Direct VPC egress 권고 구간이다. 여기서는 2세대 실행 환경과 적절한 egress 경로 선택이 네트워크 성능에 직접 닿는다고 설명한다. 즉 pooling만 조정해서 해결되지 않는 latency는 네트워크 경로 층을 따로 봐야 한다.

Cloud Run networking best practices 문서는 Direct VPC egress와 실행 환경 선택이 네트워크 성능에 영향을 준다고 설명한다.

이 문장을 먼저 읽어야 connection pooling 다음 단계의 진단 범위를 애플리케이션 안쪽에만 가두지 않게 된다. 남은 지연이 네트워크 경로와 egress 층에서 생길 수 있기 때문이다.

두 번째 자료는 Direct VPC egress 문서의 connection establishment delays 경고다. 문서는 Cloud NAT와 함께 쓸 때 startup 시 연결 수립 지연이 길어질 수 있고, 필요한 경우 egress 목적지 연결을 점검하는 HTTP startup probe를 권장한다.

Direct VPC egress 문서는 Cloud NAT와 함께 쓸 때 연결 수립 지연이 길어질 수 있음을 경고한다.

이 경고는 'pooling을 줄였는데도 첫 연결이 유난히 느리다'는 증상과 직접 연결된다. 애플리케이션 retry나 pool warm-up만 보고 있으면 네트워크 경로 층의 cold path를 놓치기 쉽다.

세 번째 자료는 Cloud NAT의 ports and addresses 문서다. 이 문서는 NAT가 source port를 어떻게 할당하는지 설명한다. 요청 수가 몰리거나 재사용이 어긋날 때는 단순한 앱 latency가 아니라 NAT port allocation과 exhaustion 징후로 봐야 하는 경우가 생긴다.

Cloud NAT 문서는 source port 할당 구조를 설명하며 포트 부족과 재할당 지연을 읽는 기준을 제공한다.

따라서 pooling 조정 후에도 spike가 남는다면 다음 분기는 '새 연결이 너무 많이 생기는가'와 'NAT가 그 연결을 안정적으로 소화하는가'다. 둘을 같은 숫자로 보면 원인 분리가 늦어진다.

실무에서는 애플리케이션 내부와 egress 경로 층을 한 표로 나눠 보는 편이 가장 빠르다. pooling 문제, Direct VPC cold path, NAT 포트 고갈 신호를 같은 표에서 비교하면 다음 로그 위치가 바로 정해진다.

pooling 문제와 Direct VPC egress, NAT 포트 고갈 신호를 나눠 보는 triage 표다.

이 표는 pooling과 retry 우선순위 글 다음 단계의 분기표로 쓸 수 있다. retry를 줄였는데도 남은 spike가 어디 층에서 생기는지 좁히는 용도다.

마지막 자료는 관찰 로그 예시다. pool acquire time, new connection count, egress destination, NAT 관련 경고 지표를 한 줄에 남기면 spike를 재현했을 때 어디부터 다시 볼지 빨라진다.

Cloud Run latency spike를 pooling 층과 egress 층으로 나눠 기록하는 로그 예시다.

이런 로그를 남겨 두면 handler runtime과 downstream I/O 분리 글, multi-vCPU와 concurrency 글과도 자연스럽게 이어진다. 애플리케이션 내부와 네트워크 외부를 같은 축으로 두지 않게 된다.

5. 주의사항과 리스크

첫 번째 리스크는 Direct VPC egress의 연결 수립 지연을 애플리케이션 warm-up만의 문제로 오해하는 것이다. 두 번째 리스크는 burst 지연을 NAT 포트 압박 가설 없이 retry 설정만으로 계속 튜닝하는 것이다. 세 번째 리스크는 new connection count와 egress mode를 안 남겨 다음 장애 때 다시 같은 분기부터 시작하는 것이다.

운영 전에 최소한 남겨야 할 것은 egress mode, destination, new connection count, first-connection latency, NAT 관련 경고 신호다. 이 다섯 가지가 있어야 네트워크 경로 층을 애플리케이션 로그와 분리해서 읽을 수 있다.

• retry를 더 줄이기 전에 egress path와 NAT 층을 먼저 본다.
• first connection과 burst spike를 같은 원인으로 보지 않는다.
• new connection count와 egress mode를 항상 남긴다.

6. 결론

Cloud Run에서 pooling 조정 뒤에도 latency spike가 남는다면 다음 진단 축은 애플리케이션 안쪽이 아니라 egress path와 NAT ports다. Direct VPC egress의 연결 수립 지연과 Cloud NAT port pressure를 먼저 분리해 봐야 retry 조정이 실제 원인에 닿는다. 남은 spike를 네트워크 경로 층으로 따로 떼어 보는 편이 가장 빠르다.

• 첫 연결 지연이면 Direct VPC path를 먼저 의심한다.
• burst spike면 NAT port pressure와 connection churn을 본다.
• 그 뒤에만 retry와 timeout을 다시 조정한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/networking-best-practices
2. https://docs.cloud.google.com/run/docs/configuring/vpc-direct-vpc
3. https://docs.cloud.google.com/nat/docs/ports-and-addresses
4. https://docs.cloud.google.com/nat/docs/troubleshooting