Lakebase는 스토리지를 컴퓨팅과 분리합니다. 쿼리를 실행하는 Postgres 엔진은 상태가 없으며, 데이터는 독립적으로 지속되는 내구성 있는 저장 계층에 보관됩니다. 이러한 분리가 자동 확장, 0까지 확장, 즉각적인 분기, 읽기 복제본, 빠른 장애 조치 등을 가능하게 합니다.
Lakebase가 무엇을 변경했는지 보여주기 위해, 이 페이지는 전통적인 단일 기계 데이터베이스 설계에서 시작해 대비를 위해 시작한 뒤, Lakebase가 동일한 설계를 독립적인 레이어로 어떻게 분리하고 각 부분이 무엇을 하는지 설명합니다.
전통적인 데이터베이스가 구축되는 방법
Lakebase를 보기 전에, 그것이 대체하는 모델을 먼저 생각해 보세요. 기존의 Postgres 데이터베이스는 하나의 모놀리스입니다. 한 대의 컴퓨터가 쿼리 엔진을 실행하여 앞서 쓰기 로그(WAL) 와 데이터 파일을 로컬 마운트 지점에 연결된 디스크에 모두 씁니다. 전통적으로 이 디스크들은 동일한 기계의 일부인 진정한 로컬이었지만, 인프라가 발전하면서 종종 네트워크 연결 저장 장치로 대체되었습니다.
WAL과 데이터 파일은 두 가지 상호 보완적인 역할을 합니다:
- WAL은 쓰기 속도를 높여줍니다. Postgres는 커밋을 인정하기 전에 각 변경 사항을 순차적으로 로그에 추가하는데, 이는 단일 디스크에서 빠르고 지속 가능합니다.
- 데이터 파일이 읽기 속도를 높입니다. Postgres는 모든 페이지의 현재 버전을 데이터 파일로 구현하여, 쿼리가 로그를 재생하지 않고도 행을 읽을 수 있습니다.
한 대의 기기로 모든 데이터를 접근하는 데는 단점이 있습니다:
- 내구성은 그 기계의 물리적 인프라와 직접적으로 연결되어 있습니다. 또한 스토리지 사전 프로비저닝과 작업 증가 예측이 필요해 비용 관리와 복원력 계획 모두를 복잡하게 만듭니다.
- 높은 가용성과 다양한 수평 확장은 전체 데이터베이스의 물리적 복제가 필요합니다.
- 그 기계가 고장 나면 데이터가 손실될 수 있습니다. RAID 저장소와 같은 기술이 이 위험을 줄여주지만, 추가된 중복성은 시스템 운영 비용을 크게 증가시킬 수 있습니다.
레이크베이스 건축
Lakebase는 동일한 책임을 유지하지만 이를 두 개의 독립적인 계층으로 나누고 있습니다:
- 표준 상태 없는 Postgres를 실행하는 컴퓨팅 계층 입니다.
- 세이프키퍼, 페이지서버, 클라우드 객체 저장소로 구성된 저장 계층 입니다.
모놀리스에서 나온 두 역할이 새로운 컴포넌트로 바로 연결됩니다. 쓰기 속도를 높인 WAL은 세이프키퍼 역할을 하여 쓰기를 확장합니다. 읽기 속도를 높인 데이터 파일들은 페이지 서버가 되어 읽기 속도를 확장합니다.
데이터가 단일 머신이 아닌 클라우드 객체 저장소에 저장되기 때문에, Lakebase는 탄력적이고 확장 가능한 컴퓨트와 지속 가능한 쓰기를 제공하여 가용성 존 전반에 걸쳐 복제됩니다. 저장 공간은 제공할 필요가 없습니다. 소비하는 저장 공간에 대해서만 비용을 지불하면 되고, 디스크 부족 같은 실패 모드를 미리 계획할 필요가 없습니다.
이 모델은 성능도 향상시킵니다. Lakebase는 각 변경 사항을 여러 위치에 직접 쓰기 때문에 전통적인 찢어진 쓰기 보호와 블록 정렬의 오버헤드를 피할 수 있습니다. 모든 쓰기가 이미 여러 위치로 전송되기 때문에, 고가용성이 활성화되었든 없든 성능은 일정하게 유지됩니다.
다음 표는 모놀리스의 각 부분을 레이크베이스에 대응하는 부분과 일치시킨다.
| 전통적인 모놀리스 | Lakebase | 역할 |
|---|---|---|
| 단일 기계 | 상태 없는 계산 | Postgres 쿼리 엔진을 구동합니다 |
| 로컬 WAL 디스크 | 세이프키퍼 | 모든 커밋된 변경 사항을 지속 가능하게 기록합니다 |
| 로컬 데이터 파일 | 페이지서버 및 객체 저장 | 페이지 버전을 구체화하고 저장합니다 |
컴퓨팅 계층
컴퓨트 계층은 Postgres를 실행합니다. 이 장치는 일시적인 상태만 유지하며, Postgres는 메모리의 버퍼와 빠른 로컬 디스크가 지원하는 로컬 컴퓨트 캐시를 공유합니다. 내구성 있는 데이터는 소유하지 않습니다.
컴퓨트는 내구성 상태를 소유하지 않기 때문이다:
- 데이터를 이동하거나 손실하지 않고 교체, 재시작, 자동 스케일링 또는 0으로 확장할 수 있습니다.
- 로컬 파일 시스템에 쓰는 대신, WAL을 저장 계층으로 스트리밍합니다.
- 여러 컴퓨트 인스턴스가 동일한 스토리지 계층에 연결할 수 있는데, 이것이 Lakebase가 리드 복제 본과 빠른 장애 조치 작업을 수행하는 방식입니다.
스토리지 계층
저장 계층은 내구성이 뛰어나며 컴퓨트와 독립적으로 작동합니다. 세 가지 구성 요소로 이루어져 있습니다.
세이프키퍼
세이프키퍼는 단일 기계에서 추출되어 매우 쉽게 사용할 수 있도록 하는 WAL입니다. Postgres가 WAL 레코드를 생성할 때, 이를 Paxos 기반 합의 프로토콜을 사용해 정족수 전체에 로그를 복제하는 세이프키퍼 그룹에 스트리밍합니다.
트랜잭션은 세이프키퍼 정족수가 WAL 레코드를 인정할 때 커밋되며, 단일 머신이 로컬 fsync. 내구성은 단일 디스크가 아니라 노드 간 복제에서 나옵니다.
페이지서버
페이지서버는 WAL에서 추출하고 재구축한 데이터 파일입니다. 페이지서버는 세이프키퍼에서 WAL 스트림을 소비하고 필요에 따라 페이지 버전을 구현합니다. 계산이 특정 로그 시퀀스 번호(LSN)로 페이지를 요청하면, 페이지서버는 이를 재구성하여 반환합니다.
페이지서버는 객체 저장 장치 위의 쓰기 스루 캐시 역할을 합니다. 이들은 비동기적으로 구체화된 페이지를 클라우드 객체 저장소에 보존하며, 페이지 재구성은 트랜잭션 커밋을 차단하지 않습니다.
클라우드 개체 스토리지
클라우드 객체 저장소는 전체 저장 계층의 내구성 기반입니다. 이 데이터는 페이지서버가 지속되는 페이지 데이터를 저장합니다.
Azure에서 Lakebase는 데이터를 Azure Blob Storage에 지속합니다.
객체 저장소는 핫 쿼리 경로에서 벗어납니다. 페이지서버만 읽습니다. 스토리지 중복성이 어떻게 작동하는지, 그리고 왜 컴퓨트 고가용성 설정과 독립적인지에 대한 자세한 내용은 스토리지 아키텍처를 참조하세요.
글쓰기 작동 방식
쓰기는 컴퓨트에서 저장 계층을 거쳐 흐릅니다:
- Postgres는 영향을 받은 페이지를 메모리에서 수정하고 WAL 레코드를 생성합니다.
- 컴퓨트는 WAL 레코드를 세이프키퍼로 스트리밍합니다.
- 세이프키퍼의 정족수가 기록을 인정하면 거래가 커밋되고 클라이언트는 성공을 얻습니다.
- 페이지서버는 WAL을 비동기적으로 적용하고 업데이트된 페이지를 객체 저장소로 영속성합니다.
세이프키퍼 정족수가 WAL 기록을 갖는 순간 거래는 지속성이 부여됩니다. 로그만으로도 데이터를 재구성하기에 충분하기 때문입니다. 페이지서버는 커밋 경로 밖에서 데이터 페이지를 재구성하고 저장하기 때문에, 커밋된 변경 사항을 위험에 빠뜨리지 않고 쓰기가 빠르게 유지됩니다.
읽기 작동 방식
리드는 빠른 순서로 캐시의 계층 구조를 확인하고, 해당 페이지가 있는 첫 번째 계층에서 멈춥니다:
- 버퍼 풀(메모리): Postgres는 컴퓨트 RAM에서 버퍼를 공유했습니다.
- 로컬 컴퓨트 캐시: 컴퓨트 노드에 디스크 백업 캐시가 있으며, 컴퓨트 메모리에 대해 크기가 설정됩니다.
- 페이지서버: 캐시 미스 시 컴퓨트는 페이지서버에 페이지를 요청하고, 페이지서버는 요청한 LSN에서 다시 구성합니다.
- 객체 저장: 페이지서버는 필요할 때 내부적으로 객체 저장소에서 읽습니다. 쿼리는 객체 저장소에 직접 도달하지 않습니다.
이 아키텍처가 가능하게 하는 것들
상태 없는 컴퓨팅과 내구성 저장소를 분리하는 것이 Lakebase의 여러 기능을 가능하게 합니다:
| 특징 | 이 기능이 가능하게 하는 것 |
|---|---|
| 자동 크기 조정 | 컴퓨트가 비스테이트(stateless)이기 때문에, Lakebase는 데이터를 이동하지 않고도 워크로드에 따라 컴퓨트 크기를 확장하거나 줄일 수 있습니다. |
| 0으로 크기 조정 | 컴퓨트는 저장이 지속되는 동안 완전히 일시정지할 수 있으며, 컴퓨트가 재개되면 데이터가 즉시 제공됩니다. |
| 즉석 지기 | 몇 초 만에 데이터베이스의 분리되고 작성 가능한 복사본을 만들 수 있습니다. 분기는 공유 스토리지에 대한 복사 시 쓰기 메타데이터 연산이기 때문에 데이터를 중복하지 않습니다. |
| 복제본 읽기 | 여러 컴퓨트 인스턴스가 동일한 저장 계층에서 읽기 때문에 복제본은 데이터 복사 없이 몇 초 만에 시작됩니다. |
| 시점 조회 | 저장 계층이 역사를 유지하기 때문에, 컴퓨트는 과거 시점에 부착하여 데이터를 다시 복사하지 않고 그 시점의 데이터베이스를 읽을 수 있습니다. |
| 빠른 장애 조치 | 장애 조치는 데이터 이동 없이 기존 저장소에 부착되는 보조 컴퓨팅 인스턴스를 촉진합니다. |
| RPO = 0 (커밋된 데이터 손실 없음) | Lakebase는 모든 커밋된 트랜잭션을 확인 전에 지속적으로 기록하기 때문에, 컴퓨트 실패, 재시작, 또는 0으로 확장될 때 커밋된 데이터를 잃지 않습니다. |
이 아키텍처가 LTAP 지원하는 방법
Lakebase는 모든 커밋된 변경 사항을 클라우드 객체 저장소에 지속적으로 저장하기 때문에, 동일한 데이터가 별도의 복제 파이프라인 없이도 트랜잭션과 함께 분석 워크로드를 수행할 수 있습니다. 이것이 바로 단일 데이터 사본이 거래 및 분석 엔진을 모두 지원하는 Lake Transactional and Analytical Processing(LTAP)의 기반입니다. LTAP가 이 아키텍처를 어떻게 기반으로 구축되었는지 알고 싶다면 LTAP 아키텍처를 참조하세요.
다음 단계
- 스토리지 아키텍처: 스토리지 중복성이 어떻게 작동하는지, 그리고 왜 컴퓨트 고가용성 설정과 독립적인지 알아보세요. 스토리지 아키텍처를 참조하세요.
- 데이터베이스 분기: 지점들이 어떻게 복사-온-라이트 스토리지를 사용해 즉각적이고 격리된 환경을 만드는 방식을 확인해 보세요. 브랜치를 참조하세요.
- 복제품 읽기: 동일한 저장 계층을 공유하는 읽기 전용 컴퓨트 인스턴스를 추가하세요. 읽기 복제본을 참조하세요.
- 핵심 개념: Lakebase를 독특하게 만드는 전체 개념들을 복습해 보세요. 핵심 개념을 참조하세요.