일반 권장사항

Cloud SQL 인스턴스는 이전 작업을 완료할 때까지 새로운 작업 요청을 수락하지 않습니다. 조기에 새로운 작업을 시작하려고 시도하면 작업 요청에 실패합니다. 인스턴스 다시 시작도 여기에 포함됩니다.

Google Cloud 콘솔의 인스턴스 상태에는 작업 실행 여부가 반영되지 않습니다. 녹색 체크표시는 인스턴스가 RUNNABLE 상태인 것만 나타냅니다. 작업 실행 여부를 확인하려면 작업 탭으로 이동하여 최근 작업 상태를 확인합니다.

스토리지 자동 증가 사용 설정 인스턴스 설정이 중지되었거나 스토리지 자동 증가 한도가 사용 설정된 경우 Cloud SQL이 수행할 수 있는 중요한 데이터베이스 유지보수 작업을 수용할 수 있도록 적어도 20%의 가용 공간이 있어야 합니다.

사용 가능한 디스크 공간이 20% 미만일 때 알림을 받으려면 기준점 초과 위치와 .8 값을 사용해 디스크 사용률 측정항목에 대한 측정항목 기반 알림 정책을 만듭니다. 자세한 내용은 측정항목 기반 알림 정책 만들기를 참조하세요.

Google Cloud 콘솔의 인스턴스 세부정보 페이지에서 인스턴스가 사용하고 있는 가용 CPU 비율을 확인할 수 있습니다. 자세한 내용은 측정항목을 참조하세요. 또한 측정항목 기준점 알림 정책 만들기를 사용하여 CPU 사용량을 모니터링하고 지정된 기준에 도달할 때 알림을 받을 수 있습니다.

사용률이 초과되지 않도록 인스턴스의 CPU 수를 늘릴 수 있습니다. CPU를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 CPU 수에 도달한 경우에는 데이터베이스를 여러 인스턴스로 샤딩해야 합니다.

메모리 소진의 징후를 찾을 때는 주로 usage 측정항목을 사용해야 합니다. 메모리 부족 오류를 방지하려면 이 측정항목이 90% 미만으로 유지되는 것이 좋습니다.

또한 total_usage 측정항목을 사용하여 데이터베이스 컨테이너가 사용하는 메모리와 운영체제 캐시에서 할당한 메모리 등 Cloud SQL 인스턴스가 사용하는 가용 메모리 비율을 관찰할 수도 있습니다.

두 측정항목의 차이를 관찰하면 프로세스에서 사용하는 메모리의 양과 운영체제 캐시에서 사용하는 메모리의 양을 식별할 수 있습니다. 이 캐시에서 메모리의 용도를 변경할 수 있습니다.

메모리 부족 문제를 예측하려면 두 측정항목을 모두 확인하고 함께 해석합니다. 측정항목이 높으면 인스턴스의 메모리가 부족할 수 있습니다. 이는 커스텀 구성, 워크로드에 비해 크기가 줄어드는 인스턴스, 이러한 요소의 조합 때문일 수 있습니다.

Cloud SQL 인스턴스를 확장하여 메모리 크기를 늘립니다. 인스턴스의 메모리 크기를 변경하려면 인스턴스를 다시 시작해야 합니다. 인스턴스가 이미 최대 메모리 크기에 있으면 데이터베이스를 여러 인스턴스로 샤딩해야 합니다. Google Cloud 콘솔에서 두 측정항목을 모니터링하는 방법에 대한 자세한 내용은 측정항목을 참조하세요.

• vCPU: 40
• 메모리: 262144 MB
• MAXDOP: 8
• 동시 로드 비용 기준점: 120
• tempdb 파일: 8. 자동 증가를 방지하도록 미리 크기가 지정되었습니다.
• 사용자 데이터베이스 파일: 자동 증가가 64-128MB로 설정됩니다. 자동 증가를 방지하도록 미리 크기가 지정되었습니다.
• 스토리지: 최적 IOPS를 위한 >= 4TB

다양한 I/O 유형 및 크기를 테스트합니다. SQL Server에서 시작되는 영구 디스크 스토리지에 수행되는 I/O 크기는 IOPS 및 처리량에 영향을 줍니다. IOPS 한도 또는 처리량 한도에 도달하면 SQL Server 워크로드가 조정됩니다. Cloud SQL에서 사용되는 스토리지 유형은 고성능 엔터프라이즈급 워크로드에 적합한 PD SSD입니다.

다음과 같이 성능을 극대화하도록 VM을 맞춤설정합니다.

• 4TB 이상의 디스크 크기는 더 많은 처리량 및 IOPS를 제공합니다.
• vCPU가 높을수록 더 많은 IOPS 및 처리량을 제공합니다. 더 높은 vCPU를 사용할 때는 함께 증가할 수 있는 동시 로드를 위한 DB 대기 시간을 모니터링하세요.
• 최적 성능을 위해 더 높은 I/O 큐 깊이를 얻을 수 있도록 I/O를 병렬로 실행합니다.

요구사항에 적합한 증분 값을 사용해서 백분율 대신 MB로 autogrow를 설정합니다. 또한 autogrowth가 적용되기 전 증가를 사전에 관리합니다.

또한 데이터베이스 및 인스턴스에 공간이 부족할 때 Cloud SQL이 저장공간을 추가할 수 있도록 Cloud SQL 스토리지 자동 증가 사용 설정 기능이 사용 설정되었는지 유의합니다.

• 데이터베이스를 클론하고 클론 데이터베이스에서 DBCC CHECKDB를 실행합니다.
• 백업을 다른 인스턴스로 복원한 다음 복원된 인스턴스의 데이터베이스에서 DBCC CHECKDB를 실행합니다. 인스턴스 복원에 대한 자세한 내용은 인스턴스 복원을 참조하세요.

다음 코드 스니펫을 사용하여 데이터베이스에서 DBCC CHECKDB를 실행합니다.

• (권장사항) EXTENDED_LOGICAL_CHECKS를 사용하여 DBCC CHECKDB을 실행합니다. 이는 포괄적이지만 리소스 집약적인 검사입니다.

        USE DATABASE_NAME
        DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
        DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
        

• PHYSICAL_ONLY로 DBCC CHECKDB를 실행합니다.

        USE DATABASE_NAME
        DBCC CHECKDB WITH PHYSICAL_ONLY,
        NO_INFOMSGS, ALL_ERRORMSGS
        

인스턴스의 테이블 수를 10,000개 미만으로 유지합니다. 데이터베이스 테이블이 너무 많으면 데이터베이스 업그레이드 시간에 영향을 줄 수 있습니다.

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

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

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

Enterprise 또는 표준 SQL Server 인스턴스에서 백업 내보내기 기능을 사용할 때는 SQL Server에서 이미 고유하게 압축된 백업을 압축하려고 시도하므로, GZ 아카이브 파일 만들기를 선택하지 마세요.

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

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

이 플래그는 Cloud SQL이 내부 풀에 할당할 수 있는 메모리 양을 제한합니다.

이 플래그 값을 설정하지 않으면 Cloud SQL은 인스턴스의 RAM 크기를 기반으로 값을 자동으로 관리합니다. 또한 인스턴스 크기를 조절하면 Cloud SQL은 새 인스턴스 크기에 대한 권장사항을 충족하도록 플래그 값을 자동으로 조정합니다.

인스턴스에 이 플래그의 값을 지정하지 않는 것이 좋습니다. 값을 80%보다 크게 설정하면 메모리 부족 문제로 인해 불안정성, 성능 저하, 데이터베이스 비정상 종료가 발생할 수 있습니다.

이 플래그의 값을 관리하려면 수동으로 설정하세요. 따라서 Cloud SQL에서 자동 관리를 비활성화합니다. 인스턴스 크기를 조절하는 경우 새 크기의 권장 값과 일치하도록 값을 다시 검토해 보세요.

다음 수식을 사용하여
max server memory 데이터베이스 플래그를 설정하는 것이 좋습니다.

• OS 및 에이전트용으로 1.4GB의 메모리를 예약합니다.
• 서버의 RAM이 16GB 이하인 경우 RAM 4GB마다 1GB의 메모리를 예약합니다.
• 서버의 RAM이 16GB를 초과하는 경우 4GB의 메모리를 남겨두고 16GB를 초과하는 RAM 8GB마다 1GB의 메모리를 예약합니다.

예를 들어 인스턴스의 RAM이 104GB
(106,496MB)이면 다음을 예약합니다.

• 1.4GB 메모리: OS 및 에이전트용
• 4GB 메모리(104GB가 16GB보다 크기 때문)
• 11GB 메모리(88GB의 RAM이 16GB보다 크고, 104-16=88, 88을 8로 나눈 값은 11이므로)

이 예에서는 16.4GB의 메모리를 예약해야 합니다. 따라서 이 플래그의 값으로 89702MB
[(104-16.4) * 1024 = 89702]를 지정합니다.

다음 표에는 많이 사용되는 가상 머신(VM) 등급의 권장 값과 총 RAM 백분율이 있습니다.

인스턴스의 메모리 사용량을 모니터링하려면 다음 측정항목을 사용합니다.

• database/memory/usage
• database/sqlserver/memory/buffer_cache_hit_ratio
• database/sqlserver/memory/memory_grants_pending
• database/sqlserver/memory/page_life_expectancy

자세한 내용은 Cloud SQL 인스턴스 모니터링을 참조하세요.

이는 SQL 옵티마이저가 동시 로드를 사용하여 쿼리를 수행할 때 사용되는 기준점입니다. 5의 기본값은 너무 많은 쿼리가 병렬로 실행되도록 만들 수 있기 때문에 병렬 스레드에서 데이터베이스 대기 시간이 길어집니다. 이 유형의 경합을 줄이려면 값을 높이세요.

maxdop이 1로 설정된 경우 이 값이 무시됩니다.

동시 로드로 인한 데이터베이스 대기를 줄이려면 사용 가능한 논리적 프로세서 수와 관련된 특정 권장사항에 따라 이 값을 조정하세요. 이 옵션을 1로 설정하는 경우 성능을 신중하게 측정합니다.

계획 캐시에서 많은 수의 단일 사용 계획을 지정하지 않도록 합니다. 많은 수의 단일 사용 임시 배치를 포함하는 워크로드에 대해 계획 캐시 효율을 향상시키려면 이 옵션을 1로 설정합니다.

자동 증가될 필요가 없도록 tempdb 크기를 미리 지정합니다. tempdb의 모든 파일은 크기가 같아야 하고 파일 증가 설정이 동일해야 합니다.

tempdb 경합의 데이터베이스 대기 유형은 PAGELATCH_UP으로 표시됩니다. 경합을 줄이려면 파일을 더 추가합니다.

프로세서 수가 8이하면 논리적 프로세서와 동일한 개수의 파일을 사용합니다. 프로세서 수가 8보다 크면 8개 데이터 파일을 사용합니다. 경합이 계속되면 더 이상 경합이 없을 때까지 4의 배수로 파일 수를 늘립니다.

하지만 자주 실행되는 쿼리에 대해 예측 가능한 응답 시간이 예상되거나 통계 업데이트를 기다리는 동안 애플리케이션에서 클라이언트 요청 시간 제한이 자주 발생하는 경우에는 이 옵션을 사용 설정하고 Auto Update Statistics를 사용 중지할 수 있습니다.