콘텐츠 유통 데이터 분석 시스템 구축 - #2
Elastic Stack
본글에서는 지난번 콘텐츠 유통 데이터 분석 시스템(이하, 코다스) 프로젝트 개요 글에 이어서, Elastic Stack 프로젝트 내용을 정리한다.
프로젝트 이력을 정리하는 글이기 때문에 구체적인 설치나 개발 가이드는 아니며, 필자의 프로젝트 구축 노하우(라고 쓰고, 개고생이라고 읽음)를 중심으로 경험담을 적어 볼까 한다.
지난 글에서 설명한 대로 코다스의 뼈대는 오픈소스인 Elastic Stack이다. Elastic Stack을 사용하여 다양한 레거시 데이터를 유연하게 수집하고 빠르게 저장 및 검색 그리고 시각화를 제공했다.
Elastic Stack을 분석 시스템의 기반으로 결정한 이유
정형, 비정형 데이터를 수집하고 분석하는 오픈소스 플랫폼
손쉽게 대용량의 데이터를 수집할 수 있는 다양한 애플리케이션 제공
대용량 데이터 적용 사례가 다양(글로벌 : 우버, 옐프, 틴더, 국내 : U+ 등)
상용 서비스인 Splunk 대비,
> 라이선스 비용 無
> 데이터 인제스트 속도는 느림
> 자체 시각화 도구(Kibana) 및 타 시각화 도구를 활용 가능
SAS 형식도 유료로 지원(단, 오픈소스와 상용서비스 간의 통신은 불가, 상용은 데이터 모두 암호화)
맞다. 결국 라이선스 비용이 제일 컸다. -_ -;; (추가로, 대용량 데이터를 적용한 다양한 국내외 사례도 주요했다.) 2년여의 시간이 흐른 지금 돌이켜보니, 이 선택은 정말 옳았다.
Elastic Stack 설치
필자는 프로젝트에서 ElasticSearch만 사용해본 터라, Elastic Stack(ElasticSearch + Logstash + Kibana) 구성은 처음이었다. 그래도 워낙 가이드 페이지가 잘 되어있어서, 개발환경(Windows)과 서버환경(CentOS) 모두 무작정 따라 하기로 크게 무리 없이 설치할 수 있었다.
- Elasticserach : https://www.elastic.co/guide/en/elasticsearch/reference/current/install-elasticsearch.html
- Kibana : https://www.elastic.co/guide/en/kibana/current/install.html
- Logstash : https://www.elastic.co/guide/en/logstash/7.16/installing-logstash.html
초기에 v7.6으로 설치했는데 프로젝트 도중 v7.10 이상으로 업데이트되더라. 엄청 공격적인 업데이트! 이게 참 양날의 검이다. 업데이트가 반가우면서도 반갑지 않은... 그래서 1차 오픈 이후 7.10로 업그레이드했다. 업그레이드는 크게 어렵지 않았다. 단, 업그레이드 시에 Kibana 플러그인 버전은 꼭 살펴봐야 한다.
그리고 윈도우 버전에서는 별다른 문제가 없는데 리눅스 버전에서 설치하다 보면 계정/권한 때문에 혼란스러운 부분이 있다. 간혹 개인 블로그에 root 계정으로 설치하면 안 된다는 말이 있는데, 이는 좀 명확히 할 필요가 있다. Elasticssearch는 루트 계정으로 실행이 안되기 때문에, 패키지가 아닌 바이너리로 직접 설치할 경우 루트 계정으로 설치하면 문제가 발생한다. 어차피 패키지(rpm, deb) 방식으로 설치하려면 루트 권한이 필요하고 자동으로 elasticsearch, logstash, kibana 계정이 만들어져서 설치된다. 결국, 굳이 별도 계정 만들어서 설치하지 말고 루트 계정 + 패키지 이용해서 설치하는 게 여러모로 편하다.
Elastic Stack 팁 앤 테크
패키지 설치 후 자동으로 서비스가 시작되지 않기 때문에, 서비스 등록 및 환경 파일 수정 후 서비스 시작 명령이 필요하다.
가이드에 나와있는 공개 Repository를 사용해서 특정 버전으로 설치하는 명령어를 실행했으나 패키지가 가능하지 않다고 에러가 발생할 경우, 다음 순서대로 설치한다.
1. rpm 설치 파일 다운로드
2. sha 검사 파일 다운로드
3. 체크섬 비교
4. 설치
Elastic Stack 7.x 에는 x-pack이 기본으로 포함되어 있다.
Elastic Stack 힙 메모리 기본 설정이 생각보다 적기 때문에 서버 사양에 맞도록 변경을 권장한다.(성능에 많은 차이가 발생함)
Elasticsearchd에서 불용어나 동의어에 복합어를 넣을 때 의도한 대로 동작하지 않는 경우, Dictionary에 복합어를 단일어처럼 등록한 이후 사용하면 정상 동작한다.
Kibana는 NodeJs 기반이라서 JDK가 불필요하다.
Kibana가 설치된 서버를 강제로 재부팅하면서 정상적으로 실행되지 않는 문제 발생할 경우, 다음 순서대로 해결한다.
1. 로그에 Elastic Search에 연결할 수 없다는 메시지가 표시됨(elasticsearch all shard failed)
2. Elasticsearch는 정상적으로 접근되지만, Kibana Manager 인덱스에 문제가 발생
3. 문제가 발생한 인덱스만 삭제하고 Kibana 재실행
Kibana를 외부에서 ip로 접근할 때 안 되는 경우, 설정 파일에 server.host를 해당 아이피로 설정한다.
Kibana 플러그인 설치 시 bin에서 실행하면 디렉터리 찾을 수 없다고 에러가 발생하므로, Kibana 홈 디렉터리에서 실행해야 한다.
Logstash 7.10.x부터는 내부에 JDK를 포함하고 있고 해당 JDK 사용을 권장하기 때문에 별도로 설치할 필요가 없다.
Lostash 설정 파일을 변경하면 반드시 서비스 재시작해야 한다. auto refresh 걸어놔도 정상적으로 동작하지 않는 경우가 종종 있다.
Logstash에서 pipeline에 실행 후 바로 끝나는(스케쥴러 같은 반복 작업이 없는) 작업이 하나만 등록되어 있는 경우 서버가 무한 재 구동되는 현상 발생한다. 스케쥴링 걸린 작업이나 Standard Input처럼 입력이 지속적으로 있는 작업을 적어도 하나 등록한다.
Logstash에서 JDBC input을 사용할 경우, 쿼리의 필드명을 소문자로 인식한다.
SELECT NAME, PHONE_NUM …
%{name} %{phone_num}
Logstash Date Filter 설정
- timezone, locale 값은 해당 데이터에 적용된 타임존과 지역 값을 설정함
ex) 한국 시간이 저장되어 있는 값을 date 필드로 설정하고 싶을 경우
timezone => "Asia/Seoul"
locale => "ko"
- elastic search에 저장될 때는 UTC 기준으로 저장
ex) 한국 시간으로 지정되어 있는 값이 자동으로 데이트 필드로 지정되는 경우
logstash : 2020-05-09 00:00:00
elasticsearch : 2020-05-09 00:00:00.000Z
Logstash에서 JDBC input을 사용할 경우, 쿼리에서 TO_DATE, TO_CHAR 변환할 때 기본 날짜 포맷이 OS Locale 정보를 따라간다. 해서 개발환경(windows), 서버(Linux)의 결과가 상이할 수 있기 때문에 서버의 로케일 설정을 반드시 해 줘야 한다.
Logstash에서 JDBC input을 사용할 경우, MySQL locale 값이 SYSTEM으로 설정되어 있으면 에러가 발생한다. 이를 해결하기 위해서 JDBC connection에 serverTimezone 파라미터를 설정한다.
jdbc_connection_string => "jdbc:mysql://IP:PORT/sales_data_db?serverTimezone=Asia/Seoul"
Elastic Stack 소고
정리하고 나니 참 짧디 짧다. 팁 앤 테크 한 문장을 해결하기 위해 며칠을 고생한 기억이 난다. 다시 하라고 하면 진짜 못하겠다 -_ -. 그럼에도 불구하고 누군가 대용량의 비정형 데이터 분석을 기획한다고 하면 고민 없이 Elastic Stack을 사용하라고 권하고 싶다.
Logstash와 Elasticsearch의 수집 능력은 기대 이상
wavve, smr, 광고판매, 시청률, 화제성 지수, 유튜브 등 많은 데이터를 주기적으로 수집하고 있지만 기대 이상으로 안정적으로 동작한다. 가령 유튜브 데이터만 보더라도, 모든 채널에 있는 모든 영상의 소비 데이터와 수익 데이터를 합치면 4GB 이상의 볼륨이다. 이를 매일 1회 수집하는데 크게 무리가 없다. 물론 사용자가 없는 새벽에 작업을 분산해서 진행하지만 그럼에도 불구하고 다양한 데이터와 인덱스 클리닝 작업이 동시에 돌아가는 걸 고려하면 그저 감사할 따름이다.
Kibana의 시각화는 빠르고 유연
데이터 분석 서비스를 기획하면서 중요한 요소중 하나는 사용자가 데이터를 정보로 받아들이게 하는 시각화였다. 이를 보다 다양하고 유연하게 그리고 빠르게 제공하는 것이 핵심이었는데, 수집된 데이터 인덱스를 통해 시각화를 쉽게 구성하고 빠르게 제공하는데 Kibana가 발군이었다. 그리고 사용자의 요구사항이 워낙 다양하기 때문에 새로운 요청이 있을 때 유연하게 대처할 수 있는지도 중요했는데 이 부분도 꽤나 훌륭했다. 추가로, 데이터 크기에 비해 시각화 속도가 빨라서 꽤나 놀라웠다.
Elastic Stack 확장성
Elasticserach를 사용해서 사용자가 요청하는 데이터를 가공해서 제공하는 REST API를 만들었다. 새로운 서비스의 데이터가 필요할 때 Logstash를 통해 쉽고 빠르게 수집하고 Kibana로 생성한 시각화는 다양한 플랫폼에서 확장 가능했다.
서버 사양은 부족함 없이
필자의 경우 부족한 예산으로 저성능의 서버에서 개발할 수밖에 없는 상황이었는데, 서비스 오픈 1년 뒤 고사양의 서버(24 Core/128GB)로 이전하고 나니 그동안 발생하던 에러가 모두 사라졌다 -_ -;(성능 최적화고 나발이고 다 필요 없다 돈이 최고다.)
사내 서비스이기 때문에 사용자가 많지 않지만, 하나의 서버에서 Elastic Stack이 안정적으로 운영 중이다. 유튜브를 포함해서 많은 형식의 데이터가 44개의 수집 모듈을 통해 저장되고 시각화와 API를 통해 가공 및 제공되고 있다.
비정형 데이터의 매칭 알고리즘 개선은 꾸준히
코다스에서는 다양한 시스템의 비정형 콘텐츠 유통 데이터를 처리한다. 때문에 이 데이터들 간의 관계를 맺어줄 방법으로 프로그램명을 사용하고 있다. 문제는 이 프로그램명이 시스템 별로 천차만별이라는 거다.(그나마 존재하면 감사한 경우도 있다.) 이를 위해 코다스는 "통합키"라는 이름으로 Elasticsearch를 이용하여 매칭하고 있다. 용어사전과 동의어를 적극 활용하고 있지만 그럼에도 불구하고 예외들이 존재하기 때문에(유튜브 작성자님들 제발 좀 제목 좀 통일해 주면 안 되겠습니까...) 통합키 매칭 알고리즘은 지속적으로 업데이트해야 한다. 추후 딥러닝을 적용하여 수고를 덜 방법이 나올 수 있을 거라 믿어 의심치 않는다. 제발.
다음 글에서는 원본 데이터 수집 시스템인 coddas crawler를 다룬다.
부족한 서버 성능 덕분에 필자를 정말 고생시켰던 다양한 최적화 이야기를 풀어볼까 한다. 개. 봉. 박. 두!
