운영 성능을 위한 Azure Database for PostgreSQL 배포 계획

클라우드 컴퓨팅은 데이터베이스 호스팅 환경을 크게 변경했습니다. 팀에게 이전에는 달성할 수 없었던 확장성, 복원력, 글로벌 도달률 및 기능에 액세스할 수 있습니다. 가능한 가장 큰 워크로드(및 첫날부터 해당 비용 수행)를 계획하여 상당한 비용과 오버헤드를 발생시키는 대신, 이제 팀은 필요할 때 필요한 정확한 규모를 최적화하고 요구 사항이 변경되면 조정할 수 있습니다.

Introduction

리소스의 적절한 균형을 선택할 수 있는 유연성은 PostgreSQL 데이터베이스 배포에 특히 유용합니다. PostgreSQL 데이터베이스 워크로드는 작게 시작되거나, 빠르게 증가하거나, 계절에 따라 급증하거나, 읽기가 많은 작업에서 쓰기가 많은 작업으로 전환하거나, 트랜잭션 워크로드에서 하이브리드 운영 및 분석 시스템으로 실시간으로 발전할 수 있습니다. Azure Database for PostgreSQL 컴퓨팅, 스토리지, 가용성, 복제, 보안, 백업 및 운영 관리 전반에 걸쳐 광범위한 옵션을 제공하여 솔루션이 대상에 도달하도록 보장합니다.

그러나 이 모든 기능을 사용하면 특히 배포를 계획할 때 책임이 있습니다. 최상의 성능을 달성하려면 배포 결정이 전체 워크로드의 요구 사항과 일치해야 합니다.

성공적인 Azure Database for PostgreSQL 배포는 "필요한 가장 많은 코어와 메모리"를 선택하는 문제가 아닙니다. 대신 최대 운영 성능은 애플리케이션의 동작, 클라이언트의 동작, 컴퓨팅, 스토리지 및 데이터베이스 증가 특성 및 이러한 모든 것이 상호 작용하고 상호 작용하는 방식을 이해하는 데서 비롯됩니다.

가장 좋은 아키텍처는 이러한 조각이 의도적으로 정렬되는 아키텍처입니다.

클라우드 성능 계획은 공동의 책임입니다.

신뢰할 수 있는 클라우드 플랫폼으로 전환할 때의 주요 이점 중 하나는 공유 책임 모델입니다. Microsoft 글로벌 인프라, 관리되는 서비스, 하드웨어 혁신, 안정성, 보안 및 운영 엔지니어링을 제공합니다. 팀은 비즈니스 중요도, 워크로드 동작, 데이터 모델 디자인, 네트워크 트래픽 프로필, 성장 기대치, 복구 목표 및 최종 사용자 환경 요구 사항과 같은 특정 애플리케이션 컨텍스트 전문 지식을 제공합니다.

가장 강력한 결과는 이 두 세력이 통합될 때 발생합니다.

Azure 확장성이 뛰어난 Postgres 인프라를 제공하지만 팀은 다음 영역에 대한 인사이트를 가져와야 합니다.

• 정상 및 사용량이 많은 기간 동안 예상되는 동시 사용자는 몇 명입니까?
• 가장 중요한 작업은 읽기가 많거나, 쓰기가 많거나, 혼합되어 있습니까?
• 월말, 분기말, 휴일, 출시 또는 보고 기간 동안 수요가 급증하나요?
• 데이터 세트가 얼마나 빠르게 성장하고 있나요?
• 지연 시간에 민감한 작업은 무엇입니까?
• 더 긴 런타임을 허용할 수 있는 쿼리 또는 작업은 무엇인가요?
• 워크로드가 주로 OLTP, OLAP 또는 하이브리드인가요?
• 클라이언트는 데이터베이스 지역 근처에 위치하고, 전역적으로 분산되거나, 하나의 지역에 집중되어 있습니까?

프로덕션 인시던트가 아닌 배포 전에 이러한 세부 정보를 캡처합니다. 클라우드 배포를 사용하면 크기 조정이 더 쉬워지지만 가장 성능이 뛰어나고 비용 효율적인 디자인은 여전히 건전한 요구 사항 수집 및 적절한 계획으로 시작됩니다. 대부분의 경우 이러한 질문은 동시 연결, 최대 IOPS 및 필요한 처리량 간의 관계로 증류될 수 있습니다.

성능에는 여러 계층이 있습니다.

데이터베이스 성능은 단일 설정에 의해 거의 결정되지 않습니다. 성공적인 배포 환경은 함께 작동하는 여러 계층에 따라 달라집니다.

• 애플리케이션 계층 성능.
  이 계층에는 애플리케이션 코드, 쿼리 패턴, 인덱스 검사, 트리거 사용, 데이터 분할, 연결 처리, 캐싱, 재시도 논리, 풀링, ORM 동작, 트랜잭션 디자인 및 백그라운드 작업 동작이 포함됩니다.
• 클라이언트 및 네트워크 계층 성능.
  이 계층에는 클라이언트가 있는 위치, 연결 방법, 요청이 지역 간 및 가용성 영역, 네트워크 대기 시간, TLS 오버헤드, 연결 변동 여부 및 애플리케이션에서 연결 풀링을 효율적으로 사용하는지 여부가 포함됩니다.
• 데이터베이스 플랫폼 성능.
  이 계층에는 Postgres 배포 구성, 컴퓨팅 크기, 메모리, CPU, 스토리지 유형, 스토리지 크기, 스토리지 IOPS, 스토리지 처리량, 고가용성, 복제본 및 유지 관리 작업이 포함됩니다.

이 문서에서는 주로 세 번째 계층, 즉 컴퓨팅 및 스토리지 선택 항목이 필요한 성능 프로필을 지원할 수 있도록 Azure Postgres 데이터베이스 배포를 계획하는 데 중점을 둡니다.

Azure Database for PostgreSQL 유연성을 제공하지만 계획은 필수적입니다.

Azure Database for PostgreSQL 유연한 서버는 다음을 비롯한 다양한 배포 옵션을 제공합니다.

이러한 유연성은 워크로드에 다른 기능이 필요하기 때문에 강력합니다. 쓰기가 많은 트랜잭션 시스템은 보고가 많은 시스템과 동일한 프로필을 필요로 하지 않습니다. 전역 SaaS 애플리케이션은 내부 지역 애플리케이션과 동일한 디자인이 필요하지 않습니다. 연간 5% 증가하는 데이터베이스에는 월별 200개% 증가하는 스토리지 계획과 동일한 스토리지 계획이 필요하지 않습니다.

계획 목표는 워크로드 성능 프로필 요구 사항을 파악한 다음 컴퓨팅 및 스토리지 옵션 모두에서 적절한 선택을 구현하여 엔드 투 엔드 솔루션을 성공적으로 제공하는 것입니다.

워크로드 프로필을 시작하십시오.

컴퓨팅 또는 스토리지를 선택하기 전에 워크로드를 정의합니다. 유용한 계획 차원은 다음과 같습니다.

목표는 미래를 완벽하게 예측하는 것이 아닙니다. 목표는 맹목적으로 설계하지 않는 것입니다.

세 가지 핵심 스토리지 성능 개념 이해

Azure 스토리지 성능 계획은 일반적으로 IOPS, 처리량 및 대기 시간의 세 가지 관련되지만 고유한 개념으로 제공됩니다. 이러한 요소는 애플리케이션 성능 계획의 핵심입니다.

IOPS

IOPS 는 초당 입력/출력 작업을 의미합니다. 데이터베이스가 스토리지에 초당 보낼 수 있는 읽기 또는 쓰기 작업 수를 측정합니다.

IOPS는 OLTP 워크로드에 특히 중요합니다. 이러한 시스템은 종종 삽입, 업데이트, 인덱스 조회, 지점 읽기 및 짧은 트랜잭션과 같은 많은 작은 임의 읽기 및 쓰기를 수행합니다. 수천 명의 동시 사용자가 있는 트랜잭션 워크로드는 각 개별 작업이 작더라도 높은 IOPS가 필요할 수 있습니다.

일반적인 IOPS 관련 시나리오는 다음과 같습니다.

• 대량 주문 처리
• 사용자 프로필 업데이트
• 인벤토리 시스템
• 이벤트 수집
• 결제 또는 청구 시스템
• 고도로 동시 실행 SaaS 애플리케이션

처리량

대역폭이라고도 하는 처리량은 시간이 지남에 따라 스토리지에서 읽거나 스토리지에 쓸 수 있는 데이터의 양을 측정합니다. MB/s로 표현됩니다.

처리량은 작업에서 많은 양의 데이터를 이동할 때 중요합니다. 분석 쿼리, 백업, 복원, 일괄 처리 작업, 인덱스 빌드, 테이블 검색 및 ETL 워크플로는 가장 높은 IOPS가 필요하지 않더라도 높은 처리량이 필요할 수 있습니다.

일반적인 처리량 중요한 시나리오는 다음과 같습니다.

• 큰 테이블에 대한 쿼리 보고서 작성
• 대량 가져오기 또는 내보내기
• 데이터 웨어하우스 방식 스캔
• 백업 및 복원 작업
• 대규모 인덱스 만들기 또는 다시 작성 작업
• 일괄 처리

Latency

대기 시간은 단일 I/O 요청을 완료하는 데 걸리는 시간입니다. 짧은 대기 시간은 특히 트랜잭션에서 많은 작은 작업이 함께 연결된 사용자 연결 데이터베이스 작업에 필수적입니다.

시스템은 이론적 IOPS가 높을 수 있지만 대기 시간이 높으면 속도가 느려집니다. Postgres 워크로드의 경우 스토리지 대기 시간은 쿼리 응답 시간, 트랜잭션 커밋 동작, 검사점 동작 및 전반적인 애플리케이션 응답성에 직접적인 영향을 줄 수 있습니다.

IOPS, 처리량 및 대기 시간을 함께 고려해야 합니다.

IOPS 및 처리량이 연결됩니다. 몇 가지 작은 8KiB 작업을 실행하는 워크로드는 높은 처리량 없이 높은 IOPS를 구동할 수 있습니다. 대규모 다중 MB 작업을 실행하는 워크로드는 낮은 IOPS로 높은 처리량을 유도할 수 있습니다.

그것에 대해 생각하는 간단한 방법은 다음과 같습니다.

IOPS x I/O 크기 = 처리량

Postgres의 경우 워크로드 스토리지 계획은 데이터베이스 크기만 사용하는 것이 아니라 관찰되거나 예상된 워크로드 동작을 기반으로 해야 한다는 것입니다. 다음은 그 예입니다.

• 동시성이 높은 OLTP 시스템에는 더 많은 IOPS와 더 낮은 대기 시간이 필요할 수 있습니다.
• 보고가 많은 시스템에는 더 많은 처리량이 필요할 수 있습니다.
• 하이브리드 시스템은 특히 피크 주기 동안 둘 다 필요할 수 있습니다.
• 동시성이 높은 OLTP 시스템에는 더 많은 IOPS와 더 낮은 대기 시간이 필요할 수 있습니다.
• 보고가 많은 시스템에는 더 많은 처리량이 필요할 수 있습니다.
• 하이브리드 시스템은 특히 피크 주기 동안 둘 다 필요할 수 있습니다.

배포 선택은 스토리지 성능에 직접적인 영향을 줍니다.

일반적인 실수는 선택한 컴퓨팅 SKU가 동일한 성능 수준을 구동할 수 있는지 여부를 완전히 고려하지 않고 대상 성능 번호에 대한 스토리지를 설정하는 것입니다.

Azure 스토리지 성능에는 여러 가지 고려 사항이 있습니다. 세부 정보에는 다음이 포함됩니다.

• 컴퓨팅 기능 집합(최대 컴퓨팅 IOPS 및 처리량 제한)입니다.
• 스토리지 생성(SSD v1, SSD v2, Ultra Disk).
• 스토리지 디스크 크기(4,096GB 미만의 SSD v1 디스크에는 표준 기준 이상으로 IOPS 버스트를 허용하는 호스트 캐싱이 포함됨).
• 스토리지 IOPS 용량입니다.
• 스토리지 처리량 능력입니다.

실질적으로: 효과적인 성능 한도는 체인에서 가장 낮은 관련 한도입니다.

스토리지 구성에서 80,000 IOPS를 제공할 수 있지만 컴퓨팅 SKU가 20,000 IOPS만 구동할 수 있는 경우 배포는 80,000 IOPS를 제공하지 않습니다. 반대로 VM 생성에서 높은 IOPS를 지원하지만 선택한 스토리지 계층이 더 낮게 제한되면 스토리지 계층이 제한됩니다.

컴퓨팅 및 스토리지 계획은 함께 수행되어야 합니다.

프리미엄 SSD v1: 중요한 캐싱 동작을 사용하는 강력한 기준 성능

프리미엄 SSD v1은 예측 가능하고 프로비저닝된 성능이 필요한 프로덕션 Azure Postgres 워크로드에 대한 일반적인 선택입니다. Azure Postgres SSD v1 스토리지는 최대 32TB 공간, 20,000 IOPS 및 900MB/s 처리량을 지원합니다.

프리미엄 SSD v1은 호스트 캐싱을 활용하는 워크로드에 적합합니다. Azure Postgres는 SSD v1 디스크 크기가 4,096GB 미만일 때 호스트 캐싱을 지원합니다. 최대 4,095GB까지 프로비전된 모든 디스크는 호스트 캐싱을 활용할 수 있습니다. 스토리지가 4,096GB 이상으로 프로비전되면 호스트 캐싱이 지원되지 않습니다. 그 경계는 중요합니다. 4TB 미만의 프리미엄 SSD v1 배포의 경우 캐싱은 읽기 성능을 향상시키고 읽기 대기 시간을 줄일 수 있습니다. 캐싱 임계값 이내로 들어맞는 읽기 집중 또는 혼합 워크로드에 대한 뛰어난 비용 대 성능 효율성을 이 캐싱은 제공합니다.

4TB 경계가 중요한 이유

프리미엄 SSD v1 배포가 캐싱 지원 범위를 벗어나면 성능 프로필이 변경될 수 있습니다.

• 읽기는 더 이상 호스트 캐시의 이점을 누릴 수 없습니다.
• 더 많은 읽기 작업은 기본 디스크에서 직접 제공됩니다.
• 읽기는 디스크 IOPS 및 처리량 제한에 영향을 미칩니다.
• 대기 시간에 민감한 읽기 워크로드는 다른 동작을 볼 수 있습니다.
• 이전에 효율적이었던 구성에는 프로비전된 IOPS, 더 많은 처리량, 컴퓨팅 크기 조정, 쿼리 튜닝 또는 다른 스토리지 옵션이 필요할 수 있습니다.

4TB를 초과하는 것은 나쁘지 않지만 계획 해야 합니다.

데이터베이스가 4TB를 초과할 것으로 예상하는 경우 아키텍처 디자인 중에 향후 상태를 고려합니다. 캐싱을 사용하여 2TB에서 잘 작동하는 디자인은 캐싱 없이 5TB에서 다른 성능 계획이 필요할 수 있습니다.

일시적인 용량 증가(버스트)는 용량 급증에 도와주는 역할을 하지만, 지속적인 용량을 대체하지는 않습니다.

Azure 4TB 미만의 Postgres Premium SSD v1 스토리지 할당은 다음과 같은 시나리오에서 도움이 될 수 있는 호스트 캐싱의 버스트를 지원합니다.

• 시작 작업
• 짧은 일괄 처리 작업
• 트래픽 급증
• 월말 처리
• 임시 워크로드 급증

버스팅은 유용하지만 신중하게 사용하세요. 버스팅은 일시적인 급증을 흡수할 수 있지만 지속적인 워크로드 수요의 기초가 되어서는 안 됩니다. 워크로드가 기준 이상으로 자주 실행되는 경우 더 높은 성능 계층을 프로비전하거나, 스토리지 성능 설정을 조정하거나, 컴퓨팅 크기를 조정하거나, 워크로드 패턴을 다시 디자인하는 것이 좋습니다.

좋은 계획 질문은 다음과 같습니다: 이것이 일시적 증가 현상입니까, 아니면 새로운 표준입니까?

일시적인 급증은 버스팅에 적합한 후보일 수 있습니다. 의도적인 용량 계획으로 지속적인 수요를 처리합니다.

프리미엄 SSD v2는 용량, IOPS 및 처리량을 분리합니다.

프리미엄 SSD v2는 디스크 크기, IOPS 및 처리량을 분리하여 계획 모델을 변경합니다. Azure Database for PostgreSQL 유연한 서버 Premium SSD v2는 다음을 지원합니다.

• 32GB에서 64TB까지의 용량.
• 최대 80,000 IOPS.
• 최대 1,200MB/s 처리량입니다.
• 1GB 단위로 세분화된 용량 조정
• 유연한 IOPS 및 처리량 구성.
• 프리미엄 SSD v1보다 대기 시간이 짧습니다.
• 호스트 캐싱이 없습니다.

이러한 변화는 큰 변화입니다. 프리미엄 SSD v1을 사용하면 성능이 디스크 크기에 더 밀접하게 결합됩니다. 프리미엄 SSD v2를 사용하면 워크로드 필요를 중심으로 성능을 보다 직접적으로 구성할 수 있습니다.

예를 들어 트랜잭션이 많은 데이터베이스는 많은 양의 스토리지를 필요로 하지 않고도 높은 IOPS가 필요할 수 있습니다. Azure Postgres는 추가 비용 없이 기준 IOPS 및 처리량을 제공하며 추가 요금에 사용할 수 있는 추가 IOPS 및 처리량을 제공합니다. 프리미엄 SSD v2 제품은 다음과 같습니다.

• 최대 399GB의 디스크는 3,000 IOPS 및 125MB/s의 기준을 받습니다.
• 400GB 이상의 디스크는 12,000 IOPS 및 500MB/s의 기준을 받습니다.
• 최소 160GB의 사용 가능한 공간으로 크기를 조정하면 디스크가 최대 80,000 IOPS 에 도달할 수 있습니다.
• 처리량은 최대 1,200MB/s까지 확장할 수 있습니다.

프리미엄 SSD v2는 비용 및 성능에 대한 보다 정확한 제어가 필요할 때 종종 매력적입니다. 성능을 잠금 해제하기 위해 스토리지 용량을 확장하는 대신 성능을 더 의도적으로 프로비전할 수 있습니다.

Ultra Disk(미리 보기): 고급 Azure 디스크 성능 클래스

Ultra Disk는 최고 성능 디스크 옵션입니다. Azure Ultra Disk는 다음과 같은 성능 수준을 제공합니다.

• 400,000 IOPS
• 10,000MB/s 처리량
• 64TB 용량
• 밀리초 이하 지연 시간 설계 목표
• 독립적으로 구성 가능한 용량, IOPS 및 처리량

Ultra Disk Storage는 최상위 계층 데이터베이스, SAP HANA 및 트랜잭션이 많은 시스템에 대한 IO 집약적 워크로드에 전력을 공급하도록 설계되었습니다. 이 새로운 스토리지 제품은 중요 업무용 워크로드에 대한 최고 수준의 성능을 제공합니다. 그러나 팀은 배포를 계획할 때 몇 가지 주요 배포 기능, 지역 가용성 제한 및 구성 옵션을 고려해야 합니다.

• Ultra Disk를 사용하는 서버에는 스토리지 자동 증가가 지원되지 않습니다.
• Ultra Disk가 있는 서버에는 고객 관리형 키를 사용한 데이터 암호화가 지원되지 않습니다.
• Ultra Disks는 디스크 캐싱을 지원하지 않습니다.

광범위한 Azure 스토리지 성능 환경의 일부로 Ultra Disk 기능을 이해하는 것이 중요합니다. 그러나 특정 Azure Postgres 워크로드에 대한 서비스 가용성 및 지원의 유효성을 검사해야 합니다. Azure Postgres 배포에 Ultra Disk Preview를 사용할 수 있는지 Microsoft 담당자에게 문의하세요.

실질적인 교훈: Ultra Disk는 Azure 스토리지 성능의 상한을 나타내지만, 엔드투엔드 Postgres 디자인에는 선택한 컴퓨팅 SKU, 지역, 릴리스 수준에 대해 유사한 수준의 지원을 받는 조합이 포함되어야 합니다.

VM 생성 문제: V5 및 V6 컴퓨팅 스토리지 한도는 다릅니다.

컴퓨팅 생성은 스토리지 성능에 실질적으로 영향을 줄 수 있습니다. Azure의 최고 수준 스토리지 성능을 탐색할 때, "대규모 컴퓨팅"이 자동으로 "최대 스토리지"를 의미한다는 오해를 피하십시오. 선택한 컴퓨팅 SKU를 의도한 스토리지 계층에 대해 유효성을 검사해야 합니다. 비슷한 크기의 두 컴퓨팅 세대 Ddsv5와 Ddsv6를 고려하여 이 점을 설명해 보겠습니다.

Ddsv5 시리즈는 VM 제품군 수준에서 Premium Storage(캐싱 사용), 프리미엄 SSD v2 및 Ultra Disk를 지원합니다. 그러나 VM의 집계 원격 스토리지 제한은 여전히 VM이 구동할 수 있는 최대값을 정의합니다. Ddsv5-series는 최대 80,000 IOPS 및 2,600MB/s에 이르는 스토리지 성능을 제공합니다.

-series는 Ddsv6최대 400,000 IOPS 및 12,000 MB/s에 이르는 더 높은 스토리지 기능을 제공합니다. 또한 V6 시리즈 컴퓨팅은 최대 192개의 vCPU 및 768GiB 메모리를 사용하여 이전 세대보다 더 높은 확장성을 제공합니다.

이러한 세대적 변화는 고성능 Postgres 디자인에 중요합니다. 대상 아키텍처에 높은 스토리지 성능이 필요한 경우 집계 스토리지 한도가 낮은 컴퓨팅 생성을 선택하면 배포에서 전체 스토리지 기능을 사용하지 못할 수 있습니다.

예: 엔드 투 엔드 맞춤이 중요한 이유

목표 스토리지가 400,000 IOPS인 PostgreSQL 워크로드를 고려하십시오.

디스크 계층에서 Azure Ultra Disk는 디스크당 최대 400,000 IOPS를 지원합니다. 프리미엄 SSD v2는 디스크당 최대 80,000 IOPS를 지원하며, 집계 디자인이 높을수록 서비스 지원에 따라 여러 디스크 또는 플랫폼 수준 추상화가 필요할 수 있습니다.

하지만 스토리지 기능만으로는 충분하지 않습니다.

V5 시리즈 구성에는 대상보다 낮은 스토리지 한도가 있을 수 있습니다. 앞서 언급했듯이 V5 시리즈 SKU는 프리미엄 SSD 원격 디스크 처리량에 대해 최대 260,000 IOPS를 지원합니다. 이 경우 400,000 IOPS 대상에 도달하기 전에 이 대상에 대한 V5 시리즈 컴퓨팅 계층을 선택하는 것이 제한 요소가 됩니다.

반면 Ddsv6 시리즈 설명서는 최대 400,000 IOPS 및 12,000MB/s를 제공합니다. 따라서 V6 시리즈 및 최신 세대는 가장 높은 스토리지 성능 클래스를 중심으로 컴퓨팅 및 스토리지를 조정해야 하는 디자인에 전략적으로 중요합니다.

단원은 간단합니다. 최대 데이터베이스 성능은 스토리지 전용 속성이 아니라 엔드 투 엔드 속성입니다.

안정적인 상태뿐만 아니라 비즈니스 주기를 고려한 계획을 세우세요.

대부분의 시스템에는 단일 성능 프로필이 없습니다. 다음과 같은 여러 가지가 있습니다.

평균 사용률에 대한 크기의 데이터베이스는 가장 중요한 순간에 어려움을 겪을 수 있습니다. 반대로 한 달에 한 번 피크에 대해 영구적으로 크기가 조정된 데이터베이스는 불필요하게 비용이 많이 들 수 있습니다.

Azure 유연성을 통해 팀은 더 미묘한 선택을 할 수 있습니다. 다음은 그 예입니다.

• 프리미엄 SSD v2를 사용하여 워크로드 요구 사항이 진화함에 따라 IOPS 및 처리량을 조정합니다.
• 읽기 복제본을 사용하여 적절한 경우 읽기 작업이 많은 워크로드를 오프로드합니다.
• 이미 알려진 최대 사용 기간에 맞춰 컴퓨팅 리소스를 조정합니다.
• 인프라 크기를 조정하기 전에 쿼리, 인덱스 및 연결 풀링을 조정합니다.
• 병목 현상이 CPU, 메모리, IOPS, 처리량, 잠금 경합, 연결 압력 또는 쿼리 디자인인지 여부를 식별하려면 관찰 기능을 사용합니다.

최상의 배포가 항상 가장 큰 배포는 아닙니다. 워크로드와 일치하고 안전하게 발전할 수 있는 디자인입니다.

관찰성은 아키텍처의 일부입니다.

배포 시 성능 계획이 중지되어서는 안 됩니다. Postgres 워크로드는 시간이 지남에 따라 변경됩니다. 데이터가 증가하고, 쿼리 패턴이 바뀌고, 새로운 기능이 시작되고, 고객 트래픽이 변경되고, 운영 작업이 누적됩니다.

Azure Database for PostgreSQL 설명서에서는 스토리지 제한, 스토리지 비율, 사용된 스토리지 및 I/O 비율을 포함하여 Azure 포털 또는 Azure CLI 메트릭을 통한 I/O 사용 모니터링을 강조 표시합니다.

이러한 메트릭은 가장 중요한 운영 질문에 대답하는 데 도움이 됩니다. 실제로 성능을 제한하는 계층은 무엇인가요?

관측 가능성이 없으면 팀이 잘못된 부분을 확장할 수 있습니다. 쿼리 계획 문제는 스토리지 문제처럼 보일 수 있습니다. 연결 폭풍은 CPU 압력처럼 보일 수 있습니다. 누락된 인덱스는 IOPS가 부족한 것처럼 보일 수 있습니다. 지역 클라이언트 배치 문제는 데이터베이스 대기 시간처럼 보일 수 있습니다.

모니터링은 팀이 비용이 많이 드는 추측 대신 대상을 변경하는 데 도움이 됩니다.

실제 계획 검사 목록

프로덕션 Azure Database for PostgreSQL 구성을 선택하기 전에 다음 정보를 캡처합니다.

권장 디자인 원칙

운영 성능을 위해 Azure Postgres 배포를 계획할 때 다음 원칙을 사용합니다.

• 데이터 크기뿐만 아니라 워크로드 셰이프의 크기입니다.
  500GB 데이터베이스는 트랜잭션 및 대기 시간에 매우 중요한 경우 5TB 데이터베이스보다 더 많은 IOPS가 필요할 수 있습니다. 크기는 중요하지만 워크로드 동작은 더 중요합니다.
• 컴퓨팅 및 스토리지의 유효성을 함께 검사합니다.
  디스크 제한에 따라 스토리지를 선택하지 마세요. 선택한 컴퓨팅 SKU가 필요한 IOPS 및 처리량을 구동할 수 있도록 합니다.
• 4TB Premium SSD 캐싱 경계를 디자인 마일스톤으로 처리합니다.
  4TB 미만의 프리미엄 SSD 배포는 호스트 캐싱을 활용할 수 있습니다. 4,096GB 이상에서는 호스트 캐싱이 지원되지 않습니다. 증가가 해당 임계값을 초과할 경우 향후 성능 모델을 조기에 계획합니다.
• 유연한 성능 조정을 위해 프리미엄 SSD v2를 고려합니다.
  프리미엄 SSD v2를 사용하면 용량, IOPS 및 처리량을 보다 세밀하게 제어할 수 있습니다. 성능 요구 사항이 고정 디스크 크기에 깔끔하게 매핑되지 않는 경우 적합할 수 있습니다.
• 지속적인 수요가 아니라 일시적인 수요에 대해 버스트를 사용하십시오.
  버스팅은 일시적인 급증에 도움이 될 수 있지만, 자주 발생하거나 지속적인 버스팅은 기준 구성을 다시 검토해야 한다는 의미입니다.
• 야망에 맞춰 생산을 창출하십시오.
  고성능 목표의 경우 v6 시리즈와 같은 최신 컴퓨팅 세대는 이전 범용 세대보다 더 높은 집계 원격 스토리지 제한을 노출할 수 있습니다. 대상이 400,000-IOPS 클래스 아키텍처인 경우 그에 따라 컴퓨팅 생성을 선택합니다.
• 변경 전후에 측정합니다.
  클라우드에서 크기 조정이 더 쉽지만 측정을 통해 크기 조정을 효과적으로 수행할 수 있습니다. 성능 결정이 증거 기반이 되도록 기준, 최대 및 변경 후 메트릭을 캡처합니다.

실제 벤치마크: 부하 중인 스토리지 구성 비교

이 문서에 설명된 원칙은 이론적이지 않습니다. 컴퓨팅, 스토리지 및 워크로드가 실제로 상호 작용하는 방법을 설명하기 위해 이 섹션에서는 제어되고 측정된 조건에서 스토리지 구성 및 컴퓨팅 계층을 비교하는 벤치마크를 요약 pgbench 합니다.

벤치마크 설정 및 방법론

벤치마크는 표준 PostgreSQL 벤치마크 도구인 를 사용하여 pgbench5가지 스토리지 및 컴퓨팅 구성에서 트랜잭션 워크로드를 시뮬레이션합니다. 테스트는 500개의 동시 연결로 시작하고 초기 기간 후에 최대 750개의 동시 연결을 램프하여 테스트 창의 나머지 부분에 대해 이 상승된 연결 부하를 유지합니다. 이 램프업 패턴은 트래픽이 증가함에 따라 시간에 따라 부하를 증가시키는 실제 애플리케이션 수를 시뮬레이션하고 데이터베이스가 초기 급증과 지속적인 높은 동시성 모두에 응답하는 방법을 측정합니다.

모든 벤치마크는 동일한 테스트 데이터베이스 및 워크로드 프로필을 사용하여 동일한 가용성 영역 내의 동일한 지역에 있는 Azure Database for PostgreSQL 유연한 서버에서 실행됩니다. 스토리지와 컴퓨팅을 변수로 격리하여 성능 차이가 네트워크, 애플리케이션 또는 워크로드 변형이 아닌 실제 플랫폼 기능을 반영하도록 합니다.

구성 세부 정보

스토리지 계층과 컴퓨팅 크기가 모두 다른 5개의 고유한 구성을 테스트하여 주요 계획 개념을 보여 줍니다.

구성 디자인의 주요 관찰:

• 구성 1 및 구성 2: 이러한 구성은 스토리지 크기( 4,095GB 및 4,096GB)에서만 다릅니다. 이 비교는 프리미엄 SSD v1 디스크에 대한 호스트 캐싱 경계를 테스트합니다.
• 구성 2 및 구성 3: 두 구성 모두 SSD v1을 사용하지만 구성 3은 32TB 용량으로 확장되어 더 높은 IOPS 및 처리량의 잠금을 해제합니다.
• 구성 3 및 구성 4: 두 구성 모두 동일한 컴퓨팅을 사용하지만 Config 4는 용량에 관계없이 프리미엄 SSD v2 유연한 IOPS 및 처리량을 보여 줍니다.
• 구성 4 및 구성 5: 구성 5는 컴퓨팅 SKU를 두 배로 높여 더 높은 계층 컴퓨팅이 더 많은 스토리지 성능 헤드룸을 잠금 해제하는 방법을 보여 줍니다.

성능 결과

구성 1: 호스트 캐싱이 있는 4,095GB Premium SSD v1

구성 1은 4,095GB Premium SSD v1 크기를 사용하며, 프리미엄 SSD v1에서 호스트 캐싱의 이점을 누릴 수 있습니다. 워크로드 중에 이 구성은 다음과 같이 유지됩니다.

• 최대 IOPS: 24,773, 프리미엄 SSD v1에서 프로비전된 IOPS 7,500으로 제한되며 캐싱은 효과적인 성능을 증폭합니다.
• 최대 읽기 IOPS: 21,330, 읽기 작업이 많은 작업에 대한 호스트 캐시의 이점을 활용합니다.
• 최대 쓰기 IOPS: 7,610.

호스트 캐싱은 읽기 증폭을 제공하므로 효과적인 IOPS는 일시적으로 디스크의 7,500 프로비전된 IOPS 제한을 초과하고 컴퓨팅 스토리지 제한에 도달합니다.

구성 2: 호스트 캐싱 없이 4,096GB Premium SSD v1

구성 2는 4,096 GB의 프리미엄 SSD v1 크기를 사용하여 캐싱 경계를 넘어 호스트 캐싱의 이점을 잃습니다. 영향을 볼 수 있습니다.

• 최대 IOPS: 캐싱 손실로 인해 Config 1에 비해 유효 IOPS가 낮습니다.
• 최대 읽기 IOPS: 호스트 캐시 없이 크게 감소합니다.
• 최대 쓰기 IOPS: 7,610, 변경되지 않음

이 구성은 4TB 캐싱 경계의 실질적인 중요성을 보여 줍니다. 4,095GB에서 4,096GB로 넘어가면 캐시된 읽기를 제거하여 성능 프로필이 변경됩니다. 이 임계값에 근접하는 증가하는 데이터베이스의 경우 미리 계획하세요.

구성 3: IOPS가 더 높은 32TB Premium SSD v1

구성 3은 32TB 용량으로 확장하여 프리미엄 SSD v1 상위 IOPS 및 처리량 제한을 해결합니다. 이 구성은 다음을 수행했습니다.

• 최대 IOPS: 20,000.
• 최대 읽기 IOPS: 약 12,000.
• 최대 쓰기 IOPS: 약 5,000.

기본 프리미엄 SSD v1 스토리지 용량을 늘리면 IOPS 및 처리량이 증가합니다. 집약적인 워크로드에 대한 컴퓨팅 스토리지 범위의 상한에 도달할 수 있습니다.

구성 4: 40,000 IOPS를 사용하는 프리미엄 SSD v2

구성 4는 4,095GB 용량에서 40,000 IOPS 및 1,200MB/s 처리량을 프로비전하는 프리미엄 SSD v2 유연한 성능 구성을 보여 줍니다.

• 최대 IOPS: 프리미엄 SSD v2 대기 시간 및 처리량 기능으로 인해 더 효과적인 사용률.
• 최대 읽기 IOPS: 프리미엄 SSD v1 구성에 비해 성능이 향상되었습니다.
• 최대 쓰기 IOPS: 지속적인 쓰기 용량이 높습니다.

프리미엄 SSD v2를 사용하면 대용량 스토리지 용량 없이 높은 IOPS를 프로비전할 수 있으므로 트랜잭션이 많은 워크로드에 효율적입니다.

구성 5: D32ds_v5 컴퓨팅에서 60,000 IOPS를 사용하는 프리미엄 SSD v2

구성 5는 스토리지 성능(60,000 IOPS)과 컴퓨팅의 크기를 모두 조정하며 Standard_D32ds_v5 및 32개의 vCore를 사용합니다. 이 구성은 종단 간 맞춤 원칙을 보여 줍니다.

• 최대 IOPS: 이전의 모든 구성보다 훨씬 높습니다.
• 최대 읽기 IOPS: 추가 컴퓨팅 헤드룸을 통한 강력한 개선.
• 최대 쓰기 IOPS: 더 높은 쓰기 용량을 유지합니다.

이 구성은 컴퓨팅 및 스토리지를 모두 더 높은 성능 계층에 맞춰 최상의 처리량과 가장 낮은 CPU 압력을 달성합니다. D32ds_v5 스토리지 한도가 높을수록 60,000-IOPS Premium SSD v2 디스크를 더 완벽하게 사용할 수 있습니다.

벤치마크의 교훈

이 다섯 가지 구성은 이 문서의 주요 원칙을 보여 줍니다.

• 4TB 캐싱 경계가 중요합니다.
  구성 1과 구성 2는 호스트 캐싱이 4TB 미만의 측정 가능한 읽기 성능 증폭을 제공하는 반면 4,096GB로 넘어가면 해당 이점이 제거된다는 것을 보여줍니다.
• 용량은 성능이 아닙니다.
  구성 3은 32TB를 프로비전했지만 가장 높은 IOPS를 제공하지 않았습니다. 스토리지 용량만으로는 트랜잭션 처리량을 결정하지 않습니다.
• 프리미엄 SSD v2는 유연한 성능 튜닝을 제공합니다.
  구성 4는 프리미엄 SSD v2에서 사용할 수 있는 분리된 모델의 유효성을 검사하여 적은 용량에서 높은 IOPS를 입증했습니다.
• 컴퓨팅 및 스토리지를 정렬해야 합니다.
  구성 5는 스토리지 성능을 최대화하려면 충분한 컴퓨팅 헤드룸이 필요하다는 것을 보여 줍니다. 60,000-IOPS 프로비저닝을 보다 완벽하게 사용하기 위해 D32ds_v5의 스토리지 용량 한도가 필요했습니다.

벤치마크 결과는 핵심 원칙의 유효성을 검사합니다. 최대 성능은 엔드 투 엔드 속성입니다. 스토리지, 컴퓨팅 또는 네트워킹과 같은 단일 계층이 결과를 결정하지 않습니다. 성공하려면 워크로드가 진화함에 따라 모든 계층에서 의도적인 맞춤, 측정된 유효성 검사 및 지속적인 관찰이 필요합니다.

결론

Azure Postgres는 클라우드에서 호스트되는 최신 데이터베이스 솔루션을 빌드하기 위한 강력하고 유연한 플랫폼을 제공합니다. Azure 컴퓨팅, 스토리지, 네트워킹, 고가용성, 복제, 보안 및 관찰성에 대한 엔지니어링을 통해 가장 성능이 뛰어나고 복원력 있는 Postgres 아키텍처를 사용할 수 있습니다.

최대 성능은 실수로 발생하지 않습니다.

최대 운영 성능을 위해서는 애플리케이션, 클라이언트, 워크로드, 데이터 증가 프로필, 읽기/쓰기 조합 및 수요를 형성하는 비즈니스 주기를 이해해야 합니다. 또한 IOPS, 처리량 및 대기 시간 목표를 엔드투엔드로 달성할 수 있도록 컴퓨팅 및 스토리지 선택 항목을 모두 조정해야 합니다.

프리미엄 SSD v1은 특히 호스트 캐싱이 4TB 경계 아래의 데이터에 적용되는 경우 강력한 예측 가능한 성능을 제공할 수 있습니다. 프리미엄 SSD v2는 용량, IOPS 및 처리량을 분리하여 보다 유연한 성능 구성을 추가합니다. Ultra Disk는 가장 높은 Azure 관리 디스크 성능 클래스를 나타내며, 최신 컴퓨팅 세대는 고급 아키텍처에 대해 훨씬 더 높은 집계 원격 스토리지 한도를 제공합니다.

최상의 Azure Postgres 배포는 플랫폼 기능과 의도적인 계획, 지속적인 모니터링 및 명확한 운영 소유권을 결합합니다. 올바른 요구 사항과 올바른 아키텍처를 통해 팀은 최고 성능을 제공하는 세계적 수준의 Postgres 환경을 제공할 수 있습니다.

관련 콘텐츠

• Azure Premium Storage: 고성능을 위한 디자인
• Azure 디스크 버스팅(임시적 처리 능력 증가)
• Ddv5 및 Ddsv5 시리즈 VM 크기
• Ddsv6 시리즈 VM 크기
• Azure Database for PostgreSQL의 프리미엄 SSD 스토리지 옵션
• Azure Database for PostgreSQL의 프리미엄 SSD v2 스토리지 옵션입니다.
• Azure 관리 디스크 형식
• Azure Database for PostgreSQL에서 메트릭 모니터링