[Elasticsearch] 개념과 용어 정리

Elasticsearch 개요

• 오픈 소스 분산 검색 엔진이자 분석 엔진으로, Apache Lucene 기반으로 만들어짐
• 대용량 데이터를 실시간으로 처리하고 분석하는데 유용
• 다양한 형태의 데이터를 색인할 수 있으며 복잡한 검색 쿼리에 대해서도 빠르고 정확한 응답 제공
• 특히 로그 및 이벤트 데이터, 텍스트 기반 데이터, 시계열 데이터 등을 처리하는 데 유용

 

Opensearch

• AWS가 주도하여 개발한 오픈 소스 검색 및 분석 엔진
• Elasticsearch와 Kibana의 오픈 소스 분기를 기반으로 하며, 검색, 로그 분석, 시각화 및 모니터링을 위한 다양한 기능을 제공하기 때문에 기본적으로 Elasticsearch에 대한 개념을 알아야 쉽게 사용할 수 있음
• 사용자가 자유롭게 사용할 수 있고 개설할 수 있는 환경 제공
• 맞춤형 검색 솔루션을 구축할 수 있는 유연성을 지님
• 사용자의 요구사항에 따라 다양한 방식의 검색엔진을 선택하고 활용 가능

 

Elasticsearch를 사용해야 하는 이유

• Apache Lucene 기반의 검색엔진으로서 복잡한 데이터 셋에서 정보를 신속하고 정확하게 검색 가능
• APM, 로그, 인프라 메트릭 데이터 분석부터 시각화 및 모니터링까지 다양한 요구사항을 충족
• 다양한 형태의 데이터를 색인할 수 있으며 개발자를 위한 REST API 및 다양한 언어 SDK 제공
• 분산시스템으로서 샤드 개념을 통한 빠른 복구, 데이터 rollup 및 인덱스 수명 주기 관리가 가능하여 효율적으로 데이터를 관리할 수 있음

 

Elastic Stack

• Elasticsearch
• Logstash
• Kibana
• Beats

 

1. Elasticsearch

• 앞서 설명했으므로 생략

 

1.1 Elasticsearch 특징

• Schemaless 방식으로 다양한 JSON 데이터 저장 및 관리
• 다양한 검색 옵션과 더불어 한글을 포함한 여러 언어 지원
• 다양한 검색 옵션 및 필터링을 통해 정교한 검색 결과 제공
• 다양한 검색 쿼리 유형 지원
• 다양한 클라이언트 SDK 제공
• 신속한 데이터 색인 및 검색, 특정 필드의 실시간 업데이트가 가능하여 NRT(Near Real Time) 즉 준실시간성 검색 지원
• 오토스케일링을 지원하여 확장성이 높고 데이터 백업 및 복원 기능을 통해 데이터를 안전하게 관리

 

2. Logstash

• 데이터 수집 및 처리 파이프라인을 담당
• 다양한 소스에서 데이터를 수집하고 실시간으로 변환하여 Elasticsearch로 전송
• 플러그인 기반 아키텍처로 확장성이 높음

 

2.1 Logstash 특징

• 로그 파일 등 다양한 소스의 데이터를 실시간 수집
• 수집한 데이터를 필터, 매핑, 정규식 등을 통해 변환하여 유연하게 저장 가능
• 트래픽이 높은 경우 다수의 노드를 추가하여 분산 처리 가능하여 확장성이 높음
• 강력한 데이터 처리 파이프라인으로서 input, filter, output의 3가지 구성요소를 통해 데이터 수집, 가공, 전송
• 다양한 입출력 플러그인 제공
• 데이터 분석, 추출, 필드 추가/수정/제거 및 형식 변환 등을 위한 필터 플러그인 제공
• 대규모 실시간 데이터 처리 환경에서 높은 성능과 효율성 유지

 

3. Kibana

• Elasticsearch에 저장된 데이터를 시각화 기능 제공
• 데이터를 통한 그래프, 차트 등 대시보드 구성 가능
• Dev Tools에서 검색 쿼리를 작성하고 검색해 볼 수 있는 UI 제공

 

3.1 Kibana 특징

• 다양한 시각화 도구와 차트, 그래프 제공
• 다양한 시각화 형식 지원
• 직관적인 인터페이스를 제공하여 검색엔진에 저장된 데이터를 쉽게 검색하고 필터링 가능
• 생성한 대시보드 URL을 통해 공유하거나 PDF 형식으로 내보내어 팀 간 협업 및 보고서 작성에 활용 가능
• 실시간 모니터링 기능 제공
• 사용자 정의 플러그인과 템플릿을 지원하여 기능의 확장성을 높여주며 커스터마이징 가능

 

4. Beats

• 경량 데이터 수집기
• 다양한 모듈로 구성되어 특정 데이터 소스에 따라 데이터를 수집하는 역할을 다르게 사용
• 시스템 로그, 메트릭, 네트워크 데이터 등 다양한 데이터를 수집하여 Logstash나 Elasticsearch로 전송
• Filebeat, Metricbeat, Packetbeat 등 다양한 종류의 Beats 존재
  • 로그 파일 수집(Filebeat)
  • 시스템 메트릭 수집(Metricbeat)
  • 네트워크 트래픽 모니터링(Packetbeat)

 

4.1 Beats 특징

• 메모리와 CP 사용량이 적어 간편하게 배포 및 운영 가능
• 다양한 데이터 수집 플러그인 제공
• 수집한 데이터를 Elasticsearch나 Logstash로 실시간을 전송하며 비동기 전송 방식을 채택하여 지연 없이 처리
• SSL/TLS 프로토콜을 사용한 데이터 통신 암호화와 인증, 접근 제어를 통해 데이터 무결성 및 보안 강화
• 확장 가능한 플러그인 제공
• 중앙화된 데이터 관리를 지원하여 다양한 데이터소스로부터 실시간으로 데이터를 수집하고 Elasticsearch나 Logstash와 같은 저장소로 전송

 

RDB vs Elasticsearch 용어 비교

 

RDB	Elasticsearch
테이블	인덱스
row	문서 (document)
column	필드
물리 파티션	샤드
스키마	매핑

 

Elasticsearch Cluster

• 하나 이상의 노드로 구성하여 노드들이 협력하여 데이터 저장, 검색 및 분석 작업을 수행
• 앞서 언급했다시피 각 노드는 고유한 이름, IP를 통해 식별하며 클러스터에 가입하여 클러스터 전반적인 상태를 관리, 데이터 관련 작업을 처리
• 다양한 룰을 통해 각 노드에 특정 기능과 권한 할당
• 데이터의 안전성과 지속적인 가용성을 보장하기 위해 가용 영역에 걸쳐 노드를 분산 배치
• 대용량 데이터를 효율적으로 처리할 수 있으며 확장성이 높아 필요에 따라 확장이 용이
• 싱글 노드 클러스터는 테스트 혹은 로컬 개발에만 적합
• Prod 환경에서는 앞서 언급했다시피 마스터 노드 3개, 데이터 노드 3개로 구성하는 것을 권장

 

인덱스의 구성

 

1. 인덱스

• 도큐먼트를 저장하는 논리적 단위로 관계형 데이터베이스의 테이블과 유사한 개념
• 하나의 인덱스에 다수의 도큐먼트가 포함되는 구조인데 동일한 인덱스에 있는 도큐먼트는 동일한 스키마를 가짐
• 모든 도큐먼트는 반드시 하나의 인덱스에 포함되어야 함
• 인덱스명에는 영어 소문자를 비롯해, [\, /, *, ?, ", <, >, |, #, 공백, 쉼표] 등을 제외한 특수문자를 사용할 수 있으며 255 바이트를 넘을 수 없음

 

2. 도큐먼트

• 인덱스 내 JSON 형식의 데이터 기본 단위로 JSON 형태
• 하나의 도큐먼트는 여러 필드와 값을 갖음

 

3. 필드와 값 (field & value)

• 각 문서는 데이터 속성이나 특성을 나타내는 필드로 구성

 

4. Term

• 필드 내 데이터의 단위
• Elasticsearch에 색인되고 검색할 단어 저장

 

 

노드의 개념

• Elasticsearch는 데이터 처리를 담당하는 하나 이상의 노드로 구성된 클러스터로 운영
• 노드는 Elasticsearch 클러스터를 구성하는 개별 서버 인스턴스
• 데이터 저장, 검색, 분석 등을 포함한 다양한 작업 처리
• 각 노드는 고유한 이름과 IP, 포트와 같은 식별 정보를 가지고 클러스터 내에서 협력
• 마스터 노드, 데이터 노드, 코디네이팅 노드 등과 같이 다양한 노드가 존재하며 각각의 특정 역할 수행
• 통상적으로 마스터 노드 3대, 데이터 노드 3대로 구성하며 노드 구성 방식에 따라 클러스터의 성능과 안전성에 영향을 미침
• 설정 파일인 elasticsearch.yml 파일을 통해 구성할 수 있으며 각각의 노드는 마스터 노드의 역할도 가질 수 있음

 

1. 마스터 노드

• Elasticsearch 클러스터의 핵심 관리자로 클러스터의 안정적인 운영을 책임짐
• 클러스터 내 인덱스 생성 및 삭제, 노드 관리, 샤드 분배 등 중요한 의사 결정을 내림
• 클러스터 상태를 모니터링하며 필요한 경우 마스터 노드 역할을 수행할 수 있는 노드로의 전환을 관리
• 클러스터의 연속적인 서비스 제공을 위해 적어도 한 개 이상의 마스터 노드 필요
  • Prod 환경에서는 세 개 이상의 마스터 노드를 두어 장애 발생 시 안전성을 보장하는 것을 권장

 

1.1 마스터 노드 선출 과정

• 마스터 노드는 클러스터의 안전성 유지와 새로운 마스터 노드 선출 과정을 관리
• 마스터 노드 장애 발생 시 다른 마스터 후보 노드가 새로운 마스터 노드로 선출될 수 있도록 마스터 노드 선출 프로세스 진행
• Prod 환경에서는 마스터 노드 선출을 위해 마스터 후보 노드(Master-Eligible Node)를 최소 세 대 이상 유지하는 것을 권장
• Voting-only 마스터 후보 노드는 마스터 노드의 선출 과정에만 참여하며 실제 마스터 노드 역할을 수행하지 않음

 

2. 데이터 노드

• Elasticsearch 클러스터에서 데이터를 실제로 저장하고 관리하는 역할
• 색인, 검색, 집계 등을 담당하며 CPU, I/O, 메모리와 같은 하드웨어 리소스를 많이 소모
• 클러스터 안전성을 위해 데이터 노드는 적절한 수의 노드를 유지하고 장애 발생 시 적절한 샤드 운영 필요
• 데이터 노드 구성은 성능 최적화와 클러스터의 안전성, 비용적인 측면에서 직접적인 영향을 끼침
• 데이터 노드의 종류는 여러 가지가 있으며 데이터의 특성과 접근 패턴에 맞게 조정
  • data_content: 지속적으로 유지되어야 하는 데이터를 저장하며 주로 읽기 작업이 많은 검색 및 집계 쿼리에 사용
  • data_hot: 최신 시계열 데이터를 바르게 읽고 쓰는데 필요하며 고성능 SSD 같은 저장 장치를 사용하여 최근 데이터 접근
  • data_warm: 쿼리 빈도가 낮은 데이터를 보관하며 비용 효율적인 HDD를 사용하여 몇 주 전 데이터를 저장
  • data_cold: 빠르게 검색할 필요가 없는 오래된 데이터를 보관하며 필요에 따라 과거 로그와 같은 데이터를 이동시켜 저장 공간을 효율적으로 사용 가능
  • data_frozen: 거의 사용되지 않거나 아카이브 목적의 데이터를 저장하며, 데이터 보존이 주된 목적일 때 사용하며 S3 등에 보관

 

3. Ingest 노드

• 데이터 수집, 가공 및 색인 전달 과정을 관리하는 노드
• 데이터를 전처리하여 다양한 소스의 데이터를 효과적으로 처리하고 필터링, 파싱, 변환 등 데이터를 최적화 형식으로 가공
• 로그, 센서 데이터, 웹 크롤링 결과 등 다양한 데이터 유형을 처리할 수 있으며 가공된 데이터를 데이터 노드에 색인하여 저장
• 데이터 처리 과정에서 리소스 사용이 높기 때문에 ingest 노드와 데이터 노드들을 분리하여 운영하는 것을 권장
• ingest 노드는 데이터 노드와 함께 구성되어 데이터 처리 및 색인 프로세스를 효율적으로 수행

 

4. Coordinating 노드

• 클러스터의 요청을 라우팅 하고 상태를 관리하는 역할
• 대규모 클러스터에서는 별도로 분리하여 운영
• 소규모 클러스터에서는 마스터 혹은 데이터 노드가 Coordinating 노드 역할 수행

 

5. 머신러닝 노드

• 머신러닝 기능을 제공하며 데이터 학습, 이상 탐지, 예측 등 작업을 처리
• 유료 라이선스 구입 시 사용 가능

 

6. Remote Cluster Client

• 다른 클러스터와 연결을 관리하고 여러 클러스터 간의 데이터 검색이 가능하도록 담당

 

7. Transform 노드

• 인덱스 간 데이터를 자동으로 복사하거나 변환하는 역할을 수행

 

노드 종류별 요구되는 시스템 리소스

 

	저장소	메모리	CPU
마스터 노드	사용량 낮음	사용량 낮음	사용량 낮음
데이터 노드	사용량 매우 높음	사용량 높음	사용량 높음
Ingesting 노드	샤용량 낮음	사용량 보통	사용량 높음
Coordinating 노드	사용량 낮음	사용량 보통	사용량 보통

 

* 처음부터 오버 스펙으로 운영하는 것은 비용적으로 부담이 될 수 있기 때문에 위 표를 고려하여 최소한의 사양으로 시작해 모니터링하면서 scale-out, scale-up 고려하는 것을 권장

• scale-up: 하드웨어 업그레이드를 통한 단일 노드 성능 향상
• scale-out: 클러스터에 추가 노드를 포함하여 확장

 

데이터 노드 샤드

 

1. Primary Shard vs Replica Shard

 

1.1 Primary Shard

• 데이터 원본을 관리
• 색인 작업 담당
• 클러스터 핵심 데이터 저장
• 인덱스 생성 시 한 번만 설정 가능

 

1.2 Replica Shard

• 데이터 복사본 관리
• 읽기 요청 부하 분산
• 데이터 손상 방지
• Primary Shard 장애 시 Primary Shard로 승격 가능
• Primary Shard와 달리 동적으로 추가가 가능하여 확장성이 높음

 

2. 인덱스 생성 시 샤드 개수 설정

 

2.1 Primary Shard 설정

• 데이터 병렬 처리 및 성능에 중요
• 인덱스 생성 시 결정되며 이후 변경 불가
• 데이터 양 및 쿼리 부하를 고려하여 설정 필요

 

2.2 노드 수와 샤드 개수

• 노드 수에 따라 샤드 개수 조정
• 향후 클러스터 확장 가능성을 고려하여 샤드 개수 설정하는 것이 중요
• 노드 부담과 관리 오버헤드 고려 필요
  • 너무 많은 샤드는 노드에 부담을 주고 관리 오버헤드를 증가시킬 수 있음
  • 노드와 샤드의 수를 균형 있게 설정해야 클러스터 안전성 유지 가능

 

2.3 Replica Shard와 성능

• 노드 장애 시 데이터 보호하는 역할
• 읽기 작업을 분산시켜 전체 클러스터의 성능 향상
• Replica Shard가 많아지면 쓰기 작업 시 오버헤드가 증가할 수 있으므로 주의 필요
  
  • 레플리카 샤드의 수가 많아질수록 이 정보는 더욱 방대해지며, 클러스터의 상태를 관리하는 데 추가적인 오버헤드가 발생

 

2.4 Replica Shard 설정

• 데이터 가용성 및 내결함성 증대
• 클러스터 운영 중 조정 가능
• Primary Shard 당 최소 1개 설정하는 것을 권장
• Replica Shard가 Primary Shard와 다른 노드에 배치되도록 설정하여 가용성을 높일 수 있음

 

2.5 인덱싱 작업과 병렬 처리

• Primary Shard 수 증가는 병렬 처리 시 향상
• 관리 오버헤드와 적절한 균형 필요

 

2.6 클러스터 확장/축소와 Replica 조정

• 노드 추가 시 Replica 수 동적 조정
• 데이터 검색 안전성 확보
• 클러스터 크기 변화에 따라 Replica Shard의 수를 유연하게 조정하여 최적의 성능과 가용성 유지하는 것을 권장

 

3. 샤드 내부의 불변성

 

3.1 데이터 불변성과 시스템 안전성

• 데이터 한번 색인 후 변경 불가능 (불변성)
• 장애 발생 시 신속한 복구 가능
  • 불변 데이터 구조로 예상치 못한 시스템 중단에도 데이터 보호

 

3.2 검색 성능의 최적화

• 불변 역색인으로 높은 읽기 성능 제공
• 검색 최적화를 위한 캐시 및 다양한 알고리즘 적용

 

3.3 데이터 변경과 샤드 관리

• 새로운 데이터 추가는 독립적으로 처리되어 복잡한 Lock 알고리즘 불필요
• 샤드 내 데이터는 장애 발생 시에도 무결한 상태 유지하여 불변성 유지
• 데이터 변경 필요시 새로운 색인 추가로 반영하며 기존 데이터는 시간 경과에 따라 자동제거
  • 가장 최근에 추가된 데이터가 검색될 확률이 높다고 가정

 

4. 세그먼트와 세그먼트 병합

• 세그먼트는 인덱스 내의 데이터를 물리적으로 저장하는 기본 단위
• 각 세그먼트는 독립적인 역색인(inverted index)을 가지고 있으며 역색인에 대해서는 추후 게시글에서 다룰 예정

 

4.1 세그먼트 역할과 중요성

• 시스템이 더 많은 데이터를 처리할 때 세그먼트 생성 및 재분배로 부하 분산
• 각 세그먼트는 키워드 문서 관계 매핑

 

4.2 세그먼트 병합의 과정과 이점

• 디스크 공간 절약 및 검색 성능 향상을 목적으로 병합을 통해 작은 세그먼트를 큰 세그먼트로 통합하며 시스템 부하, 검색 성능 저하가 우려되기 때문에 백그라운드에서 실행됨
• 정기적인 새로운 세그먼트 생성으로 실시간 데이터 색인 지원
• 삭제된 문서는 병합 시 제거하여 데이터 무결성 유지

 

4.3 세그먼트 병합의 장점

• 쓰기 성능 개선 및 유지 관리 용이성
• 장애 복구 시간 단축
• 디스크 공간 절약

 

5. NRT (Near Real Time, 준실시간성)

• Elasticsearch에서 문서가 색인된 후 거의 즉시 검색 가능
• 새로 색인된 데이터가 신속하게 검색 결과에 반영되는 과정

 

5.1 NRT 검색의 중요성과 사용자 경험 개선

• 최신 데이터에 대한 실시간 검색으로 사용자 경험 향상
• 데이터 분석, 로그 모니터링, 대시보드 등에 필수적인 기능
• 사용자들이 최신 정보를 바탕으로 즉각적인 의사 결정 가능

 

5.2 NRT 기능의 기술적 장점

• 시스템 부하 감소 및 효율성 증가
• 실시간 모니터링과 경고 시스템에 중요한 역할 수행
• 데이터 무결성 및 비즈니스 연속성 보장

 

6. Refresh vs Flush

 

6.1 Refresh

• 새로 색인된 데이터를 인메모리 세그먼트로 이동시키는 역할
• 일반적으로 1초마다 자동 실행
• NRT 검색 기능을 지원하여 최신 문서를 검색 결과에 빠르게 포함
• 디스크에 데이터를 저장하지 않기 때문에 데이터 영속성과는 무관함

 

6.2 Flush

• 메모리 버퍼의 데이터를 디스크에 영구적으로 저장하는 역할
• 시스템 재시작/충돌 후 데이터 일관성 유지하기 때문에 데이터 영속성 제공 (Refresh는 제공하지 않는 기능)
• 데이터 커밋 후 트랜잭션 로그 비움
• 장기적 데이터 보존 중심

 

7. Translog

• 사용자가 색인화 또는 문서 업데이트 시 Translog에 기록
• 시스템 장애 발생 시 마지막 커밋 이후 모든 변경 사항을 복구
  • 실시간으로 인메모리에 임시 저장 후 정해진 시간 간격으로 디스크에 반영

 

• 노드 간 데이터 동기화 시 일관성 유지하는데 사용
  • 노드 간의 동기화 과정에서 발생할 수 있는 데이터 불일치 문제 방지

 

• Refresh를 통해 해당 기간 동안 발생한 작업을 추적하여 NRT 검색 가능하도록 지원
• 장기적으로 수행되는 트랜스 로그의 병합과 정리는 시스템 효율성 유지 및 저장 공간 절약에 유리

 

참고

• 패스트 캠퍼스 -  고성능 검색 엔진 구축으로 한 번에 끝내는 Elasticsearch
• 엘라스틱 개발부터 운영까지 (김준영, 정상운 저)