Observability
오직 시스템의 외부 출력만을 이용해서 시스템의 현재 상태를 이해할 수 있는 능력
SW 애플리케이션이 observability를 가지기 위한 조건
- 애플리케이션의 내부 동작을 이해함
Understand the inner workings of your application - 애플리케이션이 처할 수 있는 모든 시스템 상태를 이해함
Understand any system state your application may have gotten itself into - 외부 툴을 이용한 관측만으로 애플리케이션의 내부 동작과 시스템 상태를 이해함
Understand the things above, solely by observing that with external tools - 시스템 상태가 어느 정도로 극단적이든 비정상적이든지 상관없이 이해함
Understand that state, no matter how extreme or unusual
소프트웨어 시스템에 대한 observability를 풀어서 얘기하자면,
시스템에서 이전에 없었던(한 번도 겪어보지 못한) 현상이 생기더라도 이를 이해하고 설명할 수 있는 척도이다.
그리고 이건 단순히 데이터 타입 혹은 입력을 의미하는 게 아니라 우리가 관리하는 복잡한 시스템과 어떻게 상호 작용하고 이해하려고 하는가에 관한 것이다.
그럼 Monitoring과 Observability는 어떻게 다른가?
Monitoring
- 어떠한 것이 문제라는 기준이 이미 정립이 되어있음
- 모니터링 시스템은 메트릭스를 수집하고, 합계를 구하고 분석함
- 이 과정을 통해 사전에 정의 내린 문제에 대한 패턴 감지
- 이를 실시간으로 대시보드를 통해서 볼수도, 경고 알림을 받을 수도 있음
때로는 경험해온 패턴과 지식에 근거해서 debugging을 할 때도 있음.
이슈가 감지되면, 이전에 알려진 문제와 비슷한 패턴이나 유사성이 있는지 비교
한계:
대시보드는 애초에 메트릭스의 조합과 주목할 만한 트렌드 흐름을 개략적으로 보여주기 위해 고안되었습니다.
하지만, 새로운 문제를 디버깅할 때는 대시보드로는 한계가 있을 수도 있습니다.
(쪼개지고 고도화된) 복잡한 현대 시스템에선 매트릭스와 모니터링만으로는 대응하는데 한계가 있다.
Observability
- 숨겨진 이슈를 찾아내는 게 중요
- 그러려면 로그, 메트릭스, 이벤트, 트레이스 등 흩어진 서로 다른 정보들을 한곳에 모아야 함
- 그리고 그 정보들의 맥락과 연관성을 파악할 수 있어야 함
이렇게 시스템을 한눈에 파악할 수 있는 능력을 갖췄을 때 가시성(visibility)이 확보되었다고 말합니다.
정리
새로운 마이크로 서비스의 복잡성을 관리하려면 가시성(visibility)이 필요합니다.
Why:
잠재된 위험 요소가 어디에 있든지 간에 신속하게 감지하고 실시간으로 대응해야 합니다.
How:
기존의 도구로는 폭발하는 유입량과 속도를 따라잡을 수가 없습니다. 마이크로 서비스 아키텍처에서도 가시성(visibility)을 확보한 게 Observability입니다.
