현재 고객사에 2년째 프리렌서로 MSA와 DevOps 설계를 지원하고 있는데요. 나름 사업이 잘되서 시스템 증설 등 지속적으로 늘어나고 있는데… 고민이 생겨요. 현재 민감한 정보는 안보이게하고, 옵져빌러티는 최대한 효과적으로 해야되서요. 현재는 그라파나 프로메테우스만 사용하고 있습니다. APM 툴은 꽤 많은데, 구매할 생각은 없는거 같아서요.
물론, 로그량이 증가하면서 알람 설정 등 좀 자유도 높게 사용하고 싶은데요. 조언을 부탁드립니다. (참고로, 이커머스는 아니고 내부 MES와 같은 철강분야에 있는 중견기업이랍니다.)
| This is a space where knowledge is not merely consumed, but respected, sovereign, and connected—shared together with cloud industry professionals (Bros).|
| 지식이 소비되지 않고 존중·주권보장·연결되는 공간으로 클라우드 현업 전문가(Bro)와 함께 공유하고 있습니다. |
말씀 주신 내용을 정리해 보니, 지금 고민은 새로운 도구를 더 도입할지의 문제가 아니라, 이미 사용 중인 구성으로 어디까지 볼 수 있느냐에 대한 이야기로 느껴졌습니다. Prometheus와 Grafana를 이미 쓰고 계신 상황이면, 옵저빌러티의 기본 뼈대는 충분히 갖춰져 있다고 봅니다. 다만 시스템이 커지고 로그량이 늘어나면서, 예전처럼 “대충 여기쯤일 것”이라고 짐작하던 방식이 점점 통하지 않게 되는 시점에 들어온 것 같고요.
상용 APM을 도입하지 않는다는 전제에서는 목표를 조금 현실적으로 잡는 게 중요합니다. APM이 제공하는 모든 기능을 그대로 구현하려고 하면 복잡도만 올라가고 운영 부담이 커집니다. 대신 실제 운영에서 체감되는 핵심, 즉 지금 시스템이 정상인지, 문제가 생기면 어디서 시작됐는지, 그리고 왜 느려졌는지를 설명할 수 있느냐에 초점을 맞추면 오픈소스 조합만으로도 충분히 납득 가능한 수준까지 갈 수 있습니다.
Prometheus는 이 중에서 “지금 상태가 어떤지”를 보여주는 역할은 이미 잘하고 있습니다. 서비스별 처리 시간이나 에러 비율, 공정 지연 여부 같은 것들은 지금도 어느 정도 보고 계실 겁니다. 다만 Prometheus만으로는 항상 한계가 있는데, 알람은 울렸는데 그 다음에 무엇을 봐야 할지가 바로 연결되지 않는다는 점입니다. 이 지점에서 로그와의 연결이 필요해집니다.
Grafana를 이미 사용 중이라면 로그 쪽에서는 Loki를 함께 사용하는 구성이 가장 자연스럽습니다. Loki의 장점은 로그를 단순히 쌓아두는 저장소로 쓰는 게 아니라, 메트릭에서 이상이 감지된 시점의 상황을 바로 이어서 볼 수 있다는 점입니다. Prometheus에서 특정 서비스나 공정의 지연이 보이면, 같은 화면에서 해당 시간대의 로그를 바로 열어볼 수 있고, 반복되는 에러나 평소에는 나오지 않던 메시지가 있는지 빠르게 확인할 수 있습니다. 이 흐름이 만들어지는 순간부터, 체감은 “로그 조회”가 아니라 “상황 파악”으로 바뀝니다.
보안 측면에서도 이 접근이 유리합니다. 로그를 많이 모은다고 해서 민감한 정보를 그대로 노출할 필요는 없고, 수집 단계에서 아예 특정 필드를 제거하거나 마스킹한 상태로 들어오게 설계할 수 있습니다. MES처럼 업무 흐름이 비교적 명확한 시스템에서는 사용자 정보 대신 공정 단계, 상태 값, 처리 결과 중심으로 로그를 재정의하는 것만으로도 장애 분석에는 충분한 맥락을 확보할 수 있습니다. 이렇게 하면 옵저빌러티 영역에는 애초에 민감 정보가 들어오지 않게 됩니다.
여기에 한 단계 더 얹을 수 있는 것이 Grafana Tempo입니다. Tempo는 흔히 말하는 APM의 “트레이싱” 영역을 담당하는 도구인데, 쉽게 말하면 하나의 요청이 여러 서비스를 거치면서 어떻게 흘러갔는지를 시간 순서대로 보여주는 역할을 합니다. OpenTelemetry를 통해 요청에 공통 식별자(trace ID)를 붙여 두면, 그 요청이 어떤 서비스에서 얼마나 머물렀는지, 어디에서 지연이 발생했는지를 한 눈에 볼 수 있습니다. 중요한 점은 Tempo 자체를 단독으로 쓰는 게 아니라, Grafana 안에서 Prometheus와 Loki와 함께 엮인다는 점입니다.
Grafana 화면에서는 메트릭 그래프에서 특정 시점을 클릭했을 때, 그 시점과 연관된 로그를 바로 열어볼 수 있고, 로그 안에 포함된 trace ID를 통해 다시 해당 요청의 트레이스 화면으로 넘어갈 수 있습니다. 즉, “처리 시간이 늘어났다”는 메트릭에서 출발해서, “이 시간대에 이런 에러 로그가 있었고”, “그 로그가 남은 요청은 이 경로를 따라 흘러갔다”라는 흐름을 한 화면 안에서 자연스럽게 이어서 볼 수 있게 됩니다. 이 경험이 상용 APM에서 사람들이 가장 편하다고 느끼는 부분이고, Tempo를 포함한 Grafana 스택이 그 부분을 꽤 잘 재현해 줍니다.
물론 이 트레이싱을 모든 서비스에 한 번에 적용할 필요는 없습니다. MES 환경에서는 특히 문제가 자주 발생하거나 성능 이슈에 민감한 핵심 공정 경로 몇 개만 대상으로 삼아도 효과가 분명합니다. 그렇게 시작해도 “왜 이 요청만 유독 느렸는지”를 설명할 수 있는 근거가 생기고, 운영과 개발 사이의 대화도 훨씬 수월해집니다.
이런 구조가 갖춰지면 알람의 성격도 자연스럽게 달라집니다. 단순히 서버 자원이 임계치를 넘었다는 알람이 아니라, 특정 공정에서 처리 시간이 늘어나고 있고, 그 시점에 어떤 에러 로그가 반복되고 있으며, 해당 요청이 어느 구간에서 지연되고 있는지까지 함께 이야기할 수 있게 됩니다. 운영팀이나 개발팀 입장에서는 알람을 받는 순간부터 대응 방향이 훨씬 명확해질 수밖에 없습니다.
정리해 보면, 지금 고객사 상황에서는 상용 APM을 새로 도입하는 것보다 Grafana를 중심으로 메트릭과 로그, 그리고 필요한 만큼의 트레이싱을 하나의 흐름으로 묶어 주는 쪽이 비용과 보안, 운영 부담을 모두 고려했을 때 가장 균형 잡힌 선택으로 보입니다. 이미 기반은 충분히 갖춰져 있고, 방향만 잘 잡으면 체감 효과는 생각보다 클 겁니다.