이 참조 아키텍처는 Google Distributed Cloud(GDC) 에어 갭에서 고가용성의 고객 관리형 MySQL 8.4 데이터베이스를 배포하고 운영하기 위한 개념적 프레임워크를 제공합니다. 이를 통해 엔터프라이즈 및 사전 체험판 고객은 강력한 멀티 영역 가상 머신(VM) 설정을 사용하여 중요한 데이터베이스 워크로드를 안정적으로 유지할 수 있습니다.
GDC 에어 갭은 영역 간 Kubernetes 확장 클러스터를 지원하지 않으므로 이 아키텍처는 3개의 가용성 도메인에 배포된 전용 VM에 전적으로 의존하여 지속적인 운영을 보장하고 데이터 손실 없이 전체 영역 장애를 견뎌냅니다.
특징 및 기능
- 멀티 영역 복원력: 단일 인프라 영역 장애로부터 보호하기 위해 3개의 개별 가용성 영역에 배포된 복원력이 뛰어난 3노드 구성입니다.
- 자동화된 고가용성 및 합의: Paxos 기반 합의 클러스터링에 그룹 복제를 사용하여 스플릿 브레인 시나리오 없이 자동 장애 감지, 노드 합의, 전역 데이터 동기화를 제공합니다.
- 지능형 트래픽 라우팅: 공동 배치된 MySQL 라우터 인스턴스가 연결 라우팅을 관리합니다. 라우터는 쓰기 작업(예: 포트 6446)을 활성 기본 노드로 엄격하게 전달하고 동기화된 복제본 간에 읽기 작업(예: 포트 6447)을 부하 분산합니다.
- 전역 부하 분산: 기본 제공되는 GDC 전역 L4 부하 분산기와 통합되어 클라이언트 애플리케이션에 단일의 안정적인 가상 IP(VIP)를 제공하고 기본 노드 토폴로지를 추상화합니다.
아키텍처 원칙
- 정족수 기반 합의: 엄격한 데이터 일관성을 우선시합니다. 그룹 복제는 다수 합의가 필요한 Paxos 기반 모델을 적용하여 네트워크 파티션 중에 데이터 손실 또는 스플릿 브레인 위험을 제거합니다.
- 관심사 분리: 데이터베이스 엔진 및 합의 레이어(그룹 복제)를 클라이언트 트래픽 라우팅 레이어 (MySQL 라우터)에서 분리하는 동시에 MySQL Shell을 사용하여 클러스터 수명 주기 관리를 간소화합니다.
- 인프라 최적화: 에어 갭 환경을 위해 특별히 설계되었으며 강력한 VM을 활용하여 현재 Kubernetes 네트워킹 제한을 우회합니다.
아키텍처
개념 및 기술
이 섹션에서는 멀티 영역 아키텍처 내의 기능 구성요소와 특정 책임을 자세히 설명합니다.
인프라 및 플랫폼
- 가상 머신(VM): 전용 컴퓨팅 인스턴스 3개로, 각각 별도의 가용성 영역에 배포되어 장애 도메인 경계를 형성합니다.
- GDC 전역 L4 부하 분산기: 안정적인 내부 VIP를 노출하고 MySQL 라우터 상태 점검을 자동으로 평가하여 인바운드 트래픽을 리디렉션하는 플랫폼 관리형 네트워킹 구성입니다.
서비스 및 로직
- MySQL 8.4: 핵심 관계형 데이터베이스 엔진입니다.
- 그룹 복제/InnoDB 클러스터: Paxos를 사용하여 멀티 마스터 복제 및 노드 쿼럼 확인을 담당하는 기본 제공 클러스터링 프레임워크입니다.
- MySQL Shell: InnoDB 클러스터 인스턴스를 구성, 프로비저닝, 관리하는 데 특별히 사용되는 통합 명령줄 인터페이스입니다.
- MySQL 라우터: 각 VM에서 트래픽 라우터 역할을 합니다. 클러스터 메타데이터를 수신 대기하고 트래픽을 전달하도록 동적으로 구성됩니다. 쓰기의 경우 활성/백업, 읽기의 경우 라운드 로빈입니다.
데이터 흐름 및 인터페이스
- 애플리케이션은 데이터베이스 요청을 GDC 전역 L4 부하 분산기 VIP로 전송합니다.
- 부하 분산기는 VM 중 하나에서 정상적인 MySQL 라우터 인스턴스에 대한 연결을 프록시합니다.
- 요청된 포트에 따라 MySQL 라우터는 트래픽을 동적으로 전달합니다. 포트 6446은 쓰기를 위해 활성 노드를 엄격하게 타겟팅하는 반면 포트 6447은 클러스터 전체에서 읽기를 순환합니다.
고려사항
- 성능과 일관성 간의 장단점: 그룹 복제는 합의를 적용하므로 트랜잭션에는 클러스터 피어의 확인이 필요합니다. 성능은 GDC 환경 내의 영역 간 네트워크 지연 시간과 직접적인 상관관계가 있습니다.
- 리소스 관리: 데이터베이스 VM에 MySQL 라우터를 직접 배포하면 하드웨어 사용률이 최적화되지만 연결 풀링 오버헤드로 인해 핵심 MySQL 프로세스가 고갈되지 않도록 신중하게 리소스를 조정해야 합니다.
설계 결정
- Kubernetes를 통한 가상 머신: GDC 에어 갭은 여러 물리적 영역에 걸쳐 있는 Kubernetes 클러스터를 지원하지 않습니다. VM 기반 접근 방식은 별도의 영역에 전용 VM을 배포하는 것이 진정한 멀티 영역 고가용성을 달성하고 전체 영역 장애를 극복할 수 있는 유일한 방법이기 때문에 선택되었습니다.
- InnoDB Cluster와 Orchestrator 및 ProxySQL 비교: ProxySQL 및 Orchestrator와 페어링된 기존 기본/보조 아키텍처가 실현 가능한 대안으로 평가되었습니다. 하지만 기본 제공되는 InnoDB 클러스터 (그룹 복제 + MySQL 라우터 + MySQL 셸)는 서드 파티 라우팅 오버레이에 대한 의존도를 없애고 MySQL 내에서 직접 합의를 유지하여 장애 조치와 관련된 운영 복잡성을 크게 간소화하므로 대신 선택되었습니다.
- 플랫폼 기본 제공 전역 부하 분산: 기본 제공되는 GDC 전역 L4 부하 분산기를 활용하면 VIP가 GDC 컨트롤 플레인에 의해 제어되므로 진입점의 복원력이 유지되고 영역 간 트래픽 전송이 간소화됩니다.
가정 및 제한사항
가정
- 인프라 가용성: 고객에게는 3개의 가용성 영역에 균등하게 분산된 적절한 크기의 전용 VM과 전역 부하 분산기를 프로비저닝할 수 있는 충분한 프로젝트 할당량이 있습니다.
- 보안 네트워킹: 클러스터 내 그룹 복제 동기화 및 MySQL 라우터 트래픽을 허용하도록 키 기반 액세스 및 적절한 ProjectNetworkPolicies(PNP)가 설정됩니다.
제한사항
- Kubernetes 미지원: 컨테이너화된/Kubernetes 기반 솔루션을 엄격하게 찾는 고객은 플랫폼에서 확장 클러스터를 완전히 지원할 때까지 멀티 영역 HA를 달성할 수 없습니다.
- 수동 업그레이드 필요: 관리형 서비스와 달리 이 솔루션은 일상적인 OS 수준 패치 및 데이터베이스 마이너 버전 업그레이드에 대한 책임을 전적으로 고객에게 부여합니다.
- 네트워크 지연 시간 민감도: 복제에는 고품질의 안정적인 네트워크가 필요합니다. 에어 갭 적용 영역 간의 네트워크 지터 또는 지연 시간 급증은 MySQL 클러스터 전반에서 쓰기 작업을 비례적으로 지연시킵니다.
추가 자료
- 솔루션 참조 구현(SRI): GDC 에어 갭 환경에서 고가용성 멀티 영역 MySQL 8을 위한 솔루션 참조 구현