Elasticsearch 마스터 — 기본 개념·Cluster·Shard

이 글은 Elasticsearch 마스터 노트 시리즈의 첫 번째 편입니다. 검색·분석·로깅의 표준 — Elasticsearch. Lucene 위에 만든 분산 검색 엔진. RDB로 풀기 어려운 검색을 우아하게.

이 시리즈 10편은 기본 개념·Mapping·Analyzer·Query DSL·Full-text Search·Aggregations·Bulk API·Spring 통합·검색 엔진 프로젝트·Security까지. 1편의 목표 — Elasticsearch가 무엇이고 왜 표준이 됐는지 손에 잡히게.

처음 Elasticsearch가 어렵게 느껴지는 이유

처음 이 단원이 어렵게 느껴지는 이유는 두 가지예요. 첫째, Cluster·Node·Index·Shard 한 번에 등장합니다. 둘째, RDB와 비교가 막연합니다. SELECT 하면 되는데 왜?

해결법은 한 가지예요. "RDB = 정확한 매칭 / Elasticsearch = 검색" 한 줄. 사용자가 "spring framework"라 검색해도 spring framwrok 오타도 찾고 관련성 순서까지. 이게 RDB로 어려운 이유.

RDB vs Elasticsearch

측면	RDB (PostgreSQL·MySQL)	Elasticsearch
핵심	트랜잭션·정합성	검색·분석
인덱스	B+Tree (정렬·범위)	역색인 (Inverted Index)
관계	강력 (JOIN·FK)	약함 (denormalize)
쿼리	SQL	JSON Query DSL
일관성	ACID	Eventual·Near Real-Time
사용처	운영 데이터	검색·로그·분석

여기서 정말 중요한 시험 함정 — Elasticsearch ≠ DB 대체. 운영 데이터는 RDB·Mongo, 검색·로그·분석용 별도 저장소. 둘 함께 쓰는 게 표준.

Lucene — Elasticsearch의 토대

[Application]
   ↓
[Elasticsearch] (분산·REST API·운영 도구)
   ↓
[Lucene] (검색 엔진 코어)
   ↓
[Disk]

Lucene = Apache의 자바 검색 라이브러리. 단일 머신·라이브러리. Elasticsearch = Lucene 위에 분산·REST·운영성 더함.

역색인 (Inverted Index)

전통 인덱스:

Document 1: "Spring Boot"
Document 2: "Spring Framework"
Document 3: "Java Spring"

→ ID 기반 빠른 lookup

역색인:

"Spring"    → [Doc 1, Doc 2, Doc 3]
"Boot"      → [Doc 1]
"Framework" → [Doc 2]
"Java"      → [Doc 3]

→ "Spring" 검색 시 즉시 모든 문서

여기서 정말 중요한 시험 함정 — 역색인이 검색 엔진의 본질. 단어 → 문서 매핑. RDB의 LIKE %word% 와는 비교 불가 빠름.

5계층 구조

Cluster (전체 클러스터)
  └── Node (서버 1대)
       └── Index (논리적 데이터베이스)
            └── Shard (물리적 분할 단위)
                 └── Document (실제 데이터)

각 계층 역할:

Cluster

여러 노드 묶음. 하나의 클러스터 이름.

cluster.name: my-es-cluster

Node

물리·가상 서버 1대. 역할별로:

• Master Node — 클러스터 관리 (메타데이터)
• Data Node — 데이터 저장·검색
• Ingest Node — 데이터 전처리
• Coordinating Node — 요청 라우팅

여기서 시험 함정이 하나 있어요. 운영 환경 = 역할별 분리. Master 3+ (정족수)·Data N개·Coordinating 옵션. 작은 환경 = 모든 역할 한 노드.

Index

논리적 데이터 그룹. RDB의 테이블 비슷 (정확히 같지 X).

products       → 상품
users          → 사용자
logs-2024-01   → 로그 (시간 기반)

Shard — 물리적 분할

products Index (Shard 3개):
  ├── Shard 0 (Node 1)
  ├── Shard 1 (Node 2)
  └── Shard 2 (Node 3)

Lucene 인덱스 1개 = 1 Shard. 데이터 분산·병렬 검색.

Replica

각 Shard의 복사본:

Shard 0:
  Primary (Node 1) ← 쓰기·읽기
  Replica (Node 2) ← 백업·읽기 분산

여기서 정말 중요한 시험 함정 — Replica는 단순 백업 X. 읽기 분산도 함. 검색 시 Primary 또는 Replica 어느 쪽이든. 처리량 ↑.

Document — 실제 데이터

{
  "_index": "products",
  "_id": "abc-123",
  "_source": {
    "name": "Spring Boot Book",
    "price": 30000,
    "category": "IT",
    "tags": ["spring", "java"]
  }
}

JSON 형식. 스키마 자유 (또는 명시).

여기서 시험 함정이 하나 있어요. _id는 자동 생성 또는 명시. 같은 _id로 다시 PUT = 업데이트. POST = 자동 ID 생성·매번 새 문서.

첫 클러스터 실행 — Docker

# docker-compose.yml
version: '3'
services:
  elasticsearch:
    image: elasticsearch:8.x
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - ES_JAVA_OPTS=-Xms1g -Xmx1g
    ports:
      - "9200:9200"
  kibana:
    image: kibana:8.x
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200

docker-compose up -d

# 클러스터 확인
curl http://localhost:9200
{
  "name": "...",
  "cluster_name": "docker-cluster",
  "version": {...}
}

# 클러스터 상태
curl http://localhost:9200/_cluster/health

REST API — 핵심 명령

# 1. 인덱스 생성
PUT /products

# 2. 문서 추가
POST /products/_doc
{
  "name": "Spring Boot Book",
  "price": 30000
}

# 3. 문서 조회
GET /products/_doc/<id>

# 4. 검색
GET /products/_search
{
  "query": {
    "match": { "name": "Spring" }
  }
}

# 5. 인덱스 삭제
DELETE /products

여기서 정말 중요한 시험 함정 — 모든 작업 = REST API. 별도 SDK 없이 curl로도 OK. Elasticsearch의 강점.

Near Real-Time (NRT)

1. 문서 INDEX 요청
2. ~1초 후 검색 가능
3. 즉시 검색 X (Lucene refresh 주기)

여기서 시험 함정이 하나 있어요. Elasticsearch = Near Real-Time. 문서 작성 즉시 검색 X. 약 1초 후. 즉시 필요 = refresh=true 옵션 (성능 비용 큼).

클러스터 상태 색

GET /_cluster/health

{
  "status": "green"     # green / yellow / red
}

상태	의미
green	모든 Shard·Replica 정상
yellow	Primary OK, Replica 일부 문제
red	Primary 일부 누락 (데이터 손실 가능)

운영 = 항상 green. yellow도 모니터링.

Mapping (스키마)

PUT /products
{
  "mappings": {
    "properties": {
      "name": { "type": "text" },
      "price": { "type": "integer" },
      "created_at": { "type": "date" }
    }
  }
}

여기서 정말 중요한 시험 함정 — Mapping 안 하면 자동 추론. 첫 문서로 타입 결정. 운영 = 명시 Mapping 권장. 자세한 건 2편.

Shard 수 결정

PUT /products
{
  "settings": {
    "number_of_shards": 3,        # Primary Shard
    "number_of_replicas": 1       # Replica per Primary
  }
}

여기서 시험 함정이 하나 있어요. Primary Shard 수는 인덱스 생성 후 변경 X. (Replica는 변경 가능). 신중히 결정. 권장 = Shard당 30~50GB.

Kibana — UI

http://localhost:5601 → Kibana

Dev Tools — REST API 콘솔
Discover — 데이터 탐색
Visualize — 차트
Dashboard — 모음
Stack Management — 인덱스 관리

REST API 직접도 OK, GUI = Kibana.

사용 사례

적합

• 검색 — 상품·문서·사용자
• 로그 분석 — ELK Stack (Elastic + Logstash + Kibana)
• APM·관찰성 — Elastic APM
• 시계열 — 메트릭·이벤트
• 지리 검색 — Geo Queries

부적합

• 트랜잭션 처리 (RDB)
• 관계형 쿼리 (다중 JOIN)
• 운영 데이터의 단일 진실 (별도 RDB·NoSQL)

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 1편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• Elasticsearch = Lucene 위 분산 검색 엔진
• RDB ≠ ES — RDB는 트랜잭션·정합성, ES는 검색·분석
• 역색인 (Inverted Index) = 단어 → 문서 매핑 (검색 엔진 본질)
• 5계층 — Cluster / Node / Index / Shard / Document
• Node 역할 — Master / Data / Ingest / Coordinating
• 운영 = 역할별 분리 (Master 3+ 정족수)
• Index = 논리 그룹 (RDB 테이블 비슷)
• Shard = 물리 분할 (Lucene 인덱스 1개 = 1 Shard)
• Primary Shard = 쓰기·읽기 / Replica = 백업 + 읽기 분산
• Document = JSON, _id 자동 또는 명시
• 모든 작업 = REST API (curl도 OK)
• Near Real-Time = ~1초 후 검색 가능
• 즉시 필요 = refresh=true (성능 비용 큼)
• 클러스터 상태 — green / yellow / red
• 운영 = 항상 green
• Mapping = 스키마, 안 하면 자동 추론 (운영 명시 권장)
• Primary Shard 수 인덱스 생성 후 변경 X, Replica는 변경 가능
• 권장 — Shard당 30~50GB
• Kibana = GUI (Dev Tools·Discover·Dashboard)
• 적합 — 검색·로그·APM·시계열·Geo
• 부적합 — 트랜잭션·관계형·단일 진실

시리즈 다른 편

• 1편 — 기본 개념·Cluster·Shard (현재 글)
• 2편 — Mapping·데이터 타입
• 3편 — Analyzer·Tokenizer·한국어
• 4편 — Query DSL
• 5편 — Full-text Search·Relevance
• 6편 — Aggregations
• 7편 — Bulk API·Reindex
• 8편 — Spring Data Elasticsearch
• 9편 — 검색 엔진 프로젝트 설계
• 10편 — Security·인증·인가·TLS

공식 문서: Elasticsearch Documentation 에서 더 깊이.

다음 글(2편)에서는 Mapping — Elasticsearch의 스키마, text vs keyword, Dynamic Mapping의 함정까지 풀어 갑니다.