1. 누가 왜 이런 말을 만들었나?
클라우드 플랫폼이 등장하고 어플리케이션의 현대화 (Application Modernazation)라는 패러다임이 등장하면서 서비스는 더욱 복잡하고 어플리케이션은 점점 세분화 되어 간다. 이로인해 각각의 서비스에서 처리되는 트랜잭션과 워크로드는 이전보다 더 증가되었을 뿐만 아니라 개별 서비스와 연계되어 있는 관리 포인트는 점점 증가하기 시작했고 클라우드의 특성상 서비스의 워크로드는 불규칙하게 증가하고 그에 준하는 컴퓨팅 파워는 Scale-In/Out을 주기적으로 반복해야 되는 클라우드 컴퓨팅 환경에서는 서비스 부터 인프라까지 전체를 통합관찰 할수 있는 새로운 모니터링 방식이 요구되기 시작했다.
[참고 이미지 : ReserchGagte]
관찰 가능성 (Observability)이라는 말은 신호처리,제어 시스템과 내비게이션 및 제어에 널리 사용되는 수학적 알고리즘 Kalman 필터의 공동 발명 및 개발자인 Rudolf E. Kálmán에 의해서 아래와 같이 정의하였다.
"외부 출력만을 사용하여 시스템의 현재 상태를 이해하는 능력" 이라고 정의
the ability to understand the current state of a system using only its external outputs."
관찰 가능성(Observability)라는 단어를 Rudolf가 정의할때는 엔지니어링 측면에서의 설명한 것이다 그렇다며 소프트웨어 시스템 측면에서의 관찰 가능성(Observability)은 어떤 의미일까?
2. Observerbility를 위해서 뭐가 필요한가?
프트웨어 엔지니어링 용어로 통합 가시성이란 내부 상태에서 수집한 데이터를 사용하여 시스템의 동작을 이해하고 디버깅할 수 있는 기능을 말한다.
소프트웨어 엔지니어링에서 통합 가시성을 달성하려면 애플리케이션에 계측 기능이 있어야 하며, 여기에는 시스템에 코드를 추가하여 동작에 대한 데이터를 수집하는 것이 포함된다. 로깅, 메트릭, 추적 및 디버깅 도구가 포함될 수 있다.
로깅(Logging)에는 오류, 경고 및 기타 관련 데이터를 포함하여 시스템 동작에 대한 정보를 캡처하는 작업이 포함되며, 이는 문제를 식별하고 문제를 디버깅하는 데 유용할있다.
메트릭(Metric)은 시간 경과에 따른 시스템의 성능과 동작을 측정할 수 있는 방법을 제공합니다. 여기에는 응답 시간, CPU 및 메모리 사용량과 관련된 메트릭과 시스템 동작에 대한 인사이트를 제공하는 기타 관련 메트릭이 포함될 수 있다.
추적(Trace)은 요청이 시스템을 통과할 때 요청을 추적하여 개발자가 요청이 어떻게 처리되는지 확인하고 시스템의 문제나 병목 현상을 파악할 수 있으며,
디버깅(Debug) 도구는 변수, 스택 추적 및 기타 관련 정보를 포함하여 시스템의 내부 상태를 검사할 수 있는 방법을 제공합니다. 이는 코드의 문제를 식별하고 수정하는 데 유용할 수 있습니다.
결론적으로 소트웨어 엔지니어링에서 통합 가시성은 시스템 동작에 대한 데이터를 수집하고 분석하여 성능에 대한 인사이트를 얻고 해결해야 할 문제를 식별하는 것을 포함하게 되고 아래의 조건들이 관찰 가능성(Observability)의 조건들이 충족되어야 한다.
1.어플리케이션의 내부적인 동작을 이해해야 한다.
Understand the inner workings of your application2.어플리케이션이 처할수 있는 모든 시스템의 상태,심지어 이전에 본 적이없고 예측할수 없었던 새로운 상태까지 이해해야 한다.
Understand any system state your application may have gotten itself into, even new ones you have never seen before and could not have predicted3.외부 툴을 이용한 관측만으로 어플리케이션의 내부 동작과 시스템의 상태를 이해해야 한다.
Understand the inner workings and system state solely by observing and interrogating with external tools4.내부 상태를 처리하기 위해서 사용자의 새로운 코드를 배포하지 않고 어플리케이션의 내부 상태를 이해할수 있어야 한다.
Understand the internal state without shipping any new custom code to handle it
3. 모니터링 vs 관찰 가능성 (Observability)의 차이점은?
그렇다면 도대체 기본의 모니터링 과 관찰가능성 (Observability)의 차이점은 무엇인가?
모니터링에는 시스템 동작에 대한 데이터를 수집하고 분석하여 시스템이 예상대로 작동하는지 확인하는 작업이 포함된다 여기에는 CPU 및 메모리 사용량, 네트워크 트래픽, 애플리케이션 응답 시간과 같은 시스템 수준 메트릭 모니터링이 포함될 수 있습니다. 모니터링의 목표는 문제를 식별하고 심각한 문제가 되기 전에 수정 조치를 취하는 것이다.
반면에 관찰 가능성은 내부 상태에서 수집한 데이터를 사용하여 시스템의 동작을 이해하고 디버깅하는 기능이다. 통합 가시성에는 모니터링이 포함되지만 그 이상으로 로깅, 추적, 디버깅과 같은 다른 측면도 포함된다. 개발자는 시스템 동작에 대한 데이터를 수집하고 분석함으로써 통합 가시성을 통해 시스템의 성능에 대한 인사이트를 얻고 해결해야 할 문제를 식별할 수 있다.
4. 정리한다면..
로그, 메트릭, 추적, 이벤트, 메타데이터 등 통합 가시성 및 원격 분석 신호는 함께 작동하여 개별 시스템의 상태를 비즈니스의 전반적인 상태와 상호 연관시킨다. 이는 순전히 수집된 기존 데이터 스트림으로부터 전체 기술 스택의 시스템, 프로세스 및 마이크로서비스 내에서 무슨 일이 일어나고 있는지 강조하고. 궁극적으로, 통합 가시성은 개발자와 운영 팀이 시스템을 더 잘 이해할 수 있게 해주는 개념으로 정리될수 있다.
서비스를 이해하고 관리하기 위해서는 서비스의 동작을 측정하고 관찰하며 정량화해야 한다. 서비스에서 기대되는 것을 결정하기 위해 도메인에 적합한 KPI를 정의하는데. 이러한 KPI를 정의하는 것은 적절한 수준의 서비스가 제공되지 않을 경우 어떤 조치를 취해야 하는지, 즉 서비스 소비자가 성능 저하를 인지하기 전에 어떤 조치를 취해야 하는지 이해하는 데 가장 중요하다
