Elasticsearch, 데이터베이스로 쓰면 안 되는 이유...ParadeDB "근본적 설계 차이"

검색 엔진을 주 데이터베이스로 사용할 때 발생하는 트랜잭션, 스키마, 안정성 문제 경고

[한국정보기술신문] 오픈소스 데이터베이스 기업 ParadeDB가 최근 발표한 기술 블로그를 통해 엘라스틱서치를 주 데이터베이스로 사용하는 것의 위험성을 경고했다. 이 회사는 엘라스틱서치가 애초에 데이터베이스가 아닌 검색 엔진으로 설계됐다는 점을 강조하며, 많은 기업들이 겪고 있는 문제점들을 구체적으로 지적했다.

엘라스틱서치는 Apache Lucene 기반의 강력한 전문 검색 엔진으로, 지난 10년간 많은 기업에서 검색 기능 구현에 활용해왔다. 문제는 일부 개발팀들이 엘라스틱서치를 단순 검색 인덱스가 아닌 주 데이터 저장소로 사용하기 시작하면서 발생했다.

ParadeDB는 데이터베이스의 핵심 요건으로 원자적 트랜잭션, 예측 가능한 업데이트, 안전한 스키마 변경, 풍부한 쿼리 기능, 장애 시 안정성을 꼽았다. 하지만 엘라스틱서치는 검색 인덱스로 설계됐기 때문에 이러한 요구사항을 충족하지 못한다고 지적했다.

트랜잭션 보장 불가능

가장 큰 문제는 트랜잭션 지원 부족이다. 관계형 데이터베이스에서는 주문 생성과 재고 감소 같은 관련 작업들이 원자적으로 처리된다. 모두 성공하거나 모두 실패하는 것이 보장된다.

반면 엘라스틱서치는 단일 문서를 넘어서는 일관성을 보장하지 못한다. 여러 문서에 대한 쓰기 작업이 독립적으로 수행되며, 일부만 실패할 경우 데이터 불일치가 발생한다. 개발팀들은 재시도 로직이나 조정 작업을 추가해 문제를 해결하려 하지만, 이는 근본적인 해결책이 아니라는 것이 ParadeDB의 설명이다.

읽기 작업에서도 문제가 있다. 엘라스틱서치의 ID 기반 조회는 최신 버전을 반환하지만, 검색 쿼리는 비동기적으로 갱신되는 Lucene 세그먼트만 조회한다. 최근 쓰기 작업이 다음 갱신 때까지 검색 결과에 나타나지 않을 수 있다는 의미다.

스키마 변경의 고통

스키마 마이그레이션도 큰 난관이다. PostgreSQL이나 MySQL에서는 ALTER TABLE 명령으로 간단히 처리되는 작업이, 엘라스틱서치에서는 전체 재색인을 요구하는 경우가 많다.

엘라스틱서치의 인덱스 매핑은 한 번 설정되면 변경할 수 없다. 정수 필드를 소수점 필드로 바꾸거나 텍스트 필드 이름을 변경하려면 새 인덱스를 만들고 모든 문서를 옮겨야 한다. 엘라스틱서치가 다른 데이터베이스의 하위 시스템일 때는 번거롭지만 안전하다. 하지만 유일한 저장소일 경우, 운영 중에 전체 시스템을 새 구조로 옮기는 고위험 작업이 된다.

제한적인 쿼리 기능

관계형 쿼리 능력의 부족도 문제로 지적됐다. 엘라스틱서치가 주 저장소가 되면 개발자들은 자연스럽게 검색을 넘어선 데이터 질의를 원하게 된다. 하지만 엘라스틱서치의 JSON 기반 쿼리 DSL은 전문 검색과 집계에는 강력하지만, 관계형 작업에는 제한적이다.

예를 들어 리뷰가 50개 이상인 제품들의 평균 평점 상위 10개를 조회하는 SQL 쿼리를 엘라스틱서치로 구현하려면, 리뷰를 제품 문서에 비정규화하거나, 두 인덱스를 따로 조회해 애플리케이션 코드에서 결합해야 한다.

Elastic은 ES|QL의 조인 기능이나 SQL 문법 지원 등으로 이 격차를 좁히려 노력하고 있다. 하지만 여전히 Lucene의 인덱스 모델에 제약을 받으며, 현재 5가지 쿼리 문법이 공존하면서 개발자들에게 혼란을 주고 있다는 지적이다.

안정성과 운영 부담

장애 복구 능력에서도 차이가 있다. 데이터베이스는 Write-Ahead Log를 사용해 커밋된 트랜잭션의 모든 변경사항이 영구적으로 보존되고 충돌 후에도 깨끗하게 재생되도록 보장한다.

엘라스틱서치도 translog를 통해 개별 문서 쓰기의 내구성을 보장한다. 하지만 트랜잭션 경계가 없기 때문에 관련된 쓰기 작업들이 함께 보존되거나 실패하는 것을 보장하지 못한다. 장애 시 일부만 적용된 작업이 남을 수 있으며, 복구 과정에서 데이터베이스처럼 롤백되지 않는다.

운영 측면에서도 부담이 크다. 엘라스틱서치는 탄력성을 우선하도록 설계됐다. 샤드 이동, 클러스터 확장, 데이터 재색인 등이 가능하지만, 이는 운영상의 트레이드오프를 수반한다. 샤드 불균형, JVM 힙 튜닝, 롤링 업그레이드 중 트래픽 정체 등의 문제가 발생할 수 있다.

ParadeDB 측은 "엘라스틱서치는 속도와 관련성에 최적화됐다"며 "시스템 기록용으로도 실행한다는 것은 데이터베이스가 부과하는 것보다 더 많은 운영 위험을 감수하는 것"이라고 설명했다.

ParadeDB의 대안 제시

ParadeDB는 이러한 문제의 대안으로 자사의 PostgreSQL 기반 솔루션을 제시했다. OLTP와 전문 검색을 하나의 시스템에서 결합하거나, 기존 PostgreSQL 데이터베이스의 논리적 팔로워로 배포해 ETL을 제거할 수 있다고 설명했다.

회사 측은 "엘라스틱서치는 검색 엔진으로서 놀라운 성과"라며 "시스템 기록용으로 사용하지 않는 한, 설계된 대로 정확히 작동한다"고 강조했다. 다만 "올바르게 사용하더라도 가장 어려운 부분은 검색 자체가 아니라 ETL 파이프라인, 동기화 작업, 수집 계층 등 주변 작업"이라고 덧붙였다.

이번 발표는 많은 기업들이 엘라스틱서치를 주 데이터베이스로 사용하면서 겪는 어려움을 공개적으로 다뤘다는 점에서 주목받고 있다. 전문가들은 도구를 설계 목적에 맞게 사용하는 것의 중요성을 다시 한번 일깨워주는 사례라고 평가한다.

한국정보기술신문 정보기술분과 유상헌 기자 news@kitpa.org