[Cloud Run][운영] Direct VPC egress에서 startup probe를 egress 연결 확인으로 바꿨는데도 첫 요청이 느릴 때 어떤 NAT 지표를 같이 보나

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

IT 리서치 노트

[Cloud Run][운영] Direct VPC egress에서 startup probe를 egress 연결 확인으로 바꿨는데도 첫 요청이 느릴 때 어떤 NAT 지표를 같이 보나

Cloud Run에서 Direct VPC egress를 쓰며 startup probe를 단순 앱 health check가 아니라 egress 연결 확인으로 바꿨는데도 첫 요청이 느리면 많은 팀이 다시 애플리케이션 초기화 코드만 본다. 하지만 2026년 7월 13일 기준 Google Cloud 문서를 다시 보면 Direct VPC egress 문서는 egress destination 연결을 시험하는 HTTP startup probe를 권장하고, Cloud NAT 문서는 port usage와 allocation error, dropped packet 지표를 함께 보라고 말한다. 이 글은 probe를 바꾼 뒤에도 첫 요청이 느릴 때 어떤 NAT 지표를 같이 봐야 하는지 정리한 것이다.

1. 개요

결론부터 말하면 Direct VPC egress에서 startup probe를 egress 연결 확인으로 바꿨는데도 첫 요청이 느리다면, 다음 진단 축은 앱 코드보다 Cloud NAT 지표다. probe가 통과했다면 적어도 한 번의 연결 확인은 끝났다는 뜻이므로, 남은 지연은 Port usage, NAT allocation errors, Dropped sent packets 같은 포트 압박 신호에서 먼저 구분해 보는 편이 빠르다.

이미 Direct VPC egress와 NAT 포트 고갈 순서 글이 남은 spike를 네트워크 경로 층으로 분리했다면, 이번 글은 startup probe를 실제 egress 연결 확인으로 바꾼 뒤에도 왜 첫 요청이 느릴 수 있는지 한 단계 더 좁혀 읽는 후속편이다.

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

현장에서 자주 꼬이는 지점은 네 가지다. 첫째, startup probe를 붙였으니 네트워크 경로 문제는 끝났다고 생각한다. 둘째, probe가 /healthz만 확인해 실제 외부 연결 준비와 무관한데도 readiness가 끝났다고 해석한다. 셋째, probe 통과 뒤 첫 요청 지연을 앱 warm-up으로만 설명한다. 넷째, burst 순간 포트 압박이 생겼는지 NAT 대시보드를 같이 안 본다.

Direct VPC egress 문서는 인스턴스 startup 시 연결 수립 지연이 길 수 있으며 egress destination 연결을 시험하는 HTTP startup probe를 권장한다. health checks 문서는 startup probe가 readiness까지 함께 보장하도록 설계하라고 적는다. NAT monitoring 문서는 Port usage, NAT allocation errors, Dropped sent packets rate 같은 기본 지표를 제공한다. troubleshooting 문서는 포트 부족 시 OUT_OF_RESOURCES와 dynamic port allocation 도중 드롭이 생길 수 있다고 설명한다. 이 넷을 같이 놓으면 probe 통과 뒤 남는 첫 요청 지연은 NAT 지표를 같이 읽지 않으면 안 된다는 점이 분명해진다.

증상: startup probe는 통과하지만 첫 요청만 느리다.
실패: 앱 health endpoint만 보고 egress 준비가 끝났다고 본다.
막힘: NAT port usage와 dropped packets를 같은 화면에서 안 본다.
누락: burst 시점의 allocation error를 request 로그와 맞물려 보지 않는다.

상황	먼저 볼 것	판단 기준
probe가 늦게 성공한다	egress probe path와 threshold	연결 확인 자체가 느린지 본다
probe는 빠른데 첫 요청만 늦다	Port usage와 allocation errors	포트 압박이 뒤늦게 올라오는지 본다
burst 순간만 지연이 튄다	Dropped sent packets와 OUT_OF_RESOURCES	동적 포트 할당 중 드롭인지 본다

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

실무에서는 다섯 단계가 실용적이다. 먼저 startup probe가 실제 egress destination 연결을 확인하도록 만든다. 두 번째로 probe 성공 시점과 첫 요청 시작 시점을 같은 trace에 남긴다. 세 번째로 같은 시각대의 NAT Port usage와 allocation errors를 본다. 네 번째로 burst 구간이면 Dropped sent packets와 OUT_OF_RESOURCES를 확인한다. 마지막으로 포트 압박이 보이면 retry 튜닝보다 min ports와 동적 포트 할당 전략을 먼저 검토한다.

startup probe를 실제 egress 연결 확인으로 만든다.
probe 성공 시점과 첫 요청 시점을 같은 trace로 묶는다.
Port usage와 NAT allocation errors를 같이 본다.
burst 구간에서는 dropped packets와 OUT_OF_RESOURCES를 확인한다.
포트 압박이 보이면 NAT 설정 검토를 먼저 한다.

이 순서를 쓰면 probe와 NAT를 서로 다른 층으로 분리할 수 있다. probe가 늦으면 egress 연결 자체가 느린 것이고, probe는 통과했는데 첫 요청만 늦으면 포트 할당과 burst 압박 가능성이 더 커진다. 앱 로그와 NAT 대시보드를 같은 타임라인에서 묶는 편이 특히 중요하다.

startup probe trace 예시

probe_passed_at=2026-07-13T13:08:20+09:00
first_request_started_at=2026-07-13T13:08:23+09:00
nat_port_usage=84%
nat_allocation_errors=0
dropped_sent_packets_reason=NONE

이렇게 남겨 두면 probe 통과 후 남는 지연이 warm-up인지 NAT 포트 압박인지 더 빨리 자를 수 있다. Direct VPC egress에서는 startup probe 하나만 좋아져도 끝난다는 가정이 가장 위험하다.

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

첫 자료는 Direct VPC egress 문서의 핵심 권고다. Google Cloud는 인스턴스가 요청을 받기 전에 egress destination 연결을 시험하는 HTTP startup probe를 권장한다. 즉 이 시점의 startup probe는 앱 내부 health endpoint보다 네트워크 경로 확인 역할이 더 크다.

Direct VPC egress 문서는 요청 수락 전 egress destination 연결을 시험하는 HTTP startup probe를 권장한다.

따라서 첫 요청 지연을 줄이려면 단순한 /healthz보다 실제 DB나 내부 API까지 닿는 연결 확인이 필요할 수 있다. 그러나 probe를 이렇게 바꿔도 느리다면 그다음은 NAT 지표를 같이 봐야 한다.

두 번째 자료는 Cloud Run health checks 문서다. Google Cloud는 startup probe가 readiness까지 함께 책임지도록 로직을 감싸는 편을 권장한다. 즉 probe가 통과했다면 새 인스턴스가 즉시 트래픽을 안전하게 받을 준비가 끝났어야 한다.

Cloud Run health checks 문서는 startup probe가 readiness까지 함께 보장하도록 설계하라고 권장한다.

이 권고를 따라도 첫 요청만 느리다면 앱 로딩보다 네트워크 자원, 특히 NAT 포트 압박을 의심할 근거가 생긴다. probe가 통과했는데도 지연이 남는다면 준비 완료 판단과 실제 외부 연결 용량이 어긋난 것이다.

세 번째 자료는 Cloud NAT monitoring 문서의 predefined dashboard 목록이다. Google Cloud는 port usage, NAT allocation errors, dropped sent packets rate를 기본 대시보드로 제공한다. startup probe를 바꾼 뒤에도 첫 요청이 느리면 이 지표들이 실제로 튀는지 같이 봐야 한다.

Cloud NAT monitoring 문서는 Port usage, NAT allocation errors, Dropped sent packets rate 같은 기본 지표를 제공한다.

이 지표를 같이 보지 않으면 첫 요청 지연을 애플리케이션 warm-up으로만 오해하기 쉽다. 네트워크 경로가 이미 probe를 통과했더라도 포트 할당 압박은 이후 요청에서 따로 튈 수 있다.

네 번째 자료는 Cloud NAT troubleshooting 문서다. 이 문서는 포트가 부족하면 dropped_sent_packets_count reason이 OUT_OF_RESOURCES가 될 수 있고, dynamic port allocation이 포트 부족에 가까워질 때 포트를 늘리지만 그 사이 드롭이 생길 수 있다고 설명한다.

Cloud NAT troubleshooting 문서는 포트 부족 시 OUT_OF_RESOURCES와 동적 포트 할당 중 드롭 가능성을 직접 설명한다.

따라서 첫 요청 지연이 burst 시점과 겹친다면 probe 성공 여부만으로는 부족하다. NAT가 포트를 늘리는 동안 드롭이 생기는지, allocation error가 같이 올라가는지 봐야 앱 warm-up과 포트 압박을 구분할 수 있다.

실무에서는 triage 표를 먼저 붙여 놓는 편이 가장 빠르다. probe가 무엇을 확인해야 하는지와, probe 통과 뒤에도 남는 지연에서 어떤 NAT 지표를 볼지 같은 표에 묶어 두면 장애 때 다시 헤매지 않는다.

Direct VPC startup probe와 Cloud NAT 지표를 함께 읽는 triage 표다.

이 표를 기준으로 보면 Direct VPC egress와 NAT 포트 고갈 순서 글이 네트워크 경로와 포트 압박을 먼저 나눴다면, 이번 글은 startup probe를 실제 egress 확인으로 바꾼 뒤 남는 첫 요청 지연을 더 좁혀 읽는 후속편이다.

5. 주의사항과 리스크

첫 번째 리스크는 startup probe가 readiness를 함께 보장해야 한다는 권고를 무시하고 단순 process up 신호만 보는 것이다. 두 번째 리스크는 NAT 대시보드를 안 보고 첫 요청 지연을 전부 앱 초기화로 설명하는 것이다. 세 번째 리스크는 dynamic port allocation 중 드롭 가능성을 모르고 retry 숫자만 더 키우는 것이다.

운영 전에 확인할 것은 네 가지다. probe가 실제 egress destination까지 확인하는지, probe 통과 시각과 첫 요청 시각이 얼마나 떨어지는지, Port usage와 allocation errors가 같은 시각에 튀는지, dropped packet reason에 OUT_OF_RESOURCES가 보이는지다. 이 네 항목이 없으면 첫 요청 지연을 같은 카테고리로 묶어 버리게 된다.

startup probe 통과는 앱 준비와 네트워크 준비가 모두 끝났는지 의미해야 한다.
NAT 지표를 안 보면 첫 요청 지연을 warm-up으로 오해하기 쉽다.
burst 지연은 dropped packets와 allocation errors를 같이 읽는다.

6. 결론

Direct VPC egress에서 startup probe를 egress 연결 확인으로 바꿨는데도 첫 요청이 느리다면, 다음 의심 지점은 Cloud NAT 지표다. probe가 통과한 뒤 남는 지연은 Port usage, NAT allocation errors, Dropped sent packets를 함께 봐야 warm-up과 포트 압박을 구분할 수 있다. Cloud Run에서 probe와 NAT는 같은 장애를 다른 층에서 설명한다.

여기까지 지표는 모였는데 실제로 min ports per VM과 max ports per VM을 어떤 값으로 둘지 막힌다면, 다음 단계는 Cloud NAT 동적 포트 min/max 결정 순서 글로 이어서 보면 된다. 이 글이 NAT 지표 축이라면 저 글은 그 지표를 설정값으로 바꾸는 운영 기준이다.

startup probe는 실제 egress destination 연결까지 확인하게 만든다.
probe 통과 뒤 남는 지연은 NAT 대시보드로 먼저 자른다.
burst 시점에는 OUT_OF_RESOURCES와 dropped packets를 같이 본다.

ABOUT ME

FullStack Lab FullStack Lab