미래를 여는 검색 솔루션, 스테이트리스 Elasticsearch

Elasticsearch의 시작

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

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

이러한 노력은 Elasticsearch가 다시 한번 진화할 수 있는 토대가 되었습니다. 클라우드 네이티브 서비스와 새로운 오케스트레이션 시스템이 성장함에 따라 클라우드 네이티브 시스템 사용 시의 경험을 개선하기 위해 Elasticsearch를 한 단계 더 발전시켜야 할 때라고 판단했습니다. 이러한 변화는 Elastic Cloud에서 Elasticsearch를 실행하는 동안 운영, 성능 및 비용을 개선할 수 있는 기회를 제공한다고 생각합니다.

Elasticsearch의 미래는 스테이트리스

Elasticsearch를 운영하거나 오케스트레이션할 때의 주요 과제 중 하나는 영구 상태의 수많은 부분에 의존하므로 상태 저장 시스템이라는 점입니다. 세 가지 주요 요소는 트랜스로그, 인덱스 저장소, 클러스터 메타데이터입니다. 이 상태는 저장 공간이 영구적이어야 하며 노드를 다시 시작하거나 교체하는 동안 손실되어서는 안 된다는 것을 의미합니다.

Elastic Cloud의 기존 Elasticsearch 아키텍처는 운영 중단 시 중복성을 제공하기 위해 여러 가용 영역에 걸쳐 색인을 복제해야 합니다. Elastic은 이 데이터의 지속성을 로컬 디스크에서 AWS S3와 같은 객체 저장소로 이동하려고 합니다. 외부 서비스를 사용하여 이 데이터를 저장함으로써 색인 복제의 필요성을 제거하면 수집과 관련된 하드웨어를 크게 줄일 수 있습니다. 또한 AWS S3, GCP Cloud Storage 및 Azure Blob Storage와 같은 클라우드 객체 저장소가 가용 영역 전체에 걸쳐 데이터를 복제하는 방식 때문에 이 아키텍처는 매우 높은 내구성을 보장합니다.

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

몇 개월 동안 개념 증명 및 실험 단계를 거친 후, 이러한 객체 저장소 서비스가 인덱스 저장 공간 및 클러스터 메타데이터에 대해 예상되는 요구 사항을 충족한다는 확신을 갖게 되었습니다. 테스트 및 벤치마크는 이러한 저장 공간 서비스가 Elastic Cloud에서 경험한 대규모 클러스터의 높은 색인 요구 사항을 충족할 수 있음을 보여줍니다. 또한 객체 저장소에서 데이터를 백업하면 색인 비용이 절감되고 검색 성능을 간단하게 조정할 수 있습니다. 데이터를 검색하기 위해 Elasticsearch는 데이터가 클라우드 네이티브 객체 저장소에 영구적으로 유지되고 로컬 디스크가 자주 액세스되는 데이터의 캐시로 사용되는 검증된 검색 가능 스냅샷 모델을 사용합니다.

쉽게 구분할 수 있도록 Elastic에서는 기존 모델을 ‘노드 투 노드’ 복제라고 설명합니다. 이 모델의 핫 티어에서 기본 샤드와 복제본 샤드는 모두 수집을 처리하고 검색 요청을 처리하기 위해 동일한 작업을 수행합니다. 이러한 노드는 호스팅하는 샤드에 대한 데이터를 안전하게 유지하기 위해 로컬 디스크를 사용한다는 점에서 ‘스테이트풀’입니다. 또한 기본 샤드와 복제본 샤드는 지속적으로 통신하여 동기화 상태를 유지합니다. 이는 기본 샤드에서 수행된 작업을 복제본 샤드로 복제함으로써 이루어집니다. 즉, 해당 작업(주로 CPU)의 비용은 지정된 각 복제본에 대해 발생합니다. 수집을 위해 이 작업을 수행하는 동일한 샤드와 노드가 검색 요청 또한 처리하므로 프로비저닝과 확장은 두 워크로드를 모두 고려하여 수행해야 합니다.

노드 투 노드 복제 모델의 샤드는 검색과 수집 외에도 Lucene 세그먼트 병합 등 다른 집중적인 작업도 처리합니다. 이 설계에도 고유의 장점이 있지만, 수년간 고객을 통해 알게 된 내용과 더 광범위한 클라우드 에코시스템의 발전을 바탕으로 많은 가능성을 발견했습니다.

새로운 아키텍처를 사용하면 다음과 같이 많은 즉각적인 개선과 향후 개선이 가능해집니다.

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

벤치마킹 - 색인 처리량 75% 향상 

이 접근 방식을 검증하기 위해 데이터를 단일 노드에서만 색인하고 복제는 클라우드 객체 저장소를 통해 수행하는 광범위한 개념 증명을 구현했습니다. 복제 색인 전용 하드웨어를 사용할 필요성을 제거함으로써 인덱싱 처리량을 75% 향상시킬 수 있다는 것을 확인했습니다. 또한 단순히 객체 저장소에서 데이터를 가져오는 것과 관련된 CPU 비용은 현재 핫 티어에 필요한 것처럼 데이터를 색인하고 로컬로 쓰는 것보다 훨씬 더 저렴했습니다. 이는 검색 노드가 CPU를 온전히 검색에 사용할 수 있음을 의미합니다.

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

색인 처리량

CPU 사용량

사용자에게 절감을 의미하는 스테이트리스 Elasticsearch

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

스테이트리스 비전에 동참 

다른 사람들보다 먼저 이 솔루션을 사용해 보는 것에 관심이 있으신가요? discuss 또는 커뮤니티 Slack 채널을 통해 Elastic에 문의하실 수 있습니다. 새로운 아키텍처의 방향을 구체화하는 데 도움이 될 수 있도록 귀하의 의견을 들려주세요.