헬스 체크 (Health Checks)
헬스 체크는 Fly.io에서 앱의 상태를 모니터링하는 유용한 방법이에요. 구성하면 플랫폼이 트래픽 라우팅과 배포 관리를 결정하는 데 도움을 줍니다. 이 페이지에서는 top-level 체크, 서비스 레벨 체크, 서비스가 없는 앱의 체크, Machine 체크, bluegreen 체크를 다룹니다.
출처: 문서
본문
헬스 체크는 Fly.io에서 앱 상태를 모니터링하는 유용한 방법입니다. 구성하면 플랫폼이 트래픽 라우팅과 배포 관리에 대한 결정을 내리는 데 도움을 줘요. 예를 들어 헬스 체크는 다음을 할 수 있습니다.
- 트래픽을 받기 전에 Machine이 준비되었는지 확인
- 비정상(unhealthy) Machine을 우회해 가용성 유지
- 새 버전이 올바르게 응답하지 않을 때 배포 중지 또는 롤백
Fly.io는 다양한 사용 사례를 위한 여러 유형의 헬스 체크를 지원합니다. 이것들은 체크 유형에 따라 fly.toml 파일의 해당 섹션에 구성됩니다.
헬스 체크 모니터링
fly checks list 명령으로 앱의 현재 헬스 체크 상태를 볼 수 있어요. 체크는 주기적으로 실행되지만, Last Updated 열은 체크의 상태가 마지막으로 변경된 시점을 보여주며 마지막 실행 시점을 보여주는 것은 아닙니다.
중요: 헬스 체크 실패는 Machine으로의 요청 라우팅을 막을 수 있어요. 하지만 헬스 체크 실패 때문에 Machine이 자동으로 재시작되거나 중지되지는 않으며, 이는 수동으로 해야 합니다.
Top-level 체크
fly.toml 파일의 [checks] 섹션에 정의된 top-level 헬스 체크는 애플리케이션의 전반적인 건강 상태를 모니터링하도록 설계되었으며, 특히 공개를 대상으로 하지 않는 서비스에 적합해요. 비정상 Machine에서 트래픽을 우회시키는 데 사용될 수 있는 서비스 레벨 헬스 체크(예: services.http_checks 또는 services.tcp_checks)와 달리, top-level 체크는 요청 라우팅에 영향을 주지 않습니다. 따라서 Machines 사이에 트래픽이 어떻게 분산되는지에 영향을 주지 않으면서 내부 모니터링과 알림 목적에 적합합니다.
커스텀 서비스 체크
인증된 엔드포인트나 프라이빗 엔드포인트를 확인하는 것처럼 특정 구성이나 헤더가 필요할 때 커스텀 체크를 사용하세요. TCP와 HTTP 서비스 체크 모두에 커스텀 체크를 구성할 수 있어요.
커스텀 체크에 대한 자세한 내용은 체크 섹션을 확인해 보세요.
서비스 레벨 체크
서비스 레벨 체크는 프록시가 Machine이 트래픽을 서비스할 준비가 되었는지 결정하는 방법을 정의합니다. 이 체크는 프록시 레벨에서 실행되며, 비정상이거나 느리게 시작하는 Machine으로 트래픽이 전송되는 것을 방지해요. TCP 체크는 앱이 예상 포트에서 듣고 있는지 확인합니다. HTTP 체크는 특정 경로에 요청을 보내 2xx HTTP 응답을 기대하는 데까지 나아갑니다. 이는 앱이 시작됐지만 실제 트래픽을 서비스할 준비가 되지 않은 경우를 잡는 데 도움이 됩니다. 두 유형을 모두 사용하면 서로 다른 종류의 문제를 잡을 수 있어요. TCP는 기본적인 도달 가능성, HTTP는 준비 상태를 위한 것입니다.
프록시는 서비스 레벨 체크를 사용해 특정 Machine으로 라우팅해야 하는지 결정합니다. Machine이 서비스 체크에 실패하면 프록시가 비정상으로 표시하고, 체크가 통과하기 시작할 때까지 라우팅되지 않습니다.
서비스 레벨 체크는 라우팅 가용성에 영향을 주지만, 체크 실패가 Machine을 재시작하거나 중지시키지는 않아요.
서비스 레벨 체크는 [[services.tcp_checks]], [[services.http_checks]], [[http_service.checks]] 섹션으로 구성됩니다.
서비스가 없는 앱의 헬스 체크
일부 앱은 오래 지속되는 서비스를 실행하지 않아요. 작업 러너, 큐 워커 등은 시작해서 일을 하고 종료되거나, 네트워크 서비스를 노출하지 않고 계속 실행될 수 있어요. 이런 앱은 Fly의 내장 서비스 레벨 헬스 체크를 사용할 수 없지만, 간접 신호로 모니터링할 수 있습니다.
흔한 접근법 중 하나는 큐 깊이로 알림을 보내는 거예요. 메시지가 쌓이면 워커가 다운됐거나 막힌 상태일 수 있어요. Machines API를 폴링해 인스턴스가 떠 있는지 확인하거나, 주기적 워치독 작업을 실행해 예상대로 실행되는지 검증할 수도 있습니다. Dead Man's Snitch 같은 도구가 여기서 도움이 됩니다.
Flower(Celery용), Prometheus exporter를 가진 Sidekiq, Prometheus 메트릭을 가진 BullMQ 같은 일부 워커 스택은 알림을 받을 수 있는 내부 헬스 신호를 노출합니다. 이것들은 Fly 라우팅의 의미에서 헬스 체크로 작동하지는 않지만, 워커 플릿에 대한 관측 가능성(observability)을 제공해요.
Machine 체크
Machine 헬스 체크는 배포 중에만 실행되며 rolling과 canary 배포 전략을 사용하는 앱에서 지원됩니다. 임시(ephemeral) Machine 안에서 커스텀 명령을 실행하며, 포트나 엔드포인트 가용성 너머의 앱 동작을 검증하는 데 사용할 수 있어요. 데이터베이스 연결 확인이나 주요 백그라운드 서비스 작동 확인처럼 더 복잡한 시나리오에서 앱 준비 상태를 검증하는 데 유용합니다. 이 체크는 라우팅에 영향을 주지 않지만, Machine 체크가 실패하면 배포가 중지됩니다.
Machine 체크는 [[services.machine_checks]]와 [[http_service.machine_checks]] 섹션으로 구성됩니다.
Bluegreen 체크
Bluegreen 체크는 bluegreen 배포의 일부로 사용되는 내부 체크예요. bluegreen 배포 전략을 사용하면 자동으로 실행되며, fly checks list 출력에 bg_deployment로 표시되는 것을 볼 수 있어요.
직접 구성할 필요는 없고, 배포가 완료된 후에는 라우팅에 영향을 주지 않습니다.