Observability & Opentelemetry

옵저버빌리티(관찰가능성)란 ?

옵저버빌리티를 사용하면 다음과 같은 질문을 통해 외부에서 시스템을 이해 할 수있다.

내부 동작 방식을 모른채 그시스템에 대한 질문 또한 새로운 문제 즉 “알수없는” 문제를 쉽게 해결하고 처리 할 수 있다. 또한 알수 없는 문제들에 있어 “왜 이런 일이 발생하는가?” 에대한 질문에 답을 하는데 도움이 된다.

 

	Moniteroring	Observability
접근 방식	미리 정의된 지표 주심의 상태 이상 감시	내부 상태 추론, 원인 파악 및 분석
활용 데이터	Metrics, 알림	Metrics, Logs, Traces
목표	무엇이 문제인가? 에 대한 문제 감지 /알림	왜 문제가 발생 하였는가? 에 대한 근본적인 원인 분석
활용 범위/관점	일부 시스템, 사후 대흥	시스템 사전.사후 통합 분석

 

 

옵저버빌리티란 무엇일까요?

그림을 보았듯이 옵저버빌리티는 빙산의 일각 혹은 그아래 숨겨진 또다른 빙산을 보여 주듯이

모니터링과 함께 이야기 되는 영역으로 함께 쓰이고 있습니다.

 

그림에서 보이듯이 시스템 내부의 상태를 외부에서 관찰 가능한 지표 (메트릭, 로그, 트레이스) 등을 토해 파악하고 분석하여 문제 해결 및 시스템 성능을 최적화 하는 능력입니다.

그럼 좀더 모니터링과 옵저버빌리티에 대해 살펴 보겠습니다.

 

모니터링 접근 방식입니다.

미리 정의된 지표를 통해 상태 이사을 감지하고, 매트릭을 통해 알림을 받습니다. 무엇이 문제인가? 에 대한 문제 감지가 가능 하고 알림을 받을수 있습니다.

옵저버빌리니는 내부상태를 추론하고 원인을 파악그리고 분석하기 위한 용도로 활용됩니다.

매트릭, 로그 , 트레이스 데이터를 활용하며 왜 이문제가 방생하였는가에 대한 근본적인 원인을 분석하기 위해 사용됩니다.

 

그럼 이런 옵저버빌리티가 왜!! 필요한것일가요?

현재 시스템은 기존 모놀리틱 서비스 아키텍처에서 마이크로서비스로 점차 변화 하고 있습니다.

그럼 이둘은 무엇이 다를가요? 그림에서도 보시다 싶이 모놀리틱 서비스는 하나의 레이어 안에 모든 기능을 담고 있습니다.

UI/ 비지니스로직/ 데이터 레이어 엑세스 모든것을 하나의 통안에서 하고 있습니다.

 

반면 마이크로 서비스는 기능 별로 서비스가 분리되어 있는 아키텍처 입니다.

여기서 마이크로 서비스에 대한 이야기를 하면 또다른 이야기가 파생되니 옵저버빌리티가 중요해진 이유에 대해 말씀드리고 넘어가겠습니다.  기존 모놀리틱에서는 모든 기능이 하나의 어플리케이션 안에서만 동작되기에 로그를 확인할때 하나의 로그만 확인 하는것으로 가능 하였습니다.  하지만 분산 서비스 즉 MSA 가 되며 로그 데이터 를 하나의 서비스가아닌 다른 서비스에서도 보아야 추적이 가능한 시스템이 되어 버린 것입니다.

 

 

이때문에 분산 추적 기술이 등장 하게 되었습니다.

좀더 다른 복잡한 Spring boot 기반의 MSA 서비스 입니다. 각 기능별로 나뉘어져 있으며 각 모듈들은 하나의 기능을 담당하게 됩니다.  그럼 다음으로 메트릭 수집은 어떻게 해야 하는지 알아 보겠습니다.

매트릭 수집 생태계 입니다. ELK , Grafana 가 있습니다.

각각의 에코시스템은 다르게 되어 있습니다. 잘아시다 싶이 log 수집은 elk , 메트릭 지표는 grafana 스택을 사용하시면 됩니다.

 

이제 Traceing 도구로는 무엇이 있는지 살펴 보겠습니다.

 

tracing 도구로는 zipkin, jaeger, tempo가 있습니다.

각각 모두 장단점을 가지고 있습니다.

zipkin은 트위터에서 만들고 개발하여 사용하고 있는 오픈 분산 추적도구입니다.

Jaeger는 우버에서 만들고 개발하여 사용중인 분산 추적도구이고,

Tempo는 그라파나에서 만들고 개바하여 사용중인 분산 추적도구입니다.

모두 분산 추적도구이며, 어떤 도구를 이용하여 트레이싱을 할지는 서비스의 성격에 맞게 선택하면됩니다.