Observability : Logs vs Traces vs Metrics! (번역) - 1

음 요즘 서비스에 대한 모니터링이라는 것에 대해서 관심이 가서 이것저것 공부하고 있는데 제목이 좀 끌려서 한번 읽어볼겸 번역해보려고 한다...

Observability : Logs vs Traces vs Metrics!

---

소프트웨어 시스템은 어떤 조직에서든지 필수적인 부분이 되고 있다. 그리고 조직이 발전하면서 소프트웨어 시스템 역시 복잡해진다. 분산 시스템에서 어떤 일을 수행하기 위해 여러 구성요소들이 모이면 시스템을 모니터링하는 일은 더욱 어려워진다. 시스템 모니터링에는 시스템 상태를 살펴보고, 애플리케이션 문제를 확인하고, 요청의 전체 흐름을 추적하는 등의 작업이 포함된다. 소프트웨어 시스템에서 각각의 구성요소들은 특정 이슈를 모니터링, 검색, 식별 및 디버깅하기 위한 서로 다른 다양한 모니터링 툴이나 알림 매커니즘을 갖고 있을 수 있다.

Observability(관찰가능성?) 는 다양한 메커니즘이 시스템의 이슈를 추적하는 것 뿐만아니라 시스템의 전반적인 정확성을 모니터링하고 추적하는 것을 나타낸다. 그것이 monolith 시스템이건 micro 시스템이건 상관 없이.

Logging, Metrics, traces는 종종 Observability(관찰가능성?)에 대해서 이야기를 할때 상호 교환적으로 사용되지만 각각은 고유한 방식으로 동작하고 서로 다른 결과를 얻어낸다. 이러한 것들을 단독으로 사용하면 관찰 가능한 시스템을 보장할 수 없지만 이러한 것들에 대해서 잘 이해하고 사용한다면 더 나은 시스템을 구축하는데 도움이 된다.

분산시스템의 장애는 특정 하나의 컴포넌트의 특정 하나의 이벤트로 발생하는 것이 아니다. 장애는 일반적으로 시스템의 여러 컴포넌트에서 다양한 트리거들로부터 올 수 있다. 그렇기 때문에 단순히 실패 지점만을 보는 것으로는 장애에 대한 정확한 이유를 얻지 못할 수도 있다. 그래서 근본적인 원인을 찾기 위해서는 아래와 같은 것들이 필요하다.

1. 증상을 세분화 된 수준으로 분석한다.
2. 요청의 lifecycle을 시스템의 다양한 컴포넌트에서 추적한다.
3. 다양한 컴포넌트간의 상호작용을 분석한다.

LOGS

로그는 요청이 수행되는 동안 시스템의 임의의 시점에서 일어난 이벤트에 대한 기록이다. 로그는 보통 timestamp와 context payload를 포함하고 일반 텍스트, json 또는 binary로그와 같은 다양한 형식으로 내보낼수 있다. 

로그를 생성하는 것은 간단하고 대부분의 라이브러리들은 ELK나 Sumologic 등등의 중앙 집중식 로깅 시스템에 로그이벤트를 push하는 기능을 제공한다. 로그는 매우 세부적인 수준에서 디버깅하는데에 도움을 주며 백분위수나 평균으로는 알 수 없는 자세한 통찰을 얻는데에 유용하다.

로그를 생성하는 것은 프로그램에서 프린트문을 찍는 것처럼 쉬울 수 있지만 로그를 최대한 활용하기 위해서는 명심해야하는 몇가지 사항이 있다.

1. 과도한 로깅은 저장 비용을 증가시키고 로그의 검색 효율성을 떨어트릴 수 있기 때문에 좋지않다. 그렇기 때문에 기록할 데이터와 기록하지 않을 데이터를 결정하는 것이 중요하다.
2. 로그는 어떤 문제(또는 현상)에 대한 의미있는 통찰을 제공하기 위해서 문제에 대한 모든 맥락을 파악할 수 있는 정보를 가지고 있어야한다.
3. 로깅은 항상 비동기여야 하며 요청의 흐름을 방해해서는 안된다.
4. 데이터를 로그에 푸쉬할 때 중요하고 민감한 데이터가 빠지진 않았는지 확인을 해야한다.
5. 대부분의 로그 데이터는 장기적인 분석에 필요한 분석데이터와 달리 단기적인 기간의 용도(단순히 현상 확인)로 사용되므로 로깅 시스템의 효율을 높이기 위해서 저장 정책을 사용할 수 있다.(며칠이 지난 로그 데이터는 삭제를 한다던지 - 저장 비용의 문제등으로?)

METRICS

로그는 일반적으로 시스템 성능, 시스템 이상 징후 감지 또는 비즈니스 적인 분석에 대한 통찰력을 얻기 위해서 사용되지 않는다. 데이터는 대부분 짧은 기간동안 유지되며 이벤트 발생 후 짧은 시간 동안 가장 유용하게 사용된다. 따라서 Metric이라는 또 다른 모니터링 메커니즘의 필요성이 떠오르는 것이다.

메트릭은 백분위수나 평균과 같은 숫자 표현으로 시스템을 전체적으로 모니터링하는데에 도움을 주고 일정 시간마다 측정이 된다.

메트릭은 시스템의 이상 징후를 감지하고, 각기 다른 시간 간격별로 시스템의 동작을 분석하며 최근의 추세를 알아내는데 사용된다. 대부분의 데이터는 갯수와 숫자의 형태로 저장이 되어서 데이터를 저장하고 처리하고 검색하고 조회하는데에 최적화 할 수 있다. 숫자 값은 저장공간을 문자열에 비해 적게 차지하므로 데이터를 오래 저장할 수 있고 그 데이터로 최근의 추세를 알아내고 시스템 전체 상태를 감지하기 위한 다양한 대쉬보드를 구축하는데 사용할 수 있다. 

메트릭은 보통 아래의 필드들로 구성이 된다.

1. Metric Name
2. Timestamp
3. Labels

로그와 달리 메트릭은 알림을 발생시키는 것이 효율적이다. 왜냐하면 시계열 데이터베이스에서 쿼리를 실행하는 것이 elastic search와 같은 분산 시스템에 저장된 로그에 쿼리를 하는 것보다 훨씬 빠르기 때문이다. 메트릭을 생성하는동안 명심해야 할 것은 너무 많은 라벨을 사용하면 저장비용이나 쿼리의 오버헤드가 증가할 수 있다는 점이다.

 

 

다음 번에는 Tracing 파트에 대해서 번역을 하겠습니다. 한 큐에 가려다가 좀 어렵고 길어져서...