Elastic Stack: Elastic 회사에서 제공하는 4개의 소프트웨어로 구성된 빅데이터 파이프라인 추가적으로, X-Pack(보안, 알림, 모니터링, 머신러닝등의 기능)과 Elastic Cloud를 제공한다.
v5.0.0 이전 - ElasticSearch + Logstash + Kibana 로 이루어진 서비스 - ELK Stack 으로 불림 v5.0.0 이후 - Beats 를 시작으로 X-Pack과 Elastic Cloud 가 포함되어 Elastic Stack으로 불림
Elastic Stack의 구조
Beats: 데이터 수집 LogStash: 데이터 수집 및 집계, 전송 ElasticSearch: 데이터 저장, 색인, 분석 Kibana: 데이터 분석 및 시각화
-> Logstash나 Beats를 통해 모든 데이터를 수집하고, ElasticSearch를 통해 수집된 데이터의 검색, 처리, 저장하며 Kibana를 통해 데이터를 시각화
1. ElasticSearch
Elastic Stack의 중심
ElasticSearch란? ▶루씬(Lucene) 기반으로 개발된 분산형 오픈소스 RESTful API 검색엔진
▧ 루씬: 자바로 이루어진 정보 검색 오픈소스 SW이자 고성능 정보 검색 라이브러리
▶역할 : ◎모든 유형의 데이터(숫자, 문자열, ip, geo, date 등)를 색인하여 저장, 검색 집계를 수행 ◎이를 통해 결과를 클라이언트 및 다른 프로그램에 전달
그럼에도 왜 우리는 루씬대신 ElasticSearch를 사용할까?
루씬이 검색과 색인이 필요한 강력한 API를 제공하는 것은 맞다.
하지만, 결국 루씬은 어플리케이션이 아닌 라이브러리 ,따라서 사용자는 원하는 부분과 기능은 다 직접 개발이 필요하다.
ElasticSearch의 특징은 다음과 같다.
SchemaLess
전문검색(Full text Search)
NRT(Near Real Time)
RestFul API
클러스터식 구성
v7.x : type 구조의 삭제 v8.x: v7.x REST API 호환이 되도록 하였고, 또한 보안기능 기본적으로 활성화시킴
1.SchemaLess
여기서 SchemaLess는 스키마가 없다는 뜻이 아니라 동적으로 스키마가 생성된다는 의미이다.
DBMS는 데이터를 입력하기 전에, 테이블을 생성과 칼럼 정의 등 사전 작업이 필요하다.
하지만 ElasticSearch는 데이터를 입력하기 전에,데이터의 어떤 필드를 저장할 것인지 사전에 정의가 필요하지 않다.
왜냐하면 ElasticSearch는 자동으로 해당 데이터를 분석한 후에, 동적으로 스키마를 생성하기 때문이다.
2. 전문검색(Full text Search)
ElasticSearch는 역색인 구조를 가지고 있다.
역색인 구조를 통해 찾고자 하는 데이터가 어느 도큐먼트에 있는지 빠르게 검색 가능하다.
●Elastic Search와 RDBMS의 비교
RDBMS
ElasticSearch
schema
mapping
database
index
table
type
row
document
column
field
역색인 구조 - 1. 공백을 기준으로 text를 Tokenize
2. 토큰 별로 어느 문서에 있는지 기록
-> 검색으로 찾고자 하는 데이터가 어느 문서에 저장되어 있는지 빠르게 검색 가능
추가적으로 아래와 같은 특징들이 존재한다.
불규칙한 구조의 text도 색인 생성을 통하여 검색
다양한 데이터 타입 제공
관계형 데이터베이스에서 불가능한 비정형 데이터의 색인과 검색이 가능(빅데이터 처리에서 중요!)
텍스트를 여러 단어로 변형하거나 텍스트의 특질을 이용한 동의어나 유의어를 활용한 검색이 가능
형태소 분석을 통한 자연어 처리가 가능
3. Near Real Time(NRT)
거의 실시간으로 분석이 가능한 System이며, 색인과 검색이 거의 동시에 이루어진다.
기존의 하둡 시스템과 달리 ES cluster가 실행되는 동안에는 꾸준히 데이터가 입력(indexing) & 동시에 1초후 바로 검색 및 집계가 가능
4. RestFul API
표준 인터페이스(REST API)를 기본으로 지원,
Data에 대한 http Method를 통해 CRUD를 수행
5. Cluster 구성
대용량의 데이터 증가에 따른Scale-Out & 데이터 Integrity(무결성) 유지를 하기 위한 구성
한 클러스터 내부에 하나 이상의 노드가 존재
- cluster : 여러 대의 컴퓨터 혹은 구성 요소들을 논리적으로 결합하여 하나의 컴퓨터처럼 사용할 수 있도록 하는 기술
여러 노드를 한 클러스터 내에 생성 - 부하 분산
여러 노드 중 한 노드 장애 발생 시, 다른 노드들로 클러스터 재구성 - 안전성 확보
여러 노드에 Data Replica(복제본) 생성 - 안전성 확보
→ 운영 및 확장성 용이
ElasticSearch의 장점
유연성 & 호환성
Elasticsearch,Logstash,Kibana는 각각의 역할을 담당하기 때문에, 용도별로 분리해 version Up 및 발전하는 솔루션 - 구조적 안정성까지 보장
스키마가 자유롭다
수평 확장성
클러스터에 노드를 추가함으로써, 수평적으로 확장이 용이
부하 분산 및 안전성 확보
운영 및 확장성이 용이
사전에 준비된 다양한 부가기능
Kibana 를 통한 UI 및 다양한 부가기능 제공 - 사전의 다른 작업 요구 X
ES 버전 별 Bulk 방법 차이 완화
Bulk = (RDBMS)의 Insert
ES는 버전 별로 벌크 방법의 차이가 존재한다.
하지만 Logstash를 통하여 ES 핸들링으로 벌크 문제를 해결
ElasticSearch 단점
진입 장벽이 존재
Document 간 조인을 수행할 수 없다. (두번 쿼리로 해결해야 한다.) -> "but" ES는 애초에 조인을 할 필요가 없다.
트랜잭션 및 롤백이 제공되지 않는다.
진정한 의미의 실시간 처리가 불가능하다. (색인된 데이터는 1초 뒤에 검색이 가능하다.)
진정한 의미의 업데이트를 지원하지 않는다. (물론 있긴 하나, 삭제했다가 다시 만드는 형태)
Search Engine의 시장 현황
Elastic Stack과 Splunk 비교
공통점: Splunk와 ES의 주요 목표는 모두 시스템 로그 파일을 모니터링, 분석, 집계 및 시각화하는 것이다.
차이점: Splunk는 우수한 사용자 인터페이스를 갖춘 보다 편리한 솔루션이지만 사용자 라이선스를 구입하는 데 비용이 많이 든다. ES에 포함된 Kibana의 데이터 시각화는 초기 설정에 있어Splunk보다 덜 편리하지만 오픈 소스이기 때문에, 사용자 라이 선스 비용이 없고, ES가 Splunk에 비해 검색성능이 빠르다는 점이 강점이다.
결론: Splunk와 ELK 간의 처리 능력과 기능은 비슷하다. ELK는 구현 프로세스 초기에 설정하는 데 더 많은 작업과 계획이 필요하 지만 초기 설정 이후로는 ELK의 데이터 추출 및 시각화는 Splunk보다 사용자 친화적이고 검색 성능면에서는 월등하다.
2. Logstash
다양한 소스로부터 데이터를 수집하고 곧바로 전환하여 원하는 대상에 전송할 수 있도록 하는 경량의 오픈 소스 서버측 데이터 처리 파이프라인이다.
특징:
데이터를 수집하고 filter를 통하여 데이터를 변환(가공) 후, ES 혹은 다른 데이터 저장소로 데이터를 전달 + 비정형 데이터를 쉽게 로드
다양한 Plug-in이 지원 (유연한 플러그인 아키텍쳐)
확장 및 실시간 데이터 파이프라인 구축에 유용
Logstash의 데이터를 처리하기 위한 과정
1. Input - 입력 데이터의 다양한 형태와 크기, source등을 지원한다.
2. Filter - 데이터의 구문을 분석 및 변환 작업을 수행하며, 데이터의 형식이나 복잡성에 관계 없이 동적으로 변환한다. ex) grok filter - 비정형 데이터 구조 도출 / ip 주소 위치 좌표 해석을 하는 필터도 존재
3. Output - ES를 포함한 다양한 데이터 저장소로 사용자의 요청에 알맞는 출력 형태로 전달
3. Kibana
ElasticSearch의 데이터를 가장 쉽게 시각화할 수 있는 확장형 UI 도구
이를 통하여 사용자는
검색 및 집계 기능을 통하여 손쉽게 ES의 데이터 조작 가능
시각화 도구를 이용하여 DashBoard 및 Canvas 생성 가능
다양한 형태(json, url)로 저장 및 Export 가능
4. Beats
Logstash는 데이터 수집기로 좋긴 하나, 다양한 기능을 제공하기 때문에 상황에 따라 너무 무거울 수 있다.
-> 가볍게 데이터만 수집할 수 있는 Beats를 만들어냄
즉, Beat는 지정된 위치의 Log file 만 읽고, logstash 혹은 ES로 전달해주는 역할만 수행한다.
따라서 가공(필터)에 대한 역할을 잘 수행해지 않음(가공을 할 순 있다.)
Logstash와 Beats 비교
Logstash
풍부한 기능을 제공(filter 및 변환)
Data 가공이 필요한 경우에 사용
Beats
resource(CPU & RAM) 적게 소모
Elasticsearch로 직접 전달할 경우에 유용
별도의 분석이 필요 없는 경우
Log 자체가 json 형식이고, 가공할 필요가 없을 경우
case 1
Beat는 log 파일을 읽기만 하고 별도의 가공X
로그 파일의 format이 달라진다면?
- parsing의 역할을 하는 Logstash의 설정을 변경해주면 된다.
따라서 이러한 경우는 beat 와 logstash의 역할을 분명히 나누었다고 볼 수 있다.
-> 확장성/효율성 측면에서 좋다.
case2
beat에서 json 형태의 문서로 가공
장점 : 빠르게 ES로 로그 전송 및 수집 가능 단점 : log file format이 변경되었을 때, 모든 application 서버의 beat의 설정을 변경해야 함
+ X-Pack
Elastic Stack에 대하여 여러가지 확장 가능성을 제공
Security - 인증기능, 사용자 관리, 노드, http elasticsearch 클라이언트 간의 통신 트래픽 보호등을 하며,
field / document 수준까지 데이터를 보호 / Audit Log(감시로그) 제공
Altering - 데이터 변경사항이 있다면, 사용자에게 알림 제공
Monitoring - ELK Stack 의 상태를 지속적으로 체크하는 기능
Reporting - PDF 형식의 주기적인 보고서를 생성할 수 있습니다. 또한 email에도 전송이 가능
Graph - 데이터 시각화를 그래프로써 표현
Machine Learning - 데이터의 흐름 및 주시성 등을 자동으로 실시간 모니터링하여 문제를 식별하고 이상값 탐지등 근본 원인을 분석
+ Elastic Cloud
최신 버전의 Elasticsearch 및 Kibana를 사용하여 Amazon AWS에서 실행되는 보안 클러스터를 배포하고 관리
