PostgreSQL용 AlloyDB: 지능형 데이터베이스 인식 스토리지

* 본 아티클의 원문은 2022년 5월 12일 Google Cloud 블로그(영문)에 게재되었습니다. 

Google I/O에서 발표된 PostgreSQL용 AlloyDB는 까다로운 엔터프라이즈급 트랜잭션 및 분석 워크로드를 처리하는 완전 관리형 PostgreSQL 호환 데이터베이스입니다. PostgreSQL에 클라우드의 장점을 결합한 덕분에 탄력적인 스토리지 및 컴퓨팅 용량 조정, 지능형 캐싱, AI/ML 기반 관리가 가능합니다. 게다가 AlloyDB는 탁월한 가격 대비 성능을 제공합니다. 성능 테스트 결과 표준 PostgreSQL 대비 트랜잭션 워크로드 처리 속도는 4배 이상 빠르고 분석 쿼리 속도는 최대 100배 더 빠른 것으로 나타났습니다. 이 모든 성능에 단순하고 예측 가능한 가격 책정 방식이 적용됩니다. 비즈니스에 중요한 애플리케이션 용도로 설계된 AlloyDB는 광범위한 데이터 보호뿐 아니라 99.99%에 달하는 업계 최고 수준의 가용성을 제공합니다. 

PostgreSQL용 AlloyDB의 우수한 성능과 가용성은 많은 혁신 기술로 뒷받침되고 있습니다. 'PostgreSQL용 AlloyDB 자세히 살펴보기' 시리즈 1부에서는 지능형으로, 데이터베이스를 인식하며 수평 확장성을 갖춘 PostgreSQL에 맞게 최적화된 스토리지 레이어에 대해 살펴봅니다. 

컴퓨팅 및 스토리지의 분리

PostgreSQL용 AlloyDB는 컴퓨팅과 스토리지를 분리한다는 기본 원칙에 따라 빌드되었으며 스택의 모든 레이어에서 분리를 활용하도록 설계되었습니다. 

AlloyDB는 데이터베이스 레이어의 스토리지 분리부터 시작해 PostgreSQL에 맞게 최적화된 새로운 지능형 스토리지 서비스를 도입 했습니다. 덕분에 I/O 병목 현상이 경감되고 로그 처리 시스템을 사용하여 많은 데이터베이스 작업을 스토리지 레이어에 오프로드할 수 있게 됩니다. 스토리지 서비스에서도 자체적으로 컴퓨팅과 스토리지가 분리되므로 로그 처리와 별도로 블록 스토리지 확장이 가능합니다. 

데이터베이스 내 컴퓨팅과 스토리지의 분리 형태는 수 년에 걸쳐 발전했습니다. 초기의 접근 방식에서는 컴퓨팅 레이어에 상관없이 스토리지 용량을 독립적으로 지정할 수 있었지만 시스템 전반적으로는 여전히 정적이고 탄력성이 부족했습니다. 클라우드 규모의 스토리지 솔루션을 토대로 빌드된 차세대 데이터베이스 시스템에서는 스토리지 탄력성이 개선되었으나 여전히 스토리지 클러스터가 지나치게 크거나 워크로드 급증(핫스팟) 시 IO가 부족해지는 문제가 있었습니다.

AlloyDB에서는 완전 분리형 아키텍처로 스토리지 레이어에서도 탄력적인 분산형 클러스터 역할을 할 수 있게 되었습니다. 그뿐만 아니라 워크로드 변화에 동적으로 적응하고, 내결함성과 가용성이 더 우수하며, 수평으로 읽기 처리량이 확장되는 비용 효율적인 읽기 풀을 지원합니다. 스택 전반의 다중 레이어 캐싱이 워크로드 패턴에 따라 자동으로 계층화되므로 클라우드 기반 스토리지의 규모, 경제성, 가용성이 그대로 유지되면서도 개발자가 향상된 성능을 누릴 수 있습니다. AlloyDB 아키텍처의 이러한 측면이 모두 결합되어 데이터베이스 분리 형태가 한 단계 더 발전하게 되었으며 AlloyDB의 탁월한 성능과 가용성에도 긍정적인 영향을 미쳤습니다.

모놀리식 설계의 문제

지금까지 PostgreSQL 데이터베이스는 하나의 머신에 스토리지와 컴퓨팅 리소스를 함께 배치하는 모놀리식 설계를 채택했습니다. 스토리지 용량이나 컴퓨팅 성능이 추가로 필요하면 보다 성능이 우수한 서버로 이전하거나 디스크를 추가하는 방법으로 시스템을 확장하게 됩니다. 추가 확장이 더 이상 가능하지 않거나 비용 효율적이지 않으면(서버의 성능이 높을수록 비용이 커짐) 복제를 사용해 데이터베이스의 읽기 전용 사본을 여러 개 만들기도 합니다. 

이러한 방식은 데이터베이스 로드와 구성에 좌우되므로 장애 조치 시간이 길어지고 예측이 어려워진다는 제약이 있습니다. 게다가 읽기 전용 복제본을 사용하면 속도가 느리고 비용이 높은 자체 데이터베이스 사본이 생성되므로 읽기 용량 확장 및 복제 지연 관리가 더욱 어려워집니다. 결과적으로 스토리지와 컴퓨팅이 긴밀하게 결합된 모놀리식 데이터베이스는 탄력성에 제약이 있을 수밖에 없습니다. AlloyDB는 컴퓨팅과 스토리지를 분리하는 방식으로 이러한 많은 제약을 극복할 수 있습니다.

AlloyDB에서는 데이터베이스 레이어의 확장성을 단일 (가상) 머신 용량 이상으로 높이기 위해 추가로 데이터베이스를 복사할 필요 없이 여러 개의 읽기 전용 복제본 인스턴스를 추가하여 읽기 전용 쿼리 처리를 지원할 수 있습니다. 스토리지 레이어가 여러 영역에 걸쳐 배포되고 어느 서버에서나 액세스할 수 있으므로 비용이 합리적이고(복제본 인스턴스별로 자체 스토리지가 필요하지 않기 때문) 최신 상태의 읽기 복제본 인스턴스를 신속하게 빌드할 수 있습니다. 기본적으로 이러한 설계 원칙을 사용하면  모놀리식의 기본 데이터베이스 인스턴스에서 기능을 분리한 플랫폼을 생성하고 성능, 확장성, 가용성, 관리 효율성이 향상된 클라우드 기반 구현 환경으로 전환할 수 있습니다.

AlloyDB 설계 개요

AlloyDB 스토리지 레이어는 다음과 같이 크게 세 가지 부분으로 구성된 분산 시스템입니다. 

1. 지연 시간이 짧은 리전별 로그 스토리지 서비스: 미리 쓰기 로그(WAL)를 매우 신속하게 기록

2. 로그 처리 서비스(LPS): 이러한 WAL 레코드를 처리하고 '구체화된' 데이터베이스 블록을 생성

3. 내결함성을 갖춘 샤딩된 리전별 블록 스토리지: 영역별 스토리지에 장애가 발생하더라도 내구성을 보장

아래의 그림 2는 로그 처리 서비스가 PostgreSQL 데이터베이스 레이어와 내구성 높은 스토리지에 통합된 모습을 대략적으로 나타낸 개념도입니다. WAL 로그 항목은 하나만 존재하는 기본 데이터베이스 인스턴스에 유지되고 데이터베이스 수정 작업(예: 삽입/삭제/업데이트)은 지연 시간이 짧은 리전별 로그 저장소에 반영되는 방식입니다. 그런 다음 로그 처리 서비스(LPS)에서 추가적인 처리 작업에 이러한 WAL 레코드를 소비합니다. 로그 처리 서비스는 PostgreSQL WAL 레코드와 PostgreSQL 스토리지 형식의 시맨틱스를 전체적으로 인지하므로 이러한 WAL 레코드에 설명되어 있는 수정 작업을 지속적으로 재생하고 샤딩된 리전별 스토리지 시스템에 최신 데이터베이스 블록을 생성할 수 있습니다. 이러한 블록은 기본 데이터베이스 인스턴스에 다시 사용되거나(재시작하거나 단순히 블록에서 캐시가 소진되는 경우), 스토리지 서비스가 운영되는 리전 내 영역에서 발생하는 하나 이상의 복제본 인스턴스에 사용될 수 있습니다.

또한 AlloyDB는 복제본 인스턴스의 로컬 캐시를 최신 상태로 유지하기 위해 기본 인스턴스의 WAL 레코드를 복제본 인스턴스로 스트리밍하여 최신 변경사항을 알리는 역할도 합니다. 변경되는 블록에 대한 정보가 없으면 복제본 인스턴스에서 캐시된 블록이 임의로 비활성 상태가 될 수 있습니다.

이 접근 방식을 취할 때의 핵심적인 이점은 무엇일까요? 이 설계에 숨어 있는 의미를 조금 더 자세히 살펴보겠습니다.

• 스토리지 레이어 수준에서도 완전한 컴퓨팅/스토리지 분리 구현: LPS는 워크로드 패턴에 따라 확장하고 핫스팟 방지에 필요하다면 투명한 방식으로 컴퓨팅 리소스를 추가해 로그를 처리할 수 있습니다. 로그 처리기는 컴퓨팅에 한해 공유된 리전별 스토리지와 연결되어 있으므로 데이터를 복사할 필요 없이 유연하게 확장 또는 축소할 수 있습니다.

• 스토리지 레이어 복제: 모든 블록을 여러 영역에 동기식으로 복제하기 때문에 한 영역에 장애가 발생하더라도 스토리지 레이어가 자동으로 시스템을 보호하고 데이터베이스 레이어에 영향을 미치거나 수정을 발생시키지 않습니다. 

• 효율적인 IO 경로/전체 페이지 쓰기 없음: 업데이트 작업의 경우 컴퓨팅 레이어가 WAL 레코드만 스토리지 레이어로 전달하면 여기에서 레코드가 지속적으로 재생됩니다. 이 설계 방식에서는 데이터베이스 레이어를 검사할 필요가 없고 파손된 페이지 문제 방지를 비롯한 어떤 이유로든 전체 데이터베이스 블록을 스토리지 레이어로 보낼 필요가 없습니다. 덕분에 데이터베이스 레이어는 쿼리 처리 태스크에 집중하게 되고 데이터베이스와 스토리지 레이어 간의 네트워크가 효율적으로 사용됩니다.

• 지연 시간이 짧은 WAL 쓰기 작업: 지연 시간이 짧은 리전별 로그 스토리지를 사용하면 트랜잭션 커밋 작업 시 시스템이 WAL 로그 레코드를 신속하게 플러싱할 수 있습니다. 그 결과, 트랜잭션 커밋 작업이 매우 신속하게 이루어지고 최대 부하 상황에서도 시스템이 높은 트랜잭션 처리량을 달성할 수 있습니다.

• 읽기 복제본 인스턴스의 신속한 생성: 영역 및 블록과 무관하게 스토리지 서비스를 사용할 수 있기 때문에 데이터베이스 레이어에 있는 하나 이상의 읽기 복제본 인스턴스가 스토리지 서비스에 연결될 수 있으며 데이터베이스의 '개별' 복사본을 만들지 않아도 쿼리를 처리할 수 있습니다. 스토리지 레이어에 있는 데이터가 필요에 따라 점진적으로 로드될 수 있기 때문에 읽기 복제본 인스턴스의 생성 속도가 매우 빠릅니다. 즉 전체 데이터베이스 사본을 복제본 인스턴스에 스트리밍하지 않아도 쿼리 처리를 시작할 수 있습니다.

• 신속한 재시작 복구: 로그 처리 서비스가 온라인 작업 도중 지속적으로 WAL 로그 레코드를 재생하기 때문에 재시작 복구 도중 처리해야 하는 미리 쓰기 로그 양이 최소화됩니다. 결과적으로 시스템 재시작 시간이 큰 폭으로 단축됩니다. WAL 관련 복구 작업이 최소한으로 유지되기 때문입니다.

• 스토리지 레이어 백업: 스토리지 서비스에서 백업 작업이 완전히 처리되므로 데이터베이스 레이어의 성능과 리소스에는 영향을 미치지 않습니다.

쓰기 작업 처리

데이터베이스 수정 작업 과정을 따라가면서 시스템 설계를 보다 자세히 살펴보겠습니다(그림 3). 이 과정은 클라이언트로 시작됩니다. 클라이언트의 TCP 연결을 통해 INSERT SQL이 데이터베이스 레이어의 기본 인스턴스에 전달되는 경우를 예로 들어보겠습니다. 기본 인스턴스는 이 문을 처리( 메모리 내 데이터 및 색인 구조 업데이트)하고 업데이트 작업의 시맨틱스를 캡처하는 WAL 로그 레코드를 준비합니다. 트랜잭션 커밋과 함께 이 로그 레코드는 우선 지연 시간이 짧은 리전별 로그 스토리지에 동기식으로 저장되었다가 다음 단계에서 로그 처리 서비스에 의해 비동기식으로 픽업됩니다.

스토리지 레이어는 의도적으로 여러 구성요소로 분리되어 스토리지 레이어에서 수행하는 각각의 태스크(예: 로그 저장, 로그 처리, 블록 저장)에 맞게 최적화됩니다. 트랜잭션 커밋 지연 시간을 단축하기 위해서는 최대한 빨리 로그 레코드를 내구성 높은 방식으로 저장하여 트랜잭션 내구성을 달성하는 것이 중요합니다. WAL 로그 쓰기는 추가만 가능한 작업이기 때문에 AlloyDB는 성능이 높고 지연 시간이 짧은 스토리지 솔루션을 사용해 이 용도에 맞게 특별히 최적화합니다. 두 번째 단계에서는 WAL 로그 레코드를 레코드가 참조하는 블록의 이전 버전에 적용하는 방식으로 처리해야 합니다. 이 작업을 수행하기 위해 스토리지 레이어의 LPS 하위 시스템은 무작위로 블록을 조회하고 PostgreSQL의 재실행 처리 로직을 성능 및 확장성이 높은 방식으로 적용합니다.

업데이트된 블록의 리전별 내구성을 보장하기 위해 로그 처리 서비스(LPS)의 다중 인스턴스가 리전의 영역별로 실행됩니다. 모든 로그 레코드가 처리되고 그 결과 생성된 버퍼가 샤딩된 리전별 블록 스토리지(아래 참조)에 내구성 높은 방식으로 저장된 후에야 리전별 로그 스토리지에서 로그 레코드가 삭제됩니다.

읽기 작업 처리

읽기 작업도 마찬가지로 SQL 쿼리가 데이터베이스 서버에 전송되면서 시작됩니다. 이때 기본 인스턴스에 전달될 수도 있고, 읽기 전용 쿼리 처리에 사용되는 하나 이상의 복제본 인스턴스에 전달될 수도 있습니다(그림 4에 두 가지 경로가 모두 나와 있음). 데이터베이스 서버는 기존 PostgreSQL 시스템과 동일하게 쿼리 파싱, 계획, 처리를 수행합니다. 필요한 모든 블록이 메모리 상주 버퍼 캐시에 존재하면 데이터베이스가 스토리지 레이어와 상호 작용할 필요가 전혀 없습니다. 작업 중인 집합이 버퍼 캐시에 없는 경우에도 AlloyDB는 신속한 쿼리 처리를 위해 초고속 블록 캐시를 데이터베이스 레이어에 바로 통합합니다. 이 캐시는 버퍼 캐시의 용량을 큰 폭으로 확장하므로 시스템 속도가 이러한 경우에도 더욱 빨라집니다.

하지만 이러한 캐시를 모두 사용해도 블록이 모자라면 해당되는 블록 가져오기 요청이 스토리지 레이어로 전달됩니다. 가져올 블록 번호와 별개로 이 요청은 데이터를 읽을 로그 시퀀스 번호(LSN)를 지정합니다. 이때 특정 LSN을 사용하는 이유는 쿼리 처리 중에 데이터베이스 서버가 항상 일관된 상태를 확인할 수 있기 때문입니다. PostgreSQL 버퍼 캐시에서 블록을 제거했다가 바로 다시 로드하는 경우, 또는 동시에 (구조적으로) 수정 가능한 B-트리 같은 복잡한 다중 블록 인덱스 구조를 통과하는 경우에 특히 일관성이 중요합니다.

스토리지 레이어의 로그 처리 서비스는 블록 가져오기 요청도 처리해야 합니다. 모든 LPS에는 자체적인 PostgreSQL 버퍼 캐시 인스턴스가 있습니다. 요청된 블록이 이미 LPS 버퍼 캐시에 있는 경우에는 I/O 작업 없이 즉시 데이터베이스 레이어로 반환될 수 있습니다. 요청된 블록이 캐시에 없는 경우에는 LPS가 샤딩된 리전별 스토리지에서 블록을 가져와서 데이터베이스 레이어에 다시 전송합니다. 로그 처리 서비스는 처리되지 않은 로그 레코드가 있는 블록을 추적하기 위해 일부 부가적인 기록 작업도 수행해야 합니다. 이러한 블록에 대한 요청이 도착하면(데이터베이스 레이어는 캐시에서 제거된 후 참조된 블록만 요청하므로 가능성은 낮은 이벤트임) 해당 로그 레코드에 대한 재실행 처리가 완료될 때까지 읽기 요청이 중단되어야 합니다. 따라서 이러한 중단 상황을 피하려면 LPS 레이어의 WAL 처리가 가장 까다로운 엔터프라이즈 워크로드도 처리할 수 있을 정도의 효율성과 확장성을 갖추는 것이 매우 중요합니다. 이에 대해서는 다음 섹션에서 더 자세히 설명하겠습니다.

스토리지 레이어 탄력성

지금까지 로그 처리 서비스를 영역당 하나의 프로세스로 보고 설명했습니다. 하지만 까다로운 엔터프라이즈 워크로드의 경우 LPS 프로세스가 하나뿐이면 확장성 문제가 야기될 가능성이 있습니다. LPS가 지속적으로 WAL 레코드를 적용하는 한편 기본 및 다중 복제본 인스턴스의 읽기 요청까지 처리해야 하기 때문입니다. 

이 문제를 해결하기 위해 데이터베이스는 샤드라는 여러 개의 블록 그룹으로 수평적으로 파티셔닝되어 지속성을 유지합니다. 샤드와 LPS 리소스 둘 다 독립적으로 수평 확장됩니다.

각 샤드는 언제나 정확히 하나의 LPS에 할당되지만 LPS는 각각 여러 개의 샤드를 처리할 수 있습니다. 샤드와 LPS 간 매핑은 동적이어서 액세스 패턴이 증가하면 LPS 리소스 수를 확장하고 샤드를 재할당하는 방식으로 스토리지 레이어가 탄력적으로 반응할 수 있습니다. 이러한 방식으로 스토리지 레이어의 처리량이 확장될 뿐 아니라 핫스팟을 피할 수 있게 됩니다.

여기서 두 가지 예시를 고려해 보겠습니다. 첫 번째 사례는 전체 시스템 로드가 증가해서 실제로 모든 샤드가 전보다 많은 요청을 받는 경우입니다. 이 경우에는 스토리지 레이어가 LPS 인스턴스 수를 예를 들어 2배로 늘릴 수 있습니다. 새로 생성된 로그 처리 서버 인스턴스는 샤드의 일부를 가져오는 방식으로 기존 인스턴스를 오프로드합니다. 이 샤드 재할당은 데이터 복사나 비용이 많이 드는 그 밖의 작업이 수반되지 않아 매우 빠르게 수행되고 데이터베이스 레이어에 영향을 미치지 않습니다.

샤드 재할당이 매우 유익한 또 다른 예시는 시스템에서 작은 샤드 집합의 사용량이 갑자기 늘어나는 경우입니다(예: 슈퍼볼 광고 후 데이터베이스에 보관된 특정 제품군에 대한 정보가 자주 요청되는 경우). 이 경우도 마찬가지로 스토리지 레이어가 동적으로 반응할 수 있습니다. 가장 극단적인 사례에서는 워크로드 급증이 관찰되는 각 샤드를 이 샤드의 로드만 처리하는 전용 LPS 인스턴스에 할당하는 방식으로 반응하기도 합니다. 결과적으로 샤드 재지정 및 LPS 탄력성을 갖추면 시스템이 워크로드 급증 시에도 높은 성능과 처리량을 유지할 수 있고 워크로드가 다시 감소하면 다시 리소스 공간을 줄이게 됩니다. 이 동적인 크기 조정 및 스토리지 레이어 탄력성은 데이터베이스 레이어와 최종 사용자의 측면에서 모두 완전히 자동으로 이루어지고 그 어떤 사용자 조치도 필요하지 않습니다.

스토리지 레이어 복제 및 복구

AlloyDB는 한 영역에 장애가 발생하더라도 데이터 내구성과 높은 시스템 가용성을 제공하는 데 그 목적이 있습니다. 데이터 센터에 정전이나 화재가 발생하는 경우를 예로 들 수 있습니다. 이와 같은 경우에 대비해 모든 AlloyDB 인스턴스의 스토리지 레이어는 3개 영역에 걸쳐 배포됩니다. 각 영역에는 데이터베이스 상태의 완전한 사본이 있으며, 위에서 설명한 것처럼 지연 시간이 짧은 리전별 로그 스토리지 시스템의 WAL 레코드를 적용하는 방식으로 계속 업데이트됩니다.

그림 6에서는 전체 시스템이 3개 영역에 걸쳐 분산되어 있으며 여러 개의 로그 처리 서버(LPS)와 서버당 여러 개의 샤드로 구성된 것을 볼 수 있습니다. 영역별로 각 샤드의 사본이 존재합니다.

이 구조에서는 최소한의 오버헤드로 블록 조회 작업을 수행할 수 있습니다. 각 영역마다 전체 데이터베이스 상태의 사본이 자체적으로 존재하므로 영역의 경계를 넘어 데이터베이스 레이어별 블록 조회 작업을 수행할 필요가 없습니다. 그뿐 아니라 스토리지 레이어는 모든 영역에 WAL 레코드를 계속 적용하고 데이터베이스 레이어는 요청되는 각 블록에 타겟 버전 LSN을 제공(위 참조)하므로 조회 작업 중에 읽기 쿼럼을 형성할 필요가 없습니다. 

단일 영역의 전체를 사용할 수 없게 되는 경우, 같은 리전의 새로운 영역을 통합한 후 전체 데이터베이스 상태의 사본으로 채우는 방법으로 장애가 발생한 영역을 스토리지 레이어로 교체할 수 있습니다. 그림 6에 시각화되어 있는 것처럼 새로운 영역에 각 샤드의 사본을 제공하고 최신 로그 처리 서비스를 실행하여 최신 WAL 레코드로 샤드를 계속 업데이트하는 방식으로 이 작업을 수행할 수 있습니다. 스토리지 레이어도 마찬가지로 데이터베이스 레이어의 조정이나 보조 활동 없이 모든 영역 장애 조치를 내부적으로 처리합니다.

스토리지 레이어의 이러한 기본 제공 기능 외에도 AlloyDB는 수동 및 자동으로 진행되는 정기적인 백업 작업을 모두 통합해 애플리케이션 수준 장애 또는 작업자 오류(실수로 테이블을 드롭하는 경우처럼)를 안전하게 방지합니다.

AlloyDB의 지능형 스토리지에서 얻을 수 있는 이점

요약하면 PostgreSQL용 AlloyDB는 데이터베이스의 컴퓨팅 및 스토리지 레이어를 분리하고 로그 처리 시스템 사용을 통해 많은 데이터베이스 작업을 스토리지 레이어에 오프로드합니다. 완전 분리형 아키텍처가 스토리지 레이어 수준에서도 실현되면서 탄력적인 분산형 클러스터 역할을 할 수 있게 되었습니다. 그뿐 아니라 워크로드 변화에 동적으로 적응하고, 내결함성과 가용성이 더 우수하며, 선형으로 읽기 처리량이 확장되는 비용 효율적인 읽기 풀을 지원합니다. 오프로드되면 쿼리 처리에 온전히 집중하고 유지보수 태스크를 스토리지 레이어에 위임할 수 있어 기본 인스턴스의 쓰기 처리량도 훨씬 더 높아집니다. 이러한 모든 측면이 결합되어 AlloyDB의 지능형 데이터베이스 인식 스토리지 레이어는 AlloyDB의 탁월한 성능 및 가용성을 실현합니다. 

직접 AlloyDB를 사용해 보려면 cloud.google.com/alloydb를 방문해 보세요. 또한 AlloyDB의 컬럼 형식 엔진에 대해 다룰 다음 게시물도 기대해 주세요.

본 게시물과 후속 게시물에서 다루는 AlloyDB의 기술적 혁신은 Google Cloud 엔지니어링팀의 헌신적인 노력이 맺은 결실입니다.