[Cloud Run][운영] 429 no available instance가 확인된 뒤 min instances와 max instances를 어떤 순서로 다시 열어야 하나

IT 리서치 노트

[Cloud Run][운영] 429 no available instance가 확인된 뒤 min instances와 max instances를 어떤 순서로 다시 열어야 하나

Cloud Run 로그에 `HTTP 429 The request was aborted because there was no available instance`가 찍히면 min instances를 올려야 할지 max instances를 올려야 할지부터 흔들린다. 2026년 7월 6일 기준 Google 공식 문서를 다시 보면 429는 최대 인스턴스 한도, 갑작스러운 트래픽, 긴 startup, 긴 처리 시간 중 하나로 시작할 수 있고, ACT가 실제 concurrency를 동적으로 낮출 수도 있다. 이 글은 429를 확인한 뒤 min과 max를 어떤 순서로 다시 열어야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 429 뒤 첫 판단은 instance count가 현재 cap에 닿았는가와 startup latency 때문에 warm capacity가 부족한가를 나누는 것이다. cap에 닿았다면 max instances를 먼저 보고, cap에는 안 닿았는데 scale-from-zero나 긴 startup 직후에 429가 튄다면 min instances를 검토하는 편이 맞다. 둘을 동시에 올리기 시작하면 원인을 다시 설명하기 어려워진다.

이미 429와 504 분기 글이 timeout과 capacity를 갈랐다면, 오늘 글은 capacity branch 안쪽이다. 또 ACT와 max instances 상한 글을 읽었다면 이번 글은 ACT 이후 실제 복구 레버를 min/max로 다시 나누는 단계다.

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

실무에서 제일 많이 헷갈리는 경우는 세 가지다. 첫째, 429가 떴다는 이유만으로 warm instance가 부족하다고 생각해 min instances를 먼저 올린다. 둘째, configured concurrency가 높으니 max instances만 올리면 된다고 본다. 셋째, service-level max와 revision-level max를 구분하지 않고 cap을 수정한다.

Cloud Run troubleshooting 문서는 429를 최대 인스턴스 한도나 스케일 실패 신호로 설명하고, autoscaling 문서는 ACT가 CPU 보호를 위해 실제 concurrency를 동적으로 낮출 수 있다고 적는다. 즉 눈에 보이는 설정값 하나만으로는 안 되고, instance count, startup latency, 처리 시간, ACT 가능성을 같이 봐야 한다.

또 container contract는 요청이 평균 startup time의 3.5배 또는 10초까지 pending queue에 머물 수 있다고 설명한다. 이 값보다 오래 버티지 못하고 429가 나온다면 새 인스턴스가 붙는 속도 자체가 문제일 수 있고, 이런 패턴에서는 min instances가 더 직접적인 카드가 된다. 반대로 instance count가 이미 cap 근처라면 warm instance를 더 둘 여지도 적으니 max부터 열어야 한다.

• 증상: 429가 반복되는데 instance count가 이미 상한 근처다.
• 실패: cold start 원인인지 cap 원인인지 나누지 않고 min과 max를 같이 올린다.
• 막힘: configured concurrency와 실제 concurrency를 같은 값으로 믿는다.
• 누락: service-level max와 revision-level max를 구분하지 않는다.

증상	먼저 볼 곳	판단 기준
429와 함께 instance count가 높다	max instances, quota	cap이 먼저 병목인지 본다
scale-from-zero 직후만 흔들린다	min instances, startup time	warm capacity 부족인지 본다
configured concurrency에 못 미치는데 막힌다	ACT, CPU per request	실제 concurrency가 내려간 것인지 본다

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

실무 복구 순서는 다섯 단계가 가장 짧다. 먼저 Cloud Monitoring에 들어가 Container instance count metric을 연다. 두 번째로 Cloud Run 서비스 화면에서 service-level max 값을 읽고, revision detail 화면을 열어 revision-level max 값을 비교한다. 세 번째로 Logs Explorer에서 429가 찍힌 시각을 잡고 scale-from-zero 직후인지, startup time이 길었는지, pending queue가 반복됐는지 확인한다. 네 번째로 configured concurrency가 실제로 활용되지 않는다면 ACT 영향을 의심하고 CPU per request나 concurrency 설계를 다시 본다. 마지막으로 이 결과에 따라 max 또는 min 하나만 먼저 바꾸고, 같은 지표를 다시 열어 변화를 비교한다.

1. Monitoring에서 instance count 그래프를 연다.
2. Cloud Run 서비스 화면에서 service-level max를 확인한다.
3. revision detail을 열어 revision-level max를 읽는다.
4. Logs Explorer에서 429 타임스탬프를 잡아 scale-from-zero 직후인지 확인한다.
5. startup latency와 pending queue hit를 비교한다.
6. configured concurrency와 실제 처리 패턴을 함께 본다.
7. ACT가 의심되면 CPU per request 설계를 점검한다.
8. max 또는 min 하나만 먼저 조정한다.
9. 조정 후 같은 metric과 로그를 다시 연다.

• Cloud Run 콘솔에 들어가 서비스 이름을 클릭한다.
• Service scaling 또는 revision scaling 화면을 연다.
• Edit service level scaling settings를 눌러 max 값을 확인한다.
• revision detail에서 현재 revision max 값을 읽는다.
• Logs Explorer에 들어가 429 로그 필터를 입력한다.
• time range를 줄여 burst 직후 구간을 확인한다.
• 필요하면 min 값을 1 이상으로 입력하고 저장한다.
• 필요하면 max 값을 올리고 다시 배포한다.
• 배포 뒤 metric과 로그를 다시 열어 성공과 실패를 구분한다.

정리하면 instance count가 cap에 닿았다면 max를 먼저 올리는 편이 맞고, cap에 안 닿았는데 scale-from-zero 직후 429가 튄다면 min instances를 먼저 검토하는 편이 맞다. max는 병목 상한을 여는 값이고, min은 startup 대기와 cold start 흔들림을 줄이는 값이다. 두 값은 목적이 다르다.

복구 메모 예시

429_seen=true
container_instance_count_near_cap=true
service_max_first=true
min_instances_change_deferred=true
startup_p95_ms=7400
act_may_reduce_effective_concurrency=true

비용도 같이 봐야 한다. min instances는 warm capacity를 확보하는 대신 idle 비용이 생기고, max instances는 잘못 크게 열면 예기치 않은 트래픽 급증 때 비용 노출이 커진다. 그래서 공식 문서가 service-level max를 cost-safety limit로 먼저 잡으라고 권하는 이유가 있다.

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

첫 자료는 Cloud Run troubleshooting 문서의 429 설명 구간이다. 여기서는 최대 인스턴스 한도에 걸렸거나 스케일이 유입 속도를 못 따라간 상황을 먼저 의심하라고 적고 있다.

Cloud Run troubleshooting 문서는 429 no available instance를 최대 인스턴스 한도 또는 스케일 실패 신호로 설명한다.

즉 429가 뜬 뒤 가장 먼저 할 일은 min instances를 늘리는 것이 아니라, 정말 max instances에 닿았는지와 인입 급증·긴 처리 시간·긴 시작 시간이 섞였는지 분리하는 일이다. 이미 429와 504 분기 글이 timeout과 capacity를 갈랐다면, 이번 글은 capacity 쪽에서 min/max를 어떻게 다시 여는지의 후속 단계다.

두 번째 화면은 autoscaling 문서의 ACT 설명 구간이다. Cloud Run은 CPU 과열을 피하려고 실제 동시 처리 한도를 동적으로 낮출 수 있고, 이 값은 직접 보이지 않는다고 적고 있다.

Cloud Run autoscaling 문서는 ACT가 CPU 보호를 위해 실제 concurrency를 동적으로 낮출 수 있다고 설명한다.

이 문장을 놓치면 configured concurrency가 높으니 max instances만 올리면 된다고 착각하기 쉽다. 실제로는 ACT가 concurrency를 낮춘 상태에서 인스턴스 수가 먼저 차 버릴 수 있다.

세 번째 자료는 min instances 문서다. 여기서는 scale from zero나 cold start 지연을 줄이고 싶을 때 minimum instances로 warm capacity를 유지하라고 설명한다.

Cloud Run min instances 문서는 cold start 지연을 줄이려면 warm instance를 유지하라고 안내한다.

즉 min instances는 이미 max limit에 막힌 서비스의 출구라기보다, startup latency 때문에 새 인스턴스가 제때 붙지 못하는 패턴을 줄이는 도구에 가깝다. 비용도 같이 든다.

네 번째 화면은 max instances 문서다. Google은 기본적으로 서비스 레벨 max instances를 쓰라고 권장하고, 기본 revision max가 100이라고 설명한다.

Cloud Run max instances 문서는 service-level max를 기본 cap으로 쓰고, 필요하면 값을 올리라고 안내한다.

이 구간을 보면 429가 뜬 뒤 first move가 max instances인지 min instances인지 갈리는 기준이 명확해진다. instance count가 이미 cap 근처라면 warm instance보다 cap부터 열어야 한다.

다섯 번째 자료는 container contract의 pending queue 설명이다. Cloud Run은 새 인스턴스를 기다리는 요청을 평균 startup time의 3.5배 또는 10초까지 보류할 수 있다고 적고 있다.

Cloud Run container contract는 요청이 평균 startup time의 3.5배 또는 10초까지 pending queue에 머물 수 있다고 설명한다.

이 문장은 min instances를 언제 검토할지 정하는 실무 기준이 된다. startup이 길고 queue 한도를 자주 건드리면 max를 올려도 warm capacity가 없어서 체감 오류가 계속 날 수 있다.

이 표는 429 뒤에 무엇부터 바꿔야 하는지 빠르게 고르는 분기표다. 지표 없이 min과 max를 같이 올리기 시작하면 원인을 다시 설명하기 어려워진다.

429 뒤에 max instances를 먼저 볼지, min instances를 먼저 볼지 구분하는 recovery matrix다.

이 분기표를 운영 문서로 남겨 두면 429가 다시 와도 cap 문제인지 startup 문제인지 더 짧게 말할 수 있다. ACT와 max instances 충돌 글, max instances와 concurrency 503 글과도 자연스럽게 이어진다.

마지막 자료는 min과 max를 바꾸기 전에 남겨 둘 점검 메모다. 특히 service-level max와 revision-level cap을 같이 섞지 않는 것이 중요하다.

Cloud Run 429 복구 전에 남겨 둘 gcloud 점검 메모 예시다.

이 메모가 있으면 min, max, startup latency, quota 요청을 한 번에 섞지 않게 된다. 비용 관점은 min instances와 concurrency 비용 글과도 연결된다.

5. 주의사항과 리스크

첫 번째 리스크는 cap 문제인데 min instances를 먼저 올려 비용만 늘리는 것이다. 두 번째 리스크는 cold start 문제인데 max instances만 올려 warm capacity가 여전히 없는 상태로 두는 것이다. 세 번째 리스크는 ACT가 실제 concurrency를 낮췄는데 configured concurrency 숫자만 믿는 것이다.

운영 전에 확인할 때는 최소한 instance count, startup p95, current max, min instances, configured concurrency를 한 번에 남기는 편이 좋다. 그래야 다음 429 때도 왜 min을 건드렸는지, 왜 max를 먼저 올렸는지 설명이 이어진다.

• 429 복구는 max cap과 warm capacity를 먼저 분리한다.
• min instances는 cold start 흔들림 대응 카드다.
• max instances는 상한 병목을 여는 카드다.

6. 결론

Cloud Run에서 429 no available instance가 확인된 뒤에는 max instances와 min instances를 같은 해결책으로 다루면 안 된다. instance count가 cap에 닿았다면 max를 먼저 열고, cap에는 안 닿았는데 startup과 scale-from-zero에서 흔들린다면 min을 먼저 검토하는 편이 맞다. ACT와 pending queue 규칙까지 같이 보면 429 복구 순서가 훨씬 선명해진다.

capacity를 다시 연 뒤에도 timeout이 남는다면, 바로 request timeout을 키우기보다 startup probe와 startup CPU boost를 먼저 보는 후속 글로 이어서 읽는 편이 좋다. 429 복구와 timeout 조정은 같은 날 일어나도 판단 기준이 다르다.

• cap 문제면 max를 먼저 본다.
• cold start 문제면 min을 먼저 본다.
• ACT 때문에 configured concurrency와 실제 동작이 다를 수 있다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/troubleshooting
2. https://docs.cloud.google.com/run/docs/about-instance-autoscaling
3. https://docs.cloud.google.com/run/docs/configuring/min-instances
4. https://docs.cloud.google.com/run/docs/configuring/max-instances
5. https://docs.cloud.google.com/run/docs/container-contract