관찰 가능성은 시스템이 생성하는 데이터를 기반으로 시스템의 현재 상태를 측정하고 추론하는 기능입니다. 이러한 데이터는 일반적으로 로그, 메트릭 및 추적의 형태로 제공됩니다. 간단한 예로, 메트릭을 검사하여 마이크로서비스 애플리케이션의 상태를 관찰할 수 있습니다.
관찰 가능성은 개발자에게 복잡한 시스템이 어떻게 작동하는지에 대한 전체적인 관점을 제공합니다. 개발자는 데이터 수집, 저장 및 분석을 통해 시스템의 문제를 파악하고 해당 문제를 해결할 수 있는 능력을 얻습니다.
관찰 가능성은 실시간으로 데이터를 수집하는 것에서 시작됩니다. 수집된 데이터는 분석을 위해 중앙 위치에 저장됩니다. 이러한 분석은 머신 러닝 알고리즘, 시각화 또는 통계 기법의 조합을 통해 수행될 수 있습니다.
이 분석 결과는 개발자에게 애플리케이션 또는 시스템 내의 모든 이상 징후를 알려줍니다. 알림은 비즈니스 또는 애플리케이션 요구 사항에 따라 설정된 임계값, 심각도 수준 또는 기타 기준에 따라 자동으로 트리거될 수 있습니다. 이상 징후가 확인되고 위치가 파악되면 개발자는 데이터를 사용하여 문제를 디버깅하고 해결할 수 있습니다.
위에서 언급했듯이 관찰 가능성 데이터의 주요 유형은 로그, 메트릭, 추적입니다.
모니터링은 시스템 또는 애플리케이션 내에서 발생하는 프로세스의 진행 상황을 관찰하고 확인하는 기능입니다. 모니터링은 메트릭에 크게 의존합니다. 즉, 환경을 시각화하고 알려진 문제에 대해 테스트할 수 있습니다. 반면에 관찰 가능성은 문제가 있을 수 있는지 추론할 수 있는 심층적인 새로운 데이터를 제공합니다. 그러면 문제의 원인을 자세히 살펴보고 미래에 대한 통찰력을 확보할 수 있습니다.
모니터링과 관찰 가능성은 뚜렷하게 구분되는 것이 아니며, 개발자가 인사이트에 빠르게 도달할 수 있게 해주는 데이터 분석 옵션 및 시각화 기법입니다.
이러한 정의를 바탕으로 아래 표에서는 소프트웨어 애플리케이션에서 모니터링 및 관찰 가능성 간의 4가지 미묘한 차이점을 자세히 살펴봅니다. 이러한 4가지 차이점은 범위, 세분성, 유연성 및 분석으로 나뉩니다.
| 모니터링 | 관찰 가능성 | |
|---|---|---|
| 범위 | 메트릭 측정(예: 시스템 가동 시간, CPU 사용량, 오류율) | 출력을 기반으로 시스템의 작동 메커니즘 이해 |
세분성 |
일정한 주기로 수집된 데이터 집계 또는 샘플링(사전 정의된 메트릭에 기반) |
세분화된 데이터를 수집 및 분석하여 시스템 동작에 대한 심층적인 인사이트와 이해 확보 |
유연성 |
배포 후 수정하기 어려운 사전 정의된 대시보드 또는 알림 임계값 구현 |
변화하는 상황과 요구 사항을 수용하는 변경하기 쉬운 도구로 유연하고 적응력 있는 접근 방식 사용 |
분석 |
특정 이벤트 또는 이상 징후 식별 및 대응 |
개발자에게 문제의 원인을 파악하고 시간 경과에 따라 솔루션을 구현하는 데 필요한 도구를 제공하여 사전 예방적 분석 및 문제 해결 강조 |
소프트웨어 관찰 가능성에서 텔레메트리는 소프트웨어 시스템의 성능과 동작에 대한 데이터를 실시간으로 수집하고 전송하는 작업을 말합니다. 이 데이터(응답 시간, 오류율, 리소스 소비 등)는 시스템의 현재 상태를 모니터링하고 이해하는 데 사용되며 개발자가 성능을 개선할 기회를 파악하는 데 도움이 됩니다.
텔레메트리에 관한 대화에서는 개발자가 더 쉽게 관찰 가능성을 확보할 수 있도록 간소화된 접근 방식을 제공하는 OpenTelemetry(OTel)가 종종 화두가 됩니다. OTel은 소프트웨어 시스템에서 텔레메트리 데이터(로그, 메트릭 및 추적)의 수집을 표준화하는 일련의 오픈 소스 도구 및 라이브러리입니다.
OpenTelemetry가 앱 추적 및 설계 방식을 바꾸는 방법에서 OTel과 클라우드 네이티브 환경에 영향을 주는 방식에 대해 자세히 알아보십시오.
관찰 가능성은 다음을 통해 개발자가 애플리케이션을 더 잘 이해할 수 있도록 도와줍니다.
관찰 가능성에는 몇 가지 단점이 있으며, 가장 일반적인 단점은 다음과 같습니다.
NGINX는 관찰 가능성과 OTel에 대한 추가 무료 교육 리소스를 제공합니다.