소프트웨어 전문지 마이크로소프트웨어 395호는 데이터과학을 주제로 담았습니다. 데이터과학에 대한 개론, 학습 방법, 실무 적용 사례, 학계 등 마소 395호 주요 기사들을 IT조선 독자에게도 소개합니다. [편집자주]
수년 전, 나는 화력 발전소 주기기(보일러, 터빈, 발전기)의 시계열 데이터를 수집해 이상징후를 감지하는 프로젝트를 리딩하고 있었다. 보안상 외부로 반출하기 어려운 발전소 데이터를 힘겹게 확보해, 노이즈를 제거하고 태그를 매핑해 가공했다.
그리고 자체적으로 만든 알고리즘을 파이썬 코드로 분석하고, 오픈소스 관계형 데이터베이스에 저장한 다음, 웹 애플리케이션을 개발해 여러 그래프와 대시보드를 사용자에게 제공했다. 1개 발전소, 지극히 좁은 영역의 데이터로 만든 제품은 개념이 증명되고 현장에서 효과를 발휘하기 시작하자, 십여 개 발전소로 확장됐다.
처음 개발을 시작할 때는 자체적으로 만든 알고리즘이 얼마나 잘 동작하는지, 그리고 발전소 고객에게 정말 가치를 전달하는지가 증명해야 할 숙제였다. 하지만 그 단계를 지나고 보니 어떻게 하면 이 제품을 십여 개가 넘는 발전소에 설치하고, 한 곳으로 데이터를 수집, 분석해야 좋을지에 관한 문제로 바뀌었다.
적은 양의 데이터를 수집할 때는 모델링과 예측을 위한 배치 수행 시간이 그리 문제가 되지 않는다. 하지만 데이터가 수십 배로 늘어나니 수행 시간 자체가 큰 문제가 되기 시작하고, 여러 컴포넌트를 섞어서 만든 웹 UI는 예전처럼 빠르게 결과물을 뱉어내지 못하고 있다. 게다가 설치하기도 쉽지 않다. 총체적 난국이다.
프로젝트가 알려지는 시점에 내가 가장 걱정했던 것은 십여 개 발전소에 설치한 제품이 제대로 동작하는지 확인할 간단한 방법이 없었다는 것이다. 결국 제품에서 발생하는 로그를 취합하기 위해 조사하다가 ‘엘라스틱 스택(Elastic Stack)’이라는 녀석을 발견했다.
당시 엘라스틱 스택은 ELK로 불리며 로깅(Logging) 플랫폼으로 잘 알려져 있었지만, 정확히 어떤 기능을 하는지 알지 못했다. 하지만 하루 동안 전체 스택을 내려받고 이리저리 가지고 놀다 보니, 벌어진 입을 다물 수가 없었다. 이 녀석은 그냥 ‘로깅 플랫폼’이 아니었다.
내가 2년 동안 팀원 여러 명과 고군분투해 만든 전체 시스템을 대체할 수 있는 완벽한 ‘데이터 분석 플랫폼’이었다. 게다가 전 세계 사용자가 내려받고 기여해 만든 오픈소스 제품이기 때문에, 그 품질은 놀라운 수준이었다. 그리고 그 당시 만든 하나의 제품뿐만이 아니라, 내가 십수 년간 만들어온 프레임워크와 플랫폼이 오롯이 녹아있는 것을 확인하고서는 바로 엘라스틱 스택에 빠져들고 말았다.
‘ELK’는 엘라스틱(Elastic)에서 공급하는 엘라스틱서치(Elasticsearch), 로그스태시(Logstash), 키바나(Kibana)의 영문 앞글자를 모은 일종의 별칭이다.
엘라스틱서치는 검색 및 분석 엔진이다. 로그스태시는 여러 데이터 소스에서 데이터를 수집해 가공한 뒤, 다양한 데이터 저장소로 전달하는 데이터 처리 파이프라인 도구다. 키바나는 엘라스틱서치에 저장된 데이터를 차트와 그래프로 시각화하는 도구다.
ELK 스택의 인기는 날이 갈수록 높아지고, 다양한 사례가 발굴됐다. 시간이 흐르면서 데이터를 입수(ingest)하기 위해 사용하던 중앙 집중식 도구인 로그스태시보다 더 가벼운 데이터 전송 도구를 찾는 사용자가 많아졌다.
마침내 2015년, 엘라스틱은 경량의 단일 목적을 가진 데이터 전송기를 추가했고, 우리는 이 녀석을 비츠(Beats)라고 불렀다. 비츠가 ELK 스택에 들어오자, 어떻게 부를 것인가 고민을 하기 시작했다. BELK? BLEK? ELKB? 하지만 이런 별칭은 엘라스틱이 제공하는 스택만큼 유연하게 확장할 수 있는 이름이 아니었다. 그래서 결국, ‘엘라스틱 스택’으로 정했다.
조인석 필자의 ‘엘라스틱 스택 기반 데이터 분석’에 대한 자세한 내용은 ‘마이크로소프트웨어 395호(https://www.imaso.co.kr/archives/4654)’에서 확인할 수 있다.