[Cloud Run][운영] startup probe timeout이 길 때 503과 failureThreshold를 같이 읽는 순서

IT 리서치 노트

[Cloud Run][운영] startup probe timeout이 길 때 503과 failureThreshold를 같이 읽는 순서

Cloud Run에서 startup probe를 켠 뒤 배포 초반 503이 길게 보이면, timeoutSeconds 한 칸만 늘려서는 이유가 잘 안 풀릴 때가 많다. 2026년 6월 25일 기준 Google Cloud 공식 문서는 startup probe가 성공하기 전까지 liveness와 readiness를 비활성화하고, timeout과 failureThreshold와 periodSeconds를 함께 설정하게 한다. 이 글은 startup probe timeout이 길 때 503과 초기화 로그를 어떤 순서로 같이 읽어야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Cloud Run startup probe 문제는 timeoutSeconds만의 문제가 아니다. startup probe는 liveness보다 먼저 동작하고, 실제 보호 시간은 timeoutSeconds와 periodSeconds와 failureThreshold가 함께 만든다. 그래서 503이 보일 때는 probe 설정 숫자와 앱 초기화 로그 시점을 같은 표로 놓고 봐야 한다.

이미 billing mode 글과 health check 비용 글이 과금 쪽 설명을 했다면, 이번 글은 운영 장애 쪽 후속편이다. 또 min instances와 concurrency 글을 같이 보면 cold start 완화와 probe 조정이 어디서 갈리는지 더 잘 보인다.

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

실무에서는 startup probe timeout을 request timeout이나 liveness probe와 섞어 읽는 경우가 많다. 그 결과 503이 보이면 timeoutSeconds만 늘리거나, 아예 min instances만 올려 버리곤 한다. 하지만 공식 문서를 보면 startup probe가 성공하기 전에는 liveness와 readiness가 비활성화될 수 있으므로, 초기화 단계의 실패를 다른 probe 실패로 오해하면 설정을 잘못 만지게 된다.

또 failureThreshold를 따로 안 보면 보호 시간이 짧아질 수 있다. timeoutSeconds가 3초여도 periodSeconds와 failureThreshold가 작으면 앱이 15초 안에 준비되지 못하는 순간 바로 재시작 루프에 들어갈 수 있다. 반대로 너무 크게 잡으면 장애는 줄더라도 실제 준비가 끝나지 않은 컨테이너를 오래 기다려 사용자 체감 503이 길어질 수 있다.

트러블슈팅 문서는 probe timeout 안에 성공 응답이 없으면 로그와 tracing을 켜서 지연 원인을 확인하라고 적고 있다. 이 말은 설정값 자체보다 앱 초기화가 어느 구간에서 길어지는지 확인하는 절차가 먼저라는 뜻이다. 데이터베이스 연결, 모델 로딩, 캐시 복원, 첫 health endpoint 준비 같은 초기화 작업이 기준점이 된다.

• 증상: 배포 직후 몇 초 동안 503이 반복된다.
• 실패: startup probe와 request timeout을 같은 문제로 본다.
• 막힘: timeoutSeconds만 보고 periodSeconds와 failureThreshold를 같이 안 본다.
• 누락: 앱 초기화 로그와 health endpoint 준비 시점을 기록하지 않는다.

증상	먼저 볼 곳	판단 기준
배포 초반 503이 보인다	startup probe와 앱 초기화 로그	health endpoint가 언제 200을 내는지 본다
timeout만 늘려도 개선이 없다	periodSeconds, failureThreshold	총 허용 대기 시간을 계산해 본다
원인을 설명하기 어렵다	tracing과 구조화 로그	느린 초기화 구간을 구체적으로 찾는다

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

점검 순서는 다섯 단계가 가장 실용적이다. 먼저 startup probe가 실제로 활성화됐는지와 endpoint 경로를 확인한다. 다음으로 timeoutSeconds, periodSeconds, failureThreshold 세 값을 같이 읽어 총 허용 대기 시간을 계산한다. 세 번째로 배포 직후 로그에서 앱 초기화 완료 시점과 /healthz가 200을 반환한 시점을 찾는다. 네 번째로 Cloud Run troubleshooting 가이드처럼 tracing과 request timeout 설정까지 같이 본다. 마지막으로 probe 숫자를 바꾼 뒤 비용과 503 변화를 함께 기록한다.

1. startup probe endpoint와 활성화 여부를 먼저 확인한다.
2. timeout, period, threshold를 같이 계산한다.
3. 앱 초기화 완료 시점과 health 200 시점을 찾는다.
4. tracing과 request timeout도 함께 본다.
5. 설정 변경 전후 503과 비용을 같이 기록한다.

여기서 중요한 것은 cold start를 줄이려는 목적과 probe 재시작을 막으려는 목적을 분리하는 것이다. 앱이 실제로 13초에 준비되는데 threshold가 10초 정도만 허용하면 재시작 루프가 생긴다. 반대로 앱이 4초에 준비되는데 timeout과 threshold를 과하게 키우면 장애 탐지가 늦고, 어제 다룬 probe 비용도 같이 늘 수 있다.

운영 메모 예시

startup_probe:
  timeout_seconds: 3
  period_seconds: 5
  failure_threshold: 12
app_boot:
  db_ready_at: 9s
  health_200_at: 13s
incident_check:
  saw_503: true
  request_timeout_checked: true

이 정도만 남겨도 왜 503이 줄었는지, 또는 왜 여전히 남는지를 나중에 다시 설명할 수 있다. probe 설정을 숫자 세 개로만 보지 말고, 앱 초기화 사건과 함께 읽는 편이 좋다.

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

첫 화면은 Cloud Run health checks 문서의 startup probe 설명 구간이다. 여기서 startup probe가 성공하기 전까지 liveness와 readiness가 비활성화된다는 점을 먼저 봐야 한다.

startup probe는 초기 기동이 끝날 때까지 liveness와 readiness 간섭을 막는 용도로 먼저 동작한다.

이 문장을 놓치면 startup probe와 liveness probe가 동시에 실패하고 있다고 오해하기 쉽다. 실제로는 startup probe가 오래 걸리면 뒤 단계는 아직 시작도 안 했을 수 있다.

두 번째 화면은 timeout과 threshold 설정 설명이다. startup probe timeout은 단독 숫자가 아니라 periodSeconds와 failureThreshold와 함께 읽어야 한다.

Cloud Run 문서는 timeout, periodSeconds, failureThreshold를 각각 따로 설명하지만 실제 해석은 세 값을 같이 봐야 한다.

운영 중에 503이 보일 때 timeout만 한 칸 늘리는 습관이 많은데, 실제로는 실패 횟수와 간격이 함께 바뀌지 않으면 cold start 보호 폭이 충분하지 않을 수 있다.

세 번째 자료는 Cloud Run troubleshooting 문서다. 이 문서는 probe timeout 안에 성공 응답이 오지 않을 때 로그와 tracing을 켜고, liveness probe timeout 증가나 request timeout 설정도 같이 보라고 안내한다.

Troubleshooting 문서는 probe timeout과 503을 볼 때 로그, tracing, timeout 값을 함께 점검하라고 설명한다.

즉 startup probe 문제를 단순 설정값 한 칸으로 보지 말고, 실제 앱 초기화 지연과 로그 시점을 함께 읽어야 한다. 503이 request timeout 문제인지 startup probe 문제인지도 이 단계에서 갈린다.

실제 설정 파일에서는 startup probe만 따로 꺼내 보지 말고 periodSeconds와 failureThreshold를 같이 보는 편이 좋다. 그래야 총 허용 대기 시간이 얼마인지 계산이 된다.

service.yaml 예시는 startup probe timeout, periodSeconds, failureThreshold를 한 블록에 모아 보여 준다.

느리게 뜨는 Java나 이미지 최적화 작업이 있는 컨테이너라면 이 블록을 바꾸는 순간 로그 비교 기준도 같이 남겨야 한다. 그렇지 않으면 왜 503이 줄었는지 설명이 불분명해진다.

다섯 번째 자료는 로그 타임라인 예시다. startup probe가 실패하는 순간만 보는 것보다, 앱 초기화 로그와 health endpoint 준비 시점을 같은 분 단위로 나열하는 편이 훨씬 빠르다.

초기화 로그와 health endpoint 준비 시점을 같은 타임라인에 놓으면 503 원인을 좁히기 쉽다.

이렇게 보면 컨테이너가 실제로 준비되기 전에 probe가 끝났는지, 아니면 앱은 이미 준비됐는데 다른 네트워크 조건 때문에 503이 난 것인지 구분된다.

마지막 자료는 startup probe 시간 예산을 읽는 표다. 실무에서는 timeoutSeconds만 보는 일이 많지만, 실제 보호 시간은 period와 threshold가 함께 만든다.

startup probe 시간 예산은 timeout, period, failure threshold를 같이 계산해야 해석이 된다.

이 표는 어제 발행한 health check 비용 글과도 연결된다. probe는 비용과 안정성 둘 다 건드리므로, 숫자를 바꿀 때 두 축을 같이 기록하는 편이 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 startup probe 실패를 request timeout 또는 liveness probe 실패로 착각하는 것이다. 두 번째 리스크는 timeoutSeconds만 계속 늘리고 실제 느린 초기화 구간을 찾지 않는 것이다. 세 번째 리스크는 threshold를 크게 늘려 재시작은 줄였지만 사용자 체감 503과 비용 변화는 더 길게 만든 상태를 모른 채 지나가는 것이다.

운영 전에는 최소한 한 번은 배포 직후 로그를 타임라인으로 정리해 보는 편이 좋다. 특히 데이터베이스 연결, 캐시 로딩, 모델 준비 같은 느린 작업이 있으면 health endpoint가 200을 반환하기까지 얼마가 걸리는지 숫자로 남겨 둬야 한다.

• startup probe는 liveness와 다른 단계에서 읽는다.
• timeout만 보지 말고 period와 threshold를 같이 계산한다.
• 503 감소와 비용 증가를 같이 기록해야 해석이 맞다.

6. 결론

Cloud Run startup probe timeout이 길 때는 503을 단순히 timeoutSeconds 한 칸 문제로 보면 부족하다. startup probe 단계, 앱 초기화 로그, failureThreshold와 periodSeconds를 같이 놓고 보면 왜 배포 직후 503이 나는지 훨씬 정확하게 설명할 수 있다.

• startup probe는 초기화 단계의 별도 제어 흐름으로 본다.
• 총 허용 대기 시간은 timeout과 period와 threshold가 함께 만든다.
• 앱 준비 시점 로그와 503 시점을 같은 타임라인에 남긴다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/healthchecks
2. https://docs.cloud.google.com/run/docs/troubleshooting
3. https://docs.cloud.google.com/run/docs/samples/cloudrun-healthchecks-startup-probe-http