Observability가 왜 필요한가요?
이 글의 원문은 Observability 톺아보기에서 확인하실 수 있습니다.
메트릭스와 모니터링만으로 충분하지 않나요? 네, 결론부터 말씀드리면 충분하지 않습니다. 복잡성이 증가한 현대 시스템에선 기존 모니터링으로는 대응하는 데 한계가 있습니다. 현대의 시스템은 이전보다 훨씬 고도화되고, 잘게 쪼개져 있습니다. 소프트웨어 개발자들은 기존 모니터링만으로는 현대의 복잡한 시스템을 온전히 이해할 수 없습니다.
Observability가 필요한 이유를 이해하려면 IT 시스템이 어떻게 변화해왔는지 대략적인 흐름을 알아야 합니다. 10년 전만 해도 사용자 수가 지금처럼 많지는 않았습니다. 시스템과 플랫폼이 수천 만의 사용자만 지원할 수 있어도 충분했죠. 지금은 사용자 수가 기하급수적으로 늘었습니다. 수백 만에서 수십억 명에 이릅니다. 예를 들어 아마존 쇼핑몰을 생각해 봅시다. 아마존 웹사이트는 미국 내 소비자 뿐만 아니라 직구를 원하는 전 세계 사람들이 접속합니다. 할인이 있는 시즌이면 트래픽이 폭발적으로 증가할 수도 있습니다. 넷플릭스 역시 비슷한 사례입니다. 인기 있는 시즌의 드라마가 방영되면 기존의 시스템으로는 그 규모를 감당할 수가 없었습니다.
결론적으로 감당해야 하는 트랜잭션, 사용자 수가 과거와는 비교가 안될 정도로 증가한 것입니다. 이렇게 변화하는 규모를 감당하려면 새로운 시스템을 도입해야만 했습니다. 이때 등장한 게 바로 클라우드입니다. 클라우드에서는 필요한 컴퓨팅 리소스 (서버, 데이터베이스 등)을 필요에 따라 사용할 만큼만 빌려 쓰면 됩니다. 변화하는 수요에 좀 더 유연하게 대응할 수 있습니다.
그런데 클라우드로 옮기는 게 쉽지 않았습니다. 하나의 큰 애플리케이션 (Monolithic Architecture)을 통째로 클라우드에 올리자니 관리하기가 너무 버거웠던 것입니다. 결국 클라우드로 이동하기 위해 그러한 큰 애플리케이션을 작게 쪼개서 만들기 시작했습니다. 그게 바로 MSA (Microservice Architecture)입니다.
많은 아키텍처들이 메인 프레임에서 마이크로 서비스로 전환했습니다. 서비스는 점점 작아지고 관리해야 할 서비스 수는 훨씬 늘어났습니다. 문제는 여기서부터 시작됩니다. 하나의 단일 트랜잭션이 들어온다고 가정해 봅시다. 이 트랜잭션이 처리되려면 여러 개의 서비스를 거치게 됩니다. 트랜잭션이 처리되기 위한 일련의 과정을 볼 수 있어야 합니다. 그래야만 문제가 생겼을 때 어디서부터 잘못된 건지, 무엇을 개선해야 할지 파악할 수 있기 때문입니다.
결국 새로운 마이크로 서비스의 복잡성을 관리하려면 가시성(visibility)이 필요합니다. 잠재된 위험 요소가 어디에 있든지 간에 신속하게 감지하고 실시간으로 대응해야 합니다. 클라우드, 마이크로 서비스와 같이 IT 시스템은 매우 빠르게 변화하고 있습니다. 기존의 도구로는 폭발하는 유입량과 속도를 따라잡을 수가 없습니다. 마이크로 서비스 아키텍처에서도 가시성(visibility)을 확보한 게 Observability입니다.
- 레거시 메인 프레임 애플리케이션은 거대하고, 복잡한 단일화된 (monolithic) 시스템으로 수많은 프로그램으로 이루어져 있습니다. 각각의 프로그램은 서로에 대한 의존도가 매우 높습니다. 따라서 하나의 프로그램에서 생긴 버그를 수정하기 위해 전체 프로그램을 모두 테스트해야 합니다.
- 마이크로 서비스 아키텍처 (Microservice Architecture)는 하나의 큰 애플리케이션을 여러 개의 작은 서비스 유닛으로 쪼개놓은 아키텍처를 말합니다. 각 마이크로 서비스는 상호 통신, 변경과 조합이 가능합니다. 이를 통해 전체 서비스를 구성하게 됩니다.
출처
