Elastic의 Elastic Cloud Serverless 구축 여정

지난 수년 동 고객의 기대치는 크게 변화했습니다. 사용자는 더 이상 크기 조정, 모니터링, 확장 등 인프라 관리의 복잡성을 신경 쓰고 싶어하지 않습니다. 대신 워크로드에만 집중할 수 있는 원활한 환경을 원합니다. 이러한 변화하는 수요에 발맞춰 운영 오버헤드를 줄이고, 원활한 SaaS 경험을 제공하며, 사용량 기반 가격 책정 모델을 도입하는 솔루션을 구축하게 되었습니다. 고객이 리소스를 수동으로 프로비저닝하고 유지관리할 필요가 없도록 함으로써 수요에 따라 동적으로 확장하는 동시에 효율성을 최적화하는 플랫폼을 만들었습니다.

Elastic Cloud Serverless는 고객 수요를 따르기 위해 빠르게 확장되고 있으며, 2024년 12월 AWS, 2025년 4월 GCP, 2025년 6월 Azure에 정식 출시(GA)되었습니다. 그 이후로 AWS에서 4개 리전, GCP에서 3개 리전, Azure에서 1개 리전으로 확장되었으며, 3개 클라우드 서비스 공급 업체(CSP) 모두에 추가 리전을 확장할 계획입니다.

Elastic Cloud Hosted(ECH)는 원래 유상태(stateful) 시스템으로 구축되었으며, 데이터 내구성을 보장하기 위해 로컬 NVMe 기반 저장 공간 또는 관리형 디스크에 의존합니다. Elastic Cloud가 전 세계적으로 확장됨에 따라, Elastic은 운영 효율성과 장기적인 성장을 더 잘 지원하기 위해 아키텍처를 발전시킬 기회를 발견했습니다. 분산 환경 전반에서 영구 상태를 관리하는 호스팅 방식은 효과적이었지만, 노드 교체, 유지 관리, 가용성 영역 전반의 중복성 보장, 색인 및 검색과 같은 컴퓨팅 집약적인 워크로드 확장과 관련하여 운영상의 복잡성이 증가했습니다.

Elastic은 무상태(stateless) 방식을 도입하여 시스템 아키텍처를 발전시키기로 결정했습니다. 핵심적인 변화는 영구 저장소를 컴퓨팅 노드에서 클라우드 네이티브 객체 저장소로 오프로드하는 것이었습니다. 이를 통해 인덱싱에 필요한 인프라 오버헤드 감소, 검색/색인 분리, 복제 필요성 제거, CSP의 내장된 이중화 메커니즘을 활용한 데이터 내구성 향상 등 다양한 이점을 얻을 수 있었습니다.

아키텍처의 주요 변화 중 하나는 클라우드 네이티브 객체 저장소를 기본 데이터 저장소로 사용하는 것이었습니다. ECH는 로컬 NVMe SSD 또는 관리형 SSD 디스크에 데이터를 저장하도록 설계되었습니다. 그러나 데이터 양이 증가함에 따라 저장 공간을 효율적으로 확장하는 데 따르는 어려움도 커졌습니다. 그 후, ECH에 검색 가능한 스냅샷을 도입하여 객체 저장소에서 데이터를 직접 검색할 수 있게 되어 저장 비용을 크게 절감할 수 있었지만, 여기서 한 발 더 나아가야 했습니다. 

주요 과제는 Elasticsearch 사용자가 기대하는 성능 수준을 유지하면서 객체 저장소가 고속 데이터 수집 워크로드를 처리할 수 있는지를 판단하는 것이었습니다. 엄격한 테스트와 구현을 통해 객체 저장 공간이 대규모 색인 작업의 요구를 충족할 수 있음을 검증했습니다. 객체 저장소으로 전환하면서 색인 복제의 필요성이 없어지고 인프라 요구 사항을 줄어들었으며 가용성 영역 간 데이터 복제를 통해 내구성을 강화하여 가용성과 복원력을 보장할 수 있게 되었습니다.

아래 다이어그램은 기존 'ECH' 아키텍처와 비교하여 새로운 '무상태' 아키텍처를 설명합니다.

ECH는 자체 개발한 컨테이너 오케스트레이터를 사용하며, 이 오케스트레이터는 Elastic Cloud Enterprise(ECE)를 지원합니다. ECE 개발은 Kubernetes(K8s)가 존재하기 전에 시작되었기 때문에, 서버리스를 지원하기 위해 ECE를 확장하거나 K8s를 사용하는 두 가지 선택지가 있었습니다. 업계 전반에서 K8이 빠르게 도입되고 관련 에코시스템이 성장함에 따라, 운영 및 확장 목표에 부합하는 Elastic Cloud Serverless의 CSP 전반에 걸쳐 관리형 Kubernetes 서비스를 채택하기로 결정했습니다.

Kubernetes를 도입하여 운영 복잡성을 줄이고 API를 표준화하여 확장성을 개선했으며 장기적인 혁신을 위해 Elastic Cloud의 입지를 강화했습니다. Kubernetes를 통해 컨테이너 오케스트레이션을 새로 만들 필요 없이, 더 높은 가치의 기능에 집중할 수 있었습니다.

Kubernetes로 전환하는 과정에서 Kubernetes 클러스터를 직접 관리할지 아니면 CSP에서 제공하는 관리형 Kubernetes 서비스를 사용할지 결정해야 했습니다. Kubernetes 구현 방식은 CSP마다 상당히 다르지만, 배포 일정을 단축하고 운영 오버헤드를 줄이기 위해 AWS, GCP 및 Azure에서 CSP 관리형 Kubernetes 서비스를 선택했습니다. 이 접근 방식을 통해 복잡한 Kubernetes 클러스터 관리 문제를 처리하는 대신 애플리케이션 구축과 업계 모범 사례 채택에 집중할 수 있었습니다. 

핵심 요구 사항에는 여러 CSP에서 일관되게 Kubernetes 클러스터를 프로비저닝하고 관리하는 기능, 컴퓨팅, 저장 공간 및 데이터베이스 관리를 위한 클라우드 중립적인 API, 비용 효율적이고 간소화된 운영이 포함되었습니다. 또한 CSP 관리형 Kubernetes를 선택함으로써 Crossplane과 같은 오픈 소스 프로젝트에 업스트림으로 기여하여 전반적인 Kubernetes 에코시스템을 개선하는 동시에 진화하는 기능의 혜택을 누릴 수 있었습니다.

Kubernetes 클러스터당 수만 개의 파드를 사용하여 대규모로 Kubernetes를 운영하려면 클라우드 중립적이고, 지연 시간을 최소화하면서 고성능을 제공하며, 고급 보안 정책을 지원하는 네트워킹 솔루션이 필요합니다. 이러한 요구 사항을 해결하기 위해 최신 eBPF 기반 솔루션인 Cilium을 선택했습니다. 처음에는 모든 CSP에 걸쳐 균일한 자체 관리형 Cilium 솔루션을 구현하는 것을 목표로 했습니다. 하지만 클라우드 구현 방식의 차이로 인해 AWS에서 자체 관리형 배포를 유지관리하면서 사용 가능한 경우 CSP 네이티브 Cilium 솔루션을 사용하는 하이브리드 접근 방식을 채택하게 되었습니다. 이러한 유연성 덕분에 불필요한 복잡성 없이 성능 및 보안 요구 사항을 충족할 수 있었습니다.

인그레스에는 기존에 ECH에서 검증된 프록시를 적응시켜 계속 사용하기로 결정했습니다. 평가의 핵심은 단순히 프록시를 기성 솔루션으로 대체할 수 있는지 여부가 아니라 대체해야 하는지 여부였습니다.

표준 리버스 프록시도 기본적인 기능은 제공하지만, ECH 프록시가 이미 처리하고 있는 차별화된 기능들을 제공하기엔 부족합니다. 표준 리버스 프록시를 사용했다면 인그레스 트래픽 필터를 위한 확장 기능, AWS PrivateLink 및 Google Cloud Private Service Connect 지원, 그리고 FIPS 준수 TLS 종단 처리를 구축해야 했을 것입니다. 또한 기존 프록시는 이미 모든 관련 규정 준수 감사 및 침투 테스트를 통과했습니다.

새로운 솔루션으로 시작하는 것은 추가적인 고객 가치를 제공하지 않으면서도 상당한 노력이 필요했을 것입니다. 프록시를 Kubernetes에 맞게 적용하는 과정에서는 주로 서비스 엔드포인트 인지 배포 방식을 업데이트하는 작업이 필요했으며, 핵심적이고 충분히 검증된 기능들은 그대로 유지할 수 있었습니다. 이 접근 방식은 여러 가지 이점을 제공합니다.

• ECH와 Kubernetes 간에 고객이 볼 수 있는 동작이 일관되게 유지됩니다.

• 특히 기성 솔루션에서 스크립팅이나 확장이 필요한 새로운 기능을 구현할 때 팀은 친숙하고 잘 알고 있는 코드베이스를 사용하여 더 효율적으로 작업할 수 있습니다.

• 단일 코드베이스로 ECH와 Kubernetes Platform을 모두 발전시킬 수 있어, 한 환경에서의 개선이 다른 환경에서의 개선으로 이어집니다.

• 지원팀은 기존 지식을 활용하여 새로운 플랫폼에 대한 학습 곡선을 줄일 수 있습니다.

Elastic Cloud Serverless를 위해 Kubernetes를 선택한 후, Crossplane을 인프라 관리 도구로 선택했습니다. Crossplane은 Kubernetes API를 확장하는 오픈 소스 프로젝트로, Kubernetes 네이티브 도구와 사례를 사용하여 클라우드 인프라 및 서비스를 프로비저닝하고 관리할 수 있도록 지원합니다. 사용자는 Kubernetes 클러스터 내에서 여러 CSP에 걸쳐 클라우드 리소스를 프로비저닝, 관리 및 오케스트레이션할 수 있습니다. 이는 맞춤형 리소스 정의(CRD)를 활용하여 클라우드 리소스를 정의하고 컨트롤러를 통해 Kubernetes 매니페스트에 지정된 원하는 상태와 여러 CSP에 걸쳐 있는 클라우드 리소스의 실제 상태를 조정함으로써 구현됩니다. Kubernetes의 선언적 구성 및 제어 메커니즘을 활용하여 인프라를 코드로 관리하는 일관되고 확장 가능한 방법을 제공합니다.

Crossplane은 서비스 배포에 사용되는 동일한 도구와 방법을 사용하여 인프라를 관리하고 프로비저닝할 수 있도록 지원합니다. 여기에는 Kubernetes 리소스, 일관된 GitOps 아키텍처, 통합 가시성 도구를 활용하는 것이 포함됩니다. 또한 개발자는 프로덕션 환경을 미러링하는 주변 인프라를 포함하여 완전한 Kubernetes 기반 개발 환경을 구축할 수 있습니다. 두 환경은 동일한 기본 코드에서 생성되므로, 단순히 Kubernetes 리소스를 생성하는 것만으로 이를 구현할 수 있습니다.

일반적으로 클라우드 용량이 무한하다고 생각하지만, 실제로는 CSP에서 제약 조건을 부과하기에 ‘용량 부족’ 오류가 발생할 수 있습니다. 인스턴스 유형을 사용할 수 없는 경우 계속해서 재시도하거나 대체 인스턴스 유형으로 전환해야 합니다.

Elastic Cloud Serverless에서는 이 문제를 완화하기 위해 우선순위 기반 용량 풀을 구현하여 필요할 때 워크로드를 신규/기타 용량 풀로 마이그레이션할 수 있도록 했습니다. 또한 수요 급증에 대비하여 컴퓨팅 리소스를 예약하는 선제적 용량 계획에 투자했습니다. 이러한 메커니즘은 고가용성을 보장하는 동시에 리소스 활용을 최적화합니다.

Kubernetes 클러스터 업그레이드에는 시간이 많이 소요됩니다. 이를 간소화하기 위해 완전히 자동화된 엔드투엔드 프로세스를 활용하며, 자동으로 해결할 수 없는 문제에 대해서만 수동 개입이 필요합니다. 내부 테스트가 완료되고 새로운 Kubernetes 버전이 승인되면 중앙에서 해당 버전을 구성합니다. 그런 다음 자동화된 시스템이 각 클러스터에 대해 컨트롤 플레인 업그레이드를 시작하여 동시성을 제어하고 특정 순서를 지정합니다. 그 이후, 맞춤형 Kubernetes 컨트롤러가 블루-그린 배포를 수행하여 노드 풀을 업그레이드합니다. 이 과정에서 고객 파드가 다른 K8s 노드로 마이그레이션되지만, 프로젝트 가용성과 성능에는 영향을 미치지 않습니다.

셀 기반 아키텍처를 사용하여 확장성과 복원력을 모두 갖춘 서비스를 제공합니다. 모든 Kubernetes 클러스터와 주변 인프라는 별도의 CSP 계정에 배포되어 CSP 제한에 영향을 받지 않고 적절한 확장이 가능하며 최대한의 보안과 격리를 제공합니다. 각각 별도의 셀로 구성된 개별 워크로드는 시스템의 특정 측면을 관리합니다. 이러한 셀은 독립적으로 작동하여 격리된 확장 및 관리가 가능합니다. 이러한 모듈식 설계는 장애 발생 범위를 최소화하고 목표에 따라 쉽게 확장할 수 있어 시스템 전체에 미치는 영향을 방지합니다. 문제로 인한 잠재적 영향을 더욱 최소화하기 위해 애플리케이션과 기본 인프라 모두에 카나리아 배포를 사용합니다.

진정한 서버리스 환경을 제공하기 위해서는 워크로드 수요에 따라 리소스를 동적으로 조정하는 지능형 자동 확장 메커니즘이 필요했습니다. Elastic의 여정은 기본적인 수평적 확장에서 시작되었지만, 서비스마다 고유한 확장 요구 사항이 있다는 것을 금방 깨달았습니다. 일부는 추가 컴퓨팅 리소스가 필요했고, 다른 일부는 더 많은 메모리 할당을 요구했습니다.

실시간 워크로드별 메트릭을 분석하는 맞춤형 자동 확장 컨트롤러를 구축하여 반응성과 리소스 효율성을 모두 갖춘 동적 확장을 구현함으로써 접근 방식을 발전시켰습니다.  그 결과, Elasticsearch에 대한 과도한 프로비저닝 없이도 Elasticsearch의 색인 및 검색 티어 작업을 모두 원활하게 확장할 수 있게 되었습니다. 또한 이 전략을 통해 다차원 파드 자동 확장을 사용하여 CPU, 메모리 및 워크로드에서 생성된 맞춤형 메트릭을 기반으로 워크로드를 수평 및 수직으로 확장할 수 있습니다.

Elasticsearch 워크로드의 경우, 클러스터에 대한 특정 주요 메트릭을 반환하는 서버리스 전용 Elasticsearch API를 사용합니다. 작동 방식은 다음과 같습니다. 추천자는 주어진 티어에 필요한 컴퓨팅 리소스(복제본, 메모리 및 CPU)와 저장 공간을 제안합니다. 그런 다음 매핑 장치는 이러한 권장 사항을 컨테이너에 적용할 수 있는 구체적인 컴퓨팅 및 저장 공간 구성으로 변환합니다. 안정화 장치는 급격한 확장 변동을 방지하기 위해 이러한 권장 사항을 필터링합니다. 그런 다음 제한 장치가 작동하여 최소 및 최대 리소스 제약 조건을 모두 적용합니다. 제한 장치의 출력은 몇 가지 선택적인 제한 정책을 고려한 후 Kubernetes 배포를 패치하는 데 사용됩니다.

서버리스 컴퓨팅의 주요 원칙 중 하나는 실제 사용량에 맞춰 비용을 조정하는 것입니다. Elastic은 간단하고 유연하며 투명한 가격 모델을 원했습니다. 다양한 접근 방식을 평가한 후, 핵심 솔루션 전반에서 서로 다른 워크로드의 균형을 맞추는 모델을 설계했습니다.

• Observability 및 Security: 수집 및 보존된 데이터를 기준으로 요금이 부과되며, 계층화된 가격 책정 적용

• Elasticsearch(Search): 수집, 검색, 머신 러닝 및 데이터 보존을 포함한 가상 컴퓨팅 단위를 기반으로 한 가격 책정

이 접근 방식은 고객에게 사용량 기반 가격을 제공하여 유연성과 비용 예측 가능성을 높입니다. 

또한 Elastic은 개발 단계에서 여러 차례 수정을 거친 이 가격 책정 모델을 구현하기 위해서는 확장성 있는 유연한 아키텍처가 필요하다는 점을 인지했습니다. 그리하여 궁극적으로 엔드투엔드 프로세스의 여러 구성 요소를 담당하는 여러 팀이 분산형 소유권 모델을 지원하는 파이프라인을 구축했습니다. 아래에서는 이 파이프라인의 두 가지 주요 부분, 즉 사용량 파이프라인을 통한 사용량 측정 데이터 수집과 청구 파이프라인을 통한 청구 계산에 대해 설명합니다.

Elasticsearch와 Kibana 같은 사용자용 구성 요소는 각 워크로드 클러스터에서 실행되는 측정된 사용량 데이터를 사용량 API 서비스로 전송합니다. 이 서비스는 데이터를 일부 보강한 후 대기열에 저장합니다. 그러면 사용량 수집기 서비스는 이 데이터를 대기열에서 가져와 객체 저장소로 전달합니다. 이러한 분리형 아키텍처는 여러 리전과 CSP 간에 데이터를 전송할 때 파이프라인의 복원력을 확보하기 위해 필수적입니다. Elastic은 지연 시간보다 전송을 우선시하기 때문입니다. 데이터가 객체 저장소에 도달하면 다른 프로세스에서 추가 변환 또는 집계(예: 청구 또는 분석)를 위해 읽기 전용 방식으로 사용할 수 있습니다.

여러 CSP에 걸쳐 유사한 기능을 제공하는 인프라 플랫폼을 구축하는 것은 복잡한 과제입니다. 안정성, 확장성, 비용 효율성을 균형 있게 유지하려면 지속적인 반복과 절충이 필요합니다. 클라우드 서비스 제공 업체마다 Kubernetes 구현 방식이 상당히 다르기에, 일관된 사용자 경험을 보장하기 위해서는 광범위한 테스트와 맞춤화가 필요합니다.

게다가 서버리스 아키텍처를 채택하는 것은 기술적 변화일 뿐만 아니라 문화적 변화이기도 합니다. 사후 대응적인 문제 해결에서 사전 예방적인 시스템 최적화로 전환하고, 운영 부담을 최소화하기 위해 자동화를 우선시해야 합니다. 이러한 여정을 통해, 성공적인 서버리스 플랫폼을 구축하는 데에는 아키텍처 결정만큼이나 지속적인 혁신과 개선을 수용하는 마음가짐을 갖추는 것이 중요하다는 것을 배웠습니다.

서버리스 환경에서 성공하려면 탁월한 고객 경험을 제공하고 운영을 선제적으로 최적화하며 안정성, 확장성, 비용 효율성 간의 균형을 지속적으로 유지해야 합니다. 앞으로도 Elastic은 Elastic Cloud Serverless에서 고객을 위한 새로운 기능을 개발하여, 서버리스가 모든 사용자에게 최고의 Elasticsearch 실행 환경이 될 수 있도록 하는 데 최선을 다하고 있습니다.

속도, 확장성, 비용 어느 것도 타협하지 않는 새로운 검색, 보안, 그리고 통합 가시성의 미래가 지금 여기에 있습니다. Elastic Cloud Serverless와 Search AI Lake를 통해 데이터에서 새로운 기회를 발견해 보세요. 서버리스의 가능성에 대해 자세히 알아보거나지금 바로 무료 체험판을시작해 보세요.

이 게시물에서 설명된 모든 기능이나 성능의 출시와 일정은 Elastic의 단독 재량에 따라 결정됩니다. 현재 제공되지 않는 기능이나 성능은 예정된 시간에 출시되지 않을 수도 있으며 아예 제공되지 않을 수도 있습니다.

해당 블로그 게시물에서는 타사 생성형 AI 도구를 사용하거나 언급했을 수 있으며 이러한 도구는 각각의 소유자가 소유하고 운영합니다. Elastic은 이러한 타사 도구에 대한 어떠한 통제권이 없으며 해당 도구의 콘텐츠, 운영, 사용뿐만 아니라 사용으로 인해 발생할 수 있는 손실이나 손해에 대해 어떠한 책임도 지지 않습니다. 개인 정보, 민감한 정보 또는 기밀 정보를 AI 도구와 함께 사용할 때는 주의하시기 바랍니다. 제출된 모든 데이터는 AI 학습이나 기타 목적으로 사용될 수 있습니다. 제공한 정보가 안전하게 보호되거나 비밀로 유지된다는 보장은 없습니다. 생성형 AI 도구를 사용하기 전에 해당 도구의 개인정보 보호 관행과 이용 약관을 숙지하시기 바랍니다. 

Elastic, Elasticsearch 및 관련 마크는 미국 및 기타 국가에서 Elasticsearch N.V.의 상표, 로고 또는 등록 상표입니다 그 외의 모든 회사 및 제품 이름은 해당 소유자의 상표, 로고 또는 등록 상표입니다.