Dzmitry Lazerka, VictoriaMetrics 공동 설립자 – 인터뷰 시리즈

Dzmitry Lazerka, VictoriaMetrics 공동 설립자는 머신러닝, 대규모 데이터 시스템, 가시성 및 인프라에 깊은 전문성을 가진 숙련된 소프트웨어 엔지니어이자 기술 리더입니다. 2018년에 VictoriaMetrics를 공동 설립하기 전, 그는 Lyft의 Level 5 자율주행 차량 부서에서 머신러닝 엔지니어로 근무하며 실제 주행 시나리오를 인식하고 분석하는 시스템 개발에 기여했습니다. 이전에는 Spire Global에서 머신러닝 및 데이터 인프라 프로젝트를 이끌었으며, Bellgram에서 엔지니어링 공동 설립자로 활동했고, EPAM Systems를 통해 Duetto Research와 Google에서 데이터 및 분석 시스템 작업을 수행했습니다. 그의 경력 전반에 걸쳐 Lazerka는 자율주행, 해양 예측, 검색, 분석, 분산 데이터 처리 및 고확장 백엔드 시스템 등 다양한 프로젝트를 구축하고 이끌어 왔습니다.

VictoriaMetrics는 대량의 운영 데이터를 수집·저장·쿼리·분석하기 위한 도구를 제공하는 오픈소스 가시성 기업입니다. 이 기술은 확장성, 빠른 쿼리, 효율적인 저장 및 낮은 운영 오버헤드를 목표로 설계된 고성능 시계열 데이터베이스 및 모니터링 솔루션인 VictoriaMetrics에서 시작했으며, 이후 VictoriaMetrics, VictoriaLogs, VictoriaTraces를 통해 메트릭, 로그, 분산 트레이스를 포괄하는 보다 넓은 가시성 스택으로 확장되었습니다. 또한 기업용 및 완전 관리형 클라우드 배포 옵션을 제공하고, 시계열 데이터에 머신러닝을 적용한 이상 탐지 기능도 포함합니다. 이 플랫폼은 OpenTelemetry, Prometheus 호환 워크플로, Grafana, Kubernetes 등 다양한 기술을 지원해 조직이 기존 가시성 환경에 VictoriaMetrics를 유연하게 통합할 수 있도록 합니다.

VictoriaMetrics를 공동 설립하기 전, Google, Spire Global, Lyft의 자율주행 차량 부서 및 기타 스타트업에서 대규모 데이터, 분석 및 머신러닝 시스템을 다루셨습니다. 궁극적으로 VictoriaMetrics를 설립하게 된 계기는 무엇이며, 이전 역할에서 어떤 문제들이 모니터링과 가시성에 근본적인 새로운 접근이 필요하다고 확신하게 만들었나요?

저는 커리어 전반에 걸쳐 방대한 데이터를 다뤄왔습니다. Google, Spire, Lyft 및 기타 기업에서 일하면서 한 규모에서는 잘 작동하던 것이 다른 규모에서는 비용이 많이 들거나 운영이 어려워질 수 있다는 것을 빠르게 깨달았습니다. 모니터링도 바로 이런 문제를 가지고 있습니다.

인프라가 성장함에 따라 메트릭이 늘어나고, 서비스와 인스턴스, 라벨이 추가되면서 어느 순간 모니터링 시스템 자체가 상당한 인프라를 필요로 하게 됩니다. 이는 우리에게 전혀 타당하지 않았습니다. 프로덕션 환경을 모니터링하도록 설계된 시스템이 더 복잡해지고 운영 비용이 증가해서는 안 됩니다.

이는 공동 설립자 Aliaksandr Valialkin와 Roman Khavronenko가 직접 목격한 내용입니다. 그들은 Prometheus 운영 경험이 있었고 메모리 제한에 부딪혔습니다. Thanos와 같은 시스템을 추가하면 일부 확장성 문제는 해결되지만, 더 많은 구성 요소와 운영 복잡성이 증가합니다. 또한 InfluxDB에서는 라이선스 정책 변경이 이미 기술에 투자한 팀의 엔지니어링 결정에 어떤 영향을 미치는지 확인했습니다.

따라서 VictoriaMetrics의 아이디어는 실용적이었습니다: 동일한 작업을 훨씬 적은 자원으로 수행하고 운영이 더 간단한 시계열 데이터베이스를 만들 수 있을까?

우리는 대규모 가시성 회사를 만들겠다는 계획으로 시작한 것이 아니라, 엔지니어링 문제를 해결하는 것부터 시작했습니다.

이를 오픈소스로 만드는 것이 그 일환이었습니다. 엔지니어들은 VictoriaMetrics를 다운로드해 실제 프로덕션 워크로드를 적용하고 직접 결과를 비교할 수 있었습니다. 우리가 그것이 더 빠르거나 효율적이라고 말할 필요가 없었고, 엔지니어들이 직접 측정할 수 있었습니다.

이것이 인프라 소프트웨어를 구축하는 최선의 방법입니다. 기술이 우수하다면 엔지니어가 스스로 입증할 수 있어야 합니다.

가시성 비용은 조용히 회사 클라우드 비용의 상당 부분을 차지하게 될 수 있습니다. 이러한 비용이 보통 어디서 급증하며, 엔지니어링 팀이 가장 자주 실수하는 아키텍처 또는 구매 결정은 무엇인가요?

먼저 카디널리티를 살펴보겠습니다.

예를 들어 합리적인 메트릭으로 시작한 뒤 가능한 값들을 가진 라벨을 추가한다고 가정해 보세요. 그러면 어느 순간 하나의 메트릭이 수천 또는 수백만 개의 고유 시계열이 됩니다. 시스템은 이제 더 많은 데이터를 수집·인덱싱·저장·쿼리해야 하므로 CPU, 메모리, 스토리지가 더 많이 필요하게 됩니다.

어려운 점은 이것이 누군가의 단일 잘못된 결정 때문이 아니라 점진적으로 발생한다는 것입니다. 서비스를 더 추가하고, K8s 파드, 고객, 라벨을 늘리면 비용이 곱해집니다.

두 번째 문제는 모든 데이터를 동일한 해상도와 동일한 기간 동안 저장하는 것입니다. 모든 가시성 데이터가 동일한 가치를 갖는 것은 아닙니다. 알림이나 SLO에 필요한 메트릭은 사고 발생 시 한 번에 살펴보는 고볼륨 진단 텔레메트리와 다릅니다.

그 모든 데이터를 동일하게 취급하면, 필요하지 않은 데이터에 대해 프리미엄 인프라 혹은 SaaS 비용을 지불하게 됩니다.

이 때문에 일부 기업은 가시성을 구매 문제로 접근하여 오늘 배포하기 가장 쉬운 플랫폼이 무엇인지 묻습니다. 저는 “텔레메트리 양이 10배 증가하면 어떻게 되나요? 카디널리티는 어떻게 변하나요? 무엇을 저장하고 있나요? 얼마나 오래 저장하나요? 비용은 어떻게 변하나요?”와 같은 질문을 합니다.

이러한 문제에 대한 엔지니어링 솔루션이 있습니다. 예를 들어 스트리밍 집계 방식을 사용하면 모든 원시 시계열을 저장하고 나중에 집계하는 대신 저장에 도달하기 전에 메트릭을 집계할 수 있습니다. 고카디널리티 워크로드를 비즈니스 핵심 모니터링과 분리할 수 있으며, 데이터의 가치에 따라 서로 다른 보존 및 해상도 정책을 적용할 수도 있습니다.

목표는 가능한 최소한의 텔레메트리를 수집하는 것이 아니라, 시스템이 무엇을 하고 있는지 파악할 수 있을 만큼 충분한 정보를 확보하는 것입니다.

목표는 추가적인 가치를 제공하지 않는 방식으로 데이터 수집·처리·저장에 자원을 낭비하지 않는 것입니다.

가시성은 엔지니어링 시스템이며, 그 비용도 설계되어야 합니다.

Grammarly는 VictoriaMetrics와의 개념 증명이 AWS 비용을 10배 낮추었다고 밝혔습니다. 기업이 이러한 규모의 비용 절감을 달성할 때, 실제로 내부에서 무엇이 변하고 있는 걸까요? 데이터 압축, 컴퓨팅 요구량, 스토리지 아키텍처, 운영 복잡성, 혹은 이들 요소의 조합 중 무엇인가요?

이는 여러 요소가 복합적으로 작용하지만, 압축과 자원 사용량이 대부분의 효과를 냅니다. VictoriaMetrics는 시계열 데이터를 위해 특수 설계된 압축 방식을 사용하므로 동일한 메트릭이 일반 목적 데이터베이스보다 훨씬 적은 디스크 공간을 차지합니다. 또한 동일한 수집 속도에서 Prometheus보다 RAM 사용량이 4~5배 적고, 디스크 사용량은 최대 10배 적습니다. Grammarly가 개념 증명을 수행했을 때, 이는 AWS 청구서에 직접 반영되었습니다. 데이터 양을 줄인 것뿐만 아니라, 이를 처리하기 위해 더 적고 작은 인스턴스를 운영했기 때문입니다.

운영 복잡성도 중요한 요소이지만, 보다 간접적입니다. 많은 팀이 가시성 비용을 산정할 때 스토리지와 컴퓨팅 항목만을 고려하고, 다섯 개 구성 요소로 이루어진 Thanos 스택을 운영하는 엔지니어링 시간과 단일 바이너리를 운영하는 시간을 간과합니다. 이는 실제 비용이지만, 수치화하기는 어렵습니다.

Prometheus는 클라우드 네이티브 모니터링의 기반이 되었지만, 일부 조직은 결국 확장성이나 운영 제한에 직면합니다. 일반적인 Prometheus 배포를 넘어 다른 솔루션을 검토하게 되는 일반적인 원인은 무엇이며, VictoriaMetrics가 논리적인 대안이 되는 시점은 언제인가요?

Prometheus는 설계 목적에 충실하게 뛰어납니다: 단일 노드 스크레이프 및 알림 엔진. 팀은 보통 두 가지 방식으로 한계에 부딪힙니다. 하나는 카디널리티가 단일 Prometheus 인스턴스가 메모리에 담을 수 있는 범위를 초과하는 경우이고, 다른 하나는 장기 보존 및 여러 클러스터에 걸친 전역 쿼리가 필요하지만 Prometheus는 원래 이러한 용도로 설계되지 않았기 때문입니다. 이때 사람들은 보통 Thanos나 Cortex를 추가하게 되며, 여기서 운영상의 어려움이 시작됩니다. 하나의 바이너리를 실행하던 것이 컴팩터, 쿼리어, 스토어 게이트웨이 등으로 구성된 분산 시스템으로 전환되며, 새벽 3시에 문제가 발생할 수 있습니다.

VictoriaMetrics는 재구축이 아니라 즉시 교체 가능한 솔루션이기 때문에 논리적인 다음 단계가 됩니다. 팀은 기존 Prometheus 스크레이프 설정을 VictoriaMetrics에 지정하고 이미 구축한 모든 Grafana 대시보드, 알림 및 레코딩 규칙을 그대로 유지합니다. 마이그레이션은 프로젝트가 아니라 설정 변경일 뿐이며, 다섯 개의 새로운 컴포넌트를 추가하지 않고도 확장성을 확보할 수 있습니다.

우리는 엔지니어링 팀들이 대규모 완전 관리형 관측 플랫폼이 필요한지, 아니면 오픈소스 구성 요소로 보다 효율적인 스택을 구축할 수 있는지를 재고하는 모습을 보고 있습니다. 이를 관측 시장의 더 넓은 구조적 변화로 보시나요? 그리고 오픈소스가 기존 가격 모델에 어느 정도 압력을 가하고 있다고 생각하시나요?

이는 구조적인 현상이며, 예산이 안 좋은 해에 일시적으로 반응하는 것이 아닙니다. 관측 공급업체들은 전통적으로 인제스트량이나 호스트 수에 따라 가격을 책정해 왔으며, 이러한 모델은 비즈니스가 성장함에 따라 고객에게 불리하게 작용합니다. 기업이 성공할수록 비용이 증가하고, 가격은 제공되는 가치와 실질적인 연관성이 없습니다. 엔지니어링 팀은 직접 계산을 시작하면서, 자체 호스팅되는 효율적인 오픈소스 스택이 그 방정식을 완전히 바꾼다는 것을 깨닫고 있습니다. 이는 비용이 공급자가 제어하는 계량식이 아니라 실제 운영되는 인프라에 비례하기 때문입니다.

이는 기존 가격 구조에 실질적인 압박을 가합니다. 팀이 기존 스크레이프 설정을 오픈소스 대안으로 전환하고 기능을 잃지 않으면서 비용을 60~80% 절감할 수 있다면, 내부 논의가 어렵지 않을 것입니다. 여전히 호스트당 또는 맞춤 메트릭당 요금을 부과하는 공급업체들은 이러한 계산을 하지 않는 고객들을 계속해서 손실시키게 될 것입니다.

AI 인프라는 방정식에 매우 비싼 새로운 자원인 GPU를 도입합니다. AI 학습이나 추론을 운영하는 기업은 기본 GPU 활용도 외에 무엇을 모니터링해야 하며, 더 나은 관측이 AI 인프라 비용을 직접 낮추는 데 어떻게 기여할 수 있을까요?

GPU 활용도만으로는 충분한 정보를 제공하지 못합니다.

대시보드에서 90% 활용도를 보고 모든 것이 정상이라고 가정할 수 있습니다. 하지만 실제로 알고 싶은 것은: GPU가 무엇을 하고 있는가입니다.

더 깊이 살펴봐야 합니다. 어떤 CUDA 커널이 실행되고 있나요? GPU 메모리는 어떻게 할당되고 있나요? 계산 대신 메모리 이동에 소비되는 시간은 얼마인가요? 워크로드가 필요할 때 Tensor Cores를 사용하고 있나요? GPU 자체가 병목 현상인지, 아니면 다른 곳에서 데이터를 기다리고 있는지 확인해야 합니다.

GPU는 비용이 많이 들기 때문에 이러한 질문은 중요합니다. 수백에서 수천 대의 GPU에 걸쳐 작은 비효율이 반복되면 막대한 비용으로 이어집니다.

예를 들어, 데이터 파이프라인이 충분히 빠르게 공급하지 못해 GPU가 대기하고 있다면 GPU를 추가해도 문제가 해결되지 않습니다. 병목을 찾아야 합니다. 메모리도 마찬가지입니다. 워크로드가 메모리를 비효율적으로 할당한다면, 더 나은 가시성을 통해 엔지니어가 배치 크기를 조정하거나 동일한 하드웨어에서 더 많은 워크로드를 실행할 수 있습니다.

이것이 AI 인프라에서 관측이 흥미로워지는 지점입니다. 단순히 문제가 발생했는지를 감지하는 것이 아니라, 어디에서 컴퓨팅 자원을 낭비하고 있는지를 알려줍니다.

이 모든 모니터링으로 인해 관측 자체에도 문제가 발생합니다. GPU는 상세하고 고카디널리티 텔레메트리를 많이 생성할 수 있습니다. 모든 데이터를 수집해 비용이 높은 SaaS 플랫폼으로 직접 전송하면 GPU 비용을 절감하고 절감된 비용의 일부를 모니터링 데이터 저장에 사용할 수 있습니다. 그러나 이는 바람직한 최적화가 아닙니다.

OpenTelemetry와 OpenLIT와 같은 프로젝트를 활용하면 GPU 워크로드에 대한 훨씬 깊은 가시성을 확보할 수 있습니다. 이후 VictoriaMetrics를 사용해 데이터를 집계하고, 필요 없는 차원을 제거하며, 엔지니어가 실제로 필요로 하는 정보를 효율적으로 보존할 수 있습니다.

유용한 질문은 “내 GPU는 얼마나 활용되고 있나요?”가 아니라

“내가 비용을 지불하고 있는 GPU에서 어떤 유용한 작업을 얻고 있나요?”입니다.

그 질문에 답할 수 있게 되면, 더 나은 엔지니어링 및 비용 결정을 내릴 수 있습니다.

AI 에이전트는 단일 요청이 모델 호출, 도구 사용, 벡터 데이터베이스 쿼리, 핸드오프, 그리고 잠재적으로 긴 자동화 작업 체인을 트리거할 수 있기 때문에 기존 소프트웨어와는 매우 다른 관측 과제를 만듭니다. 기업 애플리케이션이 점점 더 에이전트화됨에 따라 관측은 어떻게 진화해야 할까요?

전통적인 관측은 요청이 인프라를 통해 비교적 예측 가능한 경로를 따른다고 가정합니다. 에이전트형 워크로드는 그렇지 않습니다. 단일 에이전트가 모델을 호출하고, 도구를 사용한 뒤, 또 다른 모델을 호출하고, 반환하기 전에 세 번 재시도할 수 있습니다. 이러한 각 단계마다 별도의 가시성이 필요합니다.

실패 유형도 다릅니다. 전통적인 서비스는 정상 응답이거나 응답이 없거나입니다. 에이전트는 성공적으로 응답했더라도 잘못되었거나, 느리거나, 비용이 많이 들 수 있으며, 이러한 문제는 가동 시간용 대시보드에 일반적인 오류로 나타나지 않습니다.

팀을 당황하게 만드는 부분은 카디널리티입니다. 단일 에이전트 워크플은 특정 사용자, 프롬프트, 도구 호출에 연결된 메트릭을 생성할 수 있으며, 특히 플래너가 동일한 도구를 반복 호출하는 재귀 루프에서는 그 양이 빠르게 증가합니다. 에이전트형 워크로드를 관찰하려는 시스템은 비용 곡선이 급격히 상승하지 않도록 그 규모를 처리해야 하는데, 이것이 우리가 해결하고자 하는 정확한 문제입니다. 메트릭, 로그, 트레이스는 여전히 올바른 기본 요소이며, 변경이 필요한 것은 그 아래에 있는 양과 비용 모델입니다.

VictoriaMetrics는 이상 탐지에 머신러닝 및 AI 지원 워크플를 적용하고 있습니다. 현재 AI가 모니터링 및 사고 대응을 실질적으로 개선할 수 있는 영역은 어디이며, 인간의 판단이 아직 대체하기 어려운 영역은 어디라고 보시나요?

아이디어를 생성하고 구현을 이끌며 결과를 검증하는 과정에 사람을 참여시키는 것이 중요합니다. 즉, 전통적인 워크플로와 비교해 실제로 바뀐 것은 없습니다. 변화된 점은 솔루션을 생성하는 능력이 확대되었다는 것입니다. 이제 누구나 소프트웨어를 만들 수 있지만, 이는 수용 기준을 낮추어서는 안 됩니다. 오히려 크게 높여야 합니다.

AI가 실제로 도움이 되는 부분은 사람이라면 잡아내기 어려운 노이즈 속의 이상치나 추세와 같이 수동 임계값을 넘지 않는 요소들을 드러내는 것입니다. VictoriaMetrics에서는 간단한 내부 AI 정책을 가지고 있습니다: 직원은 원하는 대로 워크플로를 자동화할 수 있지만 최종 결과에 대한 책임은 여전히 자신에게 있습니다. 이는 고객의 프로덕션 환경에서 이상 탐지에 적용하는 기준과 거의 동일합니다. 모델이 이를 표시할 수는 있지만, 그 의미와 대응 방안을 결정하는 것은 여전히 사람의 몫입니다.

VictoriaMetrics는 오픈소스를 유지하면서 전통적인 벤처 지원 인프라 스타트업 모델 대신 자체 자금 및 고객 자금 조달 방식을 채택했습니다. 이러한 접근 방식이 제품 개발, 가격 책정, 그리고 어떤 기술을 오픈소스로 유지할지 결정하는 데 어떤 영향을 미쳤나요?

자체 자금 조달은 사람들이 예상하는 것보다 인센티브 구조를 크게 바꿉니다. 특정 분기에 ARR 목표를 달성하라는 이사회 압력이 없기 때문에, 일반적으로 발생하는 타협—예를 들어 오픈소스 버전을 제한해 유료 플랜으로 유도하거나, 클라우드 제공업체로부터 수익을 보호하기 위해 InfluxDB나 HashiCorp가 라이선스를 변경한 것과 같은—을 할 필요가 없었습니다. 현재 VictoriaMetrics OSS는 Apache 2.0 라이선스를 사용하고 있으며, 이를 변경할 계획은 없습니다.

우리가 오픈소스로 유지할 것을 결정하는 방식은 간단합니다: 핵심 엔진, 즉 엔지니어들이 프로덕션 데이터를 우리에게 맡길 수 있어야 하는 부분은 오픈소스로 유지됩니다. 규모가 커져서 책임이 필요한 경우, 즉 멀티 테넌시, 엔터프라이즈 인증, 컴플라이언스 지원, CVE SLA, 그리고 지원 대기열이 아닌 코드를 작성한 엔지니어와 직접 연결되는 서비스를 위해 기업은 비용을 지불합니다. 고객 자금으로 운영되기 때문에 로드맵은 실제 프로덕션에서 겪는 문제에 의해 정해지며, 피치덱에서 자금을 확보할 수 있는 것에 의해 정해지지는 않습니다.

메트릭, 로그, 트레이스, AI 애플리케이션 텔레메트리, GPU 모니터링, 자동 이상 탐지가 점점 더 융합됨에 따라, 향후 몇 년간 관측성 스택은 어떻게 변할 것으로 보며, 관련성을 유지하려는 플랫폼에 대해 엔지니어링 팀이 기대하는 바는 무엇이라고 생각하십니까?

스택은 단일 제품으로 융합되기 전에 운영 차원에서 먼저 융합되며, 이 구분은 중요합니다. 대부분의 팀은 모든 것을 하나의 UI에 묶는 단일 모놀리식 플랫폼을 원하지 않습니다. 그들이 원하는 것은 메트릭, 로그, 트레이스를 하나의 운영 모델, 하나의 공급업체, 하나의 라이선스 체계 아래에서 실행하면서, 필요에 따라 각 신호를 독립적으로 운영할 수 있는 능력을 포기하지 않는 것입니다. 이것이 VictoriaMetrics가 구축하고 있는 방향입니다. 우리는 모든 것을 하나의 바이너리로 묶으려는 것이 아니라, 세 가지 신호가 동일한 엔진과 동일한 효율 특성을 공유하도록 하여, 두 번째나 세 번째 신호를 추가한다고 해서 두 번째나 세 번째 운영상의 골칫거리를 도입하는 것이 아니도록 하고 있습니다.

관련성을 유지하는 플랫폼은 AI 텔레메트리와 GPU 모니터링을 동일한 모델에 비용 곡선이 깨지지 않게 흡수할 수 있는 플랫폼입니다. AI 워크로드는 기존의 메트릭당 또는 호스트당 가격 모델이 감당할 수 없는 규모의 텔레메트리를 생성합니다. 팀은 필요한 데이터를 수집하지 않거나, 관측성 비용이 감시해야 할 AI 투자보다 빠르게 증가하게 됩니다. 엔지니어링 팀은 워크로드가 증가할 때마다 재설계하거나 재협상하라는 요구 없이, 인프라가 확장되는 것과 동일한 방식으로 그 규모를 처리해줄 플랫폼을 기대하게 될 것입니다.

훌륭한 인터뷰에 감사드립니다. 더 알고 싶은 독자분들은 VictoriaMetrics를 방문하시기 바랍니다.