nOps, Lakehouse//RT를 통해 실시간 스택을 통합하고 비용을 6배 절감

모든 클라우드 청구서에는 저마다의 사연이 있지만, 이를 제대로 읽으려면 수십 개 클라우드 및 AI 제공업체의 수백만 개 항목을 CFO, 엔지니어링 리드, FinOps 팀이 실제로 조치할 수 있는 내용으로 변환해야 합니다. 이것이 바로 nOps가 해결하는 문제입니다. 이 회사의 플랫폼은 수백 개 고객사의 연간 50억 달러 이상의 클라우드 지출을 관리하며, 원시 청구 및 사용량 데이터를 실시간 대시보드로 전환하여 기업이 부서, 비용 센터, 커스텀 태그별로 자금이 어디로 향하는지 정확히 파악할 수 있도록 지원합니다. 

고객들은 이러한 가시성이 즉각적으로 제공되기를 기대합니다. 약정 추천이 변경되거나, 예상치 못한 계정에서 지출이 급증하거나, 새로운 AI 워크로드로 인해 비용이 발생하기 시작할 때 대시보드는 이를 실시간으로 반영해야 합니다. nOps는 맞춤형 대시보드 뷰를 제공하며, 그 이면의 데이터는 모든 고객의 고유한 구성 전반에서 최신 상태로 반응성을 유지해야 합니다. Built on Databricks 파트너인 nOps는 최근 Apache Druid를 Lakehouse//RT로 교체하여 인프라 비용을 절감하고 단일 거버넌스 플랫폼으로 아키텍처를 통합하면서 이러한 실시간 계층을 구동하고 있습니다.

차세대 엔터프라이즈 고객을 위한 실시간 계층 구축

수년간 nOps 고객 대시보드 이면의 실시간 쿼리 계층은 Apache Druid에서 실행되었습니다. 이 회사는 자체 호스팅 배포로 시작한 후 관리형 Druid 서비스로 전환했습니다. 하지만 플랫폼이 성장하고 엔터프라이즈 고객이 점점 더 복잡한 보고 요구 사항을 제시함에 따라 비즈니스 요구 사항과 Druid가 제공할 수 있는 기능 간의 격차는 더욱 벌어졌습니다.

"필요한 성능을 얻을 수 없었습니다." nOps의 엔지니어링 디렉터인 조단 스타인은 말합니다. "또한 그 가치를 이끌어내기가 정말 어려웠습니다." 문제는 단순히 속도만이 아니었습니다. nOps는 고객이 자체 매핑, 태그, 그룹화를 정의할 수 있도록 하므로 어떤 고객의 대시보드도 서로 같지 않습니다. 이러한 뷰를 구동하는 쿼리는 매우 복잡할 수 있으며, 일부는 수조 개의 행에 걸쳐 문자열 일치를 수행하는 3만 줄의 SQL에 달하기도 합니다. nOps가 더 많은 부서, 더 많은 비용 센터, 더 세분화된 보고 요구 사항을 가진 대형 엔터프라이즈 계정을 확보함에 따라 쿼리는 더 길어지고 더 까다로워졌습니다. 이들은 nOps가 가장 서비스하고 싶어 했던 고객이었지만, 기존의 실시간 계층이 플랫폼의 발목을 잡고 있었습니다.

팀은 nOps가 S3에서 데이터를 이동할 필요 없이 이러한 쿼리의 전체 복잡성을 처리할 수 있는 플랫폼이 필요했습니다. Delta 테이블을 구동하는 S3의 약 380TB 규모의 클라우드 인프라 데이터를 별도의 서빙 계층으로 복제하면 팀이 완전히 제거하고자 했던 비용, 지연 시간, 운영 오버헤드가 추가되었습니다.

Lakehouse//RT: 데이터 이동 제로, 즉시 롤백

nOps는 이미 프로덕션에서 Databricks 메트릭 뷰를 사용하고 있었고 Lakehouse//RT가 출시되었을 때 Lakebase에서 애플리케이션 데이터베이스를 실행하고 있었습니다. 시기는 팀이 새로운 실시간 엔진을 찾던 시기와 완벽하게 일치했습니다. "이것은 정확히 우리가 해결하고자 했던 문제였습니다." 스타인은 말합니다. "액세스한 순간부터 Lakehouse//RT가 Druid 계층을 직접 대체한다는 것이 분명했습니다."

가장 중요한 요구 사항은 데이터 이동 제로였습니다. nOps는 S3에 약 380TB의 데이터를 보유하고 있으며, 이를 별도의 서빙 계층으로 복제하는 것은 비용이 많이 들고 운영상 고통스러웠습니다. Lakehouse//RT는 복사, 수집 파이프라인, 보조 스토리지 없이 동일한 Delta 테이블을 직접 쿼리합니다. "380테라바이트가 넘는 데이터를 다양한 플랫폼으로 이동하려고 하는 것이 얼마나 골치 아프고 비용이 많이 드는 일인지는 누구나 알 것입니다." 스타인은 말합니다. "Lakehouse//RT를 사용하면 기본 데이터 변경이 전혀 필요하지 않았습니다."

또한 마이그레이션을 통해 즉시 테이블 버전 롤백이 가능해졌습니다. Druid에서는 테이블 버전을 롤백하려면 새 수집 작업을 제출하고 최대 3시간을 기다려야 했습니다. Lakehouse//RT가 Delta 테이블에서 직접 읽어오므로 롤백이 즉시 발생합니다. "이것은 우리에게 가장 큰 영향을 미친 변화 중 하나입니다." 스타인은 말합니다. "고객이 보는 데이터는 우리가 막 쓰기를 마친 동일한 테이블입니다. 다른 위치에 있는 해당 데이터의 복제본을 찾아다닐 필요가 없습니다."

6배 이상의 비용 절감 및 통합 데이터 플랫폼

재정적 영향은 상당했습니다. nOps의 이전 아키텍처는 항상 켜져 있는 Druid 클러스터에 의존했습니다. Lakehouse//RT의 서버리스 자동 스케일링을 통해 팀은 실시간 인프라 지출을 이전 비용의 약 16%로 줄였으며, 이는 6배 이상 저렴해진 것입니다. 또한 이번 마이그레이션을 통해 보조 Druid 스토리지 계층의 S3 외부에 저장되어 있던 40TB의 중복 서빙 데이터가 제거되었습니다. 

대시보드 외에도 nOps는 내부 AI 에이전트와 MCP(Model Context Protocol) 아키텍처를 Lakehouse//RT를 통해 라우팅하므로 응답 시간이 크게 향상되었고 고객을 위한 대화형 채팅 환경의 품질이 높아졌습니다. "백엔드에 쓰는 내용과 프론트엔드에서 고객이 보는 내용 간의 기본 데이터가 동일하다는 것은 엄청난 일입니다." 스타인은 말합니다. "이러한 상호 의존적 아키텍처를 한곳으로 이동하는 것은 많은 가치가 있습니다."

Built on Databricks 파트너로서 nOps의 경험은 왜 Lakehouse//RT가 데이터 집약적 애플리케이션을 구축하는 ISV 파트너에게 적합한지 잘 보여줍니다. 가시성 및 클라우드 비용 관리 플랫폼은 대규모 데이터 볼륨, 복잡한 고객 정의 쿼리, 실시간 응답성에 대한 기대를 다룹니다. Lakehouse//RT를 사용하면 ISV는 별도의 실시간 데이터베이스를 유지 관리하지 않고도 레이크하우스에서 직접 이러한 워크로드를 처리할 수 있으므로 인프라 비용과 운영 복잡성이 모두 줄어듭니다. 베타 기간 동안 nOps가 Databricks 제품 팀과 긴밀하게 협력한 것은 마이그레이션을 더욱 가속화했습니다. "이러한 파트너십은 새로운 기술을 추진하고 피드백을 제공할 수 있는 팀이 있을 때 매우 가치 있습니다." 스타인은 말합니다.