본문
IT 소식
Observability 톺아보기
관련링크
안녕하세요,
와탭랩스 테크니컬 라이터 Sunny입니다.
다들 ‘톺아보다’라는 단어를 들어보셨나요? ‘톺아보다’는 샅샅이 더듬어 뒤지면서 찾아보다라는 뜻의 순우리말인데요.
이 글에서는 Observability를 톺아보겠습니다. Observability가 무엇이며, Monitoring과 어떻게 다르고 왜 필요한지 알려드리겠습니다.
Observability란 무엇인가요?
소프트웨어 시스템에서의 Observability에 대해 설명하기 전에 우선 단어의 유래를 알아봅시다. Observability란 개념을 처음 도입한 건 엔지니어 Rudolf E. Kálmán 입니다. Rudolf는 Observability를 아래와 같이 정의했습니다.
오직 시스템의 외부 출력만을 이용해서 시스템의 현재 상태를 이해할 수 있는 능력
the ability to understand the current state of a system using only its external outputs.
Rudolf가 observability란 개념을 이용했던 건 엔지니어링에서의 control theory를 설명하기 위해서였습니다. 소프트웨어 시스템에서의 observability는 어떤 의미일까요?
소프트웨어 애플리케이션이 observability를 가지기 위해서는 다음 조건들이 충족되어야 합니다.
- 애플리케이션의 내부 동작을 이해함
쉽게 말하자면 소프트웨어 시스템에 대한 observability는 다음과 같습니다.
시스템에서 이전에 없었던 (한 번도 겪어보지 못한) 현상이 생기더라도 이를 이해하고 설명할 수 있는 척도
a measure of how well you can understand and explain any state your system can get into, no matter how novel or bizarre.
현대 소프트웨어 시스템에서 observability는 단순히 데이터 타입 혹은 입력을 의미하는 게 아닙니다. 우리가 관리하는 복잡한 시스템과 어떻게 상호 작용하고 이해하려고 하는가에 관한 것입니다.
Monitoring과 Observability는 어떻게 다른가요?
Monitoring에서는 어떠한 것이 문제라는 기준이 이미 정립돼있습니다. 모니터링 시스템은 메트릭스를 수집하고, 합계를 구하고 분석합니다. 이 과정을 통해 사전에 정의 내린 문제에 대한 패턴을 감지해냅니다. 이를 실시간으로 대시보드를 통해서 볼 수도 있고, 필요하면 경고 알림을 받기도 합니다.
때로는 경험이 많은 엔지니어의 직감에 의존하는 경우도 있습니다. 경험해온 패턴과 지식에 근거해서 debugging을 합니다. 이슈가 감지되면, 이전에 알려진 문제와 비슷한 패턴이나 유사성이 있는지 비교해 봅니다.
모니터링에서 흔히 사용하는 정적인 대시보드(Static dashboards)는 보통 각 서비스별로 데이터를 모아서 보여줍니다. 이러한 방식은 엔지니어가 시스템의 일부 측면을 이해할 때는 유용합니다. 즉, 대시보드는 애초에 메트릭스의 조합과 주목할 만한 트렌드 흐름을 개략적으로 보여주기 위해 고안되었습니다. 하지만, 새로운 문제를 디버깅할 때는 대시보드로는 한계가 있을 수도 있습니다.
하지만 만약 시스템에서 어떤 종류의 문제가 발생할지조차 모른다면 어떡할까요? 영어로 이런 상황을 Unknown Unknowns이라고 칭합니다. 현대의 분산된 시스템 아키텍처에서는 문제 상황을 해결하는 난이도가 훨씬 높습니다. 하나의 새로운 request는 다수의 서비스를 거치고, 여러 네트워크를 통해 이동하기도 합니다. 누구도 어떤 문제가 일어날지 예측할 수 없습니다. 한 번도 경험해 보지 못한 상황을 마주하기도 합니다.
Observability에서는 숨겨진 이슈를 찾아내는 게 중요합니다. 그러려면 로그, 메트릭스, 이벤트, 트레이스 등 흩어진 서로 다른 정보들을 한곳에 모아야 합니다. 그 정보들의 맥락과 연관성을 파악할 수 있어야 합니다. 이렇게 시스템을 한눈에 파악할 수 있는 능력을 갖췄을 때 가시성(visibility)이 확보되었다고 말합니다.
Observability가 왜 필요한가요?
메트릭스와 모니터링만으로 충분하지 않나요? 네, 결론부터 말씀드리면 충분하지 않습니다. 복잡성이 증가한 현대 시스템에선 기존 모니터링으로는 대응하는 데 한계가 있습니다. 현대의 시스템은 이전보다 훨씬 고도화되고, 잘게 쪼개져 있습니다. 소프트웨어 개발자들은 기존 모니터링만으로는 현대의 복잡한 시스템을 온전히 이해할 수 없습니다.
메인 프레임 vs. 마이크로 서비스Observability가 필요한 이유를 이해하려면 IT 시스템이 어떻게 변화해왔는지 대략적인 흐름을 알아야 합니다. 10년 전만 해도 사용자 수가 지금처럼 많지는 않았습니다. 시스템과 플랫폼이 수천 만의 사용자만 지원할 수 있어도 충분했죠. 지금은 사용자 수가 기하급수적으로 늘었습니다. 수백 만에서 수십억 명에 이릅니다. 예를 들어 아마존 쇼핑몰을 생각해 봅시다. 아마존 웹사이트는 미국 내 소비자 뿐만 아니라 직구를 원하는 전 세계 사람들이 접속합니다. 할인이 있는 시즌이면 트래픽이 폭발적으로 증가할 수도 있습니다. 넷플릭스 역시 비슷한 사례입니다. 인기 있는 시즌의 드라마가 방영되면 기존의 시스템으로는 그 규모를 감당할 수가 없었습니다.
결론적으로 감당해야 하는 트랜잭션, 사용자 수가 과거와는 비교가 안될 정도로 증가한 것입니다. 이렇게 변화하는 규모를 감당하려면 새로운 시스템을 도입해야만 했습니다. 이때 등장한 게 바로 클라우드입니다. 클라우드에서는 필요한 컴퓨팅 리소스 (서버, 데이터베이스 등)을 필요에 따라 사용할 만큼만 빌려 쓰면 됩니다. 변화하는 수요에 좀 더 유연하게 대응할 수 있습니다.
그런데 클라우드로 옮기는 게 쉽지 않았습니다. 하나의 큰 애플리케이션 (Monolithic Architecture)을 통째로 클라우드에 올리자니 관리하기가 너무 버거웠던 것입니다. 결국 클라우드로 이동하기 위해 그러한 큰 애플리케이션을 작게 쪼개서 만들기 시작했습니다. 그게 바로 MSA (Microservice Architecture)입니다.
레거시 메인 프레임 애플리케이션은 거대하고, 복잡한 단일화된 (monitoring) 시스템으로 수많은 프로그램으로 이루어져 있습니다. 각각의 프로그램은 서로에 대한 의존도가 매우 높습니다. 따라서 하나의 프로그램에서 생긴 버그를 수정하기 위해 전체 프로그램을 모두 테스트해야 합니다.
마이크로 서비스 아키텍처 (Microservice Architecture)는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개놓은 아키텍처를 말합니다. 각 마이크로 서비스는 상호 통신, 변경과 조합이 가능합니다. 이를 통해 전체 서비스를 구성하게 됩니다.
많은 아키텍처들이 메인 프레임에서 마이크로 서비스로 전환했습니다. 서비스는 점점 작아지고 관리해야 할 서비스 수는 훨씬 늘어났습니다. 문제는 여기서부터 시작됩니다. 하나의 단일 트랜잭션이 들어온다고 가정해 봅시다. 이 트랜잭션이 처리되려면 여러 개의 서비스를 거치게 됩니다. 트랜잭션이 처리되기 위한 일련의 과정을 볼 수 있어야 합니다. 그래야만 문제가 생겼을 때 어디서부터 잘못된 건지, 무엇을 개선해야 할지 파악할 수 있기 때문입니다.
결국 새로운 마이크로 서비스의 복잡성을 관리하려면 가시성(visibility)이 필요합니다. 잠재된 위험 요소가 어디에 있든지 간에 신속하게 감지하고 실시간으로 대응해야 합니다. 클라우드, 마이크로 서비스와 같이 IT 시스템은 매우 빠르게 변화하고 있습니다. 기존의 도구로는 폭발하는 유입량과 속도를 따라잡을 수가 없습니다. 마이크로 서비스 아키텍처에서도 가시성(visibility)을 확보한 게 Observability입니다.
서비스 성능관리는 와탭 애플리케이션 모니터링으로!
와탭 무료로 시작하기
- Sunny_Ryu([email protected]
- DevOps TeamTechnical Writer