0

AWS, Elasticsearch / CloudSearch 비교

AWS(Amazon Web Service)의 검색 엔진 서비스는 Amazon Elasticsearch Service 와 Amazon CloudSearch 가 있다. AWS  에서의 Elasticsearch는 Kinaba를 포함한 ‘분석’의 개념으로 접근하는 경우도 있지만, 이 글에선 검색엔진을 개발함에 있어 선택의 기준을 명확히 하고자 했기 때문에 관점을 ‘검색’으로 제한했다.

 

Apache Lucene

CloudSearch는 Solr 기반이다. Solar의 핵심 엔진은 Apache Lucene(https://lucene.apache.org/core)  이다. Elasticsearch 역시 Lucene 가 백엔드에 위치하고 있기 때문에 기반 기술의 차이는 크지 않다. Solr 를 사용했던 사람이라면 Elasticsearch 사용에 그리 거부감을 느끼지 않는것도 이 이유에서다.

폐쇄성의 CloudSearch, 개방된 Elasticsearch

앞서 언급한 것과 같이 CloudSearch 는 Solr 기반이다. 그럼에도 불구하고 Solr 라는 이름을 직접 사용하고 있지 않다. 반면, Elasticsearch Service는 명칭을 직접 사용하고 있다. 이유는 간단하다.

CloudSearch = Solr + AWS Preset 의 구성으로 생각하면 이해가 편하다. 즉, Preset은 CloudSearch 는 블로그나, 서비스를 개발함에 있어 개발 시간을 단축시켜 준다. 만약, Preset 에서 정의하고 있는 검색 요구사항이 ‘나의 서비스’와 동일하다면 별도의 추가 설계 및 개발 없이도 검색 기능을 구현할 수 있다. 예를 들어 Elasticsearch 에 형태소 분석기(like 은전한닢)을 설치하고 인덱싱 로직을 별도로 고민해야한다면 CloudSearch 는 이런 수고를 덜 수 있다. 반면 Preset 의 변형 범주가 제한되기 때문에 CloudSearch 는 내가 원하는 형태로 운영하거나, 확장하기 불편할 수도 있다.

Elasticsearch Service에서 한글 문장을 대상으로 의미있는 단어를 찾고 싶다면 ‘한글’ 형태소 분석기를 별도로 설치 및 운영방식에 대한 설계가 필요하다. 물론, 가중치 및 검색 결과에 대한 커스터마이징에 대한 요구가 크다면 N-Gram 방식(문자열을 N개의 문자 단위로 토큰화 한 뒤 부분적으로 일치시키는 형태. RDS 의 LIKE 검색과 유사하다) 반영이 가능하기에 어찌보면 CloudSearch 에 비해 사용하기 편할 수 있다.

Elasticsearch, 다양한 형식의 데이터 대응에서 적합

CloudSearch는 텍스트 또는 날짜, 숫자(int/double) 등등 여러 형태의 값을 저장할 수 있는 배열셋을 준비하고 있지만 하나의 문서에 대해 단순화된 구조만 지원하고 있다. 반면 Elasticsearch Service는 특정 데이터 유형 외에도 중첩된 객체모델과 부모 관련 인덱스를 지원하고 있기 때문에 하나의 문서에 대해 1:N 관계를 형성함으로서 좀더 정확하게 필터링 할 수 있고 앞선 기준을 정렬에 사용할 수도 있다.

일반적으로 단순화된 구조의 자료 검색은 CloudSearch, Elasticsearch Service 모두 사용함에 불편함이 없지만, 복합적 규칙이 반영되어야 하는 여행사이트 및 항공권 검색같은 경우 Elasticsearch Service 만 대응할 수 있다.

장점

  1. 아키텍처와 관리 UI 가 트랜디하다.
  2. 클러스터 구축이 편리하다. (단, Docker 의 경우 쉽지 않음)
  3. Kinaba와 Logstash와 연동할 수 있다.
  4. Percolate API는 Push 알림과 같은 기능을 쉽게 구현할 수 있다.

단점

  1. 상대적으로 손이 많이 간다.

 

CloudSearch, 펀리하고 간단하고 쉽다

CloudSearch 는 관리에 이상적인 구조로, 데이터 양, 트래픽의 변화에 능동적으로 대응할 수 있어 시스템 운용 부하가 적은편이다. Elasticsearch Service 또한 CloudWatch 를 사용한다면 장애 발생한 Node를 자동으로 감지, Fail Over를 구현함으로써 운용 부하를 줄일 수 있지만, Scale Up/Out/Down 에 있어 관제할 수 있는 요소가 제한되어 설계자. 즉 시스템을 이해할 수 있는 사람이 필요한 경우가 생긴다.

동의어 사전의 추가 및 갱신 시 CloudSearch는 자동으로 인덱싱을 통해 내용이 추가된 사전을 자동으로 반영하는 반면, Elasticsearch Service는 동의어 사전을 인덱스에 반영하기 위해 조건이 반영되어 있는 사전, 조건에 일일이 API 를 호출해야 한다. 즉, 응용프로그램 레벨에서 운용이 불편한 면이 없지 않다.

Elasticsearch 가 좀더 고급된 기술자를 필요로 한다는 오해를 낳을 수 있지만, 동의어 사전등을 적용하는 경우 등록 내용에 따라 검색 결과에 미치는 영향이 클 수 있기 때문에 새로운 동의어 사전을 등록하고 적절하게(관리자 의도에 맞게) 반영할 수 있는 유연함이 있기 때문에 반드시 단점이라 하기는 어렵다.

장점

  1. 운영이 편리하다. 트래픽 및 처리량에 따라 인스턴스가 능동적으로 Scale In/Out/Up 된다.
  2. 색인하고자 하는 자료의 형태가 PDF 혹은 문서(DOC) 파일의 경우 기본 Preset 만으로도 충분이 대응 가능하다.
  3. DynamoDB를 활용할 수 있다.

단점

  1. 텍스트 분석 정의가 제한된다. (Stemming, Stopwords, Synonyms 만 지정 가능)
  2. N-Gram 또는 형태소 분석은 자체 처리 후 업로드 해 사전에 반영해야 한다.
  3. 통계를 산출하기 적절하지 않다.
  4. 텍스트 본문을 인덱스와 함께 저장할 수 없다.

 

 

※ Apache Solr / Elasticsearch / CloudSearch 비교표

Feature Apache Solr Elasticsearch Amazon CloudSearch
Admin Operations
Backup Replication/Custom handler/Custom scripts Snapshot API/Custom scripts Fully-managed
Patch Management Manual/Automated via custom scripts Manual/Automated via custom scripts Fully-managed
Re-indexing Manual Manual Fully-managed
Manual option available from management console
Monitoring If hosted on EC2, Amazon CloudWatch If hosted on EC2, Amazon CloudWatch CloudSearch default metrics
SaaS Monitoring tools like NewRelic, Stackdriver, Datadog SaaS Monitoring tools like NewRelic, Stackdriver, Datadog
Maintenance External managed service External managed service Fully-managed
API
Client Library Java, PHP, Ruby, Rails, AJAX, Perl, Scala, Python, .NET, JavaScript Java, Groovy, JavaScript, .NET, PHP, Perl, Python, and Ruby Amazon SDK
HTTP RESTful API YES YES YES
Request Format XML, JSON, CSV XML, JSON XML, JSON
Response Format XML, JSON, CSV XML, JSON XML, JSON
Third party Integrations Available for Commercial and Open source Available for Commercial and Open source Amazon Web Services Integrations available
Search Functions
Schema Schema and Schema-less Schema and Schema-less Schema
Dynamic fields support Yes Yes Yes
Synonyms Yes Yes Yes
Multiple indexes Yes Yes No
Faceting Yes Yes Yes
Rich documents support Yes Yes No
Auto Suggest Yes Yes Yes
Highlighting Yes Yes Yes
Query parser Standard, DisMax, Extended DisMax, Other parsers Standard, query_string, DisMax, match, multi_match Simple, structured, Lucene, or DisMax
Geosearch Yes Yes Yes
Analyzers, Tokenizers and Token filters Default/Custom Default/Custom Default
Fuzzy Logic Yes Yes Yes
Did you mean Default/Custom Default/Custom No
Stopwords Yes Yes Yes
Customization Yes Yes No
Advanced
Cluster management ZooKeeper in-built Fully-managed
Scaling Vertical scaling/ Horizontal scaling Vertical scaling/ Horizontal scaling Fully-managed horizontal scaling
Replication Yes Yes Yes
Sharding Yes Yes Yes
Failover Yes, if set up in Cluster Replica mode Yes, if set up in Cluster Replica mode Fully-managed
Fault tolerant Yes, if set up in Cluster mode Yes, if set up in Cluster mode Fully-managed
Import and Export
Data import Default import handlers, custom import handlers Rivers modules, Logstash input plugins, custom programs Batch upload
Data export Default export handlers, custom export handlers Snapshot API Custom program
Others
Web Interface Solr Admin Sense AWS Management Console

결론

어느쪽이 좋다. 우수하다 말하는건 쉽지 않다. Cloud Platform 을 사용하는건 분명 인적 요소를 최소화 하고자 하는 바램이 있는 경우가 많다. 반면, 시스템의 유연한 대응이라면 바라보는 시각에서 차이가 있을 수 있다. CloudSearch 에 비해 Elasticsearch Service는 사용성이 우수하지만, 정상적 운용을 위해선 이 분야에 대해 어느정도 지식이 있는 사람이 있어야 지속적 운영이 가능한 것이 사실이다.

경우에 따라 다르지만. Elasticsearch 추천 .. .. !

Leave a Reply

Your email address will not be published. Required fields are marked *