안녕하세요! 나인투원 백엔드 팀의 라일라와 쵸파입니다. 우당탕탕 ElasticSearch 탐색기를 공유합니다.
1. 우리의 문제
나인투원은 일레클의 효율적인 기기배치 및 빠른 CS 대응 등을 위한 자체 관리앱/관제웹을 운영하고 있습니다. 최근 관리를 위한 운영 서버가 자주 부하를 발생시켜 운영과정에서 잦은 딜레이가 발생하곤 했습니다. 이유는 관제웹에서 특정 정보를 검색할 때, 다년간에 걸쳐 누적된 데이터 전체를 대상으로 특정 키워드를 쿼리하고 있었고, 키워드가 포함된 데이터를 불러오는 과정에서의 테이블간 연결 관계가 매우 복잡했습니다.
일레클 서비스는 최근 몇 년간 빠르게 성장하면서 유저와 전기자전거의 수가 크게 증가했고, 자연스럽게 라이딩, 운영, CS 등 모든 영역의 데이터는 가파른 속도로 증가했습니다. 이에 시간이 지날수록 쿼리에 걸리는 시간과 비용은 아래 사진들과 같이 점차 증가하게 되었고, 부하 발생 빈도 또한 잦아졌습니다.
1차적으로 DB Index를 추가하거나 ECS Fargate의 스펙을 올리는 등의 액션을 통해 대응하곤 했으나 이 역시도 성능/비용적인 부분에서 명확한 한계가 존재했습니다. 추가적으로 쿼리의 기본 범위를 n개월로 제한하는 방안이 있었지만 그럼에도 전체 혹은 n개월보다 넓은 범위를 대상으로 검색할 수 있어야 한다는 요구사항이 없어지는 것은 아니며 n개월 범위 제한만으로는 해결되지 않는 대상들도 존재했습니다.
2. ElasticSearch 도입 결정
다양한 논의가 있었고 최종적으로 오픈소스 검색 솔루션 ElasticSearch 도입을 결정했습니다. ElasticSearch는 엘라스틱사가 아파치 루씬을 기반으로 개발/공급하는 오픈소스 검색엔진 솔루션입니다. 기본적인 검색엔진이지만 MongoDB / Hbase와 같은 대용량 스토리지로도 사용하며, JSON 기반의 문서를 저장하고 대량의 비정형 데이터 검색이 가능하며 전문(full-text) 검색과 구조 검색 모두 지원합니다.
ElasticSearch는 매우 빠른 속도와 확장성, 복원성뿐만 아니라 정형/비정형 데이터를 모두 수용할 수 있는 유연성을 가지고 있습니다. 이같은 장점으로 DBMS 관련 인기도 등을 평가하여 매월 순위를 매기는 DB-Engines Ranking 23년 1월 기준 검색엔진 순위 1위를 차지하고 있습니다. (비정형 데이터 베이스를 포함한 순위는 3위. 1위 MongoDB, 2위 Redis, 3위 ElasticSearch)
물론, ElasticSearch가 우리가 가진 문제를 해결하는 은색총알(silver-bullet)은 아니었음에도 우리가 엘라스틱 서치 도입을 결정한 이유는 다음과 같습니다.
이미 검증된 솔루션
- ElaticSearch는 수많은 곳에서 사용중인 솔루션입니다. 검색 기능에 있어서 그 성능은 이미 널리 알려져 있습니다. 또한 데이터 색인 이후 실시간이라고 생각될 만큼 데이터에 대한 빠른 검색이 가능합니다. 비록 색인된 데이터는 1초 뒤에야 검색이 가능하다고는 하지만 일레클 운영에 있어서 색인과 검색사이의 1초는 도입에 있어서 큰 제약조건이 아니었습니다.
Reference
- 새로운 기술스택 도입에 대해서는 설치부터 이후의 운영까지 다양한 포인트에 대한 고민이 있습니다. 하지만 ElasticSearch의 경우, 이미 많은 곳에서 사용중인 솔루션인 만큼 다양한 참고자료가 존재했습니다. 데이터 모델링, 성능 최적화, 모니터링 등 새로운 스택을 적용하고 운영하는데 필요한 자료가 충분하다고 판단했습니다. 이를 통해 맨 땅에서 시작하지 않고 충분히 검증된 자료들을 바탕으로 우리에 맞게 ElasticSearch를 녹여낼 수 있을 것이라 생각했습니다.
Schemaless
- ElasticSearch는 JSON구조의 Schemaless한 document를 지향합니다. RDBMS의 경우, 엄격한 Schema 구조가 적용되면서 스키마 변경에 따라 광역적인 데이터 변경이 발생하고는 합니다. 하지만 ElasticSearch는 전통적인 RDBMS가 가지는 스키마라는 제약이 제거되면서 도입 초기에 보다 다양한 시도를 해볼 수 있을 것이라 생각했습니다.
- 최근 일레클은 렌탈 / 가맹 / 기기판매 등 다양한 영역으로 사업을 확장해 나아가고 있습니다. 각 사업의 영역이 모두 독립적으로 존재하는 것이 아니기 때문에 신규 사업이 추가될 때 마다 보다 다이나믹하게 데이터의 구조도 확장할 수 있을 것이라 생각했습니다.
위에서도 언급되었다시피 ElasticSearch는 현재 우리가 가지고 있는 문제에 대한 은색총알이 아닙니다. 어쩌면 관련 쿼리 고도화나 테이블 구조 개선이 지금 당장의 문제를 해결하는데 있어서 조금 더 직접적이고 쉬운 방향의 개선일 수도 있습니다.
하지만 이후에 충분히 도입가능한 관제웹 종합 검색, 비즈니스 분석을 위한 ELK Stack 도입. 그리고 어쩌면 일레클 서비스 앱에서도 검색기능이 추가되는 등의 상상력을 발휘해 보면 ElasticSearch의 영역은 그 범위가 제한되어 있지 않습니다. 또한 엔지니어로서 새로운 기술스택을 도입하고 적용하는 과정에서 얻게되는 지식이나 값진 경험 등을 모두 포함한다면 도입 자체의 의미는 충분하다고 생각합니다.
3. ElasticSearch에 대한 간단한 고찰
ElasticSearch(이하 ES)는 루씬(Lucene)기반의 오픈소스 분산 준 실시간 검색엔진입니다. JSON 기반으로 문서를 효율적으로 저장하고 실시간에 준하는 수준의 검색을 제공하기 때문에 강력한 검색 엔진으로 많이 활용됩니다.
특히, 데이터가 늘어나도 검색 시 속도의 큰 저하가 일어나지 않게 역색인(inverted index)이라는 자료구조를 활용합니다. 일반적인 RDBMS에서 검색을 사용할 때는 모든 row 안의 내용을 읽어 검색 대상을 찾기 때문에 데이터가 늘어날수록 검색 속도 또한 느려질 수 밖에 없습니다. 하지만 역색인을 사용할 경우 데이터에서 키워드를 추출하여 추출된 키워드에 대해 해당 키워드를 포함하고 있는 row의 id들을 배열로 저장합니다. 새로운 row가 추가되는 경우, 검색해야 하는 row가 늘어나는 것이 아닌 키워드에 대응되는 id의 배열에만 row의 id가 추가되면 되니 검색 속도에는 큰 영향이 없습니다.
ES는 REST API 기반의 인터페이스를 지원합니다. 즉, 어떤 언어로도 클라이언트를 만들 수 있고 간편하게 통신할 수 있기 때문에 사용하기 위한 진입 장벽이 낮습니다. 나의 어플리케이션에서 검색 기능을 구현하고자 할 때 간단하게 URI를 호출해 데이터를 수집할 수 있습니다.
관건은 나의 데이터를 효율적으로 검색하기 위해 어떻게 저장할지, 그리고 ES에 질의하는 layer를 나의 어플리케이션에 어떻게 끼워넣을 것인지가 되겠습니다.
4. 어떤 라이브러리를 활용할 수 있을까?
일레클의 코드베이스는 대부분 DRF가 적용된 Django 프레임워크로 이루어져 있습니다. 자연스레 ES와 Django를 손쉽게 결합할 수 있는 패키지와 라이브러리를 찾아보기 시작했는데요. 역시나 Django 프로젝트에 ES를 손쉽게 적용하기 위해 고안된 여러가지 라이브러리가 있었습니다!
조사 결과, elasticsearch-dsl-py(이하 dsl 라이브러리), django-elasticsearch-dsl(이하 django-dsl 라이브러리), django-elasticsearch-dsl-drf(이하 drf-dsl 라이브러리) 라이브러리는 elasticsearch 라이브러리에 기반하여 각각 ElasticSearch에 대한 편리한 질의, ES와 Django간의 쉬운 결합, DRF을 통한 ES 검색 구현을 지원하는 라이브러리들이라는 점을 알 수 있었습니다.
다음 화에서는 해당 세개 라이브러리를 사용해 간단한 기사제목 검색 api를 구현하고 장단점을 분석해보도록 하겠습니다.
참고 문헌
기초부터 다지는 ElasticSearch 운영 노하우: 기본 개념부터 클러스터 구축, 실무 활용 시나리오까지 (박상헌, 강진우)
