[웨비나] '킨드릴 x 엘라스틱'으로 모니터링 넘어 옵저버빌리티 구현하기

디지털 트랜스포메이션이 가속화되면서 기업의 IT 환경은 나날이 복잡해져가고 있다. 각종 클라우드 활용도는 높아지고, 물리 서버, 가상 서버, 컨테이너 등 애플리케이션 운용 환경도 다양해졌다. 데이터베이스도 한두 종류만 사용하는 것이 아니라 RDB부터 NoSQL까지 다양하게 활용되는 중이다. IT 시스템의 진화는 비즈니스 혁신을 위해 필수적인 요소이지만, IT의 복잡도 향상이라는 반대급부도 가져왔다. 이 때문에 IT운영관리는 점점 더 어려운 일이 되어 가고 있다.

이 때문에 최근에는 ‘옵저버빌리티’가 화두로 떠올랐다. 옵저버빌리티는 단순 모니터링에서 진화된 관점이다. 모니터링은 애플리케이션 운용 상황의 이상징후를 탐지해서 관리자에게 알람을 주는 것이 1차 목표인 반면, 옵저버빌리티는 IT 인프라 전체에 대한 가시성을 기반으로 문제의 원인과 해결 등의 실행을 자동화 최적화 하는 것을 의미한다.

지난 달 15일 바이라인플러스에서 진행된 “‘모니터링’을 넘어 ‘옵저버빌리티’로의 진화” 웨비나에서는 ‘킨드릴 AIOps x 엘라스틱 플랫폼을 통하 IT 운영방안’이라는 주제의 발표가 진행됐다. 이 자리에는 엘라스틱의 ‘풀스택 로깅 기반 통합 관측 기능’을 기반으로 킨드릴 AIOps 솔루션을 운영하는 방안이 소개됐다.

엘라스틱 코리아 김병준 이사는 “엘라스틱은 데이터 수집을 위한 레이어, NoSQL 데이터베이스, 시각화 툴 등 모든 레이어를 보유하고 있다”면서 “수집, 저장, 시각화를 하나의 스택에서 저장, 관리하고 분석해서 시각화하는 것을 하나의 스택으로 제공하고 있다”고 말했다.

김 이사에 따르면, 엘라스틱 에이전트 기반으로 로그를 수집하면 간단하게 시각화할 수 있다. 기본적으로 제공되는 UI를 통해 한 눈에 볼 수도 있고, 기업별, 팀별로 특화된 화면이 필요할 경우 별도의 시각화 화면을 구현하는 것도 용이하다.

에이전트 관리도 중앙에서 통합적으로 할 수 있다고 김 이사는 설명했다. 예를 들어 10만 개의 에이전트가 배포되어 있다고 가정한다면, 이를 일일이 관리하는 것은 불가능에 가깝다. 작동되지 않는 에이전트가 있는지, 버전은 어떻게 다른지 관리하기 어렵다. 김 이사는 “저희는 플릿(Fleet)이라는 기능으로 수집기의 중앙화 및 관리 기능을 제공을 하고 있다”고 설명했다.

김 이사는 이어 “중앙화 된 옵저버빌리티 플랫폼의 이점은 개발시간 등 생산성을 향상하고, 운영환경 표준화를 제공하며, 통합을 통해 비용을 절감할 수 있다”면서 “기술 지원도 한번에 제공받기 때문에 빠른 시간 내에 문제나 이슈를 해결할 수 있다”고 말했다.

김 이사에 이어 킨드릴코리아 박소연 이사가 AI기반의 옵버저빌티 환경을 구현하는 ‘AIOPS’에 대해 소개했다.

박 이사는 사람이 매뉴얼로 관리하는 모니터링의 한계를 지적했다. 예를 들어 현재의 모니터링 환경에서는 수십, 수백 개의 시스템 구성요소에 대해 각각 임계치를 정해놓는다. 그러나 사람은 각 시스템 요소마다 최적화 된 임계치를 설정하는 것이 불가능하다. 그래서 일괄적으로 설정하게 된다. 예를 들어 CPU 사용량이 90%를 넘어서면 알람을 보내도록 하는 식이다. 시스템마다의 특성을 고려해서 관리하지 못하는 것이다. 어떤 시스템 요소는 90% 이하에서도 문제를 일으킬 수 있고, 어떤 시스템 요소는 90%가 넘어도 되는데 일괄적 기준으로 알림을 받게 된다.

박 이사는 이런 문제 해결을 위해 AIOPS가 필요하다고 지적했다. 박 이사는 “AIOPS 기계학습을 활용하기 때문에 각 시스템 구성 요소마다 적절한 임계치를 학습할 수 있다”면서 “학습된 임계치를 적용하면 실제 알람이 발생하였을 때 운영자는 이것이 실제 문제 상황일 가능성이 높다는 것을 신뢰할 수 있게 된다”고 설명했다.

또 AIOPS 는 시간별로 임계치를 다르게 설정하기도 한다. 새벽 2시마다 백업을 위해 CPU 사용률이 올라가는 서버가 있다면 평소에는 CPU 사용량 90%에 알람을 보내도, 백업할 때는 알람을 보내지 않을 수 있다.

이렇게 되면 알람의 신뢰도가 높아진다. 이전에는 알람의 신뢰도가 낮기 때문에 알람이 울리면, 실제로 문제가 있는지 없는지를 운영자가 직접 확인하면서 원인 분석을 진행해야 했다. 그러나 신뢰가 높으면 알람이 발생한 구성 요소를 우선적으로 참조해 점검대상의 범위를 빠르게 좁힐 수 있다.