Azure Database for PostgreSQL - 유연한 서버의 제한

2024-09-26

적용 대상: Azure Database for PostgreSQL - 유연한 서버

다음 섹션에서는 Azure Database for PostgreSQL 유연한 서버의 용량 및 기능 제한을 설명합니다. 리소스(컴퓨팅, 메모리, 스토리지) 계층에 대해 알아보려면 컴퓨팅 및 스토리지 문서를 참조하세요.

최대 연결 수

다음 표에는 각 가격 책정 계층 및 vCore 구성에 대한 기본 최대 연결 수가 나와 있습니다. Azure Database for PostgreSQL 유연한 서버는 Azure Database for PostgreSQL 유연한 서버 인스턴스의 실제 복제 및 모니터링을 위해 15개의 연결을 예약합니다. 결과적으로, 표에 나열된 최대 사용자 연결 값은 총 최대 연결 수에서 15만큼 감소됩니다.

제품 이름	vCore 수	메모리 크기	최대 연결 수	최대 사용자 연결
버스트 가능
B1ms	1	2GiB	50	35
B2s	2	4GiB	429	414
B2ms	2	8GiB	859	844
B4ms	4	16GiB	1,718	1,703
B8ms	8 (여덟)	32GiB	3,437	3,422
B12ms	12	48GiB	5,000	4,985
B16ms	16	64GiB	5,000	4,985
B20ms	20	80GiB	5,000	4,985
범용
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5	2	8GiB	859	844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5	4	16GiB	1,718	1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5	8 (여덟)	32GiB	3,437	3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5	16	64GiB	5,000	4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5	32	128GiB	5,000	4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5	48	192GiB	5,000	4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5	64	256GiB	5,000	4,985
D96ds_v5 / D96ads_v5	96	384GiB	5,000	4,985
메모리 최적화
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5	2	16GiB	1,718	1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5	4	32GiB	3,437	3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5	8 (여덟)	64GiB	5,000	4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5	16	128GiB	5,000	4,985
E20ds_v4 / E20ds_v5 / E20ads_v5	20	160GiB	5,000	4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5	32	256GiB	5,000	4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5	48	384GiB	5,000	4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5	64	432GiB	5,000	4,985
E96ds_v5 / E96ads_v5	96	672GiB	5,000	4,985

현재 15개로 예약된 연결 슬롯은 변경될 수 있습니다. 서버에 예약된 총 연결 수를 정기적으로 확인하는 것이 좋습니다. reserved_connections 및 superuser_reserved_connections 서버 매개 변수의 값을 합산하여 이 숫자를 계산합니다. 사용 가능한 최대 사용자 연결 수는 max_connections입니다(reserved_connections + superuser_reserved_connections).

max_connections 서버 매개 변수의 기본값은 컴퓨팅을 위해 선택한 제품 이름을 기반으로 Azure Database for PostgreSQL 유연한 서버의 인스턴스를 프로비전할 때 계산됩니다. 유연한 서버를 지원하는 컴퓨팅에 대한 제품 선택의 후속 변경 내용은 해당 인스턴스의 max_connections 서버 매개 변수에 대한 기본값에 영향을 미치지 않습니다. 인스턴스에 할당된 제품을 변경할 때마다 이전 표의 값에 따라 max_connections 매개 변수의 값도 조정하는 것이 좋습니다.

max_connections 값 변경

Azure Database for Postgres 유연한 서버 인스턴스를 처음 설정하면 동시에 처리할 수 있는 최대 연결 수가 자동으로 결정됩니다. 이 숫자는 서버 구성을 기반으로 하며 변경할 수 없습니다.

그러나 max_connections 설정을 사용하여 특정 시간에 허용되는 연결 수를 조정할 수 있습니다. 이 설정을 변경한 후 새 제한이 작동하려면 서버를 다시 시작해야 합니다.

주의

기본 설정 이상으로 max_connections 값을 늘릴 수는 있지만 그렇게 하지 않는 것이 좋습니다.

워크로드가 확장되고 더 많은 메모리가 필요할 때 인스턴스에 문제가 발생할 수 있습니다. 연결 수가 증가하면 메모리 사용량도 증가합니다. 메모리가 제한된 인스턴스는 크래시이나 긴 대기 시간과 같은 문제에 직면할 수 있습니다. 대부분의 연결이 유휴 상태일 때 max_connections에 대한 더 높은 값이 허용될 수 있지만 일단 활성화되면 심각한 성능 문제가 발생할 수 있습니다.

더 많은 연결이 필요한 경우 대신 연결 풀 관리를 위해 기본 제공 Azure 솔루션인 PgBouncer를 사용하는 것이 좋습니다. 트랜잭션 모드에서 사용합니다. 시작하려면 2~5 범위 내에서 vCore를 곱하여 보수적인 값을 사용하는 것이 좋습니다. 그런 다음 리소스 사용률과 애플리케이션 성능을 주의 깊게 모니터링하여 원활한 운영을 보장합니다. PgBouncer에 대한 자세한 내용은 Azure Database for PostgreSQL 유연한 서버의 PgBouncer를 참조하세요.

연결이 한도를 초과하면 다음 오류가 나타날 수 있습니다.

FATAL: sorry, too many clients already.

동시 연결 수가 많고 사용량이 많은 데이터베이스에 Azure Database for PostgreSQL 유연한 서버를 사용하는 경우 리소스에 상당한 부담이 있을 수 있습니다. 이러한 부담은 특히 많은 연결이 동시에 설정되고 연결 기간이 짧은 경우(60초 미만) 높은 CPU 사용률을 초래할 수 있습니다. 이러한 요소는 연결 및 연결 끊기 처리에 소요되는 시간을 증가시켜 전체 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다.

Azure Database for PostgreSQL 유연한 서버의 각 연결은 유휴 상태인지 활성 상태인지에 관계없이 데이터베이스에서 상당한 양의 리소스를 소비한다는 점에 유의해야 합니다. 이러한 사용량으로 인해 디스크 및 잠금 경합과 같은 높은 CPU 사용량 이상의 성능 문제가 발생할 수 있습니다. PostgreSQL Wiki의 데이터베이스 연결 수 문서에서 이 항목에 대해 자세히 설명합니다. 자세히 알아보려면 Azure Database for PostgreSQL 유연한 서버의 연결 성능 식별 및 해결을 참조하세요.

기능 제한 사항

다음 섹션에는 Azure Database for PostgreSQL 유연한 서버에서 지원되는 것과 지원되지 않는 것에 대한 고려 사항이 나열되어 있습니다.

크기 조정 작업

이때 서버 스토리지의 크기를 조정하려면 서버를 다시 시작해야 합니다.
서버 스토리지는 2배만 증가하여 확장할 수 있습니다. 자세한 내용은 스토리지를 참조하세요.
서버 스토리지 크기를 줄이는 것은 현재 지원되지 않습니다. 유일한 방법은 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스에 덤프하고 복원하는 것입니다.

스토리지

스토리지 크기를 구성한 후에는 이를 줄일 수 없습니다. 원하는 스토리지 크기로 새 서버를 만들고, 수동으로 덤프 및 복원 작업을 수행하고, 데이터베이스를 새 서버로 마이그레이션해야 합니다.
스토리지 사용량이 95%에 도달하거나 사용 가능한 용량이 5GiB 미만인 경우 디스크가 가득 찬 상황과 관련된 오류를 방지하기 위해 서버가 자동으로 읽기 전용 모드로 전환됩니다. 드문 경우지만 데이터 증가 속도가 읽기 전용 모드로 전환하는 데 걸리는 시간을 초과하면 서버의 스토리지가 부족할 수 있습니다. 스토리지 자동 증가를 사용하도록 설정하여 이러한 문제를 방지하고 워크로드 수요에 따라 스토리지를 자동으로 크기 조정할 수 있습니다.
특정 임계값을 초과할 때 storage used 또는 storage percent에 대한 경고 규칙을 설정하여 스토리지 크기 증가와 같은 조치를 사전에 취할 수 있도록 하는 것이 좋습니다. 예를 들어, 스토리지 비율이 사용량의 80%를 초과하는 경우 경고를 설정할 수 있습니다.
논리 복제를 사용하는 경우 해당 구독자가 더 이상 존재하지 않으면 주 서버에서 논리 복제 슬롯을 삭제해야 합니다. 그러지 않으면 WAL(미리 쓰기 로깅) 파일이 기본 데이터베이스에 누적되어 스토리지가 가득 찹니다. 스토리지가 특정 임계값을 초과하고 논리적 복제 슬롯이 사용 중이 아닌 경우(사용할 수 없는 구독자로 인해), Azure Database for PostgreSQL 유연한 서버는 사용되지 않은 논리적 복제 슬롯을 자동으로 삭제합니다. 이 작업을 수행하면 누적된 WAL 파일이 해제되고 스토리지가 가득 차서 서버를 사용할 수 없게 되는 것을 방지할 수 있습니다.
테이블스페이스 만들기를 지원하지 않습니다. 데이터베이스를 만드는 경우 테이블스페이스 이름을 제공하지 마세요. Azure Database for PostgreSQL 유연한 서버는 템플릿 데이터베이스에서 상속된 기본 서버를 사용합니다. 서버 다시 시작 및 HA(고가용성) 장애 조치(failover)와 같은 이벤트 후에 해당 개체가 지속성을 유지하는지 확인할 수 없으므로 임시 테이블스페이스와 같은 테이블스페이스를 제공하는 것은 안전하지 않습니다.

네트워킹

가상 네트워크 내부 및 외부로의 이동은 현재 지원되지 않습니다.
공용 액세스와 가상 네트워크 배포를 결합하는 것은 현재 지원되지 않습니다.
가상 네트워크에서는 방화벽 규칙이 지원되지 않습니다. 대신 네트워크 보안 그룹을 사용할 수 있습니다.
공용 액세스 데이터베이스 서버는 공용 인터넷에 연결할 수 있습니다(예: postgres_fdw를 통해 연결) 이 액세스는 제한할 수 없습니다. 가상 네트워크의 서버는 네트워크 보안 그룹을 통해 아웃바운드 액세스를 제한할 수 있습니다.

고가용성

Azure Database for PostgreSQL 유연한 서버의 높은 가용성을 확인하세요.

가용성 영역

서버를 다른 가용성 영역으로 수동으로 이동하는 것은 현재 지원되지 않습니다. 그러나 기본 가용성 영역을 대기 영역으로 사용하면 HA를 활성화할 수 있습니다. 대기 영역을 설정한 후 해당 영역으로 장애 조치(failover)한 다음 HA를 끌 수 있습니다.

Postgres 엔진, 확장 및 PgBouncer

Postgres 10 및 이전 버전은 오픈 소스 커뮤니티에서 사용 중지되었으므로 지원되지 않습니다. 이러한 버전 중 하나를 사용해야 하는 경우 이전 주 버전 9.5, 9.6 및 10을 지원하는 Azure Database for PostgreSQL 단일 서버 옵션을 사용해야 합니다.
Azure Database for PostgreSQL 유연한 서버는 모든 contrib 확장 등을 지원합니다. 자세한 내용은 PostgreSQL 확장을 참조하세요.
기본 제공 PgBouncer 연결 풀러는 현재 버스트 가능 서버에서 사용할 수 없습니다.

작업 중지/시작

Azure Database for PostgreSQL 유연한 서버 인스턴스를 중지하면 7일 후에 자동으로 시작됩니다.

예약된 유지 관리

사용자 지정 유지 관리 기간을 요일/시간으로 변경할 수 있습니다. 그러나 유지 관리 알림을 받은 후 변경한 사항은 다음 유지 관리에 영향을 미치지 않습니다. 변경 내용은 다음 월간 예약된 유지 관리에만 적용됩니다.

서버 백업

시스템이 백업을 관리합니다. 현재로서는 백업을 수동으로 실행할 수 있는 방법이 없습니다. 대신 pg_dump를 사용하는 것이 좋습니다.
첫 번째 스냅샷은 전체 백업이고 연속 스냅샷은 차등 백업입니다. 차등 백업은 마지막 스냅샷 백업 이후 변경된 데이터만 백업합니다.

예를 들어, 데이터베이스 크기가 40GB이고 프로비전된 스토리지가 64GB인 경우 첫 번째 스냅샷 백업은 40GB가 됩니다. 이제 4GB의 데이터를 변경하면 다음 차등 스냅샷 백업 크기는 4GB만 됩니다. 트랜잭션 로그(미리 쓰기 로그)는 전체 및 차등 백업과 별개이며 지속적으로 보관됩니다.

서버 복원

PITR(특정 시점 복원) 기능을 사용하는 경우 새 서버는 해당 서버의 기반이 되는 서버와 동일한 컴퓨팅 및 스토리지 구성으로 만들어집니다.
가상 네트워크의 데이터베이스 서버는 백업에서 복원할 때 동일한 가상 네트워크로 복원됩니다.
복원 동안 만든 새 서버에는 원래 서버에 존재했던 방화벽 규칙이 없습니다. 새 서버에 대해 별도로 방화벽 규칙을 만들어야 합니다.
다른 구독으로의 복원은 지원되지 않습니다. 해결 방법으로 동일한 구독 내에서 서버를 복원한 다음 복원된 서버를 다른 구독으로 마이그레이션할 수 있습니다.

보안

Postgres 14 이상 버전에서는 MD5 해싱이 사용하지 않도록 설정되었으며 네이티브 Postgres 암호는 SCRAM-SHA-256 방법만 사용하여 해시됩니다.