MySQL용 Cloud SQL 인스턴스 설정 권장사항
자체 물리적 머신이나 가상 머신에 MySQL을 수동으로 배포하고 직접 관리하도록 선택할 수 있지만, 점점 널리 사용되는 옵션은 MySQL 관리의 많은 운영적 측면을 처리하는 클라우드 서비스 제공업체의 관리형 제품을 사용하는 것입니다.
관련 도움말
권장사항
MySQL용 Cloud SQL은 Google Cloud에서 MySQL 관계형 데이터베이스를 설정, 유지, 관리할 수 있는 완전 관리형 데이터베이스 서비스입니다. MySQL용 Cloud SQL 인스턴스를 만들 준비가 되면 UI 콘솔, gcloud CLI, Terraform, REST API를 비롯한 몇 가지 옵션을 사용할 수 있습니다. 각 경로에 대한 자세한 내용은 문서를 참조할 수 있지만 이 도움말의 목적상 인스턴스 설정을 위한 다양한 권장사항에 대해 다루므로 설명을 위해 UI를 사용할 예정입니다.
인스턴스 정보
안전한 비밀번호 선택
인스턴스와 함께 생성될 기본 'root'@'%' 데이터베이스 사용자의 비밀번호입니다. 루트 사용자를 관리자로 유지하려면 여기에서 안전한 비밀번호를 선택해야 합니다. 보안 문제의 경우 '루트' 대신 일반적이지 않은 관리자를 사용하는 것이 좋습니다. '데이터베이스 사용자 관리' 섹션을 참조하세요.
인스턴스 수준 비밀번호 정책 만들기
비밀번호 정책 기능을 사용하면 데이터베이스 보안이 강화됩니다. 이를 통해 비밀번호 길이, 복잡성, 만료, 제한된 재사용에 대한 정책을 구성할 수 있습니다. 자세한 내용은 MySQL 인스턴스 강화를 참조하세요.
데이터베이스 버전
성능 향상을 위해 8.0 고려
Cloud SQL MySQL은 여러 8.0 부 버전을 지원하며 현재 기본값은 v8.0.26입니다. 다양한 머신 유형에 대한 벤치마크 테스트에 따르면 8.0 기본 버전을 사용할 때 5.7 및 5.6 버전보다 쿼리 처리량이 더 높습니다.
프로덕션 인스턴스를 최신 GA 버전으로 전환 금지
Oracle 및 Cloud SQL의 모든 테스트 작업에도 불구하고 MySQL의 새로고침 릴리스는 복잡한 실제 시나리오로 완전히 검증되지 않았습니다. 따라서 프로덕션 인스턴스를 안정화 버전으로 유지하고 개발 및 스테이징 인스턴스를 사용하여 MySQL용 Cloud SQL에서 최신 부 버전 업그레이드를 테스트하는 것이 좋습니다.
고가용성
프로덕션 인스턴스의 여러 영역 구성
MySQL용 Cloud SQL은 고가용성 솔루션으로 두 번째 영역에 대한 자동 장애 조치를 통해 리전별 가용성을 제공합니다. 최고의 가용성을 위해 일일 백업 및 PITR(point-in-time recovery)을 자동으로 수행하도록 프로덕션 인스턴스에 대한 여러 영역 옵션을 구성합니다(자세한 내용은 '백업 일정' 섹션 참조).
머신 유형
현재 CPU/메모리 사용량을 평가하여 정보를 바탕으로 마이그레이션 결정
기존 인스턴스를 Cloud SQL로 마이그레이션할 때 현재 워크로드를 사용하면 적절한 VM 크기를 선택할 수 있습니다.
- CPU: 정상적인 워크로드 조건에서 CPU 사용량은 어떻게 되나요? 최대 워크로드의 경우는 어떨까요? 인스턴스가 CPU의 제약을 받나요, 아니면 I/O의 제약을 받나요? 사용자 또는 시스템의 CPU 비율이 비교적 높은 경우 이는 CPU의 제약을 받는 워크로드를 나타냅니다. I/O 비율이 비교적 높은 경우 이는 I/O의 제약을 받는 워크로드를 나타냅니다.
- 메모리: 마찬가지로 인스턴스의 정상적인 메모리 사용량은 어떻게 되며 최대 사용량은 어떻게 되나요?
참고로 MySQL용 Cloud SQL의 vCPU 1개는 최대 6.5GB의 메모리를 지원할 수 있습니다.
CPU 및 메모리에 20%~50%의 추가 공간 계획
일반적으로 안정적인 인스턴스에서도 계획되지 않은 급증을 흡수할 수 있도록 CPU 및 메모리에 최소 20%의 추가 공간을 계획합니다. 이는 성장하는 비즈니스에서 훨씬 더 중요합니다. 추가 50%를 고려해 보세요.
Cloud SQL을 사용하면 머신 유형을 쉽게 업그레이드할 수 있습니다. 업그레이드와 관련된 다운타임이 있습니다.
스토리지 맞춤설정
SSD를 사용하여 데이터베이스 성능 향상
MySQL용 Cloud SQL은 경제적인 스토리지 옵션으로 HDD를 제공하지만, 고성능 데이터베이스가 필요한 경우 SSD 옵션을 선택합니다. 다음은 I/O 성능을 비교한 것입니다.
스토리지 용량과 관련하여 성능과 비용을 균형 있게 조절
디스크 IOPS 및 처리량은 영구 디스크 크기와 상관관계가 있습니다. 용량이 높을수록 인스턴스 한도 내에서 더 많은 IOPS와 처리량을 제공합니다.
SSD의 경우 영역별 구성과 리전별 구성이 성능에 영향을 미칩니다. 자세한 내용은 영역별 SSD 성능 데이터와 리전별 SSD 성능 데이터 비교를 참조하세요. 여러 영역 가용성을 선택한 경우 리전별 SSD 성능 데이터를 참조하세요. 간단히 말해 읽기 IOPS와 쓰기 IOPS는 모두 1GB당 30이고 처리량은 1GB당 0.48MB입니다. 리전별 SSD의 경우 인스턴스당 쓰기 IOPS와 쓰기 처리량이 더 낮다는 점을 제외하고는 성능 데이터가 유사합니다.
Cloud SQL 인스턴스에서 지원되는 최대 스토리지 크기는 64TB입니다.
자동 스토리지 증가 사용 설정 및 디스크 증가 모니터링
Cloud SQL에는 인스턴스의 디스크 공간 부족(OOD)을 방지하는 자동 스토리지 증가 기능이 있습니다. 이 기능을 사용 설정하면 30초마다 스토리지가 확인되며 필요 시 증분 스토리지 용량이 추가됩니다.
이 기능은 OOD를 방지하는 데 효과적이지만 증가된 용량은 영구적입니다. 따라서 나중에 인스턴스 크기를 줄일 수 없습니다. 스토리지 용량을 관리하고 계획할 수 있도록 우선 디스크 크기에 대한 알림을 설정합니다.
암호화 옵션 숙지하기
Cloud SQL은 기본적으로 저장 데이터를 암호화합니다. 하지만 요구사항에 더 적합한 경우 기본 Google 관리 키 대신 고객 관리 암호화 키(CMEK)를 사용하는 옵션이 있습니다.
연결 구성
비공개 IP와 공개 IP 간의 장단점 평가
비공개 IP와 공개 IP는 네트워크상에서 기기가 사용하는 주소 유형을 나타냅니다. 비공개 IP는 공개 IP에 비해 강화된 네트워크 보안과 짧은 네트워크 지연 시간을 제공합니다. 하지만 비공개 IP를 사용하려면 API 및 IAM을 추가로 구성해야 하며, 실제로 공개 IP가 필요한 경우도 있습니다. 공개 IP를 사용해야 하지만 보안을 강화하려는 경우 승인된 네트워크를 요구하거나 Cloud SQL 인증 프록시를 사용하도록 선택할 수 있습니다.
보안 연결을 위해 Cloud SQL 인증 프록시 고려
Cloud SQL 인증 프록시는 SSL 또는 승인된 네트워크를 구성하는 대신 Cloud SQL 인스턴스에 대한 보안 액세스를 제공합니다. 애플리케이션은 로컬 환경에서 실행되고 보안 터널을 사용하여 Cloud SQL 인스턴스의 프록시 서버와 통신하는 인증 프록시 클라이언트와 통신합니다.
백업 일정 및 보관 설정
백업 및 PITR(point-in-time recovery)을 사용 설정하고 보관 정책 검토
정기적인 데이터 백업과 검증 가능한 데이터 복구는 정상적인 데이터베이스 관리에 매우 중요합니다. 이러한 관행은 데이터 손상 또는 의도하지 않은 데이터 작업과 같은 상황에서 매우 유용하며 둘 다 고가용성으로 완화할 수 없습니다.
Cloud SQL은 자동 백업, 백업 인증, PITR(point-in-time recovery)을 제공합니다. 기본적으로 사용 설정되며 여러 영역이 있는 인스턴스에 필요합니다. 자동 백업은 매일 수행되며 기본 보관 정책은 7개의 백업 사본과 7일의 바이너리 로그입니다(PITR에 필요함). 고급 옵션 섹션에서 보관 정책을 조정할 수 있습니다.
데이터베이스 플래그 구성
데이터베이스 플래그는 my.cnf 파일로 이동하는 서버 구성입니다. 구성 가능한 db 플래그 목록이 있으며, 특정 관리형 플래그는 구성할 수 없습니다. db 플래그를 검토하고 인스턴스 생성 시 적절한 값으로 구성하는 것이 좋습니다. 일부 db 플래그는 동적이 아니므로 변경할 경우 인스턴스가 다시 시작됩니다.
character_set_server 검토
MySQL용 Cloud SQL 인스턴스에서 기본 character_set_server는 v5.6 및 v5.7에서 utf8이고 v8.0에서는 utf8mb4입니다. character_set_server는 character_set_client, character_set_connection, character_set_database, character_set_results를 동일한 값으로 설정합니다. character_set_system의 경우 v8.0에서 기본값은 utf8mb3입니다.
인스턴스를 마이그레이션하고 현재 구성이 다른 문자 집합(예: latin1)을 사용하는 경우 새 인스턴스에 명시적으로 character_set_server를 설정해야 합니다.
time_zone 검토
시간대는 system_time_zone(UTC)으로 기본 설정됩니다. 다른 time_zone을 사용하려면 default_time_zone을 통해 설정합니다. 이 플래그는 시간대 오프셋(예: +08:00)과 시간대 이름(예: America/Los_Angeles)의 두 형식을 사용합니다. 시간대가 시간대 이름에 따라 정의되면 일광 절약 시간으로 자동 조정됩니다(해당하는 경우). default_time_zone 플래그는 동적이 아니며 변경하려면 db 인스턴스를 다시 시작해야 합니다.
느린 쿼리 로그 사용 설정
기본적으로 slow_query_log는 OFF로 설정되어 있습니다. 느린 쿼리 로그를 사용 설정하고 long_query_time을 애플리케이션에 적합한 임곗값으로 설정하는 것이 좋습니다. 느린 쿼리 로그는 분석 및 최적화를 위해 장기 실행 쿼리를 캡처하는 데 도움이 됩니다. 이 정보는 개별 쿼리뿐 아니라 예기치 않은 워크로드에 대한 전반적인 서버 처리량과 소급 분석에 도움이 됩니다.
InnoDB 성능에 가장 효과적인 구성입니다. 메모리에 버퍼링할 수 있는 데이터가 많을수록 서버 성능이 향상됩니다. 동시에 전역 버퍼와 스레드당 동적 버퍼를 위해 예약된 메모리가 충분해야 합니다.
Cloud SQL에서 문서에 설명된 대로 innodb_buffer_pool_size 플래그의 기본값, 최소 허용 값, 최대 허용 값은 인스턴스의 메모리에 따라 다릅니다.
적합한 innodb_buffer_pool_size에는 모든 데이터가 아니라 자주 액세스하는 데이터만 포함해야 합니다. 버퍼 풀 효율성을 반영하는 상태 변수는 Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests입니다. Innodb_buffer_pool_read_requests는 논리적 읽기 요청의 수이고 Innodb_buffer_pool_reads는 버퍼 풀에서 충족되지 않아 디스크에서 읽어야 하는 논리적 읽기의 수입니다. 데이터가 버퍼 풀에 완전히 있는 이상적인 경우 Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests의 비율은 0에 가깝습니다. 이러한 변수를 모니터링하면 InnoDB 버퍼 풀의 효율성을 파악할 수 있습니다. innodb_buffer_pool_size가 최대 허용 값이고 버퍼 풀 효율성이 적합하지 않고 애플리케이션에 쿼리 성능 문제가 있는 경우 인스턴스를 더 큰 용량의 메모리로 업그레이드하는 것이 좋습니다.
이 변수는 MySQL v5.7 및 v8.0에서는 동적인 반면 v5.6에서는 변경하려면 인스턴스를 다시 시작해야 합니다.
8.0.30 이전에는 innodb_log_file_size 및 innodb_log_files_in_group이 동적이 아니었으며 innodb_log_file_size를 변경하려면 완전히 종료해야 했습니다. 8.0.30에서 innodb_log_file_size 및 innodb_log_files_in_group을 바꾸기 위해 innodb_redo_log_capacity가 도입되었습니다.
MySQL용 Cloud SQL 인스턴스는 innodb_log_file_size=512MB, innodb_log_files_in_group=2(또는 innodb_redo_log_capacity=1GB)로 구성됩니다. 이렇게 하면 InnoDB는 디스크와 동기화하지 않고도 버퍼 풀에 더 많은 변경사항을 보관할 수 있으므로 서버 성능이 향상됩니다. 재실행 로그 파일의 용량이 클 경우 비정상 종료 복구 시간이 증가한다는 단점이 있습니다. 인스턴스의 HA 요구사항 및 설정에 따라 성능과 가용성 간에 균형을 이루어야 합니다.
일반적으로 1시간 분량의 쓰기 활동을 보관할 만큼 충분히 큰 재실행 로그 파일을 사용하는 것이 좋습니다. 이를 측정하는 한 가지 방법은 하루 동안의 Innodb_os_log_write를 관찰한 다음 innodb_log_file_size * innodb_log_files_in_group이 관찰된 최고 시간에 맞게 충분히 큰지 확인하는 것입니다.
MySQL v5.6 및 v5.7에서 innodb_log_buffer_size는 동적이 아니며 이를 변경하려면 인스턴스를 다시 시작해야 합니다. 따라서 초기화 시 설정하는 것이 가장 좋습니다.
innodb_log_buffer_size가 전체 트랜잭션을 포함할 만큼 충분히 큰 경우에는 트랜잭션 실행 중에 디스크에 대한 추가 플러싱은 없습니다. 기본적으로 innodb_log_buffer_size는 16MB로 설정되는데 이는 일반적으로 충분합니다. 그러나 대규모 트랜잭션에 더 큰 버퍼가 필요할 수 있는지 파악하려면 대규모 트랜잭션을 실행할 때 Innodb_log_waits 상태 변수를 모니터링하세요. innodb_log_buffer_size가 너무 작아서 플러시가 실행될 때까지 기다려야 하는 경우 Innodb_log_waits가 1씩 증가합니다.
상황에 맞게 동적 변수 조정
일부 성능 관련 db 플래그는 동적입니다(예: table_open_cache, thread_cache_size). 처음에는 적절한 크기를 사용하고 필요에 따라 측정값을 설정하고 조정하는 것이 좋습니다.
table_open_cache는 열린 테이블 수에 대한 것입니다. 캐시가 충분하면 테이블을 여는 시간이 줄어들어 쿼리 성능이 향상됩니다. Opened_tables 상태 변수에는 열린 테이블 수가 표시됩니다. Opened_tables가 계속 증가하면 table_open_cache를 늘리는 것이 좋습니다.
thread_cache_size는 클라이언트 연결이 해제된 후 재사용할 수 있도록 스레드를 캐싱하기 위한 것입니다. 인스턴스에 새로운 동시 연결이 많이 예상되는 경우 더 큰 크기를 설정합니다. Threads_created 상태 변수와 연결 수의 비율은 스레드 캐시의 효율성을 보여줍니다. 비율이 낮을수록 좋습니다.
스레드당 메모리 플래그를 신중하게 지정
쿼리 성능에 영향을 미치는 스레드당 메모리 버퍼가 있습니다(예: tmp_table_size, max_heap_table_size, join_buffer_size, sort_buffer_size 등). 이러한 변수에는 전역 범위와 세션 범위가 모두 포함됩니다. 전역 범위는 모든 새 연결에 대한 스레드당 값을 설정하는 반면, 세션 범위는 현재 세션의 후속 쿼리에 적용됩니다. 이와 같은 설정을 위한 메모리 용량이 클수록 쿼리 성능이 향상됩니다. 그러나 이는 동적이고 스레드당 하나 이상 할당하므로 메모리 부족(OOM) 시나리오가 발생할 수 있습니다.
통제된 방식으로 성능을 개선하려면 전역 값에 적당한 숫자를 사용하고 특정 세션에 더 큰 숫자를 예약하는 것이 가장 좋습니다.
performance_schema 고려
performance_schema는 MySQL v8.0.26 이전에는 기본적으로 OFF로 설정되어 있으므로 사용 설정하려면 다시 시작해야 합니다. Performance_schema는 다양한 계측을 사용 설정하고 서버 작업을 분석하기 위한 풍부한 데이터를 제공하지만 성능 비용과 비용 비용이 모두 발생합니다. 기본 계측은 약 5%의 성능 저하를 초래하며 이 수치는 계측이 추가됨에 따라 증가합니다. 메모리 소비가 1GB 이상으로 증가할 수 있으므로 워크로드로 계측을 벤치마킹합니다. 이 메모리 소비는 memory_summary_global_by_event_name 테이블에서 확인할 수 있습니다.
데이터베이스 사용자 관리
Cloud SQL 인스턴스를 만들면 사용 가능한 'root'@'%' 데이터베이스 사용자가 있습니다. 데이터베이스 사용자를 추가로 만들어야 할 수 있습니다.
필요한 작업에 대한 사용자 액세스 제한
사용자 액세스를 항상 최소 필요 요소로 제한합니다.
MySQL CLI를 통해 사용자를 만들 때 명시적으로 권한을 부여해야 합니다.
Cloud 콘솔을 통해 사용자를 만들면 사용자에게 'root'@'%' 사용자와 동일한 권한이 부여됩니다. MySQL v5.6 및 v5.7에서는 기본 권한에 SUPER 및 FILE 권한을 제외한 권한 부여 옵션이 있는 모든 권한이 포함됩니다. v8.0에서는 사용자에게 동적 권한이 함께 제공되며 SUPER 및 FILE 권한은 계속 제한되지만 사용자는 더 많은 관리자 역할을 사용할 수 있습니다(예: APPLICATION_PASSWORD_ADMIN, CONNECTION_ADMIN, ROLE_ADMIN, SET_USER_ID, XA_RECOVER_ADMIN). MySQL CLI를 통해 불필요한 권한을 취소해야 합니다. v8.0 인스턴스에서는 partial_revokes 변수가 사용 설정됩니다.
'root’@’%'를 특정 관리자로 바꾸기
'root'@'%' 사용자는 기본값으로 가장 인기 있는 수퍼유저이므로 해커의 표적이 되는 경우가 많습니다. 보안을 강화하려면 'root'@'%' 사용자와 동일한 권한을 갖는 자체 관리자를 만든 다음 바꾸어 사용하는 것이 좋습니다.
모니터링 설정
데이터베이스 작업 및 시스템 리소스의 다양한 측면을 모니터링하고 추적하는 것이 매우 중요합니다. 시간이 지남에 따라 인스턴스의 운영 상태를 검토하고 분석할 수 있으며 리소스 계획에도 도움이 됩니다.
- Cloud 콘솔 개요 페이지에는 핵심 측정항목 목록이 표시됩니다.
- Cloud Monitoring은 추가 측정항목을 제공합니다. DB 인스턴스에 대한 선택한 측정항목이 포함된 대시보드를 만들 수 있습니다. Cloud 콘솔의 왼쪽 상단 탐색 메뉴에서 '작업' - '모니터링'을 선택하여 Cloud Monitoring에 액세스합니다.
- 쿼리 성능 분석을 위해 Cloud SQL에서 쿼리 통계를 사용합니다. 개요 섹션에는 데이터베이스, 사용자, 클라이언트 주소별로 분할된 CPU 부하가 표시됩니다. CPU 사용량이 세분화되어 I/O 대기 및 잠금 대기도 표시합니다. 또한 쿼리 다이제스트를 기준으로 상위 쿼리가 나열됩니다. 각 쿼리 다이제스트에 대해 평균 실행 시간, 쿼리 수, 스캔 후 반환된 평균 행 수를 확인할 수 있습니다. 이러한 측정항목은 최적화할 핫스팟과 쿼리를 파악하는 데 매우 유용합니다.
- 자체 개발한 모니터링 도구 또는 서드 파티 도구를 사용하여 이를 보완할 수도 있습니다. 주요 목표는 서버 및 쿼리 최적화와 문제 해결에 모두 영향을 줄 수 있는 데이터베이스 작업을 이해하는 것입니다.
알림 설정
적절한 알림은 서버 상태에 매우 중요합니다. 메모리 부족(OOM) 또는 CPU 포화로 인한 시스템 중단과 같은 서비스 중단을 방지하는 데 도움이 됩니다.
Cloud Monitoring을 사용하면 측정항목 기반 알림을 만들 수 있습니다. 자세한 내용은 문서를 참조하세요.
다른 모니터링 도구를 사용하는 경우 알림을 구성해야 합니다.
복제본 구성
읽기를 확장하려면 읽기 복제본을 추가하는 것이 좋습니다. HAProxy, ProxySQL, 다른 부하 분산기를 사용하여 여러 읽기 복제본에 읽기를 배포할 수 있습니다.
Cloud SQL은 연쇄 복제본에서 알아볼 수 있는 연결된 복제도 지원합니다.
읽기 복제본은 기본 인스턴스와 동일한 MySQL 버전으로 생성됩니다. 복제본을 만든 후 기본 인스턴스로 업그레이드하도록 선택할 수 있습니다.
재해 복구 계획
고가용성 솔루션은 동일한 리전 내의 보조 영역에서 데이터 중복을 제공합니다. 재해가 발생하면 한 리전을 사용하지 못할 수 있습니다. 리전 간 읽기 복제본은 필요할 때 기본 인스턴스로 승격될 수 있으므로 재해 복구 계획의 강력한 리소스입니다. 자세한 내용은 문서를 참조하세요.
관련 제품 및 서비스
Google Cloud는 온프레미스 데이터 센터 사용 중지부터 SaaS 애플리케이션 실행, 핵심 비즈니스 시스템 마이그레이션에 이르기까지 비즈니스 니즈에 맞게 설계된 관리형 MySQL 데이터베이스를 제공합니다.
