-
[Cloud Run][운영] 429 뒤 timeout이 이어질 때 request timeout을 올리기 전에 startup probe와 startup CPU boost를 먼저 보는 법기타개발지식/풀스택개발 2026. 7. 7. 09:16
IT 리서치 노트
[Cloud Run][운영] 429 뒤 timeout이 이어질 때 request timeout을 올리기 전에 startup probe와 startup CPU boost를 먼저 보는 법
Cloud Run에서 429 no available instance가 한 번 지나간 뒤에도 timeout이 이어지면 많은 팀이 곧바로 request timeout부터 늘린다. 하지만 2026년 7월 7일 기준 Google 공식 문서를 다시 보면 429는 긴 startup time과 긴 request processing time을 함께 원인으로 들고 있고, request timeout에는 container startup time도 포함된다. 이 글은 429 뒤 timeout이 이어질 때 request timeout을 올리기 전에 startup probe와 startup CPU boost를 먼저 어디서 봐야 하는지 정리한 것이다.
1. 개요
결론부터 말하면 429가 진정된 뒤 timeout이 계속된다고 해서 request timeout부터 올리는 것은 순서가 자주 틀린다. 먼저 startup time이 길어졌는지, startup probe 예산 안에서 healthy가 되는지, startup CPU boost로 cold start를 줄일 수 있는지 확인하고, 그 뒤에도 실제 request runtime이 길 때만 timeout 값을 다시 본다.
이미 429 뒤 min instances와 max instances를 다시 여는 글이 capacity 복구 순서를 다뤘다면, 이번 글은 복구 뒤에도 timeout이 남는 상황을 더 좁게 본다. 또 429와 504를 나누는 글이 증상 분기라면, 오늘은 조치 우선순위다.
2. 어디서 실제로 막히는가
429 뒤 timeout이 이어질 때 현장에서 흔한 실수는 네 가지다. 첫째, capacity 이슈가 아직 끝나지 않았는데 request timeout만 늘린다. 둘째, startup이 길어 healthy 전까지 요청이 pend되는데 handler 코드가 느리다고만 본다. 셋째, startup probe budget이 부족해 revision이 계속 내려가는데 애플리케이션 타임아웃으로 읽는다. 넷째, startup CPU boost로 줄일 수 있는 cold start를 그대로 두고 request timeout만 늘린다.
Google troubleshooting 문서는 429의 원인으로 sudden traffic, long container startup time, long request processing time을 함께 적고 있다. container contract는 요청이 인스턴스를 기다리며 average startup time의 3.5배 또는 10초까지 pend할 수 있다고 설명한다. health checks 문서는 startup probe budget을 넘기면 컨테이너가 shut down된다고 말한다. 여기에 request timeout에는 container startup time도 포함된다는 설명까지 합치면, timeout을 runtime 한 가지로만 읽으면 안 된다는 점이 분명해진다.
- 증상: 429가 줄었는데도 일부 요청이 timeout이나 504로 끝난다.
- 실패: request timeout만 키우고 startup time과 probe를 다시 보지 않는다.
- 막힘: startup pending 시간을 실제 handler runtime과 구분하지 않는다.
- 누락: startup CPU boost로 줄일 수 있는 cold start 병목을 그대로 둔다.
상황 먼저 볼 곳 판단 기준 429 직후 일부 timeout이 남는다 pending queue와 startup time 인스턴스 대기가 긴지부터 본다 revision이 반복 재시작된다 startup probe budget healthy 되기 전에 컨테이너가 내려가는지 본다 cold start가 유난히 길다 startup CPU boost startup 중 CPU 부족이 병목인지 본다 3. 실무에서 적용하는 순서
가장 실용적인 순서는 네 단계다. 먼저 429 자체가 줄었는지와 max/min instances가 실제로 풀렸는지 확인한다. 두 번째로 pending queue와 startup time을 본다. 세 번째로 startup probe budget과 startup CPU boost를 조정해 startup path를 안정화한다. 마지막으로 그 뒤에도 실제 request runtime이 길 때만 request timeout 값을 올리거나 handler 자체를 줄인다.
- capacity recovery가 끝났는지 본다.
- pending queue와 startup time이 실제 timeout의 앞단인지 본다.
- startup probe budget과 startup CPU boost로 startup path를 먼저 안정화한다.
- 그래도 남는 실제 runtime에만 request timeout과 코드 최적화를 적용한다.
콘솔 화면에서는 Metrics와 Logs를 먼저 열고, Cloud Run 서비스의 Health checks 메뉴에서 startup probe 필드와 timeout 필드를 같이 확인하는 편이 좋다. 그다음 Configure 화면에서 startup CPU boost 설정을 보고, Request timeout 필드 값을 마지막에 비교해야 조치 순서가 뒤집히지 않는다. 메뉴, 필드, 로그, 결과를 같은 표로 남겨 두면 이후 배포 때도 다시 확인하기 쉽다.
- 콘솔에서 Metrics를 클릭하고 pending queue와 request 수치를 확인한다.
- Logs를 열고 startup 로그, probe 로그, 429 응답, 504 응답을 비교한다.
- Health checks 메뉴를 열고 startup probe 필드, timeout 필드, threshold 값을 입력한 현재 설정을 확인한다.
- Configure 화면에서 startup CPU boost 설정을 조회하고 이전 배포와 비교한다.
- Request timeout 필드는 마지막에만 입력하거나 변경하고, 변경 뒤 새 응답 결과를 다시 확인한다.
gcloud run services update SERVICE_NAME --region=REGION --timeout=300 --startup-probe=httpGet.path=/health,httpGet.port=8080,periodSeconds=10,timeoutSeconds=5,failureThreshold=12 # compare next: # 1) request count / pending queue metrics # 2) startup logs # 3) probe result # 4) only then request timeout field여기서 request timeout을 바로 올리면 startup 병목을 느리게 드러나게 할 수는 있어도, startup이 healthy 전까지 오래 걸리는 구조 자체는 바뀌지 않는다. 공식 문서는 request timeout에 container startup time도 포함된다고 말하므로, startup 문제가 해결되지 않은 상태에서 timeout 값만 늘리면 비용과 대기 시간만 길어질 수 있다.
4. 공식 문서와 예시 화면으로 확인하기
첫 자료는 429 no available instance 설명 구간이다. Google은 이 오류의 원인을 sudden traffic, long container startup time, long request processing time으로 함께 적고 있다.
즉 429 뒤 timeout이 이어졌다고 해서 곧바로 handler 시간이 길다고 단정하면 안 된다. startup 경로가 아직 불안정한데 request timeout만 올리는 경우가 많다.
두 번째 자료는 pending queue 규칙이다. Cloud Run은 인스턴스를 기다리는 요청이 average startup time의 3.5배 또는 10초까지 pend할 수 있다고 설명한다.
이 규칙을 보면 429 직후의 timeout은 handler 본문보다도, 아직 인스턴스가 준비되기 전 대기와 startup 자체가 길어진 신호일 수 있다.
세 번째 자료는 startup probe 예산이다. Cloud Run은 startup probe가 설정된 시간 안에 성공하지 못하면 컨테이너를 내린다고 명시한다.
따라서 timeout 증상이 request timeout 값 때문인지, startup probe budget 안에서 아직 healthy가 안 되는지 먼저 나눠야 한다. probe 실패를 timeout으로만 읽으면 revision이 반복 재시작되는 이유를 놓친다.
네 번째 자료는 startup CPU boost 설명이다. Cloud Run은 startup 중과 시작 후 10초 동안 추가 CPU를 줄 수 있다고 안내한다.
이 기능은 request timeout을 늘리는 것과 역할이 다르다. startup CPU boost는 cold start와 초기 준비 구간을 줄이는 장치이고, timeout 증상을 줄일지부터 먼저 확인할 수 있는 손잡이다.
다섯 번째 자료는 request timeout 자체의 의미다. Cloud Run은 서비스가 요청을 받은 뒤 response를 보내야 하는 시간에 container startup time도 포함된다고 적고 있다.
그래서 startup이 느린 상태에서 request timeout만 올리면 문제를 늦게 드러나게 할 뿐, startup path의 병목이 그대로 남을 수 있다. 이미 429 뒤 min instances와 max instances를 다시 여는 글이 capacity 복구를 다뤘다면, 이번 글은 그 다음 단계인 timeout 진단 순서다.
마지막 자료는 429 회복 뒤 timeout 분리 순서를 표로 정리한 것이다. capacity, startup, probe, request runtime을 한 줄에 묶어 보면 어디서부터 손대야 하는지 바로 좁혀진다.
이 표가 있으면 request timeout을 바로 늘릴지, startup CPU boost를 켤지, startup probe budget을 조정할지, 실제 handler latency를 최적화할지 순서가 잡힌다. 429와 504를 나누는 글이 증상 분기를 다뤘다면, 이번 표는 조치 우선순위다.
5. 주의사항과 리스크
startup probe를 너무 타이트하게 두면 healthy 직전마다 컨테이너가 내려가서 429 뒤 timeout이 계속 꼬일 수 있다. 반대로 request timeout만 크게 잡아 두면 느린 startup이나 외부 의존성 병목이 오래 숨어 버린다. startup CPU boost도 모든 문제를 해결해 주는 것은 아니므로, 이미지 크기, 초기화 시점, 외부 연결 지연은 여전히 별도로 봐야 한다.
- 주의: capacity 복구 전에 timeout만 키우면 429와 timeout 원인이 같이 섞인다.
- 주의: startup probe budget이 부족한지 먼저 보지 않으면 revision restart를 놓친다.
- 리스크: startup CPU boost가 필요 없는 경로인데 무조건 켜면 원인 파악 범위가 불명확해질 수 있다.
- 리스크: 실제 handler runtime이 긴데도 startup만 의심하면 잘못된 최적화로 이어질 수 있다.
6. 결론
Cloud Run에서 429 뒤 timeout이 이어질 때는 request timeout을 늘리기 전에 startup path부터 다시 봐야 한다. pending queue, startup probe, startup CPU boost, 그리고 startup time이 request timeout 안에 포함된다는 사실을 먼저 정리하면, timeout 값을 언제 손대야 하는지 훨씬 분명해진다.
capacity 복구 쪽 선행 글로는 429 뒤 min instances와 max instances 복구 순서를 같이 보는 편이 좋고, 증상 분기가 헷갈릴 때는 429와 504를 나누는 글이 앞단이 된다.
7. 참고 링크
'기타개발지식 > 풀스택개발' 카테고리의 다른 글
