이 페이지에서는 PostgreSQL용 AlloyDB의 성능, 내구성, 가용성을 개선하는 데 도움이 되는 일반적인 권장사항을 소개합니다. 이 페이지는 이미 AlloyDB 및 PostgreSQL에 익숙한 데이터베이스 관리자와 개발자를 대상으로 합니다.
인스턴스 구성 및 관리
AlloyDB 도구를 사용하여 데이터베이스 사용량 및 상태를 모니터링합니다.
운영 가이드라인을 따릅니다.
기본 인스턴스의 유지보수 기간을 구성합니다.
읽기 트래픽을 오프로드하기 위해 읽기 풀 인스턴스 추가
복제 지연 관리
이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.
중요한 데이터베이스 유지보수를 수용할 수 있을 만큼 충분한 스토리지 할당량을 구성합니다.
CPU 사용률 초과 방지
메모리 소진을 방지합니다.
인스턴스에 최적의 거래 ID가 있는지 확인합니다.
AlloyDB 도구를 사용하여 데이터베이스 사용량 및 상태 모니터링
다음 표를 사용하여 데이터베이스 사용량, 상태, 성능을 모니터링하는 데 도움이 되는 AlloyDB 도구에 대해 알아보세요.
| AlloyDB 도구 | 설명 |
|---|---|
| 실적 개요 보고서 | 두 가지 시점 간의 시스템 측정항목 스냅샷을 비교합니다. |
| 쿼리 통계 | AlloyDB 데이터베이스의 쿼리 성능 문제를 감지, 진단, 방지하는 데 도움이 됩니다. 감지뿐 아니라 셀프서비스, 직관적인 모니터링, 진단 정보를 제공하여 문제의 근본 원인을 식별하는 데 도움이 됩니다. |
| 시스템 통계 | 활성 노드 수, CPU 사용량, 최대 연결 수, 로그 오류, 초당 트랜잭션 수, 최대 복제 지연을 비롯한 데이터베이스 리소스 및 측정항목을 모니터링할 수 있습니다. |
운영 가이드라인 준수
인스턴스에 PostgreSQL용 AlloyDB SLA가 적용되는지 확인하려면 운영 가이드라인을 따르세요.
기본 인스턴스의 유지보수 기간 구성
기본 인스턴스의 유지보수 기간을 구성하여 방해가 되는 업데이트가 발생할 수 있는 시간을 계획하세요. 자세한 내용은 유지보수 시간 보기 및 설정을 참고하세요.
읽기 트래픽을 오프로드하기 위해 읽기 풀 인스턴스 추가
읽기가 많은 워크로드의 경우 읽기 풀 인스턴스를 추가하여 기본 인스턴스에서 읽기 트래픽을 오프로드합니다.
캐싱을 개선하려면 인스턴스의 각 데이터베이스에 하나 이상의 읽기 풀을 구성합니다.
자동 부하 분산 및 고가용성을 용이하게 하려면 풀당 노드를 추가해 보세요.
복제 지연 관리
AlloyDB는 복제 지연을 개선하기 위해 몇 가지 개선사항을 적용했습니다. 그러나 로그 재생이 차단되거나 따라잡을 수 없는 시나리오가 발생하여 복제 지연이 증가할 수 있습니다.
예를 들어 기본 VM 크기가 읽기 풀 노드 크기보다 훨씬 큰 경우, 특히 읽기 노드에서 동시에 실행되는 읽기 워크로드가 많은 경우, 쓰기 워크로드가 많으면 기본 VM이 읽기 노드가 로그 레코드를 재생할 수 있는 속도보다 더 빠르게 로그 레코드를 생성할 수 있습니다. 이 시나리오에서는 읽기 노드 크기를 늘려 더 많은 리소스를 제공하는 것이 좋습니다.
애플리케이션 요구사항에 따라 다음 매개변수를 조정할 수 있습니다.
max_standby_streaming_delay: 재생이 차단 중인 쿼리를 취소하기 전에 대기하는 시간을 결정합니다.google_storage.log_replay_throttle_read_transactions: 지연 시간이 길 때 쿼리를 제한할지 여부를 결정합니다. 쿼리 제한을 사용하면 재생이 더 많은 리소스를 사용하여 더 빨리 따라잡고 오래된 데이터를 쿼리에 반환하지 않을 수 있습니다.alloydb.promote_cancel_to_terminate: 취소에 응답하지 않는 쿼리 백엔드를 강제로 종료할지 결정합니다.
이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.
AlloyDB 인스턴스는 이전 작업이 완료될 때까지 새 작업 요청을 수락할 수 없습니다. 이전 작업이 완료되기 전에 새 작업을 시작하려고 하면 작업 요청에 실패합니다. 인스턴스 다시 시작도 여기에 포함됩니다.
Google Cloud 콘솔의 인스턴스 상태에는 작업 실행 여부가 반영되지 않습니다. 녹색 체크표시는 인스턴스가 RUNNABLE 상태인지 여부만 나타냅니다. 작업이 실행 중인지 확인하려면 작업 탭을 클릭하고 최근 작업의 상태를 확인합니다.
중요한 데이터베이스 유지보수를 수용할 만큼 충분한 스토리지 할당량 구성
기본적으로 클러스터당 최대 16TB의 스토리지를 사용할 수 있습니다. 저장용량이 더 필요한 경우 저장용량 할당량을 늘리세요.
CPU 사용률 초과 방지
Google Cloud 콘솔의 인스턴스 세부정보 페이지에서 인스턴스가 사용하고 있는 가용 CPU 비율을 확인할 수 있습니다. 자세한 내용은 인스턴스 모니터링을 참고하세요. 또한 측정항목 기준점 알림 정책 만들기를 사용하여 CPU 사용량을 모니터링하고 지정된 기준에 도달할 때 알림을 받을 수 있습니다.
사용률이 초과되지 않도록 인스턴스를 더 많은 수의 CPU로 확장할 수 있습니다. CPU를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 CPU 수에 도달한 경우에는 데이터베이스를 여러 인스턴스로 샤딩하는 것이 좋습니다.
메모리 소진 방지
AlloyDB에는 메모리 부족 문제를 방지하는 자동 메모리 관리가 있습니다. 그러나 지속적인 메모리 부족은 성능 문제를 일으킬 수 있습니다. 메모리 소진의 징후를 찾을 때는 주로 usage 측정항목을 사용해야 합니다. 최적의 성능을 위해 이 측정항목이 90% 미만으로 유지되는 것이 좋습니다.
또한 total_usage 측정항목을 사용하여 데이터베이스 컨테이너에서 사용하는 메모리와 운영체제 캐시에서 할당한 메모리를 포함하여 AlloyDB 인스턴스에서 사용 중인 사용 가능한 메모리 비율을 관찰할 수 있습니다.
사용량과 총 사용량 측정항목의 차이를 관찰하면 프로세스에서 사용하는 메모리의 양과 운영체제 캐시에서 사용하는 메모리의 양을 식별할 수 있습니다. 이 캐시에서 메모리의 용도를 변경할 수 있습니다.
AlloyDB 인스턴스를 확장하여 메모리 크기를 늘립니다. 인스턴스의 메모리 크기를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 메모리 크기에 도달한 경우에는 데이터베이스를 여러 인스턴스로 샤딩해야 합니다.
Google Cloud 콘솔에서 사용량 및 총 사용량 측정항목을 모니터링하는 방법에 관한 자세한 내용은 인스턴스 모니터링을 참고하세요.
인스턴스에 최적의 트랜잭션 ID가 있는지 확인
Resource Type를 AlloyDB for PostgreSQL Database로 설정하고 Metric를 Percentage of instance's transaction IDs consumed로 설정하여 Google Cloud 콘솔의 측정항목 탐색기 페이지에서 인스턴스의 트랜잭션 ID 사용량을 볼 수 있습니다. 자세한 내용은 측정항목 탐색기로 차트 만들기를 참고하세요.
AlloyDB에는 자동화된 적응형 자동 정리 기능이 내장되어 있어 정리 관련 문제를 완화하는 데 도움이 됩니다.
데이터 아키텍처
가능하면 큰 인스턴스를 작은 인스턴스로 분할
가능하면 하나의 큰 인스턴스를 사용하는 대신 여러 개의 작은 AlloyDB 클러스터를 사용하세요. 큰 모놀리식 인스턴스를 관리하면 작은 인스턴스 그룹을 관리할 때 발생하지 않는 문제가 발생합니다.
데이터베이스 테이블을 너무 많이 사용하지 않음
인스턴스의 테이블 수를 10,000개 미만으로 유지합니다. 데이터베이스 테이블이 너무 많으면 데이터베이스 업그레이드 시간에 영향을 줄 수 있습니다.
쿼리 성능
분석 쿼리를 실행하는 경우 열 기반 엔진 사용 설정
AlloyDB 열 형식 엔진 개요를 읽습니다. 열 기반 엔진을 사용 설정하면 이점이 있는 쿼리 유형을 확인합니다.
열 형식 엔진 사용량을 모니터링할 수 있습니다.
열 엔진을 처음 사용하는 경우 먼저 자동 열 정렬을 숙지하세요. 그런 다음 열을 수동으로 관리하도록 선택할 수 있습니다.
인스턴스 확장으로 쿼리 성능 개선
쿼리 성능이 낮은 경우 인스턴스를 확장하는 것이 좋습니다.
각 SKU에는 제한된 vCPU 및 메모리 구성이 있으며 각 SKU에는 제한된 빠른 캐시도 있습니다. 데이터 크기가 크고 쿼리 성능이 좋지 않은 경우 더 큰 인스턴스로 확장해 보세요.
읽기 풀을 배포하고 읽기 풀에 읽기 쿼리 오프로드
애플리케이션에서 쓰기 및 읽기가 많은 경우 읽기 풀을 배포하고 읽기 풀에 읽기 쿼리를 오프로드하는 것이 좋습니다.
읽기가 많은 워크로드의 경우 읽기 풀 인스턴스를 추가하여 기본 인스턴스에서 읽기 트래픽을 오프로드합니다.
애플리케이션 구현
적절한 연결 관리 기법 사용
유지보수 업데이트에 대한 애플리케이션의 응답을 테스트합니다.
장애 조치에 대한 애플리케이션의 응답을 테스트합니다.
대규모 트랜잭션은 피하세요.
다수의 하위 트랜잭션을 피하세요.
최신 버전의 인증 프록시를 사용합니다.
우수한 연결 관리 권장사항 사용
연결 풀링 및 지수 백오프와 같은 연결 관리 권장사항을 사용합니다.
올바른 연결 관리 기법을 사용하면 애플리케이션의 리소스 사용이 개선되고 AlloyDB 연결 한도를 유지할 수 있습니다.
유지보수 업데이트에 대한 애플리케이션의 응답 테스트
유지보수 기간 중 언제든지 발생할 수 있는 유지보수 업데이트에 대한 애플리케이션의 응답을 테스트하세요.
컴퓨팅 확장 작업을 실행하거나 비즈니스 중단 시간이 짧은 유지보수(LDTM)를 트리거하는 정적 PostgreSQL 플래그를 업데이트하여 유지보수 업데이트를 시뮬레이션할 수 있습니다.
LDTM 중에 인스턴스를 잠시 사용할 수 없게 되고 기존 연결이 끊어집니다. LDTM을 테스트하면 애플리케이션이 예약된 유지보수를 처리하는 방법과 시스템이 복구되는 속도를 더 잘 이해할 수 있습니다.
장애 조치에 대한 애플리케이션의 응답 테스트
언제든지 발생할 수 있는 장애 조치에 대한 애플리케이션의 응답을 테스트하세요.
Google Cloud 콘솔, Google Cloud CLI 또는 API를 사용하여 장애 조치를 수동으로 시작할 수 있습니다. 자세한 내용은 장애 조치 시작을 참고하세요.
대규모 트랜잭션 방지
트랜잭션을 작고 짧게 유지하세요. 대규모 데이터베이스 업데이트가 필요한 경우 하나의 큰 트랜잭션을 실행하는 대신 여러 건의 작은 트랜잭션으로 업데이트를 실행하세요.
대규모 하위 트랜잭션 피하기
장기 실행 트랜잭션이 있는 경우 트랜잭션에서 하위 트랜잭션을 다량 사용하지 마세요.
AlloyDB에서 PL/pgSQL 오류 블록에서 트랜잭션을 실행하면 오류 블록에 해당하는 트랜잭션의 하위 트랜잭션이 생성됩니다. 장기 실행 트랜잭션이 있는 경우 하위 트랜잭션 수가 64개를 초과하면 전반적인 시스템 성능이 저하됩니다.
인증 프록시의 최신 버전 사용
AlloyDB 인증 프록시를 사용하는 경우 최신 버전을 사용하세요. 자세한 내용은 인증 프록시 클라이언트를 최신 상태로 유지를 참고하세요.
데이터 가져오기 및 내보내기
이전을 위해 PostgreSQL용 Cloud SQL 백업에서 복원
마이그레이션을 쉽게 하려면 PostgreSQL용 Cloud SQL에서 AlloyDB로 마이그레이션을 참고하세요.
연속 데이터 복제를 사용하여 PostgreSQL용 Cloud SQL에서 AlloyDB로 데이터를 마이그레이션하는 방법을 알아보려면 PostgreSQL용 AlloyDB를 위한 Database Migration Service를 참고하세요.
소형 인스턴스의 가져오기 속도 높이기
작은 인스턴스에 큰 데이터 세트를 가져올 때 성능을 개선하기 위해 인스턴스의 CPU와 RAM을 일시적으로 늘릴 수 있습니다.
백업 및 복구
적절한 AlloyDB 기능을 사용하여 데이터 보호
중복 및 보호를 위해 백업, point-in-time recovery (PITR), 내보내기를 사용하세요. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다.
백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 AlloyDB의 백업 기능에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다.
PITR(point-in-time recovery)은 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다. point-in-time recovery는 항상 새 인스턴스를 만듭니다. 즉, 기존 인스턴스에는 point-in-time recovery를 수행할 수 없습니다.
Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다.
인스턴스와 백업이 실수로 삭제되지 않도록 보호
기본 실수로 인한 삭제 방지를 사용 설정하려면 Google Cloud 콘솔 또는 Terraform을 사용하여 AlloyDB 인스턴스를 만듭니다.
추가 보호를 위해 AlloyDB의 내보내기 기능을 사용하여 데이터를 내보내세요. Cloud Scheduler를 Cloud Scheduler API와 함께 사용하여 내보내기 관리를 자동화하세요.
고급 시나리오의 경우 자동화를 위해 Cloud Scheduler와 Cloud Run Functions를 함께 사용합니다.