[Cloud Run][비용] min instances와 concurrency를 같이 조정할 때 비용이 달라지는 이유

IT 리서치 노트

[Cloud Run][비용] min instances와 concurrency를 같이 조정할 때 비용이 달라지는 이유

Cloud Run에서 cold start를 줄이려고 min instances를 올리고, 처리량을 맞추려고 concurrency를 바꾸다 보면 비용 방향이 예상과 달라질 수 있다. 이유는 warm instance 유지 비용과 인스턴스 수 증가가 같이 움직이기 때문이다. 공식 문서 기준으로 min instances는 idle 상태 비용과 연결되고, concurrency는 같은 요청량을 몇 개 인스턴스로 처리할지에 영향을 준다. 이 글은 지연 시간, 메모리 사용, 비용 셋을 같이 보며 숫자를 조정하는 기준을 설명한다.

목차

1. 개요
2. 어디서 막히는가
3. 실제로 해결하는 순서
4. 화면과 출력으로 확인하기
5. 주의할 점
6. 결론
7. 참고 링크

1. 개요

Cloud Run에서 cold start를 줄이려고 min instances를 올리고, 처리량을 맞추려고 concurrency를 바꾸다 보면 비용 방향이 예상과 달라질 수 있다. 이유는 warm instance 유지 비용과 인스턴스 수 증가가 같이 움직이기 때문이다.

공식 문서 기준으로 min instances는 idle 상태 비용과 연결되고, concurrency는 같은 요청량을 몇 개 인스턴스로 처리할지에 영향을 준다. 이 글은 지연 시간, 메모리 사용, 비용 셋을 같이 보며 숫자를 조정하는 기준을 설명한다.

• 이 글은 현재 공식 문서와 공개 도움말을 다시 확인한 뒤 정리했다.
• 설정 경로, 실패 지점, 검증 결과를 분리해서 읽으면 바로 실행에 옮기기 쉽다.
• 실제 운영에서는 권한, 비용, 배포 로그를 함께 봐야 같은 실수를 반복하지 않는다.

2. 어디서 막히는가

문제가 길게 보이더라도 실제 막힘은 몇 가지 패턴으로 모인다. 아래 증상 중 하나라도 보이면 설정값, 요청값, 실행 결과를 분리해서 기록하는 쪽이 빠르다.

• cold start를 줄이려고 min instances를 올렸는데 야간 비용이 계속 누적된다.
• concurrency를 1로 낮춰 응답 시간은 나아졌지만 인스턴스 수가 급증한다.
• 메모리를 충분히 안 보고 concurrency만 올려 OOM이나 지연이 생긴다.
• request-based billing과 instance-based billing 차이를 섞어 계산한다.

여기서 가장 흔한 실수는 증상만 보고 권한을 넓히거나 비용 플랜을 올리거나, 별도 로그 없이 다시 시도하는 것이다. 그러면 당장은 지나가도 다음 배포나 다음 운영 시간대에 같은 문제가 다시 나온다.

따라서 먼저 실제 값과 공식 기준이 어떻게 다른지 좁히고, 그 다음에 클릭, 입력, 실행, 저장 순서를 하나씩 재현해야 한다. 이 순서가 있어야 팀원끼리 같은 결과를 볼 수 있다.

문제정의 단계에서는 오류 문구 한 줄만 보는 대신, 어떤 메뉴에서 확인했고 어떤 필드가 비어 있었는지, 어떤 응답 상태가 먼저 나타났는지까지 적어두는 편이 좋다. 그래야 해결 단계에서 값을 바꾼 뒤에도 같은 기준으로 성공과 실패를 다시 비교할 수 있다.

특히 비용 문제나 권한 문제는 겉으로는 비슷하게 보여도 원인이 다르다. 청구 화면, 콘솔 설정, 배포 로그, 브라우저 요청, CLI 출력 가운데 무엇이 기준 화면인지 먼저 정하고 그 화면을 중심으로 확인해야 엉뚱한 메뉴를 오래 헤매지 않는다.

3. 실제로 해결하는 순서

아래 순서는 메뉴를 열고 값을 확인하고 결과를 다시 보는 실무용 순서다. 한 번에 모두 바꾸지 말고 한 단계씩 적용한 뒤 출력과 화면을 확인하는 편이 안전하다.

1. 현재 billing 모델이 request-based인지 instance-based인지 먼저 확인한다.
2. min instances를 0, 1, 2처럼 작게 바꿔가며 idle 시간 비용을 본다.
3. concurrency를 바꿀 때는 latency, instance count, memory peak를 같이 기록한다.
4. cold start가 진짜 병목인지, DB 연결 초기화가 문제인지 로그로 구분한다.

안전한 예제 코드

gcloud run services update example-service \
  --min-instances 1 \
  --concurrency 20

gcloud run services describe example-service \
  --format='value(spec.template.metadata.annotations)'

CLI 예제는 설정 위치를 보여주기 위한 것이다. 실제 서비스명과 프로젝트 ID는 placeholder로 처리한다.

예제 코드는 흐름만 남겼다. 실제 토큰, 계정, 내부 서버 주소, 비공개 저장소 이름은 placeholder로 바꾸고 서버 환경변수나 보안 저장소로 분리한다.

중요한 점은 설정 변경 직후 바로 다음 단계로 넘어가지 않는 것이다. 각 단계마다 어떤 메뉴를 클릭했고, 어떤 값을 입력했고, 어떤 출력이 돌아왔는지 짧게라도 기록해야 한다. 그래야 실패했을 때 마지막으로 바뀐 값이 무엇인지 빠르게 되짚을 수 있다.

또한 해결 절차는 한 번 성공했다고 끝나지 않는다. 같은 절차를 다른 환경이나 다른 브랜치, 다른 계정에서도 다시 실행해 보고 결과가 같은지 확인해야 한다. 운영 환경과 로컬 환경의 URL, 권한, 캐시, 플랜, 리전 차이가 숨어 있으면 여기서 드러나는 경우가 많다.

4. Cloud Run 문서에서 비용 기준 대조하기

Cloud Run 비용은 min instances만 보거나 concurrency만 보면 판단이 틀릴 수 있다. 아래 화면에서는 최소 인스턴스, 요청 라우팅, 동시 요청 수, 가격표를 같은 기준으로 확인한다.

먼저 min instances 문서에서 최소 인스턴스가 어떤 문제를 줄이는지 확인한다. cold start를 줄이는 대신 유휴 시간에도 비용이 남을 수 있다.

min instances 문서에서는 서비스에 최소 인스턴스를 설정하는 기본 목적과 적용 범위를 확인한다.

Billing 설명은 비용 계산의 핵심이다. 인스턴스를 미리 유지하는 설정은 요청이 없을 때도 과금 기준에 영향을 준다.

Billing 화면에서는 최소 인스턴스가 요청 처리 중인지 유휴 상태인지에 따라 비용 기준이 어떻게 달라지는지 확인한다.

service-level과 revision-level 설정 차이도 확인해야 한다. 같은 숫자를 넣어도 어느 범위에 적용했는지에 따라 실제 유지되는 인스턴스가 달라질 수 있다.

service-level과 revision-level 비교 화면은 최소 인스턴스 적용 범위를 정할 때 확인한다.

concurrency 문서에서는 한 인스턴스가 동시에 처리할 요청 수를 본다. 요청을 더 많이 묶으면 인스턴스 수는 줄 수 있지만 지연 시간과 CPU 병목을 같이 봐야 한다.

Concurrency cost considerations 화면에서는 동시 요청 수가 인스턴스 수와 비용에 미치는 영향을 확인한다.

마지막으로 가격표를 확인한다. vCPU, memory, request 과금 모델을 실제 리전과 사용량 기준으로 대입해야 추정치가 의미를 가진다.

Cloud Run pricing 화면에서는 vCPU, memory, request 단가를 실제 설정값과 함께 대조한다.

이 순서로 확인하면 문서의 기능 설명, 설정 범위, 제한 조건, 실제 운영 판단 기준을 한 번에 대조할 수 있다. 화면에서 먼저 볼 항목을 정한 뒤 코드나 콘솔 설정을 수정해야 같은 문제가 반복되지 않는다.

5. 주의할 점

설정을 맞췄더라도 운영에서는 다시 틀어지는 지점이 있다. 아래 항목은 배포 직전과 배포 직후에 꼭 다시 점검할 부분이다.

• 서비스와 revision 양쪽에 min instances를 섞어 걸면 예상보다 많이 유지될 수 있다.
• concurrency를 높였는데 메모리를 그대로 두면 장애가 먼저 난다.
• 비용 최적화 실험은 피크 시간과 유휴 시간을 분리해 보지 않으면 오해하기 쉽다.

특히 권한, 비용, 캐시, 재시도 정책은 한 번 맞춘 뒤에도 환경이 바뀌면 다시 확인해야 한다. 문서가 바뀌었는지, 콘솔 기본값이 달라졌는지, 팀의 배포 방식이 바뀌었는지도 같이 본다.

6. 결론

지연 시간 민감도가 낮으면 min instances를 무리하게 올리지 않는다.

• 지연 시간 민감도가 낮으면 min instances를 무리하게 올리지 않는다.
• concurrency는 CPU보다 메모리와 내부 병렬 처리 능력을 같이 본다.
• 낮은 지연이 중요한 API만 별도 서비스로 분리하는 편이 더 낫기도 하다.

핵심은 추상적인 '좋은 설정'을 찾는 것이 아니라, 지금 내 서비스에서 어떤 값과 어떤 출력이 정답인지 빠르게 확인하는 것이다. 이 글의 순서대로 문서, 설정, 실행 결과를 묶어 보면 같은 문제를 다시 만났을 때 훨씬 빨리 끝낼 수 있다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/min-instances
2. https://docs.cloud.google.com/run/docs/about-concurrency
3. https://cloud.google.com/run/pricing