MySQL Orchestrator로 High Availability(HA) 구축

MySQL Orchestroator란?

MySQL Orchestrator는 GitHub의 openark/orchestrator 프로젝트에서 호스팅 되고 있는 오픈소스 도구로, MySQL 복제(Replication) 토폴로지를 관리하고 고가용성(HA)을 확보하기 위해 사용됩니다.

GitHub - openark/orchestrator: MySQL replication topology management and HAGitHub

Orchestrator를 도입하면 복잡한 MySQL 복제 구조를 직관적인 UI로 시각화할 수 있으며, 새로 추가되는 인스턴스도 자동으로 감지합니다. 또한, UI 상에서 드래그 앤 드롭만으로 복제 연결 구조를 손쉽게 변경할 수 있다는 장점이 있습니다.

여러 장점이 있지만, Orchestrator의 가장 핵심적인 기능은 자동화된 복구(Auto Failover)입니다. Master/Slave 구조에서 Master 서버에 장애가 발생했을 때, 개발자가 미리 설정한 규칙에 따라 가장 적합한 Slave를 찾아 Master로 승격시킵니다. 이를 통해 수동 개입 없이 서비스의 가용성을 지속적으로 보장할 수 있습니다.

Orchestrator GUI

그림 1

master db의 인스턴스를 등록하면 그림과 같이 클러스터 현황이 나타납니다.

• 파란색 원: 현재 구성된 클러스터 내의 정상적인 인스턴스를 의미합니다.

주황색/빨간색 원은 복제 지연이 발생하거나, 접근할 수 없는 등 상태가 좋지 않은 Slave 인스턴스를 나타내고, 검은색 원: 응답이 없거나(Down), 관리가 불가능한 서버를 의미합니다.

상세 대시보드 화면을 보면, Master DB만 등록하더라도 연결된 Slave DB까지 자동으로 탐지하여 토폴로지 트리 구조를 시각적으로 보여줍니다. 예를 들어 1090b:3306(Master)과 428c4:3306(Slave)의 관계가 연결선으로 표현됩니다.

수동 Failover

Orchestrator의 Failover 모드는 기본값(Default)이 '수동'으로 설정되어 있습니다. 따라서 별도 설정 없이는 장애 발생 시 관리자가 직접 인지하고 조치해야 합니다.

기존 Master DB 서버를 종료하면 대시보드에 응답 없음(검은색 등)으로 상태가 변경됩니다.

장애가 발생한 Master 인스턴스 메뉴에서 Recover를 클릭하면, Failover 조치가 가능한 서버 리스트가 나타납니다. (Master 1대, Slave 1대 구성이었다면 Slave 인스턴스가 후보로 노출됩니다.)

수동으로 Failover를 수행하면 선택된 Slave 인스턴스가 새로운 Master로 승격되며, 기존 클러스터 구조에서 분리되어 독립적인 Master 역할을 수행하게 됩니다.

이 과정에서 눈여겨볼 점은 read_only 속성입니다.

기존 Slave 428c4 인스턴스는 read_only가 켜져 있었지만, Master로 승격되는 순간 Orchestrator가 이를 자동으로 해제합니다. 이는 ApplyMySQLPromotionAfterMasterFailover 설정(기본값 true)에 의해 처리됩니다.

자동 Failover

자동 복구를 활성화하기 위해서는 Orchestrator의 설정 파일을 수정해야 합니다.

orchestrator/docs/configuration-recovery.md at master · openark/orchestratorGitHub

상세한 파라미터는 공식 문서를 참고하실 수 있으며, 주요 설정값은 다음과 같습니다.

parameter	descripition	before	after
RecoveryPeriodBlockSeconds	노드에 장애가 발생해서 복구된다면, 해당 파라미터 값(시간) 동안 복구를 block 한다. 즉, 한번 recover가 되고 지정한 시간동안 장애가 발생해도 복구되지 않는다.	3600	30
RecoverMasterClusterFilters	마스터 장애에 대해서 auto failover를 진행할 클러스터를 지정하는 옵션이다. 예를들어 "slave1"로 명시했다면 여러 클러스터(Replica Set)이 존재할 때, "slave1"에 대해서만 자동 마스터 장애 복구가 실행된다.	[ "master_pattern" ]	["*"]
RecoverIntermediateMasterClusterFilters	복제 토폴로지에서 중간 마스터 서버에 장애가 발생했을 때, 어떤 클러스터에서 자동 복구를 수행할지를 결정하는 필터이다.	["intermediate_master_pattern" ]	["*"]
PromotionIgnoreHostnameFilters	이 필터에 지정한 slave 노드는 마스터로 승격되지 않는다.	[]	[]

auto failover를 확인하기 위해 변경한 구성이며, 직접 값을 명시할 수 있지만, 패턴이나 정규식으로도 표현이 가능합니다. 예를 들어 "*"는 모든 클러스터를 의미합니다.

RecoverIntermediateMasterClusterFilters에 대해서 좀더 다루자면,

Master -> Intermediate Master -> Slaves

복제 토폴로지가 위와 같은 구조일 때, 중간 마스터가 실패하면 그 아래 슬레이브들이 영향을 받게 됩니다. 따라서 중간 마스터에서 장애가 발생하여 접근이 불가능하면, 필터에 설정된 복구 대상 클러스터에 대해 자동 복구를 수행합니다.

설정을 변경하고 적용하면, 대시보드 우측 상단에 하트 아이콘이 표시됩니다. 이는 해당 클러스터에 대해 자동 복구(Auto Failover)가 활성화되었음을 의미합니다. 이 상태에서 Master 노드를 강제로 다운시키면, Orchestrator가 즉시 감지하여 Slave를 Master로 승격시키는 과정을 확인할 수 있습니다.

추가 고려 사항

1. 엔드포인트 변경

Orchestrator는 DB 자체의 승격은 아주 잘 수행합니다. 하지만 애플리케이션(WAS)이 바라보는 DB 주소까지 자동으로 바꿔주지는 않습니다.

• 문제점: DB는 Failover 되었지만, 웹 서버는 여전히 죽어있는 구(Old) Master의 IP를 바라보고 있어 서비스 장애가 지속될 수 있습니다.

• Orchestrator의 Hooks 기능(PostMasterFailoverProcesses)을 활용하기

  • 스크립트를 등록하여 DNS 레코드를 업데이트하거나,

  • HAProxy 설정을 변경하거나,

  • VIP(Virtual IP)를 새로운 Master로 이동시키는 스크립트가 실행되도록 설정해야 HA를 완성할 수 있습니다.

2. 고가용성 확보

Orchestrator 서버 자체가 죽으면 복구를 해줄 수 없습니다. 따라서 실무에서는 Orchestrator 서버도 여러 대로 구성하여 Orchestrator 자체의 고가용성을 확보하는 것이 좋겠습니다.