Mar 24, 2026

마지막 업데이트 Mar 30, 2026

GCP Cloud Run revision not ready: 먼저 확인할 것들

Cloud Run revision이 not ready 상태에 머문다면, 대개 Cloud Run 자체 장애라기보다 container startup failure, 잘못된 port binding, config drift, dependency 대기 때문에 revision이 healthy 상태에 도달하지 못한 경우가 많습니다.

짧게 말하면, scaling이나 cold-start 설정을 바꾸기 전에 revision log와 startup 동작부터 보고, 컨테이너가 기대한 port에 제대로 bind 하는지 확인한 뒤, 마지막 healthy revision과 차이를 비교하는 것이 가장 빠릅니다.

먼저 “느리지만 결국 뜨는가”와 “아예 ready가 되지 않는가”를 구분하세요

실무에서는 아래 두 상황이 자주 섞입니다.

서비스는 결국 healthy가 되지만 첫 요청이 느린 경우
revision이 끝내 healthy 상태가 되지 못해 트래픽을 받지 못하는 경우

진짜 revision not ready 문제는 두 번째입니다. 결국 뜨기는 하는데 느리기만 하다면 GCP Cloud Run cold start를 보는 편이 맞습니다.

revision이 ready가 되지 않는 흔한 이유

1. container가 기대한 port에 listen 하지 않음

Cloud Run은 애플리케이션이 제공된 port에 맞게 bind 하길 기대합니다. 다른 port를 쓰거나 잘못된 interface에만 bind 하면 readiness가 끝나지 않습니다.

2. startup 중 서비스가 healthy 상태에 도달하기 전에 실패함

잘못된 config, 누락된 env var, missing secret, dependency failure는 트래픽 허용 전 startup을 끊어버릴 수 있습니다.

3. main process가 너무 일찍 종료됨

container가 잠깐 떴다가 serving 대신 종료되면 revision은 안정화되지 못합니다.

표면은 Cloud Run 문제처럼 보여도 본질은 startup failure에 가깝습니다.

4. initialization이 너무 느리거나 어딘가에서 block 됨

무거운 startup 작업, remote config fetch, 긴 database handshake, 다른 서비스 대기가 readiness를 오래 지연시킬 수 있습니다.

5. revision 사이 설정이나 가정이 바뀜

memory 설정, startup command, secret mount, env drift, dependency version 변경은 이전 revision이 멀쩡했어도 새 revision만 망가뜨릴 수 있습니다.

실전 점검 순서

1. 무엇보다 revision log부터 읽으세요

기본 명령은 아래와 같습니다.

gcloud run revisions describe <revision> --region <region>
gcloud logging read 'resource.type="cloud_run_revision"' --limit 50
gcloud run services describe <service> --region <region>

여기서 startup failure인지, port binding 문제인지, permission인지, config drift인지 대개 윤곽이 잡힙니다.

2. container가 기대한 port에 bind 하는지 확인하세요

이건 여전히 가장 신호가 강한 점검입니다. 앱은 Cloud Run이 기대하는 port와 방식으로 listen 해야 합니다.

이 가정이 틀리면 아무리 다시 배포해도 revision은 ready 상태가 되지 않습니다.

3. 실패한 revision과 마지막 healthy revision을 비교하세요

특히 아래 차이를 봐야 합니다.

command나 entrypoint
env var와 secret
memory, CPU 설정
dependency나 image 변경
startup log와 초기화 동작

전체 배포 구성을 처음부터 다시 읽는 것보다 빠를 때가 많습니다.

4. 앱이 exit 하는지, hang 하는지, dependency를 기다리는지 구분하세요

top-level 오류는 비슷해도 실제 경로는 다릅니다.

startup failure로 빨리 종료되는 경우
프로세스는 살아 있지만 ready 상태가 되지 않는 경우
missing dependency나 remote call을 기다리다 멈춰 있는 경우

이 분기를 먼저 알아야 scaling knob을 잘못 만지지 않게 됩니다.

5. 그다음에야 startup latency와 resource tuning을 보세요

config와 port binding이 맞다면 그때 startup이 너무 무거운지, dependency initialization이 너무 느린지 확인하면 됩니다.

결국 healthy가 되긴 하는데 늦다면 readiness failure가 아니라 cold-start 쪽에 더 가깝습니다.

패턴을 찾은 뒤 어떻게 바꿀지

앱이 잘못된 port나 interface에 bind 하는 경우

애플리케이션 startup이나 container 설정을 고쳐서 기대한 port와 address에 listen 하도록 해야 합니다.

config drift 때문에 startup이 깨진 경우

마지막 healthy revision과 비교해서 env var, secret, mounted resource, command 변경을 바로잡으세요.

process가 startup 중 종료되는 경우

Cloud Run scaling 문제로 보지 말고 container startup failure로 접근해야 합니다.

같은 image가 다른 runtime에서도 실패한다면 Docker container keeps restarting와 함께 보는 편이 좋습니다.

startup 작업이 너무 무거운 경우

초기화 비용을 줄이고 첫 요청 경로를 정리하세요. 결국 healthy는 되는데 늦다면 GCP Cloud Run cold start가 더 맞는 가이드입니다.

startup 중 다른 GCP 서비스 접근에서 실패하는 경우

이 단계에서는 permission과 service account 문제가 자주 나오므로 GCP Permission Denied도 같이 확인하세요.

빠른 체크리스트

Cloud Run revision이 not ready에 머물 때는 아래 순서가 가장 좋습니다.

revision log와 condition을 읽는다
앱이 기대한 port에 bind 하는지 확인한다
실패한 revision과 마지막 healthy revision을 비교한다
앱이 exit, hang, dependency wait 중 어느 경로인지 구분한다
그다음에야 startup latency와 resource tuning을 본다

FAQ

Q. not ready revision은 항상 port 문제인가요?

아닙니다. port mismatch가 흔하긴 하지만, bad config, missing permission, early process exit, dependency wait도 같은 증상을 만듭니다.

Q. 가장 빠른 첫 단계는 무엇인가요?

실패한 revision의 startup log를 읽고 port binding 동작을 확인하는 것입니다.

Q. 이전 revision은 잘 됐는데 새 revision만 실패하는 이유는 뭔가요?

config, image 내용, env var, startup logic의 작은 차이만으로도 readiness가 깨질 수 있기 때문입니다.

Q. 이게 cold start인지 아닌지는 어떻게 구분하나요?

revision이 결국 healthy가 되고 첫 요청만 느리다면, readiness failure보다 cold-start 혹은 startup-cost 문제일 가능성이 큽니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.