Elastic Stack 이란 ?

이동명·2023년 6월 24일

Elastic Stack

# 일반적인 검색의 문제

RDBMS 내 검색 (WHERE, LIKE 등등)

단순 텍스트 패턴매칭에 대한 검색만을 제공 (ex. like %가%)
다량 또는 복잡한 조건의 데이터 검색 시, 속도 현저히 느려짐
자연어 처리 및 비정형 데이터의 색인과 검색 불가

예시를 들어보자

문제점 시나리오 RDBMS

H.com 에 방문하신 유OO 씨는 "두루치기" 를 검색.

하지만 배고픔으로 인해 급한 나머지 "enfnclrl(두루치기)" 로 검색.

RDBMS : 뭐? enfnclrl? 오케이!

RDBMS의 관리중인 "Food" 테이블에서 enfnclrl이 포함된 데이터를 조회
당연하게도 저런 데이터가 존재하지않아 Empty 를 반환

-> 사용자가 원하지 않는 결과 반환

사용자의 실수를 고려하지 않는 결과에 분노하며 사이트를 꺼버림

이처럼 서비스를 이용하는 고객들은 예기치못한 상황을 발생시킴

이런 상황에 대해 유연하게 대처할 수 있는 서비스의 개발이 필요하다.

이런 검색도 해결해줄 방법 없나? -> Elastic search

`Elastic search`

루씬(정보 검색 라이브러리)을 기반으로 개발된 오픈소스 검색 엔진
NoSQL(비관계형 데이터베이스) 의 일종
기존 데이터베이스의 검색 방식이 아닌 역색인 방식의 검색을 지원
전문검색 및 분석 후 검색 지원
Rest API 지원

루씬 라이브러리

자바로 만들어진 고성능 정보 검색 개발용 라이브러리
색인과 검색기능에만 집중한 강력한 기능 지원
정확도와 재현율을 기준으로 검색의 품질을 구현
정확도: 관련없는 데이터를 얼마나 정확하게 제거한지 판단
재현율: 입력받은 데이터를 얼마나 빼먹지않고 찾아냈는지 판단

루씬 검색 과정

관리 인터페이스
- 서버 상태 관리, 검색 과정에서의 다양한 설정 API 를 담당
분석 인터페이스
- 웹 기반으로 구성, 질의어 분석과 데이터 분석 API를 담당

역색인

색인 (List)

어떠한 내용에 대해 최단시간내에 찾아내기 위해 먼저 조회하는 자료구조
- ex) 책의 목차
일반적인 RDBMS 에서 주로 단방향 색인을 사용
문서들을 조회하며 해당 단어가 있는지 확인

역색인 (Map)

분석된 키워드들을 바탕으로 문서를 찾아가는 형식
미리 인덱싱되어있는 구조를 통해 단어가 나타나는 문서를 빨리 찾아낼 수 있음

색인과 인덱싱의 차이

일반적으로 색인(Index)은 데이터의 정렬된 구조를 의미합니다. 즉, 데이터를 효율적으로 관리하고 검색하기 위해 특정 기준에 따라 데이터를 정리하는 과정을 말합니다. 색인은 특정 데이터 구조에 따라 데이터의 키와 해당 데이터의 위치 정보를 연결하는 역할을 합니다. 데이터베이스나 검색 엔진에서는 색인을 사용하여 데이터를 검색하고 접근하는 데에 활용됩니다.
인덱싱(Indexing)은 데이터를 색인 구조로 변환하는 과정을 의미합니다. 즉, 데이터를 색인화하여 검색 가능한 구조로 만드는 작업을 말합니다. 데이터를 인덱싱한다는 것은 데이터를 효율적으로 검색할 수 있는 형태로 변환하는 과정이라고 볼 수 있습니다. 이 과정에서 데이터는 적절한 데이터 구조에 따라 정리되고 역색인 등의 방법을 사용하여 키와 위치 정보를 연결하여 색인을 생성합니다.
간단히 말해, 색인(Index)은 정렬된 데이터 구조를 의미하며, 인덱싱(Indexing)은 데이터를 색인 구조로 변환하는 과정을 말합니다. 데이터를 색인으로 만들어 검색 기능을 효율적으로 수행할 수 있도록 합니다.

물리적 구조

세그먼트

엘라스틱 서치의 빠른 문서 검색을 위해 설계된 자료 구조
검색 시, 샤드에 있던 다량의 세그먼트들이 결과값을 도출

샤드

인덱스 내부의 파티션, 데이터 손실 최소화 가능

노드(프로세스 단위)

엘라스틱 서치의 대용량 데이터(클러스터)의 색인 및 검색을 처리
마스터노드, 데이터노드, 코디네이팅 노드, 인제스트 노드로 이루어져있으며
각자의 수행 작업이 모두 다름

클러스터(시스템 단위)

엘라스틱 서치의 노드가 여러개 모인 전체 데이터를 저장하고 모든 노드를 포괄하는
통합적인 색인과 검색을 처리함
각 클러스터는 고유한 이름을 지녀야 노드가 잘못된 곳에 포함될 일이 없음

검색 과정

Query Phase

처음 쿼리 명령을 받은 노드는 모든 샤드에게 쿼리를 전달 후 1차적으로 샤드 검색 실행
각 샤드들은 요청된 크기만큼의 검색 결과 큐를 노드로 반환

Fetch Phase

노드는 반환받은 결과들의 점수 (score) 를 기반으로 정렬한 후, 샤드들에게 최종 결과를 요청
전체 문서내용등의 정보가 담긴 결과가 반환되어 클라이언트로 전달

REST api 를 통한 데이터 조작

example) curl -X GET http://localhost:9200/shop/products/1

shop 이라는 인덱스(데이터베이스)의 products라는 타입(테이블)의 첫번째 Document(Row, 데이터)를 가져오라는 명령어입니다.

엘라스틱 서치 사용 시나리오

분노를 가라앉히고 이번에 새로나온 T마켓 에 방문한 고객은 "두루치기" 를 검색

하지만 이번에도 배고픔과 분노로 인해 급한 나머지 "enfnclrl(두루치기)" 로 검색

Elastic search -> 분석된 키워드로 인덱스 조회

Elastic search -> 원하는 결과 반환

고객 만족!

강력한 검색 엔진 어떻게 저런 결과가 가능한 걸까 ?

엘라스틱 서치에서는 여러 플러그인을 통해 시나리오와 같은 오타뿐만 아니라, 사전에 등록된 여러 동의어 처리도 가능하게끔 해줄 수 있습니다.

엘라스틱 활용 성공 사례

NSHC
- 언더그라운드 해커모임으로 시작하여 2003년부터 정보보호 전문 회사로 발전한 회사이다. DarkWeb 에서 Elastic Search 를 활용한 보안 데이터 수집 및 분석 특정 거래가 이루어졌는지를 확인할 수 있는 모니터링 솔루션을 만들어 냄
eBay Korea
- Gmarket, G9, 옥션 등 브랜드를 보유하고 있는 국내 최대 전자상거래 기업 이베이코리아 에서는 내부 툴을 위한 검색 뿐만 아니라, 지마켓, G9, 옥션의 상품검색, 주소록 자동완성 등의 기능을 Elastic Search 로 이용
- 발생하는 대량의 데이터 로그들을 엘라스틱서치를 사용해서 저장 및 검색

그 외 삼성SDS, 11번가 , Citi 은행, 포스코, 네이버 등 등등 많이 사용되고 있다.

# 전문 (full text)검색 엔진

전문 full text : 단순한 문장부터 뉴스 기사나 논문 등 다양한 글의 전체 내용을 의미함

프로젝트를 진행 하다보면 DB 설계를 하고 개발에 들어가며 처음에는 큰 문제없이 잘 작동하다 많은 사람들이 사용하게 됨에 따라 서버 성능 , DB 설계의 문제나 혹은 DB 최적화가 되어있지 않아 서비스가 느려지는 현상을 경험하게 될 것이다. 그 문제를 해결하는 과정에서 관계형 데이터 베이스에 최적화를 위해 인덱싱을 하게 되고 이 점은 굉장히 중요한 작업이며 어떻게 인덱싱을 하냐에 따라 퍼포먼스가 다른 것을 경험할 수 있을 것이다.

DB 인덱스란 ?

인덱스(Index)는 데이터베이스 분야에 있어서 테이블에 대한 동작의 속도를 높여주는 자료 구조를 일컫는다. 인덱스는 테이블 내의 1개의 컬럼, 혹은 여러 개의 컬럼을 이용하여 생성될 수 있다. 고속의 검색 동작뿐만 아니라 레코드 접근과 관련 효율적인 순서 매김 동작에 대한 기초를 제공한다. 인덱스를 저장하는 데 필요한 디스크 공간은 보통 테이블을 저장하는 데 필요한 디스크 공간보다 작다. (왜냐하면 보통 인덱스는 키-필드만 갖고 있고, 테이블의 다른 세부 항목들은 갖고 있지 않기 때문이다.) 관계형 데이터베이스에서는 인덱스는 테이블 부분에 대한 하나의 사본이다.

예를 들어, 고객 데이터를 포함하는 데이터베이스 테이블이 있다고 가정해봅시다. 이 테이블에는 고객의 이름, 전화번호, 주소 등 다양한 열이 포함될 수 있습니다. 이때, 고객의 이름을 기준으로 빠르게 검색하고자 한다면, 이름 열에 인덱스를 생성할 수 있습니다.
인덱스를 사용하면 데이터베이스는 인덱스 구조를 생성하여 각 고객의 이름과 해당 고객의 데이터가 저장된 물리적인 위치를 매핑합니다. 따라서 이름이 "John"인 고객을 검색할 때, 데이터베이스는 인덱스를 통해 "John"이라는 값이 저장된 위치를 빠르게 찾을 수 있습니다. 이를 통해 검색 속도를 향상시킬 수 있습니다.
하지만 인덱스는 데이터베이스의 성능을 향상시키는 동시에 일정한 오버헤드를 가지고 있습니다. 인덱스를 생성하면 데이터의 추가, 수정, 삭제 작업이 더 복잡해지며, 디스크 공간을 추가로 사용하게 됩니다. 따라서 인덱스를 생성할 때는 검색 작업의 빈도와 성능 향상의 이점을 고려해야 합니다.

정리하자면

테이블에 대한 검색의 속도를 높여주는 자료 구조입니다.
색인이고 메모리 영역의 일종의 목차를 생성하는 개념입니다.
따라서 이런 목차를 이용하여 검색 범위를 줄여 속도를 높일 수 있습니다.

인덱스는 고유 제약 조건을 실현하기 위해서도 사용된다. 고유 인덱스는 중복된 항목이 등록되는 것을 금지하기 때문에 인덱스의 대상인 테이블에서 고유성이 보장된다.

엘라스틱 서치가 빠른 이유 또한 역시 데이터에 다양한 규칙으로 최적화된 인덱싱을 처리 할 수 있어서 검색에 빠른 성능을 보이는 것이다.

그렇다면 `RDB` 와 무엇이 다르길래 그렇게 빠르다고 하는 것일까 ?

RDB 와 Elastic search의 데이터 저장되는 구조 자체가 다르다.

RDBMS의 데이터 저장 형태
inverted index라는 구조로 텍스트를 다 뜯어서 검색어 사전을 만든다. (Term이라고도 한다)

따라서 Text Analysis에서 특히 효과적이다.
한국어 형태소 분리도 가능하다고 한다. 실제로 저장되는 형태는 아래와 같다.

Elastic search의 데이터 저장되는 구조
RDB 와 비교

만약 사용자가 "봉준호" 라고 검색을 할 시.. ?

RDB의 경우 Document에 하나하나 접근을 하여 director 가 "봉준호" 인지 확인을 한다.

그리고 맞다면 해당 Document(Column)을 노출 시켜 준다. 이런식으로 RDB는 해당 데이터안에 접근을 하여 확인할 수 있는 반면에

Elastic search 의 경우 Text 자체 "봉준호"를 저장을 한다. 그리고 봉준호가 가지고 있는 데이터 자체가 어디에 있는지 한번에 알 수 있다. 이러한 차이 때문에 속도가 굉장히 빠르다.

RDB는 document 중심이라면 Elastic search는 텍스트 중심이라고 보면 된다.

유저가 영화감독 봉준호를 검색하는 순간 관계형 데이터는 doc1~ doc3을 하나하나 확인하며 봉준호의 영화 데이터 위치를 찾지만. Elastic search 는 검색하는 순간 데이터를 찾을 수 있기 때문이다.

그렇다면 이렇게 생각할 수 있다.

"그럼 왜 관계형 DB를 쓰지? 그냥 엘라스틱 서치로 처음부터 하면 되지 않을까?"

답은 No이다.

이유는 Elastic search 장 단점에서 볼 수 있다.

엘라스틱 서치의 장점

오픈소스 검색 엔진이기 때문에 무료로 사용 가능하다.
오픈소스의 장점처럼 많은 전문가들이 버그에 빠르게 대응합니다.
방대한 양의 데이터를 신속하게 처리가 가능하다.

엘라스틱 서치의 단점

진입장벽이 있다.
- 어느정도 학습이 되지 않으면 에러 대응이 힘들다.
Document간의 조인을 수행할 수 없습니다.
- 다만 이 경우엔 쿼리를 두번 던져 해결 가능
트랜잭션과 롤백을 제공하지 않는다..
기존 데이터 Update 를 제공하지 않음
- 업데이트 명령 요청 시 기존 문서를 삭제하고 새로운 문서를 생성하는 방식

# 로그 수집 기술

로그 수집 기술이란 무엇일까?

완성된 시스템을 안정적으로 운영하려면 로그 수집 기술은 정말 필수적이다.

만약 운영하고 있는 시스템에 장애가 발생한다면, 로그를 분석함으로써 발빠르게 대응할 수 있기 때문이다.

개발할 때야 개발자들 끼리 지지고 볶고 한다고 해도

완성된 시스템을 운영할 땐 실제로 사용되는 서비스이기 때문에 짧은 몇분 몇초의 장애에도 정말 속이탄다.

게임 서비스 에서 시스템 장애라던지, 또는 악성 사용자, 인가되지 않은 프로그램으로 무언가 시도 하려는 사용자, 또는 1초에 수십억씩 거래가 되고 매순간 매초가 소중한 거래소 페이지 라던지 이런 부분에서 에러 대응이 늦어지면 늦어질 수록 커다란 피해가 올 수 있다.

ex) 루나 대폭락시 1일 거래량 6468만달러(약 7217억원)

IT 업계에서 개발 직군으로 일하게 된다면 반드시 마주치게 되고 익숙해져야 할 것이 이 로그 관련 기술이다.

이번 글에서는 그런 기술 중에서도 꽤나 트렌디하고 핫한 ELK 스택에 대해 알아보려고 한다.

# ElasticStack 이란 ?

여기서 말하는 Stack 이란 3개의 기술을 가지고 스택처럼 구성을 한 것을 말한다. 예를 들면 MEAN 스택 WAMP 스택 LAMP 스택 등 처럼 무언가 만들어 낼 때 사용하는 하나의 패키지 혹은 번들 처럼 엮어놓은 것이라고 볼수 있다.

1. ElasticStack 의 구성 원리

Elastic Search : 수집된 데이터를 한곳에 모아주고 관리하는 일종의 데이터베이스, 검색엔진으로 사용이 되고 있다. (로그 저장 및 검색)
LogStash : 로그 수집 엔진
Kibana : 로그 시각화 및 관리

앞글자를 따서 E.L.K 스택 혹은 ElasticStack 이라고 부른다

물론 세 모듈은 각자의 독립된 기술이기 때문에 필요에 따라 일부만 써도 된다.

하지만 서로 호환이 잘되고 합쳤을 때 시너지가 좋기 때문에 같이 구축된다.

세 기술을 같이 쓰기 때문에 Stack 이라고 부르며, 일반적으로 구성되는 형태는 다음과 같다.

Data Processing (Logstash)
- 서버 내의 로그, 웹, 메트릭 등 다양한 소스에서 데이터를 수집하여 입력
- 데이터 변환 및 구조 구축
- 데이터 출력 및 송신
Storage (Elasticsearch)
- 데이터 저장
- 데이터 분석
- 데이터 관리
Visualize (Kibana)
- Dashboard를 통한 데이터 탐색
- 팀원들과 공유 및 협업하는데 사용 가능
- 엑세스 제어 (Access Control) 사용 가능

2. ElasticStack 의 장점

가격

ELK는 Elastic이라는 회사에서 제공하는 오픈소스이다.

별도로 AWS EC2 등의 인스턴스에 사용한다면 관련 비용이 들어가긴 하겠지만,
ELK 자체로만은 무료이기 때문에 다른 시스템에 비해 가격적인 측면에서 장점을 가진다.

접근성 & 사용성

ELK는 오픈소스를 내려받아 설치하는 것으로 구축이 완료된다.
그 외의 별도의 추가적인 개발 과정이 필요없기 때문에 접근성이 뛰어나다.
또 그 사용이 다른 유사 시스템들에 비해 쉬운 편이다.

속도

ELK중 데이터 보관 및 분석 역할을 담당하는 Elasticsearch는 거의 실시간 (Real-Time)에 가깝게 데이터를 처리할 수 있다.

유연성

ELK는 각자의 기능을 담당하는 세가지의 모듈은 붙여서 만든다. 그렇기 때문에 그 기능만 담당할 수 있다면 얼마든지 모듈을 유연하게 변경할 수 있다.
예를 들어서, 굳이 Logstash를 쓰지 않아도 데이터 수집 역할만 할 수 있다면 경우에 따라 다른걸로 대체가 가능하다.

다음 포스팅에서 Elastic Search 와 Logstash Kibana 실습을 직접 해보는 글을 포스팅 해보겠다.

이동명

Web Developer

이전 포스트

플레이데이터 백엔드 부트캠프 6월 회고록

다음 포스트