[Cloud Run][운영] ACT가 concurrency를 낮춘 뒤 수동 max instances 상한과 충돌하는 신호 읽는 법

IT 리서치 노트

[Cloud Run][운영] ACT가 concurrency를 낮춘 뒤 수동 max instances 상한과 충돌하는 신호 읽는 법

Cloud Run에서 latency가 늘거나 503이 나오면 보통 concurrency 값을 먼저 본다. 그런데 2026년 7월 4일 기준 Google Cloud 공식 문서를 다시 보면 Cloud Run은 ACT로 인스턴스당 동시 요청 수를 동적으로 낮출 수 있고, 동시에 서비스별 max instances 상한도 따로 적용할 수 있다. 이 글은 ACT가 concurrency를 낮춘 뒤 수동 max instances 상한과 충돌할 때 어떤 신호를 먼저 읽어야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloud Run에서 설정한 concurrency 숫자와 실제 serving 시점의 동시 처리량은 항상 같지 않다. Cloud Run은 ACT로 CPU 사용률을 보며 인스턴스별 최대 동시 요청 수를 더 낮출 수 있고, 서비스에는 별도로 max instances 상한도 걸 수 있다. 따라서 latency가 늘 때는 단순히 앱 성능만 볼 게 아니라, ACT가 concurrency를 보수적으로 조정한 상태에서 scale-out이 max instances 상한에 막힌 것은 아닌지 같이 봐야 한다.

이미 max instances와 높은 concurrency를 503 기준으로 나눈 글이 capacity 축을 넓게 다뤘다면, 이번 글은 그 내부에서 ACT 개입을 따로 떼어 보는 후속편이다. 또 readiness 지연과 concurrency 포화 글을 같이 보면 probe 문제와 capacity 문제를 더 빨리 분리할 수 있다.

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

실무에서 먼저 헷갈리는 지점은 세 가지다. 첫째, 설정한 concurrency가 곧 실제 인스턴스 처리량이라고 가정한다. 둘째, latency가 느는 원인을 앱 코드 한쪽으로만 몰고 max instances 상한을 잊는다. 셋째, multi-vCPU 인스턴스에서 단일 스레드 앱이 hotspot을 만들고 있는데 평균 CPU만 보고 scale-out이 충분하다고 판단한다.

Cloud Run autoscaling 문서는 ACT가 CPU 사용률을 보고 동시 요청 수를 동적으로 조정해 high request latency를 막는다고 설명한다. concurrency 문서는 vCPU hotspot이 있으면 CPU 평균만으로는 autoscaling이 둔해질 수 있으므로 concurrency를 낮춰 scale-out을 유도하라고 적는다. max instances 문서는 서비스별 인스턴스 수 상한을 명시적으로 제한할 수 있다고 설명한다. 이 셋을 같이 읽으면, concurrency를 낮추는 판단과 max instances 상한이 같은 방향으로 capacity를 줄일 수 있다는 점이 보인다.

특히 메모리 때문에 multi-vCPU 인스턴스를 골랐는데 실제 앱은 single-threaded인 경우가 그렇다. 운영자는 concurrency를 낮춰 scale-out을 유도하고 싶지만, 이미 max instances가 낮게 고정돼 있으면 새 인스턴스가 충분히 늘어나지 못한다. 그 결과 CPU 평균은 낮은데도 latency와 요청 대기가 길어지는 이상한 증상이 남는다.

• 증상: concurrency를 낮춘 뒤 오히려 latency와 503이 늘었다.
• 실패: 설정값과 실제 serving 동시 처리량을 같은 값으로 본다.
• 막힘: max instances 상한을 잊고 앱 코드만 계속 손본다.
• 누락: vCPU hotspot 특성과 평균 CPU 한계를 같이 보지 않는다.

상황	먼저 볼 곳	판단 기준
latency 증가 + 새 인스턴스가 안 는다	max instances 상한	instance 수가 상한에 붙어 있는지 본다
CPU는 낮아 보이는데 요청이 밀린다	vCPU hotspot과 concurrency 변경 이력	평균 CPU만으로는 scale 신호가 약할 수 있다
503이 startup 근처에서 난다	probe 로그	capacity 축이 아니라 readiness 축인지 먼저 자른다

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

진단 순서는 다섯 단계가 가장 실용적이다. 먼저 배포에 설정된 concurrency와 max instances를 기록한다. 두 번째로 최근 latency 증가가 concurrency 변경 이후에 시작됐는지 본다. 세 번째로 실제 instance 수가 상한에 붙어 있는지 확인한다. 네 번째로 앱이 single-threaded 또는 hotspot 특성을 가지는지 본다. 마지막으로 probe 오류가 아니라 capacity saturation인지 로그를 다시 나눈다.

1. 설정된 concurrency와 max instances를 먼저 기록한다.
2. latency 증가 시점이 concurrency 변경과 겹치는지 본다.
3. instance 수가 서비스 상한에 붙어 있는지 확인한다.
4. 앱이 vCPU hotspot 특성을 갖는지 점검한다.
5. probe 오류와 capacity saturation을 로그로 다시 나눈다.

핵심은 'concurrency를 낮추면 무조건 안전하다'고 보지 않는 것이다. 낮춘 concurrency가 scale-out 수요를 올렸는데, 바로 옆에서 max instances가 scale-out을 막고 있으면 결과는 더 나빠질 수 있다. 이때는 앱 코드, concurrency, max instances 세 값을 함께 움직여야 한다.

운영 메모 예시

service=checkout-api
configured_concurrency=16
configured_max_instances=8
instance_count_pinned=true
latency_p95_jump_after_change=true
single_threaded_hotspot_suspected=true
probe_failures_present=false

이 정도 메모만 있어도 ACT가 개입한 상태에서 서비스 상한이 추가 병목을 만들었는지 빠르게 설명할 수 있다. 반대로 probe 오류와 용량 포화를 섞어 놓으면 같은 503이라도 원인을 늦게 자르게 된다.

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

첫 자료는 Cloud Run autoscaling 문서의 ACT 구간이다. 여기서는 CPU throttling으로 인한 latency를 막기 위해 Cloud Run이 인스턴스별 동시 요청 수를 동적으로 조정한다고 설명한다.

Cloud Run ACT는 CPU 사용률을 보며 인스턴스별 최대 동시 요청 수를 동적으로 조정한다.

즉 설정 화면에 concurrency를 80으로 적어 뒀다고 해도, 실제 serving 시점에는 Cloud Run이 더 낮은 값을 택할 수 있다. 이 상태에서 수동 max instances 상한까지 낮게 두면 용량 계산이 예상보다 빨리 막힐 수 있다.

두 번째 자료는 concurrency 문서의 scaling 설명이다. 단일 스레드 앱이 multi-vCPU 인스턴스에서 hotspot을 만들면 CPU 기반 autoscaling이 둔해질 수 있고, 이때 concurrency를 낮춰 scale-out을 유도하는 전략이 필요하다고 적혀 있다.

Cloud Run 문서는 vCPU hotspot이 있으면 concurrency를 낮춰 scaling을 유도하라고 설명한다.

여기서 중요한 점은 낮춘 concurrency가 scale-out을 더 자주 요구한다는 사실이다. 그런데 서비스에 max instances 상한을 함께 묶어 두면 ACT와 운영자가 같은 방향으로 capacity를 줄이는 상황이 생길 수 있다.

세 번째 자료는 max instances 설정 문서다. Cloud Run은 서비스별 최대 인스턴스 수를 명시적으로 제한할 수 있고, 이 값은 확장 한도를 직접 자른다.

Cloud Run은 서비스별 <code>Maximum number of instances</code>를 명시적으로 제한할 수 있다.

즉 concurrency를 낮춘 뒤 latency가 늘 때 무조건 앱 코드만 볼 게 아니라, 실제 인스턴스 수가 상한에 닿았는지도 같이 봐야 한다. 상한에 닿은 상태에서는 더 많은 scale-out을 기대해도 서비스가 늘어나지 않는다.

실무에서는 배포 명령과 운영 메모를 같이 남겨 두는 편이 좋다. 그래야 concurrency와 max instances가 같은 배포에서 어떻게 바뀌었는지 나중에 바로 비교할 수 있다.

concurrency와 <code>max instances</code>를 같이 바꾼 Cloud Run 배포 예시다.

이런 메모가 없으면 ACT가 개입한 결과인지, 운영자가 상한을 줄여 둔 탓인지 나중에 설명이 길어진다. 이미 max instances와 concurrency를 503 기준으로 나눈 글을 읽었다면, 이번 글은 그보다 한 단계 더 안쪽인 ACT 개입 시점을 다룬다.

503이나 latency가 나올 때 probe 지연, concurrency 포화, max instances 상한, ACT 개입을 한 표에 놓고 보면 진단 순서가 빨라진다. 같은 증상이라도 먼저 볼 지표가 다르기 때문이다.

ACT 개입, concurrency 포화, max instances 상한을 나눠 보는 신호표다.

이 표를 쓰면 readiness 문제를 capacity 문제로 오판하는 일도 줄어든다. 또 readiness 지연과 concurrency 포화 글과 이어서 읽으면 probe 축과 capacity 축을 분리하기 쉽다.

마지막 자료는 운영 체크 순서다. 로그를 볼 때 concurrency 변경 이력, instance count 상한, latency, 503 시점을 같은 순서로 적어 두면 다음 장애 때 빠르게 재현된다.

ACT와 <code>max instances</code> 충돌을 볼 때 남겨 둘 운영 체크리스트다.

이 메모가 있으면 '앱이 느려졌다'는 감상 대신 어떤 축에서 capacity가 막혔는지 바로 좁힐 수 있다. 기존의 startup 뒤 readiness 503 글과 같이 보면 장애를 probe 쪽과 autoscaling 쪽으로 더 빨리 나눌 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 concurrency를 낮춘 사실만 기억하고 max instances 상한을 잊는 것이다. 두 번째 리스크는 평균 CPU가 낮으니 scale 문제가 아니라고 단정하는 것이다. 세 번째 리스크는 probe 실패와 capacity saturation을 같은 분기로 처리하는 것이다.

운영 전에 확인할 때는 concurrency, max instances, 최근 배포 시각, latency 변화, instance 수 상한 도달 여부를 한 화면에 모아 보는 편이 좋다. 이 다섯 값이 있으면 ACT 개입 여부를 더 빨리 추정할 수 있다.

• 설정 concurrency와 실제 serving capacity는 같지 않을 수 있다.
• 낮은 평균 CPU가 곧 여유 용량을 뜻하지는 않는다.
• probe 축과 capacity 축을 항상 따로 자른다.

6. 결론

Cloud Run에서 ACT가 concurrency를 보수적으로 조정한 상태에서 max instances 상한까지 낮게 걸려 있으면 latency와 503이 더 빨리 튈 수 있다. 이때는 앱 성능만 손보지 말고 concurrency 변경 이력, instance 상한, hotspot 특성을 같이 봐야 원인을 빨리 자를 수 있다.

운영 중 실제 응답 코드가 503보다 429 또는 504로 먼저 보인다면, 이어서 ACT 이후 429 no available instance와 504 timeout을 분리하는 후속 글까지 같이 보는 편이 좋다. 이 글이 설정 충돌 축을 설명한다면, 후속 글은 응답 코드 기준으로 instance 부족과 느린 요청을 바로 자르는 진단 순서를 다룬다.

• ACT 개입과 max instances 상한을 같이 본다.
• latency 증가 시점과 배포 설정 변경을 연결한다.
• probe 실패와 capacity saturation을 구분한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/about-instance-autoscaling
2. https://docs.cloud.google.com/run/docs/about-concurrency
3. https://docs.cloud.google.com/run/docs/configuring/max-instances
4. https://docs.cloud.google.com/run/docs/tips/general