동적 PostgreSQL을 만나보세요: 클라우드 데이터베이스의 자연스러운 진화

오늘부터, Timescale에서 동적 PostgreSQL 데이터베이스를 생성할 수 있습니다. .

Dynamic PostgreSQL 은 클라우드 데이터베이스의 자연스러운 진화로, 프로비저닝된 데이터베이스와 서버리스 데이터베이스 모두의 문제를 해결합니다. 이는 로드에 따라 사전 정의된 최소/최대 범위 내에서 사용 가능한 컴퓨팅을 즉시 확장하는 Timescale 혁신인 동적 컴퓨팅으로 뒷받침됩니다. 최대 용량에 대해 프로비저닝하고 항상 비용을 지불하는 대신 이제 컴퓨팅 범위를 선택할 수 있습니다. 데이터베이스는 기본 용량으로 작동하고 필요할 때만 최대 용량까지 즉시 액세스합니다. 기지를 구입하고 최고점을 임대하십시오.

이로 인해 비교할 수 없는 가격 대비 성능이 제공됩니다. 프로덕션 워크로드를 실행하는 고객은 AWS RDS for PostgreSQL에서 마이그레이션할 때 10-20%, AWS Aurora Serverless에서 마이그레이션할 때 50-70%를 절약하게 됩니다.

지금 Dynamic PostgreSQL을 사용해 볼 수 있습니다. 우리는 신용 카드가 필요 없는 무료 평가판을 제공하여 30일 동안 플랫폼에 대한 전체 액세스 권한을 제공합니다.

동적 PostgreSQL 서비스를 생성하려면 Timescale에 로그인할 때 PostgreSQL 옵션을 선택하기만 하면 됩니다.

귀하의 애플리케이션은 항상 켜져 있는데 데이터베이스가 켜져 있으면 안되는 이유는 무엇입니까?

미래에 오신 것을 환영합니다.

문제 1: 개발자가 필요한 것보다 훨씬 더 많은 컴퓨팅을 프로비저닝합니다.

지난 몇 년 동안 Timescale을 처음 출시한 이후로 우리는 개발자가 데이터베이스를 사용하는 방법을 가장 먼저 살펴보았습니다. 예를 들어, 지난 몇 달 동안, 우리는 1조 개가 넘는 쿼리를 분석했습니다. Insights 제품의 일부로.

우리가 배운 한 가지는 개발자가 실제로 필요한 것보다 훨씬 더 많은 컴퓨팅을 프로비저닝하는 경우가 많다는 것입니다.

한편으로는 이것이 의미가 있습니다. 데이터베이스에 대해 걱정하고 싶지 않습니다. 대부분의 데이터베이스 워크로드는 연속적이며 일반적으로 약간의 변동성 또는 폭증이 있습니다. 예를 들어 밤에 사용량이 많은 게임, 낮에 사용량이 많은 비즈니스 애플리케이션, 주중보다 주말에 사용량이 많은 Connected Home 장치 등이 있습니다.

데이터베이스의 리소스가 부족해지는 것을 결코 원하지 않습니다. 데이터베이스가 최대 용량에 도달하면 끔찍한 고객 경험이 발생합니다(또는 고객 경험이 전혀 발생하지 않습니다!). 따라서 대부분의 개발자는 결국 피크와 버퍼에 대한 프로비저닝을 완료합니다. 이로 인해 개발자는 실제로 필요한 것보다 훨씬 더 많은 컴퓨팅 비용을 지불하게 됩니다.

반면에 이것은 우리에게 미친 것처럼 보입니다. 조직이 필요한 것보다 훨씬 더 많은 비용을 지출해도 괜찮은 다른 비즈니스 리소스는 무엇입니까? 낭비된 계산은 낭비된 돈과 같습니다.

문제 2: 서버리스 데이터베이스는 프로덕션 워크로드에 비해 부족합니다.

“서버리스 데이터베이스는 어떻습니까?”라고 묻는 분들도 계실 것입니다.

서버리스 개념은 상태 비저장 워크로드에서 유래되었습니다. 사용자가 하드웨어에 대해 걱정할 필요가 없는 클라우드에서 가상 머신이 성공한 후, 사용자는 애플리케이션 서버 실행에 대해 전혀 걱정할 필요가 없는 이유를 물었습니다. 결국 많은 사용자는 단지 기능을 실행하고 해당 기능이 실행된 시간에 대해서만 비용이 청구되기를 원했습니다. 또한 Stateless이기 때문에 필요에 따라 기능을 쉽고 원활하게 가동할 수 있습니다. 서버리스와 FaaS(Function-as-a-Service)가 AWS Lambda를 대신해 히트를 쳤습니다.

그런 다음 개발자들은 "내가 사용하지 않는 데이터베이스에 대해 왜 비용을 지불하는가?"라고 자문했습니다. 실제 질문은 좋습니다. 낭비되는 리소스는 대규모 데이터베이스 문제입니다. 그리고 특정 서버 인스턴스(예: db.m6gd.2xlarge)에 AWS RDS 데이터베이스를 프로비저닝하는 방식은 고정 CPU, 고정 메모리, 고정 로컬 디스크 등 현대적이거나 유연하다고 느껴지지 않습니다. 대부분의 경우 활용도가 낮습니다.

하지만 여기서 상황이 까다로워집니다. 데이터베이스는 Lambda 함수와 매우 다릅니다.

오늘날 서버리스 데이터베이스는 다음 두 가지 주요 이유로 인해 대부분의 프로덕션 워크로드에 적합하지 않습니다.

• 서버리스 데이터베이스는 0까지 확장 및 축소하는 극단적인 방법에 중점을 둡니다.

• 서버리스 데이터베이스는 변화하는 수요를 충족하기 위해 예약된 리소스 "헤드룸"을 설명하기 위해 훨씬 더 높은 가격을 도입합니다. 더 나쁜 것은 종종 이해하거나 예측하기 어려운 가격 모델을 사용하는 경우입니다.

  
  

'scale to zero'라는 뜨거운 주제에 대해 논의하는 것부터 시작하겠습니다. 현실은 대부분의 프로덕션 데이터베이스가 필요하지 않으며 실제로 0으로 확장해도 이점을 얻지 못한다는 것입니다.

이제 "0으로 확장"이 적합한 몇 가지 사용 사례가 있습니다. 예를 들어 개념 증명 데모 또는 취미용 응용 프로그램 등이 있습니다. 데이터 세트에 대해 임시 쿼리를 실행하는 기능(AWS Athena 및 Google BigQuery는 매우 간헐적으로 사용되는 저비용 서버리스 클라우드 데이터 웨어하우스에 대한 강력한 사례를 제시합니다). 또 다른 적합한 사용 사례는 완료된 후 클라우드 개발 인스턴스를 스핀다운하는 것을 잊지 않는 것입니다. 비프로덕션 데이터베이스를 "자동 일시 중지"하는 데는 가치가 있습니다(서버리스에서 예상하는 것보다 훨씬 간단한 기능이 필요하지만).

그러나 프로덕션 데이터베이스와 더 많은 운영 설정의 경우? 0으로 확장하고 싶지 않습니다.

0으로 확장한다는 것은 재시작 시 "콜드 부팅"을 의미합니다. 즉, 빈 데이터베이스 공유 버퍼, 빈 OS 캐시, 빈 카탈로그 캐시(PostgreSQL의 경우)입니다.

(예, 일부 서버리스 데이터베이스는 데이터베이스 실행을 시작하는 데 걸리는 시간을 낮추지만 빈 상태에서 그렇게 합니다. PostgreSQL과 같은 관계형 데이터베이스에서는 웜 작업 세트를 다시 구축하는 데 몇 분(또는 그 이상)이 걸릴 수 있습니다. 특히 대규모 데이터베이스의 경우.)

많은 서버리스 데이터베이스가 다양한 클라우드 스토리지 아키텍처를 채택하므로 콜드 스타트 성능 저하가 더욱 커집니다. 여기서 데이터베이스 페이지를 원격 스토리지에서 메모리로 가져오는 데 드는 비용과 대기 시간이 훨씬 더 큽니다. 이러한 오버헤드는 다시 성능 저하로 이어지거나 플랫폼 공급자가 더 큰 물리적 리소스를 사용하여 보상하도록 강요합니다(예: Amazon Aurora 데이터베이스는 RDS 메모리의 두 배를 가짐). 이 비용은 궁극적으로 사용자에게 전가됩니다.

따라서 많은 시나리오에서 서버리스 데이터베이스의 가격은 더 높고 예측할 수 없게 됩니다.

예를 들어 Aurora Serverless를 Amazon RDS와 비교하면 Serverless의 8 vCPU 컴퓨팅과 500GB 스토리지가 RDS보다 85% 더 비싸다는 것을 알 수 있습니다($1,097 대 $593). 그리고 이것은 불과 6개월 전에 출시된 Aurora I/O Optimized와 보다 예측 가능한 스토리지 가격을 사용하고 있습니다. (여기에서도 Aurora 서버리스 가격은 불투명한 "Aurora 용량 단위"를 혼동하여 가격을 책정하므로 실제 컴퓨팅 용량을 추론해야 합니다. 가장 잘 알려진 추정치는 1 ACU = 0.25 vCPU입니다.)

이전에는 Aurora Standard를 사용하면 사용자가 각 내부 I/O 작업에 대해서도 비용을 지불해야 했는데, 이는 예측이나 예산 책정이 거의 불가능했습니다. 많은 서버리스 데이터베이스에서는 이러한 읽기 및 쓰기에 대해 계속 요금을 부과합니다. 실제로 서버리스 AWS Timestream을 벤치마킹했을 때 우리는 비용이 100배 이상 증가했습니다. 이러한 더 높은 한계 비용으로 인해 Timescale보다. 비용의 예측 불가능성과 가변성은 걱정 없음의 반대였습니다.

즉, 서버리스 데이터베이스는 워크로드 확장에 따라 성능이 저하되고, 청구서를 예측할 수 없으며, 비용이 높아지는 경향이 있습니다. 가끔씩만 실행되고 인메모리 데이터 캐싱이 부족하여 콜드 스타트를 허용할 수 있는 간헐적인 워크로드에만 적합합니다.

개발자의 딜레마

이것이 우리가 끝난 곳입니다:

• 많은 개발자는 안정적인 성능, 제어 및 이해 가능성으로 인해 여전히 프로덕션 애플리케이션을 위한 프로비저닝이 포함된 기존 DBaaS 서비스를 선택하지만 과잉 프로비저닝의 필요성으로 인해 발생하는 낭비를 싫어합니다.

  
  

• 일부 개발자는 비용 절감, 유연성 및 사용 편의성을 위해 서버리스 데이터베이스를 선택하지만 성능 저하와 예측할 수 없는 모호한 가격(프로비저닝된 인스턴스보다 청구서가 이상할 정도로 높음)을 싫어합니다.

  
  

개발자로서 이러한 옵션 중 어느 것도 그다지 매력적이지 않습니다! 더 나은 기회가 있습니다.

솔루션: 동적 PostgreSQL 소개

이것이 우리가 Dynamic PostgreSQL을 개발한 이유입니다.

동적 PostgreSQL은 지속적으로 기준선을 지원하고 필요할 때 정의된 최대값까지 컴퓨팅을 원활하게 확장합니다. 이는 프로덕션 설정에서 일반적으로 볼 수 있는 광범위한 연속 워크로드(균일, 가변 또는 폭주 등)에 적합합니다.

Dynamic PostgreSQL은 100% PostgreSQL이며, PostgreSQL 커뮤니티와 생태계의 모든 이점과 더불어 Timescale 데이터베이스 플랫폼의 성숙도 . Dynamic PostgreSQL을 구축하기 위해 우리는 PostgreSQL의 내부를 수정하는 대신 PostgreSQL 인프라를 운영하는 방법을 혁신했습니다. 이를 통해 포크된 PostgreSQL 쿼리 또는 스토리지 엔진에서 실행될 염려 없이 PostgreSQL과 Timescale 플랫폼이 제공하는 모든 것에 액세스할 수 있습니다.

Dynamic PostgreSQL을 사용하면 워크로드 요구 사항에 맞는 컴퓨팅 범위 (최소 및 최대 CPU)를 선택할 수 있습니다. 또한 이 컴퓨팅 범위에는 대부분의 DBaaS 서비스가 컴퓨팅 범위의 "최대" 끝에서 전통적으로 제공하는 것과 동일한 유효 메모리가 함께 제공됩니다.

CPU 범위의 기본(최소)은 프로비저닝된 DBaaS 모델과 동일하게 작동합니다. 즉, 최소 CPU는 항상 애플리케이션을 실행하는 서비스 전용입니다. 외부 애플리케이션의 수요로 인해 또는 증분 백업이나 테이블 자동 비우기와 같은 간헐적인 내부 데이터베이스 작업으로 인해 로드가 증가하면 데이터베이스는 지연 없이 CPU 범위의 최대치(최대)까지 사용할 수 있습니다.

지연 제로를 달성하려면 어떻게 해야 합니까? 동적 컴퓨팅은 다른 서버리스 또는 자동 확장 데이터베이스 제품과 다르게 작동하므로 일반적으로 원격 마이그레이션에서 볼 수 있는 느린 확장(및 성능 저하)이 발생하지 않습니다. 대신, 우리의 인프라 구성 및 워크로드 배치 알고리즘은 데이터베이스를 다시 시작하거나 재구성하지 않고도 기본 노드에서 확장할 수 있도록 보장합니다. 인스턴스는 필요에 따라 항상 최대 컴퓨팅에 액세스할 수 있습니다.

그리고 가장 좋은 점은 기본 요금과 그 이상으로 사용한 요금만 지불한다는 것입니다. 우리는 컴퓨팅 범위를 선택하고 그 사이에서 확장하는 이 모델을 " 기본을 구입하고 최고점을 임대 "라고 부릅니다.

예를 들어, 4~8 CPU 옵션을 선택하면 항상 서비스 전용 CPU 4개와 유효 메모리 32GB를 갖게 됩니다. 이는 항상 좋은 기본 성능을 보장합니다. 로드가 증가하면 애플리케이션은 필요에 따라 즉시 최대 8개의 CPU를 사용할 수 있으며(부분 CPU 기준으로 측정 및 청구) 최대 한도인 경우 8개를 초과할 수 없습니다.

동적 모델을 사용하면 보다 비용 효율적이고 걱정 없이 데이터베이스를 "크기 조정"할 수 있습니다. 표준 수요가 최소값에 맞는 컴퓨팅 범위를 선택할 수 있지만 필요에 따라 최대값(최대값)까지 확장하거나 급증할 수 있습니다. 이 최대값은 기본 컴퓨팅을 초과하는 모든 사용량에 대해 고유한 한도를 생성하여 이해하기 쉬운 비용 상한선으로 이어집니다. 또한 기본 사용량과 이에 대한 측정 사용량 모두에 대해 (부분) CPU 시간당 동일한 요금을 청구합니다. 기본 사용량 이상을 사용하는 경우 추가 요금이 부과되지 않으므로 확장 시 가격 패널티가 없습니다.

마지막으로, 너무 낮거나 너무 높은 크기 범위를 프로비저닝한 경우 애플리케이션 요구 사항에 더 적합한 크기로 컴퓨팅 범위를 쉽게 조정할 수 있습니다.

비용 절감을 위한 설계

현재 우리는 워크로드 크기에 따라 5가지 컴퓨팅 범위를 제공하며, 순간 사용량에 관계없이 해당 범위에 대해 해당 유효 메모리를 받게 됩니다.

Dynamic PostgreSQL은 또한 프로비저닝된 디스크 크기가 아닌 저장된 데이터 볼륨(GB-시간)에 대해서만 비용을 지불하는 Timescale의 사용량 기반 스토리지를 사용합니다. 과도하게 프로비저닝된 디스크로 인한 비용 낭비나 디스크 공간 부족에 대해 걱정할 필요가 없습니다. Timescale의 동적 클라우드 인프라는 필요할 때 충분한 스토리지 용량을 확보하고 사용한 만큼만 비용을 지불하도록 보장합니다.

우리는 귀하의 비용을 절약하기 위해 의도적으로 Dynamic PostgreSQL을 개발했습니다. 프로덕션 워크로드를 실행하는 고객은 일반적으로 PostgreSQL용 AWS RDS에서 마이그레이션할 때 10~20%를 절약하고, AWS Aurora Serverless에서 마이그레이션할 때 50~70%를 절약합니다.

월말 청구서는 간단하고 이해하기 쉬운 두 가지 지표로 구성됩니다. (1) 컴퓨팅 비용은 시간당 기본 컴퓨팅에 그 이상의 CPU 사용량을 더한 금액으로 청구되지만 최대 사용량을 초과하지 않습니다. (2) 데이터 소비량(GB-시간)으로 청구되는 스토리지 비용. 측정하거나 이해해야 할 새로운 측정항목이나 파생 단위가 없습니다.

사용한 만큼만 비용을 지불하면 됩니다. 추가 비용이나 숨겨진 수수료가 없습니다.

• 컴퓨팅: 정의된 범위를 기반으로 예측 가능

• 스토리지: 저장한 만큼만 비용 지불

  
  

낭비되는 자원이 없습니다. 초과 지불이 없습니다. 밤에 잠을 잃지 않습니다. 상사에게 설명할 수 있는 청구서.

오늘 사용해 보세요

오늘 Dynamic PostgreSQL을 사용해 볼 수 있습니다! Timescale은 무료 평가판을 제공합니다 —신용카드가 필요하지 않습니다. —30일 동안 플랫폼에 대한 전체 액세스 권한을 제공합니다. 동적 PostgreSQL 서비스를 생성하려면 Timescale에 로그인할 때 PostgreSQL 옵션을 선택하기만 하면 됩니다.

이제 플랫폼은 데이터베이스의 특정 요구 사항을 충족하기 위해 두 가지 서비스 유형을 제공합니다.

• 시계열 서비스는 가장 까다로운 워크로드에 대한 쿼리 속도와 확장성을 향상하도록 설계되었으며 하이퍼테이블, 열 형식 압축, 연속 집계, 계층형 스토리지와 같은 주요 시간 척도 기능을 제공합니다. 센서 데이터, 에너지 지표, 재무 데이터, 이벤트 및 기타 데이터 집약적인 워크로드를 호스팅하는 데 사용하세요.

  
  

• PostgreSQL 서비스는 비용 효율성과 사용 편의성을 위해 최적화된 동적 Postgres 서비스입니다. 비즈니스 기록과 같은 관계형 전용 데이터베이스에 사용하세요.

  
  

“PostgreSQL”을 선택하면 Dynamic PostgreSQL 서비스 구성이 매우 간단해집니다. 지역, 동적 컴퓨팅 범위, 고가용성 및 연결 풀링 옵션을 선택하세요. 붐! 🔥 이제 프로덕션에서 사용할 수 있는 동적 PostgreSQL 데이터베이스가 준비되었습니다.

만약 질문이 있다면, 우리에게 연락해 . 우리는 여러분의 피드백을 듣고 PostgreSQL 사용 사례(시계열 여부)에 도움을 주고 싶습니다!

이것은 시작에 불과합니다. 3주 연속 출시 주간을 맞이하고 있으며, 이는 2주차: Dynamic Infra Week의 시작일 뿐입니다. 이번 주, 이번 달, 올해, 그리고 앞으로의 몇 년 동안 더 많은 소식을 기대해 주세요. 🙂

- Mike Freedman과 Grant Godeke가 작성했습니다.