[Cloud Run][운영] startup probe에서 initialDelaySeconds와 timeoutSeconds를 같이 조정할 때 로그 읽는 법

IT 리서치 노트

[Cloud Run][운영] startup probe에서 initialDelaySeconds와 timeoutSeconds를 같이 조정할 때 로그 읽는 법

Cloud Run startup probe를 튜닝할 때 initialDelaySeconds와 timeoutSeconds가 비슷하게 보여도 실제로는 다른 문제를 건드린다. 2026년 6월 29일 기준 Google Cloud 공식 문서를 다시 보면, startup probe가 성공하기 전에는 liveness와 readiness가 비활성화되고, startup probe 설정에는 initialDelay와 timeout과 period와 failureThreshold가 함께 들어간다. 이 글은 배포 초반 503을 볼 때 두 값을 어떤 로그 기준으로 나눠 읽어야 하는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 initialDelaySeconds는 첫 probe 시작 시점을 늦추는 값이고, timeoutSeconds는 각 probe 요청이 얼마나 기다릴지 정하는 값이다. 둘 다 '기다리는 시간'처럼 보여도 실패 원인이 다를 때 만져야 하는 값이 다르다. health endpoint가 아직 안 열렸다면 initialDelay를, endpoint는 열렸지만 응답이 느리다면 timeout을 먼저 의심하는 편이 맞다.

또 startup probe는 liveness나 request timeout과 같은 문제가 아니다. Cloud Run 문서는 startup probe가 성공하기 전까지 liveness와 readiness가 비활성화된다고 적고 있다. 즉 이 단계는 초기화 구간만 따로 보는 흐름이다.

이미 startup probe path mismatch 글과 port mismatch 글이 경로와 포트 문제를 다뤘다면, 이번 글은 시간 예산 문제를 initialDelay와 timeout으로 다시 쪼개 보는 글이다.

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

실무에서는 503이 보이면 timeoutSeconds부터 올리는 경우가 많다. 하지만 앱이 실제로는 8초 뒤에야 /healthz 자체를 열고 있다면, 각 요청 timeout을 늘리는 것보다 첫 probe 시작 시점을 늦추는 쪽이 더 직접적일 수 있다. 반대로 health endpoint는 3초 안에 열리는데 내부 종속성 때문에 첫 응답이 2초를 넘겨 늦게 끝나는 상황이면 initialDelay보다 timeout이 더 가깝다.

문서는 startup probe 기본 TCP 설정도 따로 보여 준다. 명시적 HTTP startup probe를 붙이면 그 기본값 대신 직접 준 initialDelay, timeout, period, threshold가 적용된다. 그래서 기본 TCP probe에서는 별문제 없던 서비스가 HTTP startup probe로 바꾸자마자 배포 초반 재시작이 늘어날 수 있다.

또 전체 허용 창은 initialDelay 하나로 설명되지 않는다. 실제 재시작 전까지는 initialDelay 이후 timeoutSeconds, periodSeconds, failureThreshold가 함께 작동한다. 따라서 로그를 볼 때도 '첫 probe가 언제 시작됐는지', '각 probe가 몇 초 뒤 실패했는지', '몇 번 실패 뒤 종료됐는지'를 분리해 기록해야 한다.

• 증상: 배포 초반 503이 반복되는데 path와 port는 맞다.
• 실패: initialDelay와 timeout을 같은 문제로 본다.
• 막힘: 기본 TCP probe와 직접 설정한 HTTP probe 차이를 기억하지 않는다.
• 누락: 첫 probe 시작 시점과 health 200 시점을 로그에 남기지 않는다.

증상	먼저 볼 곳	판단 기준
health endpoint가 늦게 열린다	앱 부팅 로그, first probe start	initialDelay를 먼저 본다
endpoint는 열렸는데 응답이 늦다	probe 요청 duration	timeoutSeconds를 먼저 본다
몇 번 실패 뒤 재시작된다	failureThreshold x periodSeconds	전체 허용 창을 계산한다

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

점검은 다섯 단계가 가장 빠르다. 먼저 path와 port가 맞는지 기존 문제를 제외한다. 두 번째로 첫 probe가 언제 시작되는지 initialDelaySeconds를 로그 타임라인에 올린다. 세 번째로 각 probe 요청이 timeoutSeconds 안에 끝나는지 본다. 네 번째로 failureThreshold와 periodSeconds를 곱해 전체 허용 창을 계산한다. 마지막으로 설정 변경 전후 health 200 시점과 503 시점을 나란히 비교한다.

1. path와 port 문제가 아닌지 먼저 제외한다.
2. first probe start 시점을 initialDelaySeconds와 함께 기록한다.
3. 각 probe 요청 duration을 timeoutSeconds와 비교한다.
4. failureThreshold x periodSeconds로 전체 허용 창을 계산한다.
5. 설정 변경 전후 health 200 시점과 503 시점을 비교한다.

이 순서를 따르면 값 변경의 방향이 분명해진다. 앱이 health endpoint를 늦게 열었다면 initialDelay를 먼저 늘려 probe 시작을 뒤로 미루고, health endpoint는 열렸지만 응답 본문이 늦었다면 timeout을 먼저 본다. 둘 다 아닌데 재시작이 너무 빠르면 threshold와 period를 같이 봐야 한다.

운영 메모 예시

startup_probe:
  initial_delay_seconds: 8
  timeout_seconds: 2
  period_seconds: 5
  failure_threshold: 6
timeline:
  health_200_at: 9s
  first_probe_start_at: 8s
  first_probe_timeout: false
  saw_503: true

이 정도 메모만 있어도 나중에 왜 initialDelay를 손댔는지와, 왜 timeout이 아니라 delay를 바꿨는지를 설명할 수 있다. probe 설정은 숫자를 늘렸다는 사실보다 어떤 실패 양상을 줄이려는 변경인지가 중요하다.

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

첫 화면은 Cloud Run health checks 문서의 핵심 문장이다. startup probe가 성공하기 전까지 liveness와 readiness가 비활성화된다는 점을 먼저 확인해야 한다.

Google Cloud 문서는 startup probe가 통과되기 전까지 liveness와 readiness가 비활성화된다고 설명한다.

이 문장을 놓치면 request timeout이나 liveness failure를 startup probe 문제와 섞어 읽게 된다. startup probe는 배포 초반 초기화 구간만 따로 보는 흐름이라고 생각하는 편이 맞다.

두 번째 자료는 startup probe 설정 구간이다. 여기서는 initialDelaySeconds, timeoutSeconds, failureThreshold, periodSeconds를 같은 블록에서 설정하는 예시가 나온다.

Cloud Run 문서는 startup probe에서 initialDelaySeconds와 timeoutSeconds를 함께 설정하는 예시를 제공한다.

즉 initialDelay와 timeout은 대체 관계가 아니다. initialDelay는 첫 probe 시작 시점을 늦추는 값이고, timeout은 각 probe 요청이 얼마나 기다릴지의 문제다.

세 번째 화면은 default TCP startup probe 설명이다. 명시적으로 설정하지 않으면 Cloud Run이 어떤 기본값으로 시작하는지, 특히 timeoutSeconds 240과 failureThreshold 1을 같이 기억해야 한다.

Cloud Run은 명시적 설정이 없을 때 기본 TCP startup probe를 적용하며, 관련 기본값을 문서에 적어 둔다.

이 기본값을 모르면 HTTP startup probe를 직접 붙인 뒤 오히려 더 엄격한 시간 예산으로 바뀌었는데도 왜 재시작이 늘었는지 해석하기 어렵다.

실제 설정 파일에서는 initialDelay와 timeout을 따로 떼지 말고 failureThreshold와 period까지 한 번에 보는 편이 좋다. 그래야 첫 시도 시점과 각 시도당 대기 시간과 전체 허용 창을 함께 계산할 수 있다.

service.yaml에서 startup probe의 initialDelaySeconds와 timeoutSeconds를 함께 설정한 예시다.

이미 startup probe timeout과 failureThreshold 글을 읽었다면, 이번 글은 그 안에서 initialDelay가 실제로 어떤 역할을 하는지 좁혀 보는 후속편이다.

다섯 번째 자료는 로그 타임라인 예시다. initialDelay를 늘려야 하는지 timeout을 늘려야 하는지는 결국 health endpoint가 언제 준비되는지와 각 probe가 어디서 실패하는지를 같이 봐야 갈린다.

컨테이너 부팅, health endpoint 준비, probe 시점을 같은 타임라인에 놓은 로그 예시다.

이렇게 보면 앱이 9초 뒤에 /healthz 200을 내는데 첫 probe가 1초부터 시작했는지, 아니면 8초 뒤에 시작했는데 각 요청 timeout이 너무 짧은지가 분리된다.

마지막 자료는 값을 나눠 보는 표다. initialDelay와 timeout은 둘 다 '기다린다'는 느낌을 주지만 실제로는 실패 지점을 다르게 바꾼다.

initialDelaySeconds와 timeoutSeconds를 어떻게 나눠 읽을지 정리한 비교표다.

또 startup probe port mismatch 글과 같이 보면 port 문제와 시간 예산 문제를 섞지 않는 데 도움이 된다.

5. 주의사항과 리스크

첫 번째 리스크는 initialDelay를 너무 크게 잡아 실제 장애 탐지가 늦어지는 것이다. 두 번째 리스크는 timeout만 늘리고 health endpoint를 늦게 여는 구조 자체는 그대로 두는 것이다. 세 번째 리스크는 기본 TCP probe보다 더 엄격한 HTTP startup probe로 바꿨는데도 이전 성공 경험만 믿고 숫자를 그대로 두는 것이다.

운영 전에는 최소한 부팅 로그, health 200 시점, first probe 시작 시점 세 가지를 한 줄 타임라인으로 남기는 편이 좋다. 그래야 값 하나를 바꿔도 어떤 실패 양상이 바뀌었는지 다시 설명할 수 있다.

• initialDelay는 첫 probe 시작 시점을 바꾼다.
• timeout은 각 probe 요청의 대기 시간을 바꾼다.
• 재시작 전까지의 전체 시간은 threshold와 period까지 같이 봐야 한다.

6. 결론

Cloud Run startup probe에서 initialDelaySeconds와 timeoutSeconds는 비슷해 보여도 건드리는 실패 지점이 다르다. health endpoint가 아직 안 열렸다면 initialDelay를, endpoint는 열렸지만 응답이 늦다면 timeout을 먼저 보고, 나머지는 failureThreshold와 period로 전체 창을 계산하면 배포 초반 503을 훨씬 덜 헷갈리게 읽을 수 있다.

• initialDelay는 첫 probe 시점, timeout은 각 probe 대기 시간이다.
• 로그 타임라인으로 health 준비 시점을 먼저 확인한다.
• 전체 허용 창은 threshold와 period까지 같이 계산한다.

7. 참고 링크

1. https://docs.cloud.google.com/run/docs/configuring/healthchecks
2. https://docs.cloud.google.com/run/docs/container-contract
3. https://docs.cloud.google.com/run/docs/troubleshooting
4. https://docs.cloud.google.com/run/docs/testing/local