[Cloud Run][비용] health check를 켰을 때 요청이 없어도 CPU 과금이 생기는 지점

IT 리서치 노트

[Cloud Run][비용] health check를 켰을 때 요청이 없어도 CPU 과금이 생기는 지점

Cloud Run 비용을 볼 때 요청 수와 billing mode만 보다가 health check를 놓치는 경우가 많다. 하지만 2026년 6월 25일 기준 Cloud Run 공식 문서는 probe가 실행될 때 CPU가 항상 할당되고 CPU와 memory 사용량이 청구된다고 적고 있다. 이 글은 request-based billing을 쓰더라도 health check 때문에 어떤 비용 설명이 추가되는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloud Run health check는 안정성 기능이지만 비용에서도 완전히 공짜가 아니다. 공식 문서는 probe가 돌 때 CPU가 항상 할당되고 CPU·memory 사용량이 청구된다고 적고 있다. request-based billing이라도 probe 구간을 따로 읽어야 하고, instance-based billing이라면 인스턴스 전체 수명 과금 위에 probe가 얹힌다고 이해하는 편이 안전하다.

이미 min instances와 concurrency를 같이 보는 글이나 billing mode를 고르는 글을 읽었다면, 이번 글은 그 위에 probe라는 운영 비용 항목을 한 층 더 얹는 설명이라고 보면 된다.

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

실무에서 흔한 오해는 세 가지다. 첫째, request-based billing이면 요청이 없을 때는 health check도 비용이 거의 없다고 생각한다. 둘째, startup probe와 liveness probe를 많이 세밀하게 넣을수록 무조건 좋다고 본다. 셋째, 비용이 늘어도 요청량만 보고 설명하려 든다. 공식 문서를 보면 probe는 요청과 별개로 CPU allocation이 생길 수 있으므로 이 세 가지 모두 틀릴 수 있다.

특히 시작이 느린 서비스는 startup probe를 길게 주는 것이 안정성에는 도움이 된다. 하지만 probe 주기와 failure threshold를 너무 공격적으로 잡으면 시작 중 CPU 사용 시간도 함께 늘어난다. liveness probe도 마찬가지다. 너무 촘촘하게 두면 정상 서비스에서도 불필요한 확인 비용과 재시작 비용이 생길 수 있다.

또 billing mode를 같이 안 보면 설명이 틀어진다. billing settings 문서는 instance-based billing이 예전의 CPU always allocated 명칭이라고 적고 있다. 따라서 같은 probe 설정이어도 request-based와 instance-based는 읽는 방식이 다르다. request-based는 per-request fee만 보는 것이 아니라 probe 실행 구간의 CPU·memory 청구도 같이 봐야 하고, instance-based는 전체 인스턴스 수명 과금과 probe를 함께 해석해야 한다.

• 증상: 요청이 거의 없는데도 비용이 완전히 0으로 떨어지지 않는다.
• 실패: startup probe와 liveness probe를 너무 촘촘하게 잡는다.
• 막힘: billing mode 구분 없이 probe 비용을 한 줄로 설명한다.
• 누락: min instances와 probe 조정 이력을 따로 기록하지 않는다.

증상	먼저 볼 곳	판단 기준
요청이 적은데 비용이 남는다	health check CPU allocation, min instances	probe 구간 CPU 청구와 idle 인스턴스 비용을 분리해 본다
배포 후 비용이 올랐다	probe 주기, timeout, failure threshold	안정성 조정이 비용 설명을 바꿨는지 확인한다
cold start 개선 후 이유 설명이 안 된다	startup probe + min instances + billing mode	세 값을 같이 기록해야 재현된다

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

점검 순서는 다섯 단계가 가장 안정적이다. 먼저 billing mode가 request-based인지 instance-based인지 확인한다. 다음으로 startup probe와 liveness probe가 실제로 켜져 있는지, 그리고 주기와 timeout이 얼마인지 본다. 세 번째로 min instances와 concurrency 설정을 같이 읽는다. 네 번째로 최근 비용 변동 시점과 probe 설정 변경 시점을 맞춰 본다. 마지막으로 서비스 안정성 이득이 비용 증가를 정당화하는지 판단한다.

1. billing mode를 먼저 확인한다.
2. startup/liveness probe 주기와 timeout을 본다.
3. min instances와 concurrency를 같이 본다.
4. 비용 변동 시점과 probe 설정 변경 시점을 대조한다.
5. 안정성 이득과 비용 증가를 따로 기록한다.

예를 들어 시작이 느린 Java 서비스라면 startup probe를 두는 편이 좋다. 다만 periodSeconds와 failureThreshold를 무턱대고 키우면 시작 중 CPU 과금 설명도 길어진다. 반대로 liveness probe를 지나치게 촘촘하게 두면 정상 상태에서도 쓸데없는 확인이 늘 수 있다. 그래서 probe는 '많을수록 안전'이 아니라, 서비스 특성에 맞는 최소 유효값으로 잡는 편이 낫다.

설정 메모 예시

billing_mode: request-based
startup_probe: enabled
liveness_probe: enabled
min_instances: 1
question:
- cold start 감소 효과가 있는가
- 요청이 없을 때도 probe CPU 사용이 누적되는가
- 설정 변경 시점과 비용 증가 시점이 같은가

이 식으로 메모를 남기면 요청량만으로 설명이 안 되는 비용 변화도 빠르게 좁힐 수 있다. probe는 운영 안정성을 위한 기능이므로, 비용 회고에서도 별도 축으로 남겨 두는 편이 좋다.

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

첫 화면은 Cloud Run health check 문서의 CPU allocation 구간이다. 이 문서는 probe가 돌 때 CPU가 항상 할당되고, CPU와 memory 사용량이 청구된다고 분명히 적고 있다.

Cloud Run health check 문서는 probe 실행 중에는 CPU가 항상 할당되고 과금된다고 설명한다.

즉 요청이 없는 시간대라도 probe가 돌면 비용이 완전히 0으로 남는 것은 아니다. request-based billing을 쓰더라도 probe 구간은 별도로 읽어야 한다.

두 번째 화면은 startup probe 설명 구간이다. startup probe는 느린 시작을 보호하는 데 유용하지만, probe 주기와 실패 임계값을 과하게 잡으면 그만큼 확인 비용도 길어진다.

startup probe 관련 문서는 느린 시작 보호와 함께 probe 주기, timeout, failure threshold를 같이 조정해야 함을 보여 준다.

여기서 중요한 것은 probe가 안정성 기능이라는 점과 별개로, 너무 공격적으로 돌리면 운영 비용과 시작 시간이 같이 늘어날 수 있다는 점이다.

세 번째 화면은 billing settings 문서다. 여기서 request-based billing과 instance-based billing이 구분되고, instance-based가 예전의 CPU always allocated 명칭이라는 점을 같이 봐야 한다.

Billing settings 문서는 request-based와 instance-based billing의 차이, 그리고 CPU always allocated의 현재 명칭을 보여 준다.

즉 health check 비용을 이해할 때도 먼저 어떤 billing mode인지 알아야 한다. probe 비용은 request-based에서도 생길 수 있고, instance-based에서는 인스턴스 전체 수명 과금과 겹쳐 읽어야 한다.

실제 설정 파일에서는 어떤 probe를 얼마나 자주 돌리는지 숫자로 남겨 두는 편이 좋다. 콘솔에서 클릭만 해두면 왜 비용이 바뀌었는지 팀이 나중에 추적하기 어렵다.

서비스 YAML 예시는 startup probe와 liveness probe의 주기, timeout, failure threshold를 한 번에 묶어 보여 준다.

특히 시작이 느린 서비스는 startup probe를 길게 주고 liveness probe는 과도하게 빠르지 않게 잡는 편이 비용과 안정성 둘 다 읽기 쉽다.

다섯 번째 자료는 probe 비용을 볼 때 어떤 값을 먼저 비교할지 정리한 표다. health check 자체보다 billing mode, min instances, probe 주기가 함께 움직인다는 점을 빼먹기 쉽다.

billing mode와 probe 주기, min instances를 같이 보는 비교표다.

이미 request-based와 instance-based billing 글을 읽었다면, 이번 표는 health check가 그 위에 어떤 추가 비용 설명을 만드는지 보여 주는 보조판이라고 보면 된다.

마지막 자료는 운영 메모 예시다. 비용이 튀었을 때 요청 수만 보지 말고 probe 조정 이력과 min instances 변경 이력을 함께 기록하는 편이 좋다.

비용 회고 메모는 요청량 외에 probe 주기와 billing mode 변경 이력을 같이 남겨야 한다.

이 기록이 있어야 probe 안정성 실험과 비용 실험을 따로 설명할 수 있다. 그렇지 않으면 요청이 없는데 왜 비용이 있느냐는 질문에 답이 자꾸 흔들린다.

5. 주의사항과 리스크

첫 번째 리스크는 request-based billing이라는 이유만으로 health check 비용을 무시하는 것이다. 두 번째 리스크는 probe를 너무 세밀하게 잡아 안정성보다 비용과 재시작 변동성을 키우는 것이다. 세 번째 리스크는 billing mode, min instances, probe 설정을 한 메모에 남기지 않아 나중에 원인을 재현하지 못하는 것이다.

운영 전에는 probe 목적과 기대 효과를 적고, 운영 후에는 그때 바꾼 숫자와 비용 변화를 같이 기록하는 편이 좋다. 그래야 health check가 정말 필요한지, 아니면 과하게 촘촘한지만 분리해서 판단할 수 있다.

• probe는 안정성 기능이지만 비용 설명에서는 독립 항목으로 남긴다.
• startup probe와 liveness probe를 같은 강도로 잡지 않는다.
• billing mode와 min instances를 같이 기록해야 해석이 맞는다.

6. 결론

Cloud Run에서 health check를 켰을 때는 요청이 없어도 probe 실행 구간의 CPU와 memory 청구를 같이 읽어야 한다. billing mode, probe 주기, min instances를 한 표로 묶어 보면 '왜 요청이 적은데 비용이 남는가'를 훨씬 정확하게 설명할 수 있다.

• probe 비용은 request-based에서도 따로 읽는다.
• probe 주기와 threshold는 안정성뿐 아니라 비용에도 영향을 준다.
• billing mode와 min instances를 같이 기록해야 해석이 맞는다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/healthchecks
2. https://docs.cloud.google.com/run/docs/configuring/billing-settings
3. https://cloud.google.com/run/pricing