GCP Cloud Run cold start: 먼저 확인할 것들
Infra
마지막 업데이트

GCP Cloud Run cold start: 먼저 확인할 것들

Cloud Run 서비스가 평소에는 빠른데 한동안 유휴 상태였다가 들어온 첫 요청만 유독 느리다면, 문제는 대개 “Cloud Run이 느리다”라기보다 startup 작업, warm instance 부족, revision 변경 패턴에 있습니다.

짧게 말하면, 먼저 startup time과 request time을 분리해서 보고, 느린 구간이 정말 cold start와 맞물리는지 확인한 뒤, 플랫폼 옵션보다 초기화 비용부터 줄이는 쪽이 보통 더 효과적입니다.

먼저 정말 cold start 문제인지 확인하세요

팀에서 Cloud Run 응답이 느리면 전부 cold start라고 부르는 경우가 많지만, 실제로는 아래 세 가지를 구분해야 합니다.

  • 유휴 상태 뒤 첫 요청만 느리고 이후 요청은 정상인 경우
  • 모든 요청이 느려서 실제 핸들러나 다운스트림 의존성이 병목인 경우
  • 새 revision이 healthy 상태가 되기까지 오래 걸려 startup 지연이 cold start처럼 보이는 경우

이 구분이 중요한 이유는 대응 방식이 완전히 다르기 때문입니다. 첫 요청만 느리다면 initialization과 warm instance 커버리지를 봐야 하고, 모든 요청이 느리다면 애플리케이션 처리 경로나 외부 시스템을 봐야 합니다. revision이 늦게 뜬다면 rollout, startup failure, readiness 쪽을 먼저 의심해야 합니다.

Cloud Run cold start가 체감상 느려지는 흔한 이유

Cloud Run cold start는 새 인스턴스가 요청을 받았을 때 이미지 준비, 프로세스 시작, dependency import, 프레임워크 초기화, 외부 클라이언트 준비를 모두 끝내야 트래픽을 처리할 수 있기 때문에 드러납니다.

즉, 플랫폼만의 문제가 아니라 애플리케이션 startup 경로가 실제 지연의 큰 비중을 차지하는 경우가 많습니다.

1. 프로세스 초기화에서 너무 많은 일을 하고 있음

무거운 import, 프레임워크 bootstrap, 스키마 로딩, 모델 로딩, 비싼 connection setup은 startup 시간을 크게 늘립니다.

특히 첫 요청 전에 모든 준비를 eager 하게 끝내려고 할수록 cold start 비용이 커집니다.

2. 이미지와 dependency 세트가 필요 이상으로 무거움

컨테이너 이미지가 크다고 항상 문제는 아니지만, 불필요한 시스템 패키지, 과한 라이브러리, 다목적 런타임 이미지는 startup 시간을 늘리고 편차도 키우는 경우가 많습니다.

최근 라이브러리 추가, base image 변경, 번들 자산 증가 뒤에 첫 요청 지연이 심해졌다면 강한 신호입니다.

3. 요청이 들어올 때 warm instance가 없음

트래픽이 들쑥날쑥하거나 평소 요청량이 적은데 min instances가 0이면 scale-to-zero 이후 cold start가 더 자주 눈에 띕니다.

이 자체가 버그는 아닙니다. 트래픽 패턴이 startup 비용을 더 자주 드러내는 상황일 뿐입니다.

4. 새 revision이 너무 자주 만들어짐

배포가 잦거나 설정 변경이 많고, traffic split도 자주 바뀌면 새 인스턴스가 반복해서 생기면서 팀에서는 “계속 cold start가 심하다”라고 느끼기 쉽습니다.

이 경우는 애플리케이션 문제만이 아니라 운영 방식도 영향을 주고 있습니다.

5. startup이 외부 시스템 지연에 묶여 있음

startup 단계에서 secret fetch, metadata 조회, remote config 로드, database handshake 같은 작업을 동기적으로 수행하면, 컨테이너 내부 코드는 단순해도 전체 startup은 느려질 수 있습니다.

이 패턴은 겉보기엔 “앱 초기화가 느리다”처럼 보이지만, 실제 병목은 컨테이너 밖에 있는 경우가 많습니다.

실전 점검 순서

1. 유휴 뒤 첫 요청과 평시 요청을 비교하세요

먼저 차이가 정말 있는지 확인해야 합니다. 한동안 요청이 없다가 들어온 첫 요청만 느리고, 그 뒤 몇 번의 요청은 정상이라면 cold-start 패턴일 가능성이 큽니다.

반대로 warm 상태에서도 계속 느리다면 cold start로 부르지 말고 핸들러 latency를 추적해야 합니다.

2. service 설정, revision, 최근 로그를 같이 보세요

기본 명령부터 확인합니다.

gcloud run services describe <service> --region <region>
gcloud run revisions list --service <service> --region <region>
gcloud logging read 'resource.type="cloud_run_revision"' --limit 50

여기서 min instances가 0인지, 최근 revision rollout이 있었는지, 로그에 startup 지연이나 initialization error, instance 생성 반복이 보이는지를 같이 확인하세요.

3. 첫 요청 전에 실제로 무슨 일을 하는지 측정하세요

애플리케이션 startup 경로를 직접 봐야 합니다. 아래 질문이 핵심입니다.

  • 서비스가 트래픽을 받기 전에 어떤 import나 bootstrap이 실행되는가?
  • module import 단계에서 database, cache, API client를 바로 생성하는가?
  • 첫 요청 전부터 큰 config, template, model, data set을 읽고 있는가?

실제 Cloud Run 장애에서는 이 구간을 줄이는 것만으로 개선되는 경우가 많습니다.

4. 이미지 무게와 애플리케이션 초기화 비용을 분리해서 보세요

이미지 크기가 늘었다면 이전 revision과 비교해보는 것이 좋습니다. 다만 이미지 크기만 보고 결론 내리면 놓치는 게 많습니다. 이미지가 가벼워도 startup 코드가 무거우면 느릴 수 있고, 이미지가 조금 커도 초기화 경로가 단순하면 괜찮을 수 있습니다.

결국 아래 셋 중 무엇이 핵심인지 구분해야 합니다.

  • 이미지와 dependency 준비 시간
  • 프레임워크 및 애플리케이션 bootstrap 시간
  • 외부 연결과 설정 로드 시간

5. 설정 변경으로 풀 문제인지, 코드 변경이 필요한지 결정하세요

사용자-facing API처럼 첫 응답 latency가 중요한 서비스라면 min instances가 가장 단순한 완화책일 수 있습니다.

하지만 startup 경로가 과하게 무거운 상태라면, 장기적으로는 코드와 dependency를 줄이는 편이 더 낫습니다.

현업에서는 보통 두 가지를 함께 합니다. 먼저 startup 비용을 줄이고, 그래도 latency budget을 못 맞추는 경우에만 min instances를 최소한으로 적용합니다.

패턴을 찾은 뒤 어떻게 바꿀지

startup 초기화가 너무 무거운 경우

전역 초기화에서 꼭 필요하지 않은 작업을 빼고, 비싼 컴포넌트는 lazy-load 하며, 실제로 필요해지기 전까지 모든 다운스트림 시스템에 연결하지 않도록 바꾸세요.

또 startup에서 중복 수행되는 작업이 없는지도 확인해야 합니다.

dependency 무게가 핵심인 경우

패키지 수를 줄이고, 쓰지 않는 라이브러리를 제거하고, base image를 가볍게 만들고, 하나의 서비스에 너무 많은 책임을 담지 않도록 정리하세요.

컨테이너 자체가 과하게 커졌다면 Docker image가 너무 클 때 글도 함께 보는 편이 좋습니다.

트래픽 패턴 때문에 scale-to-zero cold start가 자주 드러나는 경우

첫 응답이 중요한 인터랙티브 API나 로그인 경로라면 min instances가 적절할 수 있습니다.

반대로 요청 빈도가 낮은 내부 툴이나 비동기 엔드포인트라면, 비용을 들여 항상 warm 상태를 유지하기보다 드문 cold start를 허용하는 편이 더 현실적일 수 있습니다.

startup이 외부 시스템 지연에 묶인 경우

동기 startup 호출을 줄이고, 중요하지 않은 remote fetch는 뒤로 미루고, 느린 handshake나 retry 때문에 전체 프로세스가 ready 상태가 되지 못하는 구조를 피해야 합니다.

또 실제 문제는 권한일 수도 있습니다. startup 중 다른 GCP 리소스에 접근하다가 실패한다면 GCP Permission Denied 글과 같이 보세요.

간단한 장애 체크리스트

Cloud Run cold start가 눈에 띄기 시작하면 아래 순서로 보는 것이 좋습니다.

  1. 유휴 뒤 첫 요청만 느린지 확인한다
  2. 최근 배포나 revision 변경 뒤부터 심해졌는지 본다
  3. min instances와 instance availability를 확인한다
  4. 첫 요청 전 initialization 작업을 측정한다
  5. dependency, remote startup call, eager boot logic을 줄인다
  6. 그래도 latency budget을 못 맞추면 min instances를 적용한다

이 순서대로 보면 모든 느린 응답을 플랫폼 문제로 오해하는 실수를 줄일 수 있습니다.

FAQ

Q. Cloud Run에서 cold start를 완전히 없앨 수 있나요?

완전히 없앤다기보다, 얼마나 자주 발생하는지와 체감이 얼마나 큰지를 줄인다고 보는 편이 더 현실적입니다.

Q. min instances가 항상 정답인가요?

아닙니다. startup 경로가 비효율적인 상태라면 단지 비용을 써서 문제를 가리는 것에 가깝습니다.

Q. 배포 후 갑자기 cold start가 심해졌다면 무엇을 의심해야 하나요?

대개는 Cloud Run 자체 변화보다 dependency 증가, 초기화 작업 추가, revision churn을 먼저 의심하는 편이 맞습니다.

Q. readiness 문제와는 어떻게 구분하나요?

revision이 healthy 상태가 되지 못하거나 startup error가 반복된다면, 단순 cold start보다 startup failure나 rollout 문제를 먼저 봐야 합니다.

Sources:

계속 읽어볼 글

심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.

계속 읽어볼 글

심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.

관련 글

이 카테고리의 다른 글