Observability

Observability 즉 관찰 가능성이란, 시스템의 외부로 출력된 정보를 기반으로 복잡한 시스템의 내부 상태 또는 조건을 파악할 수 있는 능력으로

Metric, Log, Trace 수집, 분석 및 상관관계를 파악하는 능력을 뜻합니다.

Observability의 기본 요소

탐지(Detect), 분석(Investigate), 조치(Remediate)

Observability와 Monitoring의 차이점

Observability

- 무엇이 왜 문제를 일으켰고, 현재 시스템의 상태가 최종 사용자에게 어떤 영향을 주고 있는지 파악하는 것

- 환경의 모든 애플리케이션, 마이크로서비스, 서버 및 데이터베이스에서 수집되고 집계된 로그, 추적 및 메트릭을 사용
- 전체 인프라의 전반적인 상태 및 성능에 대한 세부적인 인사이트를 제공

Monitoring

- 알람을 기반으로 어디에 문제가 발생했는지 파악하는 것이 목적

- 미리 정의된 메트릭 및 로그 세트를 사용하여 오류 및 사용 패턴을 추적

- 추적 및 로싱 활동돠 함께 시스템을 Observable 하게 만드는 활동

 

Observability가 중요해지고 필요한 이유는 무엇일까요?

먼저 Observability의 중요성을 논하기 전에, Issue Timeline에 대해 조금 알아봅시다.

Issue Timeline

Issue Timeline이란, 어떤 사건에 대한 시각적 표현으로 본 상황에서는

장애 발생 시 탐지 - 식별 - 수정 - 검증의 절차로 이슈가 발생한 후 부터 종료될 때 까지의 타임라인을 의미합니다.

 

위 사진에서 MTTD MTTI MTTR 을 볼 수 있는데 각 의미는 다음과 같습니다.

MTTR	– Mean Time To Repair (평균 복구 시간) – 장애 인지 시점 부터 복구 완료까지의 시간
MTTI	– Mean Time To Identify (평균 식별 시간) – 장애 발생 시점 부터 장애 식별까지의 시간
MTTD	– Mean Time To Detect (평균 장애 인지 시간) – 장애 발생 시점 부터 장애 인지까지의 시간

DevOps 문화와 발전으로 더욱 자주 릴리즈 하고 자동화 됨에 따라 성능 및 가용성 문제가 증가하고, 안정적인 서비스 품질은 곧 수익으로 직결되기 때문에 MTTR과 MTTI를 줄이는 것이 중요합니다.

Observability가 중요해지는 이유

Observability가 중요해지는 이유로 가시성, 신속한 문제 해결, 핵심가치 전달 및 수익등 다양한 부분에 영향을 주기 때문인데요.

크게 두가지 이점이 있습니다.

기술적 이점

- 디버깅 및 문제해결 능력 향상

- 데이터로 입증한 설계 가능

- 결함 발생 빈도 감소 및 이슈 사전 탐지

- 시스템 개발의 가속화

문화적 이점

- 유관부서간 업무 투명성 확보

- MSA의 이해도 향상

- 데이터 기반의 의사결정 문화

- 효과적인 실험 가능

- 문제 발생 시 담당자 비난 보다 데이터 기반의 문제 해결에 집중

 

결과적으로 DevOps 팀은 복잡한 MSA 환경에서 이슈 발생 시 어디서부터 잘못된 건지, 무엇을 개선해야 할지 빠른 원인 파악과 분석, 조치를 통해 복구 시간을 단축할 수 있도록 가시성을 확보하기 위해 Observability의 중요성이 대두되고 있다고 볼 수 있습니다.

 

 

출처 : Observability with AWS