Observability — 작은 팀의 가난한 자의 스택
Datadog도 Grafana Cloud도 없는 세 명짜리 팀이 운영 중인 서비스를 어떻게 들여다보는지, 현실적인 observability 스택을 공유한다.
“Observability”라는 단어를 들으면 Datadog, New Relic, Grafana Cloud, Jaeger 같은 이름들이 떠오른다. 전부 훌륭한 도구다. 그리고 전부 작은 팀이 선뜻 결제하기엔 비싸거나, 세팅하는 데 드는 시간 비용이 운영 이점보다 크다. 우리 팀은 세 명이고, 서비스는 여러 개다. 이 글은 그 간극을 어떻게 메웠는지에 대한 기록이다.
우리가 정말로 필요한 것
먼저 무엇을 알고 싶은지를 정리했다. 서비스가 살아있는가, 응답이 느려지고 있는가, 에러가 갑자기 늘었는가, 서버 리소스가 한계에 다가가고 있는가. 이 네 가지다. 분산 트레이싱이나 실시간 대시보드는 나중 문제다. 일단 이 네 가지를 저비용으로 커버하는 것이 목표였다.
실제 스택
헬스체크 + 업타임 알림은 UptimeRobot 무료 플랜으로 해결했다. 1분 간격으로 엔드포인트를 찌르고, 다운되면 슬랙으로 알림이 온다. 비용 제로, 세팅 5분.
로그 수집은 서버별 journalctl과 애플리케이션 로그 파일을 tail -f로 보는 수준에서 시작했고, 지금은 Loki + Promtail 조합을 셀프호스팅으로 운영한다. Loki는 메모리를 적게 먹고, Promtail은 설정 파일 몇 줄이면 원하는 로그를 긁어온다. 대신 Grafana는 붙이지 않았다. LogCLI로 터미널에서 쿼리하는 것이 우리 워크플로우에 더 맞았다.
메트릭은 Prometheus + 단일 node_exporter다. 전체 인프라를 커버할 생각은 없고, 가장 중요한 서버 두 개에만 붙여두었다. CPU, 메모리, 디스크, 네트워크. Grafana 없이 Prometheus의 기본 UI로 필요할 때만 들여다본다.
에러 트래킹은 Sentry 무료 플랜이다. 프로젝트당 월 5,000 이벤트 제한이 있지만, 규모가 작을 때는 전혀 부족하지 않다. 스택 트레이스와 환경 정보가 슬랙으로 바로 와서 반응 속도가 크게 빨라졌다.
운영하며 배운 것
완벽한 가시성보다 빠른 알림이 더 중요하다는 걸 깨달았다. 무슨 일이 일어났는지 아는 것보다, 일이 생겼다는 것을 빨리 아는 게 먼저다. 그래서 우리는 UptimeRobot과 Sentry 알림 설정에 가장 공을 들였다. 나머지는 일이 생기고 나서 손으로 뒤지는 방식으로 충분했다.
비용도 따져보면 현재 월 0원에 가깝다. 셀프호스팅 서버 비용이 있지만, 어차피 서비스를 위해 띄워둔 서버에 사이드카처럼 붙여둔 것이라 추가 비용이 거의 없다. 팀이 커지거나 트래픽이 늘어나면 그때 유료 SaaS로 이전할 계획이다. 지금은 이 스택으로 충분하다.
— by mings