[ElasticSearch] 엘라스틱 서치 도입과 함께 맞닥뜨린 문제점

회사에서 기능 요구 사항으로 아이템 검색 기능을 추가해달라는 요구를 받았었습니다. Mongodb의 Atlas Search와 ElasticSearch 중에서 어떤 도구를 선택해야 좋을지 고민이 됐었는데 결론적으로 Elastic Search를 선택했습니다.

 

이 도구를 선택한 이유는 쿼리를 정말 다양하게 사용할 수 있다는 점과, atlas search에 비해서 참고할 자료가 많았던 점, DB와 함께 사용하면서 복잡한 쿼리 혹은 데이터 색인 과정에서 리소스를 어느 정도 필요로 한다는 점이었습니다.

 

하지만, 마냥 장점만 있던 것은 아니었습니다. 사이드 이펙트가 꽤 단순하지 않아서 골머리를 앓았던 경험이 떠오르네요.

그래서 이번에는 엘라스틱 서치를 도입하면서 어떤 문제점을 맞닥뜨렸는지 공유드리겠습니다.

 

DB - ES 간 동기화

가장 큰 문제는 DB와 ES 간 데이터가 완전히 동기화가 되지 않는다는 것입니다. DB에 데이터가 추가되면 ES에도 데이터를 넣어줘야 합니다. 가장 쉬운 방법은 Connector를 추가하는 방법입니다.

 

1. Monstache

https://rwynn.github.io/monstache-site/

Monstache

https://github.com/rwynn/monstache

GitHub - rwynn/monstache: a go daemon that syncs MongoDB to Elasticsearch in realtime. you know, for search.

 

Monstache는 mongodb 데이터를 elasticsearch와 연동시키기 위한 도구 중 하나입니다. mongodb에 저장되는 데이터를 바로 elasticsearch에 색인해주는 서비스입니다.

 

이는 외부 오픈소스이고 데이터가 중요한 상용환경에서 사용하는 것이 우려되어 선택하지는 않았습니다. 또한, 계속 연동을 시켜주기 위해 프로세스를 중단시키면 안되므로 추가 리소스가 필요하며, 이를 위한 엔지니어링 리소스를 사용하고 싶지 않았기 때문입니다.

 

2. Elastic Connectors

https://www.elastic.co/guide/en/enterprise-search/current/connectors.html

Elastic connectors | Enterprise Search documentation [8.15] | Elastic

 

elastic에서 제공해주는 연동 도구로 자체적으로 제공하는 커넥터들이 존재하므로 신용할 수 있다는 점이 좋았습니다. 하지만 enterprise search를 사용해야 한다는 점이 약간의 부담으로 다가왔습니다.

 

또한, 매핑을 설정하는 과정이 복잡하고 문서가 자세하지 않아 원하는 매핑을 설정할 수 없다는 점이 가장 아쉬웠습니다.

 

3. 서버 애플리케이션 코드 + 배치 작업

서버에서 아이템을 DB에 저장할 때, 이벤트를 사용하여 특정 아이템이 추가되었을 때 ES로 색인 데이터를 저장합니다. 하지만 모종의 이유로 DB에는 데이터가 저장되었더라도, ES에 데이터가 추가되지 않을 수도 있으므로 주기적으로 배치 작업을 수행해 데이터를 추가해주는 방법입니다.

 

이것도 물론 엔지니어링 리소스를 사용하지만, 가장 단순하게 외부 인적 자원을 사용하지 않고 처리할 수 있다는 점에서 긍정적인 부분이었습니다. 또한, 현재 기능이 검색 데이터가 무조건 DB 데이터와 매칭될 필요도 없었기 때문에 이 방법을 선택했습니다.

 

색인 데이터 중복

이게 가장 큰 문제점이었습니다. 엘라스틱 서치에 데이터를 추가하더라도 색인 과정을 거쳐 저장이 되기 때문에 바로 조회하더라도 데이터를 확인하지 못할 수 있습니다.

 

이 이유 때문에 upsert 요청을 서버에서 구현하여 사용하면 데이터가 중복으로 들어갈 수 있습니다.

 

예를 들어, A 아이템을 DB에 넣고 ES에 데이터를 추가합니다. 그리고 직후 A 아이템을 수정하여 ES에 upsert를 수행합니다. 여기서 upsert는 유니크한 identifier로 data를 찾고 해당 데이터의 _id를 통해 update하는 연산을 사용했습니다. 하지만, 여기서 DB에는 데이터가 존재하더라도 ES에는 데이터가 아직 반영되지 않았을 수 있습니다. 혹은 모종의 이유로 es에서 찾지 못한 경우도 있습니다.

 

이렇게 때문에 upsert를 Elastic search에 사용한다면, 충분히 데이터 중복 문제가 발생할 수 있습니다.

 

마무리

위와 같은 문제점이 존재하였지만, 개인적으로 검색의 자유도가 매우 높다는 점과 높은 성능을 보여주었기에 이를 도입한 후 아쉬움보다는 만족감이 더 큽니다.

 

아직 배워나갈 점이 많다고 느끼기 때문에 앞으로 배워나가는 내용들을 기재하도록 하겠습니다 🫡