[LGTM] Observability 기술스택 변경 여정 첫번째

현재 Obserability 기술스택

재직중인 회사에서는 설립 초창기부터 Newrelic을 사용해서 Observability를 확보하고 있었다.

Observability 란?
Rudolf E. Kálmán이 최초로 도입했다고 알려져있다.
 "오직 시스템의 외부 출력만을 이용해서 시스템의 현재 상태를 이해할 수 있는 능력"으로 정의 된다."
즉, 일반적으로는 Log 와 Metric 그리고 APM 정보를 수집해서 현재 제공중인 어플리케이션의 이상 유무를 판단하는것이다.

AWS Cloudwatch 지표, 인스턴스 Log/Metric 그리고 Service log까지 모두 Newrelic에 수집해서 사용하는 구조였다.

그렇다보니 시간이 지나면 지날수록 수집하는 데이터가 많아지게 됬고, 사용한 만큼 과금이 되는 SaaS 특정상 비용 부담이 커지게 됬다.

왜 기술스택을 바꿔야할까?

내가 생각하는 기술스택에는 정답은 없다고 생각한다. 그 당시 선택했던 기술이 시간이 지남에 따라 구형이 될 수도 있고

당시에는 부적합했던 기술이 현재는 적합한 기술이 될 수도 있다고 생각한다.

그래서 정기까지는 아니지만 현재 사용하고 있는 기술스택이 현재 상황에 적합한지 다시 한번 생각해보는것은 필요하다고 생각한다.

 

Newrelic을 사용해본 사람이라면 알겠지만, NRQL 기반으로 쉽게 검색할 수 있는 장점이 있다.

그리고 Cloudwatch, Log, Metric, APM 데이터를 단일 UI에서 한눈에 파악할 수 있기 때문에 좋은 솔루션이라고 생각한다.

하지만, 적재하는 데이터가 많아지고 서비스가 잘 된다면.. 비용 부담이 커지게 된다.

 

위에서 정의한것과 Observability 기술은 자사 어플리케이션에 대한 이상 유/무를 판단하기 위해서는 반드시 필요한 영역이다.

그렇기에 비용 부담이 있지만, 어쩔 수 없이? 하는 계속 갱신계약을 해서 사용하고 있었다.

그러다가 언젠가부터 정말 Observability를 확보하기 위해 사용하는 금액이 합당할까? 모든 서비스 로그를 Newrelic에 반드시 수집해야 할까? 하는 생각이 들었다.

• 일을 하면서 가장 주의해야하는것이 익숙함인것 같다. 익숙함에 매료되어 개선을 하지 않으면 안된다.

그래서 처음에는 기술스택을 바꾸려고 했다기 보다는 Newrelic 계약 비용이 합당한가 검증하기 위해 Self hosted Monitoring PoC를 진행했었다. 그리고 Self hosted PoC를 통해서 검증하고자 했던 항목은 크게 2가지 였다.

• Self hosted vs Newrelic 운영 비용을 고려해서 반드시 SaaS를 써야할까?
• 모든 서비스 로그를 SaaS에 의존해야할까? 기준을 만들고 비용효율적으로 SaaS를 사용할수는 없을까?

PoC에 대한 최종 목표를 수집하고하는 데이터의 기준을 수립하고, 기준에 따라서 SaaS + Self hosted를 같이 사용하는 것이였다.

기술스택 변경의 여정

현황을 파악하고 -> 기준을 만들고 -> PoC를 하고 -> 실제 데이터 이관의 순서를 진행했다.

첫번째, 현황 파악하기

가장 먼저 얼마나 많은 데이터가 어떤 창구를 통해서 수집되는지 현황 정리할 필요가 있었다.

기존에 따로 문서화되어 있는게 없었기 때문에 이번에 정리했었는데, 확실히 현황을 파악해보니 불필요한 영역이 많았다.

• Influxdb는 거의 사용하지 않는데 수집하고 있어서, 이번 기회에 정리를 했다.
• AWS CloudWatch에서 거의 대다수의 AWS 서비스 지표를 Newrelic으로 수집하고 있었는데, 필요한 서비스 지표만 수집하는것으로 변경했고, 수집 주기도 좀 늘렸다.

Observability 현황 파악

두번째, 로그 시스템 적재 기준 수립

지금까지는 데이터 수집은 해서 가시성을 보여줘야 하지만, 로그 시스템 적재 기준이 없다 보니 모두 단일 SaaS에만 의존했던것 같다.

• 운영하는 입장에서도 보면 이미 사용하고 있는 시스템이기에 Helm을 배포하거나 Output을 조금만 변경하면 되기 때문에 설치하기도 간편했고 SaaS이기에 따로 유지보수 노력도 필요하지 않았기에 Newrelic을 사용하는것이 편하다.

기준은 데이터의 중요도와 서비스 영향도 그리고 로그 검색 빈도를 기준으로 기준을 세웠다.

구분	데이터 중요도	서비스 영향도	데이터 검색 빈도	데이터 적재 위치	비고
서비스 클러스터	높음	높음	높음	SaaS
데이터 클러스터	높음	낮음	낮음	Self-hosted	데이터는 중요하나, 잘 보지 않음
샌드박스 클러스터	낮음	낮음	낮음	Self-hosted	테스트를 위한 클러스터
중요 시스템 인스턴스	높음	높음	낮음	SaaS	장애시에만 확인하나, 영향 큼
AWS Infra	높음	높음	높음	SaaS

 

클러스터를 만들거나 신규 인스턴스를 띄울 때마다 그래서 데이터를 어디로 적재할지가 매번 고민이고, 논쟁 거리였는데 로그 시스템 적재 기준을 만들고 나니 논쟁 거리가 줄어들어 업무 효율도 올라갔다.

아래 기준은 각 회사마다 다르고, 가치관에 따라 다를 수 있다. 정답이 있는것은 아니다.

세번째, Self hosted 시스템 선정하기

로그 시스템이라고 하는것이 한번 정하면 변경하기가 쉽지 않았기에 가장 많은 시간을 썼다.

기술스택을 선정할 때 2가지 대전제가 있었다.

• 대전제 1 : 단일 UI에서 Log, Metrics, APM, Cloudwatch 지표 등 확인이 가능해야 한다.
• 대전제 2 : S3와 같은 Object Strogage를 제공해야 한다.

처음에는 OpenSearch를 알아보고 ELK 스택을 알아보았으나 대전제 1, 2를 만족하는 솔루션이 많지 않다. 

대전제 1을 만족하기 위해서는 Grafana 가 최적이였고, Grafana에서 지원하는 시스템 중 대전제 2를 찾다보니 결국 LGTM을 선택했다.

LGTM : Loki + Grafana + Tempo + Mimir 기술스택을 뜻하며 최근 Grafana 재단에서 내세우고 있는 스택이다.
Loki를 통해서 Log를 수집하고, Tempo를 통해서 APM 데이터를 수집하며 Mimir로 Metrics 정보를 수집한다.
그리고 해당 데이터를 모두 Grafna에서 Data Source로 설정이 가능하고, Mysql 등의 3rd도 Source로 설정이 가능하다.

 

LGTM 기술스택이 Grafana에서 모두 사용 가능하다는것도 좋았지만, 특히 S3를 외부 저장소로 사용할 수 있다는 점이 좋았다.

주변에 Observability 사용 현황을 보면 대다수 데이터 용량에 큰 문제를 겪는다.

데이터 용량이 크기 때문에 주기적으로 클리닝 작업을 해줘야하고, 그렇기에 장기간 데이터를 보관하는데 큰 어려움이 있다고 한다.

하지만, S3를 사용하게 되면 그런 어려움에서는 완전히 자유로워진다.

 

그리고 최근에 타사를 보면 LGTM 기술스택을 많이 사용하는것 같았다.

핀다, 우아한 형제들 모두 2023년 ELK 스택에서 LGTM, 특히 Loki로 Monitoring 기술 스택을 변경했다는 블로그가 있었다.

• ELK는 이전 회사에서 운영했었는데, Logstash도 빈번하게 연결이 끊어지고 결국에는 스토리지 문제가 있었다.

---

왜 Observability, Monitoring을 해야 하는지에 대해 의문을 가지는 사람은 없을것이다.

다만, 우리 회사에서는 어떤 방식으로 Monitoring 할것 인가에 대해서는 의문을 가져야 한다고 생각한다. 정답은 없다.

 

재직중인 회사에서는 SaaS를 사용하다가 일부 시스템을 Self-hosted로 이관을 해서 사용하고 있다.

하지만 Devops팀이 없거나, Devops팀 리소스가 없는 회사일 경우에는 Self-hosted보다는 SaaS 사용이 더 좋을 수 있다.

그리고 SaaS를 사용한다고 하더라도, 데이터 수집 주기나 필요한 데이터만 적절하게 필터링한다면 효율적으로 사용할 수 있다.

 

만약, 아직 회사에서 로그 시스템 적재 기준이 없다면 이 글을 보고 꼭 수립해보는것을 권고하고 싶다.

이전에는 필요성을 느끼지 못했는데, 이번에 기준을 세워보고 나니깐 어떻게 하면 로그 시스템을 비용 효율적으로 사용할 수 있을까? 생각해보는 계기가 되기도 했고 애매한 부분에 대한 해결책을 많이 만들었다.

• 기준이 없을 때는 로그 검색 빈도도 적고, 시스템 중요성은 없으나 종종 로그를 봐야할 때가 있었다.
• 그리고 이런 작은 사유 때문에 SaaS를 사용하고 있었고, 지금 생각해보면 아주 비효율이라고 생각한다.

 

다음장에는 LGTM 중에서 LPG 스택에 대한 글을 작성해보려고 한다. 끄읏!