서버리스 PostgreSQL이란 무엇인가요?

서버리스 PostgreSQL (Postgres)은 컴퓨팅과 스토리지를 분리하는 완전 관리형 클라우드 데이터베이스 모델입니다. 이를 통해 수요에 따라 각 요소를 독립적이고 자동으로 확장할 수 있습니다. 애플리케이션은 데이터베이스 서버를 직접 관리하는 대신, 워크로드에 따라 컴퓨팅 리소스를 자동으로 프로비저닝하고 사용하지 않을 때는 축소하는 시스템과 상호 작용합니다.

반면, 기존 Postgres 환경에서는 팀이 인프라 규모를 미리 산정하고, 용량 요구 사항을 예측하며, 시간에 따른 확장성을 관리해야 합니다. 이로 인해 오버프로비저닝, 유휴 비용 낭비, 수요가 가용 용량을 초과할 때의 성능 병목 현상이 자주 발생합니다.

서버리스 Postgres는 다음과 같은 방식으로 이러한 오버헤드를 크게 줄여줍니다.

• 서버 프로비저닝 및 인프라 관리 제거
• 수동 용량 계획의 필요성 제거
• 유휴 컴퓨팅이 아닌 실제 활성 사용량에 대해서만 비용 청구

"서버리스"라는 용어는 애플리케이션이 서버나 인프라 없이 실행된다는 의미가 아니기 때문에 오해의 소지가 있을 수 있습니다. 기본 시스템은 여전히 존재하지만, 클라우드 제공업체에 의해 추상화되고 완전 관리됩니다. 서버 설정, 확장, 유지 관리와 같은 작업은 사용자에게 거의 보이지 않으며 직접 구성하거나 유지 관리할 필요가 없습니다.

기존 vs. 서버리스 PostgreSQL

PostgreSQL 아키텍처는 프로비저닝된 인프라 모델에서 보다 동적인 클라우드 네이티브 디자인으로 발전해 왔습니다.

기존 Postgres 배포는 워크로드에 관계없이 고정된 컴퓨팅 리소스를 지속적으로 실행합니다. 확장을 위해서는 수동 개입이나 사전 구성된 임계값이 필요하며, 데이터베이스가 유휴 상태일 때도 항상 켜져 있는 비용이 발생합니다.

서버리스 Postgres는 다른 모델을 도입했습니다. 컴퓨팅 리소스는 온디맨드로 프로비저닝되어 워크로드 활동에 따라 자동으로 확장되고, 사용하지 않을 때는 0으로 축소됩니다. 요금은 예약된 용량이 아닌 실제 소비량을 기준으로 청구됩니다.

서버리스 Postgres는 Databricks SQL과 같은 서버리스 컴퓨팅 플랫폼과 함께 사용할 수도 있어, 통합된 레이크하우스 아키텍처 내에서 동일한 기본 데이터에 계속 액세스하면서 분석 쿼리를 독립적으로 실행할 수 있습니다.

이러한 전환은 분리된 스토리지 레이어 및 온디맨드 컴퓨팅 오케스트레이션과 같은 아키텍처 변화 덕분에 가능해졌으며, 이를 통해 리소스를 독립적으로 확장하고 워크로드 활동에 동적으로 대응할 수 있습니다.

주요 차이점은 다음과 같습니다:

차세대 진화: 레이크베이스 아키텍처

데이터베이스 아키텍처가 발전함에 따라, 서버리스 Postgres를 기반으로 하면서 그 한계를 해결하는 세 번째 모델이 등장하고 있습니다. 이 접근 방식은 때로 레이크베이스 아키텍처라고도 불립니다.

서버리스 Postgres는 확장성을 개선하고 운영 오버헤드를 줄여주지만, 일반적으로 분석 시스템과는 분리되어 있습니다. 이러한 분리로 인해 운영 데이터베이스와 분석 플랫폼 간의 데이터 이동, 복제 또는 동기화가 필요한 경우가 많습니다.

레이크베이스 아키텍처는 데이터 스토리지 및 처리에 대한 우리의 생각을 바꾸고 있습니다. 트랜잭션 데이터베이스의 강력함과 레이크하우스 기반의 유연성을 결합하여, 운영 및 분석 워크로드를 모두 함께 실행할 수 있는 단일 플랫폼을 구축합니다. 즉, 서로 다른 작업을 위해 별도의 시스템을 두는 대신 하나의 공유 데이터 플랫폼에서 모든 작업을 수행할 수 있습니다. 그 결과 데이터 중복이 줄어들고 데이터에 액세스하고 사용하는 방법이 훨씬 더 간단해집니다. 모든 것을 하나로 통합함으로써 레이크베이스 아키텍처는 데이터를 더 쉽게 관리하고 분석할 수 있도록 지원하며, 이는 더 나은 의사 결정과 보다 효율적인 운영으로 이어질 수 있습니다.

레이크베이스 아키텍처 작동 방식

레이크베이스 아키텍처는 서버리스 Postgres 패턴을 기반으로 구축되는 동시에 클라우드 스토리지 및 데이터 플랫폼과의 긴밀한 통합을 도입합니다.

주요 구성 요소는 다음과 같습니다:

• 분리된 컴퓨팅 및 스토리지
  컴퓨팅은 상태 비저장(stateless) 방식이며 독립적으로 확장되는 반면, 스토리지는 영구적이고 분산된 상태로 유지됩니다.
• 임시 컴퓨팅
  컴퓨팅 리소스는 쿼리를 처리하기 위해 가동되었다가 유휴 상태일 때 축소되므로, 항상 켜져 있는 인프라를 유지하지 않고도 탄력성을 확보할 수 있습니다.
• 로그 기반 스토리지 시스템
  데이터 변경 사항은 연속적인 로그로 캡처되며, 이는 데이터베이스 상태를 재구성하고 브랜칭, 복구 및 시간 기반 액세스와 같은 기능을 지원하는 데 사용할 수 있습니다.
• 기반으로서의 오브젝트 스토리지
  내구성 있는 데이터가 클라우드 오브젝트 스토리지에 저장되므로 확장성, 내구성 및 레이크하우스 아키텍처와의 정렬이 가능합니다.
• 컨트롤 플레인 및 오케스트레이션
  제어 레이어는 확장, 라우팅 및 수명 주기 이벤트를 관리하여 컴퓨팅과 스토리지를 동적으로 조정합니다.

이것이 중요한 이유

공유된 기반 위에서 트랜잭션 및 분석 기능을 결합함으로써 레이크베이스 아키텍처는 다음과 같은 이점을 제공할 수 있습니다:

• 시스템 간의 데이터 중복 감소 또는 제거
• 운영 데이터에 대한 실시간에 가까운 분석 지원
• 인프라 통합을 통한 데이터 아키텍처 단순화
• 트랜잭션 및 분석 액세스가 모두 필요한 AI 애플리케이션을 포함하여 새로운 워크로드 지원

이러한 변화는 개별 시스템을 최적화하는 것에서 벗어나 단일 데이터 아키텍처 내에서 시스템을 통합하는 방향으로의 전환을 반영합니다.

서버리스 Postgres 아키텍처 작동 방식

서버리스 Postgres는 컴퓨팅과 스토리지를 독립된 레이어로 분리하는 클라우드 네이티브 아키텍처를 기반으로 구축되었습니다. 이러한 기본 설계 원칙은 각 구성 요소를 독립적으로 확장할 수 있도록 하여 효율성과 유연성을 향상시킵니다.

이 아키텍처의 핵심 기능은 '0으로 축소(scale-to-zero)' 동작입니다. 실행 중인 쿼리가 없으면 시스템이 컴퓨팅 리소스를 자동으로 일시 중단합니다. 새 쿼리가 실행되면 컴퓨팅이 다시 활성화됩니다. 이로 인해 콜드 스타트 지연(cold start latency)이라고 하는 짧은 지연이 발생하며, 이는 제공업체 및 구성에 따라 수 밀리초에서 수 초까지 걸릴 수 있습니다.

또 다른 중요한 기능은 종종 copy-on-write 기술을 사용하여 구현되는 데이터베이스 브랜칭(branching)입니다. 브랜칭을 통해 팀은 데이터를 복제하지 않고도 개발, 테스트 또는 스테이징을 위한 격리된 데이터베이스 환경을 만들 수 있습니다. 브랜치에서 변경한 사항은 원래 데이터베이스에 영향을 미치지 않으므로 더 빠른 반복 작업과 더 안전한 실험이 가능합니다.

주요 서버리스 Postgres 제공업체

서버리스 Postgres 제품은 프로비저닝된 데이터베이스에서 완전한 클라우드 네이티브 아키텍처로 진화하는 다양한 단계를 반영합니다. 초기 관리형 서비스는 기존 데이터베이스 아키텍처 내에서 자동 확장을 도입했습니다. 보다 최근의 클라우드 네이티브 디자인은 AI 에이전트, 실시간 애플리케이션 및 현대적인 운영 워크로드를 지원하도록 구축되었습니다. 이러한 시스템은 컴퓨팅과 스토리지를 완전히 분리하고 빠른 확장, 브랜칭, 보다 유연한 리소스 관리와 같이 이전 모델에서는 달성하기 어려웠던 기능을 도입합니다. Neon과 Databricks Lakebase는 이러한 기반 위에 구축되었으며, AI 지향 애플리케이션 및 에이전트 기반 시스템의 요구 사항에 맞게 설계되었습니다.

• Databricks Lakebase
  트랜잭션 데이터베이스를 레이크하우스 기반과 통합하여 서버리스 Postgres를 확장하는 레이크베이스 아키텍처 기반의 운영 데이터베이스입니다. AI 에이전트, 실시간 애플리케이션 및 현대적인 운영 워크로드의 요구 사항에 맞게 설계된 Databricks Lakebase를 사용하면 운영 및 분석 워크로드가 공통 데이터 플랫폼을 공유할 수 있습니다. 사용 사례로는 AI 에이전트 상태 저장, 트랜잭션 애플리케이션 구동, 앱 및 워크플로에 직접 분석 인사이트 제공 등이 있습니다. 그 결과 데이터 이동이 줄어들고 다양한 사용 사례에서 보다 일관된 액세스가 가능해집니다.
• Amazon Aurora Serverless v2
  데이터베이스 재시작 없이도 세분화된 오토스케일링을 제공하는 AWS 내의 Postgres 호환 관리형 서비스입니다. Aurora Serverless v2는 엔터프라이즈 워크로드용으로 설계되었으며 네트워킹, 보안 및 모니터링을 위한 AWS 서비스와 긴밀하게 통합됩니다. 운영 오버헤드는 줄어들지만, 확장 동작 및 리소스 격리는 여전히 기본 인프라의 제약을 반영할 수 있습니다.
• Neon
  로그 기반 스토리지를 갖추고 완전히 분리된 컴퓨팅 및 스토리지 모델을 기반으로 구축된 레이크베이스 아키텍처입니다. Neon은 scale-to-zero 기능과 데이터베이스 브랜칭을 지원하여 빠른 환경 생성과 더 동적인 개발 워크플로우를 가능하게 합니다.

분석 및 데이터 처리 워크로드의 경우, Databricks SQL과 같은 플랫폼에서도 서버리스 컴퓨팅을 사용할 수 있습니다. 트랜잭션(OLTP) 데이터베이스는 아니지만, 이러한 시스템은 분석을 위한 서버리스 쿼리 실행을 제공하며 Postgres 기반 시스템과 함께 작동할 수 있습니다.

오픈 소스 기반 및 클라우드 네이티브 옵션

Postgres는 널리 사용되는 오픈 소스 관계형 데이터베이스 시스템입니다. 서버리스 Postgres 제품군은 이러한 기반 위에 구축되었으며 확장 기능, psql과 같은 명령줄 도구, 일반적인 ORM 등을 포함하는 광범위한 Postgres 생태계와 완전한 호환성을 유지합니다.

구현 방식은 기본 시스템 중 오픈 소스인 부분과 독점 기술인 부분의 비율에 따라 다릅니다. Neon과 같은 일부 제공업체는 오픈 소스 인프라를 기반으로 구축되어 아키텍처의 더 많은 부분을 커뮤니티에 공개합니다. 반면 Amazon Aurora Serverless와 같은 다른 제공업체는 기본 구현의 상당 부분을 추상화하는 독점 관리형 서비스입니다.

어떤 접근 방식을 사용하든 대부분의 서버리스 Postgres 솔루션은 완전한 Postgres 호환성을 유지하는 동시에 자동 확장, 데이터베이스 브랜칭, 관리형 운영과 같은 클라우드 네이티브 기능을 추가하는 것을 목표로 합니다.

이러한 차이는 팀이 성능과 비용에 대해 가질 수 있는 가시성과 제어력에 영향을 미칠 수 있습니다. 오픈 소스 기반 시스템은 더 뛰어난 투명성과 유연성을 제공할 수 있는 반면, 독점 관리형 서비스는 종종 사용 편의성과 운영 단순성을 우선시합니다.

요금제 모델 및 성능 트레이드오프

프로덕션 워크로드를 위해 서버리스 Postgres를 평가할 때는 요금제 모델과 성능 특성이 비용, 지연 시간 및 전반적인 시스템 동작에 어떤 영향을 미치는지 이해하는 것이 중요합니다.

사용량 기반 요금제: 실제 지불하는 비용의 기준

대부분의 서버리스 Postgres 제공업체는 다음과 같은 세 가지 주요 기준으로 요금을 부과합니다.

• 컴퓨팅: 일반적으로 vCPU 시간 또는 ACU 초와 같이 쿼리 실행 중에 사용된 리소스를 기준으로 측정됩니다.
• 스토리지: 저장된 데이터의 양을 기준으로 청구되며, 보통 월별 GB 단위로 계산됩니다.
• 데이터 전송: 리전 및 네트워크 구성에 따라 데이터베이스로 유입되고 유출되는 데이터에 대해 부과되는 요금입니다.

컴퓨팅은 온디맨드로 프로비저닝되므로 워크로드 활동에 따라 비용이 확장됩니다. 따라서 서버리스 요금제는 트래픽이 가변적이거나 예측하기 어려운 애플리케이션에 매우 적합합니다.

많은 제공업체가 개발, 테스트 및 소규모 워크로드에 유용한 프리 티어를 제공합니다. 이러한 티어에는 일반적으로 컴퓨팅 사용량, 스토리지 또는 활성 런타임에 대한 제한이 포함되어 있어 프로덕션 워크로드나 지속적인 트래픽이 발생하는 애플리케이션에는 적합하지 않습니다.

서버리스 요금제는 가변적인 워크로드에 효율적일 수 있지만, 항상 가장 저렴한 옵션은 아닙니다. 트래픽이 많고 상시 가동되는 워크로드나 장시간 실행되는 쿼리가 있는 경우, 총 비용이 고정 용량의 프로비저닝된 데이터베이스 인스턴스 비용을 초과할 수 있습니다.

콜드 스타트, 확장성 및 프로덕션 안정성

서버리스 Postgres에서 가장 먼저 고려해야 할 성능 요소 중 하나는 콜드 스타트 지연 시간입니다. 데이터베이스가 0으로 축소된 경우, 쿼리를 실행하기 전에 컴퓨팅을 다시 활성화해야 합니다. 이로 인해 제공업체 및 구성에 따라 약 100밀리초에서 수 초에 이르는 지연이 발생할 수 있습니다.

콜드 스타트의 영향을 줄일 수 있는 몇 가지 완화 방법은 다음과 같습니다.

• 완전한 일시 중단을 방지하기 위해 주기적으로 "keep-alive" 핑 보내기
• 리소스를 부분적으로 활성 상태로 유지하도록 최소 컴퓨팅 하한선 구성하기
• 아키텍처 설계를 통해 콜드 스타트를 최소화하거나 제거하는 제공업체 선택하기

또한 서버리스 시스템은 변화하는 워크로드를 처리하기 위해 자동 확장에 의존합니다. 쿼리 볼륨 증가에 대응하여 컴퓨팅 리소스를 확장할 수 있으며, 일부 경우에는 동시 액세스를 지원하기 위해 읽기 복제본을 독립적으로 확장할 수도 있습니다. 이러한 탄력성은 예측할 수 없는 트래픽 급증이 발생하는 애플리케이션에 특히 유용합니다.

프로덕션 워크로드의 경우 가용성과 결함 허용성은 중요한 고려 사항입니다. 대부분의 관리형 서버리스 Postgres 제공업체는 여러 가용 영역에 데이터를 복제하고 내장된 백업 및 복구 기능을 제공합니다. 하지만 서비스 수준 보장 및 복구 동작은 제공업체마다 다르므로 프로덕션에 사용하기 전에 SLA 보장 범위를 검토하고 확인하는 것이 중요합니다.

콜드 스타트 동작 및 자동 확장과 같은 기능 덕분에 서버리스 Postgres는 가변적인 트래픽이 발생하는 워크로드에 적합하지만, 지연 시간에 민감하거나 상시 가동되는 애플리케이션에는 트레이드오프가 발생할 수 있습니다.

서버리스 Postgres 사용 사례 및 제한 사항

서버리스 Postgres와 레이크베이스 아키텍처는 서로 다른 워크로드 요구 사항을 충족합니다. 어떤 모델이 귀하의 사용 사례에 적합한지 이해하면 불필요한 복잡성과 비용을 피하는 데 도움이 될 수 있습니다.

다음 지침은 서버리스 Postgres와 레이크베이스 아키텍처 중 어떤 것이 귀하의 워크로드에 적합한지 결정하는 데 도움이 될 수 있습니다.

서버리스 Postgres에 적합한 경우

• 대부분의 OLTP 워크로드

레이크베이스 아키텍처에 더 적합한 경우:

• AI 에이전트 개발 및 배포
• 변동이 심하거나 일시적으로 급증하는(bursty) 워크로드
• 개발, 테스트 및 스테이징 환경
• 비용 최적화 및 운영 오버헤드 감소를 목표로 하는 스타트업
• 서버리스 또는 에지 기반 애플리케이션
• 빠른 환경 생성이 가능한 CI/CD 워크플로우
• 멀티 테넌트 SaaS 애플리케이션(브랜칭 및 자동 확장)

더 일관된 성능이나 상시 가동 가용성이 필요한 워크로드의 경우, 레이크베이스 아키텍처는 공유 데이터 플랫폼에서 컴퓨팅과 스토리지가 조정되는 방식을 재고하여 이러한 요구 사항을 해결합니다.

서버리스 Postgres 시작하는 방법

서버리스 Postgres를 시작하는 과정은 일반적으로 다음과 같이 간단합니다.

1. 워크로드 요구 사항, 확장 동작 및 생태계 선호도에 따라 제공업체를 선택합니다.
2. 제공업체의 콘솔 또는 API를 통해 데이터베이스 인스턴스를 생성합니다.
3. 자격 증명, 리전 및 액세스 설정으로 연결 문자열을 구성합니다.
4. 표준 Postgres 클라이언트, ORM 또는 psql 명령줄 도구를 사용하여 연결합니다.

설정은 비교적 간단하지만, 초기 선택이 전반적인 성능과 내구성에 큰 영향을 미칠 수 있습니다. 최초 배포 시 고려해야 할 사항은 다음과 같습니다.

• 콜드 스타트 지연 시간이 우려되는 경우 최소 컴퓨팅 수준 설정하기
• 서버리스 또는 에지 환경에서 동시 연결을 관리하기 위해 연결 풀러 구성하기
• 데이터 손실을 방지하기 위해 백업 및 특정 시점 복구 활성화하기
• 확장 및 제한 시간 설정이 예상 트래픽 패턴과 일치하는지 검토하기

서버리스 Postgres는 분석 및 데이터 엔지니어링을 위해 Databricks SQL과 같은 서버리스 컴퓨팅 플랫폼과 함께 사용할 수 있습니다. 이러한 분리를 통해 분석 쿼리는 동일한 기본 데이터에서 작동하면서도 트랜잭션 처리와 독립적으로 실행될 수 있습니다.

운영 데이터와 분석을 함께 관리하는 팀의 경우, Databricks Lakebase와 같은 새로운 아키텍처는 공유 데이터 플랫폼에서 트랜잭션 및 분석 워크로드를 통합함으로써 이러한 접근 방식을 확장합니다. 이를 통해 데이터 이동을 줄이고 시스템 간 데이터 액세스 방식을 단순화합니다.

레이크베이스 아키텍처가 귀하에게 적합한 서버리스 Postgres일까요?

서버리스 Postgres는 인프라 관리의 상당 부분을 제거하고 비용을 실제 사용량에 더 밀접하게 맞춤으로써 데이터베이스 운영을 단순화합니다. 컴퓨팅과 스토리지가 분리되어 있으므로 리소스가 수요에 따라 조정됩니다. 더 까다로운 워크로드를 처리해야 하는 팀의 경우, 레이크베이스 아키텍처는 이러한 기반을 더욱 확장합니다.

이러한 트레이드오프는 신중하게 평가하는 것이 중요합니다. 성능 예측 가능성, 대규모 환경에서의 비용, 콜드 스타트 지연 시간 및 연결 관리와 같은 요소는 워크로드에 따라 다릅니다.

제공업체 선택은 매우 중요합니다. 콜드 스타트 동작, 가격 책정 모델, 확장 세분성 및 생태계 적합성의 차이는 결과에 큰 영향을 미칠 수 있습니다. 분석 및 데이터 엔지니어링 워크로드의 경우, Databricks SQL과 같은 플랫폼은 서버리스 쿼리 실행을 제공합니다. 팀은 Databricks Lakebase 제품 투어를 통해 이 모델이 운영 워크로드로 어떻게 확장되는지 살펴볼 수도 있습니다.

데이터베이스 아키텍처가 계속 진화함에 따라, 레이크베이스 아키텍처는 공유된 데이터 기반 위에서 운영 및 분석 워크로드를 통합합니다.

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