1억 개 이상의 레코드에 대한 전문 검색(full-text search)을 어떻게 구축하시겠습니까?

Question

IT Interview Practice · Accepted Answer

전용 검색 엔진을 사용하십시오 — **역인덱스(inverted index) 위에 구축된 Elasticsearch/OpenSearch** — 소스 DB에서 **CDC**를 통해 공급받고, 확장을 위해 인덱스를 샤딩하십시오. 당신의 primary 데이터베이스(Postgres/MySQL)는 수억 row에 대한 relevance 순위 텍스트 검색을 할 수 없습니다. `LIKE '%term%'`는 모든 row를 스캔합니다. 검색 엔진은 문제를 뒤집습니다.

```text
Source DB ─▶ CDC (Debezium) ─▶ Kafka ─▶ Indexer ─▶ Elasticsearch/OpenSearch
(Postgres)   (change stream)                        ├─ Shard 0 (inverted index) + replicas
                                                     ├─ Shard 1
Query ─▶ Coordinator ─▶ scatter to shards ─▶ gather ─┴─ Shard N ── ranked by BM25
```

## 역인덱스 — 왜 빠른가

일반 인덱스는 row → 값을 매핑합니다. **역인덱스**는 *term → 그것을 포함하는 문서 목록*을 매핑합니다. "database scaling"을 검색하면 두 개의 짧은 posting list를 조회하고 교집합을 구합니다 — O(모든 문서)가 아니라 O(일치 문서). 이것이 1억 개 이상의 문서에서 100ms 이하 검색을 가능하게 합니다. 텍스트는 먼저 **분석(analyze)**됩니다: 토큰화, 소문자화, 어간 추출(stemming)("running" → "run"), 불용어(stopword) 제거 — 그래서 쿼리가 변형을 매칭합니다.

## CDC를 통한 수집

이중 write(앱이 DB *와* ES에 write)를 하지 마십시오 — 실패는 둘을 불일치 상태로 남깁니다. 대신 **Change Data Capture**로 변경을 스트리밍하십시오: **Debezium**이 DB의 write-ahead log를 tail하여 row 변경을 **Kafka**에 발행하고, indexer가 이를 Elasticsearch에 적용합니다. 이는 검색을 소스와 **최종적으로 일관(eventually consistent)**되게 유지하고 ES 다운타임에도 견딥니다(이벤트가 Kafka에서 리플레이됨).

## 샤딩 & relevance

인덱스는 **shard**(각각 독립적인 Lucene 인덱스)로 분할되어 노드에 분산되고, **replica**가 read throughput과 HA를 더합니다. 쿼리는 모든 shard로 scatter되어 각각 top-k를 반환하고 coordinator가 병합합니다. relevance는 기본적으로 **BM25**를 사용합니다 — term frequency × inverse document frequency — boost, 동의어, 필드 가중치로 조정 가능합니다.

## 면접 관점

면접관은 당신이 (1) `LIKE` 대신 올바른 도구에 손을 뻗는지, (2) 역인덱스가 *어떻게* 작동하는지 아는지, (3) 이중 write 없이 **동기화 문제(sync problem)**를 푸는지 확인합니다. 좋은 답변: "Elasticsearch를 쓴다." 훌륭한 답변: 수집을 위한 CDC/Debezium, 순위를 위한 BM25를 짚고, 규모를 위한 트레이드오프로 최종적 일관성을 받아들입니다.

**흔한 함정:** Elasticsearch를 진실 공급원으로 취급하는 것. 그것은 파생 인덱스입니다 — DB처럼 내구성/트랜잭션이 있지 않습니다. 필요할 때 소스에서 다시 빌드하십시오.

## 트레이드오프 및 실패 모드

- **최종적 일관성:** 검색은 CDC 파이프라인 latency만큼 write보다 지연됩니다(보통 1초 미만).
- **Reindex 고통:** mapping/analyzer 변경은 전체 reindex가 필요합니다 — 무중단 교체를 위해 alias를 쓰십시오.
- **깊은 페이지네이션:** 10,000페이지는 비쌉니다(scatter-gather) — `from/size`가 아니라 `search_after`를 쓰십시오.
- **Hot shard / 편향:** 고르지 않은 문서 분포. 좋은 routing key를 고르고 충분한 shard를 미리 두십시오(생성 시 고정됨).
- **Relevance 튜닝은 지속적:** BM25 기본값이 비즈니스 의도와 맞는 경우는 드뭅니다 — 반복을 예상하십시오.

역인덱스 — 왜 빠른가

CDC를 통한 수집

샤딩 & relevance

면접 관점

트레이드오프 및 실패 모드

관련 질문