이 페이지는 Cloud Translation API를 통해 번역되었습니다.

일반 권장사항

MySQL | PostgreSQL | SQL Server

이 페이지에서는 Cloud SQL의 성능, 내구성, 가용성을 최적화하기 위한 권장사항을 제공합니다.

Cloud SQL 인스턴스에 문제가 발생하면 문제 해결 중에 다음을 검토하세요.

인스턴스 구성 및 관리

권장사항	추가 정보
운영 가이드라인을 읽고 따라 인스턴스에 Cloud SQL SLA가 적용되는지 확인하세요.
기본 인스턴스의 유지보수 기간을 구성하여 방해가 되는 업데이트가 발생할 수 있는 시간을 제어하세요.	유지보수 기간을 참조하세요.
읽기가 많이 발생하는 워크로드의 경우 읽기 복제본을 추가하여 기본 인스턴스에서 트래픽을 오프로드하세요.	원하는 경우 HAProxy와 같은 부하 분산기를 사용하여 복제본에 대한 트래픽을 관리할 수 있습니다.
인스턴스를 정기적으로 삭제하고 다시 만드는 경우 인스턴스 ID의 타임스탬프를 사용하여 새로운 인스턴스 ID의 사용 가능성을 높이세요.
이전 작업이 완료되기 전에 관리 작업을 시작하지 마세요.	Cloud SQL 인스턴스는 이전 작업을 완료할 때까지 새로운 작업 요청을 수락하지 않습니다. 조기에 새로운 작업을 시작하려고 시도하면 작업 요청에 실패합니다. 인스턴스 다시 시작도 여기에 포함됩니다. Google Cloud 콘솔의 인스턴스 상태에는 작업 실행 여부가 반영되지 않습니다. 녹색 체크표시는 인스턴스가 `RUNNABLE` 상태인 것만 나타냅니다. 작업 실행 여부를 확인하려면 작업 탭으로 이동하여 최근 작업 상태를 확인합니다.
중요한 데이터베이스 유지보수를 지원하도록 스토리지를 구성합니다.	스토리지 자동 증가 사용 설정 인스턴스 설정이 중지되었거나 스토리지 자동 증가 한도가 사용 설정된 경우 Cloud SQL이 수행할 수 있는 중요한 데이터베이스 유지보수 작업을 수용할 수 있도록 적어도 20%의 가용 공간이 있어야 합니다. 사용 가능한 디스크 공간이 20% 미만일 때 알림을 받으려면 기준점 초과 위치와 .8 값을 사용해 디스크 사용률 측정항목에 대한 측정항목 기반 알림 정책을 만듭니다. 자세한 내용은 측정항목 기반 알림 정책 만들기를 참조하세요.
CPU 사용률 초과를 방지하세요.	Google Cloud 콘솔의 인스턴스 세부정보 페이지에서 인스턴스가 사용하고 있는 가용 CPU 비율을 확인할 수 있습니다. 자세한 내용은 측정항목을 참조하세요. 또한 측정항목 기준점 알림 정책 만들기를 사용하여 CPU 사용량을 모니터링하고 지정된 기준에 도달할 때 알림을 받을 수 있습니다. 사용률이 초과되지 않도록 인스턴스의 CPU 수를 늘릴 수 있습니다. CPU를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 CPU 수에 도달한 경우에는 데이터베이스를 여러 인스턴스로 샤딩해야 합니다.
메모리 소진을 방지하세요.	메모리 소진의 징후를 찾을 때는 주로 usage 측정항목을 사용해야 합니다. 메모리 부족 오류를 방지하려면 이 측정항목이 90% 미만으로 유지되는 것이 좋습니다. 또한 total_usage 측정항목을 사용하여 데이터베이스 컨테이너가 사용하는 메모리와 운영체제 캐시에서 할당한 메모리 등 Cloud SQL 인스턴스가 사용하는 가용 메모리 비율을 관찰할 수도 있습니다. 두 측정항목의 차이를 관찰하면 프로세스에서 사용하는 메모리의 양과 운영체제 캐시에서 사용하는 메모리의 양을 식별할 수 있습니다. 이 캐시에서 메모리의 용도를 변경할 수 있습니다. 메모리 부족 문제를 예측하려면 두 측정항목을 모두 확인하고 함께 해석합니다. 측정항목이 높으면 인스턴스의 메모리가 부족할 수 있습니다. 이는 커스텀 구성, 워크로드에 비해 크기가 줄어드는 인스턴스, 이러한 요소의 조합 때문일 수 있습니다. Cloud SQL 인스턴스를 확장하여 메모리 크기를 늘립니다. 인스턴스의 메모리 크기를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 메모리 크기에 있으면 데이터베이스를 여러 인스턴스로 샤딩해야 합니다. Google Cloud 콘솔에서 두 측정항목을 모니터링하는 방법에 대한 자세한 내용은 측정항목을 참조하세요.
인스턴스에 최적의 트랜잭션 ID가 있는지 확인합니다.	`Resource Type`을 `Cloud SQL Database`로 설정하고 `Metric`를 `Percentage of instance's transaction IDs consumed`로 설정하여 Google Cloud 콘솔의 측정항목 탐색기 페이지에서 인스턴스의 트랜잭션 ID 사용량을 볼 수 있습니다. 자세한 내용은 측정항목 탐색기로 차트 만들기를 참조하세요. 데이터베이스 인스턴스를 미세 조정하고 모니터링하면 청소 관련 문제를 줄이거나 방지하는 데 도움이 됩니다. 인스턴스의 트랜잭션 ID 사용을 모니터링하고 인스턴스의 워크로드에 따라 `autovacuum` 파라미터를 사용 설정하고 조정합니다. 자세한 내용은 트랜잭션 ID(TXID) 랩어라운드 보호 해결을 참조하세요.

데이터 아키텍처

권장사항	추가 정보
가능하면 큰 인스턴스를 작은 인스턴스로 분할합니다.	가능한 경우 여러 개의 작은 Cloud SQL 인스턴스를 사용하는 것이 하나의 큰 인스턴스를 사용하는 것보다 더 효과적입니다. 큰 모놀리식 인스턴스를 관리하면 작은 인스턴스들의 그룹을 관리할 때 발생하지 않는 문제가 발생합니다.
너무 많은 데이터베이스 테이블을 사용하지 마세요.	인스턴스의 테이블 수를 10,000개 미만으로 유지합니다. 데이터베이스 테이블이 너무 많으면 데이터베이스 업그레이드 시간에 영향을 줄 수 있습니다.

애플리케이션 구현

권장사항	추가 정보
연결 풀링 및 지수 백오프와 같은 우수한 연결 관리 권장사항을 사용하세요.	이러한 방법을 사용하면 애플리케이션의 리소스 사용이 향상되고 Cloud SQL 연결 한도를 유지할 수 있습니다. 자세한 내용과 코드 샘플은 데이터베이스 연결 관리를 참조하세요.
유지보수 기간 중 언제든지 발생할 수 있는 유지보수 업데이트에 대한 애플리케이션의 응답을 테스트하세요.	셀프서비스 유지보수를 통해 유지보수 업데이트를 시뮬레이션하세요. 유지보수 중에 인스턴스를 잠시 사용할 수 없게 되고 기존 연결이 끊어집니다. 유지보수 출시 테스트를 통해 애플리케이션이 예약된 유지보수를 처리하는 방법과 시스템이 복구되는 시간에 대해 보다 잘 이해할 수 있습니다.
언제든지 발생할 수 있는 장애 조치에 대한 애플리케이션의 응답을 테스트하세요.	Google Cloud 콘솔, gcloud CLI 또는 API를 사용하여 장애 조치를 수동으로 시작할 수 있습니다. 장애 조치 시작을 참조하세요.
대규모 트랜잭션은 피하세요.	트랜잭션을 작고 짧게 유지하세요. 대규모 데이터베이스 업데이트가 필요한 경우 하나의 큰 트랜잭션이 아니라 여러 건의 작은 트랜잭션으로 수행하세요.
Cloud SQL 인증 프록시를 사용하는 경우 최신 버전을 사용하세요.	Cloud SQL 인증 프록시를 최신 상태로 유지하기를 참조하세요.

데이터 가져오기 및 내보내기

권장사항	추가 정보
서버리스 내보내기를 사용합니다.	서버리스 내보내기는 내보내기 작업을 임시 인스턴스로 오프로드하므로 기본 인스턴스가 계속 쿼리를 처리하고 일반 성능으로 작업을 수행할 수 있습니다. 데이터 내보내기가 완료되면 임시 인스턴스가 자동으로 삭제됩니다.
작은 인스턴스 크기의 가져오기 속도를 높이세요.	작은 인스턴스의 경우 큰 데이터 세트를 가져올 때 성능을 개선하기 위해 임시로 인스턴스의 CPU와 RAM을 증가시킬 수 있습니다.
Cloud SQL로 가져올 데이터를 내보내는 경우 적절한 절차를 사용하세요.	외부 관리 데이터베이스 서버에서 데이터 내보내기를 참조하세요.

백업 및 복구

권장사항	추가 정보
적절한 Cloud SQL 기능을 사용하여 데이터를 보호하세요.	데이터 중복 및 보호 기능을 제공하는 방법은 백업, point-in-time recovery, 내보내기입니다. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다. 백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 백업에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다. point-in-time recovery는 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다. point-in-time recovery는 항상 새로운 인스턴스를 만듭니다. 즉, 기존 인스턴스에는 point-in-time recovery를 수행할 수 없습니다. Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 선택한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다.
트랜잭션(바이너리) 로그 보관을 고려하여 인스턴스의 크기를 조정합니다.	데이터베이스에 대한 쓰기 작업이 많으면 대량의 트랜잭션(바이너리) 로그가 생성되어 상당한 디스크 공간을 사용할 수 있고 자동으로 스토리지를 늘리기 위해 사용 설정된 인스턴스의 디스크 증가로 이어질 수 있습니다. 트랜잭션 로그 보관을 고려하여 인스턴스 스토리지의 크기를 조정하는 것이 좋습니다.
인스턴스와 백업이 실수로 삭제되지 않도록 보호하세요.	Google Cloud 콘솔 또는 Terraform을 통해 만든 Cloud SQL 인스턴스는 실수로 인한 삭제 방지를 기본적으로 사용 설정합니다. 추가 보호를 위해 Cloud SQL에서 내보내기 기능을 사용하여 데이터를 내보내세요. Cloud Scheduler를 REST API와 함께 사용하여 내보내기 관리를 자동화하세요. 고급 시나리오의 경우 자동화를 위해 Cloud Scheduler와 Cloud Run 함수를 함께 사용합니다.

권장사항

추가 정보

적절한 Cloud SQL 기능을 사용하여 데이터를 보호하세요.

데이터 중복 및 보호 기능을 제공하는 방법은 백업, point-in-time recovery, 내보내기입니다. 이러한 방법들은 각각 다른 시나리오에서 서로 보호하고 강력한 데이터 보호 전략을 통해 상호 보완합니다.

백업은 간편하며 인스턴스의 데이터를 백업을 수행할 당시의 상태로 복원할 수 있습니다. 그러나 백업에는 몇 가지 제한사항이 있습니다. 인스턴스를 삭제하면 백업도 삭제됩니다. 단일 데이터베이스 또는 테이블은 백업할 수 없습니다. 인스턴스가 위치하는 지역을 사용할 수 없는 경우에는 사용 가능한 리전에서도 해당 백업에서 인스턴스를 복원할 수 없습니다.

point-in-time recovery는 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다. point-in-time recovery는 항상 새로운 인스턴스를 만듭니다. 즉, 기존 인스턴스에는 point-in-time recovery를 수행할 수 없습니다.

Cloud Storage에 데이터를 다시 만들 때 사용할 수 있는 외부 파일이 만들어지므로 내보내기를 만드는 데 시간이 더 오래 걸립니다. 내보내기는 인스턴스를 삭제해도 영향을 받지 않습니다. 또한 선택한 내보내기 형식에 따라 단일 데이터베이스 또는 테이블만 내보낼 수도 있습니다.

트랜잭션(바이너리) 로그 보관을 고려하여 인스턴스의 크기를 조정합니다.

데이터베이스에 대한 쓰기 작업이 많으면 대량의 트랜잭션(바이너리) 로그가 생성되어 상당한 디스크 공간을 사용할 수 있고 자동으로 스토리지를 늘리기 위해 사용 설정된 인스턴스의 디스크 증가로 이어질 수 있습니다. 트랜잭션 로그 보관을 고려하여 인스턴스 스토리지의 크기를 조정하는 것이 좋습니다.

인스턴스와 백업이 실수로 삭제되지 않도록 보호하세요.

Google Cloud 콘솔 또는 Terraform을 통해 만든 Cloud SQL 인스턴스는 실수로 인한 삭제 방지를 기본적으로 사용 설정합니다.

추가 보호를 위해 Cloud SQL에서 내보내기 기능을 사용하여 데이터를 내보내세요. Cloud Scheduler를 REST API와 함께 사용하여 내보내기 관리를 자동화하세요. 고급 시나리오의 경우 자동화를 위해 Cloud Scheduler와 Cloud Run 함수를 함께 사용합니다.

미세 조정 및 모니터링

데이터베이스 인스턴스를 미세 조정하고 모니터링하는 것은 청소 관련 문제를 줄이거나 방지하는 데 도움이 됩니다.

VACUUM 작업마다 잠금 수준(표준 VACUUM 및 VACUUM FULL)이 다릅니다. VACUUM FULL 옵션은 더 많은 디스크 공간을 회수할 수 있지만 테이블을 독점적으로 잠그고 느리게 실행됩니다. 대신 프로덕션 데이터베이스 작업과 동시에 실행될 수 있는 VACUUM의 표준 형식을 사용합니다. VACUUM 작업을 사용하면 SELECT, INSERT, UPDATE, and DELETE와 같은 명령어는 계속 정상적으로 작동합니다. VACUUM 작업이 진행 중인 상태에서는 ALTER TABLE과 같은 명령어가 있는 테이블 정의를 수정할 수 없습니다.

다음은 VACUUM 작업을 완료하는 데 걸리는 시간을 단축하는 데 유용할 수 있는 몇 가지 권장사항입니다.

시스템 메모리와 maintenance_work_mem를 늘립니다. 이렇게 하면 각 반복에서 더 많은 튜플을 일괄 처리하고 최대한 빠르게 작업을 완료합니다. 자동 청소가 실행될 때 최대 autovacuum_max_workers배까지 이 메모리가 할당될 수 있으므로 기본값을 너무 높게 설정하지 않도록 주의하세요.
VACUUM 작업은 다수의 미리 쓰기 로그(WAL) 레코드를 생성합니다. 이 인스턴스에 구성된 복제본이 없는 경우와 같이 WAL 레코드 수를 줄일 수 있으면 작업은 더 빠르게 완료됩니다.
고정된 튜플이 없기 때문에 테이블이 20억 트랜잭션 ID 한도에 도달한 경우 단일 사용자 모드에서 수행되는 작업량을 줄여보세요. 가능한 한 가지 옵션은 vacuum_freeze_min_age=1,000,000,000(기본값 50,000,000보다 높은 허용되는 최댓값)을 설정하는 것입니다. 이 새로운 값은 고정된 튜플 수를 최대 2배까지 줄입니다.
PostgreSQL 버전 12.0 이상은 색인 항목을 삭제하지 않고도 삭제 및 VACUUM 작업을 지원합니다. 색인 삭제에 전체 색인 스캔이 필요하고 색인이 여러 개 있는 경우 총 시간은 색인 크기에 따라 달라지므로 이는 매우 중요합니다.
색인 크기가 크면 색인 스캔에 상당한 시간을 소비하므로 INDEX_CLEANUP OFF를 사용하여 테이블 데이터를 빠르게 삭제하고 고정하는 것이 좋습니다. 12.0 이전의 PostgreSQL 버전은 색인 수를 미세 조정해야 합니다. 즉, 중요하지 않은 색인이 있는 경우 NON-CRITICAL 색인을 삭제하여 청소 작업을 가속화하면 도움이 될 수 있습니다.