[Cloud Run][운영] multi-vCPU single-thread에서 평균 CPU는 낮은데 latency가 높을 때 concurrency와 1 vCPU를 어떤 순서로 다시 보나

IT 리서치 노트

[Cloud Run][운영] multi-vCPU single-thread에서 평균 CPU는 낮은데 latency가 높을 때 concurrency와 1 vCPU를 어떤 순서로 다시 보나

Cloud Run에서 multi-vCPU 인스턴스를 쓰는데 평균 CPU utilization은 낮게 보이고, 반대로 latency만 계속 높은 경우가 있다. 이런 상황에서는 max instances를 더 올리거나 timeout을 키우기 전에 single-thread 특성과 concurrency를 먼저 다시 봐야 한다. 2026년 7월 11일 기준 공식 문서를 다시 보면 Cloud Run은 multi-vCPU인데 앱이 single-threaded 또는 effectively single-threaded라면 concurrency tuning이 특히 중요하다고 설명하고, autoscaling은 average CPU와 concurrency utilization을 함께 본다고 적는다. 이 글은 그 문장들을 운영 판단으로 바꿔, 평균 CPU는 낮은데 latency가 높을 때 concurrency와 1 vCPU를 어떤 순서로 다시 봐야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 multi-vCPU single-thread 워크로드에서 평균 CPU가 낮다고 곧 여유가 있다는 뜻은 아니다. Cloud Run은 average CPU와 concurrency utilization을 함께 보고 autoscaling하기 때문에, 한 코어만 포화된 single-thread 앱은 전체 vCPU 평균으로 보면 낮아 보여도 latency는 높게 남을 수 있다. 이때는 max instances를 더 올리기보다 concurrency를 낮춰 보고, 필요하면 다시 1 vCPU로 단순화하는 실험을 먼저 하는 편이 맞다.

즉 이 문제는 용량 부족만의 문제가 아니라 지표 해석의 문제다. 이미 capacity를 풀어도 timeout이 남는 허브 글이 startup latency와 request timeout을 갈랐다면, 이번 글은 그 안쪽에서 '왜 CPU는 낮은데 느리지?'라는 multi-vCPU single-thread 착시를 다룬다.

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

현장에서 흔한 증상은 세 가지다. 첫째, 2 vCPU나 4 vCPU로 올렸는데 평균 CPU는 낮게 보이는데도 P95 latency가 계속 높다. 둘째, concurrency를 높여 인스턴스 수를 아끼려 했더니 응답 시간이 오히려 늘어난다. 셋째, autoscaling이 생각보다 늦게 붙거나, instance 수는 늘지 않는데 요청이 계속 밀린다.

공식 문서를 붙여 보면 원인이 보인다. concurrency 문서는 multi-vCPU인데 앱이 single-threaded라면 concurrency tuning이 특히 중요하다고 말한다. CPU limits 문서는 기본값이 1 vCPU임을 분명히 한다. autoscaling 문서는 average CPU와 concurrency utilization을 target thresholds에 맞추도록 instance 수를 조정한다고 설명한다. 이 세 문장을 합치면, single-thread 앱이 여러 vCPU 중 한 코어만 실제로 바쁘게 쓸 때 average CPU가 낮아 보이는 착시가 생길 수 있다는 운영 해석이 자연스럽게 나온다. 이 해석은 공식 문장들을 조합한 추론이다.

따라서 이 증상에서 가장 흔한 실수는 평균 CPU 수치만 믿고 concurrency를 더 올리거나, 반대로 instance 수만 더 푸는 것이다. 실제 병목이 single-thread handler라면 더 많은 동시 요청이 같은 코어에 줄을 서게 만들 수 있다. 특히 Python GIL, Node.js CPU-bound handler, 단일 스레드 이미지 처리, 단일 락 기반 연산처럼 앱 내부 병렬성이 약한 경우 이 현상이 잘 보인다.

• 증상: 평균 CPU는 낮은데 P95 latency와 timeout이 높다.
• 실패: 평균 CPU가 낮으니 concurrency를 더 올려도 된다고 본다.
• 막힘: multi-vCPU와 single-thread 조합이 만든 평균값 착시를 놓친다.
• 누락: 1 vCPU 회귀 실험과 concurrency 하향 실험을 분리하지 않는다.

질문	먼저 볼 값	이유
앱이 실제로 병렬 처리하나	thread model, CPU-bound 여부	multi-vCPU 이득이 있는지 본다
평균 CPU가 착시일 수 있나	vCPU 수와 average CPU	한 코어 hotspot이 전체 평균에 묻힐 수 있다
무엇을 먼저 줄일까	concurrency, 1 vCPU 회귀 순서	latency 원인을 분리한다

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

가장 실용적인 순서는 다섯 단계다. 먼저 현재 vCPU 수와 앱의 thread model을 확인한다. 두 번째로 concurrency를 보수적으로 낮춰 latency가 바로 떨어지는지 본다. 세 번째로 평균 CPU와 latency가 계속 어긋나면 1 vCPU 회귀 실험을 별도로 한다. 네 번째로 1 vCPU에서 latency가 오히려 더 안정되면 multi-vCPU를 유지해야 할 근거가 있는지 다시 따진다. 마지막으로 startup latency, request timeout, max instances는 이 실험 뒤에 다시 읽는다.

1. 현재 vCPU 수와 앱의 thread model을 먼저 확인한다.
2. concurrency를 낮춰 latency 변화부터 본다.
3. 평균 CPU 착시가 의심되면 1 vCPU 회귀 실험을 따로 한다.
4. 1 vCPU가 더 낫다면 multi-vCPU 유지 근거를 다시 검토한다.
5. 그 뒤에야 timeout, startup, max instances를 다시 튜닝한다.

이 순서가 좋은 이유는 single-thread 병목과 capacity 병목을 분리할 수 있기 때문이다. concurrency를 낮췄을 때 latency가 바로 내려가면 handler 병렬성이 부족한 신호일 수 있고, 1 vCPU로 내렸는데 latency가 비슷하거나 더 좋아지면 multi-vCPU가 평균 CPU 지표만 희석하던 상황일 수 있다. 반대로 1 vCPU로 내렸더니 더 나빠진다면 실제로는 멀티코어 이점을 쓰는 경로가 있다는 뜻이다.

운영 메모 예시

vcpu=4
thread_model=single_thread
concurrency_before=40
concurrency_after=8
avg_cpu_before=0.28
p95_latency_before_ms=4200
p95_latency_after_ms=1700
rollback_to_1_vcpu=planned

운영 점검을 실행할 때는 먼저 현재 revision 설정과 CPU limits를 확인하고, 그다음 로그나 APM에서 handler thread model을 정리한다. 이후 concurrency를 한 번에 크게 올리기보다 단계적으로 낮춰 보고, 실험 결과를 같은 표로 남기면 원인 분리가 쉬워진다. 이미 429와 504 분기 글을 보고 있다면, 이 실험 결과를 그 분기표 안에 같이 넣는 편이 좋다.

실무에서는 Cloud Run 콘솔에서 revision 설정을 확인하고, 현재 CPU 값을 조회하고, concurrency 값을 조정하고, 새 revision을 배포하고, 배포 뒤 로그를 다시 조회하는 다섯 동작을 같은 메모에 적어 두는 편이 좋다. 이렇게 해야 누가 무엇을 클릭했고 어떤 값을 입력했고 어떤 결과를 저장했는지 다음 운영자도 같은 순서로 재현할 수 있다.

• revision 설정에서 vCPU 값과 concurrency 값을 먼저 확인한다.
• handler 로그나 프로파일로 single-thread 여부를 점검한다.
• 실험 전후 latency와 average CPU를 같은 표로 남긴다.

핵심은 낮은 average CPU가 곧 낮은 부하라는 뜻이 아닐 수 있다는 점이다. multi-vCPU single-thread에서는 오히려 1 vCPU와 낮은 concurrency가 더 설명 가능한 운영 상태를 만들어 줄 때가 있다.

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

첫 자료는 Cloud Run concurrency 문서의 multi-vCPU instances 구간이다. Google은 애플리케이션이 single-threaded 또는 effectively single-threaded라면 concurrency tuning이 특히 중요하다고 적고 있다. 오늘 글은 바로 이 조건에서 시작한다.

Cloud Run 문서는 multi-vCPU인데 앱이 single-threaded면 concurrency tuning이 특히 중요하다고 설명한다.

즉 vCPU 수를 늘렸다고 곧바로 처리량이 늘어나는 것이 아니다. 앱이 한 코어만 바쁘게 쓰면 높은 concurrency가 오히려 지연을 키울 수 있다.

두 번째 자료는 CPU limits 문서다. 기본값은 1 vCPU이고 더 큰 값을 줄 수 있다고 설명한다. 즉 multi-vCPU는 선택지이지 기본값이 아니며, 워크로드에 맞는 이유가 있을 때 올려야 한다.

Cloud Run은 기본 1 vCPU에서 시작하고 필요할 때 더 큰 vCPU 값을 선택하게 한다.

이 문맥 때문에 single-thread 앱에서 multi-vCPU를 유지할지 다시 1 vCPU로 내릴지 판단하는 문제가 생긴다. 단순히 '더 크면 좋다'가 아니라 autoscaling과 latency 신호가 어떻게 보이는지가 중요하다.

세 번째 자료는 instance autoscaling 문서다. Cloud Run은 average CPU와 concurrency utilization을 target thresholds에 맞추도록 instance count를 조정한다고 설명한다. 이 문장은 평균 CPU가 여러 vCPU에 걸쳐 분산돼 보일 수 있다는 운영 해석의 근거가 된다.

Cloud Run autoscaling은 average CPU와 concurrency utilization을 함께 보고 instance 수를 조정한다.

따라서 single-thread 앱이 4 vCPU 인스턴스에서 한 코어만 바쁘게 쓰면, 평균 CPU는 낮아 보이는데도 latency는 높을 수 있다. 이 부분은 공식 문장들을 조합한 운영 해석이며, multi-vCPU single-thread 진단의 핵심이다.

네 번째 자료는 general development tips의 concurrency 최적화 구간이다. Cloud Run은 instance가 동시에 여러 요청을 처리할 수 있지만, workload 특성에 맞게 concurrency를 조정하라고 적는다.

general tips는 concurrency를 workload 특성에 맞게 조정하라고 안내한다.

즉 평균 CPU가 낮다고 바로 concurrency를 더 올리는 것이 답은 아니다. 오히려 single-thread CPU-bound 워크로드에서는 concurrency를 낮추거나 1 vCPU로 단순화하는 편이 지연 분리를 더 쉽게 만든다.

실무에서는 low average CPU와 high latency를 바로 triage 표로 바꾸는 편이 좋다. 아래 표는 multi-vCPU single-thread 상황에서 먼저 볼 값을 정리한 것이다.

평균 CPU는 낮은데 latency가 높은 Cloud Run 서비스를 triage하는 표다.

이 표처럼 보면 'CPU가 낮으니 괜찮다'와 'latency가 높으니 max instances를 더 올리자' 사이에서 헤매는 시간을 줄일 수 있다. 이미 capacity를 풀어도 timeout이 남는 글을 봤다면, 이번 글은 그 안쪽에서 single-thread와 multi-vCPU 조합만 따로 좁힌 분기다.

마지막 자료는 운영 메모 예시다. 단순히 CPU가 낮았다는 사실보다 vCPU 수, concurrency, thread 모델, latency 결과를 같이 남겨야 다음 배포 때 같은 착시를 피할 수 있다.

1 vCPU 회귀 여부와 concurrency 조정 순서를 남기는 Cloud Run 운영 메모 예시다.

이 메모 구조가 있으면 1 vCPU 회귀 실험과 concurrency 하향 실험을 분리해 볼 수 있다. max instances와 concurrency 503 글, startup latency와 request timeout 글과도 바로 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 평균 CPU가 낮다고 해서 concurrency를 계속 올리는 것이다. 두 번째 리스크는 multi-vCPU를 더 큰 용량으로만 보고, 앱이 실제 병렬 실행을 못 한다는 사실을 놓치는 것이다. 세 번째 리스크는 1 vCPU 회귀 실험 없이 timeout이나 max instances만 계속 만지는 것이다.

운영 전에 확인할 때는 최소한 vcpu, thread_model, concurrency, avg_cpu, p95_latency 다섯 칸을 같은 표에 남겨 두는 편이 좋다. 이 다섯 칸이 없으면 지표가 서로 다른 질문에 답하게 된다.

• 낮은 average CPU는 single-thread hotspot을 숨길 수 있다.
• concurrency 하향과 1 vCPU 회귀 실험을 분리한다.
• max instances와 timeout은 그 다음 단계에서 본다.

6. 결론

Cloud Run multi-vCPU single-thread 서비스에서 평균 CPU는 낮은데 latency가 높다면, 먼저 concurrency를 낮추고 필요하면 1 vCPU 회귀 실험을 하는 편이 맞다. 공식 문서가 말하는 multi-vCPU single-thread 주의점과 average CPU 기반 autoscaling 문장을 함께 읽으면, 이 증상은 단순 용량 부족이 아니라 지표 해석 문제일 수 있다는 결론이 나온다. 낮은 average CPU에 속지 말고, thread model과 concurrency를 먼저 다시 보자.

• multi-vCPU single-thread는 average CPU 착시를 만들 수 있다.
• 먼저 concurrency를 낮추고 1 vCPU 회귀 실험을 한다.
• 그 뒤에 startup·timeout·max instances를 다시 튜닝한다.

7. 참고 링크

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