무국적 - Elasticsearch를 통한 새로운 검색 상태

대표적인 AI 및 머신 러닝 플랫폼과 원활하게 연동하세요. Elastic의 생성형 AI 기능을 살펴보려면 무료 클라우드 체험을 시작하거나 지금 바로 내 기기에서 사용해 보세요.

상태 저장소가 없는 Elasticsearch를 통해 규모와 속도의 한계를 뛰어넘는 새로운 완전 클라우드 네이티브 아키텍처를 구축하는 데 투자하고 있습니다. 이 블로그에서는 상태 저장소 없는 아키텍처의 도입과 이 아키텍처의 세부 사항을 통해 우리가 어디서부터 시작했는지, Elasticsearch의 미래는 어떤 모습일지 살펴봅니다.

시작점

Elasticsearch의 첫 번째 버전은 2010년에 사용자가 중요한 인사이트를 빠르게 검색하고 표시할 수 있는 분산 확장형 검색 엔진으로 출시되었습니다. 12년이 지나고 65,000개 이상의 커밋이 이루어진 후에도 Elasticsearch는 사용자에게 다양한 검색 문제에 대한 실전에서 검증된 솔루션을 계속 제공하고 있습니다. 수백 명의 정규직 Elastic 직원을 포함해 1,500명이 넘는 기여자들의 노력 덕분에 Elasticsearch는 검색 분야에서 발생하는 새로운 과제를 해결하기 위해 끊임없이 발전해 왔습니다.

데이터 손실에 대한 우려가 제기된 Elasticsearch 출시 초기에 Elastic 팀은 인정된 데이터가 안전하게 저장되도록 클러스터 조정 시스템을 재작성하기 위해 다년간의 노력을 기울였습니다. 대규모 클러스터에서 인덱스를 관리하는 것이 번거롭다는 것이 분명해지자, 팀은 사용자가 인덱스 패턴과 수명 주기 작업을 미리 정의하여 이 작업을 자동화할 수 있는 광범위한 ILM 솔루션을 구현하기 위해 노력했습니다. 사용자들이 상당한 양의 메트릭 및 시계열 데이터를 저장할 필요성을 느끼면서 데이터 크기를 줄이기 위해 더 나은 압축 등 다양한 기능이 추가되었습니다. 방대한 양의 콜드 데이터를 검색하는 데 드는 스토리지 비용이 증가함에 따라 저비용 개체 저장소에서 사용자 데이터를 직접 검색할 수 있는 방법으로 검색 가능한 스냅샷을 만드는 데 투자했습니다.

이러한 투자는 Elasticsearch의 다음 진화를 위한 토대를 마련합니다. 클라우드 네이티브 서비스와 새로운 오케스트레이션 시스템이 성장함에 따라, 우리는 클라우드 네이티브 시스템으로 작업할 때의 경험을 개선하기 위해 Elasticsearch를 발전시켜야 할 때라고 판단했습니다. 이러한 변화는 Elastic Cloud에서 Elasticsearch를 실행하면서 운영, 성능 및 비용을 개선할 수 있는 기회를 제공한다고 생각합니다.

우리가 나아갈 방향 - 무국적 아키텍처 채택

Elasticsearch를 운영하거나 오케스트레이션할 때의 주요 과제 중 하나는 수많은 영구 상태 조각에 의존하기 때문에 상태 저장 시스템이라는 점입니다. 세 가지 주요 요소는 번역, 인덱스 저장소, 클러스터 메타데이터입니다. 이 상태는 스토리지가 영구적이어야 하며 노드를 다시 시작하거나 교체하는 동안 손실되지 않아야 함을 의미합니다.

Elastic Cloud의 기존 Elasticsearch 아키텍처는 중단 시 중복성을 제공하기 위해 여러 가용성 영역에 걸쳐 인덱싱을 복제해야 합니다. 이 데이터의 지속성을 로컬 디스크에서 AWS S3와 같은 객체 저장소로 옮길 계획입니다. 이 데이터를 저장하기 위해 외부 서비스에 의존함으로써 인덱싱 복제의 필요성을 없애고 수집과 관련된 하드웨어를 크게 줄일 수 있습니다. 또한 이 아키텍처는 AWS S3, GCP 클라우드 스토리지, Azure Blob 스토리지와 같은 클라우드 개체 저장소가 가용 영역 간에 데이터를 복제하는 방식 덕분에 매우 높은 내구성을 보장합니다.

인덱스 저장소를 외부 서비스로 오프로드하면 인덱싱과 검색 책임을 분리하여 Elasticsearch를 다시 설계할 수도 있습니다. 기본 인스턴스와 복제 인스턴스가 두 워크로드를 모두 처리하는 대신, 인덱싱 티어와 검색 티어를 만들려고 합니다. 이러한 워크로드를 분리하면 독립적으로 확장할 수 있고 하드웨어를 각 사용 사례에 맞게 더 세분화하여 선택할 수 있습니다. 또한 검색과 색인 부하가 서로 영향을 미칠 수 있는 오랜 문제를 해결하는 데 도움이 됩니다.

수개월에 걸친 개념 증명과 실험 단계를 거친 결과, 이러한 개체 저장소 서비스가 인덱스 스토리지와 클러스터 메타데이터에 대해 우리가 구상하는 요구 사항을 충족한다고 확신하게 되었습니다. 테스트와 벤치마크 결과, 이러한 스토리지 서비스는 Elastic Cloud에서 본 최대 규모의 클러스터의 높은 인덱싱 요구 사항을 충족할 수 있는 것으로 나타났습니다. 또한 개체 저장소에 데이터를 백업하면 인덱싱 비용이 절감되고 검색 성능을 간단하게 조정할 수 있습니다. 데이터를 검색하기 위해 Elasticsearch는 데이터가 클라우드 네이티브 개체 저장소에 영구적으로 보존되고 로컬 디스크가 자주 액세스하는 데이터의 캐시로 사용되는, 수많은 테스트를 거친 검색 가능한 스냅샷 모델을 사용합니다.

차별화를 위해 기존 모델을 "노드 간" 복제라고 설명합니다. 이 모델의 핫 티어에서는 기본 샤드와 복제 샤드 모두 수집을 처리하고 검색 요청을 제공하기 위해 동일한 작업을 수행합니다. 이러한 노드는 로컬 디스크에 의존하여 호스팅하는 샤드의 데이터를 안전하게 유지한다는 점에서 "stateful" 입니다. 또한 기본 샤드와 복제 샤드는 동기화 상태를 유지하기 위해 지속적으로 통신합니다. 이는 기본 샤드에서 수행된 작업을 복제 샤드로 복제하는 방식으로 이루어지며, 이는 지정된 각 복제본에 대해 해당 작업의 비용(주로 CPU)이 발생한다는 의미입니다. 수집을 위해 이 작업을 수행하는 동일한 샤드와 노드가 검색 요청도 처리하므로 프로비저닝과 확장은 두 가지 워크로드를 모두 염두에 두고 수행해야 합니다.

노드 간 복제 모델의 샤드는 검색 및 수집 외에도 Lucene 세그먼트 병합과 같은 다른 집중적인 작업을 처리합니다. 이러한 설계에도 장점이 있지만, 수년 동안 고객과 함께 배운 점과 광범위한 클라우드 에코시스템의 진화를 바탕으로 많은 기회를 발견했습니다.

새로운 아키텍처를 통해 다음과 같은 많은 즉각적인 개선과 향후 개선이 가능합니다:

1. 동일한 하드웨어에서 수집 처리량을 크게 늘리거나, 다른 방식으로 말하면 동일한 수집 워크로드의 효율성을 크게 개선할 수 있습니다. 이러한 증가는 모든 복제본에 대한 인덱싱 작업의 중복을 제거한 결과입니다. CPU 집약적인 인덱싱 작업은 인덱싱 계층에서 한 번만 수행하면 결과 세그먼트를 오브젝트 저장소로 전송합니다. 이제 검색 계층에서 데이터를 그대로 사용할 수 있습니다.
2. 컴퓨팅과 스토리지를 분리하여 클러스터 토폴로지를 간소화할 수 있습니다. 현재 Elasticsearch는 데이터를 하드웨어 프로필과 일치시키기 위해 여러 데이터 계층(콘텐츠, hot, warm, cold, frozen)을 갖추고 있습니다. 핫 티어는 실시간에 가까운 검색을 위한 것이고, 프로즌은 검색 빈도가 낮은 데이터를 위한 것입니다. 이러한 계층은 가치를 제공하지만 복잡성을 증가시키기도 합니다. 새로운 아키텍처에서는 데이터 계층이 더 이상 필요하지 않으므로 Elasticsearch의 구성과 운영이 간소화됩니다. 또한 인덱싱과 검색을 분리하여 복잡성을 더욱 줄이고 두 워크로드를 독립적으로 확장할 수 있도록 하고 있습니다.
3. 로컬 디스크에 저장해야 하는 데이터의 양을 줄임으로써 인덱싱 계층의 스토리지 비용을 개선할 수 있습니다. 현재 Elasticsearch는 인덱싱을 위해 핫 노드(기본 및 복제본 모두)에 전체 샤드 복사본을 저장해야 합니다. 오브젝트 저장소에 직접 인덱싱하는 상태 비저장 방식에서는 해당 로컬 데이터의 일부만 필요합니다. 추가 전용 사용 사례의 경우 인덱싱을 위해 특정 메타데이터만 저장하면 됩니다. 이렇게 하면 인덱싱에 필요한 로컬 저장 공간을 크게 줄일 수 있습니다.
4. 검색 쿼리와 관련된 스토리지 비용을 절감할 수 있습니다. 검색 가능한 스냅샷 모델을 데이터 검색의 기본 모드로 설정하면 검색 쿼리와 관련된 스토리지 비용이 크게 감소합니다. 사용자의 검색 대기 시간 요구 사항에 따라 Elasticsearch는 자주 요청되는 데이터에 대한 로컬 캐싱을 늘리도록 조정할 수 있습니다.

벤치마킹 - 75% 인덱싱 처리량 개선

이 접근 방식을 검증하기 위해 단일 노드에서만 데이터를 인덱싱하고 클라우드 개체 저장소를 통해 복제를 수행하는 광범위한 개념 증명을 구현했습니다. 인덱싱 복제에 전용 하드웨어를 사용할 필요가 없어짐으로써 인덱싱 처리량을 75%(% ) 향상시킬 수 있다는 사실을 발견했습니다. 또한, 단순히 개체 저장소에서 데이터를 가져오는 것과 관련된 CPU 비용은 오늘날 핫 티어에 필요한 것처럼 데이터를 인덱싱하고 로컬에 쓰는 것보다 훨씬 낮았습니다. 즉, 검색 노드는 CPU를 검색에 전적으로 사용할 수 있게 됩니다.

이러한 성능 테스트는 3대 퍼블릭 클라우드 제공업체(AWS, GCP, Azure) 모두에 대해 2노드 클러스터에서 수행되었습니다. 프로덕션 상태 비저장 구현을 추진하면서 더 큰 규모의 벤치마크를 계속 구축할 계획입니다.

인덱싱 처리량

CPU 사용량

우리는 무국적자, 당신은 절약

Elastic Cloud의 상태 저장소 없는 아키텍처를 사용하면 색인 오버헤드를 줄이고, 수집과 검색을 독립적으로 확장하며, 데이터 계층 관리를 간소화하고, 확장이나 업그레이드와 같은 운영을 가속화할 수 있습니다. 이것은 Elastic Cloud 플랫폼의 실질적인 현대화를 향한 첫 번째 이정표입니다.

Elasticsearch 상태 저장소 없는 비전의 일부가 되세요.

다른 사람들보다 먼저 이 솔루션을 사용해보고 싶으신가요? 토론이나 커뮤니티 슬랙 채널에서 문의하실 수 있습니다. 새로운 아키텍처의 방향을 설정하는 데 도움이 되는 여러분의 피드백을 기다립니다.