작성자: 브라이언 스미스
nOps는 연간 40억 달러 이상의 클라우드 지출을 관리하는 Databricks Built On 파트너로, 프로덕션 애플리케이션을 Databricks Lakebase로 이전했습니다. 그 결과 더 빠르고 간단한 아키텍처가 구현되어 앱과 분석 간의 연결이 제거되었으며, 이를 수행하려는 ISV를 위한 플레이북이 만들어졌습니다.
Databricks에서 구축하는 모든 ISV는 결국 동일한 아키텍처 교차점에 도달합니다. 분석은 Lakehouse에 있지만 애플리케이션은 저지연 읽기 및 쓰기를 위해 관계형 데이터베이스가 필요합니다. 따라서 별도의 Postgres 인스턴스(RDS 또는 자체 관리형)를 추가하면 두 시스템을 동기화하기 위해 ETL 파이프라인, cron 작업 및 변경 감지 로직을 유지 관리해야 합니다.
nOps는 수년간 그 현실을 경험했습니다. 그러다 더 나은 방법을 찾았습니다.
잘 모르는 분들을 위해 설명하자면, nOps는 AWS, GCP 및 Azure 전반의 약정 기반 할인을 관리하는 자동화된 클라우드 비용 최적화 플랫폼입니다. 이들의 접근 방식은 명확하게 "항상 켜져 있는" 방식입니다. 기계 학습을 사용하여 효과적인 절감률과 약정 잠금 위험을 균형 있게 조정하면서 시간별로 클라우드 약정을 모니터링, 구매 및 교환합니다. 이 모델은 성능 기반입니다. nOps는 생성된 증분 절감액의 백분율만 청구합니다.
이는 데이터 집약적인 작업입니다. 매시간 nOps는 수천 개의 고객 계정 전반의 사용 패턴을 분석하고, 세 가지 주요 클라우드 제공업체 및 수십 가지 서비스에 걸친 약정 포트폴리오를 평가하며, 자동화된 구매 결정을 내립니다. 또한 중앙 집중식 FinOps 플랫폼을 통해 비용 가시성, 예측 및 이상 감지를 제공합니다.
이 모든 것의 분석 백본은 오랫동안 Databricks Lakehouse였습니다. 하지만 고객이 절감액을 확인하고, 예산을 관리하고, 비용 데이터를 탐색하기 위해 로그인하는 플랫폼인 프런트엔드 애플리케이션에는 더 많은 것이 필요했습니다.
nOps의 이전 아키텍처는 Databricks의 ISV에게 익숙한 패턴이었습니다. 고급 분석 및 메트릭 계산은 Lakehouse에서 실행되었습니다. 고객 대면 데이터(계정 구성, 사용자 기본 설정, 빠르게 변경되는 클라이언트별 상태)는 타사 공급업체 및 자체 솔루션으로 구동되는 별도의 관계형 데이터베이스에 있었습니다.
이 두 시스템 간의 이음새는 실제 마찰을 일으켰습니다. 프런트엔 드 데이터베이스와 Lakehouse를 동기화 상태로 유지하려면 예약된 작업과 cron 기반 변경 감지가 필요했습니다. 한 시스템에서 "실시간"인 데이터가 다른 시스템에 표시되는 데 몇 분 이상 걸릴 수 있었습니다. 또한 별도의 데이터베이스 스택을 관리하는 운영 오버헤드(확장, 백업 및 보안 문제 포함)는 엔지니어링 시간을 nOps가 실제로 가장 잘하는 일, 즉 약정 자동화 구축에서 빼앗아 갔습니다.
nOps가 2026년 초 AWS 전용에서 GCP 및 Azure 전반의 멀티 클라우드 지원으로 확장되면서 증가하는 워크로드는 이 아키텍처에 부담을 주었습니다. 팀은 플랫폼을 재구축하기로 결정했으며, 이번에는 전문 분야에 집중하고 제대로 작동하는 인프라를 선택했습니다.
nOps는 새 플랫폼의 OLTP 백본으로 Lakehouse에 직접 통합된 완전 관리형 PostgreSQL 데이터베이스인 Databricks Lakebase를 선택했습니다.
nOps의 제품 책임자인 Jordan Stein은 Lakebase가 적합한 세 가지 요인을 지적했습니다.
nOps의 새 아키텍처는 다음과 같습니다.
Lakebase는 프런트엔드 애플리케이션과 AI 인프라 모두에 대한 중앙 Postgres 데이터베이스 및 단일 진실 공급원 역할을 합니다.
Databricks Lakehouse는 분석을 위해 Lakebase에서 지속적으로 데이터를 수집합니다.
nOps 플랫폼은 Databricks Metric Views를 자동으로 검색하고 표시하므로 Lakehouse에서 계산된 표준화된 메트릭이 프런트엔드에 일관되게 표시됩니다.
데이터는 Lakehouse에서 분석을 위해 Lakebase로 단방향으로 흐르며 직접적인 쓰기 백이 필요하지 않습니다. 이렇게 하면 아키텍처가 깔끔하게 유지되고 진실 공급원이 명확해집니다.
나머지 스택은 동일한 접근 방식을 따릅니다. 호스팅 및 관찰 가능성은 Vercel, 인증은 WorkOS, 데이터는 모두 Databricks를 사용합니다.
Jordan Stein은 최근 파트너 스포트라이트 프레젠테이션에서 전체 nOps Lakebase 마이그레이션 스토리를 자세히 설명했습니다. 전환이 어떻게 진행되었는지, 성능에 놀랐던 점은 무엇인지, Lakehouse 통합이 데이터 엔지니어링 워크플로를 어떻게 변화시켰는지 알아보려면 동영상을 시청하세요.
nOps의 이야기는 독특하지 않습니다. Databricks에서 구축하는 거의 모든 ISV는 동일한 OLTP와 분석의 만남이라는 긴장감을 겪습니다. 주목할 만한 점은 Lakebase가 이를 얼마나 깔끔하게 해결하는가입니다.
동기화 비용 제거. 모든 ISV 스택에서 가장 비용이 많이 드는 코드는 종종 시스템 간에 데이터를 이동하는 코드입니다. Lakebase의 Unity Catalog와의 기본 통합 및 원클릭 Delta Lake 동기화는 사용자 지정 ETL 파이프라인을 관리형 인프라로 대체합니다. 이는 되찾은 엔지니어링 시간입니다.
하나의 거버넌스 모델. OLTP 데이터베이스가 Unity Catalog 자산으로 등록되면 운영 및 분석 데이터에 대한 통합 거버넌스, 계보 및 액세스 제어를 얻게 됩니다. 더 이상 두 곳에서 보안 정책을 관리할 필요가 없습니다.
Postgres 호환성으로 재작성 불필요. Lakebase는 완전 관리형 PostgreSQL입니다. 기존 라이브러리, ORM 및 SQL 도구가 즉시 작동합니다. pgvector 및 PostGIS와 같은 확장도 지원됩니다. 쿼리를 재작성하는 것이 아니라 새 연결 문자열로 앱을 가리켜 마이그레이션합니다.
합리적인 규모 경제. 사용량 기반 가격 책정과 제로 스케일링을 통해 유휴 용량에 대한 비용을 지불하지 않습니다. 가변 워크로드를 가진 ISV(어떤 ISV가 가변 워크로드를 가지고 있지 않겠습니까?)의 경우 이는 단위 경제에 직접적인 영향을 미칩니다.
더 빠르게 출시. 애플리케이션 데이터베이스와 데이터 웨어하우스가 동일한 플랫폼이면 한 범주의 통합 작업이 사라집니다. 팀은 배관을 유지 관리하는 대신 기능을 출시합니다.
nOps는 혁신적인 Built On 파트너의 좋은 예입니다. Lakebase가 여러 릴리스 주기를 통해 성숙하기를 기다리는 대신, 아키텍처 적합성을 조기에 인식하고 프로덕션 마이그레이션에 전념했으며 이미 결과를 보고 있습니다. 즉, 더 빠른 데이터 파이프라인, 더 낮은 운영 오버헤드 및 고객을 위한 더 나은 경험입니다.
이러한 조기 이동 의지는 전략적으로도 현명합니다. 지금 Lakebase를 기반으로 구축함으로써 nOps는 별도의 데이터베이스 스택을 계속해서 임시방편으로 연결하고 있는 경쟁사보다 Databricks 플랫폼과 더 긴밀하게 통합되어 있습니다. 플랫폼을 운영하기 더 쉽고 확장하기 더 빠릅니다.
Lakebase 살펴보기. Databricks에서 구축 중이거나 고려 중인 ISV라면 Lakebase에 대해 자세히 알아보고 아키텍처를 단순화하는 데 어떻게 도움이 되는지 알아보세요.
nOps 살펴보기. 조직에서 약정 위험 없이 AWS, GCP 또는 Azure 전반의 클라우드 비용을 절감하려고 한다면 nOps를 방문하여 Databricks Lakebase로 구동되는 자동화된 최적화 플랫폼이 어떻게 도움이 될 수 있는지 알아보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.