작은 서비스에 헬스 체크를 붙인 뒤 배포 실패를 빨리 알아챈 회고

프로세스가 살아 있어도 요청은 실패했다

VPS에 작은 API를 올린 뒤 서비스 상태가 active인 것만 보고 배포를 끝낸 적이 있다. 몇 분 후 폼 제출이 모두 500이 됐다. 실행 프로세스는 살아 있었지만 배포 환경의 DB 주소가 빠져 실제 요청만 실패하고 있었다. 그 뒤로 완료 기준을 프로세스 실행이 아니라 HTTP 응답으로 바꿨다.

live와 ready를 나눴다

처음에는 DB까지 확인하는 엔드포인트 하나만 만들었다. DB 점검 중에는 앱 자체가 응답하는지 알 수 없었다. 그래서 프로세스 확인용 live와 의존성 확인용 ready를 구분했다.

export async function GET() {
  try {
    await prisma.$queryRaw`SELECT 1`
    return Response.json({ ok: true, service: 'ready' })
  } catch {
    return Response.json({ ok: false }, { status: 503 })
  }
}

공개 응답에는 연결 문자열이나 상세 오류를 넣지 않았다. 상태 코드만으로 배포 자동화에는 충분했다.

배포 끝에 검사 하나를 추가했다

앱 포트와 도메인을 각각 확인했다. 앞 검사는 앱, 뒤 검사는 프록시와 TLS까지 포함한다.

curl --fail --silent http://127.0.0.1:3000/api/health > /dev/null
curl --fail --silent https://example.com/api/health > /dev/null

--fail 없이 503 페이지를 받아도 성공처럼 보인 적이 있어 반드시 넣었다.

회고

메일이나 분석 도구까지 모두 헬스 체크에 넣지는 않았다. 사용자 요청에 필수인 의존성과 참고용 외부 서비스를 분리했다. 배포 후 새로고침 한 번보다, 실패를 종료 코드로 남기는 확인이 훨씬 믿을 만했다.