주요 컨텐츠로 이동

데이터베이스의 새로운 시대: Lakebase

Lakebase

Summary

  • 운영 데이터베이스는 오늘날의 AI 주도 애플리케이션을 위해 설계되지 않았습니다. 그들은 분석 및 AI 스택 외부에 위치하며, 수동 통합이 필요하고, 현대 개발 워크플로우에 필요한 유연성이 부족합니다.
  • 레이크베이스는 OLTP 데이터베이스에 대한 새로운 아키텍처를 도입하며, 이에는 독립적인 스케일링과 분기를 위한 컴퓨트와 스토리지의 분리가 포함됩니다.
  • Lakehouse와 깊게 통합된 레이크베이스는 운영 데이터 워크플로우를 단순화합니다. 이것은 불안정한 ETL 파이프라인과 복잡한 인프라를 제거함으로써, 팀들이 더 빠르게 움직이고 통합 데이터 플랫폼에서 지능형 애플리케이션을 제공할 수 있게 합니다.

수십 년 동안 데이터베이스는 전자상거래 결제 흐름부터 전사적 자원 관리까지 모든 것을 조용히 지원하며 소프트웨어의 중추 역할을 해왔습니다. 세상의 모든 소프트웨어, 모든 애플리케이션, 모든 워크플로우, 모든 AI 생성 코드 줄은 궁극적으로 데이터베이스에 의존합니다. 그 과정에서 애플리케이션 구축 방식을 완전히 재창조했지만, 기반이 되는 데이터베이스는 1980년대 이후 거의 변하지 않았습니다. 이러한 데이터베이스는 현대 클라우드 이전의 아키텍처에 기반하고 있으며 다음과 같은 문제점을 안고 있습니다.

  • 취약하고 비용이 많이 드는 운영: 기존 데이터베이스는 가장 섬세한 인프라 중 하나로 간주되며, 안정적으로 운영하려면 종종 전문가 팀이 “달걀 위를 걷듯” 조심해야 합니다. 컴퓨팅과 스토리지가 단단하고 일체형으로 결합되어 있습니다. 이로 인해 팀은 최대 용량에 맞춰 프로비저닝해야 하므로 비용이 많이 드는 유휴 리소스가 발생합니다. 부하가 프로비저닝된 용량을 초과하면 데이터베이스가 응답하지 않을 수 있습니다. 더 나쁜 것은 데이터베이스 스냅샷 찍기 또는 GDPR 정리 쿼리 실행과 같은 간단한 유지 관리 작업이 전체 데이터베이스를 다운시킬 수 있다는 것입니다.
  • 불편한 개발 경험: 기존 데이터베이스는 현대적이고 민첩한 개발 워크플로우와 충돌합니다. 코드의 경우, 코드베이스의 완전히 격리된 복제본인 개발용 git 브랜치를 만드는 데 1초도 걸리지 않습니다. 데이터베이스의 경우, 프로비저닝하는 데 몇 분 또는 몇 시간이 걸릴 수 있으며, 프로덕션 데이터베이스의 고충실도 복제본을 만드는 것은 매우 비용이 많이 들고 프로덕션 데이터베이스를 다운시킬 위험이 있습니다. AI 기반 개발의 부상은 이러한 압력을 더욱 심화시켰습니다. AI 에이전트는 실험을 위해 임시 격리 환경을 즉시 생성해야 합니다.
  • 극심한 공급업체 종속성: 데이터베이스 마이그레이션은 조직 내에서 가장 두려운 기술 프로젝트 중 하나입니다. 일체형 아키텍처는 데이터를 가져오거나 내보내는 유일한 방법이 데이터베이스 엔진 자체를 통하는 것임을 의미합니다. 이는 상당한 공급업체 종속성을 부과하여 조직이 특정 공급업체에 깊이 의존하게 만듭니다.

이제 데이터베이스도 진화할 때입니다.

Lakebase란 무엇인가요?

기존 데이터베이스의 한계를 해결하는 새로운 시스템이 등장하고 있습니다. Lakebase는 트랜잭션 데이터베이스의 장점과 데이터 레이크의 유연성 및 경제성을 결합한 새로운 개방형 아키텍처입니다. Lakebase는 컴퓨팅과 스토리지를 분리하고 데이터베이스 데이터를 저렴한 클라우드 스토리지(“레이크”)에 개방형 형식으로 직접 저장하며, 트랜잭션 컴퓨팅 계층이 그 위에 독립적으로 실행되도록 하는 근본적으로 새로운 설계를 통해 가능해집니다.

이 분리가 핵심적인 돌파구입니다. 기존 데이터베이스는 CPU와 스토리지를 하나의 일체형 시스템으로 묶어 단일 대형 머신으로 프로비저닝, 관리 및 비용을 지불해야 했습니다. Lakebase는 이러한 계층을 분리합니다. 데이터는 레이크에 개방적으로 저장되고, 데이터베이스 엔진은 즉시 확장할 수 있는 완전 관리형 서버리스 컴퓨팅 계층(예: Postgres)이 됩니다. 이 아키텍처는 수십 년 동안 데이터베이스를 정의해 온 비용, 복잡성 및 종속성을 크게 제거하며, 개발자가 여러 인스턴스를 시작하고 자유롭게 실험하며 사용한 만큼만 비용을 지불하려는 현대 AI 및 에이전트 기반 워크로드에 특히 강력합니다.

Lakebase는 다음과 같은 주요 기능을 갖습니다.

스토리지와 컴퓨팅 분리: 데이터는 클라우드 객체 스토리지(“레이크”)에 저렴하게 저장되고, 컴퓨팅은 독립적이고 탄력적으로 실행됩니다. 이를 통해 대규모 확장성, 높은 동시성 및 1초 이내에 제로까지 확장할 수 있는 기능(레거시 데이터베이스 시스템에서는 불가능)을 제공하여 비싼 데이터베이스 머신을 유휴 상태로 유지할 필요가 없습니다.

무제한의 저렴하고 내구성 있는 스토리지: 데이터가 레이크에 저장되므로 스토리지는 사실상 무한해지고 고정 용량 인프라가 필요한 기존 데이터베이스 시스템보다 훨씬 저렴해집니다. 또한 클라우드 객체 스토리지(예: S3)의 내구성을 기반으로 하며 기본적으로 99.999999999%의 내구성을 제공합니다. 이는 스토리지 중복성을 위해 복제본을 사용하는 기존 데이터베이스 설정(대부분 비동기적으로 업데이트되므로 이중 장애 발생 시 데이터 손실 가능성이 있음)보다 훨씬 뛰어납니다.

탄력적이고 서버리스인 Postgres 컴퓨팅: Lakebase는 수요에 따라 즉시 확장되고 유휴 상태일 때는 축소되는 완전 관리형 서버리스 Postgres를 제공합니다. 비용은 사용량과 직접적으로 일치하므로 버스트 워크로드, 개발 환경 및 임시 인스턴스를 시작하는 AI 에이전트에 이상적입니다.

즉각적인 브랜칭, 복제 및 복구: 데이터베이스를 개발자가 코드를 브랜칭하는 방식과 동일한 방식으로 브랜칭하고 복제할 수 있습니다. 페타바이트 규모의 데이터베이스도 몇 초 안에 복사할 수 있어 빠른 실험, 안전한 롤백 및 운영 오버헤드 없이 즉각적인 복원이 가능합니다.

통합된 트랜잭션 및 분석 워크로드: Lakebase는 OLTP 및 OLAP에 대해 동일한 스토리지 계층을 공유하는 Lakehouse와 원활하게 통합됩니다. 이를 통해 데이터를 이동하거나 복제하지 않고도 트랜잭션 데이터에서 직접 실시간 분석, 머신 러닝 및 AI 기반 최적화를 실행할 수 있습니다.

개방형 및 멀티 클라우드 설계: 개방형 형식으로 저장된 데이터는 독점적인 종속성을 피하고 AWS, Azure 등 전반에 걸쳐 진정한 이식성을 제공합니다. 내장된 멀티 클라우드 유연성은 재해 복구, 장기적인 자유 및 시간이 지남에 따라 더 나은 경제성을 지원합니다.

이것이 Lakebase의 핵심 속성입니다. 엔터프라이즈급 트랜잭션 시스템에는 보안, 거버넌스, 감사 및 고가용성과 같은 추가 기능이 필요하지만, Lakebase를 사용하면 이러한 기능은 단일 개방형 기반에서 한 번만 구현하고 관리하면 됩니다. Lakebase는 데이터베이스의 다음 진화 단계로, 클라우드, 개발자 및 AI 시대를 위해 재구축된 트랜잭션 시스템입니다.

가이드

최신 분석을 위한 컴팩트 가이드

데이터베이스 아키텍처 진화

새로운 시대가 필요한 이유를 이해하려면 지난 50년간 데이터베이스 아키텍처가 어떻게 진화했는지 살펴보는 것이 도움이 됩니다. 우리는 이 진화를 세 가지 뚜렷한 세대로 보고 있습니다.

1세대: 모놀리스

예시: MySQL, Postgres, 클래식 Oracle

데이터베이스 시스템은 절대적인 모놀리스로 시작되었습니다. 클라우드 이전 시대에는 네트워크가 시스템에서 가장 느린 부분이었습니다. 고성능 데이터베이스를 설계하는 유일한 방법은 컴퓨팅(CPU/RAM)과 스토리지(디스크)를 단일 물리적 머신 내에 긴밀하게 결합하는 것이었습니다. 이는 1980년대 하드웨어 제약에는 합리적이었지만, 데이터가 독점 형식에 갇히고 확장이 더 큰 상자를 구매하는 것을 의미하는 경리적인 우리를 만들었습니다.

2세대: 스토리지의 독점적 느슨한 결합

예시: Aurora, Oracle Exadata

클라우드 인프라가 개선되면서 공급업체는 스토리지를 컴퓨팅과 물리적으로 분리하고 스토리지를 독점 백엔드 계층으로 옮겼습니다. 이러한 시스템은 처리량의 한계를 뛰어넘는 엔지니어링의 경이로움이었습니다. 그러나 그들은 충분히 나아가지 못했습니다. 분리는 순전히 내부 최적화였습니다. 데이터는 단일 엔진만 액세스할 수 있는 독점 형식 내에 잠겨 있기 때문에 2세대 시스템은 구조적 교착 상태를 겪습니다.

  • 단일 엔진 병목 현상: 데이터는 기본 데이터베이스 엔진을 통해서만 액세스할 수 있으며, 이 엔진이 병목 현상이 됩니다. 대규모로 데이터에 액세스하는 AI 에이전트나 분석 엔진에 어렵습니다.
  • 분석 마찰: OLAP 엔진이 대규모로 데이터 파일에 직접 액세스할 수 없기 때문에 분석 쿼리를 실행하는 것은 여전히 어렵고 일반적으로 데이터를 이동하기 위해 복잡한 ETL이 필요합니다.
  • 클라우드 종속성: 스토리지 계층은 종종 특정 클라우드 공급업체의 독점 인프라에 긴밀하게 결합됩니다. 이로 인해 멀티 클라우드 상호 운용성이 어려워지고 진정한 크로스 클라우드 고가용성 및 재해 복구(HADR)가 불가능해집니다. 공급업체의 리전이 실패하면 데이터가 갇히게 됩니다.

우리는 이러한 시스템이 궁극적인 3세대 시스템으로 가는 과도기 상태에 있다고 생각합니다.

3세대: Lakebase - 레이크의 개방형 스토리지

Lakebase는 분리된 아키텍처를 궁극적이고 논리적인 결론으로 이끌어갑니다. 2세대와 마찬가지로 컴퓨팅과 스토리지를 분리하지만 중요한 차이점이 있습니다. 바로 스토리지 인프라와 데이터 형식 모두 완전히 개방적이라는 것입니다.

이 아키텍처를 기반으로 구축하면 앞서 언급한 세 가지 문제를 해결할 수 있습니다.

  • 더 나은 안정성과 더 낮은 비용을 위한 간편한 운영: 프로비저닝, 스케일 업/다운, 브랜칭, 스냅샷, 복구와 같은 일반적인 작업이 몇 초 안에 완료될 수 있습니다. 프로덕션 트래픽에 영향을 주지 않고 다른 탄력적 컴퓨팅 인스턴스에서 비용이 많이 드는 쿼리를 실행할 수 있습니다.
  • Git과 유사한 개발자 경험: 프로덕션 데이터베이스의 고품질 브랜치를 기반으로 애플리케이션을 더 빠르게 실험하고 개발할 수 있습니다. 개발자와 AI 에이전트에게 이는 데이터베이스가 코드만큼 빠르게 이동한다는 것을 의미합니다.
  • 극심한 공급업체 종속성 해결: 클라우드 객체 저장소에 저장된 개방형 형식의 데이터를 사용하면 종속성이 훨씬 줄어듭니다. 엔진과 무관하게 데이터를 소유할 수 있습니다.

저렴하고 안정적인 객체 저장소와 클라우드 탄력성을 사용할 수 있게 된 오늘날 OLTP 데이터베이스를 재설계해야 한다면 구축할 것이 바로 Lakebase입니다. 조직이 클라우드와 AI를 채택하여 더 빠르게 발전함에 따라 이 모델이 트랜잭션 시스템 구축을 위한 표준 기반이 될 것으로 예상합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요