[Etc] Elasticsearch를 통해 검색 시간 단축하기 (1)

1. Elasticsearch란?

Elasticsearch는 Apache Lucene(아파치 루씬) 기반의 Java 오픈 소스 분산 검색 엔진입니다. Elasticsearch를 통해 루씬 라이브러리(Java에서 개발한 정보 검색용 라이브러리)를 단독으로 사용할 수 있으며, 방대한 양의 데이터를 신속하게(거의 실시간) 저장, 검색, 분석을 수행할 수 있습니다. Elasticsearch는 검색을 위해 단독으로 사용하기도 하며, ELK(Elasticsearch/Logstash/Kibana) 스택으로 사용되기도 합니다. ELK 스택은 다음과 같습니다.

• Logstash : 다양한 소스(DB, csv 파일 등)의 로그 또는 트랜잭션 데이터를 수집, 집계, 파싱 하여 Elasticsearch로 전달
• Elasticsearch : Logstash로부터 받은 데이터를 검색 및 집계하여 필요한 정보를 획득
• Kibana : Elasticsearch의 빠른 검색을 통해 데이터를 시각화 및 모니터링

주로 ELK는 로드밸런싱되어 있는 WAS의 흩어져 있는 로그를 한 곳으로 모으고, 원하는 데이터를 빠르게 검색한 뒤 시각화하여 모니터링하기 위해 사용합니다.

 

2. Elasticsearch vs RDB

 

• RDB는 정규화된 스키마에 따라 데이터를 구조화하지만, Elasticsearch는 JSON 문서 형태로 비정형 데이터도 저장하고 인덱싱할 수 있습니다.
• RDB는 Row를 기반으로 데이터를 저장하지만, Elasticsearch는 단어를 기반으로 데이터를 저장합니다.
• Elasticsearch는 마치 NoSQL의 key-value DB와 같이 저장됩니다. 그렇기 때문에 Elasticsearch는 수정과 삭제가 많은 경우에는 많은 리소스가 소비될 수 있지만 검색 속도는 빠르다는 장점이 있습니다.

💡 주의할점

위에서 인덱스는 RDB의 데이터베이스고, 타입은 RDB의 테이블이라고 했습니다. 하나의 데이터베이스에 여러 테이블을 가지듯이, Elasticsearch도 하나의 인덱스에 여러 타입을 가질 수 있습니다. 하지만 Elasticsearch 7.0 이상부터는 하나의 인덱스에는 하나의 타입만 가질 수 있도록 변경되었습니다. RDB의 테이블은 완전 개별적인 관계이기 때문에 각 테이블에 이름이 같은 컬럼이 있어도 문제가 없습니다.
그런데, Elasticsearch에서 한 인덱스 내의 타입들은 내부적으로 같은 Lucene 필드를 사용합니다. 따라서 타입이 다를지라도 동일한 이름을 가진 필드는 독립적이지 않으므로 여러 가지 문제가 발생할 수 있으므로 하나의 인덱스에는 하나의 타입만 갖도록 수정되었습니다.

 

3. Elasticsearch 구조

 

a. Cluster

클러스터란 Elasticsearch에서 가장 큰 시스템 단위를 의미하며, 최소 하나 이상의 노드로 이루어진 노드의 집합입니다. 서로 다른 클러스터는 데이터 접근, 교환을 할 수 없는 독립적인 시스템으로 유지되며, 여러 대의 서버가 하나의 클러스터를 구성할 수 있고 한 서버에 여러 개의 클러스터가 존재할 수 있습니다.

 

b. Node

노드는 Elasticsearch의 기본 동작 단위로, 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여합니다. 노드는 역할에 따라 Master-eligible, Data, Ingest, Tribe 노드로 구분할 수 있습니다.

 

 

b-1. Master-eligible Node

 

클러스터를 제어하는 마스터로 선택할 수 있는 노드입니다. 마스터 노드가 하는 역할은 다음과 같습니다.

• 인덱스 생성, 삭제
• 클러스터 노드의 추적, 관리
• 데이터 입력 시 할당할 샤드 선택

 

b-2. Data Node

 

데이터(Document)가 저장되는 노드이며, 데이터가 분산 저장되는 물리적 공간인 샤드가 배치되는 노드입니다. CRUD, 색인, 검색, 통계 등의 데이터 작업을 수행하므로 많은 리소스(CPU, 메모리 등)를 필요로 합니다. 따라서 모니터링 작업을 해야 하고, 마스터 노드와는 분리해야 합니다.

 

 

b-3. Ingest Node

 

데이터를 변환하는 등 사전 처리 파이프라인을 실행하는 역할을 합니다.

 

 

b-4. Coordination Only Node

 

사용자의 요청을 받고 라운드 로빈 방식으로 분산을 하는 노드입니다. 클러스터에 관련된 것은 마스터로 넘기고, 데이터와 관련된 것은 데이터 노드로 넘깁니다. 로드밸런싱의 역할을 하는 노드라고 생각하시면 됩니다.

 

c. Index / Shard / Replication

• Index : 앞서 이야기했듯이, RDMS에서 데이터베이스와 대응하는 개념입니다.
• shard (샤드) 
  • 인덱스 내부에는 색인된 데이터들이 존재하는데, 이 데이터들은 하나로 뭉쳐서 존재하지 않고 물리적 공간에 여러 부분으로 나뉘어 존재합니다. 이러한 부분을 샤드라고 합니다. 즉, 스케일 아웃을 위해 하나의 인덱스를 여러 샤드로 쪼갰다고 생각하면 됩니다.
  • 샤드는 프라이머리 샤드와 레플리카 샤드로 나뉩니다.
    • 프라이머리 샤드 : 데이터의 원본입니다. Elasticsearch에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청하게 되고, 해당 내용은 레플리카 샤드로 복제됩니다. 샤드의 개수만큼 cpu의 스레드를 사용하기 때문에 샤드의 개수가 많아질수록 리소스를 많이 잡아먹습니다. 이렇기에 검색 성능 향상을 위해 클러스터의 샤드 개수를 조정하기도 합니다. 
      • 레플리카 샤드(복제). : 프라이머리 샤드의 복제본입니다. 기존 원본 데이터가 무너졌을 때 그 대신 사용하면서 장애를 극복하는 역할을 합니다. 기본적으로 원본인 프라이머리 샤드와 동일한 노드에 배정하지 않습니다.

d. Segement

세그먼트란 Elasticsearch에서 문서의 빠른 검색을 위해 설계된 자료 구조이며, 샤드의 데이터를 가지고 있는 물리적인 파일입니다. 각 샤드는 다수의 세그먼트로 구성되어 있으므로 검색 요청을 분산 처리하여 훨씬 효율적인 검색이 가능합니다.

 

샤드에서 검색 시, 먼저 각 세그먼트를 검색하여 결과를 조합한 후 최종 결과를 해당 샤드의 결과로 반환하게 됩니다. 이때 세그먼트는 내부에 색인된 데이터가 역색인 구주로 저장되어 있으므로 검색 속도가 매우 빠릅니다.

 

그런데 매 요청마다 새로운 세그먼트를 만들어 주면 엄청나게 많은 세그먼트가 생성될 것이고, 이로 인해 다른 요청에 지장이 생길 수 있습니다. 이를 방지하기 위해 인메모리 버퍼를 사용합니다. 인메모리 버퍼에 쌓인 내용을 일정 시간이 지나거나 버퍼가 가득 차면 flush를 취하고, flush 작업이 수행되면 시스템 캐시에 세그먼트가 생성됩니다. 이 시점부터 데이터가 비로소 검색이 가능해집니다. 하지만 이 상태는 세그먼트가 시스템 캐시에 저장된 상태이지, 디스크에 저장된 상태는 아닙니다.

 

디스크에 쓰이는 작업 역시 일정 시간이 지나면 commit을 통해서 물리적인 디스크에 세그먼트를 저장해 주고 저장된 세그먼트는 시간이 지날수록 하나로 병합하는 과정을 수행합니다. 병합을 통해 세그먼트를 하나로 줄여 주면, 검색할 세그먼트의 개수가 줄어들기 때문에 검색 성능이 향상됩니다.

 

 

 

4. Elasticsearch 장/단점

a. 장점

• Schema less
  • JSON 문서를 통해 데이터 검색을 수행하므로 스키마 개념이 없습니다.
  • 로그 데이터처럼 비구조화된 데이터는 스키마가 다이나믹하게 변할 수 있기 때문에 JSON 구조가 적합합니다.
• 저장
  • RDB는 트랜잭션 처리와 데이터 일관성 유지에 중점을 두고 설계되었기 때문에 무수히 생성되는 로그 데이터를 실시간으로 저장하는 것은 한계가 있을 수 있습니다.
  • 대부분 RDBMS는 단일 노드에서 실행되지만 Elasticsearch는 처음부터 분산 시스템으로 설계되었습니다.
  • 그렇기 때문에 데이터를 여러 노드에 분산 저장하고 처리 및 새로운 노드를 추가(수평 확장(scale out)) 할 수 있고, 스키마리스 방식이므로, 비구조화된 대량 데이터도 유연하게 저장할 수 있습니다.
• 검색
  • 로그 데이터는 구조화되어 있지 않고 비구조화된 텍스트로 이루어져 있습니다.
  • 비구조화된 많은 로그 데이테들을 RDB에서 조회하려면 복잡한 텍스트를 검색하기 힘들뿐더러, 인덱싱과 같은 추가 작업이 요구되어 시스템 부하가 증가할 수 있습니다.
  • 반면에 Elasticsearch는 전체 텍스트 검색에 최적화된 엔진(Luence 기반)을 사용해 대용량 데이터에서도 빠르게 정보를 찾을 수 있습니다. 또한 모든 데이터를 역색인 구조로 저장해 가공된 텍스트를 검색합니다.
  • 거의 실시간 검색으로 사용할 수 있기 때문에 보안 분석, 인프라 모니터링 같은 사용 사례에 적합합니다.
• 데이터 구조 유연성
  • RDB에서는 스키마 변경이 필요한 경우에는 DDL 작업이 필요하며 이 작업은 리소스 소모가 크고 복잡합니다.
  • 반면에 Elasticsearch는 JSON 형식의 문서 기반 모델을 사용해 스키마 변경 없이도 다양한 형태의 데이터를 유연하게 저장할 수 있습니다.
• 가용성
  • 자동 복제(replication)와 샤딩(sharding) 기능으로 인해, 하나 또는 여러 개의 노드가 실패해도 서비스 중단 없이 데이터 저장 및 검색 작업을 계속할 수 있습니다.
• Restful 사용
  • 데이터 CRUD 작업을 HTTP Restful API를 통해 수행합니다.
  • SELECT = GET
  • INSERT = PUT
  • UPDATE = POST
  • DELETE = DELETE

b. 단점

• 완벽한 실시간 X
  • 빠르지만 완전한 실시간은 아닙니다. Near real-time입니다.
  • Elasticsearch는 데이터 저장 시점에 해당 데이터를 인덱싱 합니다.
• 트랜잭션과 롤백 기능 X
  • 전체적인 클러스터의 성능 향상을 위해서 시스템적으로 비용 소모가 큰 롤백과 트랜잭션을 지원하지 않습니다.
  • 즉, 트랜잭션과 무결성이 중요한 데이터의 저장소로 사용하기에 적합하지 않습니다.
  • Elasticsearch가 DB의 기능도 하지만 메인 데이터베이스로 단독 사용하는 것은 권장되지 않습니다.
  • 엄격한 데이터 요구사항이 있는 경우에는 RDB가 더 적합합니다.
• 데이터 삭제 및 수저의 비효율성
  • Elasticsearch는 실시간 검색과 분석을 위해 설계되었습니다. 그렇기 때문에 데이터 삭제나 수정 작업은 상대적으로 비효율적입니다.
  • Elasticsearch에서의 업데이트는 기존 문서를 삭제하고 다시 삽입하는 방식입니다.