Elastic Search 관련 기초 상식 정리

작성일 | In

개인 프로젝트를 진행하며 Elasticsearch를 처음 사용해보았는데, 검색 속도에서도 이점이 있었지만 한글 형태소 검색 최적화 작업이 무척 신기하고 재미있었다. 추후 ES를 더 깊이 있게 다루어 볼 때 도움이 되도록 궁금했던 내용들에 대한 답을 찾아보고 정리해둔다.

📌 Elasticsearch는 왜 빠른걸까?

✅ 역색인 (Inverted Index) 구조 사용

기본적으로 검색 엔진은 “정방형 인덱스”를 사용하지만, Elasticsearch는 “역색인(Inverted Index)”을 사용해 빠른 검색이 가능하다. 그럼 역색인이란 뭘 어떻게 하는 걸까?

  • 🔍 일반적인 데이터베이스(RDBMS) 검색 방식 :
    행 단위로 저장되어 있는 데이터를 where 조건으로 일일이 비교함.
    SELECT * FROM products WHERE name LIKE '%노트북%' → 데이터를 하나하나 검사해야 해서 데이터가 많아질수록 조회 속도가 느려진다.
  • 🔍 Elasticsearch의 역색인 방식 :
    문서가 저장될 때 단어를 먼저 분해(Tokenize)하고, 각 단어가 등장하는 위치를 저장한다.
    즉, 데이터가 아니라 “단어 → 문서” 형태로 저장되므로 검색이 훨씬 빠르다.
    | 단어 | 포함된 문서 ID | | — | — | | 노트북 | Doc1, Doc3 | | 삼성 | Doc1 | | 핸드폰 | Doc2 | 이런 형태로 저장되어 있으니 노트북을 검색하면 바로 Doc1, Doc3을 찾을 수 있어서 속도가 매우 빠른 것이다.

✅ Sharding(샤딩)과 Replication(복제)으로 분산 검색

Elasticsearch는 데이터를 여러 개의 작은 조각(Shard)으로 나누어 저장하고, 동시에 여러 개의 서버(Node)에서 병렬로 검색을 수행한다. 이 덕분에 대량의 데이터를 처리할 때에도 속도가 빠르다.

샤드 번호 저장된 데이터 검색 요청 처리
Shard 1 Doc1, Doc2, Doc3 검색 요청 처리 가능
Shard 2 Doc4, Doc5, Doc6 검색 요청 처리 가능
Shard 3 Doc7, Doc8, Doc9 검색 요청 처리 가능

📌그럼 Shard는 무조건 많을 수록 좋은 걸까? :
운영 환경에서는 최소 2개 이상의 샤드를 설정하는 게 일반적이다. 여러개의 노드에 샤드를 나누어 저장하면 병렬 검색이 가능하고, 장애 발생 시 복구가 가능하기 때문이다. 하지만 샤드 개수가 너무 많으면 메모리가 낭비되므로 운영 환경의 규모에 따라 샤드 개수를 결정하는 게 제일 좋다. 레플리카도 마찬가지.

✅ 메모리 기반 검색 (File System Cache + Lucene Segment)

Elasticsearch는 디스크에서 데이터를 찾는 것이 아니라, “메모리 캐시”를 적극 활용해서 검색 속도를 높인다. 검색할 때 파일 시스템 캐시(File System Cache)를 활용해서, 자주 사용하는 데이터를 메모리에 올려둘 수 있다. 즉, 자주 검색하는 데이터는 디스크를 거치지 않고 메모리에서 바로 가져오므로 속도가 빨라진다.

📌 한글 분석기 Nori의 형태소 분석 원리는 뭘까?

한글 검색에서는 형태소 분석이 중요하다. 띄어쓰기, 조사, 어미 변화가 많아서 일반적인 역색인 방식으로는 검색 정확도가 떨어지기 때문이다. Nori는 형태소 단위로 단어를 적절하게 분해해서 검색을 최적화 한다. 예시를 통해 이해해보자.

  • 예제 : “나는 밥을 먹었다.”
  • 일반적인 공백(띄어쓰기) 기반 토큰화: [“나는”, “밥을”, “먹었다.”]
  • 📌 문제점: “나는” → “나” + “는”(조사) “먹었다” → “먹”(동사) + “었다”(과거형 어미) 단순히 띄어쓰기 기준으로 나누면 검색 정확도가 떨어짐!

✅ Nori Analyzer 적용 시 결과

1
2
3
4
5
6
7
8
9
10
11
{
  "tokens": [
    { "token": "나", "pos": "NNG" },  
    { "token": "는", "pos": "JX" },  
    { "token": "밥", "pos": "NNG" },  
    { "token": "을", "pos": "JKO" },  
    { "token": "먹", "pos": "VV" },  
    { "token": "었", "pos": "EP" },  
    { "token": "다", "pos": "EF" }
  ]
}

✔ “나는” → “나” + “는”
✔ “먹었다” → “먹” + “었” + “다” 위와 같이 Nori는 조사, 어미 등을 분리하여 검색 성능을 최적화해준다.

📌 Node, Shard, Replica의 역할 정리

  • Node : Elasticsearch 클러스터를 구성하는 서버 1대 = Node 1개.
  • Shard : 인덱스를 “작은 조각”으로 나눈 단위. 노드가 하나의 도서관이라면 샤드는 그 안에 있는 책장이라고 생각 할 수 있다. 책장이 1개 뿐이면 A~Z를 다 한 군데에서 찾아야하지만, A-C, D-F, G-I 처럼 나누어져 있으면 더 빠르게 원하는 책을 찾으러 갈 수 있다.
  • Replica : 샤드의 복사본. 원본 샤드(Primary Shard)가 고장나도, 복제본 샤드(Replica Shard)가 대신 역할을 수행할 수 있다. 비유하자면 같은 책을 여러 권 준비해두는 것으로, 책 한 권이 손상되어도 다른 책을 대신 대여 할 수 있다.

📌 Node, Shard, Replica는 몇 개씩 있는게 좋을까?

  • Node는 3개 이상을 권장한다.
    장애가 발생해도 클러스터가 계속 작동하려면 최소 3개 이상의 노드가 필요하다. Elasticsearch 클러스터는 Kafka, Redis와 마찬가지로 Master Node를 투표로 결정하는데 홀수로 구성하는 게 좋기 때문이다.
  • Shard는 2개 이상을 권장한다.
    샤드가 1개면 모든 검색 요청이 한 곳으로 집중되어 성능이 저하된다. 샤드를 여러 개 두면 여러 노드에서 병렬로 검색이 가능하므로 검색 속도가 향상된다.
  • Replica는 1개 이상을 권장한다.
    장애 발생 시 데이터를 복구 할 수 있고, 검색 속도가 빨라지기 때문이다. Replica가 없으면 Primary Shard가 고장났을 때 데이터 손실 발생 가능성이 있다.

📌 ELK 스택이란 정확히 뭘 말하는 걸까?

ELK 스택은 Elasticsearch, Logstash, Kibana의 조합으로 이루어진 로그 및 데이터 분석을 위한 오픈소스 솔루션 스택이다. 주로 대량의 로그 데이터를 수집, 저장, 검색, 시각화하는 데 사용되며, DevOps, 보안, 모니터링 시스템에서 널리 활용된다. 한 마디로, ELK 스택 = 로그 데이터를 효과적으로 관리하는 3가지 핵심 도구의 조합이다.

📌 Elasticsearch와 Logstash, Kibana의 역할

  • Elasticsearch : 데이터를 저장하고 검색하는 역할을 하는 NoSQL 데이터베이스
  • Logstash : 다양한 소스에서 데이터를 수집하고 변환하고 저장
  • Kibana : Elasticsearch 데이터를 시각화하고 분석하는 대시보드

즉, Logstash가 데이터를 모으면 Elasticsearch에서 데이터를 관리하고, Kibana는 그 데이터를 보기 좋게 정리하는 역할을 한다.

📌 Prometheus는 무엇을 모니터링하는가

Prometheus는 메트릭(Metrics) 기반 모니터링 시스템이다. CPU 사용량, 메모리 사용량, 트래픽, 애플리케이션 성능 등을 모니터링한다.

📌 로그, 메트릭, 트레이스의 차이점

  • Log : 텍스트 기반으로 시스템 이벤트를 기록 (ex. [로그인] userID : 사용자A )
  • Metrics : 수치화 된 데이터로 시스템 성능을 모니터링 (ex. CPU 사용량 70%)
  • Trace : 요청 흐름을 추적(결제 요청이 A서비스 → B서비스 → C서비스로 전달 됨)

📌 데이터 파이프라인에서 Kafka가 필요한 이유

카프카는 대량의 데이터를 빠르고 안정적으로 처리해주는 분산 메시징 시스템이다. 데이터 파이프라인에서 카프카가 필요한 주요 이유는 다음과 같다.

  1. 실시간 데이터 처리가 가능해 지연시간이 적다.
  2. 데이터 분산 처리를 지원해 고가용성이 보장된다.
  3. 여러 시스템과 연동이 가능하다(Elasticsearch와도 연동 가능)

📌 Elasticsearch의 인덱스란?

ES의 Index는 RDBMS의 테이블과 유사한 개념이다. 테이블과의 공통점은 ‘데이터를 저장하는 논리적인 공간’ 이라는 것이고, 차이점은 ‘테이블-로우’가 아니라 ‘인덱스-도큐먼트’, 즉 하나의 인덱스 안에 여러 개의 도큐먼트(Document)로 구성되어 있다는 점이다.

1
2
3
4
5
6
7
8
9
10
PUT /products
{
  "settings": { "number_of_shards": 1 },
  "mappings": {
    "properties": {
      "name": { "type": "text" },
      "price": { "type": "double" }
    }
  }
}

👉 “products”라는 인덱스를 생성하고, name과 price 필드를 저장할 수 있도록 설정한 경우이다.

📌 Elasticsearch에서 Aggregation란?

데이터를 그룹화 하고 통계, 분석하는 기능이다. RDBMS의 GROUP BY 또는 COUNT와 비슷한 개념.

1
2
3
4
5
6
7
GET /products/_search
{
  "query": { "match": { "name": "Laptop" } },
  "aggs": {
    "avg_price": { "avg": { "field": "price" } }
  }
}

👉 검색 + 가격 평균 계산을 한 번에 수행하는 예제.

📌 추가로 알아두면 좋을 개념

  • 🔹 RAG (Retrieval-Augmented Generation)
    검색 시스템에서 대규모 언어 모델(LLM) 을 활용하여 검색 결과를 보강하는 기법이다. Elasticsearch와 벡터 검색을 활용하여 GPT 같은 모델과 결합할 수 있다. OpenAI API + Elasticsearch 벡터 검색을 조합하는 방식.

  • 🔹 벡터 검색
    텍스트 데이터를 벡터화하여 유사도가 높은 검색 결과를 제공하는 기술이다. FAISS, Annoy, Elasticsearch의 kNN(벡터 검색)을 활용한다.

  • 🔹 Observability (옵저버빌리티)
    서비스의 상태와 성능을 실시간으로 모니터링하는 개념으로 로그, 메트릭, 트레이스를 분석하여 서비스 이상을 탐지한다. Prometheus + Grafana + Elastic Stack을 활용한 구축 방법

  • 🔹 Anomaly Detection (이상 탐지)
    머신러닝을 활용하여 비정상적인 패턴을 탐지하는 기법
    Elastic Machine Learning 기능을 활용하여 이상 탐지 가능