GCP Cloud Run 503와 콜드스타트 지연 해결법

Cloud Run을 운영하다 보면 두 가지 증상이 함께 나타나는 경우가 많습니다. 첫 요청이 유독 느리거나 타임아웃에 걸리고, 트래픽이 몰릴 때는 간헐적으로 503이 튀는 현상입니다. 겉보기엔 단순한 "서버가 바쁨"처럼 보이지만, Cloud Run의 스케일링 방식(요청 기반, 인스턴스 단위 동시성, 컨테이너 시작 비용)과 애플리케이션의 초기화 로직이 결합되면서 특정 패턴에서 재현됩니다.

이 글은 503을 "에러 코드"가 아니라 "어떤 단계에서 실패했는지"로 쪼개서 진단하고, 콜드스타트 지연을 시스템적으로 줄이는 방법을 정리합니다. Node.js, Python, JVM 계열 어디에도 적용 가능한 공통 원칙과, 바로 붙여 넣어 쓸 수 있는 설정·코드 예제를 포함합니다.

1) Cloud Run의 `503`은 언제 발생하나

Cloud Run에서 503이 뜬다고 해서 항상 애플리케이션이 503을 반환한 것은 아닙니다. 크게 다음 범주로 나뉩니다.

1-1. 인스턴스가 준비되기 전에 요청이 들어옴(스케일아웃·콜드스타트)

트래픽이 급증하면 Cloud Run은 새 인스턴스를 띄우지만, 컨테이너가 "리스닝 가능한 상태"가 되기 전까지는 요청을 처리할 수 없습니다. 이때 플랫폼 레벨에서 503이 발생할 수 있습니다. 특히 다음 조건에서 악화됩니다.

컨테이너 시작 시간이 길다(이미지 크기, 런타임 부팅, DI 컨테이너 초기화)
시작 직후 외부 의존성(DB, Redis, 외부 API) 연결이 느리다
startup 단계에서 무거운 작업(마이그레이션, 캐시 워밍, 대용량 파일 로드)을 수행한다

1-2. 동시성(concurrency)과 CPU 할당의 불일치로 큐잉이 길어짐

Cloud Run은 한 인스턴스가 여러 요청을 동시에 처리할 수 있습니다. 하지만 애플리케이션이 CPU 바운드이거나 이벤트 루프가 막히는 구조인데 동시성을 높게 잡으면, 요청이 인스턴스 내부에서 대기하다가 타임아웃으로 이어지고 결과적으로 503처럼 관측될 수 있습니다.

1-3. 상위 타임아웃(Cloud Run / LB / 클라이언트)로 인한 중간 실패

Cloud Run의 요청 타임아웃, HTTP(S) Load Balancer의 타임아웃, 클라이언트 타임아웃이 서로 다르면 "서버는 처리 중인데 앞단이 끊는" 상황이 생깁니다. 이 경우 로그에는 애매하게 남고, 모니터링에서는 503 또는 504로 보이기도 합니다.

1-4. 의존성 장애가 `503`로 전이됨

DB 커넥션 풀 고갈, DNS 지연, 외부 API 429 재시도 폭주 같은 문제가 애플리케이션 지연을 만들고, 결국 타임아웃으로 503이 관측됩니다. 특히 외부 API 호출이 많은 서비스는 재시도 정책이 공격적으로 설정되면 스로틀링이 눈덩이처럼 커집니다.

외부 API 429 재시도·백오프 설계는 아래 글의 패턴을 참고하면 Cloud Run에서도 같은 방식으로 안정성을 올릴 수 있습니다.

OpenAI 429 RateLimitError 재시도·백오프 구현

2) 진단: `503`을 "어디서" 맞는지부터 확인

해결은 튜닝보다 "정확한 위치"를 찾는 게 먼저입니다. Cloud Run에서는 다음 3가지를 함께 봐야 합니다.

Cloud Run 요청 로그(응답 코드, latency, instance id)
Cloud Run 컨테이너 로그(애플리케이션 내부 에러)
Cloud Monitoring 지표(인스턴스 수, 동시 요청, CPU, 메모리)

2-1. Cloud Logging에서 플랫폼 `503` vs 앱 `503` 구분

Cloud Run 요청 로그는 대개 httpRequest.status로 상태 코드를 남깁니다. 컨테이너가 실제로 응답을 만들었는지 확인하려면, 동일 요청에 대해 애플리케이션 로그가 남았는지 함께 추적하세요.

다음은 gcloud로 최근 503만 필터링하는 예시입니다.

gcloud logging read \
  'resource.type="cloud_run_revision" AND resource.labels.service_name="YOUR_SERVICE" AND httpRequest.status=503' \
  --limit 50 --format json

요청 로그는 있는데 컨테이너 로그가 없다면, 컨테이너가 준비되기 전이거나 플랫폼 단계에서 끊겼을 가능성이 큽니다.
컨테이너 로그에 예외가 있다면 앱 레벨 에러입니다(커넥션 실패, OOM, 런타임 크래시 등).

2-2. `latency` 분해: 첫 바이트가 늦은지, 처리 시간이 긴지

콜드스타트는 보통 "연결 수립 후 첫 응답까지"가 늦습니다. 반면 내부 병목(쿼리, 외부 API)은 처리 시간이 길어집니다. Cloud Run 요청 로그의 latency와 애플리케이션 내부 타이밍(미들웨어로 측정)을 같이 보면 원인이 빨리 좁혀집니다.

3) 콜드스타트 지연을 줄이는 핵심 처방 6가지

3-1. `min-instances`로 콜드스타트 자체를 제거

가장 확실한 방법은 최소 인스턴스를 유지하는 것입니다. 비용은 늘지만, 사용자 체감과 503 감소 효과가 큽니다.

gcloud run services update YOUR_SERVICE \
  --min-instances 1 \
  --region asia-northeast3

트래픽이 일정하거나, B2C에서 첫 페이지 요청이 중요한 서비스라면 1만으로도 효과가 큽니다.
배치성 트래픽(간헐적 호출)이라면 0을 유지하되 아래 최적화를 병행하는 편이 낫습니다.

3-2. 시작 경로에서 무거운 초기화를 제거(지연 로딩)

컨테이너 시작 시점에 모든 것을 초기화하면 콜드스타트가 길어집니다. 원칙은 하나입니다.

프로세스 시작 시에는 "서버를 빨리 띄우고" 요청 처리 중에 필요한 것만 준비한다

Node.js(Express) 예시입니다.

import express from 'express';

const app = express();

let expensiveResourcePromise;
function getExpensiveResource() {
  if (!expensiveResourcePromise) {
    expensiveResourcePromise = (async () => {
      // 예: 원격 설정 로드, 큰 모델 파일 로드, 외부 API 토큰 교환 등
      return { ready: true };
    })();
  }
  return expensiveResourcePromise;
}

app.get('/healthz', (req, res) => {
  // 헬스체크는 외부 의존성까지 강제하지 말고, 프로세스 생존만 확인
  res.status(200).send('ok');
});

app.get('/api', async (req, res) => {
  const r = await getExpensiveResource();
  res.json({ ok: true, r });
});

const port = process.env.PORT || 8080;
app.listen(port, () => console.log('listening', port));

포인트는 healthz 같은 경로에서 외부 의존성 연결을 강제하지 않는 것입니다. 콜드스타트 상황에서 헬스체크가 외부 DB까지 기다리면, 인스턴스 준비가 더 늦어지고 스케일아웃이 꼬일 수 있습니다.

3-3. 이미지 크기 줄이기(빌드 최적화)

컨테이너 이미지가 크면 pull 및 시작 시간이 늘어납니다.

멀티 스테이지 빌드로 런타임에 빌드 도구 제거
불필요한 OS 패키지 제거
Node.js는 npm ci --omit=dev 또는 pnpm --prod 활용

Dockerfile(멀티 스테이지) 예시:

FROM node:20-bookworm AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-bookworm-slim
WORKDIR /app
ENV NODE_ENV=production
COPY package.json package-lock.json ./
RUN npm ci --omit=dev && npm cache clean --force
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]

3-4. CPU 부스트와 CPU 할당 정책 점검

Cloud Run은 설정에 따라 "요청 처리 중에만 CPU"가 할당될 수 있습니다. 백그라운드 준비 작업을 하거나, 초기화가 CPU 바운드라면 시작이 더 느려질 수 있습니다.

CPU 부스트를 켜면 시작 및 스파이크 트래픽에서 유리한 경우가 많습니다.
다만 비용과 워크로드 특성에 따라 달라지므로 A/B로 확인하세요.

gcloud 설정은 서비스 옵션에 따라 다를 수 있으니, 콘솔에서 CPU boost 및 CPU is always allocated 여부를 확인하고, 변경 후 콜드스타트 p95를 비교하는 방식이 안전합니다.

3-5. 동시성(concurrency) 낮추기: CPU 바운드·DB 의존 서비스에 특히 효과

동시성을 높이면 인스턴스 수를 덜 띄워 비용이 줄 수 있지만, 애플리케이션이 그 동시성을 감당 못 하면 내부 큐잉이 늘어 지연과 503이 증가합니다.

gcloud run services update YOUR_SERVICE \
  --concurrency 10 \
  --region asia-northeast3

API 서버가 DB 쿼리 비중이 높고 커넥션 풀이 작다면 5~20 사이가 안전한 출발점인 경우가 많습니다.
Node.js에서 CPU 바운드 작업(이미지 처리, 암호화, 대용량 JSON 변환 등)이 있다면 동시성을 더 낮추거나 워커 분리를 고려하세요.

3-6. 타임아웃과 재시도 정책을 "앞단부터" 정렬

타임아웃이 뒤죽박죽이면, 실제로는 처리되었는데 클라이언트는 실패로 인식하는 상황이 생깁니다.

클라이언트 타임아웃 <= 로드밸런서 타임아웃 <= Cloud Run 타임아웃
외부 API 호출 재시도는 지수 백오프 + 지터를 기본으로 하고, 총 대기 시간을 상위 타임아웃보다 짧게 제한

예: Python에서 requests 재시도를 설계할 때 총 재시도 시간을 제한하는 패턴

import time
import random
import requests

def get_with_backoff(url, timeout=2.0, max_attempts=4):
    base = 0.2
    for attempt in range(1, max_attempts + 1):
        try:
            return requests.get(url, timeout=timeout)
        except requests.RequestException:
            if attempt == max_attempts:
                raise
            sleep = base * (2 ** (attempt - 1))
            sleep = sleep + random.uniform(0, sleep * 0.2)  # jitter
            time.sleep(sleep)

resp = get_with_backoff('https://example.com/api')

재시도는 장애를 "완화"하기도 하지만, 설계가 잘못되면 트래픽 폭주를 "증폭"시킵니다. 특히 콜드스타트 시점에 외부 의존성이 느리면 재시도가 겹쳐서 인스턴스가 더 바빠지고 503이 늘 수 있습니다.

4) `503` 스파이크를 줄이는 운영 설정 체크리스트

4-1. `max-instances`로 과도한 스케일아웃을 막고, 다운스트림을 보호

DB가 작은데 Cloud Run이 무제한 스케일아웃하면, DB 커넥션 폭주로 결국 전체가 느려집니다. 이때 503이 늘어납니다.

gcloud run services update YOUR_SERVICE \
  --max-instances 50 \
  --region asia-northeast3

max-instances는 "우리 DB가 견딜 수 있는 동시 커넥션"과 함께 결정해야 합니다.

4-2. DB 커넥션 풀을 인스턴스 수 기준으로 재설계

Cloud Run은 인스턴스가 늘어날수록 풀도 복제됩니다. 예를 들어 인스턴스당 풀 20이고 최대 인스턴스 50이면 이론상 1000 커넥션이 생깁니다. DB가 못 버티면 지연이 증가하고 503으로 번집니다.

권장 접근:

인스턴스당 풀 크기를 줄이고
max-instances로 상한을 두고
필요하면 Cloud SQL 커넥션 풀러(예: PgBouncer)나 프록시를 도입

4-3. OOM(메모리 부족)로 인한 재시작을 의심

메모리가 부족하면 컨테이너가 종료되고, 다음 요청이 콜드스타트를 유발합니다. 이 패턴은 "간헐적 503 + 첫 요청 지연"로 나타납니다.

Cloud Monitoring에서 메모리 사용률과 재시작 이벤트를 확인
이미지 처리, 대용량 응답, 캐시 적재가 있는지 점검

4-4. 이벤트 루프/스레드 블로킹 점검

Node.js라면 동시성을 높게 잡아도 실제로는 이벤트 루프가 막혀 지연이 발생할 수 있습니다. 브라우저 성능에서 Long Task를 추적하듯, 서버에서도 "블로킹 작업"을 찾아야 합니다.

Chrome INP 급락 원인 찾기 - Long Task 추적

위 글은 클라이언트 관점이지만, "긴 작업이 전체 응답성을 깨뜨린다"는 구조는 서버에서도 동일합니다. 서버에서는 APM(Cloud Trace, OpenTelemetry)로 느린 핸들러와 블로킹 구간을 찾아 분리(워커, 큐, 배치)하는 게 정공법입니다.

5) 실전: 콜드스타트 완화용 워밍업과 헬스체크 설계

Cloud Run에서 워밍업을 하고 싶다면, 두 가지를 분리하세요.

healthz: 프로세스가 살아 있고 포트가 열렸는지(가벼워야 함)
readyz: 핵심 의존성이 준비되었는지(필요 시에만)

Spring Boot(개념 예시)에서는 Actuator로 readiness/liveness를 나눌 수 있고, Node/Python도 동일한 방식으로 엔드포인트를 분리하면 됩니다.

또한 워밍업 트래픽을 인위적으로 넣는 경우(스케줄러로 주기 호출)는 다음을 주의하세요.

워밍업이 실제 사용자 트래픽과 같은 경로를 호출하면, 외부 의존성에 불필요한 부하를 줄 수 있음
워밍업은 캐시 적중을 만드는 정도로 최소화

6) 배포 직후 `503`이 늘어나는 경우(리비전 전환 이슈)

새 리비전이 올라갈 때 초기화가 느리면, 트래픽 전환 구간에서 503이 잠깐 증가할 수 있습니다.

대응 전략:

초기화 단축(앞 절의 지연 로딩, 이미지 최적화)
최소 인스턴스 유지
트래픽 분할(새 리비전에 소량만 보내며 관측)

CI에서 빌드 산출물이 바뀔 때마다 이미지 레이어 캐시가 깨져 배포가 느려지는 경우도 있습니다. 캐시 키 설계는 배포 안정성에 직접 영향을 줍니다.

GitHub Actions 캐시 미적중? 키 설계 7원칙

7) 추천하는 튜닝 순서(가장 효과 큰 것부터)

Cloud Logging으로 플랫폼 503인지 앱 503인지 구분
min-instances를 1로 올려 사용자 체감과 503 변화를 확인
동시성을 낮춰 인스턴스 내부 큐잉을 줄임
max-instances로 다운스트림(DB 등) 보호
초기화 로직 지연 로딩, 이미지 슬림화로 콜드스타트 자체를 단축
타임아웃·재시도 정책 정렬(총 재시도 시간 상한 포함)

8) 마무리: `503`은 결과, 원인은 준비·병목·폭주 중 하나

Cloud Run의 503과 콜드스타트 지연은 대개 하나의 원인이 아니라, "느린 시작"과 "동시성/의존성"이 결합해 특정 순간에 폭발합니다. 가장 빠른 해결은 min-instances로 바닥을 깔고, 그 다음에 동시성·풀·타임아웃·초기화를 순서대로 정리하는 것입니다.

운영 관점에서는 "스케일아웃이 빨라질수록 안정적"이라는 직관이 항상 맞지 않습니다. 다운스트림이 약하면 스케일아웃은 오히려 장애 증폭기가 됩니다. Cloud Run의 스케일링 파라미터를 애플리케이션의 처리 모델과 함께 맞추는 것이 503과 콜드스타트를 함께 줄이는 정답입니다.

1) Cloud Run의 503은 언제 발생하나