ELK를 도입하게 된 이유

#왜 ELK를 썼는가

mysql 5.6부터 Innodb에도 FULLTEXT 인덱싱이 되는 데, 현재 시스템의 mysql 버전은 5.4의 innodb 여서 불가능하다.

쉽게 버전을 올리기도 불안하고 잘 돌아가는 시스템을 갈아 엎기도 부담스러웠다.

데이터 양이 억대로 많거나 복잡도가 높은 구조가 아니어서 미러 서버를 하나 새로 팔까 해보았지만,

생각 외로 손이 많이 갈 거 같아서 조금 더 찾아보고 결정하기로 했다.

인덱싱에 대한 방법적인 것은 많이 나와있지만 경험이 없고 최적화된 담당자도 없기 때문에, 

엘라스틱서치 로 인덱싱을 하기로 하였다. (정확히는 로그스태시가 jdbc로 긁어올 예정이지만)

그에 관한 내용을 좀 담을까 한다.

이러한 연유로 루씬 기반의 여러 검색엔진들을 찾아보다가, 가장 포럼이 큰 엘라스틱서치를 선택하게 되었다. 사실 여러 이유가 있었지만 이게 가장 컸다.

보통 어떻게 보면 WAS단에서 떨어지는 로그들을 마이닝하려고 개인적으론 보통 ELK를 많이 도입하는 걸로 파악이 되었었는 데, 이러한 접근과는 나는 조금 많이 다르다 보니 관련 문제에 대해 포스팅의 방향성이 많이 다르다.

우선 나는 엘라스틱서치 2.4.0 을 설치하고 (1달전에 이미 구축해서 인덱싱과 필터에 관한 내용을 학습했던지라, 오늘보니 2.4.1이 나와있더라)

로그스태시를 설치해, jdbc와 mysql을 연동해 인덱싱 된 데이터를 엘라스틱서치에 적재하였다.

여기서 엘라스틱서치에 웹 대시보드 플러그인을 설치해서 웹에서 관리가 쉽게 하도록 변경하였고, 몇 가지 쿼리와 테이블(RDB에서의) 형태로 엘라스티서치를 쉽게 접근하여 사용해보았다. 빠르긴 겁나 빨랐는 데, 내가 필터에 대한 이해도도 낮고, 인덱싱 설정도 몇 못한 게 있어서 인덱싱이 너무 세세하게 되어있던 것을 파악했다. 예를 들면 나에게 가장 필요한 것은 url 형태로 저장 된 데이터를 풀텍스트 검색하는 것인데, url의 특징을 보면 . . 점과 점으로 도메인이 나뉘어져있고, 슬래시를 통해서 자원의 경로(path)가 스플릿되어 있는 구조다 보니 딱히 설정을 안했더니 로그스태시 가 다 분할해서 집어넣었다.

이런 문제 때문에 다시 인덱싱을 해야하는 문제가 생겼다, 어쨋든 최종적인 문제가 내가 서버단에서 언제든 curl을 날릴 수 있는 것도 한계가 있으니 (당연한 이야기겠지)  에코 서버를 하나 개발 해야하지 않나 생각한다. 이 상황은 내가 RDB 에 익숙한지라 이를 어떻게 해결해야 하는 고민을 가지게 했다. 

사실 어떻게 보면 불가능한 것은 아니고, 간단하게 httpsimpleclient 라던지 좋은 http 관련 라이브러리로 간단하게 get/post만 엘라스틱서치 서버로 던지고 받은 json을 그냥 jaxkson이나 simplejson 같은 걸로 파싱해버리면 그만인 내용일 수도 있다. 그래도 뭐 더 편해질만한 것이 없나 하고 찾아보다가 몇몇 고마운 친구들이 좋은 플러그인을 만들어 놓은 것을 봤는데, 이 중에서도 엘라스틱서치의 nosql을 rdb의 sql 형태로 치환 해주는 플러그인이 있었다. (딱 내 상황에 적당한거였다.)

이름은 'elasticsearch-sql' 이고 (https://github.com/NLPchina/elasticsearch-sql) 지원하는 엘라스틱 서치 버전은 2.x 대를 지원한다.

대충 데모를 보아하니, mysql 기반의 익숙한 쿼리들이 많이보이는 데,

테스트 해보고 생각외로 괜찮아서 연동하기로 하였다.