[Cloud Run][운영] startup probe 뒤 readiness probe가 늦게 붙을 때 503을 해석하는 순서

IT 리서치 노트

[Cloud Run][운영] startup probe 뒤 readiness probe가 늦게 붙을 때 503을 해석하는 순서

Cloud Run에서 startup probe는 통과했는데 readiness probe가 뒤늦게 붙거나 새 트래픽을 받지 못하는 상황은 겉으로 보면 모두 503처럼 보이기 쉽다. 하지만 2026년 6월 30일 기준 Google Cloud 공식 문서를 다시 보면, readiness는 startup 성공 뒤에 시작되고, Cloud Run은 startup 성공이 곧 즉시 안전한 트래픽 수용을 의미하도록 설계하라고 권한다. 이 글은 startup 이후 readiness가 늦게 붙는 분기에서 503을 어떤 순서로 해석해야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 startup probe가 통과한 뒤 readiness가 늦게 붙는 상황은 timeout 하나로 설명되지 않는다. startup 성공 조건이 너무 느슨해서 실제 준비 전 200을 내는 경우, readiness endpoint가 느리게 뜨는 경우, 503 자체가 probe 문제가 아니라 concurrency 한계인 경우를 먼저 분리해야 한다. readiness 지연을 probe chain 전체의 해석 문제로 보면 대응이 훨씬 빨라진다.

이미 startup path mismatch 글, startup port mismatch 글, initialDelaySeconds와 timeoutSeconds 조정 글을 봤다면, 오늘 글은 그 다음 단계인 traffic cutover 해석이다. readiness가 늦게 붙는다면 startup을 다시 정의해야 할 수도 있다.

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

실무에서 자주 보이는 증상은 세 가지다. 첫째, 앱 로그로는 부팅이 끝난 것처럼 보이는데 revision이 한동안 새 요청을 받지 못한다. 둘째, startup은 성공했지만 첫 사용자 요청에서 503이 나고, 잠시 뒤 다시 정상화된다. 셋째, 같은 503이라도 어떤 배포에서는 probe 지연이고 어떤 배포에서는 concurrency 한계인데, 팀 문서에는 모두 'Cloud Run가 느림'으로만 적혀 있다.

Cloud Run health checks 문서는 readiness probe가 startup probe 성공 뒤에 시작된다고 분명히 적고 있다. 또 startup probe가 readiness를 어느 정도 대신하게 설계하라고 권고한다. 즉 startup이 200을 너무 빨리 내면, 실제 앱 준비는 덜 됐는데 Cloud Run은 트래픽을 보내기 시작할 수 있다. 이런 구조에서는 readiness가 늦게 붙는 문제가 timeout 값이 아니라 endpoint 의미 정의에서 시작된다.

known issues 문서가 더 중요한 이유는 요청이 startup probe 결과가 확정되기 전 인스턴스를 깨울 수 있다고 설명하기 때문이다. 이때 요청 로그만 보면 '앱 코드가 실행됐으니 startup은 멀쩡하다'고 착각할 수 있다. 하지만 probe 타임라인은 별도로 실패할 수 있고, readiness는 그 뒤에 또 따로 늦게 붙을 수 있다. 그러니 app log, request log, probe log를 하나의 시간축으로 묶어야 한다.

• 증상: startup은 통과했는데 첫 트래픽 구간에서 503이 보인다.
• 실패: timeout만 조정하고 startup 성공 조건은 그대로 둔다.
• 막힘: probe 로그와 request 로그를 서로 다른 사건처럼 읽는다.
• 누락: 503이 concurrency 한계인지 readiness 지연인지 초반에 분리하지 않는다.

증상	먼저 볼 곳	판단 기준
startup 뒤 readiness가 늦다	startup 성공 시점과 endpoint 준비 시점	startup 성공 조건이 너무 이른지 본다
첫 요청에서만 간헐적 503이 보인다	known issue request timing	요청이 인스턴스를 깨운 것인지 분리한다
지속적인 503이 보인다	concurrency, max instances, malformed response	probe 외 원인인지 함께 본다

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

점검은 다섯 단계가 빠르다. 먼저 startup endpoint가 정말 '트래픽을 받아도 안전한 상태'에서만 200을 내는지 본다. 두 번째로 readiness endpoint가 startup 뒤 어느 시점에 준비되는지 로그로 찍는다. 세 번째로 request log, app log, probe log를 같은 타임라인으로 정렬한다. 네 번째로 503이 보이면 concurrency와 max instances, malformed response 문서도 같이 대조한다. 마지막으로 startup과 readiness의 역할을 YAML에 주석처럼 남겨 다음 배포에서 섞이지 않게 한다.

1. startup endpoint가 실제 준비 완료 전 200을 주지 않는지 본다.
2. readiness endpoint가 언제부터 200을 주는지 로그로 남긴다.
3. request, app, probe 로그를 하나의 시간축으로 맞춘다.
4. 503이면 concurrency와 malformed response 문서도 함께 대조한다.
5. startup과 readiness 역할 차이를 revision 메모에 남긴다.

이 순서를 따르면 readiness 지연 문제를 timeout 한 줄로만 다루는 실수를 줄일 수 있다. startup이 readiness 일부를 대신해야 한다는 공식 문서 문장을 기준으로 보면, 실제 대응은 endpoint 설계와 로그 관측 두 축에서 동시에 이뤄져야 한다. 그래야 다음 배포에서도 같은 문제가 재현될 때 원인 분리가 빨라진다.

운영 메모 예시

startup_success_at=12:00:09
readiness_success_at=12:00:16
first_request_received_at=12:00:11
request_before_startup_known=true
concurrency_checked=true
startup_endpoint_requires_db_ready=true

비용 해석도 잊지 않는다. readiness가 오래 붙지 않는데도 계속 새 인스턴스를 띄우거나 재시도 요청이 누적되면 간접적으로 비용이 커질 수 있다. 이 부분은 health check 비용 글을 같이 보는 편이 좋다.

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

첫 화면은 Cloud Run health checks 문서의 readiness 설명이다. 여기서는 readiness probe가 startup probe 뒤에 붙는 순서와, 실패했을 때 Cloud Run이 인스턴스를 어떻게 취급하는지 먼저 확인해야 한다.

Cloud Run 문서는 readiness probe가 startup probe 성공 뒤에 시작되고, 실패 시 새 트래픽을 중단한다고 설명한다.

이 문장 하나만으로도 'startup은 통과했는데 readiness가 늦게 붙는다'와 'startup 자체가 계속 실패한다'를 서로 다른 문제로 볼 수 있다. 이미 startup timeout과 failureThreshold 글을 읽었다면, 이번 글은 그 다음 단계인 traffic cutover 해석 쪽이다.

두 번째 자료는 같은 문서의 권고 문장이다. startup probe가 통과한 순간 바로 안전하게 트래픽을 받을 수 있도록 설계하라는 문장을 놓치면 readiness 지연을 너무 가볍게 보게 된다.

Cloud Run은 startup probe가 readiness를 어느 정도 대신하도록 설계하라고 권장한다.

즉 startup endpoint가 너무 빨리 200을 주면 readiness가 뒤늦게 실패하면서 503이 나올 수 있다. 이때는 readiness만 조정할 일이 아니라 startup 성공 조건을 더 엄격하게 바꿔야 할 수도 있다.

세 번째 화면은 Cloud Run known issues 문서다. 여기서는 probe 결과가 확정되기 전에도 서비스 요청이 인스턴스를 깨울 수 있다는 예외 상황을 함께 본다.

Cloud Run known issues 문서는 startup probe 결과가 확정되기 전 요청이 인스턴스에 할당될 수 있다고 설명한다.

이 예외를 모르고 로그를 읽으면 '앱 코드가 실행됐으니 startup은 멀쩡하다'고 착각하기 쉽다. 실제론 요청이 인스턴스를 깨웠을 뿐이고, probe 타임라인은 따로 실패했을 수 있다. 로그를 같은 시간축에 놓아야 하는 이유가 바로 여기다.

네 번째 자료는 troubleshooting 문서의 503 예시다. readiness 지연에서 보이는 503과, 최대 인스턴스나 concurrency 때문에 생기는 503은 분리해서 봐야 한다.

Cloud Run troubleshooting 문서는 503이 항상 probe 문제는 아니며 concurrency와 인스턴스 제한에서도 발생할 수 있다고 보여 준다.

이 구간이 중요한 이유는 503이라는 상태 코드만 같고 원인은 전혀 다를 수 있기 때문이다. readiness 지연을 봐야 할지, 동시성 한도를 먼저 조정해야 할지 초반에 갈라 주는 기준으로 쓸 수 있다.

설정 블록은 실제로 어디가 어긋났는지 찾는 데 가장 빠른 자료다. startup과 readiness를 같은 파일에서 나란히 보면 path, timeout, failureThreshold가 어느 역할인지 더 선명해진다.

startup probe와 readiness probe를 같이 둔 Cloud Run YAML 예시다.

앱 팀이 /startup과 /ready를 따로 두었다면 이 YAML 한 장만으로도 누가 먼저 200을 주어야 하는지 이야기할 수 있다. 이미 startup probe path mismatch 글이나 startup probe port mismatch 글을 본 상태라면, 이번 글은 그 다음 분기인 readiness cutover 해석이다.

마지막 표는 503을 처음 봤을 때 readiness 지연, concurrency 한계, malformed response를 나누기 위한 triage 표다. 같은 503이라도 보는 로그와 조치 순서는 달라진다.

Cloud Run 503을 readiness 지연과 다른 원인으로 분리하는 triage 표다.

이 표가 있으면 운영자는 먼저 봐야 할 로그를, 앱 개발자는 먼저 바꿔야 할 설정을 같은 문서에서 공유할 수 있다. '503이니 timeout을 올리자' 같은 반사 반응을 줄이는 데 가장 도움이 되는 자료다.

5. 주의사항과 리스크

첫 번째 리스크는 startup이 readiness를 어느 정도 대체해야 한다는 권고를 무시하고, startup 성공을 너무 쉽게 주는 것이다. 두 번째 리스크는 request log만 보고 startup 문제가 아니라고 단정하는 것이다. 세 번째 리스크는 503을 전부 probe 문제로만 보고 concurrency와 malformed response 분기를 놓치는 것이다.

운영 문서에는 최소한 startup 성공 기준, readiness 성공 기준, 첫 요청 시각, probe 실패 시각을 남기는 편이 좋다. 이 네 값이 있어야 다음에 비슷한 503이 나도 readiness 지연인지 다른 원인인지 빠르게 갈라진다.

• startup 성공은 실제 트래픽 안전 시점과 가깝게 둔다.
• 요청 로그와 probe 로그를 같은 시간축으로 읽는다.
• 503은 concurrency와 malformed response 분기도 함께 본다.

6. 결론

Cloud Run에서 startup probe 뒤 readiness probe가 늦게 붙는 503은 단순 timeout 이슈가 아니라 traffic cutover 해석 문제다. startup 성공 조건, readiness 준비 시점, request/probe 타임라인을 같이 보면 같은 503이라도 전혀 다른 원인으로 갈라진다. 이 순서를 문서화해 두면 다음 배포 때도 훨씬 덜 헤맨다.

• startup과 readiness의 역할을 분리해 본다.
• 첫 요청 시각과 probe 타임라인을 같이 본다.
• 503은 probe 외 원인도 같은 표에서 분기한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/healthchecks
2. https://docs.cloud.google.com/run/docs/known-issues
3. https://docs.cloud.google.com/run/docs/troubleshooting
4. https://docs.cloud.google.com/run/docs/container-contract