[Cloud Run][운영] ACT가 켜진 뒤 HTTP 429 no available instance와 504 request timeout을 어떤 순서로 나누나

IT 리서치 노트

[Cloud Run][운영] ACT가 켜진 뒤 HTTP 429 no available instance와 504 request timeout을 어떤 순서로 나누나

Cloud Run에서 ACT나 custom scaling target을 켠 뒤에는 같은 트래픽 급증이라도 어떤 날은 no available instance가 먼저 뜨고, 어떤 날은 request timeout 504가 먼저 보인다. 2026년 7월 6일 기준 Cloud Run 공식 문서를 다시 보면 429 no available instance와 504 timeout은 서로 다른 failure mode이며, autoscaling target과 concurrency, request timeout 설정이 모두 해석에 영향을 준다. 이 글은 ACT가 켜진 뒤 HTTP 429 no available instance와 504 request timeout을 어떤 순서로 나눠 볼지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 429와 504는 첫 질문이 다르다. 429 no available instance는 인스턴스가 부족했거나 확장이 충분히 따라오지 못했다는 쪽을 먼저 봐야 하고, 504 timeout은 이미 들어간 요청이 설정된 시간 안에 끝나지 못했는지부터 봐야 한다. Cloud Run 문서는 429를 max instances, 긴 startup, 긴 request processing과 연결하고, timeout 문서는 504 뒤에도 인스턴스 코드가 계속 돌 수 있다고 설명한다. 따라서 ACT가 켜졌더라도 두 오류를 같은 대응표로 처리하면 조치가 늦어진다.

이미 ACT가 concurrency를 낮춘 뒤 max instances 상한과 충돌하는 글이 상한 충돌 신호를 다뤘다면, 이번 글은 그 다음 단계인 429와 504의 실제 증상 분리다. 또 max instances 제한과 높은 concurrency를 503 기준으로 나눈 글은 pre-ACT 판단에 가깝고, 오늘은 ACT와 custom target을 염두에 둔 triage다.

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

실무에서 가장 흔한 오해는 429와 504를 같은 '트래픽이 많음' 신호로만 보는 것이다. 429는 인스턴스가 부족하거나 scale-up이 늦은 쪽을 먼저 의심해야 하지만, 504는 이미 잡힌 요청이 timeout을 넘겼을 수 있다. 또 timeout 뒤에도 기존 인스턴스 코드가 계속 돌 수 있으므로, 후속 요청의 지연이나 인스턴스 점유가 같이 커질 수 있다.

Cloud Run troubleshooting 문서는 429 no available instance를 max instances 상한, 긴 startup, 긴 request processing time과 연결한다. request timeout 문서는 응답이 제때 끝나지 않으면 504를 주지만 인스턴스가 즉시 종료되는 것은 아니라고 적는다. autoscaling 문서는 CPU와 request concurrency target 60% 기준을 설명하고, concurrency 문서는 낮은 concurrency가 더 많은 인스턴스를 쓰게 만든다고 말한다. 이 네 문서를 같이 읽으면 429는 capacity/scale-up 쪽 질문, 504는 request duration 쪽 질문으로 먼저 갈라야 한다는 점이 분명해진다.

특히 ACT나 custom scaling target을 켠 뒤에는 '확장 판단이 더 똑똑해졌으니 429는 줄어들 것'이라고 기대하기 쉽다. 하지만 실제 요청이 길거나 concurrency가 너무 낮거나, max instances 상한이 낮으면 429는 여전히 뜰 수 있다. 반대로 인스턴스 수는 충분해 보여도 timeout이 짧으면 504가 먼저 나타난다.

• 증상: ACT 이후에도 간헐적으로 429와 504가 번갈아 보인다.
• 실패: 429를 timeout 문제로만 보고 timeout만 올린다.
• 막힘: 504를 인스턴스 수 부족으로만 보고 max instances만 올린다.
• 누락: concurrency, target, timeout 값을 같은 시간축으로 기록하지 않는다.

상황	먼저 볼 곳	판단 기준
429 no available instance	instance count, max instances, concurrency	capacity 또는 scale-up 감도 문제를 먼저 본다
504 timeout	timeout 설정, 실제 처리 시간	느린 handler 또는 긴 downstream wait를 먼저 본다
두 오류가 번갈아 발생	지속 요청 + 낮은 capacity 혼합 여부	처리 시간과 scale-up 둘 다 본다

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

가장 실용적인 triage 순서는 네 단계다. 먼저 오류 코드를 429와 504로 정확히 나눈다. 두 번째로 429라면 max instances, container instance count, concurrency 값을 먼저 확인하고 비교한다. 세 번째로 504라면 timeout 값과 실제 처리 시간을 먼저 보고 로그를 확인한다. 네 번째로 두 오류가 섞여 나오면 긴 요청이 인스턴스를 오래 점유해 뒤쪽 요청까지 capacity 부족으로 밀어낸 것은 아닌지 함께 본다.

1. 오류 코드를 429와 504로 먼저 분리한다.
2. 429는 max instances와 concurrency부터 확인한다.
3. 504는 timeout과 실제 처리 시간부터 확인한다.
4. 두 오류가 섞이면 긴 요청 점유와 capacity 부족의 혼합을 의심한다.
5. 원인이 좁혀진 뒤에만 concurrency, target, timeout 중 어떤 값을 바꿀지 정한다.

핵심은 autoscaling target 조정과 request timeout 조정을 서로 대체재로 보지 않는 것이다. autoscaling은 얼마나 빨리 얼마나 많이 늘릴지의 문제이고, timeout은 이미 들어온 요청을 얼마나 오래 기다릴지의 문제다. ACT가 켜졌더라도 긴 handler는 timeout을 만들 수 있고, timeout을 늘려도 인스턴스 부족은 429를 계속 만들 수 있다.

incident 메모 예시

error_code=429
container_instance_count=12
max_instances=12
concurrency=8
request_timeout_seconds=300
decision=capacity-first

error_code=504
container_instance_count=6
max_instances=12
average_handler_ms=322000
decision=timeout-first

이 정도 메모만 남겨도 회고 때 '어떤 값을 왜 먼저 바꿨는지' 설명이 쉬워진다.

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

첫 자료는 Cloud Run troubleshooting의 429 구간이다. 문서는 no available instance가 max instances 상한, 긴 startup, 긴 request processing time과 연결될 수 있다고 적는다.

Cloud Run troubleshooting 문서는 HTTP 429 no available instance를 max instances 또는 느린 처리와 연결해 설명한다.

ACT를 켠 뒤 이 신호가 보이면 바로 timeout만 늘리는 것이 아니라, 현재 인스턴스가 부족했는지부터 먼저 분리해야 한다. 특히 429와 504는 증상이 비슷해 보여도 원인 순서가 다르다.

두 번째 자료는 request timeout 문서다. Cloud Run은 응답이 timeout 안에 끝나지 않으면 504를 반환하지만, 인스턴스 자체는 곧바로 죽지 않을 수 있다고 설명한다.

Cloud Run request timeout 문서는 timeout 뒤 504를 반환하고 기존 인스턴스 코드가 계속 돌 수 있다고 설명한다.

이 차이 때문에 504는 단순히 인스턴스가 부족했다는 뜻이 아니라, 이미 들어간 요청이 너무 오래 걸렸다는 신호일 수 있다. 429와 섞어 보면 조치 순서가 꼬인다.

세 번째 자료는 autoscaling 문서다. 기본 metrics-based scaling은 CPU와 request concurrency target을 60% 임계치 기준으로 잡고, custom scaling controls를 통해 더 정밀하게 바꿀 수 있다고 적는다.

Cloud Run autoscaling 문서는 기본 확장 판단이 CPU와 request concurrency target 60% 기준이라고 설명한다.

ACT를 켰더라도 무한정 빨리 확장되는 것은 아니다. 현재 target과 실제 요청 특성이 어긋나면 no available instance와 timeout 중 무엇이 먼저 튀는지 달라질 수 있다.

네 번째 자료는 concurrency 문서의 Lower concurrency 설명이다. 문서는 concurrency를 낮추면 같은 요청량에서도 더 많은 인스턴스를 쓰게 되어 응답성은 좋아질 수 있지만, 인스턴스 수 판단과 비용에 직접 영향을 준다고 적는다.

Cloud Run concurrency 문서는 concurrency를 낮추면 더 많은 인스턴스를 사용하게 된다고 설명한다.

즉 ACT가 concurrency target을 더 민감하게 보는 상황에서는 concurrency 조정이 429와 504 분류에 모두 영향을 줄 수 있다. 이미 ACT와 max instances 상한 충돌 글을 읽었다면, 이번 글은 그 다음 증상 분리다.

실무 triage는 순서가 중요하다. 429인지 504인지, max instances와 concurrency가 어떤 값인지, request timeout이 얼마인지 한 번에 적어 두면 대응이 짧아진다.

ACT 환경에서 429 no available instance와 504 timeout을 분리하는 triage 순서표다.

이 메모를 남겨 두면 429를 timeout 문제로 오해하거나, 504를 무조건 max instances 부족으로 오해하는 실수를 줄일 수 있다. post 76과 72가 각각 max instances와 concurrency 503을 다뤘다면 이번 표는 ACT 이후 429/504 분기표다.

마지막 자료는 운영 메모 예시다. 값을 한 줄로 남겨 두면 incident 회고에서 autoscaling, concurrency, timeout을 같은 시간축으로 다시 읽기 쉬워진다.

429와 504를 다시 볼 때 남겨 두면 좋은 Cloud Run triage 메모 예시다.

이런 메모를 두면 ACT 설정을 건드릴지, concurrency를 조정할지, timeout이나 처리 로직을 먼저 볼지 우선순위가 정리된다. 이미 readiness와 concurrency 포화를 503 기준으로 나눈 글을 봤다면 오늘 메모는 그 이후 429/504 상황에 맞는 버전이다.

5. 주의사항과 리스크

첫 번째 리스크는 429를 봤다고 timeout을 무조건 늘리는 것이다. 두 번째 리스크는 504를 봤다고 max instances만 올리는 것이다. 세 번째 리스크는 timeout 뒤에도 인스턴스 코드가 계속 돌 수 있다는 문서 설명을 놓쳐, 뒤이은 capacity 압박을 따로 보지 않는 것이다.

운영 전에는 적어도 error code, instance count, max instances, concurrency, timeout, 평균 처리 시간을 같은 incident 메모에 남겨 두는 편이 좋다. 그래야 ACT 조정과 handler 최적화를 서로 다른 레버로 다룰 수 있다.

• 429는 capacity 쪽 질문부터 시작한다.
• 504는 request duration 쪽 질문부터 시작한다.
• 두 오류가 섞이면 긴 요청 점유와 scale-up 한계를 같이 본다.

6. 결론

Cloud Run에서 ACT가 켜진 뒤에도 429 no available instance와 504 request timeout은 서로 다른 순서로 봐야 한다. 429는 인스턴스 부족과 scale-up 감도를 먼저, 504는 timeout과 처리 시간을 먼저 분리하면 concurrency, max instances, timeout 중 어떤 값을 먼저 건드려야 할지가 더 빨리 정리된다.

특히 429가 capacity 쪽으로 확정됐다면, 후속으로는 min instances와 max instances를 다시 여는 순서 글처럼 cap과 warm capacity를 따로 보는 편이 복구가 더 빨라진다.

• 429와 504를 먼저 나눈다.
• 429는 capacity, 504는 duration부터 본다.
• 혼합 증상일 때만 두 축을 함께 조정한다.

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/about-concurrency
4. https://docs.cloud.google.com/run/docs/configuring/request-timeout