2010년에 출시된 Elasticsearch는 분석 또는 빅데이터 출력에 표시할 데이터를 빠르게 쿼리하기 위해 만들어진 최초의 분산 검색 엔진 중 하나입니다. 그 당시, 더 많은 기업들이 방대한 양의 데이터를 축적하고 있었지만, 기존의 데이터베이스 엔진은 이를 따라잡을 수 없었습니다. Elasticsearch는 정형 및 비정형 데이터를 저장할 수 있는 벡터 데이터베이스로 도입되었습니다. 엔터프라이즈 분석이 성능 문제를 야기하는 테라바이트의 데이터를 초과했을 때 빅데이터 인덱싱과 더 빠른 쿼리를 최초로 도약했습니다.
Elasticsearch란?
Elasticsearch는 데이터를 모아 API를 통해 검색할 수 있도록 하는 데 사용되는 데이터스토어입니다. Apache Lucene을 기반으로 합니다. Apache Lucene은 데이터를 샤드로 분산시키는 인덱싱 및 스토리지 서비스입니다. 각 샤드는 자체 데이터를 저장하지만, 샤드는 노드 간에 데이터를 분산하기 위해 서로 분리되어 있습니다. Elasticsearch는 모든 샤드를 통합하고 개발자가 데이터를 쿼리할 수 있는 API를 제공합니다. API를 통해 관리자는 특정 사용자에게 권한을 설정하여 데이터를 더욱 안전하게 보호하고 승인된 사용자에게만 특정 데이터에 대한 액세스를 제공할 수 있습니다.
개발자는 정형 또는 비정형 데이터로 제한되지 않습니다. Elasticsearch를 사용하면 정형 및 비정형 데이터를 모두 가져올 수 있지만, 스토리지가 하나의 대규모 데이터베이스인 것처럼 분산 샤드의 데이터를 쿼리합니다. Elasticsearch가 데이터를 처리하는 방식은 표준 데이터베이스 엔진보다 훨씬 빠르기 때문에, 분석, 많은 데이터 전반에 걸친 검색 기능 또는 네트워크 트래픽 분석을 갖춘 애플리케이션에 가장 적합합니다.
Elasticsearch 아키텍처의 핵심 구성 요소
Elasticsearch의 첫 번째 핵심 구성 요소는 노드입니다. 노드는 데이터가 저장되는 서버 또는 장치입니다. 클러스터는 노드 컬렉션으로 구성됩니다. 노드와 클러스터는 중복성을 위해 데이터센터에 분산될 수 있지만 분산 데이터는 데이터 쿼리의 성능을 향상시킵니다. Elasticsearch는 벡터 데이터베이스이지만 데이터를 문서로 저장합니다. 문서는 비정형 데이터를 저장하는 엔터티이지만, 정형 데이터도 저장할 수 있습니다.
데이터는 노드에 분산되어 있습니다. 샤드는 대규모 데이터스토어를 더 작은 부분으로 분할하기 위한 데이터의 일부이며, 프런트엔드 애플리케이션을 위한 결과 세트에서 데이터를 쉽게 배포하고 동시에 쿼리할 수 있도록 합니다. Logstash는 데이터를 원시 형태로 가져와 사용 가능한 형태로 변환하는 데이터 파이프라인으로 사용됩니다.
Elasticsearch에는 데이터 게이트웨이인 API도 있습니다. 개발자는 API를 인증하고 키로 쿼리해야 합니다. API는 데이터에 대한 액세스와 개발자가 쿼리하는 방법을 제어합니다. 또한 API를 사용하면 백엔드 아키텍처를 가리지 않고 안전하게 보호하므로, 개발자는 Apache Lucene 및 기타 구성 요소가 작동하는 방식에 익숙하지 않게 액세스할 수 있습니다.
노드 및 클러스터
클러스터는 노드 그룹이지만, 노드는 클러스터에서 고유한 역할을 합니다. 일반적으로 마스터 노드는 클러스터를 제어합니다. 마스터 노드는 인덱스를 생성 또는 삭제하고 클러스터에 참여하는 다른 노드를 추적할 수 있습니다. 모든 클러스터에는 마스터 노드가 있습니다.
데이터 노드는 데이터를 저장합니다. 데이터의 조작 또는 변경은 데이터 노드의 책임입니다. 데이터를 집계하면 데이터 노드에 추가됩니다. 검색 기능은 데이터 노드에서도 발생합니다.
조정 노드를 올바른 노드로 트래픽을 제어하는 게이트웨이라고 생각하십시오. 조정 노드는 대상에 따라 마스터 노드 또는 데이터 노드로 요청을 전송합니다. 예를 들어, 검색이 클러스터로 전송되면 조정 노드가 요청을 관리합니다.
Elasticsearch는 데이터 변환 및 이동을 위한 파이프라인을 갖추고 있습니다. 인덱싱을 위해 문서를 관리하고 변환하는 것은 인덱싱 노드의 책임입니다. Elasticsearch는 데이터 전송이 많은 환경에서 마스터 및 데이터 노드와 독립적인 수신 노드를 보유할 것을 권장합니다.
원격 적격 노드는 Elasticsearch 시스템의 다른 클러스터로 요청을 전송합니다. 검색 쿼리는 원격 적격 노드가 있는 교차 클러스터 기능을 사용하여 데이터를 찾을 수 있습니다. 클러스터 전반에 걸친 데이터 복제는 원격 적격 노드의 책임입니다.
조각 및 복제본
빠른 검색과 쿼리에는 인덱스가 필요합니다. 인덱스는 데이터스토어가 검색 속도를 높이는 방식으로 데이터를 구성하는 방법입니다. Elasticsearch에서 각 인덱스는 여러 개의 샤드로 구성됩니다. 샤드는 Elasticsearch가 더 빠른 처리를 위해 클러스터 전반에 분산되는 노드에 저장됩니다. 샤드는 하나의 데이터 복사본을 보유하지만, Elasticsearch는 여러 샤드에 대해 동시 검색을 수행할 수 있습니다.
페일오버 및 내결함성에는 중복이 필요하므로 복제본은 샤드 사본을 처리합니다. 복제본은 여러 노드에 저장되므로 한 노드에 장애가 발생해도 데이터가 손실되지 않습니다. 노드에 장애가 발생하면 Elasticsearch는 다른 노드의 복제본에 있는 데이터에 액세스할 수 있습니다.
Elasticsearch의 데이터 흐름
Elasticsearch는 개발자가 쿼리를 보낼 수 있는 API를 제공합니다. API는 개발자를 백엔드의 복잡성으로부터 보호합니다. 백엔드는 샤드, 노드, 인덱스 및 복제본을 포함한 여러 구성 요소로 구성됩니다. 개발자가 Elasticsearch 연구원을 관리하도록 강요하는 대신, 데이터 흐름은 API에 대한 쿼리로 시작됩니다.
API는 먼저 조정자에게 쿼리를 보냅니다. 코디네이터는 샤드가 있는 적절한 노드로 이를 보냅니다. 쿼리는 또한 각각 자체 데이터 세트가 있는 여러 샤드로 전송할 수 있습니다. 라우팅은 조정자가 수행하며, 조정자가 쿼리에 적합한 샤드를 결정합니다.
샤드가 문서를 수집한 후, 문서의 색인이 코디네이터에게 다시 전송됩니다. 여러 개의 샤드가 데이터를 코디네이터에게 다시 전송하면 코디네이터는 인덱스를 구성하고 병합한 후 정렬합니다. 인덱스가 정렬되면 코디네이터는 샤드에서 실제 문서를 검색합니다. 데이터가 검색되면 API를 통해 애플리케이션으로 다시 전송됩니다.
Elasticsearch 아키텍처 최적화를 위한 모범 사례
Elasticsearch는 일반 데이터베이스 엔진보다 훨씬 복잡하기 때문에 최적화는 다른 접근 방식을 필요로 합니다. 먼저 백엔드에서 충분한 리소스가 실행되고 있는지 확인해야 합니다. 쿼리가 너무 느리면 CPU, 메모리 또는 서버 스토리지 용량을 늘리는 것을 고려하십시오.
인덱스는 데이터를 검색하는 데 필요하지만, 일부 데이터는 다른 데이터만큼 자주 사용되지 않습니다. Elasticsearch를 사용하면 인덱스를 고정할 수 있으며, 사용하지 않은 인덱스는 다른 샤드로 이동합니다. 그런 다음 코디네이터는 모든 쿼리를 검색하는 샤드를 줄여 성능을 향상시킵니다.
Elasticsearch 제어 쿼리 크기의 스레드 풀은 각 쿼리에서 처리되는 데이터의 양을 지원하도록 최적화되어야 합니다. 쿼리에 충분한 데이터를 처리할 수 있도록 스레드 풀을 구성하지만 노드 리소스에도 연결됩니다. 노드와 스레드 풀 모두 충분한 리소스를 보유해야 합니다. 그렇지 않으면 대용량 쿼리 중에 성능이 저하될 수 있습니다.
결론
Elasticsearch는 표준 데이터베이스보다 훨씬 복잡하기 때문에 최적의 성능을 위해서는 올바른 아키텍처와 컴퓨팅 리소스를 확보해야 합니다. Elasticsearch를 구성할 때 모범 사례를 활용하지만, 백엔드에 필요한 쿼리와 데이터 스토리지를 지원할 수 있는 적절한 컴퓨팅 리소스를 확보하는 것도 중요합니다.
충분한 스토리지 리소스를 확보하는 한 가지 방법은 퓨어스토리지의 플래시블레이드(플래시블레이드(FlashBlade))를 활용하는 것입니다. 플래시블레이드(FlashBlade)는 중소기업에서 대기업으로의 기하급수적인 성장을 지원합니다. 애플리케이션은 더 많은 사용자가 데이터를 저장하고 모든 수의 고객을 지원함에 따라 확장될 수 있습니다.
