라이트하우스 모니터: 장기 실행 서비스가 조용히 썩어가는 것을 막는 작은 일일 체크인

장기 실행 서비스는 잘 폭발하지 않습니다. 대신 조용히 썩어갑니다.

메모리 누수가 서서히 쌓이고, 재시도가 실패하는 의존성을 가려 버리고, 지연 시간은 아무도 눈치채지 못할 정도로 조금씩 늘어납니다. 그러다 작은 트래픽 스파이크가 큰 사고로 번집니다. 대부분의 시간엔 대시보드도 멀쩡하고, 알림도 잠잠합니다. 그러다 어느 날 새벽 3시에 온콜 휴대폰 불이 번쩍 켜집니다.

당신에게 필요한 건 단순한 모니터링만이 아닙니다. 라이트하우스가 필요합니다. 서비스가 진짜로 중요한 측면에서 여전히 건강한지 증명해 주는, 작고 예측 가능하며 잡음이 적은 체크인입니다.

이 글에서는 좋은 헬스 체크와 관측 가능성(observability)을 바탕으로 하는 라이트하우스 모니터라는 아이디어를 살펴봅니다. 하루에 한 번(또는 일정 주기마다) 돌리는 작은 검증 실행을 어떻게 설계할지, 실시간 모니터링과는 어떻게 어우러지는지, 그리고 불안정성을 늘리지 않고 어떻게 가치를 유지할 수 있는지를 다룹니다.

왜 장기 실행 서비스는 조용히 썩어가는가

수 주, 수 개월 동안 계속 떠 있는 서비스에는 미묘한 문제가 조금씩 쌓입니다.

• 리소스 누수 (메모리, 파일 디스크립터, 커넥션)
• 설정 드리프트(configuration drift) (피처 플래그, 환경 변수/인프라 변경)
• 의존성 성능 저하 (느려지는 DB, 불안정한 외부 API)
• 백오프와 재시도가 근본적인 실패를 가려 버리는 문제
• 관측되지 않은 에러 경로 (테스트나 스테이징에선 거의 안 밟히는 코드 경로)

이런 문제는 서비스가 한 번에 박살 나게 만들기보다는, 성능과 신뢰도를 서서히 갉아먹습니다. 겉으로 보기엔 서비스가 “잘 동작”하는 것 같다가, 트래픽/부하/의존성 변동이 어떤 조합으로 엮이는 순간 한계점을 넘습니다.

전통적인 모니터링은 즉각적인 탐지를 목표로 하지만, 현실은 이렇습니다.

• 실시간 알람은 잡음을 줄이기 위해 보수적인 임계값을 쓰는 경우가 많고
• 온콜 엔지니어는 자주 울리는, 영향이 작은 알람을 점점 무시하게 되고
• 많은 코드 경로는 낮은 트래픽의 특정 비즈니스 워크플로우에서만 실행됩니다.

그 결과, 심각한 장애와 일상적인 지표 사이의 틈새에서 “부식”이 조용히 쌓입니다.

그래서 라이트하우스가 필요합니다.

라이트하우스 모니터란 무엇인가?

라이트하우스 모니터는 다음과 같은 성격을 가진 체크입니다.

• 아주 작다: 범위가 최소이고, 오버헤드가 적습니다.
• 주기적이다: 실시간이 아니라, 하루 한 번 혹은 거친 간격으로 실행됩니다.
• 외부에서 동작한다: 서비스 내부가 아니라, 실제 사용자나 클라이언트처럼 바깥에서 호출합니다.
• 의견적(opinionated)이다: 소수의, 가치가 큰 건강 지표만 확인합니다.

즉, 스케줄된 Synthetic User라고 보면 됩니다. 이 모니터는:

1. 공개 헬스 엔드포인트를 호출하고
2. 대표적인 몇 개의 API 엔드포인트를 두드리며
3. 응답의 기본적인 정합성을 검증하고
4. 메트릭을 기록하고 명확한 성공/실패 상태를 남깁니다.

이 작은 일일 체크가 실패하기 시작하거나, 아니면 점점 느려지는 추세를 보인다면, 장기 실행 서비스가 기대했던 동작에서 서서히 벗어나고 있다는 강한 신호입니다.

핵심은 이것입니다. 라이트하우스 모니터는 세밀한 모니터링이나 부하 테스트를 대체하려는 것이 아닙니다. 이것은 현실 점검(Sanity Check)을 비추는 등대에 가깝습니다.

설계 원칙 #1: 빠르고 가볍고, 부작용이 없어야 한다

헬스 체크와 라이트하우스 모니터 자체가 새로운 장애 요인이 되어서는 안 됩니다.

핵심 규칙은 다음과 같습니다.

• 빠르게: 지연 시간은 초 단위가 아니라 밀리초 단위를 목표로 합니다. 느린 체크는 쌓여서 부하를 올리고, 전체 지연 지표를 왜곡합니다.
• 가볍게: 최소한의 쿼리, 작은 페이로드, 짧은 코드 경로를 사용합니다.
• 부작용 없이: 쓰기 작업 없음, 상태 변경 없음, “프로덕션에서 대충 테스트해 보자”식의 꼼수 없음.

이게 왜 중요한가?

• 헬스 체크가 DB에 쓰기까지 한다면, 불필요한 부하와 락 경합을 스스로 추가하는 셈입니다.
• 느린 의존성을 그대로 호출하면, 그 의존성이 이미 문제일 때 사고를 증폭시킬 수 있습니다.
• 체크가 복잡해질수록 이해하기 어렵고, 플래키해질 가능성도 커집니다.

좋은 라이트하우스 모니터는 섬을 비추는 등대 불빛처럼 동작해야 합니다. 해안을 비추되, 해안을 태우지는 않아야 합니다.

얕은(Shallow) 헬스 체크 vs 깊은(Deep) 헬스 체크

모든 헬스 체크가 같은 건 아닙니다. 얕은(shallow) 체크와 깊은(deep) 체크로 구분해 두면 도움이 됩니다.

얕은 헬스 체크(기본값)

얕은 체크는 이런 질문에 답합니다. “서비스가 일단 떠 있고, 아무거나 하나라도 응답을 하고 있는가?”

예시:

• 프로세스 생존 여부(PID가 살아 있는지, 컨테이너가 떠 있는지)
• /health, /ready 같은 엔드포인트에서 HTTP 200 OK 여부
• 단순한 프로세스 내부 체크 (스레드 풀 상태, 큐 크기, 설정 로딩 여부 등)

특징:

• 매우 빠르다
• 외부 시스템 호출이 없다
• 상태 변경이 없다

이런 체크는 다음 상황에서 기본값이 되어야 합니다.

• 로드 밸런서, Kubernetes Readiness/Liveness Probe 등
• 기본 Synthetic 체크 (예: Prometheus로 /health 모니터링)
• 라이트하우스 모니터의 “심장박동(heartbeat)” 역할

깊은 헬스 체크(타깃형 진단용)

깊은 체크는 이런 질문에 답합니다. “핵심 의존성들이 지금 이 순간, 기대하는 방식으로 제대로 동작하고 있는가?”

예시:

• 실제 DB 연결/쿼리 수행 확인
• 캐시나 메시지 큐에 대한 읽기/쓰기 테스트
• 외부 API에 대한 연결성 및 간단한 계약(contract) 체크

특징:

• 상대적으로 느리다
• 다른 시스템에 의존하기 때문에 깨지기 쉽다
• 부하와 부작용의 위험이 더 크다

이런 체크는 신중하게, 목적을 분명히 두고 사용해야 합니다.

• 수동으로 트리거하거나, 더 낮은 빈도로 실행하거나
• 피처 플래그 뒤에 두거나
• 배포 후 readiness 검증이나 장애 진단 과정의 일부로 사용합니다.

라이트하우스 모니터는 기본적으로 얕은 체크에 기반해야 하며, 꼭 필요하고 위험이 낮은 핵심 의존성에 한해 선택적으로 깊은 체크를 추가하는 정도가 적당합니다.

관측 가능성(Observability): 시스템을 “밖에서” 보는 법

마이크로서비스 환경에서는 프로세스 내부를 직접 들여다보는 일은 거의 없습니다. 좋은 관측 가능성이란, 외부로 드러나는 출력만으로 내부 상태를 추론하는 것을 의미합니다.

• 로그(Logs): 에러, 경고, 핵심 비즈니스 이벤트를 담은 구조화 로그
• 메트릭(Metrics): 지연 시간, 처리량, 에러율, 리소스 사용량 등
• 트레이스(Traces): 서비스 간 요청 흐름과 병목 지점
• 헬스 엔드포인트: /health, /ready, /live 등

라이트하우스 모니터는 내부에 복잡한 체크 로직을 다시 구현하기보다는, 이러한 외부 출력들을 최대한 활용해야 합니다.

예시 접근법:

1. 라이트하우스가 소량의 요청을 보냅니다.
2. 응답 코드와 간단한 불변 조건(예: 특정 필드 존재 여부, 기본 값 범위 등)으로 기본적인 정합성을 검증합니다.
3. 응답 시간과 에러 개수를 기록합니다.
4. Prometheus, Datadog 같은 관측 시스템이 이 결과를 내부 메트릭/트레이스와 연관시켜 분석합니다.

이렇게 하면 모니터 자체는 단순하게 유지하면서도, 무언가 이상해졌을 때는 깊은 인사이트를 얻을 수 있습니다.

알림 피로(Alert Fatigue) 없이 모니터링 & 알림 설계하기

라이트하우스 모니터의 목적은 알림을 더 많이 만드는 것이 아니라, 더 좋은 알림을 만드는 것입니다.

모니터링/알림 전략은 다음 두 가지를 동시에 달성해야 합니다.

• 다운타임 최소화: 실제 문제를 가능한 일찍 포착하고
• 알림 피로 감소: 시끄럽고, 자주 깨지는, 가치 낮은 알림을 줄이는 것

라이트하우스 모니터 관점에서 특히 중요한 점은:

• 집계 사용: 단 한 번의 일시적인 실패로 알람을 쏘지 말고, 일정 기간 동안 M번 중 N번 실패 같은 조건을 쓰십시오.
• 적절한 임계값 설정: 예를 들어, “지난 1주일 동안 라이트하우스 실행의 1% 이상이 실패했을 때” 정도로 설정합니다.
• 심각도 우선순위화:
  • 하드 실패(5xx, 타임아웃)는 높은 우선순위
  • 성능 저하(느려졌지만 응답은 하는 상태)는 낮은 우선순위로 두고, 페이지 대신 티켓 생성 정도로 처리
• 지능적인 라우팅: 온콜 페이저 대신, 개발 팀이 슬랙이나 이메일로 저심각도 라이트하우스 실패를 받게 할 수 있습니다.

라이트하우스는 조용하고 예측 가능한 신호가 되어야지, 또 하나의 소방호스가 되어서는 안 됩니다.

느린 부식을 예측 분석으로 잡아내기

실시간 모니터링은 보통 이런 질문에 답합니다. “지금 당장 무언가 깨져 있는가?”

하지만 느린 부식은 종종 이렇게 나타납니다.

• 지연 시간이 조금씩 증가하는 추세
• 재시도 로직 뒤에 숨어 있는 에러율 상승
• 당장은 장애로 이어지지 않았지만 계속 증가하는 메모리/CPU 사용량

실시간 모니터링에 **예측 분석(predictive analytics)**을 더하면, 이런 추세를 장애로 번지기 전에 잡아낼 수 있습니다.

아이디어 몇 가지:

• Prometheus나 Datadog으로 라이트하우스 메트릭(지연 시간, 에러율, 응답 크기 등)의 장기 추세를 추적합니다.
• 일일 라이트하우스 결과에 이동 평균, 표준편차, 롤링 퍼센타일 같은 간단한 이상 탐지 기법을 적용합니다.
• 추세선이 가까운 미래에 임계값을 넘을 것으로 예상될 때 비긴급(non-urgent) 알림을 트리거합니다. (예: “일주일 내에 지연 시간이 SLO를 넘을 것 같다”)

고급 머신러닝이 없어도 충분히 효과를 볼 수 있습니다. 안정적인 일일 신호에 간단한 예측만 얹어도, 슬금슬금 다가오는 문제를 조기에 표면 위로 끌어올릴 수 있습니다.

라이트하우스 구성을 위한 도구 선택

라이트하우스 모니터는 본질적으로 설계의 문제지만, 도구 선택도 중요합니다. 흔히 쓰이는 옵션은 다음과 같습니다.

• Prometheus: 메트릭 기반 라이트하우스 체크에 적합합니다. 라이트하우스 결과를 노출하는 간단한 Exporter를 만들어 Prometheus가 스크랩하게 할 수 있습니다.
• Datadog: 이미 APM/메트릭으로 Datadog을 쓰고 있다면 이상적입니다. Synthetic Monitor 기능으로 라이트하우스 스타일의 체크를 만들고, 풍부한 대시보드를 구성할 수 있습니다.
• Nagios/Zabbix: 전통적인 모니터링 시스템으로, 주기적인 커맨드 실행이나 HTTP 체크를 돌리고 실패 시 알림을 보낼 수 있습니다.

선택 시 고려사항:

1. 기존 스택과의 정렬: 팀이 이미 잘 알고 운영 중인 도구를 활용하는 것이 좋습니다.
2. 명확한 건강 지표 정의: 어떤 메트릭/상태가 “라이트하우스 실행이 양호하다”는 의미인지 명확히 합의해야 합니다.
3. 간단한 설정: 라이트하우스 체크를 추가하거나 수정하는 일이 쉬울수록, 시간이 지나도 정확하고 최신 상태로 유지될 가능성이 높습니다.

간단한 예시 구성:

• 작은 스크립트(Python/Go/Bash 등)를 하나 만들고, 이 스크립트가:
  • /health와 한두 개의 핵심 엔드포인트를 호출하고
  • 지연 시간을 측정하고 응답 코드/본문을 검증하며
  • 결과를 메트릭으로 노출하거나, 모니터링 도구로 전송하게 합니다.
• 이 스크립트를 매일 실행하는 스케줄 작업(cron, Kubernetes CronJob, CI 파이프라인 등)을 둡니다.
• 라이트하우스 메트릭을 기반으로 대시보드와 알람을 구성합니다.

전체 그림 정리하기

실제로 도움이 되는 라이트하우스 모니터를 구축하려면, 다음 단계를 밟아 보십시오.

1. 서비스에 대해 “충분히 건강한 상태”가 무엇인지 정의합니다.

   • 핵심 엔드포인트 목록
   • 지연 시간 기대치
   • 허용 가능한 에러 비율

2. 탄탄한 얕은 헬스 체크를 만듭니다.

   • 빠른 /health 또는 /ready 엔드포인트
   • 외부 시스템을 호출하지 않는 liveness 체크

3. 작은 라이트하우스 스크립트를 추가합니다.

   • 서비스 외부에서 동작하고
   • 부작용이 없으며
   • 하루 한 번(또는 적절한 주기) 실행되도록 합니다.

4. 관측 시스템과 통합합니다.

   • 라이트하우스 메트릭과 로그를 Prometheus, Datadog, Nagios, Zabbix 등에 보냅니다.
   • 트레이스/내부 메트릭과 연계해서 살펴봅니다.

5. 알림과 분석을 튜닝합니다.

   • 실패를 집계해서 플래핑(반복적인 ON/OFF)을 줄이고
   • 단발 이벤트가 아니라 임계값과 추세에 기반해 알람을 만들고
   • 긴급하지 않은 신호는 백로그 관리나 용량 계획에 반영합니다.

결론

장기 실행 서비스는 보통 한 번에 다운되지 않습니다. 조금씩 표류하고, 성능이 떨어지고, 조용히 썩어갑니다. 전통적인 실시간 모니터링과 알림은 필수이지만, 이런 느린 실패를 포착하기에는 충분하지 않을 때가 많습니다.

라이트하우스 모니터—작고, 일일로, 외부에서 실행되는 체크인—는 “서비스가 여전히 우리가 기대하는 방식으로 동작하고 있다”는 단순하지만 강력한 신호를 제공합니다. 이것을 빠르고 가볍고 부작용 없이 설계하고, 탄탄한 관측 가능성과 잘 설계된 알림과 결합하면 다음과 같은 효과를 얻을 수 있습니다.

• 느리게 타오르는 문제를 장애가 되기 전에 드러내고
• 장기 실행 배포에 대한 자신감을 높이며
• 예기치 못한 사고와 온콜의 고통을 줄입니다.

시작부터 거창한 시스템이 필요하지 않습니다. 하루에 한 번, 몇 개의 엔드포인트만 확인하는 최소한의 라이트하우스만 있어도, “아무도 불평 안 하니 괜찮겠지”라고 막연히 믿는 것보다는 훨씬 낫습니다.

부식이 시작되기 전에, 지금 당신의 라이트하우스를 세우십시오.