엘라스틱 Status update

진행해 주세요. 여러분, 좋은 아침입니다. 환영합니다.

저는 엘라스틱의 투자자관계 담당 부사장 알렉스 커츠먼입니다. 오늘 저희의 새로운 메트릭스 제품을 자세히 살펴보는 자리에 함께해 주셔서 감사합니다. 오늘은 옵저버빌리티 총괄 바하 아자르미와 보안 및 옵저버빌리티 솔루션 담당 수석 부사장 산토시 크리슈난이 함께합니다. 오늘 순서는 먼저 바하가 간략한 프레젠테이션을 진행하고, 이어 짧은 고객 영상을 시청한 다음 질의응답을 진행하는 것으로 구성되어 있습니다. 먼저 법적 고지 사항을 간단히 말씀드리겠습니다. 오늘 발표에는 시장과 당사 제품 및 솔루션에 대한 수요, 그리고 당사 제품 및 솔루션의 예상 기능과 관련된 예측 및 기대를 포함한 미래예측 진술이 포함될 수 있습니다.

이러한 미래예측 진술은 현재 당사가 알고 있는 요인에 근거하며, 본 발표일 현재에 한해 유효하고, 실제 결과가 중대하게 달라질 수 있는 위험과 불확실성의 영향을 받습니다. 법률상 요구되는 경우를 제외하고 이러한 미래예측 진술을 업데이트하거나 수정할 의무는 부담하지 않습니다. 여기에 제시된 위험과 불확실성에 관한 고지 사항과 증권거래위원회 제출 서류에 보다 자세히 설명된 내용을 참조하시기 바랍니다. 그럼 바하에게 넘기겠습니다.

감사합니다, 알렉스. 다음 슬라이드로 넘어가겠습니다. 가능하다면요. 좋습니다. 안녕하세요, 여러분. 저는 바하입니다. 엘라스틱에서 옵저버빌리티를 총괄하고 있습니다. 저는 엘라스틱에서 11년째 근무하고 있으며, 오늘 여러분께 저희의 새로운 메트릭스 제품을 소개하게 되어 기쁘게 생각합니다. 저희의 새로운 메트릭스 제품은 회계연도가 시작된 6월에 거의 맞춰 출시되었습니다. 이 새로운 메트릭스 제품을 통해 저희는 고객의 요구사항을 충족할 뿐만 아니라 시장에서 가장 우수한 메트릭 솔루션들을 능가하는 솔루션으로 이 시장에 진입했습니다. 이 프레젠테이션에서 저희가 어떻게 이를 달성했는지 확인하실 수 있습니다.

큰 틀에서 말씀드리면, 메트릭스를 위해 엘라스틱서치를 새롭게 설계했으며, 고객이 있는 곳에서 고객을 지원하고 있습니다. 또한 오늘날 고객들이 수행하는 작업, 즉 AI 워크로드를 고려해 메트릭 솔루션을 구축하고자 했습니다. 메트릭 솔루션의 특징은 세 가지입니다. 첫째, 매우 빠릅니다. 메트릭 시장에 진입하려면 속도가 빨라야 하며, 이는 솔루션을 개발하는 데 있어 저희가 중시한 원칙 중 하나입니다. 프로메테우스와 미미르 같은 경쟁 솔루션을 대상으로 벤치마크를 실시했습니다. 수치는 이 프레젠테이션 후반부에서 좀 더 자세히 말씀드리겠습니다. 또 한 가지 저희가 한 일은, 고객이 저희와 함께 로그, 트레이스, 메트릭스를 사용하고 있을 때 한 솔루션에서 다른 솔루션으로 옮겨 다니게 하지 않는 것입니다. 고객은 동일한 플랫폼에 머물러야 합니다. 데이터 저장소도 동일해야 합니다.

고객이 옵저버빌리티를 수행할 때 모든 신호를 저희와 함께 저장하고, 엘라스틱에서 데이터를 조회하거나 저희가 제공하는 다양한 옵저버빌리티 환경을 이용하더라도 이러한 과정은 고객에게 완전히 투명하게 이루어져야 합니다. 모든 것이 동일한 플랫폼에 존재합니다. 마지막으로, AI를 위해 구축했습니다. AI로 인해 워크로드의 형태가 기존 애플리케이션 중심에서 에이전트 중심으로 바뀌면서, 이전보다 훨씬 더 많은 신호와 데이터, 메트릭스가 발생하고 있습니다. 따라서 저희는 이러한 새로운 유형의 워크로드를 처리할 수 있도록 메트릭 솔루션을 최대한 효율적으로 설계했습니다. 하지만 저희가 무엇을 했는지 자세히 말씀드리기에 앞서, 모두가 같은 이해를 할 수 있도록 기본적인 내용부터 짚고 넘어가겠습니다. 메트릭스가 무엇인지 익숙하지 않으시다면, 메트릭스는 옵저버빌리티에서 가장 중요한 신호입니다. 사고가 발생했을 때 엔지니어들을 새벽 3시에 말 그대로 잠에서 깨우는 것이 바로 메트릭스입니다.

확인해야 할 문제가 발생하면 담당자에게 알림을 보내는 역할을 합니다. 따라서 옵저버빌리티 솔루션을 사용하면 규칙을 생성하게 됩니다. 이러한 규칙이 알림을 발생시키며, 99%의 경우 이 규칙은 메트릭스를 기반으로 합니다. 화면에 있는 몇 가지 예를 보시겠습니다. 애플리케이션, 즉 웹 애플리케이션이 있고 이 애플리케이션의 트래픽을 확인한다고 가정해 보겠습니다. 예를 들어 HTTP 요청 수를 확인하게 됩니다. 이 애플리케이션은 인프라와 애플리케이션 스택을 기반으로 운영됩니다. 여러 기술이 사용되며 이 앱에 리소스가 할당되어 있습니다. 따라서 CPU와 같은 리소스 사용률을 확인하게 됩니다. 또한 이 애플리케이션을 통해 제공하는 API로 들어오는 요청의 지연 시간과 같은 항목도 확인할 수 있습니다. 이처럼 애플리케이션의 여러 특성이 메트릭스를 생성합니다.

애플리케이션과 인프라가 메트릭스를 생성합니다. 옵저버빌리티 솔루션이 이러한 메트릭스를 수집하고, 이후 담당자에게 알림을 보내는 규칙을 생성하게 됩니다. 달라진 점은 전통적인 애플리케이션, 예를 들어 은행 애플리케이션을 살펴볼 때입니다. 사용자가 직접 은행 계좌에 접속해 거래내역을 확인하고, 거래내역을 스크롤하면서 특정 항목을 클릭한다고 가정해 보겠습니다. 이러한 모든 과정은 매우 전통적인 애플리케이션에서 미리 정의된 경로와 트랜잭션입니다. 프론트엔드, 백엔드, 데이터 저장소, 데이터베이스, 마이크로서비스, 클라우드 배포가 있습니다. 이 모든 것을 저는 전통적인 애플리케이션이라는 범주에 포함시킵니다. 따라서 이러한 트랜잭션은 잘 알려져 있을 뿐만 아니라, 앞서 말씀드렸듯이 트레이스, 로그, 메트릭스도 생성합니다. 따라서 예상할 수 있는 양도 예측 가능합니다.

하지만 에이전트의 경우에는 매우 다릅니다. AI는 메트릭스의 폭발적인 증가를 일으키고 있습니다. AI라고 말씀드릴 때는 LLM 호출, GPU 사이클, RAG 쿼리, 에이전트와 하네스 등 다양한 유형의 워크로드나 관찰해야 하는 항목을 생각하시면 됩니다. 이 모든 것이 새롭게 포착해야 하는 관측 가능성 신호를 만들어내고 있습니다. 여러분도 아시다시피 LLM과 상호작용할 때는 추론 단계가 발생하며, 이러한 추론 단계는 무엇을 요청하느냐에 따라 달라집니다. 이 과정에서 도구 호출로 이어집니다. 이러한 도구가 사전에 반드시 알려져 있는 것은 아닙니다. 이제 에이전트가 MCP를 통해 노출된 기존 애플리케이션을 호출하게 되며, 에이전트와 몇 차례의 상호작용을 하게 될지는 정말 예측하기 어렵습니다. 이로 인해 고객에게 새로운 역설이 생깁니다.

첫째, 고객은 이 모든 데이터를 어떻게 처리할지 고민해야 합니다. 고객에게 불이익을 주는 솔루션이 시장에 존재하며, 고객이 모든 데이터를 보관하지 못하게 된다는 점을 저희도 알고 있습니다. 이렇게 되면 고객은 사각지대를 갖게 된다는 것이 문제입니다. 보관할 수 있는 데이터의 양을 타협해야 합니다. 그러면 장애가 발생했을 때 무슨 일이 있었는지에 대한 완전한 세부 정보를 얻지 못하게 됩니다. 결과적으로 근본 원인이 무엇인지 파악하기가 어려워집니다. AI와 관련된 새로운 과제입니다. 저희는 이 새로운 메트릭스 제품을 어떻게 시장에 출시할지 고민하기 시작하면서 몇 가지 지침 원칙을 세웠으며, 이후 슬라이드에서 이를 더 자세히 설명드리겠습니다.

첫째, 메트릭스를 저장하는 새로운 방식을 도입했으며, 단순히 저장하는 것뿐만 아니라 관리할 수 있도록 했습니다. 여기에는 데이터를 자동으로 집계하거나, 다운샘플링하거나, 압축하는 기능이 포함되어 있습니다. 둘째, 메트릭스 솔루션 사용자가 Elastic을 이용하고 저희의 메트릭스 제품을 사용할 때 익숙하게 느낄 수 있도록 하고자 했습니다. 이를 위해 PromQL과 같이 시장에서 표준으로 사용되는 기술을 지원하는 데 특히 중점을 두었으며, 이에 대해서는 곧 살펴보겠습니다. 마지막으로, 다시 말씀드리지만 AI 규모에 맞춰 구축했습니다. AI가 더 많은 데이터와 새롭게 관찰해야 할 항목을 만들어내고 있다는 점을 보셨을 텐데, 저희는 이러한 워크로드를 처리하는 데 필요한 효율성을 갖추도록 이를 구축했습니다. 아마 엘라스틱은 로그 분야로 알고 계실 것입니다. 고객들은 정리가 잘 되지 않은 로그를 저희에게 맡기고 있습니다. 저희는 이러한 비정형 데이터를 모두 받아들이는 것을 매우 기쁘게 생각합니다.

핵심적으로 저희는 검색 엔진이기 때문에 정형 데이터와 비정형 데이터 모두에 매우 적합합니다. 로그가 유입되면 문서 저장소에 저장됩니다. 저희는 해당 필드를 추출한 다음 집계에 사용할 수 있도록 제공합니다. 이를 대상으로 전체 텍스트 검색을 수행할 수 있습니다. 이것이 로그와 관련해 저희가 어떤 방식으로 처리하는지에 대한 설명입니다. 저희는 문서 저장소를 사용합니다. 메트릭의 경우에는 로그와 형태가 다르기 때문에 상황이 매우 다릅니다. 메트릭에는 숫자가 있고, 레이블이 함께 제공됩니다. 예를 들어 CPU 사용량을 나타내는 숫자와 같은 것이 있습니다. 타임스탬프가 있고, 여러 차원이 있습니다. 해당 메트릭은 특정 호스트에 속하고, 그 호스트는 특정 쿠버네티스 파드에 배포되어 있으며, 해당 파드는 세계의 특정 리전에, 그리고 특정 클라우드 제공업체에 배포되어 있는 식입니다. 이처럼 서로 다른 차원이 매우 많습니다. 메트릭을 처리하기 위해 저희는 엘라스틱서치를 완전히 재설계했습니다.

메트릭에는 고유한 과제가 따르기 때문에 엘라스틱서치 안에 컬럼 저장소를 구축했습니다. 방금 차원에 대해 말씀드렸습니다. 첫째, 차원은 현재 시장에 있는 기존 메트릭 솔루션이 관리하기 매우 어려운 요소입니다. 저희는 카디널리티 측면에서 고객에게 제한을 두지 않도록 하는 데 중점을 두었습니다. 이런 표현은 현재 시장에 나와 있는 메트릭 솔루션과 관련해 자주 듣게 되실 것입니다. 카디널리티는 저희가 제한하고 싶지 않은 요소입니다. 원하시는 만큼 차원을 추가하실 수 있습니다. 그러면 저희는 그렇게 말씀드리는데, 사용자들은 이렇게 반응합니다. "알겠습니다. 그런데 쿼리할 때는 어떤 의미가 있나요?" 차원이 많아지면 모든 데이터를 메모리에서 관리하기가 어려워지기 때문입니다.