[스타트업 리뷰] 웹 장애를 자동으로 확인한다, 인포플라 웹 장애 모니터링
[편집자주] 스타트업(start-up)은 특정한 문제를 해결하기 위해서 ‘시작하는’ 기업을 말합니다. 기업의 생사가 걸려있는 만큼 스타트업은 문제에 대한 가장 효율적인 답을 찾으려고 노력합니다. 이들의 고군분투가 낳은 결과가 현재 우리가 향유하는 ‘혁신’이 된 경우가 많습니다.
다만, 대다수의 스타트업이 좋은 기술과 서비스를 보유하고 있음에도 충분히 성장하지 못하고 있습니다. 다양한 원인이 함께 작용한 결과지만, 가장 큰 문제는 좋은 기술이 있어도 이를 사회에 잘 알리지 못한다는 것입니다. 이에 [스타트업리뷰]를 통해 스타트업의 좋은 기술을 접해보고, 이를 어떻게 사용할지 그리고 업계 관계자들의 시선은 어떠한지 시리즈로 전하고자 합니다.
[IT동아 정연호 기자] 스타트업 리뷰 시리즈를 통해서 인포플라(대표 최인묵)의 IT운영관리 자동화 솔루션 ‘아이톰스’ 기능들을 소개하고, 검증하고 있다. 국가와 산업 전반의 디지털전환에 따라 IT시스템을 관리하는 역량이 중요해질 것이란 판단에서다.
최 대표가 아이톰스를 설명하면서 강조한 지점은 “IT관리자가 불편함을 느끼는 지점에서 시작한 솔루션”이라는 것이다. 아이톰스로 자동화할 수 있는 영역에는 IT장비 비밀번호 변경, 장비의 CPU 및 메모리 부하체크, 웹 장애 모니터링 등이 있다.
IT관리자들이 현장에서 느끼는 가장 큰 불편함은 대부분의 작업을 사람이 직접 해야 한다는 점이다. 이들이 공통으로 하는 말은 “아직 이곳은 자동화와 같은 IT기술의 수혜를 보지 못했다”는 것이다. 가령, CPU/메모리 부하를 점검하는 솔루션이 있음에도 IT관리자들은 시간이 날 때마다 웹사이트에 들어가 장애가 발생했는지 확인한다. 부하체크만으로는 발견하지 못하는 장애가 있어서다.
사람이 매번 웹을 실시간 모니터링을 할 수는 없으니 “서비스에 문제가 생겼다”는 고객의 항의를 받고서 장애를 해결하는 사례가 많다고 한다. 특정 홈페이지에서 ‘A’ 메뉴를 눌렀더니 다음 페이지로 넘어가는 데 시간이 10초 정도 걸리거나, ‘오류코드:400’이 뜨면서 페이지 연결이 안 될 때 이용자가 고객센터에 연락해 관련 사실을 전달하는 것처럼 말이다.
하지만, 웹 장애 모니터링을 실시간으로 하는 건 앞으로 더욱 어려워질 전망이다. IT시스템이 확장되면서 관리 작업도 늘어남에 따라 장애 모니터링에 쓸 수 있는 시간도 줄어들 것이기 때문이다. 최 대표는 “IT관리자들이 해야 하는 일이 정말 많다. IT시스템이 고도화될수록 할 일은 더 늘어난다”고 말했다.
인포플라는 웹 장애 모니터링을 자동화하기 위해서 자체 RPA(로봇프로세스자동화) 알파카를 활용했다. 이 작업은 단순하고 반복되는 일이라 RPA 자동화에 무리가 없었다고 한다. 최 대표는 “단순반복 작업은 RPA로 자동화하고, IT관리자는 중요한 일에 더 많은 시간을 쏟을 수 있다”고 했다. 코딩이 필요하지 않은 노코드 기반 RPA라 누구나 RPA 스크립트를 만들 수 있다.
아이톰스의 웹 장애 모니터링 기능을 적용하면 RPA가 지정된 홈페이지의 메뉴를 눌러서 정상 작동하는지 확인한다. 새 페이지로 연결될 때 속도가 너무 느리진 않은지, 접속은 되는지 점검하는 작업을 로봇인 RPA가 하는 것이다.
웹 장애 모니터링을 자동화하려면 RPA 스크립트를 만든 뒤 아이톰스와 연동해야 한다. 이후, 이벤트 등록에서 장애 모니터링과 관련된 설정을 할 수 있다. ‘네이버 계정 로그인’이 정상 작동하는지 확인한다고 해보자. 이때 ‘허용시간’은 정상과 장애를 구분하는 기준을 말한다. RPA가 수행하는 작업이 허용시간을 넘어서도 완료가 안 되면 장애로 분류된다. 로그인을 눌렀을 때 5초 이상 지나면 시스템이 ‘장애’라고 판단하게끔 할 수 있는 것이다.
이벤트 등록 창의 ‘이벤트 단계’는 작업 수행 과정에서 장애가 발생했을 때의 심각도를 뜻한다. 네이버 계정 로그인이 안 된다면 이는 심각한 문제인 ‘Critical’ 혹은 ‘Down’으로 분류돼야 하는 상황이다. 작업의 중요성을 고려해 이벤트 단계를 지정하면 된다.
웹 장애 모니터링 대시보드를 보면 위 사진처럼 작업에 대한 기록이 나온다. 장애가 발생하지 않았다면 이벤트등급에 info라고 표시된다. 문제가 있었다면 미리 지정한 이벤트 단계(Major)로 기록된다.
대시보드의 작업기록을 누르면 상세 내용을 볼 수 있다. 1시간 동일 이벤트에선 이전에 진행됐던 동일한 작업들이 나온다. 추후에 가벼운 장애를 뜻하는 minor가 세 개 연달아 나오면 이를 심각도가 더 높은 major 장애로 인식하게끔 하는 알고리즘을 적용할 계획이라고 한다.
사용자는 웹 장애 체크에 대한 스케줄을 설정할 수 있다. 스케줄표에서 반복여부를 누른 뒤 시작날짜와 종료날짜, 반복 요일, 작동 시간을 택하면 된다.
“노코드 기반 RPA, 스크립트를 쉽게 제작할 수 있다”
최 대표는 “알파카는 코딩이 필요하지 않은 노코드 RPA라서 IT운영 전문가가 아니어도 웹 장애 모니터링 스크립트를 쉽게 만들 수 있다”고 설명했다. 보통 RPA 제품은 코딩을 할 줄 아는 전문가도 제품별로 2~4개월씩은 교육을 받아야 한다고 한다.
스크립트 제작에 코딩이 필요하지 않다는 건 비전문가도 쉽게 만들 수 있다는 뜻일까? 이를 확인해보기 위해서 알파카 프로그램을 설치한 뒤 웹 장애 모니터링 스크립트를 만들어봤다. 스크립트를 만드는 건 코딩을 전혀 할 줄 모르는 사람도 안내서만 따르면 충분히 할 수 있을 정도로 쉬웠다. 왼쪽에 있는 ‘Activities’에서 필요한 활동을 마우스로 끌고 온 뒤 필요한 정보를 입력하고, 활동들을 작업 순서에 맞게 연결하면 된다.
기자가 RPA로 장애 모니터링을 한 곳은 IT동아 홈페이지의 ‘뉴스’ 메뉴였다. 스크립트를 짜는 과정은 다음과 같다. 우선, Activities에서 크롬을 여는 openBrowser를 마우스로 끌고 와야 한다. 특정 홈페이지에 접속하는 GetURL에는 URL 정보를 입력해야 해서 IT동아 URL을 썼다. InputBrowserByimage에선 RPA가 눌러야 하는 위치를 사진으로 캡처한 뒤 등록해야 한다. IT동아 홈페이지에는 뉴스, 리뷰, 강의, 동영상 네 가지 메뉴가 있는데 그 중 ‘뉴스’를 캡처했다.
그 이후의 작업도 어렵지 않았다. RPA가 작동할 홈페이지에서 F12를 누르면 뜨는 XML문서에서 XPath값을 복사해서 붙이기만 하면 된다. XPath값은 XML문서가 뜬 뒤 RPA가 눌러야 하는 지점(뉴스)에 마우스를 대면 나온다.
XPath값을 입력해야 한다는 지침을 봤을 땐 스크립트를 완성할 수 있을지 의문이 들긴 했다. 코딩 문외한이라 익숙하지 않은 용어에 헤매긴 했지만, 설명서를 따르니 스크립트 제작에 큰 어려움은 없었다.
인포플라의 RPA 툴은 마치 레고블록을 쌓는 것과 같다. 필요한 블록을 조합한 뒤 정보만 입력하면 스크립트가 완성된다. 이 과정에 코딩 과정이 전혀 필요하지 않았다. 스크립트는 아이톰스와 연동만 하면 된다. 웹 장애 모니터링이 아닌 다른 작업을 자동화할 때도 스크립트를 제작하는 데 어려움은 없을 것이다.
스크립트를 다 만들고 실행을 누르니 위 사진처럼 크롬 브라우저가 실행됐고, 마우스가 자동으로 뉴스 탭으로 이동한 뒤 이를 눌렀다. 사람이 마우스로 크롬을 켜고 메뉴를 누르는 것처럼 빠르게 작동하진 않았다. 그럼에도 각 동작은 2~3초 내로 완료됐다.
인포플라의 웹 장애 모니터링 자동화 기능은 CPU나 메모리 등의 부하체크로는 감지하지 못하는 장애도 RPA로 확인하는 기능이다. 최 대표는 “24시간 내내 IT관리자가 서비스 모니터링에 매달려 있을 수는 없다”고 말한다. 사람에겐 한계가 있지만 RPA는 24시간 작동하며 장애를 탐지할 수 있다는 설명이다.
다만, 간단한 사용법이 우수한 성능 그 자체를 뜻하진 않는다. 이를 확인하려면, 현장에서 일하는 전문가의 시선에서 RPA 작업 속도가 어떤지, 장애를 탐지하는 역량을 제대로 갖췄는지 등을 따져봐야 한다. 다음 기사에선 IT운영관리 업계 관계자 세 명의 시선으로 웹 장애 모니터링의 이용자 경험, 유용성, 정확도 등을 하나씩 뜯어볼 예정이다.
글 / IT동아 정연호 (hoho@itdonga.com)