Elasticsearch가 주 데이터베이스로 적합하지 않은 경우는?

Question

IT Interview Practice · Accepted Answer

Elasticsearch는 데이터를 영구적으로 저장할 수 있습니다. 주 데이터베이스로 사용할지는 **쓰기가 실패하거나 동시에 실행될 때도 어떤 업무 규칙이 지켜져야 하는지**부터 판단합니다.

주문 시스템에서 상품 검색과 구매 확정은 다른 일입니다. 전자는 검색 관련성이, 후자는 정확한 결제와 재고 변경이 중요합니다.

## 1. 함께 성공해야 하는 변경부터 확인합니다

구매에 주문 레코드 생성과 재고 감소가 필요하다고 가정합니다. 둘 중 하나만 성공하면 어떻게 할지 업무적으로 정해야 합니다.

```text
[Create order] ---- must coordinate ---- [Reduce stock]
      |                                      |
   success                                failure?
```

Elasticsearch Bulk API는 여러 문서 작업을 함께 보내지만 한 항목은 실패하고 다른 항목은 성공할 수 있습니다. 전체 성공 또는 전체 취소의 트랜잭션이 아닙니다. 애플리케이션이 각 결과를 확인해야 합니다. [Bulk API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-bulk).

여러 레코드의 원자적 변경이 필요하다면 트랜잭션 데이터베이스가 보통 더 직접적인 기반을 제공합니다. 조정 기능을 직접 만들면 실패 사례와 복구 작업이 늘어납니다.

## 2. 문서 보호와 업무 보장을 구분합니다

낙관적 동시성 제어는 읽은 버전 이후 문서가 바뀌었는지 검사합니다. 오래된 버전의 갱신을 거절해 한 클라이언트가 다른 클라이언트의 작업을 조용히 덮어쓰지 않게 할 수 있습니다. [동시성 제어](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/optimistic-concurrency-control).

이 보호는 갱신하는 문서에 적용됩니다. 재고 문서와 주문 문서를 자동으로 조정하거나, 관계형 외래 키를 제공하거나, 업무 필드 간 임의의 고유성 규칙을 강제하지는 않습니다.

저장소를 선택하기 전에 필요한 규칙을 적습니다. 그러면 ‘검색 엔진’이나 ‘데이터베이스’라는 이름 대신 구체적인 조건으로 결정할 수 있습니다.

## 3. 쓰기가 언제 검색 가능한지 확인합니다

쓰기 성공과 검색 결과에 보이는 것은 별개입니다.

```text
[Write accepted] -> [Refresh] -> [Search can see the change]
```

리프레시는 최근 변경을 검색에 보이게 합니다. 따라서 문서 ID로 실시간 조회하는 것과 검색 쿼리는 다릅니다. refresh=wait_for는 검색에 보일 때까지 기다릴 수 있지만 여러 문서의 트랜잭션을 만들지는 않습니다. [리프레시 동작](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/refresh-parameter).

상품 검색 페이지는 짧은 반영 지연을 허용할 수 있습니다. 최종 결제나 권한 판단에서는 필요한 일관성을 명시하고 이를 제공하는 원본을 읽습니다. 리프레시와 영구 저장도 서로 다른 문제입니다.

## 4. Elasticsearch의 역할을 선택합니다

| 요구 | 검토 방향 | 이유 |
| --- | --- | --- |
| 주문과 관련 레코드가 원자적으로 변경되어야 함 | 트랜잭션 주 데이터베이스 | 정확성 규칙은 권위 있는 레코드 가까이 있어야 합니다. |
| 유연한 전문 검색이 필요함 | Elasticsearch를 검색 사본으로 사용 | 검색 데이터를 독립적으로 구성하고 재구축할 수 있습니다. |
| 독립 문서이며 일관성 요구가 맞음 | Elasticsearch 단독 주 저장소도 가능 | 두 번째 데이터베이스에는 입증된 목적이 있어야 합니다. |

일반적인 주문 시스템 구조는 다음과 같습니다.

```text
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
 authoritative data                               search copy
```

CDC는 커밋된 변경을 수집하고, outbox는 업무 갱신과 같은 트랜잭션에 이벤트를 기록합니다. 별도 프로세스가 이를 인덱스로 전달합니다. 서로 독립적인 애플리케이션 쓰기 두 개가 항상 함께 성공한다는 가정에 기대지 않을 수 있습니다.

인덱싱 경로에는 여전히 안정적인 ID, 버전 처리, 삭제, 재시도, 지연 모니터링이 필요합니다. 원본에서 인덱스를 재구축하는 시험을 합니다. 그렇지 않으면 검색 사본이 불일치하는 두 번째 원본이 될 수 있습니다.

## 5. 결정 전에 복구 모델을 확인합니다

어떤 역할이든 백업을 계획하고 복원을 시험합니다. 복제본은 가용성을 돕지만 백업을 대신하지 않습니다. 실제 구성에서 허용할 데이터 손실과 복구 시간을 정합니다.

주문 예시라면 업무 규칙을 지원하는 데이터베이스에 트랜잭션 레코드를 두고, 검색 요구가 정당화할 때 Elasticsearch를 추가하겠습니다. 독립적인 검색 중심 문서라면 Elasticsearch만으로 저장, 일관성, 복구 요구를 충족하는지 평가하겠습니다.

**기억할 점:** 작업에 필요한 보장으로 선택하고 실패와 복구 동작을 검증합니다. 검색 속도는 판단의 일부일 뿐입니다.

요구	검토 방향	이유
주문과 관련 레코드가 원자적으로 변경되어야 함	트랜잭션 주 데이터베이스	정확성 규칙은 권위 있는 레코드 가까이 있어야 합니다.
유연한 전문 검색이 필요함	Elasticsearch를 검색 사본으로 사용	검색 데이터를 독립적으로 구성하고 재구축할 수 있습니다.
독립 문서이며 일관성 요구가 맞음	Elasticsearch 단독 주 저장소도 가능	두 번째 데이터베이스에는 입증된 목적이 있어야 합니다.

1. 함께 성공해야 하는 변경부터 확인합니다

2. 문서 보호와 업무 보장을 구분합니다

3. 쓰기가 언제 검색 가능한지 확인합니다

4. Elasticsearch의 역할을 선택합니다

5. 결정 전에 복구 모델을 확인합니다

관련 질문