Opentelemetry 에 대해서

이 섹션에 사용된 자료는 https://hanmac-study.github.io/hanmac-opentelemetry-demo/ 링크에 모두 있음

</aside>

Opentelemetry는 무엇인가

OpenTelemetry는 "Open"(열린) + "Telemetry"(원격 측정)의 합성어임

의사가 환자의 상태를 원격으로 모니터링하는 것처럼 개발자가 애플리케이션의 건강 상태를 원격으로 확인할 수 있게 해주는게 주목적임

다시말해 애플리케이션의 상태를 실시간으로 관찰하고 문제를 빠르게 찾는 도구이다.

한 줄 요약했다고 기능이 단순하다고 생각하면 안된다. 엄청난 규모의 오픈소스이다. (https://github.com/open-telemetry)

무려 CNCF(Cloud Native Computing Foundation) 에서 관리하는 오픈소스이다. (Kubernetes 관리하는 거기 맞다)

이 오픈소스를 이해하기 위해선 배경지식이 약간 필요하다.

하나씩 알아보겠다.

모니터링 시스템의 진화 과정부터 알아보자

과거에도 서비스 로그를 쌓고 분석했다.
지금과 다른점은 로그 파일을 문자열로 쭈욱 쌓아놓고 정적으로 분석하거나 RDBMS에 트리거 기능을 활용해 Log History를 쓰거나 하는 등 다양한 수단을 이용했다.
- 레거시 시스템에서는 지금도 사용된다.
현재에는 Datadog, New Relic 등의 업체에 의해서 APM이라는 개념이 등장했고 이들 서비스를 사용해서 자사 서비스를 분석했다.
- 문제는 벤더 독립적이지 않기 때문에 APM 업체를 바꿔야 할때 혹은 분석에 있어서 크리티컬 이슈가 발생했을 때 대응이 안됐었다.
- 그리고 2015년부터 MSA가 대두되기 시작하면서 분산된 환경에서 사용자 요청이 여러 서비스를 거쳐 처리되기 시작했다.
  - 하나의 요청을 처리 할 때 여러 서버에 걸쳐서 처리하는 일이 빈번해졌고 이 때 어디서 병목이 생기는지 어떤 오류가 발생하는지 추적하기가 골치아파지기 시작한것임
  - 기존의 로그나 메트릭만으로는 분산된 서비스 간의 복잡한 상호작용을 파악하기에 한계가 있었다는 것임.
이 때부터 (2015년 즈음부터) 마이크로서비스 환경에서 요청의 전체 흐름(Trace)을 시각화하고 각 서비스에서의 응답 시간(Span)을 측정하여 문제 지점을 빠르게 식별할 수 있는 분산 트레이싱(Distributed Tracing) 기술의 중요성이 커지기 시작했다
- 2014년도부터는 MSA 개발이 애플리케이션 설계시 일반적으로 채택되는 패턴으로 자리 잡았었다. (https://rejolut.com/blog/devops-microservices-and-what-challenges-are-faced-in-implementing-a-microservice-architecture/)
- MSA에 대해서 잘 알고 싶다면 https://martinfowler.com/microservices/ 를 참고하면 됨
그리고 APM 을 넘어선 관측가능성 (=Observability) 을 확보해야 한다는 의견이 나오면서 OpenTracing 이라는 오픈소스가 대기업에 의해서 발족된다.