칼럼ㅣ화성에서 온 클라우드 네이티브, 금성에서 온 구형 모니터링 툴

기술 인프라 세계가 클라우드 네이티브를 두 팔 벌려 환영하고 있긴 하지만 구형 모니터링 도구를 이 새로운 IT 요소에 쉽게 끼워 맞출 수는 없을 것이다. 

클라우드 네이티브는 모니터링, 마이그레이션, 관리에 새로운 접근 방식이 필요하다. 그렇다면 어디서부터 시작해야 할까? 

오늘날 IT는 확장 가능한 클라우드 서비스를 기반으로 하는 복잡한 인프라를 구축, 배포, 관리해야 한다. 그리고 기업들은 광범위한 클라우드 인프라 요소(예: 가상머신(VM), 컨테이너, 자동 확장 인스턴스, 고성능 스토리지, 콘텐츠 딜리버리 네트워크(CDN), 엣지 컴퓨팅, 다양한 데이터베이스 및 머신러닝 서비스 등)를 활용하여 고객 경험을 향상할 수 있다. 

디지털 IT 운영 관리 플랫폼 회사 ‘옵스램프(OpsRamp)’의 제품 관리 부문 부사장 시아란 번은 이게 말은 쉽지만 실제 운영 환경에서 이렇게 섞여 있는 다양한 요소를 실행한다는 건 간단한 일이 아니라고 말했다. 
 

1990년대 복고풍 기술
번에 따르면 그의 팀은 1990년대 중반으로 거슬러 올라가는 모니터링 도구를 사용 중인 고객을 만날 때가 종종 있다. 클라우드 운영 관리자라면 1993년 출시됐던 마이크로 포커스 오퍼레이션 브릿지(Micro Focus Operations Bridge; 일명 HP 오픈뷰 오퍼레이션(HP OpenView Operations))와 같은 제품을 알 것이다.

이러한 인프라에 굉장히 동적인 워크로드를 지원하는 새로운 최신 클라우드 네이티브 구현을 구축하는 건 고사하고 25년 묵은 기술이라면 조직에서 이를 신뢰하기 어려워하는 것도 이해가 간다. 

물론 최신 애플리케이션과 서비스를 실행하는 데 여전히 사용되고 있는 오래된 소프트웨어가 많지만(자바와 리눅스는 확실히 오랫동안 사용돼 왔다) 애초에 구형 IT 운영 도구는 최신 클라우드 인프라의 분산된 속성에 맞게 설계되지 않았다. 

번은 “구형 도구는 (조직의) 혁신에 족쇄를 채우고, 기술 부채를 악화시키며, 귀중한 회사 리소스를 (구형 도구의) 일상적인 유지보수에만 쓰이도록 한다”라면서, “대표적인 ‘4대’ 모니터링 도구의 대부분은 수십 년 전에 도입됐으며 오늘날 클라우드 운영에서 요구하는 바를 전혀 충족시키지 못하고 있다”라고 지적했다. 

끓어오르는 불만의 배경은?
어째서 번은 BMC 소프트웨어(BMC Software), CA/브로드컴(CA/Broadcom), 마이크로 포커스(Micro Focus), IBM 등의 업체에 그렇게 불만이 많은 걸까? 그는 이들 업체가 합병으로 주주 가치를 올리는 데 많은 시간을 할애했다고 언급했다. 즉 R&D보다 판매 및 관리에 너무 큰 비용 지출이 있었다는 것이다. 

다소 개인적인 이유 외에 번이 지적하는 부분은 클라우드의 글로벌 설치 기반에 이미 배포된 많은 구형 모니터링 도구가 온프레미스 설치를 목적으로 설계된 것이 많다는 점이다.

다시 말해, (구형 모니터링 도구가) SaaS의 세계를 수용하지 못하고 있는 것이다. 또 유연한 SaaS에 반해 기존의 오래된 솔루션은 오늘날의 사용량 기반의 가격 책정 모델을 제공할 가능성이 훨씬 낮다. 

번은 “지난 10년간 가장 큰 발전을 하나 꼽자면 프로메테우스(Prometheus), 센수(Sensu), 엘라스틱(Elastic), 오픈텔레메트리(OpenTelemetry), 그라파나(Grafana) 등 클라우드 및 클라우드 네이티브 환경을 모니터링하기 위한 오픈소스 프로젝트의 확산이었다. 클라우드 네이티브 컴퓨팅 재단(CNCF)이 프로젝트 육성, 다양한 조직의 기여 정리, 업계 표준을 통한 채택 촉진 등에 중요한 역할을 했다”라고 설명했다. 

그에 의하면 구형 IT 운영 관리(ITOM) 업체가 오픈소스 플랫폼을 받아들이고 여기에 투자 및 참여하는 데 상대적으로 느렸다(매우 순화하여 표현했다). 그리고 위에서 언급된 오픈소스 프로젝트는 이제 시대가 변화하고 있음을 시사한다. 

RPA 봇의 부상
클라우드 네이티브 모니터링에서 분야에서 신구 부조화가 생기는 또 다른 근본적인 이유는 알고리즘 인텔리전스와 RPA 소프트웨어 봇의 등장 때문이다. 

번은 지난 몇 년 동안 단일 목적의 도구를 사용하던 것에서 (최신 IT 환경의 규모, 다양성, 속도를 처리하기 위해) 점점 더 RPA를 지원하는 디지털 운영 관리 플랫폼을 채택하는 것으로 뚜렷한 변화가 보였다고 밝혔다. 이어서 그는 사건의 근본 원인을 정확히 파악하려면 수동 규칙을 필요로 하는 구형 이벤트 관리 도구는 상황이 계속해서 변화하는 하이브리드 인프라 환경에서는 적합하지 않다고 덧붙였다. 

그는 “최신 인프라에서 생성되는 이벤트, 알림, 경고뿐만 아니라 다양한 데이터 소스(지표, 로그, 추적)를 감안할 때 효과적인 클라우드 운영을 위해서 실시간 인사이트를 통합하고 추출하고자 머신러닝 및 데이터 과학 기술이 널리 채택됐다. 하지만 IT의 반복적인 수작업을 줄일 뿐만 아니라 사건 문제해결을 위해 규모에 맞게 자동 대응을 이끌어낼 수 있는 RPA도 등장했다”라고 말했다. 

클라우드 네이티브 모니터링으로 가는 5단계
관리자, 아키텍트, 개발자를 위한 엔드투엔드 클라우드 네이티브 데브옵스 솔루션 전문업체 ‘코파도(Copado)’의 CMO 앤드류 리는 클라우드 네이티브 모니터링으로 마이그레이션하려면 5단계가 필요하다고 전했다. 

리는 “첫 번째 단계는 프로젝트 구상이다. 이를 통해 클라우드 마이그레이션으로 해결할 수 있는 문제점, 즉 구형 기술의 단점을 파악해야 한다. 이어서 팀을 꾸리고, 자금을 투입하며, 요건 확정에 따라 계획하고 시작하는 게 두 번째 단계다”라고 설명했다. 

그에 따르면 세 번째는 개발 및 테스트 단계다. 팀이 마이그레이션을 실제로 구현하기 시작하는 단계라고 할 수 있다. 여기서 중요한 것은 자동화된 모니터링 그리고 변경사항에 관한 문서 작성이다. 1~3단계는 모두 사전 프로덕션 단계(실제로 배포하기 전 단계)이며, 4~5단계가 포스트 프로덕션 단계에 해당된다고 그는 덧붙였다. 

“네 번째 단계는 프로덕션에서 사용자를 지원하는 것이다. 사용자의 요구가 지속적으로 충족되고 있는지 확인하기 위해 피드백을 수집해야 한다. 모든 클라우드 마이그레이션 및 그 이후의 모니터링 계층은 폐기될 때까지 프로덕션 단계에 머무른다. 마지막 단계는 새로운 서비스로 마이그레이션하는 것을 포함해 클라우드 서비스의 생애주기 마지막 활동이 진행된다”라고 리는 전했다. 

목표 지점에 도달하겠지만 속도는 느릴 것
결론은 (빠르고 성능이 뛰어난 새로운 유형의 클라우드 도구가 있지만) 여러 중간 규모 및 대규모 조직에 걸쳐 오래된 모놀리식 모니터링 제품이 여전히 많이 남아 있다는 것이다. 

이 불편한 진실에 라이선스 계약이 복잡한(그리고 애플리케이션 및 서비스 종속성이 얽히고설켜 있는) 구형 ITOM 제품군을 더하면 당면한 문제에서 벗어날 수 있는 빠른 해결책은 거의 없다는 걸 알 수 있다. 

클라우드 네이티브 환경이 눈에 보이긴 하지만 기본적으로 이는 클라우드(구름)이기 때문에 안개와 스모그가 있을 수 있다. 마스크를 착용하고 신중하게 걸음을 내디뎌야 한다. 

* Adrian Bridgwater는 10년 이상의 경력을 가진 기술 전문 저널리스트다. ciokr@idg.co.kr