AWS OpenSearch에서 자가 호스팅 ElasticSearch로 마이그레이션하기

Ditching OpenSearch: How I Saved $200/Month on Rails Search

3줄 요약

  • AWS OpenSearch의 높은 비용과 불투명성으로 인해 자가 호스팅 ElasticSearch 7.10.2로 마이그레이션을 단행했습니다.
  • 스크롤 및 재가져오기, 매핑 확인, Alias 활용 등 체계적인 절차를 통해 중단 시간 없이 마이그레이션을 완료했습니다.
  • 마이그레이션 과정에서 기존 시스템의 숨겨진 버그를 발견했으며, ElasticSearch의 비용 효율성과 유연성을 확인했습니다.

Rails 기반 SaaS를 운영하는 필 스메이(Phil Smay)는 기존 검색 백엔드인 AWS OpenSearch를 자가 호스팅 ElasticSearch 7.10.2 인스턴스로 성공적으로 이전한 경험을 공유합니다. 이 결정은 주로 AWS OpenSearch 사용에 따른 높은 비용 부담(월 250달러)과 서비스의 불투명성(로그, 성능, 클러스터 상태 파악의 어려움), 그리고 만족스럽지 못한 성능 문제에서 비롯되었습니다. 자가 호스팅 ElasticSearch는 동일한 기능을 월 45달러 수준으로 제공할 수 있다는 점이 매력적이었습니다.

마이그레이션의 핵심 목표는 서비스 중단 시간을 ‘제로’로 유지하고 애플리케이션 코드 변경을 최소화하는 것이었습니다. 첫 단계로 Ubuntu 22.04 서버에 ElasticSearch 7.10.2를 설치했습니다. Elastic Search Rails 젬과의 호환성을 고려하여 특정 버전을 선택했습니다. 데이터 마이그레이션을 위해 사용자 정의 Ruby 스크립트인 migrate_index를 개발하여 사용했습니다. 이 스크립트는 OpenSearch에서 스크롤 API를 통해 데이터를 가져와 ElasticSearch로 푸시하는 방식으로 작동했으며, 대규모 데이터로 인해 완료하는 데 수일이 소요되었습니다. 데이터 일관성을 보장하기 위해 OpenSearch와 ElasticSearch 간의 매핑(mappings)이 일치하는지 확인하는 과정을 거쳤습니다. 또한, ElasticSearch의 강력한 기능인 Alias를 적극적으로 활용했습니다. 인덱스를 직접 참조하는 대신 Alias를 사용함으로써, 향후 인덱스 구조를 변경하거나 새로운 인덱스로 전환할 때 애플리케이션 코드 수정 없이 Alias만 업데이트하면 되도록 유연성을 확보했습니다. 첫 번째 데이터 이전 이후 마이그레이션 기간 동안 발생한 변경 사항들을 반영하기 위해 추가적인 재가져오기(re-import) 과정을 수행하여 최종 데이터 정합성을 맞추었습니다. 마이그레이션 완료 후에는 check_elastic_search_counts 스크립트를 사용하여 문서 수를 비교하고, 중요 쿼리를 직접 실행하여 데이터가 올바르게 이전되었는지 스팟 체크했습니다. 이 검증 과정에서 색인되지 않은 필드에 대해 집계 쿼리를 수행했을 때 결과가 항상 0으로 나오는 기존의 버그를 발견했습니다. 이는 OpenSearch 사용 중에는 인지하지 못했던 문제였으나, 전체 시스템을 점검하는 마이그레이션 과정을 통해 비로소 드러난 것입니다.

이번 자가 호스팅 ElasticSearch로의 마이그레이션은 비용 절감 목표를 성공적으로 달성했을 뿐만 아니라(비용 5분의 1 수준), 성능 및 투명성 측면에서도 개선을 이루었습니다. 특히 시스템 백엔드를 전반적으로 재검토하고 이전하는 과정에서 기존 코드베이스에 잠재되어 있던 버그를 발견하고 수정할 수 있었던 것은 중요한 성과입니다. 발표자는 비정형 데이터 처리에 탁월하고 유연하며 안정적인 ElasticSearch의 장점을 다시 한번 강조하며, 시스템의 주기적인 점검 및 개선이 숨겨진 문제를 해결하는 데 도움이 된다고 조언합니다. 마이그레이션에 사용된 구체적인 스크립트와 도구는 공유될 예정입니다.