[Spring] - Elasticsearch 적용 방법

🛠️ 개발 환경

• Kotlin : 1.9.25
• Spring boot : 3.3.4
• Github

왜 Elasticsearch를 사용할까?

DB에서 특정 문자열이 포함된 데이터를 검색할 때 LIKE 연산을 사용하게 된다. 예를 들어, 5만 개의 편의점 상품이 있다고 생각해보자. 내가 '쫀득'을 검색하려면, product 테이블에서 LIKE '%쫀득%' 같은 조건으로 값을 찾게 된다.

 

B-Tree 인덱스는 정렬된 키를 바탕으로 '어디부터 어디까지'라는 범위를 빠르게 좁혀 탐색하는 구조이다. 때문에, LIKE '쫀득%'의 경우 인덱스를 탈 수 있지만, LIKE '%쫀득%'(leading wildcard) 는 문자열의 시작(prefix)이 고정되지 않기 때문에, 인덱스로 탐색 범위를 만들기가 어렵다.

 

결과적으로 옵티마이저는 테이블 전체 또는 인덱스 전체를 훑으면서 조건을 검사하는 실행 계획으로 기울기 쉽고, 데이터가 많아질수록 비용이 급격히 커질 수 있다.

 

즉, 데이터가 많은 상황에서 LIKE '%keyword%' 기반 검색은 RDB 입장에서 구조적으로 불리해지기 쉽다. 그렇다면 Elasticsearch는 어떤 이점이 있길래 검색에 많이 사용될까?

검색 구조

RDB의 B-Tree 인덱스가 정렬된 값에서 범위를 빠르게 줄여나가는 방식이라면, Elasticsearch는 텍스트를 저장(색인)할 때 분석(analyze) 과정을 거쳐 토큰(term) 단위로 분해하고, “토큰 → 문서 ID 목록” 형태의 역색인(inverted index)을 생성한다.

 

예를 들어 "두바이 쫀득 쿠키", "쫀득쫀득 달고나", "쫀득한 초코칩 쿠키" 같은 데이터를 색인한다고 가정해보자(토큰 분해 결과는 분석기 설정에 따라 달라질 수 있다). Elasticsearch는 개념적으로 아래와 같은 구조를 유지한다.

문서	데이터
1	두바이 쫀득 쿠키
2	쫀득쫀득 달고나
3	쫀득한 초코칩 쿠키

토큰	문서 ID 목록
쫀득	1, 2, 3
쿠키	1, 3

즉, “쫀득”을 검색하면 전체 문서를 훑는 대신, 역색인에서 “쫀득” 토큰의 문서 후보 목록을 먼저 빠르게 찾고, 그 후보들에 대해서만 점수 계산(관련도)과 정렬을 수행한다. 이 때문에 데이터가 커질수록 스캔 기반 검색보다 훨씬 유리해질 수 있다.

 

다만 이런 구조를 유지하려면 색인 시점에 토큰 분석과 역색인 갱신 작업이 필요하므로, 일반적으로 검색 성능을 얻는 대신 쓰기(색인) 비용이 추가되는 트레이드오프가 존재한다.

적용 방법

Elasticsearch는 주로 Kibana와 함께 사용한다. Kibana는 Elasticsearch에 저장된 데이터를 사용자 친화적인 대시보드와 그래프, 차트 등으로 시각화하고 탐색하는 오픈 소스 웹 인터페이스이다.

 

즉, Elasticsearch가 데이터 저장 및 분석 엔진이라면, Kibana는 그 엔진의 데이터를 보고, 분석하고, 관리하는 모니터링 역할인 것이다. Kibana가 꼭 필요하지 않을 경우, Docker 설정에서 제외해도 무방하다.

Docker 설정

docker-compose에서 elasticsearch:build:context에는 Dockerfile의 경로를 적어주면 된다.

# /elasticsearch/Dockerfile
FROM docker.elastic.co/elasticsearch/elasticsearch:8.18.1
RUN elasticsearch-plugin install --batch analysis-nori

# docker-compose.yaml
services:  
  elasticsearch:  
    build:  
      context: ./elasticsearch  
      dockerfile: Dockerfile  
    container_name: elasticsearch  
    environment:  
      - discovery.type=single-node  
      - xpack.security.enabled=false  
      - xpack.security.enrollment.enabled=false  
      - ES_JAVA_OPTS=-Xms1g -Xmx1g  
    ports:  
      - "9200:9200"  
    volumes:  
      - es_data:/usr/share/elasticsearch/data  

  kibana:  
    image: docker.elastic.co/kibana/kibana:8.18.1  
    container_name: kibana  
    environment:  
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200  
    ports:  
      - "5601:5601"  
    depends_on:  
      - elasticsearch  

volumes:  
  es_data:

보통 로컬은 IDE를 통해 앱을 실행하고, 배포 환경에서는 Docker로 띄우기 때문에 다음과 같이 application.yaml을 설정해줘야 한다.

# local
spring:
  elasticsearch:
    uris: http://localhost:9200

# prod
spring:
  elasticsearch:
    uris: http://elasticsearch:9200

만약 로컬에서도 스프링을 Docker에 올려서 사용할 경우 prod와 동일하게 두면 된다.

통합 yaml을 가지고, env를 통해 운영할 경우 env 파일에 주소를 작성하고 uris: ${ES_URL}처럼 작성해주면 된다.

의존성 설정

Elasticsearch를 Spring Boot에서 사용하려면 spring-boot-starter-data-elasticsearch 의존성을 추가하면 된다.

implementation("org.springframework.boot:spring-boot-starter-data-elasticsearch")

Spring Boot를 쓰는 경우, 대부분은 Boot가 Spring Data Elasticsearch 버전을 함께 맞춰주기 때문에 의존성 버전을 직접 고정할 일이 많지 않다. 반대로 Boot가 아닌 일반 Spring 환경이라면, 사용 중인 Spring/Data 조합과 버전 호환표를 보고 호환되는 버전을 맞춰야 한다.

RDB와 Elasticsearch 역할 분리

구조를 잡을 때 핵심은 역할을 분리하는 것이다.

• RDB: 진실의 원천(source of truth). 데이터 생성/수정/삭제 같은 상태 변경이 확정되는 곳
• Elasticsearch(ES): 검색 전용 read model. 검색 성능/검색 품질을 위해 필요한 필드를 별도로 저장해 조회에 사용

즉, 실제 상태 변경은 RDB에서 처리하고 ES는 그 결과를 따라가는 복제본으로 운영하는 것이 좋다. 따라서 운영 관점에서는 동기화 지연이나 실패를 고려해 재시도/재색인 같은 복구 경로를 준비하고, 최종적으로 일관되게(eventually consistent) 맞춰지도록 설계하는 것이 중요하다.

Document 정의

ES에 저장되는 형태는 RDB 테이블과 1:1로 맞출 필요가 없다. 검색과 정렬에 필요한 필드만 뽑아서 Document로 정의하면 된다.

@Document(indexName = "product", createIndex = true)
data class ProductDocument(
    @Id
    val productId: Long,
    @Field(type = FieldType.Text, analyzer = "nori")
    val title: String,
    val price: Int
)

여기서 @Field(type = FieldType.Text, analyzer = "nori")는 해당 필드를 '한국어 형태소 분석 기반으로 토큰화해서 색인/검색하겠다'는 의미다. 한국어는 공백만으로 단어 경계를 잡기 어려운 경우가 많아서, 한글 검색 품질을 위해 nori 분석기를 사용하는 구성이 흔하다.

 

nori를 사용하려면 Elasticsearch에 analysis-nori 플러그인이 설치되어 있어야 하지만, 우리는 이미 Dockerfile에서 플러그인 설치를 이미 포함했기 때문에, 컨테이너가 빌드/실행될 때 함께 반영되며 별도의 추가 작업이 필요하지 않다.

 

참고로 createIndex = true는 애플리케이션 시작 시 인덱스 생성/매핑 적용을 자동으로 시도하는 옵션이다. 로컬에서는 편하지만, 운영에서는 인덱스 관리 정책(버전 인덱스, 마이그레이션, alias 운영 등)에 따라 끄고 별도로 관리하는 경우도 많다.

Repository 정의

마지막으로 ElasticsearchRepository를 만들면 JPA Repository처럼 ES 문서에 대해 저장/조회가 가능해진다.

interface ProductEsRepository : ElasticsearchRepository<ProductDocument, Long>

실제 사용

ES를 사용할 때 가장 주의해야할 점은 RDB와 ES를 동기화하는 것이다. 즉, ES에 Document로 추가한 RDB 테이블에 Create, Update, Delete가 일어난 경우, ES에도 함께 적용을 해주어야 한다.

fun save(dto: ProductDto) {
    val product = dto.toEntity()

    productRdbRepository.save(product)
    productEsRepository.save(product.toDocument())
}

ElasticsearchRepository의 대부분 함수가 JPA와 유사하기 때문에 큰 어려움은 없겠지만, 필요한 함수를 찾지 못할 경우 공식 문서를 통해 보면 도움이 될 것이다.