이 문서에서는 Google Cloud에서 MySQL 배포를 위한 고가용성 HA)을 제공하는 여러 아키텍처를 설명합니다. HA는 기본 인프라 장애에 대한 대응하여 시스템 복원력을 측정합니다. 이 문서에서 HA는 단일 클라우드 리전 내 MySQL 클러스터의 가용성을 처리합니다.
이 문서는 전반적인 시스템 업타임을 개선하여 MySQL 데이터 계층 안정성을 높이는 방법을 알아보려는 데이터베이스 관리자, 클라우드 설계자, DevOps 엔지니어를 대상으로 합니다. 이 문서는 Compute Engine에서 MySQL을 실행한다는 가정하에 작성되었습니다. MySQL용 Cloud SQL을 사용하는 경우 이 문서는 적합하지 않습니다.
요청 또는 트랜잭션을 처리하기 위해 지속적인 상태가 필요한 시스템 또는 애플리케이션의 경우 데이터 쿼리 또는 변형 요청을 성공적으로 처리하기 위해서는 데이터 지속성 레이어를 사용할 수 있어야 합니다. 애플리케이션이 서비스 요청에 대한 데이터 계층과 상호작용해야 하는 경우 데이터 계층의 다운타임으로 인해 애플리케이션이 필요한 작업을 수행할 수 없게 됩니다.
시스템의 시스템 서비스 수준 목표(SLO)에 따라 더 높은 가용성을 제공하는 아키텍처 토폴로지가 필요할 수 있습니다. HA를 확보하는 방법에는 여러 가지가 있지만 일반적으로 중복 인프라를 프로비저닝하면 애플리케이션에서 신속하게 액세스할 수 있습니다.
이 문서에서는 다음 주제에 대해 설명합니다.
- HA 데이터베이스 개념을 이해하는 데 도움이 되도록 용어를 정의합니다.
- HA MySQL 토폴로지의 여러 가지 옵션을 이해하도록 지원합니다.
- 각 옵션에서 고려해야 할 사항을 이해하는 데 도움이 되는 상황 정보를 제공합니다.
용어
이 문서의 범위를 벗어나므로 다루지는 않지만 이해에 도움이 되는 업계 표준의 여러 용어와 개념이 있습니다.
복제. 쓰기 트랜잭션(INSERT, UPDATE 또는 DELETE)이 안정적으로 캡처 및 로깅된 후 토폴로지의 모든 데이터베이스 노드에 순차적으로 적용되는 프로세스입니다.
소스 노드. 모든 데이터베이스 쓰기는 소스 노드로 전달되어야 합니다. 소스 노드는 지속 데이터의 최신 상태가 포함된 읽기를 제공합니다.
복제본 노드. 소스 데이터베이스 노드의 온라인 사본입니다. 변경사항은 소스 노드의 복제본 노드에 거의 동기적으로 복제됩니다. 복제본 노드에서 읽을 수도 있으며 이 경우 복제 지연으로 인해 데이터가 약간 지연될 수 있습니다.
복제 지연. 트랜잭션이 복제본에 적용되는 시점과 소스 노드에 적용되는 시점 간의 차이를 나타내는 시간 측정값입니다.
업타임. 리소스가 작동하고 요청에 대한 응답을 제공할 수 있는 시간의 비율입니다.
장애 감지. 인프라 장애가 발생했는지 식별하는 프로세스입니다.
장애 조치. 백업 또는 대기 인프라(이 경우에는 복제본 노드)를 기본 인프라로 승격하는 프로세스입니다. 즉, 장애 조치 중에 복제본 노드는 소스 노드가 됩니다.
복구 시간 목표(RTO). 데이터 계층 장애 조치 프로세스가 끝날 때까지 비즈니스 관점에서 허용 가능한 실제 경과 시간입니다.
대체. 장애 조치가 발생한 후 이전 소스 노드를 복구하는 프로세스입니다.
자가 복구. 인간 운영자의 외부 작업 없이 문제를 해결하는 시스템 기능입니다.
네트워크 파티션. 토폴로지의 두 노드(예: 소스 노드와 복제본 노드)가 네트워크를 통해 서로 통신할 수 없는 조건입니다.
분할 브레인. 두 노드가 동시에 소스 노드로 간주될 때 발생하는 조건입니다.
노드 그룹. 서비스를 제공하는 컴퓨팅 리소스 작업 집합입니다. 이 문서에서 이 서비스는 데이터 지속성 계층입니다.
감시 또는 쿼럼 노드. 분할 브레인 조건이 발생할 때 노드 그룹이 수행할 작업을 결정하는 데 유용한 별도의 컴퓨팅 리소스입니다.
소스 또는 리더 선택. 감시 노드를 포함한 피어 인식 노드 그룹이 어떤 노드를 소스 노드로 설정해야 하는지 결정하는 프로세스입니다.
노드 그룹. 서비스를 제공하는 컴퓨팅 리소스 작업 집합입니다. 이 문서에서 이 서비스는 데이터 지속성 계층입니다.
상시 대기. 다른 소스 노드의 가까운 복사본을 나타내고 최소한의 다운타임으로 새 소스 노드가 될 수 있는 노드입니다.
HA 아키텍처를 고려해야 하는 경우
HA 아키텍처는 데이터 계층 다운타임에 대한 향상된 보호 기능을 제공합니다. 다운타임의 허용 범위와 다양한 아키텍처 각각의 단점을 이해하는 것이 비즈니스 사용 사례에 적합한 옵션을 선택하는 데 중요합니다.
워크로드 및 서비스의 안정성 요구사항을 충족하기 위해 향상된 데이터 계층 업타임을 제공하려는 경우 HA 토폴로지를 사용합니다. 어느 정도의 다운타임이 허용되는 환경의 경우 HA 토폴로지는 불필요한 비용과 복잡성을 수반합니다. 예를 들어 개발 또는 테스트 환경은 높은 데이터베이스 계층 가용성을 필요로 합니다.
HA 요구사항 고려
HA를 제공하려면 컴퓨팅 인프라와 스토리지 비용이 최소 두 배가 될 것으로 예상해야 하므로 비용은 중요한 고려사항입니다. 가능한 MySQL HA 옵션을 평가할 때는 다음 질문을 고려하세요.
- 어떤 서비스 또는 고객이 데이터 계층을 사용하나요?
- 작업 예산은 어느 정도인가요?
- 데이터 지속성 계층에 다운타임이 발생할 경우 비즈니스 비용은 얼마인가요?
- 프로세스가 얼마나 자동화되어야 하나요?
- 99.5%, 99.9% 또는 99.99% 등 달성하려는 가용성 수준이 어떻게 되나요?
- 얼마나 신속하게 장애 조치를 해야 하나요? RTO가 어떻게 되나요?
다음은 복구 시간에 영향을 미치기 때문에 RTO 설정 시 고려해야 하는 요소입니다.
- 중단 감지
- 보조 가상 머신(VM) 인스턴스 준비
- 스토리지 장애 조치
- 데이터베이스 복구 시간
- 애플리케이션 복구 시간
MySQL HA 아키텍처
가장 기본적인 수준에서 데이터 계층의 HA는 다음으로 구성됩니다.
- 소스 노드의 장애가 발생했는지 식별하는 메커니즘
- 복제본 노드가 소스 노드로 승격되는 경우 장애 조치를 수행하는 프로세스
- 애플리케이션 요청이 새 소스 노드에 도달할 수 있도록 쿼리 라우팅을 변경하는 프로세스
- 소스 및 복제본 노드를 사용하여 원래 토폴로지로 대체할 수 있는 수단(선택사항)
이 문서에서는 다음 세 가지 HA 아키텍처에 대해 설명합니다.
이러한 각 아키텍처는 인프라 장애 외에도 예기치 않은 영역 장애 발생 시 다운타임을 최소화하는 데 도움이 될 수 있습니다. DNS(도메인 이름 시스템) 변경과 함께 이러한 아키텍처를 사용하면 멀티 리전 HA를 제공하여 리전 서비스 중단을 방지할 수 있지만 이 문서에서는 다루지 않습니다.
리전 Persistent Disk를 사용하는 HA
데이터 계층의 HA는 항상 특정 데이터 복제 유형을 활용합니다. 가장 간단한 복제 유형은 바로 관리할 필요가 없는 복제입니다.
Compute Engine에서 리전 Persistent Disk 스토리지 옵션을 사용하면 리전의 두 영역 간에 동기 데이터 복제를 제공하는 블록 스토리지 기기를 프로비저닝할 수 있습니다. 리전 Persistent Disk는 Compute Engine에서 HA 서비스를 구현하기 위한 강력한 기본 구성 요소를 제공합니다.
다음 다이어그램은 리전 Persistent Disk를 사용하는 HA의 아키텍처를 보여줍니다.
인프라 장애 또는 영역 장애로 인해 소스 노드 VM 인스턴스를 사용할 수 없게 되면 리전 Persistent Disk를 동일한 리전의 백업 영역에 있는 VM 인스턴스에 강제로 연결할 수 있습니다.
이 태스크를 처리하려면 다음 중 하나를 수행해야 합니다.
- 공유 리전 Persistent Disk에 액세스할 수 있는 백업 영역에서 다른 VM 인스턴스를 시작합니다.
- 백업 영역에서 상시 대기 VM 인스턴스를 유지합니다. 상시 대기 VM 인스턴스는 실행 중인 VM 인스턴스로, 사용 중인 인스턴스와 동일합니다. 리전 Persistent Disk를 연결한 후에 데이터베이스 엔진을 시작할 수 있습니다.
데이터 서비스 중단이 즉시 식별된 경우 강제 연결 작업은 일반적으로 1분 이내에 완료됩니다. 즉, 분 단위로 측정되는 RTO를 사용할 수 있습니다.
비즈니스에서 서비스 중단을 감지한 후 전달하는 데 필요한 추가 다운타임을 허용할 수 있고 장애 조치를 수동으로 수행할 경우, 프로세스를 자동화할 필요가 없습니다.
RTO 허용 범위가 낮으면 감지 및 장애 조치 프로세스를 자동화할 수 있습니다. 이 아키텍처를 자동화하는 경우 장애 조치 및 대체 프로세스에 몇 가지 특이 사례가 있기 때문에 시스템이 더 복잡해집니다. 이 아키텍처의 완전 자동 구현에 대한 자세한 내용은 Cloud SQL 고가용성 구성을 참조하세요.
장점
리전 Persistent Disk를 사용하여 HA를 확보하면 다음과 같은 기능으로 여러 이점을 얻을 수 있습니다.
- 이 아키텍처는 기본 영역 서버 인프라 장애, 단일 영역 블록 스토리지 성능 저하 또는 전체 영역 장애 등 여러 장애 모드에 대한 동시 보호 기능을 제공합니다.
- 리전 Persistent Disk는 Google Cloud에서 완전 관리형으로 지원하는 지속적인 동기식 블록 수준 데이터 복제를 제공하므로 애플리케이션 또는 데이터베이스 레이어 복제가 필요하지 않습니다. 리전 Persistent Disk는 오류 및 속도 저하를 자동으로 감지하고, 복제 모드를 전환하고, 한 영역에만 복제된 데이터를 포착합니다.
- 기본 영역에 스토리지 문제가 있는 경우 리전 Persistent Disk는 보조 영역에서 읽기를 자동으로 수행합니다. 이 작업으로 읽기 지연 시간이 증가할 수 있지만 애플리케이션은 수동 작업 없이 계속 작동할 수 있습니다.
고려사항
이 아키텍처의 제한사항은 이 토폴로지의 단일 리전 특성과 다음과 같은 리전 Persistent Disk의 몇 가지 고유한 제약조건과 관련이 있습니다.
- 리전 Persistent Disk는 하나의 데이터베이스에만 마운트할 수 있습니다. 대기 데이터베이스 VM 인스턴스가 실행 중인 경우에도 이 인스턴스를 사용하여 데이터베이스 읽기를 수행할 수 없습니다.
- 이 아키텍처의 기반이 되는 기술은 동일한 리전의 영역 간 복제만 허용합니다. 따라서 이 아키텍처만 사용하는 경우에는 리전 장애 조치를 사용할 수 없습니다.
- 리전 Persistent Disk의 쓰기 처리량은 영역 Persistent Disk의 절반입니다. 처리량 제한이 필요 허용 범위 내에 있는지 확인해야 합니다.
- 리전 Persistent Disk의 쓰기 지연 시간은 영역 Persistent Disk보다 약간 높습니다. 워크로드를 테스트하여 쓰기 성능이 요구사항을 충족하는지 확인하는 것이 좋습니다.
- 장애 발생 도중 및 컷오버 종료 시 리전 Persistent Disk를 대기 영역 VM에 강제로 연결해야 합니다. 강제 연결 작업은 일반적으로 1분 이내에 실행되므로 RTO를 평가할 때 이 시간을 고려해야 합니다.
- RTO 추정 시 리전 Persistent Disk의 강제 연결에 필요한 시간과 상시 연결 디스크의 VM 파일 시스템 감지에 필요한 시간을 고려해야 합니다.
대기 및 감시 노드를 사용하는 HA
자동 장애 조치를 원하는 경우 다른 아키텍처가 필요합니다. 한 가지 옵션은 2개 이상의 데이터베이스 노드 그룹을 배포하고, 데이터베이스 비동기 복제를 구성하고, 감시 노드를 실행하여 소스 노드를 선택하는 동안 쿼럼에 도달할 수 있도록 지원하는 것입니다.
소스 데이터베이스 노드는 쓰기 트랜잭션을 처리하고 읽기 쿼리를 제공합니다. 데이터베이스 복제 프로세스는 온라인 상시 대기 복제본 노드로 변경사항을 전송합니다.
감시 노드는 작은 가상 머신일 수 있으므로 소스 노드 선출 시 대부분의 그룹을 사용할 수 있도록 저렴한 비용의 메커니즘을 제공합니다.
그룹 노드는 다른 그룹 노드의 상태를 지속적으로 평가합니다. 이러한 상태 확인 시 몇 초마다 사용되는 신호는 다른 그룹 노드의 상태를 평가하는 데 사용되므로 하트비트라고 합니다. 비정상적인 소스 데이터베이스 노드를 빠르게 식별해야 상시 대기의 장애 조치를 시작할 수 있으므로 데이터베이스 노드 상태를 신속하게 평가하는 것이 중요합니다.
노드 그룹 쿼럼은 클러스터를 제대로 시작하거나 계속 실행하기 위해 활성 클러스터 멤버십에 속해야 하는 투표 요소의 수에 따라 결정됩니다. 소스 데이터베이스 노드 선출 시 노드 그룹이 쿼럼에 도달하려면 그룹 내 노드 중 과반수가 참여해야 합니다. 분할 브레인 조건을 방지하기 위해 대부분의 요건은 네트워크 파티션이 있는 경우 투표할 수 있는 노드를 두 개의 투표 그룹이 동시에 갖지 못하도록 합니다.
대부분의 그룹은 (n+1)/2개의 노드로 구성됩니다. 여기서 n은 그룹의 총 노드 수입니다. 예를 들어 그룹에 노드가 3개 있는 경우 2개 이상의 노드가 소스 노드 선출에 대해 작동해야 합니다. 그룹에 노드가 5개 있는 경우 노드가 3개 이상 필요합니다.
노드 그룹의 하위 그룹 간 통신을 방지하는 네트워크 파티션이 있는 경우 그룹의 크기는 홀수 개의 노드로 지정됩니다. 그룹이 짝수인 경우 두 하위 그룹이 과반수를 차지하지 못할 가능성이 높습니다. 그룹 크기가 홀수인 경우 하위 그룹 중 하나가 과반수이거나 어떤 그룹도 과반수가 아닐 가능성이 더 높습니다.
다음 다이어그램은 정상 노드 그룹과 성능이 저하된 노드 그룹을 비교합니다.
이 다이어그램에서는 2개의 노드 그룹 즉, 정상 작동하는 노드 그룹과 성능이 저하된 노드 그룹을 보여줍니다. 제대로 작동하는 정상 노드 그룹에는 세 그룹 구성원이 있습니다. 이 상태에서 소스 및 복제본 데이터베이스 노드는 예상 목표를 제공합니다. 이 노드 그룹에 필요한 쿼럼은 2개의 노드입니다.
성능이 저하된 노드 그룹은 인프라 장애로 인해 소스 노드 하트비트가 더 이상 전송되지 않는 상태를 보여줍니다. 이 상태는 소스 데이터베이스 노드 인스턴스 장애의 결과이거나 소스 노드가 계속 실행 중일 수도 있습니다. 또는 네트워크 파티션으로 인해 소스 노드와 그룹의 다른 노드 간의 통신이 차단되었을 수 있습니다.
원인에 관계없이 복제본 및 감시 노드는 소스 노드가 더 이상 정상이 아니라고 판단합니다. 이 시점에서 대부분의 그룹은 소스 노드 선출을 수행하고, 소스 노드가 될 상시 대기 노드를 결정하고, 장애 조치를 시작합니다.
다음 다이어그램은 감시 노드 아키텍처의 데이터베이스 트랜잭션, 복제, 하트비트 흐름을 보여줍니다.
앞의 다이어그램에서 이 HA 아키텍처는 장애 조치 시 프로덕션 쓰기를 빠르게 시작하기 위해 상시 대기 복제본 노드를 사용합니다. 장애 조치(예: 소스 노드 승격) 메커니즘은 그룹의 데이터베이스 노드에서 수행됩니다.
이 아키텍처를 구현하려면 다음 두 프로젝트를 고려하세요.
- MySQL 그룹 복제는 HA 토폴로지를 만들 수 있는 MySQL용 오픈소스 플러그인입니다.
- Galera Cluster 및 Percona XtraDB Cluster는 고가용성을 제공할 수 있는 다른 오픈소스 옵션입니다.
장점
이동하는 부분이 있는 상시 대기 아키텍처는 간단히 배포할 수 있으며 다음과 같은 몇 가지 이점을 제공합니다.
- 추가 저비용 감시 노드 하나만 있으면 완전한 자동 장애 조치가 제공됩니다.
- 이 아키텍처는 단기적인 장애(예: 시스템 재부팅)를 처리하는 것만큼 손쉽게 장기적인 인프라 장애를 해결할 수 있습니다.
- 일부 관련 복제 지연 시간이 있는 멀티 리전 HA가 제공됩니다.
고려사항
장애 조치는 자동으로 적용되지만 다음 운영 작업은 직접 수행해야 합니다.
- 소스 노드와 복제본 노드 간의 복제를 관리합니다.
- 감시 노드를 관리합니다.
- 부하 분산기를 사용하여 연결 라우팅을 배포 및 관리합니다.
- 이 문서의 범위에 속하지 않는 애플리케이션 로직을 변경하지 않고 사용하면 복제본 노드로 읽기를 전달할 수 없습니다.
Orchestrator 및 ProxySQL을 사용하는 HA
오픈소스 구성요소인 Orchestrator 및 ProxySQL을 결합하는 경우 중단을 감지하며 장애가 발생한 소스 노드에서 새로 승격된 정상 복제본 노드로 트래픽을 자동으로 장애 조치 처리할 수 있는 아키텍처를 사용할 수 있습니다.
또한 적절한 읽기 노드 또는 읽기 및 쓰기 노드로 쿼리를 투명하게 라우팅하여 안정적인 상태 데이터 계층의 성능을 향상할 수 있습니다.
Orchestrator는 오픈소스 MySQL 복제 토폴로지 관리자 및 장애 조치 솔루션입니다. 이 소프트웨어를 사용하면 복잡한 복제 토폴로지를 감지, 쿼리, 리팩터링할 수 있으며 안정적인 장애 감지, 지능형 복구, 승격 기능을 제공합니다.
ProxySQL은 MySQL용으로 가용성이 높은 고성능 오픈소스 데이터베이스 프로토콜 인식 프록시입니다. ProxySQL은 수십만 개의 백엔드 서버에서 수백만 개의 연결로 확장됩니다.
다음 다이어그램은 Orchestrator와 ProxySQL이 결합된 아키텍처를 보여줍니다.
이 아키텍처에서는 앞의 다이어그램에 표시된 것처럼 데이터베이스 결합 트래픽이 내부 부하 분산기에서 중복 ProxySQL 인스턴스로 라우팅됩니다. 이러한 인스턴스는 ProxySQL 구성에 따라 쓰기용 또는 읽기용 데이터베이스 인스턴스로 트래픽을 라우팅합니다.
Orchestrator는 다음과 같은 장애 감지 및 복구 단계를 제공합니다.
- Orchestrator가 소스 데이터베이스 노드를 사용할 수 없다고 판단합니다.
- 모든 복제본 노드는 쿼리를 통해 소스 노드의 상태에 대한 두 번째 의견을 제공합니다.
- 복제본 노드가 소스 노드를 사용할 수 없다는 일관된 평가를 제공하면 장애 조치가 진행됩니다.
- 토폴로지에서 정의한 대로 승격된 노드는 장애 조치 중에 새로운 소스 노드가 됩니다.
- 장애 조치가 완료되면 Orchestrator는 토폴로지에 따라 올바른 수의 새로운 복제 노드가 프로비저닝되도록 합니다.
영역 A의 소스 데이터베이스와 보조 영역의 데이터베이스 복제본 간의 지속적인 복제는 소스 노드로 라우팅되는 쓰기를 통해 복제본을 최신 상태로 유지합니다. Orchestrator가 기본 하트비트를 계속 전송하여 소스 및 복제본 데이터베이스의 상태를 확인합니다. Orchestrator 애플리케이션 상태는 별도의 Cloud SQL 데이터베이스에서 유지됩니다. 토폴로지를 변경해야 하는 경우 Orchestrator는 데이터베이스에 명령어를 전송할 수도 있습니다.
ProxySQL은 장애 조치 완료 시 새로운 소스 및 복제본 노드로 트래픽을 적절하게 라우팅합니다. 서비스는 부하 분산기의 IP 주소를 사용하여 데이터 계층을 계속 처리합니다. 가상 IP 주소는 이전 소스 노드에서 새 소스 노드로 원활하게 전환됩니다.
장점
아키텍처 구성요소 및 자동화는 다음과 같은 이점을 제공합니다.
- 이 아키텍처에서 사용되는 소프트웨어는 복제 토폴로지 그래프, 쿼리 트래픽 가시성 등 다양한 관측 가능성 기능을 제공합니다.
- ProxySQL 및 Orchestrator는 자동 복제본 승격 및 장애 조치를 제공합니다.
- 복제본 승격 정책을 자유롭게 구성할 수 있습니다. 다른 HA 구성과 달리 장애 조치 발생 시 특정 복제본 노드를 소스 노드로 승격하도록 선택할 수 있습니다.
- 장애 조치 후 새 복제본은 토폴로지에 따라 선언적으로 프로비저닝됩니다.
- ProxySQL은 구성된 정책에 따라 적절한 복제본 및 소스 노드로 읽기 및 쓰기 요청을 투명하게 라우팅하므로 부하 분산 면에서 추가적인 이점을 제공합니다.
고려사항
이 아키텍처는 다음과 같은 고려사항으로 인해 운영 부담을 높이고 추가 호스팅 비용을 발생시킵니다.
- Orchestrator와 ProxySQL을 모두 배포하고 유지해야 합니다.
- Orchestrator에는 상태 유지를 위한 별도의 데이터베이스가 필요합니다.
- Orchestrator와 ProxySQL이 모두 HA에 맞게 설정되어야 하므로 구성과 배포 복잡성이 증가합니다.
또한 Orchestrator는 다중 소스 복제와 모든 유형의 병렬 복제를 지원하지 않으며 Galera 또는 Percona XtraDB와 같은 클러스터링 소프트웨어와 결합할 수 없습니다. 현재 제한사항에 대한 자세한 내용은 Orchestrator FAQ를 참조하세요.
다음 단계
- Cloud SQL 고가용성 구성 알아보기
- 리전 Persistent Disk를 사용하는 고가용성 옵션 자세히 알아보기
- MySQL 그룹 복제 문서 검토
- Galera 클러스터 또는 관련 Percona XtraDB 클러스터 알아보기
- Orchestrator 문서 검토
- ProxySQL 자세히 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기