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

  • 아티클

적용 대상: 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를 통해 연결) 이 액세스는 제한할 수 없습니다. 가상 네트워크의 서버는 네트워크 보안 그룹을 통해 아웃바운드 액세스를 제한할 수 있습니다.

고가용성

가용성 영역

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

관련 콘텐츠