Elasticsearch 도입으로 검색 지연 시간 40배 줄이기

TL;DR#

• 수백만 건 규모에서 RDBMS의 LIKE '%keyword%' 검색은 Full Table Scan 때문에 쿼리 하나가 2초 이상 걸리며 병목이 됩니다.
• RDBMS Full Text Index, Redis 캐싱, Elasticsearch 세 가지를 비교한 뒤 역색인과 한글 형태소 분석이 필요해 Elasticsearch를 채택했습니다.
• NestJS에서 multi_match 쿼리로 전문 검색을 붙였고, RDBMS와의 데이터 정합성은 Logstash 배치 동기화와 MQ 기반 실시간 갱신을 병행해 해결했습니다.
• 검색 속도는 평균 2.1초에서 48ms로 약 43배 빨라졌지만, JVM Heap 메모리 점유와 인프라 비용, Near Real-time 지연이라는 트레이드오프가 따랐습니다.

문제의 배경#

서비스 규모가 커지고 데이터가 수백만 건 이상 쌓이면, 가장 먼저 성능 한계가 드러나는 곳 중 하나가 검색 기능입니다.

PostgreSQL이나 MySQL 같은 관계형 데이터베이스에서 LIKE '%keyword%' 쿼리를 실행하면, DB 엔진은 테이블의 모든 행을 하나씩 훑는 Full Table Scan을 수행합니다. 데이터가 적을 때는 문제가 없지만, 수백만 개의 상품이나 게시글이 쌓인 상태에서 동시 접속자가 늘어나면 검색 쿼리 하나가 2초 이상 걸립니다. 이는 곧 전체 시스템의 병목으로 이어집니다.

해결 방안 탐색#

검색 성능 문제를 풀기 위해 세 가지 대안을 고려했습니다.

1. RDBMS Full Text Index: 설정은 간편하지만 한글 형태소 분석의 정교함이 떨어지고, 데이터가 늘어날수록 성능 향상폭이 제한적이었습니다.
2. Redis를 활용한 검색 캐싱: 자주 검색되는 키워드는 빠르지만, 새로운 검색어나 복잡한 필터링 조건에는 대응할 수 없었습니다.
3. Elasticsearch 도입: 루씬(Lucene) 기반의 분산 검색 엔진으로, 텍스트 검색에 최적화된 역색인(Inverted Index) 구조를 사용합니다.

대규모 데이터에 대한 실시간 검색과 정교한 한글 분석(Nori 등)이 필수였기에, Elasticsearch를 최종 솔루션으로 채택했습니다.

핵심 개념과 아키텍처#

Elasticsearch가 RDBMS보다 수십 배 빠른 이유는 데이터를 저장하는 방식 자체가 다르기 때문입니다.

역색인(Inverted Index) 구조#

책 맨 뒷부분의 '찾아보기' 페이지를 떠올리면 쉽습니다. 일반적인 DB가 "문서 번호 → 내용" 순서로 저장한다면, Elasticsearch는 "단어 → 그 단어가 포함된 문서 번호들" 형태로 저장합니다. 따라서 특정 단어를 검색할 때 모든 데이터를 훑을 필요 없이, 단어가 등록된 위치로 즉시 점프해 결과를 찾습니다.

분산 처리와 고가용성#

Elasticsearch는 여러 대의 서버(Node)를 하나의 클러스터로 묶어 데이터를 분산 저장(Sharding)합니다. 특정 서버에 장애가 발생해도 복제본(Replica)을 통해 서비스 중단 없이 작동합니다.

구현과 트러블슈팅#

NestJS 환경에서 Elasticsearch 클라이언트를 연동해 상품을 검색하는 기본 흐름은 다음과 같습니다.

복사
// elasticsearch.service.ts
import { Injectable } from '@nestjs/common';
import { ElasticsearchService } from '@nestjs/elasticsearch';

@Injectable()
export class ProductSearchService {
  constructor(private readonly esService: ElasticsearchService) {}

  async searchProducts(query: string) {
    // Elasticsearch의 match 쿼리를 사용한 전문 검색
    const result = await this.esService.search({
      index: 'products',
      body: {
        query: {
          multi_match: {
            query,
            fields: ['title', 'description', 'category'],
            fuzziness: 'AUTO' // 오타 교정 기능 포함
          }
        }
      }
    });

    return result.hits.hits.map(item => item._source);
  }
}

데이터 동기화 문제#

Elasticsearch 도입에서 가장 까다로운 부분은 RDBMS와의 데이터 일관성 유지였습니다. DB에서 상품명이 수정됐는데 검색 엔진에는 옛날 이름이 남아 있는 현상이 발생했습니다.

이를 해결하기 위해 Logstash를 활용한 배치 동기화와, 데이터 변경 시점에 MQ(Message Queue)로 인덱스를 실시간 갱신하는 방식을 병행해 데이터 정합성 문제를 풀었습니다.

결과와 트레이드오프#

도입 전후 지표 변화는 극적이었습니다.

• 검색 속도: 평균 2.1초에서 48ms로 약 43배 향상됐습니다.
• 검색 품질: 단순 일치 검색을 넘어 형태소 분석기를 통한 유의어 검색과 오타 교정이 가능해졌습니다.

다만 트레이드오프도 분명합니다. Elasticsearch는 메모리를 매우 많이 점유(JVM Heap)하며, 운영을 위한 인프라 비용이 추가로 발생합니다. 또한 실시간(Real-time)이 아닌 Near Real-time(약 1초 지연) 구조이므로, 데이터 입력 직후 검색 결과에 바로 나오지 않을 수 있다는 점을 설계 단계에서 반드시 고려해야 합니다.

마치며#

검색은 사용자가 서비스의 가치를 가장 먼저 경험하는 창구입니다. 단순 기능 구현을 넘어 Elasticsearch 같은 전문 도구를 도입하는 것은 사용자 경험을 한 단계 끌어올리는 중요한 엔지니어링 결정입니다. 성능 병목으로 고민 중이라면 검색 엔진 도입을 검토해 볼 만합니다.