실시간 데이터 검색이 필요했는데 단순히 빠른 검색만 제공하는 Elasticsearch 사용이 왜 나빴는가
Source: Dev.to
🚧 실제로 해결하고 있던 문제
프로덕션에서 우리의 고통은 검색 속도가 아니었습니다.
실시간 정확성이었습니다.
우리는 다음과 같은 워크플로우를 가지고 있었습니다:
- 사용자의 행동이 즉시 반영되어야 함
- 상태 변화가 밀리초 단위로 보여야 함
- “점진적 일관성”은 고객이나 지원팀에게 설명하기에 충분하지 않음
하지만 그때 나는 문제를 잘못 정의했습니다:
“쿼리가 느리다 → Elasticsearch를 추가한다”
그 잘못된 정의 때문에 몇 달을 허비했습니다.
🔍 규모에서 발생한 문제점
Elasticsearch는 약속한 대로 정확히 동작했습니다:
- 색인된 데이터에 대한 빠르고 분산된 검색
하지만 보장하지 않는 것도 있습니다:
- 강력한 실시간 보장
- 쓰기 후 즉시 일관성
- 트랜잭션 흐름을 위한 기본 데이터 소스로의 역할
실제 프로덕션 트래픽에서 우리는 다음과 같은 현상을 목격했습니다:
- 최근에 업데이트된 레코드가 결과에 누락됨
- 쓰기는 성공했지만 읽기가 지연되는 엣지 케이스
- 복잡한 재시도 및 새로 고침 로직이 애플리케이션 코드에 스며듦
각 버그는 “드물다”고 느껴졌지만, 합쳐지면 지속적인 문제였습니다.
비기술적인 이해관계자는 왜 발생했는지 신경 쓰지 않았고, 단지 신뢰할 수 없는 데이터만 보았습니다.
⚖️ 내가 과소평가한 트레이드‑오프
Elasticsearch는 규모에 따라 정확성을 포기하고 성능을 제공합니다.
우리는 쓰기 후 예측 가능한 읽기가 필요했습니다.
🧠 내게 남은 교훈
실수는 Elasticsearch를 사용한 것이 아니라, 문제가 명확히 정의되지 않은 상태에서 이를 보완 수단으로 사용한 것이었습니다.
- 빠른 검색 ≠ 실시간 데이터 조회
- 색인 ≠ 상태 관리
- 확장성 ≠ 정확성
다음과 같이 아키텍처를 재정비했을 때:
- 기본이 되는 강력히 일관된 데이터 스토어
- 명확한 읽기/쓰기 경로
- 검색은 검색이 필요한 경우에만 사용
시스템은 안정됐고, 사고는 감소했으며, 엔지니어들은 더 편안히 잠들 수 있었습니다.
🌱 이 경험이 시스템 설계에 미친 영향
오늘날 나는 “강력한” 인프라를 도입할 때 훨씬 신중합니다.
새로운 것을 추가하기 전에 스스로에게 묻습니다:
- 이 시스템이 제공하는 보장은 무엇인가?
- 명시적으로 제공하지 않는 보장은 무엇인가?
- 6개월 뒤에 내가 디버깅하게 될 실패는 무엇인가?
대부분의 프로덕션 고통은 도구가 부족해서가 아니라, 보장의 불일치에서 비롯됩니다.
마무리 생각
Elasticsearch는 훌륭한 도구입니다. 다만 신뢰가 필요하고 속도가 중요한 것이 아닌 문제에는 맞지 않았을 뿐입니다.
경험을 통해 얻은 교훈은, 아키텍처 성숙도는 더 많은 기술을 아는 것이 아니라, 언제 사용하지 말아야 할지 아는 것이라는 점입니다. 이 교훈은 실제로 배포하고, 문제를 일으키고, 그 결과를 책임질 때 비로소 얻을 수 있습니다.