서버가 멈추기 전에 알 수 있을까? 소규모 서비스 모니터링 구성
모든 장애를 미리 예측할 수는 없다. 대신 사용자가 먼저 알려 주기 전에 이상을 발견하고, 원인을 좁힐 자료를 남기고, 같은 장애가 반복되지 않게 만들 수는 있다. 소규모 서비스의 모니터링은 비싼 도구보다 적은 수의 정확한 신호에서 시작하는 편이 낫다.
네 층으로 나눠 본다
1. 외부 가용성
인터넷 밖의 감시 지점에서 로그인 페이지와 핵심 API를 호출한다. 서버 내부의 프로세스가 살아 있다는 신호만으로는 DNS, 인증서, 방화벽, 프록시 장애를 발견하지 못한다.
Uptime Kuma는 HTTP, TCP, WebSocket, DNS, Ping과 인증서 만료 등을 확인하고 여러 알림 채널로 통지할 수 있는 자체 호스팅 도구다. 작은 VPS가 이미 있다면 시작 비용을 낮추기 좋다. 다만 감시 대상과 같은 서버에만 설치하면 서버가 함께 멈출 때 알림도 사라진다. Uptime Kuma 공식 저장소
2. 애플리케이션 오류
오류 개수만 세지 말고 배포 버전, 사용자 요청, 추적 ID, 호출 경로를 연결한다. 같은 오류가 천 번 나면 천 건의 알림을 보내는 대신 하나의 사건으로 묶고 영향을 받은 사용자 수를 본다. 개인정보, 토큰, 요청 본문 전체를 무분별하게 수집하지 않는 것도 중요하다.
3. 자원과 데이터베이스
CPU, 메모리, 디스크 사용률뿐 아니라 증가 속도를 본다. DB는 연결 수, 느린 쿼리, 잠금, 복제 지연을 확인한다. Vercel Observability는 모든 플랜에서 프로젝트의 트래픽과 성능을 볼 수 있고, 더 긴 보존과 추가 기능은 플랜에 따라 달라진다. Vercel Observability
4. 업무 지표
가장 중요한 신호는 기술 지표가 아닐 때가 많다. 결재 요청이 평소보다 급감했는지, 대기 작업의 가장 오래된 항목이 몇 분째인지, 메일 발송 실패가 쌓이는지 확인한다. 서버가 정상이어도 업무 흐름이 멈춘 상태를 잡아낼 수 있다.
처음 설정할 알림
| 알림 | 의미 | 첫 대응 |
|---|---|---|
| 핵심 URL 연속 실패 | 사용자가 접근하지 못할 가능성 | 외부에서 재확인, 최근 배포 확인 |
| 오류율 급증 | 새 코드나 외부 연동 문제 가능성 | 배포 버전과 오류 묶음 확인 |
| 디스크 부족 예상 | 로그, DB, 이미지가 디스크를 채우는 중 | 증가 원인 확인, 안전하게 정리 |
| DB 연결 포화 | 요청 지연과 실패 가능성 | 연결 누수, 풀 설정, 느린 쿼리 확인 |
| 큐의 오래된 작업 증가 | 워커 중단 또는 처리 병목 | 워커 상태, 실패 사유, 재시도 확인 |
| 백업 미실행 | 복구 가능한 시점이 멀어짐 | 백업 작업과 저장 위치 확인 |
| 인증서 만료 임박 | HTTPS 접속 장애 가능성 | 자동 갱신과 DNS 확인 |
한 번의 실패로 야간 알림을 보내면 일시적인 네트워크 흔들림에도 사람이 깨게 된다. 연속 실패 횟수와 일정 시간을 조합하고, 경고와 긴급 알림을 나눈다. 반대로 결재나 결제처럼 한 번의 실패도 중요한 업무는 별도 기준을 둔다.
20명에서 100명까지의 구성
20명
외부 URL 확인, 오류 추적, 플랫폼 기본 지표, 백업 실패 알림이면 충분한 경우가 많다. 알림은 운영 담당자와 한 명의 대체 담당자에게 보낸다.
50명
큐, DB 연결, 주요 업무 성공률을 추가한다. 배포 버전을 오류와 연결하고, 반복 장애에 대한 짧은 대응 절차를 만든다.
100명
서비스별 책임자, 심각도, 공지 채널을 정한다. 운영 대시보드를 만들고 월별로 오류 예산과 복구 시간을 검토한다. 외부 감시와 로그 저장소가 운영 서버와 같은 장애 영역에 있지 않은지도 확인한다.
알림에는 행동이 붙어야 한다
좋은 알림은 무엇이 이상한지, 어느 서비스인지, 언제 시작됐는지, 어디를 확인할지를 담는다. 각 긴급 알림에 한 페이지 분량의 실행 문서를 연결한다. 최근 배포 취소, 워커 재시작, 읽기 전용 전환처럼 안전한 첫 행동을 명시하면 담당자가 바뀌어도 대응 속도를 유지할 수 있다.
모니터링의 목표는 그래프를 많이 만드는 것이 아니다. 사용자 영향이 있는 문제를 빨리 찾고, 원인을 확인할 증거를 남기며, 복구 행동까지 이어 주는 것이다. 처음에는 다섯 개 안팎의 중요한 알림으로 시작하고, 실제 장애에서 쓸모가 없었던 알림은 지우는 편이 건강하다.
우리 서비스에 적용할 계획이 있으신가요?
클라우드 구축·배포 운영 살펴보기 →함께 읽기
- 모니터링 서비스 비교: Better Stack부터 Datadog까지 7곳Better Stack 첫 화면에는 표가 하나 있습니다. 한 달에 트레이스·로그·지표를 각각 1TB씩 보낼 때 Datadog은 약 $55,574, Better Stack은 $687이라고 적혀 있습니다. 표 아래 각주는 이 숫자가 추정치이며 연 결제, 유럽 데이터 위치, 응답자 1명, Tera 번들, 평균 이벤트 크기 1…
- 배포가 실패해도 5분 안에 되돌리는 소규모 서비스 운영법빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.
- 웹사이트 구축 후 운영 설계: 측정·콘텐츠·보안·백업웹사이트는 공개 버튼을 누르는 순간 완성되는 것이 아니라 운영이 시작된다. 담당자, 지표, 콘텐츠 갱신, 보안 업데이트, 백업과 복구 절차가 없으면 잘 만든 사이트도 빠르게 낡는다. 이 글에서는 소규모 팀도 지속할 수 있는 웹사이트 운영 체계를 만드는 방법을 다룬다.
- Sentry 란 무엇인가: 에러 수집 도구가 하는 일과 대안 비교헬스체크는 200 을 돌려주는데 화면은 500 입니다. 컨테이너는 떠 있고, 워치독은 조용하고, 서버 로그에는 같은 스택 트레이스가 수백 줄 흩어져 있습니다. 어느 배포부터 시작됐는지, 몇 명이 겪었는지, 지금도 나고 있는지는 로그를 아무리 봐도 안 나옵니다.
- 20명에서 100명까지, 사내 시스템 배포 아키텍처 설계하기사내 시스템은 직원 수가 적다고 해서 항상 가볍지 않다. 20명이 쓰는 문서 변환 시스템은 100명이 쓰는 단순 결재 시스템보다 더 많은 CPU와 저장 공간을 요구할 수 있다. 그래서 배포 구조는 인원수보다 동시 접속, 요청 시간, 파일 크기, 실시간 연결 수, 장애 허용 시간을 기준으로 정해야 한다.