[Cloud Run][운영] capacity를 풀어도 timeout이 남을 때 startup latency와 request timeout을 어떤 순서로 다시 줄이나

카테고리 없음 2026. 7. 10. 20:20

IT 리서치 노트

[Cloud Run][운영] capacity를 풀어도 timeout이 남을 때 startup latency와 request timeout을 어떤 순서로 다시 줄이나

Cloud Run에서 max instances를 올리고 min instances도 열었는데 여전히 504 timeout이 이어지면, 많은 팀이 바로 request timeout부터 올린다. 하지만 2026년 7월 10일 기준 공식 문서를 다시 보면 Cloud Run timeout 문제는 startup latency, 요청 대기 구간, single-core 병목, 실제 request execution time이 서로 다른 층으로 나뉜다. startup CPU boost와 minimum instances는 startup latency 축의 해법이고, request timeout은 핸들러 실행 시간이 문제일 때의 해법이다. 이 글은 capacity를 이미 풀었는데도 timeout이 남는 상황에서 startup latency와 request timeout을 어떤 순서로 다시 줄여 봐야 하는지 정리한 것이다.

1. 개요

결론부터 말하면 capacity를 풀어도 timeout이 남을 때는 request timeout부터 올리기보다 먼저 startup latency와 실제 handler runtime을 분리하는 편이 맞다. Cloud Run 문서는 timeout이 나면 504를 반환하지만 인스턴스가 계속 작업을 이어갈 수 있다고 설명하고, startup contract와 general tips는 startup CPU boost, minimum instances, concurrency가 startup latency를 줄이는 축이라고 말한다. 반면 request timeout은 실제 handler 실행 시간이 길 때의 조정 축이다.

이미 429 뒤 timeout 글이 startup probe와 CPU boost를 먼저 보라고 했다면, 이번 글은 그 분기를 더 넓게 받아 capacity를 이미 풀었는데도 timeout이 남는 상황까지 확장하는 허브다. 또 startup probe timeout 글과 max instances와 concurrency 503 글의 사이를 메운다.

같은 축을 더 좁혀서 보고 싶다면 2026-07-12 후속 글인 concurrency를 낮췄는데도 latency가 남을 때 handler runtime과 downstream I/O를 먼저 분리하는 순서를 바로 이어서 보는 편이 좋다. 이 글이 startup latency와 timeout의 큰 분기라면, 후속 글은 concurrency 조정 뒤에도 남는 지연을 애플리케이션 계산 시간과 외부 I/O 대기로 더 세밀하게 가른다.

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

현장에서 자주 생기는 오해는 세 가지다. 첫째, 인스턴스 수를 늘렸는데도 504가 나면 timeout 숫자부터 키우면 된다고 생각한다. 둘째, startup CPU boost나 minimum instances를 켰으니 이제 startup latency는 원인이 아니라고 단정한다. 셋째, 평균 CPU가 낮게 보이면 CPU 병목은 아니라고 본다.

하지만 공식 문서를 붙여 읽으면 구조가 다르다. request timeout 문서는 응답이 제때 안 오면 504가 반환되고, 인스턴스는 종료되지 않을 수 있어 뒤 요청까지 간섭할 수 있다고 설명한다. runtime contract는 새 인스턴스가 4분 안에 준비되어야 하고, 요청이 startup time의 3.5배 또는 10초까지 대기할 수 있다고 말한다. general tips는 startup CPU boost, minimum instances, concurrency를 startup latency 완화 카드로 제시한다. troubleshooting은 multi-vCPU 환경에서 단일 코어만 꽉 차면 평균 CPU가 낮아 scaling이 덜 일어날 수 있다고 짚는다.

즉 capacity를 올린 뒤에도 timeout이 남는 상황은 크게 세 갈래다. 새 인스턴스가 늦게 떠서 첫 요청이 오래 대기하는 경우, 인스턴스는 빨리 떴지만 핸들러가 실제로 오래 돌아 timeout에 걸리는 경우, 또는 vCPU/concurrency 모델이 scale signal을 약하게 만들어 이미 capacity를 열었어도 체감상 확장이 안 되는 경우다. 이 세 갈래를 안 나누면 timeout 숫자만 올리고 원인은 그대로 남게 된다.

증상: max instances와 min instances를 올렸는데도 504가 이어진다.
실패: request timeout부터 바로 상향한다.
막힘: startup latency와 handler runtime, CPU/concurrency 병목을 같은 원인으로 본다.
누락: 평균 CPU가 낮아도 단일 코어 병목일 수 있다는 문장을 놓친다.

질문	먼저 볼 값	이유
대기 중인가 실행 중인가	startup latency vs handler time	조치 축이 완전히 다르다
capacity를 늘렸는데 왜 안 풀리나	vCPU 평균과 concurrency	단일 코어 병목이면 autoscaling 신호가 약해진다
boost를 켤 가치가 있나	cold start 비중과 startup time	추가 과금과 맞바꾸는 카드다

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

가장 덜 꼬이는 순서는 다섯 단계다. 먼저 실제 실패가 새 인스턴스 대기인지, 이미 뜬 인스턴스의 handler runtime인지 구분한다. 두 번째로 startup latency 쪽이면 startup CPU boost, minimum instances, 초기화 경량화, startup probe 흐름을 본다. 세 번째로 handler runtime 쪽이면 request timeout을 무작정 올리기 전에 외부 API 대기, payload 크기, DB 응답 시간, cleanup 누수를 줄인다. 네 번째로 평균 CPU가 낮은데도 지연이 크면 multi-vCPU + single-thread 조합인지 보고 concurrency를 낮추거나 1 vCPU로 줄이거나 worker 구조를 바꾼다. 다섯 번째로 이 분기가 끝난 뒤에만 request timeout 상향을 최종 카드로 검토한다.

대기 시간과 실행 시간을 먼저 분리한다.
startup latency라면 boost, min instances, 초기화 경량화를 본다.
handler runtime이라면 외부 대기와 payload, DB 시간을 줄인다.
CPU 평균이 낮아도 vCPU/concurrency 병목을 다시 본다.
마지막 카드로만 request timeout 상향을 검토한다.

이 순서가 좋은 이유는 timeout 상향이 원인을 고치지 못하기 때문이다. 공식 문서대로 timeout을 넘긴 요청은 인스턴스 안에서 계속 돌 수 있고, 그 실행 시간이 뒤 요청을 방해할 수 있다. startup CPU boost 역시 startup latency를 줄일 때는 효과적이지만, 이미 떠 있는 인스턴스의 긴 handler를 줄여 주지는 않는다. 그리고 multi-vCPU single-thread 앱은 평균 CPU가 낮아 보이면서도 한 코어 병목 때문에 autoscaling이 늦을 수 있으므로, max instances만 올린다고 해결되지 않는다.

운영 메모 예시

queue_wait_dominant=true|false
startup_latency_ms=estimated
handler_runtime_ms=estimated
startup_cpu_boost_enabled=true|false
vcpus=2
concurrency=80
request_timeout_seconds=300

실제 운영에서는 Cloud Logging 콘솔이나 터미널에서 요청 로그를 조회하고, 504 응답 시각과 startup latency 로그, handler 실행 시간을 나란히 확인해야 한다. 그다음 서비스 설정에서 timeout, concurrency, CPU, min instances 값을 저장해 배포 전후 결과를 비교하면 어떤 축이 원인인지 더 빨리 확인된다.

요청 로그를 조회해 504 응답, queue wait, startup latency 시간을 함께 확인한다.
콘솔 설정 화면이나 배포 명령 기록에서 timeout, CPU boost, concurrency 값을 저장한다.
오류 재현 뒤에는 DB 응답 시간과 외부 API 응답 로그를 비교해 handler runtime 원인을 분리한다.

이 일곱 칸을 남겨 두면 timeout이 startup 축인지 runtime 축인지, 아니면 scale signal 축인지 훨씬 빨리 가른다. 그러면 비용이 드는 boost와 timeout 상향도 더 신중하게 쓸 수 있다.

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

첫 자료는 Cloud Run request timeout 문서다. 여기서는 응답이 지정 시간 안에 돌아오지 않으면 네트워크 연결이 닫히고 504가 반환되며, 컨테이너 인스턴스는 종료되지 않을 수 있다고 설명한다.

Cloud Run request timeout은 응답이 늦으면 504를 반환하고, 인스턴스는 계속 작업을 이어갈 수 있다고 적고 있다.

이 한 줄 때문에 timeout 문제는 단순히 '더 오래 기다리면 된다'가 아니다. 이미 timeout을 넘긴 요청이 뒤 요청 처리까지 방해할 수 있어, request timeout 조정 전에 실제 지연 축을 먼저 나눠야 한다.

두 번째 자료는 general tips의 startup latency 구간이다. Cloud Run은 startup CPU boost와 minimum instances, concurrency 조합으로 startup 시간을 줄일 수 있다고 설명한다.

Cloud Run general tips는 startup CPU boost, minimum instances, concurrency를 startup latency 축에서 같이 보라고 안내한다.

즉 capacity를 풀었는데도 timeout이 남는다면, 이미 instance 수보다 startup latency가 더 큰 병목일 수 있다는 뜻이다. timeout을 먼저 올리기 전에 cold start와 queue 구간을 분리해야 한다.

세 번째 자료는 container runtime contract의 startup 구간이다. 서비스 인스턴스는 시작 후 4분 안에 요청을 받을 준비가 되어야 하고, 요청은 startup time의 3.5배 또는 10초까지 대기할 수 있다고 적혀 있다.

Cloud Run startup contract는 인스턴스 준비 시간과 요청 대기 구간의 상한을 같이 보여 준다.

따라서 새 인스턴스가 늦게 떠서 쌓이는 지연과, 이미 떠 있는 인스턴스의 긴 핸들러 실행은 다른 문제다. capacity를 늘렸는데도 timeout이 남는다면 이 둘을 먼저 분리해야 한다.

네 번째 자료는 troubleshooting의 high latency when CPU utilization is low 섹션이다. Cloud Run은 multi-vCPU 인스턴스에서 단일 코어만 꽉 차면 평균 CPU가 낮아 보여 scaling이 덜 일어날 수 있다고 설명한다.

Cloud Run troubleshooting은 CPU 평균이 낮아도 실제 단일 코어 병목 때문에 지연과 scale-up 실패가 생길 수 있다고 짚는다.

이 문장은 capacity를 이미 풀었다고 생각한 뒤에도 timeout이 남는 이유를 잘 설명한다. max instances만 올렸다고 끝나는 것이 아니라, concurrency와 vCPU 사용 방식이 scale signal 자체를 약하게 만들 수 있다.

다섯 번째 자료는 CPU limits 문서의 startup CPU boost 세부 설명이다. startup CPU boost는 인스턴스 시작 중과 시작 후 10초 동안 추가 CPU를 주고, 그 구간 과금도 따로 생긴다고 적혀 있다.

startup CPU boost는 latency를 줄이지만 시작 중과 시작 후 10초 구간의 추가 CPU 과금도 같이 만든다.

그래서 timeout 문제를 boost로 줄일 때는 latency만이 아니라 비용까지 함께 봐야 한다. startup latency가 주범일 때만 이 카드가 제대로 먹힌다.

실무에서는 504, startup latency, concurrency 병목을 하나의 표로 나눠 두는 편이 가장 빠르다. 아래 표는 capacity를 이미 열어 둔 뒤에도 timeout이 남는 상황에서 무엇부터 다시 볼지 정리한 것이다.

Cloud Run에서 capacity를 풀어도 timeout이 남을 때 startup latency와 request timeout을 나누는 triage 표다.

이 표를 쓰면 429 뒤 timeout 글, 429와 504 분리 글, max instances와 concurrency 503 글을 더 넓은 허브 문맥에서 다시 연결할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 capacity를 늘렸다는 이유만으로 startup latency 가능성을 너무 빨리 지우는 것이다. 두 번째 리스크는 startup CPU boost를 만능 카드처럼 켜고 추가 과금을 잊는 것이다. 세 번째 리스크는 평균 CPU가 낮다는 이유로 single-core 병목 가능성을 놓치는 것이다. 네 번째 리스크는 request timeout만 올려 끊겨야 할 핸들러가 더 오래 남게 두는 것이다.

운영 전에 확인할 때는 최소한 queue_wait, startup_latency, handler_runtime, vCPU/concurrency, request_timeout 다섯 축을 한 표에 두는 편이 좋다. 이 다섯 축을 분리하지 않으면 504와 cold start, scale-up 지연이 계속 한 덩어리로 섞인다.

timeout 상향은 마지막 카드여야 한다.
startup CPU boost는 startup latency가 원인일 때만 가치가 크다.
평균 CPU가 낮아도 single-core 병목은 남을 수 있다.

6. 결론

Cloud Run에서 capacity를 이미 풀었는데도 timeout이 남는다면, request timeout 숫자부터 올리기보다 startup latency와 실제 handler runtime, 그리고 vCPU/concurrency 병목을 먼저 나눠야 한다. 공식 문서 기준으로 startup CPU boost와 minimum instances는 startup 축의 카드이고, request timeout은 실행 시간이 정말 긴 경우의 카드다. 이 순서를 지키면 504를 더 짧게 줄일 수 있고, 불필요한 추가 과금도 덜 낸다.

capacity와 timeout을 이미 만졌는데도 평균 CPU는 낮고 latency만 높다면 single-thread 병목을 별도로 의심해야 한다. concurrency와 1 vCPU 재검토 순서가 필요한 경우에는 후속 글을 같이 보면 startup 축과 runtime 축을 더 명확히 분리할 수 있다.

capacity 조정 뒤에도 남는 timeout은 원인 축을 다시 나눠 본다.
startup latency와 handler runtime은 같은 문제가 아니다.
timeout 상향은 가장 마지막에 검토한다.

ABOUT ME

FullStack Lab FullStack Lab