[Cloud Run][운영] readiness probe 지연과 concurrency 포화를 503 기준으로 나누는 법

IT 리서치 노트

[Cloud Run][운영] readiness probe 지연과 concurrency 포화를 503 기준으로 나누는 법

Cloud Run에서 503이 나왔을 때 readiness probe를 먼저 볼지, concurrency 설정을 먼저 볼지 헷갈리는 경우가 많다. 2026년 6월 30일 기준 Google Cloud 공식 문서를 다시 보면 readiness probe는 트래픽 수용 시점을 제어하고, 높은 concurrency 설정 때문에 생기는 503도 별도 분기로 존재한다. 이 글은 같은 503이라도 readiness 지연과 concurrency 포화를 어떤 기준으로 갈라 봐야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloud Run의 503은 probe 문제 하나로 묶으면 안 된다. readiness probe 지연은 '트래픽에 넣을 준비가 안 됐다'는 신호에 가깝고, concurrency 포화는 '들어오는 요청량을 현재 인스턴스 구성이 못 받는다'는 신호에 가깝다. no available instance 문구까지 보이면 probe보다 capacity와 availability를 먼저 보는 편이 맞다.

이미 startup 뒤 readiness가 늦게 붙는 글이 cutover 타이밍을 다뤘다면, 이번 글은 그 503이 capacity 쪽인지까지 좁히는 단계다. 또 health check 비용 글을 봤다면, 불필요한 재시도와 인스턴스 확장이 비용으로 이어질 수 있다는 점도 같이 이해할 수 있다.

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

실무에서 많이 꼬이는 순간은 세 가지다. 첫째, 배포 직후 첫 요청이 503이라 readiness path만 본다. 둘째, 트래픽이 몰리는 시간대에 503이 났는데 timeout 값만 올린다. 셋째, 로그에 no available instance 문구가 있는데도 probe 실패로만 분류한다.

Cloud Run health checks 문서는 readiness probe가 인스턴스가 트래픽을 받을 시점을 결정한다고 설명한다. 또 readiness 실패가 일정 threshold를 넘으면 Cloud Run은 새 트래픽을 중단하고, 다시 passing 상태가 되면 트래픽을 돌려준다. 이건 인스턴스가 죽었다는 뜻과는 다르다. 반면 troubleshooting 문서는 높은 concurrency 설정 때문에 일부 요청을 처리하지 못하는 503을 별도로 설명한다.

즉 상태 코드는 같아도 읽어야 할 로그가 다르다. readiness 지연은 probe pass/fail 시각과 endpoint 준비 시점이 중요하고, concurrency 포화는 max instances와 동시성 설정, 실제 요청량이 중요하다. known issues에 나오는 no available instance 문구까지 보이면 probe보다 더 바깥쪽 인프라 상태를 먼저 볼 가능성이 높다.

• 증상: 배포 직후 첫 요청에서만 503이 난다.
• 실패: readiness 지연과 concurrency 포화를 같은 timeout 문제로 묶는다.
• 막힘: no available instance 로그를 probe 실패와 같은 표에 두지 않는다.
• 누락: capacity 설정을 안 보고 readiness path만 반복 조정한다.

증상	먼저 볼 곳	판단 기준
첫 요청 구간 503	readiness probe 시각과 startup 이후 준비 시점	probe chain 문제인지 본다
부하 시간대 503	concurrency, max instances	capacity 포화 여부를 먼저 본다
no available instance 로그	availability, billing, known issue 분기	probe보다 상위 레이어 문제일 수 있다

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

점검은 다섯 단계가 가장 빠르다. 먼저 readiness가 언제 first pass 했는지 기록한다. 두 번째로 같은 시각대의 request log에서 high concurrency 또는 no available instance 문구가 있는지 본다. 세 번째로 현재 concurrency와 max instances 값을 확인한다. 네 번째로 readiness path와 startup 성공 조건이 너무 느슨하지 않은지 재검토한다. 마지막으로 capacity 원인과 probe 원인을 서로 다른 장애 분류로 문서화한다.

1. readiness first pass 시각과 failure 횟수를 남긴다.
2. 같은 시간대 request log에서 high concurrency와 no available instance 문구를 찾는다.
3. concurrency와 max instances 값을 확인한다.
4. startup 성공 조건과 readiness path 의미를 다시 본다.
5. probe 원인과 capacity 원인을 다른 장애 유형으로 기록한다.

이 순서를 따르면 readiness 지연인데 capacity를 늘리는 실수도, 반대로 capacity 포화인데 probe timeout만 올리는 실수도 줄일 수 있다. 특히 배포 직후에는 readiness 구간 503이 많고, 트래픽 급증 시간대에는 concurrency 포화 503이 많다. 시간대와 로그 표현을 함께 보면 분기가 빨라진다.

점검 메모 예시

revision=api-00072
startup_passed_at=12:00:09
readiness_first_pass_at=12:00:16
503_window=12:00:11-12:00:15
log_high_concurrency=false
log_no_available_instance=true
next_action=check_instance_availability_and_billing

capacity 503과 readiness 503을 분리해 두면 대응도 달라진다. readiness 지연이면 endpoint 준비 시점과 startup 조건을 조정하고, concurrency 포화면 max instances 또는 concurrency를 조정하거나 부하를 분산한다. no available instance면 probe 전에 계정과 프로젝트 상태를 본다.

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

첫 화면은 readiness probe의 역할을 직접 설명하는 구간이다. 여기서는 readiness가 단순 헬스체크가 아니라 트래픽 수용 시점을 결정한다는 점을 먼저 봐야 한다.

Cloud Run 문서는 readiness probe가 인스턴스가 트래픽을 받을 시점을 정한다고 설명한다.

이 문장을 기준으로 보면 readiness 지연 503은 '앱이 죽었다'보다 '트래픽에 넣을 준비가 안 됐다'에 더 가깝다. 그래서 concurrency 포화 503과 같은 코드라도 분리해서 읽어야 한다.

두 번째 자료는 readiness가 완전히 끝나기 전에 트래픽이 섞일 수 있다는 경고 문장이다. 이 문장을 놓치면 첫 요청 503을 전부 concurrency 문제로 읽기 쉽다.

Cloud Run은 첫 readiness probe가 끝나기 전에도 새 인스턴스로 트래픽을 보낼 수 있다고 경고한다.

즉 readiness 지연은 queue, traffic cutover, 첫 요청 실패처럼 보일 수 있다. 이미 startup 뒤 readiness가 늦게 붙는 글을 읽었다면, 이번 글은 그중에서도 concurrency 503과 어떻게 갈라 볼지를 다룬다.

세 번째 화면은 troubleshooting 문서의 concurrency 503 분기다. 같은 503이어도 최대 인스턴스나 동시성 한계 때문에 생기는 경우가 별도로 있다.

Cloud Run troubleshooting 문서는 높은 concurrency 설정 때문에 일부 요청을 처리하지 못하는 503을 따로 설명한다.

이 분기를 모르고 readiness만 손보면 실제 원인이 부하 포화인데 probe만 조정하는 실수를 하게 된다. 로그에서 instance 수와 concurrency를 같이 봐야 하는 이유가 바로 여기다.

네 번째 자료는 known issues 문서에 나오는 no available instance 로그 표현이다. 이 표현은 readiness 지연보다 인스턴스 가용성 부족 쪽에 더 가깝다.

Known issues 문서는 no available instance 로그를 동반하는 429 또는 503 상황을 따로 다룬다.

실무에서는 상태 코드만 보면 둘 다 503이지만, no available instance 문구가 있으면 readiness endpoint보다는 capacity와 billing, instance availability를 먼저 보는 편이 빠르다.

이 표는 503을 readiness 지연, concurrency 포화, 가용 인스턴스 부족 세 갈래로 빠르게 나누기 위한 것이다. 같은 에러 코드라도 보는 로그와 설정이 다르다.

Cloud Run 503을 readiness와 concurrency와 instance availability로 나눈 triage 표다.

이 표를 팀 문서에 붙여 두면 배포 직후 503이 났을 때 probe만 볼지, 인스턴스 수를 볼지, spend cap이나 billing 이슈를 볼지 바로 갈린다. 운영 시간이 짧아진다.

마지막 자료는 readiness와 capacity를 같이 적는 운영 메모 예시다. 503을 한 줄로만 남기면 다음 배포 때 같은 실수가 반복된다.

Probe 시각과 capacity 신호를 함께 적는 운영 체크리스트다.

이 메모가 있으면 readiness 지연을 timeout 문제로만 볼지, concurrency 포화를 먼저 볼지를 더 빨리 결정할 수 있다. 특히 initialDelay와 timeout 글과 같이 보면 시간 예산과 부하 포화를 분리하는 데 도움이 된다.

5. 주의사항과 리스크

첫 번째 리스크는 상태 코드만 같다고 해서 모두 readiness 문제로 처리하는 것이다. 두 번째 리스크는 high concurrency 분기를 모르고 timeout만 계속 늘리는 것이다. 세 번째 리스크는 no available instance 로그가 있는데도 billing, spend cap, instance availability를 나중으로 미루는 것이다.

운영 문서에는 최소한 readiness first pass 시각, concurrency 값, max instances 값, no available instance 여부를 남겨 두는 편이 좋다. 이 네 값만 있어도 다음번 503은 훨씬 빠르게 갈라진다.

• 같은 503이라도 probe와 capacity를 분리해서 본다.
• high concurrency 문구가 있으면 timeout보다 capacity를 먼저 본다.
• no available instance는 probe보다 상위 가용성 문제일 수 있다.

6. 결론

Cloud Run의 503은 readiness probe 지연과 concurrency 포화, 가용 인스턴스 부족을 먼저 갈라 봐야 한다. readiness는 트래픽 수용 준비 문제이고, concurrency는 capacity 문제이며, no available instance는 그보다 더 상위의 availability 신호다. 로그 문구와 설정 값을 같은 표에서 보면 같은 503도 훨씬 덜 헷갈린다.

• readiness 시각과 capacity 값을 같이 본다.
• high concurrency와 no available instance 문구를 별도 분기로 둔다.
• probe 원인과 capacity 원인을 서로 다른 장애 유형으로 기록한다.

7. 참고 링크

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