[Cloud Run][운영] max instances 제한과 높은 concurrency 설정을 503 기준으로 나누는 법

IT 리서치 노트

[Cloud Run][운영] max instances 제한과 높은 concurrency 설정을 503 기준으로 나누는 법

Cloud Run에서 503이 나왔을 때 concurrency를 낮춰야 하는지, max instances를 늘려야 하는지 바로 판단하기 어렵다. 2026년 7월 1일 기준 Google Cloud 공식 문서를 다시 보면 한 인스턴스의 최대 동시 요청 수와 서비스 전체 최대 인스턴스 수는 서로 다른 제어면이고, troubleshooting 문서도 high concurrency 503을 별도 분기로 다룬다. 이 글은 max instances 제한과 높은 concurrency 설정을 503 기준으로 어떻게 나눠 봐야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloud Run 503에서 concurrency와 max instances는 같은 손잡이가 아니다. concurrency는 인스턴스 하나가 동시에 몇 개 요청을 받을지를 정하고, max instances는 서비스 전체가 몇 개 인스턴스까지 늘어날 수 있는지를 정한다. 그래서 503이 났을 때 둘 중 무엇이 먼저 임계에 닿았는지 확인하지 않고 숫자 하나만 바꾸면 원인을 놓치기 쉽다.

이미 readiness vs concurrency 503 글이 probe와 concurrency 분리를 다뤘다면, 이번 글은 capacity 쪽에서 max instances 상한이 언제 앞에 튀어나오는지의 문제다. 또 health check 비용 글을 봤다면 불필요한 재시도와 인스턴스 확장 상한이 비용과도 이어진다는 점을 함께 볼 수 있다.

여기서 한 단계 더 들어가고 싶다면 오늘 발행한 ACT가 concurrency를 낮춘 뒤 수동 max instances 상한과 충돌하는 신호를 읽는 글이 바로 이어진다. 같은 max instances 문제라도 ACT 개입 여부를 따로 보면 원인 분리가 더 빨라진다.

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

실무에서 흔한 착각은 세 가지다. 첫째, 503이 나면 concurrency만 낮추면 된다고 본다. 둘째, 반대로 인스턴스가 늘지 않으니 max instances만 올리면 된다고 본다. 셋째, 요청당 CPU 사용량과 서비스 전체 확장 상한을 분리하지 않고 두 값을 동시에 크게 잡거나 동시에 낮게 잡는다.

하지만 Cloud Run 문서는 concurrency를 인스턴스당 최대 동시 요청 수로 설명하고, max instances를 서비스 전체 인스턴스 상한으로 따로 설명한다. troubleshooting 문서는 높은 concurrency 설정 때문에 503이 날 수 있다고 적으면서 동시에 max instances를 늘리는 조치도 같이 제시한다. 이는 둘이 서로 다른 병목이면서 동시에 같은 503에서 만날 수 있다는 뜻이다.

즉 capacity 503을 제대로 보려면 request당 CPU 사용량, 현재 concurrency 설정, 503 시점의 instance count, max instances 상한을 같은 화면에서 봐야 한다. 한 인스턴스가 과하게 숨차는 경우와, 인스턴스 수가 상한에 먼저 닿는 경우는 대응이 다르다. 전자는 concurrency를 낮추거나 요청 구조를 바꾸는 쪽에 가깝고, 후자는 max instances와 예산을 재조정하는 쪽에 가깝다.

• 증상: 503이 부하 시간대에만 집중된다.
• 실패: concurrency와 max instances를 같은 의미로 취급한다.
• 막힘: instance count가 상한에 닿았는지 확인하지 않는다.
• 누락: request당 CPU 부담과 서비스 전체 확장 상한을 분리해 적지 않는다.

증상	먼저 볼 값	판단 기준
인스턴스 하나가 바빠 보인다	concurrency와 CPU 여유	한 인스턴스당 요청 밀도가 높은지 본다
인스턴스 수가 금방 꽉 찬다	max instances와 instance count	서비스 전체 확장 상한이 먼저 병목인지 본다
high concurrency 503이 보인다	troubleshooting 로그와 상한 값	concurrency와 max instances를 함께 본다

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

점검은 다섯 단계가 가장 빠르다. 먼저 503이 난 시점의 instance count를 확인한다. 두 번째로 같은 시각대의 high concurrency 관련 로그가 있는지 본다. 세 번째로 현재 concurrency와 max instances 값을 나란히 적는다. 네 번째로 요청당 CPU 부담이 높은 서비스인지 확인한다. 마지막으로 무엇이 먼저 임계에 닿았는지에 따라 조치를 갈라 적는다.

1. 503 시점의 instance count를 먼저 확인한다.
2. high concurrency 관련 로그가 있는지 본다.
3. service concurrency와 max instances 값을 같이 적는다.
4. 요청당 CPU 부담과 응답 시간 특성을 확인한다.
5. 상한이 먼저 찼는지, 한 인스턴스가 먼저 숨찼는지에 따라 조치를 나눈다.

이 순서를 따르면 숫자 두 개를 한 번에 키우거나 한 번에 줄이는 실수를 줄일 수 있다. 예를 들어 instance count가 상한에 먼저 닿았고 high concurrency 로그도 있다면 max instances와 concurrency를 같이 다시 봐야 한다. 반대로 instance count는 여유가 있는데 한 인스턴스 CPU가 먼저 꽉 차면 concurrency를 낮추는 쪽이 더 직접적일 수 있다.

점검 메모 예시

request_cpu_profile=high
service_concurrency=80
max_instances=5
instance_count_at_503=5
high_concurrency_signal=true
decision=raise_max_instances_then_retest_concurrency

운영 문서에는 조치 순서도 남겨 두는 편이 좋다. max instances를 올릴 때는 비용과 예산 상한을 같이 보고, concurrency를 낮출 때는 cold start와 인스턴스 수 증가를 같이 본다. 둘은 서로 바꿔치기하는 값이 아니라 같은 503을 다른 방향에서 설명하는 값이다.

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

첫 화면은 Cloud Run concurrency 기본 설명이다. 여기서는 한 인스턴스가 동시에 몇 개 요청을 받을지 직접 설정할 수 있다는 점을 먼저 확인해야 한다.

Cloud Run은 인스턴스당 최대 동시 요청 수를 직접 설정할 수 있고 최대 1000까지 올릴 수 있다.

이 숫자를 높였다고 해서 서비스가 무조건 더 잘 버티는 것은 아니다. 실제로는 인스턴스당 CPU 여유와 요청 특성에 따라 503이 더 빨리 드러날 수도 있다.

두 번째 자료는 max instances 설정 화면 설명이다. concurrency와 별개로 서비스가 몇 개 인스턴스까지 늘어날 수 있는지도 따로 제한할 수 있다.

Cloud Run 서비스는 최대 인스턴스 수를 따로 제한할 수 있다.

즉 503의 원인이 단순히 인스턴스당 동시 처리량 부족인지, 아니면 서비스 전체 확장 상한에 먼저 막혔는지를 나눠 봐야 한다. 이 분리를 안 하면 concurrency 숫자만 계속 바꾸게 된다.

세 번째 화면은 troubleshooting 문서의 high concurrency 503 분기다. 문서는 이 경우 max instances를 늘리거나 concurrency를 낮추라고 직접 적고 있다.

Troubleshooting 문서는 높은 concurrency 설정 때문에 일부 요청을 처리하지 못하는 503을 별도 분기로 설명한다.

이 문장 덕분에 concurrency 503은 readiness 지연이나 malformed response와 다른 분기라는 점이 분명해진다. 이미 readiness vs concurrency 503 글을 읽었다면, 이번 글은 그중에서도 max instances 제한이 어디서 끼어드는지를 더 좁힌 후속편이다.

네 번째 자료는 max instances limit 동작 설명이다. 예시 숫자가 5일 때 서비스가 그 상한까지 확장한 뒤 새 요청 처리 방식이 어떻게 바뀌는지 이해하는 데 도움이 된다.

Max instances limit이 낮으면 서비스는 그 상한까지 확장한 뒤 추가 요청을 받는 방식이 달라진다.

이 구간을 보면 concurrency 숫자만 높게 잡고 max instances를 낮게 묶어 두는 구성이 왜 위험한지 이해하기 쉽다. 인스턴스 하나당 처리량과 서비스 전체 확장 상한이 동시에 병목이 될 수 있기 때문이다.

이 표는 같은 503이라도 concurrency 한계와 max instances 상한을 어떻게 구분할지 빠르게 정리한 것이다. 운영 문서에 이 표 하나만 있어도 점검 순서가 크게 달라진다.

Concurrency 한계와 max instances 상한을 503 증상 기준으로 나눈 비교표다.

특히 request당 CPU 사용량이 높은 서비스는 concurrency를 올릴수록 한 인스턴스가 먼저 숨차고, 반대로 max instances가 너무 낮으면 확장 여지 자체가 막힌다. 둘은 서로 대신하는 설정이 아니다.

마지막 자료는 capacity 점검 메모 예시다. 503이 났을 때 concurrency와 max instances 값을 같은 줄에 남기지 않으면 원인 분리가 계속 늦어진다.

Cloud Run 503에서 concurrency와 max instances를 함께 기록하는 체크리스트 예시다.

이 메모를 남겨 두면 다음 번 장애에서도 readiness, concurrency, max instances 상한을 더 빨리 갈라낼 수 있다. startup 뒤 readiness 503 글과 같이 보면 probe 문제와 capacity 문제를 문서 단위로 분리하기 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 concurrency를 올리면 인스턴스 수를 아낄 수 있으니 무조건 좋다고 생각하는 것이다. 두 번째 리스크는 max instances를 낮게 묶어 두고도 503 원인을 application code나 probe 문제로만 보는 것이다. 세 번째 리스크는 high concurrency 503과 no available instance 류 신호를 문서상 같은 표에 두지 않는 것이다.

운영 전에는 최소한 service concurrency, max instances, 503 시점 instance count, request CPU 특성을 같이 남기는 편이 좋다. 이 네 가지가 없으면 같은 503도 언제는 concurrency 탓이고 언제는 상한 탓인지 설명이 흔들린다.

• concurrency와 max instances는 서로 다른 병목을 설명한다.
• 503에서는 두 값을 같은 로그 시점에서 같이 본다.
• 비용 조정과 장애 대응 문서를 따로 두지 말고 연결해 둔다.

6. 결론

Cloud Run 503을 제대로 나누려면 한 인스턴스당 동시 처리량과 서비스 전체 확장 상한을 같이 봐야 한다. concurrency는 인스턴스 밀도 문제를, max instances는 서비스 확장 상한 문제를 설명한다. 두 값을 같은 시점 로그와 함께 적어 두면 503 대응이 훨씬 짧아진다.

• 503에서 concurrency와 max instances를 동시에 적는다.
• instance count가 상한에 먼저 닿는지 먼저 본다.
• 조치는 병목이 드러난 쪽부터 하나씩 바꾼다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/about-concurrency
2. https://docs.cloud.google.com/run/docs/configuring/max-instances
3. https://docs.cloud.google.com/run/docs/configuring/max-instances-limits
4. https://docs.cloud.google.com/run/docs/troubleshooting