Cloud Run 콜드 스타트 비용: 최소 인스턴스 가이드

Cloud Run은 트래픽이 없을 때 서비스를 0개 인스턴스까지 축소할 수 있습니다. 이후 첫 요청은 container instance가 시작되는 동안 기다릴 수 있습니다. 인스턴스를 warm 상태로 유지하기 전에 idle 이후 첫 요청의 startup latency와 사용자 체감 응답 시간을 측정하세요. 가끔 실행되는 background·내부 요청과 실제 응답 시간 목표가 있는 대화형 경로도 구분해야 합니다.

최소 인스턴스 설정은 준비된 용량을 유지해 0에서 확장할 때의 지연을 줄일 수 있지만 billable idle time을 만듭니다. 특정 process가 영구히 유지된다는 보장이 아니라 best-effort warm capacity 목표이므로, 애플리케이션은 여전히 restart를 견디고 안전하게 초기화되어야 합니다.

서비스별 region, 최소 instance 수, vCPU, memory, billing 설정, 월간 활성 시간을 기록하세요. Request-based billing에서는 요청을 기다리는 최소 인스턴스에 해당 idle rate가 적용되고 실제 요청 처리 시간은 별도로 청구됩니다. Instance-based billing에서는 idle time을 포함한 instance lifecycle 동안 CPU와 memory가 청구됩니다. 최신 region별 단가와 free tier 적용은 공식 Cloud Run 가격표에서 확인하세요.

요청 수에 고정 cold-start 단가를 곱하면 안 됩니다. Startup과 active compute는 image 크기, 초기화 작업, startup 중 network call, 요청 시간, concurrency, 트래픽 형태, instance 유지 시간에 따라 달라집니다. Scale-to-zero와 minimum-one 시나리오를 만들고, 현실적인 테스트에서 측정한 latency 개선과 월 기본 비용을 비교하세요.

Firebase Functions에 최소 인스턴스 비용 모델 적용하기

Container image를 간결하게 유지하고 필수적이지 않은 초기화를 늦추며 startup 단계의 불필요한 network call을 피하고 필요하면 startup probe를 사용하세요. Concurrency는 인스턴스당 요청 1개로 가정하지 말고 부하 테스트로 정합니다. 안전한 concurrency는 여러 요청이 active instance의 CPU와 memory를 공유하게 해 트래픽 처리에 필요한 instance 수를 줄일 수 있습니다.

특별히 revision별 설정이 필요한 이유가 없다면 minimum instance는 service level에 적용하고, revision-level minimum과 traffic tag가 함께 있어 추가 용량이 계속 청구되는지 확인하세요. Downstream 보호와 scaling 비용 상한을 위해 maximum-instance 제한도 함께 설정합니다. 계산기에 평상시·peak 요청량, 처리 시간, memory를 입력한 뒤 공식 최신 가격으로 측정한 최소 인스턴스 기본 비용을 더하세요.