Skip to content

ElasticSearch ‐ Managing Document (1)

woojin edited this page Aug 1, 2026 · 1 revision

Elasticsearch란

  • 오픈소스 검색·분석 엔진이다. 수평 확장성(horizontal scalability), 안정성, 운영 편의성을 목표로 설계되었다.
  • Apache Lucene 위에 구축되었고, Elastic Stack(Logstash, Kibana 포함)의 일부다.

핵심 특성 4가지

특성 내용
분산 처리(Distributed) 클러스터의 가용 노드들에 데이터와 쿼리 부하를 자동 분산한다. 대용량 데이터를 준실시간으로 처리한다
전문 검색(Full-Text Search) 고급 전문 검색이 본질이다. HTTP 웹 인터페이스와 스키마 없는 JSON 문서를 사용한다
확장성(Scalability) 수백~수천 대 서버로 스케일 아웃하며, 페타바이트급 정형/비정형 데이터를 처리한다
유연성(Flexibility) 다양한 소스의 이기종 데이터 타입을 색인하고 복잡한 검색을 수행한다

기본 데이터 모델: Document & Field

  • Document는 색인 가능한 정보의 기본 단위이며, JSON으로 표현한다.
  • Field는 Elasticsearch에서 가장 작은 데이터 단위로, 문서 안의 key-value 쌍이다.
{
  "name": "John Doe",     ← Field
  "age": 30,
  "email": "john.doe@example.com"
}

↑ 이 JSON 객체 전체가 하나의 Document다

주요 활용 사례

  • Enterprise Search — 사내 전체 디지털 콘텐츠를 색인해 웹사이트나 내부망에 정교한 검색을 제공한다.
  • Logging & Log Analysis — Logstash, Kibana와 함께 로그를 분석한다. IT 운영·보안·성능 모니터링에 필요한 인사이트를 얻는다.
  • SIEM(보안 정보·이벤트 관리) — 보안 데이터를 실시간으로 분석·시각화해 위협 탐지와 컴플라이언스 관리를 돕는다.
  • Data Analysis — 빅데이터 분석에 활용한다. 대용량 데이터를 빠르고 다양한 방식으로 탐색한다.
  • 개인화·추천 — 이커머스에서 사용자 행동과 인터랙션을 분석해 맞춤 상품 추천과 동적 콘텐츠를 제공한다.

데이터 분산과 저장

  • Indexing(색인)
    • 데이터는 index 단위로 구성되며, index는 데이터베이스에 해당하는 개념이다.
    • index에 저장되는 문서는 JSON 형식이다.
    • 문서가 추가되면 Elasticsearch가 검색에 최적화된 형태로 변환해 색인한다.
  • Sharding(샤딩)
    • 각 index는 여러 shard로 분할할 수 있으며, 이를 통해 클러스터의 여러 노드에 분산 배치된다.
    • 고가용성과 성능 확장성을 확보한다. 대용량 데이터셋과 높은 쿼리 부하를 처리하는 핵심이다.
  • Replicas(복제본)
    • primary shard의 복사본인 replica shard를 생성할 수 있다.
    • 하드웨어 장애에 대비한 데이터 이중화를 제공하고, 어느 replica에서도 검색이 가능하므로 쿼리 처리량이 증가한다.

검색 메커니즘

  • Query Processing(쿼리 처리)
    • 쿼리가 들어오면 파싱한 뒤 Lucene 인덱스 검색에 적합한 형태로 변환한다.
    • 변환된 쿼리를 관련된 모든 shard(primary 또는 replica)에 병렬로 실행한다.
  • Relevance Scoring(연관도 점수)
    • TF-IDF(Term Frequency–Inverse Document Frequency), BM25(Best Matching 25) 등의 알고리즘으로 문서가 쿼리에 얼마나 부합하는지 점수화한다.
    • 이 점수를 기준으로 검색 결과 랭킹을 결정한다.

실시간 처리

  • Near Real-Time(NRT) 검색
    • 데이터 색인과 조회가 거의 동시에 이루어진다.
    • 인메모리 버퍼에 들어오는 문서를 모으고, 이 버퍼를 주기적으로 flush해 인덱스의 새 세그먼트를 생성하는 방식으로 구현한다.

클러스터 관리

  • Nodes & Cluster
    • 클러스터는 하나 이상의 노드(서버) 집합이다. 전체 데이터를 보유하고 모든 노드에 걸쳐 색인·검색 기능을 제공한다.
    • 클러스터는 고유 이름으로 식별하며 기본값은 elasticsearch다.
  • Master Node
    • 클러스터의 health와 metadata를 관리한다.
    • 새 문서 추가를 추적하고 노드에 대한 shard 할당을 담당한다.
  • Node Communication
    • 노드 간 통신은 JSON over HTTP의 RESTful API나 내부 transport 프로토콜을 사용한다.

분석과 집계

  • Analysis(분석)
    • 색인 시점에 텍스트 분석을 수행하며, 텍스트를 토큰이나 텀 단위로 분해한다.
    • 커스텀 tokenizer, filter, analyzer로 고도로 커스터마이징할 수 있다.
  • Aggregation(집계)
    • 데이터로부터 복합적인 요약과 인사이트를 도출한다.
    • metric(합계·평균 등 계산), bucketing(데이터 그룹화), nested aggregation(계층적 탐색)으로 나뉜다.

Elastic Stack 구성요소

구성요소 역할
Elasticsearch 저장(Store), 검색(Searching), 분석(Analyzing)을 담당한다
Logstash 서버 사이드 데이터 처리를 담당한다
Kibana 데이터 시각화 대시보드를 제공한다
Beats 데이터를 수집해 전송한다(shipper). 예: Filebeat, Metricbeat
X-Pack Security(RBAC, 암호화, Audit, IP Filtering), Alerting, Monitoring, Reporting, Machine Learning(이상 탐지), Graph Analytics, SQL을 제공한다

데이터 파이프라인

LOGS → [beats(Data Collection)] → [logstash(Data Processing)] → [elasticsearch(Storage)] → [kibana(Visualize)]

확장 구성: 수집(beats)과 처리(logstash) 사이에 Kafka나 Redis를 버퍼로 두어 유입량 급증을 흡수하고 처리 단계를 분리할 수 있다.

LOGS → beats → [Kafka / Redis] → logstash → elasticsearch → kibana

Cluster와 Node

  • Cluster는 함께 동작하는 하나 이상의 노드 집합이다. 고유한 이름으로 자신을 식별하며, 데이터를 분산하고 집합적으로 관리하는 데 쓰인다.
  • Node는 Elasticsearch의 각 인스턴스를 가리킨다. 노드는 데이터를 저장하고 클러스터의 색인·검색 기능에 참여한다.

노드의 종류

노드 역할
Master Node 인덱스 생성·삭제, 노드 상태 관리 등 클러스터 전역 작업을 관리한다
Data Node 데이터를 저장하고 CRUD, 검색, 집계를 처리한다
Ingest Node 색인 전에 필터링이나 보강 같은 데이터 변환을 처리한다
Coordinating Node 클라이언트 요청을 라우팅하고 노드 간 검색 부하를 분산한다

Index, Document, Shard

  • Index는 문서를 조직하는 논리적 네임스페이스다. 관계형 데이터베이스의 테이블에 해당하는 개념이다.
  • Document는 색인 가능한 정보의 단위다. 데이터 속성을 나타내는 필드들로 구성된 JSON 객체다.
  • Shard는 index를 잘게 나눈 조각이다. 데이터를 클러스터의 여러 노드에 분산할 수 있게 해주며, 각 shard는 본질적으로 하나의 작은 Lucene 인스턴스다.

Shard의 두 종류

  • Primary Shard — 인덱스 생성을 담당하고 CRUD 연산을 직접 처리한다.
  • Replica Shard — primary shard의 복사본으로, 이중화와 고가용성을 제공한다.

클러스터를 지탱하는 요소

  • Replica — 각 primary shard는 장애 내성을 위해 0개 이상의 replica를 가질 수 있다. replica는 읽기 요청도 처리하므로 검색 성능을 높인다.
  • Routing Table — 어느 노드가 어느 shard를 가지고 있는지 결정한다. 이 정보는 master node가 갱신하고, coordinating node가 요청을 적절한 shard로 보내는 데 사용한다.
  • Gateway — Elasticsearch가 클러스터와 인덱스의 상태를 영속화하는 메커니즘이다. 메타데이터를 유지하며, 노드 장애 시 이 정보를 복구할 수 있다.
  • Discovery Module — 새 노드가 기존 클러스터에 매끄럽게 합류하도록 보장하고, 노드 상태 변화를 관리한다.

전체 구조

Replication이란

  • Elasticsearch의 replication은 데이터의 중복 사본을 만드는 과정이다. 데이터 이중화, 고가용성, 장애 내성을 확보하는 것이 목적이다.

Shard와 Replica

  • Primary Shard — 각 인덱스는 primary shard로 분할된다. 원본 데이터의 색인과 저장을 담당한다.
  • Replica Shard — primary shard의 복사본이다. 백업 역할을 하면서 동시에 쿼리 부하를 분담한다.

Replication 동작 방식

  • Primary–Replica 관계 — 각 primary shard는 0개 이상의 replica shard를 가질 수 있다.
  • 쓰기(Write) — 문서가 primary shard에 색인되면 해당 primary의 모든 replica shard에도 복제된다. 이를 통해 일관성을 보장한다.
  • 읽기(Read) — 검색 쿼리는 primary와 replica 어느 쪽에서도 처리할 수 있다. 읽기 부하를 분산해 성능을 높인다.

Replication의 이점

  • High Availability(고가용성) — primary shard를 가진 노드가 다운되면 그 replica 중 하나가 primary로 승격되어 데이터에 계속 접근할 수 있다.
  • Load Balancing(부하 분산) — 검색 요청을 primary와 replica 양쪽으로 라우팅해 검색 쿼리 성능을 개선한다.
  • Data Redundancy(데이터 이중화) — 여러 노드에 걸쳐 복수의 사본을 유지하므로, 노드 장애로 인한 데이터 유실을 막는다.

고려사항

  • 노드 수 — replication 설정을 감당할 만큼 노드가 충분해야 한다. 동일한 shard의 primary와 replica는 같은 노드에 배치될 수 없기 때문이다.
  • 네트워크·스토리지 오버헤드 — 데이터가 중복되므로 추가적인 네트워크 트래픽과 저장 공간을 소비한다.
  • 트레이드오프데이터 안전성(replica를 늘림)과 자원 사용량(디스크와 네트워크) 사이에 트레이드오프가 존재한다.

📖 Java🔥

📖 Kotlin⭐

📖 Coroutine📎

📖 Spring🔥

📖 Spring Security⭐

📖 Spring Security OAuth2⭐

📖 Spring Batch📎

📖 Database🔥

📖 MySQL🔥

📖 Redis⭐

📖 JPA⭐

📖 QueryDsl📎

📖 MSA⭐

📖 Kafka⭐

📖 Apache Flink📎

  • [Apache Flink - Apache Flink Architecture]
  • [Apache Flink - Stream Processing]
  • [Apache Flink - Data Stream API & Window]
  • [Apache Flink - State Management]

📖 HTTP🔥

📖 AWS⭐

📖 Docker⭐

📖 Kubernetes⭐

📖 Github Actions📎

📖 Jenkins📎

📖 Nginx⭐

📖 Monitoring📎

📖 Test(feat. Load Testing)📎

📖 Test(feat. Java)⭐

📖 Spring AI📎

📖 gRPC📎

  • [gRPC - Writing .proto Files with Protocol Buffers]
  • [gRPC - Various Communication Patterns in gRPC]
  • [gRPC - gRPC Optimization Techniques and Advanced Features]

📖 TDD(Test-Driven-Development)⭐

📖 PostgreSQL📎

  • [PostgreSQL - Docker만을 사용하는 경량화된 환경 구성 방법]
  • [PostgreSQL - PostgreSQL에서 제공하는 데이터 타입]
  • [PostgreSQL - PostgreSQI의 JSONB, 역인덱싱과 활용 방법]
  • [PostgreSQL - 데이터베이스 성능을 위한 최적화 패턴 및 전략]
  • [PostgreSQL - 트랜잭션과 ACID, Isolation 수준별 차이]
  • [PostgreSQL - Database Lock 교착상태와 읽기/쓰기 성능을 보장하는 MVCC 모델]
  • [PostgreSQL - pgvector와 벡터 저장, 유사도 검색 패턴 개념]
  • [PostgreSQL - 벡터 인덱스 최적화와 벡터 검색과 전문 검색 결합 패턴]
  • [PostgreSQL - PostgreSQL 플러그인]
  • [PostgreSQL - PostGIS - 공간 쿼리와 GIST 인덱스, 지리 타입과 공간 쿼리를 위한 타입과 기본 함수]
  • [PostgreSQL - pg_search - 검색 엔진 없이 텍스트 검색 구현과 주의사항]
  • [PostgreSQL - 단일 인스턴스 한계를 극복하는 분산 패턴과 스케줄링, 분산 환경 구축 방법]
  • [PostgreSQL - Citus - 분산 테이블과 분산 쿼리를 위한 Extension과 데이터 분산 처리]
  • [PostgreSQL - pg_cron - PostgreSQL로 구성하는 CronJob]
  • [PostgreSQL - 스케줄러 + 분산 처리를 동시에 도입하는 주기적 집계 쿼리 패턴]

📖 Workflow-Driven Techniques for Large-Scale Traffic Processing📎

  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka + Debezium을 활용한 CDC 패턴 설계]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Temporal을 활용한 워크플로우 패턴]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Docker와 경량 이미지를 활용한 환경 구축 방법]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Kafka에서의 메시지 Delivery Guarantee]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - 실시간 동기화의 핵심 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - MySQL Binary Log 기반의 CDC]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Binary Log 기반의 CDC 구현 플랫폼 Debezium이란?]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture]
  • [Workflow-Driven Techniques for Large-Scale Traffic Processing - Debezium Architecture Best Practice와 주의사항]

📖 Reactive Programming📎

📖 ElasticSearch📎

📖 Design Pattern📎

📖 Clean Spring📎

  • [Clean Spring - Domain-Driven Development]
  • [Clean Spring - Domain-Driven Development with Design Patterns]
  • [Clean Spring - Developing Membership Application with Hexagonal Architecture]
  • [Clean Spring - JPA and Domain Model Patterns]
  • [Clean Spring - Designing a Consistent Domain Model with Aggregates]
  • [Clean Spring - Web API Adapter]
  • [Clean Spring - Hexagonal Architecture: Ports]
  • [Clean Spring - Hexagonal Architecture: Application Components]
  • [Clean Spring - Test Improvement & Architecture Validation]
  • [Clean Spring - Developing Application Components]
  • [Real MySQL 8.0 - 인덱스]
  • [Real MySQL 8.0 - 실행 계획]
  • [Real MySQL 8.0 - 아키텍처]
  • [Real MySQL 8.0 - 트랜잭션과 잠금]

Clone this wiki locally