Elasticsearch on

Elastic Stack으로 코로나19 대시보드 만들기 - 2부 : 대시보드

Wed, 17 Feb 2021 16:53:49 +0900

　지난 포스팅에서는 데이터를 수급하며 전처리 과정을 거쳤고, Filebeat와 Logstash를 거쳐 Elasticsearch에 인덱싱 하는 것까지 알아보았다. 앞선 포스팅에서 이야기했지만 단순하게 데이터를 시각화 도구를 이용해서 대시보드를 만드는 게 아니라 데이터가 추가되면 만들어둔 대시보드에 자동으로 반영되는 흐름을 만들고 싶었다. 마침 파이프라인을 이틀 전에 만들었기 때문에 그동안의 빠진 데이터를 추가해야 하는 상황이다. 이 경우 Filebeat-Logstash-Elasticsearch 가 실행 중이라면 앞서 작성했던 파이썬 스크립트만 한번 실행해 주면 이틀 치 데이터가 파이프라인을 거쳐 Elasticsearch로 인덱싱이 된다. 즉, 별도로 데이터를 가져와서 재 가공하고 추가하는 다소 까다로운 작업이 미리 만들어둔 파이프라인 덕분에 한 번의 스크립트 실행으로 손쉽게 처리가 됨을 알 수 있다.

　이제는 쌓여있는 데이터를 가지고 시각화를 해볼 차례이다. ElasticStack에서는 Kibana라는 강력한 시각화 도구를 제공하는데 이번 포스팅에서는 Kibana를 이용해서 대시보드를 만드는 방법에 대해 알아보려 한다.

Visualize

　Elasticsearch에 인덱싱 되어있는 데이터들은 기본으로 제공되는 REST API를 통해서 조회할 수 있고 JSON 형태로 결과가 나오기 때문에 이를 가지고 다양하게 시각화를 할 수도 있다. 하지만 Kibana에서는 데이터를 조회하고 UI로 표현하는 일련의 모든 행위를 클릭 몇 번으로 할 수 있게 해주기 때문에 전문가가 아니더라도 조금만 만져보면 누구나 만들 수 있다.

New Visualizaion!!

　버전업이 되면서 비쥬얼라이즈를 만드는 첫 화면 또한 변화가 생겼다. 기존에는 어떤 유형의 비쥬얼라이즈를 선택할 것인지에 대해 선택하는 화면부터 나왔는데 만드는 걸 보다 편리하게 도와주는 Lens, TSVB 같은 기능들이 먼저 반겨준다. 이 기능을 통해서 만드는 방법도 괜찮지만 보다 명시적으로 만들고 싶으니 하단에 Aggregation based을 선택해서 원하는 비쥬얼라이즈의 타입을 선택해 보자. 이후 생성되어 있는 인덱스를 선택하면 본격적으로 비쥬얼라이즈를 그릴 수 있는 화면이 나오는데 대시보드 화면 기준으로 만들어야 할 항목별로 살펴보자.

전체 수

　확진자, 사망자, 격리 해제의 총합을 표현하려 한다. 이렇게 ‘숫자’를 표현하려 하는 경우 Metric을 활용하곤 한다. 우측에서 Aggregation 방법을 ‘sum’으로 설정하고 필드는 유형별로 각각 선택해 주자. 아래 ‘Add’버튼을 눌러 확진, 사망, 격리 해제 수를 모두 표시한 다음 저장을 눌러준다. Label을 지정하지 않으면 어떤 형태로 Aggregation을 했는지를 Label 영역에 보여주는데 그게 보기 싫다면 원하는 텍스트로 지정해 주는 것도 방법이다.

최근 수

　확진자, 사망자, 격리 해제의 ‘최근 데이터’를 보여주는 게 목적이다. 이 경우 Aggregation을 Top Hit으로 선택하면 필드를 선택할 수 있게 되는데 하루의 데이터가 총 18 row이기 때문에 (서울, 부산, …, 제주, 검역) 18 row 을 전부 더한 값이 하루 기준의 합계가 된다. 여기서 정렬을 날짜 기준 내림차순으로 해줘야 가장 최근 데이터의 합계가 되는 점도 신경 써야 한다.

각 타입별 합계

　지역별로 타입별 수를 보기 위해 Pie 타입으로 선택하여 진행한다. 타입별(예로 들어 확진이면 confirmed)로 합계를 구하기 위해 Aggregation을 ‘sum’으로 설정하면 빈 원이 나오지만 각 지역별로 차트를 잘라서 봐야 하기에 하단의 Buckets의 Add를 누르고 regieon의 필드를 Terms Aggregation 한다. 18 row의 데이터가 전부 보여야 하기에 정렬 개수를 늘리고 option 탭에서 보는 취향에 알맞게 설정값들을 바꿔준다.

타입별 추이

　확진, 사망, 격리 해제 중에 사망을 제외하고 나머지 둘은 데이터의 크기가 크고 변화량이 비슷하기 때문에 x축은 시간으로 설정해두고 사망은 막대로, 나머지 둘은 라인으로 한 화면에서 표현하면 이 3가지 데이터를 한눈에 보기 좋을 것 같았다. Vertical bar 을 선택하고 x축(Buckets > X-axis)은 데이터 타입인 convert_date로 설정한다. 다음으로 사망은 매일 몇 명 사망했는지 뚜렷하게 보기 위해 그냥 sum으로, 나머지 둘은 누적 합계가 더 의미 있어 보일 것 같아 Cumulative Sum으로 Aggregation을 한다. 한 화면에서 3가지의 데이터를 보여주기엔 다소 y 축의 크기가 맞지 않으므로 확진, 격리 해제를 별도의 y 축(Y-axes)으로 ‘Metrics & axes’탭에서 설정해 준다. 다음으로 각 항목의 범례를 위로 표시하여 보다 보기 편하게 배치한다.

Elastic Stack으로 코로나19 대시보드 만들기 - 1부 : 파이프라인 구성

Mon, 15 Feb 2021 17:50:12 +0900

　얼마 전에 필자의 블로그를 보고 어느 교육 기관에서 ElasticStack에 대한 강의 요청이 들어왔다. 사실 관련 기술에 대해 지식이 아주 깊고 해박한 게 아니라서 약간의 반감부터 들었지만 ElasticStack을 전혀 모르는 사람들 기준으로 어떻게 돌아가는지에 대해서만 간단하게 소개하는 정도로 하면 된다고 하여 조심스럽지만 떨리는 마음으로 열심히 준비를 하기 시작했다. 그런데, 이런저런 이유로 갑자기 강의를 할 수 없게 되었고 그간 준비했던 내용들이 너무 아쉽지만 아무 소용이 없게 되어버렸다. 그냥 중단하기엔 아쉬운 마음이 너무 커서 준비했던 내용 중에 ‘데이터를 가지고 대시보드를 만드는 부분’은 누군가에겐 도움이 될까 싶어 블로그에 정리를 해보려 한다.

강의를 준비한 올해 1월 중순엔 Elasticsearch 버전이 7.10.2이었는데 블로그를 쓰고 있는 지금은 벌써 7.11으로 버전 업 되었다. 내가 아는 오픈소스 중에 버전업이 가장 빠른데 그렇다고 기능이 확 바뀌거나 습득하기 어렵게 바뀌진 않았다. 그만큼 사용자가 무엇을 원하는지 명확히 알고 작은 단위로 조금씩 바뀌어 가는 모습이 꽤 인상적이다.

　작년 초부터 코로나19 바이러스가 전 세계적으로 퍼지기 시작했고 아직까지도 진행 중이다. 나도 전염되는 건 아닐까 하는 두려움에 어디에서 얼마나 발생했는지를 확인하기 어렵던 시절 우리나라의 뛰어난 개발자들은 누가 시키지도 않았는데 정말 감사하게도 그 현황을 한눈에 볼 수 있도록 여러 유형으로 코로나19 바이러스 대시보드를 만들기 시작한다. 그 덕분에 좀 더 현황을 보기에 편해졌고 더욱 조심하게 되는 계기가 되었다고 생각한다. 이제는 포털사이트나 각종 매체를 통해 손쉽게 코로나19 바이러스의 현황을 볼 수 있지만 이러한 데이터를 가지고 검색엔진이지만 대시보드를 구축하는데 훌륭한 기능을 가지고 있는 ElasticStack을 활용해서 ‘나만의 대시보드’를 만드는 걸 정리해보고자 한다. 본 포스팅의 일회성으로 데이터를 가지고 대시보드를 만드는 것에서 끝나는 게 아니라 지속적으로 데이터가 업데이트된다는 가정하에 전반적인 “파이프라인"을 구축한 뒤 대시보드를 만들어 두고 데이터만 갱신하면 자동으로 대시보드 또한 업데이트되는 것을 목적으로 한다.

전체 흐름

글을 모두 작성하고 보니 양이 생각보다 길어져서 데이터를 조회하고 필터링하여 Elasticsearch에 인덱싱 하는 대시보드를 만들기 위한 일종의 “데이터 파이프라인"을 구성하는 부분과 만들어진 데이터 기반으로 Kibana의 다양한 기능을 활용하여 대시보드를 만드는 2개의 포스팅으로 나누어 정리해보겠다.

　최종적으로 만들게 될 대시보드의 모습은 다음과 같다.

최종 목표!

대시보드 구성 준비

　예전에는 Elasticsearch, Logstash, Kibana 3가지를 가지고 ELK라 불리다 Beat라는 경량 수집기 제품이 등장하며 이 모든 걸 ElasticStack라 부르기 시작했다. (공식 홈페이지 참고) 먼저 어떤 목표와 어떤 순서로 대시보드를 구성할 것인지에 대해 정리해봐야겠다.

데이터

　데이터는 공공데이터 포털에서 가져오려다 조회를 해보니 누락되는 날짜도 있었고 원하는 데이터의 품질이 생각보다 좋지 않아서 다른 곳을 찾아봐야 했다. 그러다 간결하게 정리한 데이터가 깃헙에 공개가 되어 있어서 그것을 사용하려 한다. 해당 데이터는 https://coronaboard.kr/ 에서도 사용되는 데이터라고 한다.

데이터 전처리(preprocessing)

　원하는 데이터는 위 깃헙에서 제공하는 데이터 중에 지역별 발생 현황. 해당 데이터를 살펴보면 요일별로 데이터가 ‘누적’되어 저장되어 있다. 즉, 서울지역 기준으로 2020년 2월 17일에 14명이 발생했고 2020년 2월 18일에 한 명도 발생하지 않았는데 14명으로 ‘누적’되어 저장되어 있다. 사실 이대로 해도 큰 문제는 없지만 어디까지나 별도의 가공 없이 최대한 원본 데이터(raw) 가 있어야 데이터 분석 시 다양하게 활용이 가능하기에 데이터를 분석하기 전에 전처리 과정이 필요했다. 정리하면, 집계 수가 누적되지 않고 날짜 기준으로 집계된 수만 있는 데이터를 원했다.

　필자는 주로 java를 가지고 개발을 하지만 가끔 간단한 스크립트성 개발은 python을 활용하는 편이기에 다소 이쁜 코드는 아니지만 데이터를 조작하려 아래와 같은 코드를 작성하였다.

누구나 할 수 있는 엑세스 로그 분석 따라 해보기 (by Elastic Stack)

Sun, 10 Feb 2019 14:37:31 +0000

필자가 Elastic Stack을 알게된건 2017년 어느 여름 동기형이 공부하고 있는것을 보고 호기심에 따라하며 시작하게 되었다. 그때까지만 해도 버전이 2.x 였는데 지금 글을 쓰고있는 2019년 2월초 최신버전이 6.6이니 정말 빠르게 변화하는것 같다. 빠르게 변화하는 버전만큼 사람들의 관심도 (드라마틱하게는 아니지만) 꾸준히 늘어나 개인적으로, 그리고 실무에서도 활용하는 범위가 많아지고 있는것 같다.

그래서 그런지 최근들어 (아주 코딱지만큼 조금이라도 더 해본) 필자에게 Elastic Stack 사용방법에 대해 물어보는 주변 지인들이 늘어나고 있다. 그리고 예전에 한창 공부했을때의 버전보다 많이 바꼈기에 이 기회에 “그대로 따라만 하면 Elastic Stack을 구성할 수 있을만한 글"을 써보고자 한다. 사실 필자가 예전에 “도큐먼트를 보기엔 너무 어려워 보이는 느낌적인 느낌” 때문에 삽질하며 구성한 힘들었던 기억을 되살려 최대한 심플하고 처음 해보는 사람도 따라하기만 하면 “아~ 이게 Elastic Stack 이구나!”, “이런식으로 돌아가는 거구나!” 하는 도움을 주고 싶다.

+ 그러면서 최신버전도 살펴보고… 1석2조, 이런게 바로 블로그를 하는 이유이지 않을까? 다시한번 말하지만 도큐먼트가 최고 지침서이긴 하다…

Elastic 공식 홈페이지에 가면 각 제품군들에 대해 그림으로 된 자세한 설명과 도큐먼트가 있지만 이들을 어떤식으로 조합하여 사용하는지에 대한 전체적인 흐름을 볼 수 있는 곳은 없어 보인다. (지금 보면 도큐먼트가 그 어디보다 설명이 잘되어 있다고 생각되지만 사전 지식이 전혀없는 상태에서는 봐도봐도 어려워 보였다.) 이번 포스팅에서는 Apache access log를 Elasticsearch에 인덱싱 하는 방법에 대해 설명해보고자 한다.

전체적인 흐름

필자는 글보다는 그림을 좋아하는 편이라 전체적인 흐름을 그림으로 먼저 보자.

외부에서의 접근이 발생하면 apache 웹서버에서 설정한 경로에 access log가 파일로 생성이 되거나 있는 파일에 추가가 된다. 해당 파일에는 한줄당 하나의 엑세스 정보가 남게 된다.
fileBeat에서 해당 파일을 트래킹 하고 있다가 라인이 추가되면 이 정보를 logstash 에게 전달해준다.
logastsh 는 filebeat에서 전달한 정보를 특정 port로 input 받는다.
받은 정보를 filter 과정을 통해 각 정보를 분할 및 정제한다. (ip, uri, time 등)
정리된 정보를 elasticsearch 에 ouput 으로 보낸다. (정확히 말하면 인덱싱을 한다.)
elasticsearch 에 인덱싱 된 정보를 키바나를 통해 손쉽게 분석을 한다.

한번의 설치고 일련의 과정이 뚝딱 된다면 너무 편하겠지만, 각각의 레이어가 나뉘어져있는 이유는 하는 역활이 전문적으로(?) 나뉘어져 있고 각 레이어에서는 세부 설정을 통해 보다 효율적으로 데이터를 관리할 수 있기 때문이다.

beats라는 레이어가 나오기 전에는 logstash에서 직접 file을 바라보곤 했었는데 beats가 logstash 보다 가벼운 shipper 목적으로 나온 agent 이다보니 통상 logstash 앞단에 filebeat를 위치시키곤 한다고 한다.

전체적인 그림은 위와 같고, 이제 이 글을 보고있는 여러분들이 따라할 차례이다. 각 레이어별로 하나씩 설치를 해보며 구성을 해보자. 설치순서는 데이터 흐름의 순서에 맞춰 다음과 같은 순서로 설치를 해야 효율적으로 볼수가 있다. (아래순서대로 하지 않을경우 설치/시작/종료 를 각각의 타이밍에 맞추어 해줘야 할것 같아 복잡할것같다.)

elasticsearch → logstash → kibana → filebeat

이 포스팅은 CentOS 7.4에서 Java 1.8, apache 2.2가 설치되어있다는 가정하에 보면 될듯하다. 또한 각 레이어별 설명은 구글링을 하거나 Elastic 공식 홈페이지에 가보면 자세히 나와있으니 기본 설명은 안하는것으로 하고, 각 레이어의 세부 설정은 하지 않는것으로 한다.

Elasticsearch

공식 홈페이지

다운받고 압축풀고 심볼릭 경로 만들고 (심볼릭 경로는 선택사항)
$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.6.0.tar.gz
$ tar zxvf elasticsearch-6.6.0.tar.gz
$ ln -s elasticsearch-6.6.0 elasticsearch

설정 파일을 열고 추가해준다.
$ cd elasticsearch/conf
$ vi elasticsearch.yml
path.data: /~~~/data/elasticsearch (기본경로에서 변경할때추가)
path.logs: /~~~/logs/elasticsearch
network.host: 0.0.0.0 # 외부에서 접근이 가능하도록 (실제 ip를 적어줘도 됨)

elasticsearch 의 시작과 종료를 조금이나마 편하게 하기위해 스크립트를 작성해줌 (이것또한 선택사항)
$ cd ../bin
$ echo './elasticsearch -d -p es.pid' > start.sh
$ echo 'kill `cat es.pid`' > stop.sh
$ chmod 755 start.sh stop.sh

혹시 아래와 같은 에러가 발생할경우 공식문서 대로 진행해준다.

엘라스틱서치 12월 서울 밋업 후기

Thu, 13 Dec 2018 22:27:02 +0000

엘라스틱을 처음 접하게 된 건 2017년 여름 facebook 피드에 “Elastic Stack을 이용한 서울시 지하철 대시보드” 라는 링크를 보게 된 것부터인 것 같다. 그 당시 데이터 분석 및 자동화에 관심이 커지고 있던 찰나였는데 키바나로 간단하면서도 아주 멋진 대시보드를 그릴 수 있다는 게 너무 흥미롭게 다가왔고 거기다 실시간으로 볼수 있다는 점에 공부를 시작하지 않을 수 없었다. 그렇게 이것저것 만들어 보기도 하고 한국 엘라스틱서치 커뮤니티 활동을 해오던 찰나 (최근들어 눈팅만 하고 있지만…) 올해 마지막 밋업을 한다고 하여 참여하게 되었다.

여기어때 본사 방문

강남에 위치한 여기어때 본사에서 밋업을 하게 되어 덕분에 다른 회사 구경을 할 수 있게 되었다. 예전 다른 IT 스타트업 밋업 행사에서도 느꼈던 부분인데 엄청나게 큰 시설은 아니지만 아기자기하게 회사의 색깔과 특징을 잘 살려놓은 인테리어가 인상적이었다. 그런데 생각보다 사람이 너무~ 많이 와서 약간 집중이 안 될것 같았지만 다행히도 자리를 잘 잡아서 세션을 듣는 데는 무리가 없었다. (정확하진 않지만 참석하신 분들 중의 절반 정도만 강의장에 들어오고 나머지는 밖에서 듣는 걸 보고 이런 IT 행사의 인기를 다시 한번 실감할 수 있었다.)

‘여기어때’ 본사건물에서 엘라스틱 밋업을!

엘라스틱서치 6.5 최신버전 소개 및 커뮤니티 회고

행사 처음 세션으로 김종민 커뮤니티 엔지니어 분께서 엘라스틱의 최근 업데이트 정보와 커뮤니티 활동에 대해서 회고해주셨다. 내가 처음 엘라스틱서치를 접한 버전이 2.4였는데 벌써 6.5라니… 빨라도 너무 빠르다. 이번 버전에서는 한 클러스터에서 다른 클러스터로의 인덱스를 복제하는 방법인 Cross-cluster replication (클러스터 복제) 기능이 추가되었고 ODBC Client 추가, 자바 11지원 등 여러 가지 기능이 추가되었다고 한다. 특히 키바나에서는 파일을 업로드하면 자동으로 분석해서 인덱싱을 해주는 기능도 생겼고 (파일 크기가 100메가 제한이라는게 살짝 아쉽긴 했다.) 캔버스, 스페이스 등 역시 키바나 라는 생각이 들 정도로 비주얼라이징을 한번더 업그레이드 한듯 하다. (다 사용할 수 있을까 하는 정도로… 엘라스틱 스택을 들어보기만 하던 함께 참석한 동기 녀석도 당장 해보겠다고 할 정도로…) 다른 자세한 내용은 여기서 확인이 가능하다.

너무나 빠른 버전업과 너무나 발빠르게 움직이는 사람들

엘라스틱서치 활용사례

스마일게이트 및 여기어때 에서 엘라스틱 서치를 활용한 사례를 발표해 주셨다. 하지만 아쉽게도 필자는 5.6 버전까지밖에 사용한 게 전부여서인지(그것도 일부 기능만) 전체 발표 내용을 다 이해를 하진 못했지만 구축하면서 생긴 문제나 삽질 경험담을 공유해주셔서 간접적으로라도 그때의 현장감(?)을 느낄 수 있어 좋았고, 한편으로 여태까지 나름 엘라스틱서치를 만져봤다고 약간의 자신감 반 자만심 반으로 생각했었는데 역시 세상엔 고수가 많구나 하며 다시 분발해야겠다고 다짐했다.

스마일게이트 + 여기어때

마치며

커뮤니티 활동 회고 시간에 누가 페이스북 커뮤니티에서 “공유"라는 단어를 사용해서 게시글을 작성했는지 키바나로 보여주고 밋업에 온 사람이 있다면 5만원 여기어때 쿠폰을 준다고 했었다. 마침 키바나 대시보드 한쪽 구석에 필자의 이름이 보였지만 (예전에 나름 활발하게 질문도 하고 공유도 했던 적이 있어서…) 쿠폰을 받는구나 하며 기대를 하고 있었지만 아쉽게도 최근에 작성한 몇 분에게만 선물이 돌아갔다… 하지만 그 아쉬움도 잠시, 무작위로 추첨하여 또 쿠폰을 준다고 했는데 당첨이 되어서ㅎㅎ 감사하게도 쿠폰을 받는 기쁨을 누릴 수 있었다!!

역시 밋업의 마무리는 굿즈모음이지(?)

매번 이런 IT밋업에 참가 신청을 하고 참석하기 전에는 “아 귀찮다. 취소할까. 날도 추운데. 피곤한데” 하며 가기 싫었지만 막상 와보면 생각보다 많은 것을 배워가고 얻어 간다. (쿠폰을 받아서가 아니라…) 세션에 발표하시는 분들, 그리고 그 발표를 듣는 참석하신 분들의 눈동자에서 배움에는 끝이 없고 배워야 살아남는다는 걸 (특히 IT직군은 더…) 다시 한번 느끼고 생각할 수 있었던 좋은 시간이었다.

시계열 데이터를 분석하여 미래 예측 하기(Anomaly Detection)

Thu, 31 May 2018 17:03:41 +0000

급변하는 날씨를 예측하려면 어떠한 정보가 있어야 할까? 또는 마트를 운영하는 담당자인 경우 매장 운영시간을 정해야 한다면 어떠한 기준으로? 뜨거운 감자인 비트코인 시장에서 수익을 얻으려면 어떤 정보들이 있어야 물리지(?) 않을수 있을까?

위 질문에 공통된 정답은 예전 기록들인것 같다. 날씨예측은 기상청에서 과거 기록들을 보고 비가 올지 말지를 결정하고 ( 과거 날씨 서비스를 담당해봤지만 단순히 과거 기록들로 예측한다는건 불가능에 가깝긴 하다. ) 매장 운영시간은 예전에 손님들이 언제왔는지에 대한 데이터를 보고. 비트코인이나 주식은 차트를 보고 어느정도는 상승장일지 하락장일지 추측이 가능하다고 한다. ( 물론 호재/악재에 따라 흔들리지만..ㅠㅠ..?? ) 이처럼 시간의 흐름에 따라 만들어진 데이터를 분석하는것을 시계열 데이터 분석이라 부르고 있다. 필자가 운영하는 서비스에서 시계열 데이터 분석을 통해 장애를 사전에 방지하는 사례를 공유 해보고자 한다.

상황파악부터

손자병법에는 지피지기 백전불태 라는 말이 있다. 그만큼 현 상황을 잘 알아야 대응을 잘할수 있다는것. 필자가 운영하는 서비스는 PG(Payment Gateway) 서비스로 쇼핑몰같은 온/오프라인 사업자와 실제 카드사와의 중간 역활을 해주고 있다. 이를테면 사용자가 생수를 10,000원에 XX카드로 구매해줘 라고 요청이 오면 그 정보를 다시 형식에 맞춰 카드사로 전달하여 사용자가 물건을 구매할수 있도록 해준다.

PG서비스 : 쇼핑몰과 카드사의 중간에서 릴레이 해주는 역활이라 보면된다.

요구사항 및 과거 데이터 분석

서비스를 운영해보니 감지하기 어려운 상황들이 있었다.

연동하는 쇼핑몰에서 문제가 발생하거나 네트워크 문제가 발생할경우 즉, 트래픽이 평소보다 적게 들어올 경우
정상적인 에러(e.g. 잔액부족) 가 갑자기 많이 발생할 경우

이를 분석하기위해 기존의 트래픽/데이터를 분석해봐야 했다.

결제건수 Kibana Visualize, 기영이 패턴

위 그래프는 결제데이터 카운트 인데 어느정도 패턴을 찾을수 있다.

에러건수 Kibana Visualize, 악어 패턴..(무리수..)

위 그래프는 에러카운트 인데 일정한 패턴 속에서 어느 지점에서는 튀는것을 확인할수 있다. (빨간색 영역) 그렇다면 어떤 방법으로 장애상황보다 앞서서 감지를 할수 있을까? ( 장애 : 어떠한 내/외부 요인으로 인해 정상적인 서비스가 되지 않는 상태 )

장애발생 전에 먼저 찾아보자!

가장 간단하게는 기존 데이터를 보고 수동으로 설정하는 방법이 있을수 있다. 예로들어 자정 즈음에는 결제량이 가장 많기때문에 약 xx건으로 설정해두고, 새벽에는 결제량이 가장 적기 때문에 약 yy건으로 설정해둔 후 에러 건수나 결제건수에 대해 실시간으로 검사를 해가면서 설정한 값보다 벗어날 경우 알림을 주는 방법이다. 하지만 아무리 과거 데이터를 완벽하게 분석했다 할지라도 24시간 모든 시점에서 예측은 벗어날 수밖에 없다. (예로들어 쇼핑 이벤트를 갑작스럽게 하게되면 결제량은 예측하지 못할정도로 늘어날테고…) 또한 설정한 예측값을 벗어날 경우 수동으로 다시 예측값을 조정해줘야 하는데, 이럴꺼면 24시간 종합 상황실에서 사람이 직접 눈으로 보는것 보다 못할것 같다. (인력 리소스가 충분하다면 뭐… 그렇게 해도 된다.)

지난 데이터와 비교하기

일주일 기준으로 지난 일주일과의 데이터를 비교해보는 방법또한 있다. 간단하게 설명하면 이번주 월요일 10시의 데이터와 지난주 월요일 10시의 데이터의 차이를 비교해보는 방법이다. 키바나에서 클릭 몇번만으로 시각화를 도와주는 Visualize 기능을 통해 지난 일주일과 이번주를 비교해보면 아래 그래프처럼 표현이 가능하다.

일주일 전 데이터와 단순 비교

이 경우도 지난주 상황과 이번주 상황이 다른 경우에는 원하는 비교 항목 외에 다른 요인이 추가되기 때문에 원하는 비교를 할수가 없고 위에서 수동으로 설정하는 방법과 별반 다를바 없을것으로 생각된다.

조금더 우아하게! `(언제부턴가 우아하단 말을 좋아하는것 같다..)`

개발자는 문제에 대해서 언제나 분석을 토대로 접근을 하는것을 목표로 해야한다. 언제부턴가 Hot한 머신러닝을 도입해 보고 싶었으나 아직 그런 실력이 되질 못하고… 폭풍 구글링을 통해 알게된 Facebook에서 만든 Prophet이라는 모듈을 활용해보고자 한다. https://opensource.fb.com/#artificial 이곳에 가보면 여러 Artificial Intelligence 관련된 오픈소스들중에 Prophet 모듈을 찾을수 있다. 다행히도 BSD License라서 실무에서도 다양하게 활용할수 있을것으로 보인다. 친절하게도 Quick Start을 통해 어떤식으로 예측을 하는지 보여준다. 참고로 Python 과 R 을 지원한다. (python 의 대단함을 다시금 느끼며…) 구성은 CentOS 7 + python3.6 + jenkins 를 활용한다. (python 경험이 부족하므로 코드가 허접할수도 있으니 양해바란다.) 데이터 분석시 가장 많이 사용된다는 Pandas와 대규모 다차원 배열을 쉽게 처리 할 수 있게 해주는 numpy, 그리고 bprophet를 비롯한 필요한 모듈들을 pip로 설치해준다.

아파치 엑세스 로그를 엘라스틱서치에 인덱싱 해보자.

Thu, 25 Jan 2018 21:18:35 +0000

apache access log 를 분석하고 싶은 상황이 생겼다. 아니 그보다 apache access에 대해서 실시간으로 보고싶었고, log를 검색 & 데이터를 가공하여 유의미한 분석결과를 만들어 보고 싶었다. 그에 생각한것이 (역시) ElasticStack.

처음에 생각한 방안은 아래 그림처럼 단순했다.

처음 생각한 단순한 구조

하지만, 내 단순한(?) 예상은 역시 빗나갔고 logstash에서는 다음과 같은 에러를 내뱉었다.

retrying individual bulk actions that failed or were rejected by the previous bulk request

request가 많아짐에 따라 elasticsearch가 버벅거리더니 logstash에서 대량작업은 거부하겠다며 인덱싱을 멈췄다. 고민고민하다 elasticsearch에 인덱싱할때 부하가 많이 걸리는 상황에서 중간에 버퍼를 둔 경험이 있어서 facebook그룹에 문의를 해봤다. https://www.facebook.com/groups/elasticsearch.kr/?multi_permalinks=1566735266745641 역시 나보다 한참을 앞서가시는 분들은 이미 에러가 뭔지 알고 있으셨고, 중간에 버퍼를 두고 하니 잘된다는 의견이 있어 나도 따라해봤다. 물론 답변중에 나온 redis가 아닌 기존에도 비슷한 구조에서 사용하고 있던 kafka를 적용. 아, 그전에 현재구성은 Elasticsearch 노드가 총 3대로 클러스터 구조로 되어있는데 노드를 추가로 늘리며 스케일 아웃을 해보기전에 할수있는 마지막 방법이다 생각하고 중간에 kafka를 둬서 부하를 줄여보고 싶었다. (언제부턴가 마치 여러개의 톱니바퀴가 맞물려 돌아가는듯한 시스템 설계를 하는게 재밌었다.) 아래 그림처럼 말이다.

그나마 좀더 생각한 구조

그랬더니 거짓말 처럼 에러하나 없이 잘 인덱싱이 될수 있었다. logstash가 양쪽에 있는게 약간 걸리긴 하지만, 처음에 생각한 구조보다는 에러가 안나니 다행이라 생각한다.

이 구조를 적용하면서 얻은 Insight가 있기에, 각 항목별로 적어 보고자 한다. ( ~~이것만 적어놓기엔 너무 없어보여서..~~ )

access log 를 어떻게 분석하여 인덱싱 할것인가?

apache 2.x를 사용하고 별도의 로그 포맷을 정하지 않으면 아래와 같은 access log가 찍힌다. 123.1.1.1 - - [25/Jan/2018:21:55:35 +0900] "GET /api/test?param=12341234 HTTP/1.1" 200 48 1144 "http://www.naver.com/" "Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_2 like Mac OS X) AppleWebKit/604.3.5 (KHTML, like Gecko) Mobile/15B202 NAVER(inapp; blog; 100; 4.0.44)" 그럼 이 로그를 아무 포맷팅 없이 로깅을 하면 그냥 한줄의 텍스트가 인덱싱이 된다. 하지만 이렇게 되면 elasticsearch 데이터를 다시 재가공하거나 별도의 작업이 필요할수도 있으니 중간에 있는 logstash에게 일을 시켜 좀더 nice 한 방법으로 인덱싱을 해보자. 바로 logstash 의 filter 기능이다. 그중 Grok filter 라는게 있는데 패턴을 적용하여 row data 를 필터링하는 기능이다. 조금 찾아보니 너무 고맙게도 아파치 필터 예제가 있어 수정하여 적용할수 있었다. http://grokconstructor.appspot.com/do/match?example=2 그래서 적용한 필터설정은 다음과 같다.

filter {
 grok {
 match => {
 message => "%{IP:clientIp} (?:-|) (?:-|) \[%{HTTPDATE:timestamp}\] \"(?:%{WORD:httpMethod} %{URIPATH:uri}%{GREEDYDATA}(?: HTTP/%{NUMBER})?|-)\" %{NUMBER:responseCode} (?:-|%{NUMBER})"
 }
 }
}

이렇게 하고 elasticsearch 에 인덱싱을 하면 키바나에서 다음과 같이 볼수 있다.

키바나에 내가 원하는 구조대로 이쁘게 들어가 있는 access log

각 필드가 아닌 한줄로 인덱싱이 되어버린다.

Elasticsearch 에 인덱싱이 되긴 하는데 로그 한줄이 통째로 들어가 버린다. message라는 이름으로… 알고보니 현재 구조는 logstash가 kafka 앞 뒤에 있다보니 producer logstash 와 consumer logstash 의 codec이 맞아야 제대로 인덱싱이 될수 있었다. 먼저 access log에서 kafka 로 produce 하는 logstash 에서는 output 할때 codec 을 맞춰주고

output {
 kafka {
 bootstrap_servers => "123.1.2.3:9092,123.1.2.4:9092"
 topic_id => "apache-log"
 codec => json{}
 }
}

kafka 에서 consume 하는 logstash 에서는 input 에서 codec 을 맞춰준다.

input {
 kafka {
 bootstrap_servers => "123.1.2.3:9092,123.1.2.4:9092"
 topic_id => "apache-log"
 codec => json{}
 }
}

그렇게 되면 codec이 맞아 각 필드로 이쁘게 인덱싱을 할수 있게 되었다.

Elastic{ON}Tour

Thu, 14 Dec 2017 12:02:45 +0000

작년에 팀을 옮기면서 로깅에 대해서 관심을 갖기 시작 하였고 찾아보다 ElasticStack 이 적합하다고 판단, 팀 내에서 나홀로 삽질해가며 지금의 로그 모니터링 시스템을 구축하였다. 그에 ElasticStack 에 관심을 갖던 찰나 지난 화요일(12월 12일)에 있었던 Elastic On Tour에 참석을 하였고 다양한 기술적 인사이트를 얻을수 있었는데 그 감동(?)을 잃기 싫어 정리해보고자 한다.

Registration + Partner Showcase

코엑스 인터컨티넨탈 호텔에서 진행되었다. 역시 외국계 기업이여서 그런지 행사 규모가 어마어마 했다. 이정표를 따라 지하로 가서 등록을 하고, ElasticStack 을 이용해서 서비스를 하고 있는 파트너사들의 부스를 기웃거리며 ElasticStack의 저력(?)을 다시한번 실감을 할수 있었다. 특히 Elatic 본사에서 나온듯한 외국인들이 Q&A 같은걸 해줬는데 답변을 해주는 외국인도 대단해 보였는데 질문을 하는 한국사람(?)들이 더 대단하게 보였다. 과연 난 저렇게 아무렇지 않고 프로페셔널(?)하게 질문을 할수 있을까?

Registration + Partner Showcase

Track 1 : Partner Sessions

Track 1 과 2로 나뉘였는데 2는 Elastic Stack 을 경험하지 못해봤거나 소개하는 자리같아서 Track 1를 듣기로 하였다. 내가 도입을 할때만 해도 관련 자료가 잘 없었고, 정말 특이 케이스가 아닌 이상엔 잘 사용하지 않겠구나 하는 느낌이였는데 발표하시는 분들을 보고서는 생각이 180도 바뀌었다. 너무 활용들을 잘 하며 서비스를 하고 있었고 단순하게 검색엔진이 아닌 상황에 맞는 커스터 마이징이나 다른 기술 스택을 함께 사용함으로써 시너지 효과를 내고 있었다.

Microsoft
- OpenSource 에 안좋은 이미지가 있으나 오래전부터 투자를 많이 해왔다고 설명을 하며 Azure라는 서비스에서 Elastic Stack 을 어떤식으로 활용하는지 발표를 하였다.
- 상당히 심플하고 처음 접하는 사람도 클릭 몇번으로 ES Cluster를 구성할수 있다는게 장점이였으나, 유료 + 커스터마이징 제한 이 아쉬웠다.
S-Core : 에스코어 경험에 기반한 Elastic 활용법
EZFarm
- (외모 비하는 아니지만)농부 처럼 생기신 분이 나와서 기술에 대해 말씀하시는게 신기한 발표였다.
- 간단히 말하면 돼지가 물 먹는 량 등 농업/축산업의 데이터를 ES에 담고 머신러닝을 통하여 효율화 하는 방안 이였던것 같다.
MEGAZONE
- 파트너 부스에서 티셔츠를 준(?) 곳이였는데 Elastic Cloud Seoul 을 발표하였다. (드디어 한국에도 이런 서비스가!)
OpenBase
- 키바나 플러그인을 직접 개발하고 커스텀 UI의 사례를 보여주었다.
- 키바나 소스중에 엑셀 다운로드가 한글로 안되어 고쳐본것 말곤 플러그인을 개발할 생각은 없었는데 정말 개발자 스러운 발표였다.
DIREA
- 결제 관련 장애추적 및 예측 시스템을 발표하였다.
- 마침 내가 하고있는 서비스와 비슷하고, 내가 구현해보려고 했던 부분과 거의 일맥상통한 부분이 있어서 소름이였다.

Track 1 : Partner Sessions

Opening Keynote

앞서 어떤 발표에서 ElasticSearch가 탄생하게된 계기가 어떤 분이 요리사가 되려는 아내를 위해 조리법을 더 빨리 검색할수 있는 엔진을 만들었다고 하는데 그 어떤분이 내눈앞에 나타나 발표를 하셨다. 현 Elastic CEO 이신 Shay Banon 이였다. (어색한 동시 통역으로 이해하였지만) 그분이 강조하신 Elastic 회사 정신인 “간단한건 간단하게 만들어야 하며 쉬워야 한다.” 가 연설중에 가장 인상적이였고, 통역하신 아주머님(?)때문이였는지 전달하시는 의도를 정확히 파악하긴 어려웠으나 일단 CEO를 포함한 전체 회사 분위기가 젊어보인다는걸 느낄수 있었다.

Shay Banon key note

Break (식사시간)

이런 세미나? 컨퍼런스? 를 많이 다녀본건 아니지만 역대급으로 좋았던 점심식사였다. ;) 사실 혼자와서 밥을 어떻게 해결하나 했는데 우르르르 호텔 직원분들이 각 자리에 도시락을 대령(?)해주셔서 맛있게 먹을수 있었다. 참 사람이 간사한게, 아침에 졸린눈 비벼가며 지옥철 고생을 뚫고 와서 힘들었지만 밥을 먹으면서 아침의 그 고생은 눈녹듯 사라졌다.

호텔 도시락!!

Deep Dive (Elasticsearch, Ingest, Kibana, Machine Learning)

각 스택(?)에 대해서 변화된 부분, 그리고 활용가능성과 최근 출시한 6.X 버전에 대해서 소개하는 시간이였다. 사실 아직 2.4 버전을 운영중이라서인지 6.X의 변화된 부분, 그리고 5.x 버전에서의 차이를 설명해주는데 확 와닿지는 못하였다. 아직 5.x 버전의 필요성을 못느껴서 버전업을 안하고 있었는데 발표를 듣고 꼭 유료 라이센스를 구매하지 않아도 용량 단축이나 안정성, 추가 기능등 5.X로의 버전업은 해서 나쁠것도 없을듯 하다는 생각이 들었다. (단, 무조건 신버전이 좋은것은 아닌듯 잘 알아보고 해야겠지…) 특히 키바나를 활용해 머신러닝을 눈앞에서 보여준건 너무 좋았다. 성능이 좋아서인지 데모시연 하는데 전혀 막힘이 없었으니…

Elasticsearch on

Elastic Stack으로 코로나19 대시보드 만들기 - 2부 : 대시보드

Visualize

전체 수

최근 수

각 타입별 합계

타입별 추이

Elastic Stack으로 코로나19 대시보드 만들기 - 1부 : 파이프라인 구성

대시보드 구성 준비

데이터

데이터 전처리(preprocessing)

누구나 할 수 있는 엑세스 로그 분석 따라 해보기 (by Elastic Stack)

전체적인 흐름

Elasticsearch

엘라스틱서치 12월 서울 밋업 후기

여기어때 본사 방문

엘라스틱서치 6.5 최신버전 소개 및 커뮤니티 회고

엘라스틱서치 활용사례

마치며

시계열 데이터를 분석하여 미래 예측 하기(Anomaly Detection)

상황파악부터

요구사항 및 과거 데이터 분석

장애발생 전에 먼저 찾아보자!

지난 데이터와 비교하기

조금더 우아하게! (언제부턴가 우아하단 말을 좋아하는것 같다..)

아파치 엑세스 로그를 엘라스틱서치에 인덱싱 해보자.

access log 를 어떻게 분석하여 인덱싱 할것인가?

각 필드가 아닌 한줄로 인덱싱이 되어버린다.

Elastic{ON}Tour

Registration + Partner Showcase

Track 1 : Partner Sessions

Opening Keynote

Break (식사시간)

Deep Dive (Elasticsearch, Ingest, Kibana, Machine Learning)

조금더 우아하게! `(언제부턴가 우아하단 말을 좋아하는것 같다..)`