보통 Logstash와 Kibana를 같이 쓰기 때문에 ELK라 하는데 최근엔 Beats등 제품군이 늘어남에 따라 그냥 Elastic stack이라 하기도 한다.
//
Elasticsearch는 기존의 RDB와 자주 비교되는데 가장 큰 특징은 역-인덱스(Inverted Index) 구조로 데이터를 관리하는 부분이다. 기술 서적의 목차를 바라보면 개념에 대한 이해가 빠른데,
기존의 Index가 토픽 기준으로 정리한 책 앞부분의 목차와 같은 구조라면 역-인덱스는 단어(Term) 기준으로 정리한 책 뒷 부분의 색인과 같은 구조를 가진다. 단어를 기준으로 색인을 만들게 되면 영단어의 경우 대소문자, 복수형/단수형 등 세밀한 처리가 필요하게 된다. 이러한 처리를 위해 Elasticsearch는 Analyzer(Filter, Tokenizer, ..) 같은 장치가 마련되어 있다. (한글은 지원을 안하지만 '은전한닢' 프로젝트에서 플러그인을 제공하는 것 같다.)
//
개념 잡기엔 inflearn 무료강의나 공식 홈페이지 튜토리얼이 좋다. 문제는 운영 측면에서, 클러스터 구축이나 메모리, 캐싱 설정 등등 경험해보지 않으면 알 수 없는 미지의 영역이 있는듯 하다. 작게 일을 벌여보기엔 굉장히 쉽고, 크게 일을 벌여보기엔 꽤나 어려운듯..
운영 관련해서,, 엄청 낮은 버전에서의 아티클이지만 아래 자료를 읽어볼 만하다.
http://d2.naver.com/helloworld/273788
보통 RDB를 많이 쓰니까 흔히 RDB와 많이 비교된다. 구조(개념) 측면에서
RDB : Database - Table - Row - Column - Schema는
Elasticsearch : Index - Type - Document - Field - Mapping으로 비교될 수 있다.
* 개인적으로 RDB의 'Database'에 대응되는 녀석의 이름을 'Index'라 지은게 좀 아쉽다. 영문으로 작성된 아티클을 읽어내려갈 때 이 'Index'가 이건지 저건지(?) 이해하기가 힘듬..
* Mapping은 따로 지정해주지 않아도 알아서 데이터가 들어가지만 잘못된 형식으로 저장될 수 있기 때문에 시각화 도구인 Kibana 까지 고려해서 사용한다면 Mapping이 있는 것이 좋다.
Elasticsearch는 REST API로 CRUD 작업을 할 수 있다. 메서드 타입으로 동작을 구분하며 각각 GET - Select / PUT - Update / POST - Insert / DELETE - Delete 와 같이 대응된다. Search 작업의 경우 간단한 것은 URI로 표현할 수 있지만 복잡한 구문은 Body에 실어서 수행하게 된다. 'BOOL' 구문과 같이 조금 특이한 구문이 많고 양이 많아 요건 천천히 들여다 볼 예정..
//
Logstash는 Input, Filter, Output을 지정해 특정 데이터 소스에 기록되는 데이터를 Elasticsearch 까지 보내주는 역할을 수행한다. 개인적으론 이쪽이 Elasticsearch에 비해 더 멋진 것 같다. 입력 소스로 표준 입출력이나 파일, 소켓, 등등을 지정할 수 있다. 로그 파일의 경우 파일 롤링까지 인식해서 처리되는듯 하다. Filebeat는 Logstash의 Input 타입이 파일인 경우에 쓰인다. (모든 수집 대상에 Logstash를 설치할 순 없는 노릇이다.)
[참고] csv를 input으로 받는 logstatsh 설정 예시. (출처: inflearn)
마지막으로 Kibana.
Elasticsearch에 쌓인 데이터를 입맛에 맞게 시각화해 볼 수 있는 엄청 멋진 툴인데, Front-end 코드를 한 줄도 작성하지 않고도 대시보드를 만들어 운영할 수 있다.
댓글 없음:
댓글 쓰기