GDC 에어 갭의 MySQL 데이터베이스 참조 아키텍처

이 참조 아키텍처는 Google Distributed Cloud (GDC) 에어 갭에서 고가용성 고객 관리형 MySQL 8.4 데이터베이스를 배포하고 운영하기 위한 개념적 프레임워크를 제공합니다. 엔터프라이즈 및 조기 액세스 고객은 강력한 다중 영역 가상 머신 (VM) 설정을 사용하여 중요한 데이터베이스 워크로드를 안정적으로 유지할 수 있습니다.

GDC 에어 갭은 영역 간 Kubernetes 스트레치 클러스터를 지원하지 않으므로 이 아키텍처는 데이터 손실 없이 지속적인 운영을 보장하고 전체 영역 장애를 견딜 수 있도록 세 개의 가용성 도메인에 배포된 전용 VM에만 의존합니다.

특징 및 기능

  • 다중 영역 복원력: 단일 인프라 영역 장애로부터 보호하기 위해 세 개의 개별 가용성 영역에 배포된 복원력이 뛰어난 3노드 구성입니다.
  • 자동화된 고가용성 및 합의: Paxos 기반 합의 클러스터링에 그룹 복제 를 사용하여 스플릿 브레인 시나리오 없이 자동 장애 감지, 노드 합의, 전역 데이터 동기화를 제공합니다.
  • 지능형 트래픽 라우팅: 공동 배치된 MySQL 라우터 인스턴스가 연결 라우팅을 관리합니다. 라우터는 쓰기 작업 (예: 포트 6446)을 활성 기본 노드로만 전달하고 읽기 작업 (예: 포트 6447)을 동기화된 복제본 간에 부하 분산합니다.
  • 전역 부하 분산: 기본 제공 GDC 전역 L4 부하 분산기 와 통합되어 클라이언트 애플리케이션을 위한 단일의 안정적인 가상 IP (VIP)를 제공하고 기본 노드 토폴로지를 추상화합니다.

아키텍처 원칙

  • 쿼럼 기반 합의: 엄격한 데이터 일관성을 우선시합니다. 그룹 복제는 과반수 합의가 필요한 Paxos 기반 모델을 적용하여 네트워크 파티션 중에 데이터 손실 또는 스플릿 브레인의 위험을 제거합니다.
  • 관심사 분리: 데이터베이스 엔진 및 합의 레이어(그룹 복제)를 클라이언트 트래픽 라우팅 레이어 (MySQL 라우터)에서 분리하는 동시에 MySQL 셸을 사용하여 클러스터 수명 주기 관리를 간소화합니다.
  • 인프라 최적화: 현재 Kubernetes 네트워킹 제한사항을 우회하기 위해 강력한 VM을 활용하여 에어 갭 환경을 위해 특별히 설계되었습니다.

아키텍처

공동 배치된 서비스 스택을 실행하는 3개의 VM 아키텍처

개념 및 기술

이 섹션에서는 다중 영역 아키텍처 내에서 기능 구성요소와 특정 책임을 자세히 설명합니다.

인프라 및 플랫폼

  • 가상 머신 (VM): 세 개의 전용 Compute 인스턴스가 각각 별도의 가용성 영역에 배포되어 장애 도메인 경계를 형성합니다.
  • GDC 전역 L4 부하 분산기: 안정적인 내부 VIP를 노출하고 MySQL 라우터 상태 확인을 자동으로 평가하여 인바운드 트래픽을 리디렉션하는 플랫폼 관리형 네트워킹 구성입니다.

서비스 및 로직

  • MySQL 8.4: 핵심 관계형 데이터베이스 엔진입니다.
  • 그룹 복제 / InnoDB 클러스터: 다중 마스터 복제를 담당하고 Paxos를 사용하여 노드 쿼럼을 확인하는 기본 제공 클러스터링 프레임워크입니다.
  • MySQL 셸: InnoDB 클러스터 인스턴스를 구성, 프로비저닝, 관리하는 데 특별히 사용되는 통합 명령줄 인터페이스입니다.
  • MySQL 라우터: 각 VM에서 트래픽 라우터 역할을 합니다. 클러스터 메타데이터를 수신하고 트래픽을 전달하도록 동적으로 구성됩니다. 쓰기의 경우 활성/백업, 읽기의 경우 라운드 로빈입니다.

데이터 흐름 및 인터페이스

  1. 애플리케이션이 데이터베이스 요청을 GDC 전역 L4 부하 분산기 VIP 로 전송합니다.
  2. 부하 분산기는 VM 중 하나의 정상 MySQL 라우터 인스턴스에 대한 연결을 프록시합니다.
  3. 요청된 포트에 따라 MySQL 라우터는 트래픽을 동적으로 전달합니다. 포트 6446 은 쓰기를 위해 활성 노드를 엄격하게 타겟팅하는 반면 포트 6447 은 클러스터 전체에서 읽기를 순환합니다.

고려사항

  • 성능과 일관성 간의 절충: 그룹 복제는 합의를 적용하므로 트랜잭션에는 클러스터 피어의 승인이 필요합니다. 성능은 GDC 환경 내의 영역 간 네트워크 지연 시간과 직접적인 관련이 있습니다.
  • 리소스 관리: 데이터베이스 VM에 MySQL 라우터를 직접 배포하면 하드웨어 사용률이 최적화되지만 연결 풀링 오버헤드가 핵심 MySQL 프로세스를 고갈시키지 않도록 리소스를 신중하게 조정해야 합니다.

설계 결정

  • Kubernetes를 통한 가상 머신: GDC 에어 갭은 여러 물리적 영역에 걸쳐 있는 Kubernetes 클러스터를 지원하지 않습니다. 별도의 영역에 전용 VM을 배포하는 것이 진정한 다중 영역 고가용성을 달성하고 전체 영역 장애를 견딜 수 있는 유일한 방법이므로 VM 기반 접근 방식이 엄격하게 선택되었습니다.
  • InnoDB 클러스터와 Orchestrator 및 ProxySQL: ProxySQL 및 Orchestrator와 페어링된 기존 기본/보조 아키텍처가 실행 가능한 대안으로 평가되었습니다. 그러나 기본 제공 InnoDB 클러스터 (그룹 복제 + MySQL 라우터 + MySQL 셸)는 타사 라우팅 오버레이에 대한 의존성을 없애고 합의를 MySQL 내에 직접 유지하여 장애 조치와 관련된 운영 복잡성을 크게 간소화하므로 대신 선택되었습니다.
  • 플랫폼 기본 제공 전역 부하 분산: 기본 제공 GDC 전역 L4 부하 분산기를 활용하면 VIP가 GDC 컨트롤 플레인에 의해 제어되어 진입점을 복원력 있게 유지하고 영역 간 트래픽 전달을 간소화할 수 있습니다.

가정 및 제한사항

가정

  • 인프라 가용성: 고객은 세 개의 가용성 영역에 고르게 분산된 적절한 크기의 전용 VM과 전역 부하 분산기를 프로비저닝할 수 있는 충분한 프로젝트 할당량을 보유하고 있습니다.
  • 보안 네트워킹: 클러스터 내 그룹 복제 동기화 및 MySQL 라우터 트래픽을 허용하기 위해 키 기반 액세스 및 적절한 ProjectNetworkPolicies(PNP)가 설정됩니다.

제한사항

  • Kubernetes 미지원: 컨테이너화된/Kubernetes 기반 솔루션을 엄격하게 찾는 고객은 플랫폼에서 스트레치 클러스터를 완전히 지원할 때까지 다중 영역 HA를 달성할 수 없습니다.
  • 수동 업그레이션 필요: 관리형 서비스와 달리 이 솔루션은 일상적인 OS 수준 패치 및 데이터베이스 부 버전 업그레이션의 책임을 전적으로 고객에게 부여합니다.
  • 네트워크 지연 시간 민감도: 복제에는 고품질의 안정적인 네트워크가 필요합니다. 에어 갭 영역 간의 네트워크 지터 또는 지연 시간 급증은 MySQL 클러스터 전체에서 쓰기 작업을 비례적으로 지연시킵니다.

추가 자료