Observability 개념과 도구 발전과정
(insight.infograb.net)-
Observability 개념:
- 시스템 외부 출력의 결괏값(지식)에서 시스템 내부 상태를 얼마나 잘 추론하는지 나타내는 척도
- 출력값 측정에서 시스템 상태를 추정하도록 설계된 동적 시스템
- 클라우드 환경이 대중화되고, 도커화된 앱과 마이크로서비스 아키텍처가 보편화되면서 Observability 필요
-
Observability와 모니터링 차이점:
- 모니터링: 사용자가 수행하는 무엇. 무엇이 잘못됐는지 보여줌
- Observability: 모니터링을 포함하는 상위 개념. 내부 동작 배경 정보를 풍부하게 제공하고, 심층적인 시스템 문제를 해결. 무엇이 ‘왜’ 잘못됐는지까지 보여줌
-
조직에서 Observability가 필요한 상황:
- 프로덕션에 이슈가 생기면 ‘문제 원인을 파악하는 데이터는 무엇이고, 이는 어디에 있으며, 데이터를 어떻게 봐야 하는가?’라는 의문이 들 때
- 1분 전까지 괜찮던 서비스에 문제가 생겨 ‘근본 원인을 어디서 찾아야 하는가?’란 문제를 맞닥뜨릴 때
- 조직에서 ‘개발팀이 고객이나 지원/운영팀보다 서비스 이상 증상을 먼저 알려면 어떻게 해야 할까?’ 를 고민할 때
- 마이크로서비스의 서비스 오류, 성능 오류를 효과적으로 추적할 방법이나 ‘로그 또는 애플리케이션 성능 모니터링(APM) 형태로 이를 확인할 수 있을지’ 궁금할 때
-
Observability 도구 발전 과정:
- 2010년대 이후로 IT 업계에 다양한 Observability 도구가 나옴
- 2010년 구글이 대규모 분산 시스템 추적 인프라 ‘Dapper’를 선보임
- 이후 우버와 트위터에서 분산 추적 시스템 ‘Jaeger’(우버)와 ‘Zipkin’(트위터)을 각각 만듦
- 분산 시스템 동작을 계속 모델링하고, 설명하는 표준 API 세트인 ‘Open Tracing’이 나옴
- ‘Open Census’ 공개: 애플리케이션 지표와 분산 추적을 수집한 다음, 백엔드에 데이터를 실시간 전송하는, 다양한 언어용 라이브러리 세트
- 이어서 ‘프로메테우스’가 나옴
- 2019년에는 Open Tracing과 Open Census를 통합한 ‘Open Telemetry(OTel)’라는 도구, API, SDK 모음 공개
-
Open Telemetry:
- 벤더 중립 오픈 소스 Observability 프레임워크
- 소프트웨어 성능과 동작을 분석하도록 돕는 원격 측정 데이터로 로그, 지표, 추적이 있는데 Open Telemetry는 이를 계측, 생성, 수집하고 내보내는 데 쓰임
- 로그: 타임스탬프 메타데이터. 이슈의 근본 원인을 판단하는 데 쓰임
- 지표: 서비스에서 측정한 키/밸류 태그를 갖는 통계 또는 집계 데이터. 런타임에 포착한 서비스의 측정값
- 추적: 사용자와 애플리케이션에 발생한 이벤트 기록. 개별 리퀘스트가 전파되는 경로 기록
- 사용방식: Observability 도구에서 알림 보냄->알림 내용 확인하고, 대시보드로 가서 문제 지점 확인->이 문제 지점에서 특정 부분을 상세하게 쿼리->로그를 찾아 확인->이 로그와 관련된 추적 데이터를 찾아 패턴화->여기서 문제 확인하고, 고치며 Observability 구현
- 요즘 만든 대부분의 Observability 도구는 Open Telemetry를 기본 지원
-
Open Telemetry가 나온 이유:
- 과거에는 각 Observability 백엔드가 도구로 데이터를 전송하는 자체 계측 라이브러리와 에이전트가 있었고, 코드를 계측하는 방식이 여러 가지였음
- Observability 백엔드로 데이터를 보내는 표준화된 데이터 형식이 없음
- 이후, 하나의 표준을 만들기 위해 Open Tracing과 Open Census가 통합돼 Open Telemetry가 나옴
-
SigNoz: 오픈 소스 APM 도구
- 애플리케이션을 모니터하고, 문제를 해결하도록 도움
- 분산 추적 기술을 사용해 사용자 소프트웨어 스택 파악
- latency, requests per second, error rates 같은 애플리케이션 지표를 모니터링
- CPU 이용이나 메모리 사용 같은 인프라 지표도 관찰
- 서비스 전반에 사용자 리퀘스트 추적
- 지표에 알림 설정
- 문제를 일으키는 정확한 추적에 가서 문제 근본 원인을 찾을 수 있음
- 개별 리퀘스트 추적의 자세한 flame 그래프도 볼 수 있음
모니터링이 잘 동작하는 건 어떻게 모니터링하지?
왓치맨이라는 만화에서 나오는 고민 비슷한 걸 했었는데 옵저버빌리티라는 말이 있었군여 감사합니다
감사합니다! 요즘 AI로 Observability를 간소화하는 도구를 개발하는 곳들도 눈에 띄더라고요. 더 알고 싶은 분야에요! :)