포스트

카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄

Tech Blog Review
게시
By August
좋아요 조회 10 분 읽는 시간

원문: MySQL Orchestrator 기반의 새로운 HA 표준 개발기 — kakao tech, 2025-09-30

한 줄 요약

카카오는 2015년부터 MHA로 MySQL 고가용성을 맞춰 왔지만, MHA는 10년 넘게 패치가 없고, Perl이라 고치기 어렵고, 외부에서 Source 서버를 찔러 보는 구조라 네트워크 장애에 오동작하며, Replica 상태는 아예 볼 수 없었다. 2023년 13개 후보를 비교해 Orchestrator를 골랐고, 가장 어렵지만 가장 안전한 Raft HA(3대 이상 홀수)로 구성했다. 사내 DBaaS와 잇는 연동 시스템 Protego를 만들고, 코드 변경은 최소화하며 위험한 UI 제거·API 추가·Hook 알림·Replica용 DNS Failover를 넣었다. 그리고 Orchestrator의 장애 판정 방식에 맞춰 slave_net_timeout을 바꾸자 네트워크 장애 페일오버가 5~10초로 줄었다. 3년 안에 MHA를 전부 대체하는 것이 목표다.

배경: MHA의 세 가지 한계

MHA는 2012년 DeNA의 Yoshinori Matsunobu가 만든 자동 페일오버 도구다. 문제는 셋이다.

  1. 변화 대응 부족. 10년 넘게 패치·기능 추가가 없다. MySQL과 OS 버전이 올라가는데 대응이 없다.
  2. 구조적 한계. Source 서버 상태를 외부에서 접근해 확인하는 로직이라 “네트워크는 안정적”이라는 전제가 깔려 있고, 다양한 네트워크 장애에서 오동작했다. 카카오는 이를 보완하려 HAM이라는 MHA 클러스터 매니저를 만들었지만 Perl 소스를 고치는 것이 큰 부담이었다. 그리고 MHA는 “Source가 죽으면 Replica를 승격”이 기본 설계라 Replica 상태를 보고 조치하는 요구를 넣을 수 없었다.
  3. Perl. 한국에서 거의 안 쓰는 언어라 분석·수정에 시간이 많이 든다.

선정: 13개 후보 중 Orchestrator

MySQL Cluster, ProxySQL, Corosync+Pacemaker(+NFS/DRBD), Heartbeat 조합, PRM, Percona XtraDB Cluster, Automatic Asynchronous Replication Connection Failover, ClusterControl, InnoDB Cluster, Orchestrator 등을 검토했다. Orchestrator는 Shlomi Noach(gh-ost 개발자, Vitess 기여자)가 만든 것으로, 단순 페일오버를 넘어 복제 토폴로지 전체를 이해하고 복구(healing)하는 데 초점이 있다. MHA와 달리 한 클러스터에서 여러 토폴로지를 관리하고, 자기 자신도 클러스터로 HA를 갖출 수 있다.

구성: Raft HA

Orchestrator 클러스터는 Meta DB 구성과 프로세스 관리 방식에 따라 넷으로 나뉜다.

구성OrchestratorMeta DBOrchestrator 자체 HA
No HA11없음(테스트·개발용)
Semi HA여러 개1(Source-Replica 가능)없음
Shared Backend HA여러 개클러스터(InnoDB Cluster 등)없음
Raft HA클러스터(리더 선출)리더가 관리있음

구성 난이도가 가장 높지만 안전한 Raft HA를 택했다. Raft는 여러 서버가 하나처럼 동작하도록 합의를 만드는 알고리즘이고, 핵심은 정족수(과반수)다.

노드과반수장애 허용분리 시
3212:1로 갈리면 2쪽이 정상 동작
4312:2로 갈리면 양쪽 모두 불가
5323:2로 갈리면 3쪽이 정상 동작

짝수는 split-brain은 안 생기지만 정족수가 회복될 때까지 서비스가 멈추고, 장애 허용 수가 하나 적은 홀수와 같아 비효율적이다. 그래서 최소 3대, 홀수다. 리더 선출뿐 아니라 내부 로그 커밋도 과반수에서 이뤄져야 커밋된다.

카카오에 맞추기

Protego. 모든 DB가 DBaaS로 운영되므로 Orchestrator를 그냥 쓸 수 없었다. DB 메타 정보를 제공하고 Orchestrator와 DBaaS를 연동하는 솔루션을 만들었다.

코드 수정. 전제는 둘이다. 변경을 최소화한다. 업스트림 최신 버전과 카카오 버전 사이의 충돌이 문제가 되지 않도록 배포 프로세스를 정의한다. 다섯 영역(Web UI, Client API, Hook, Backend DB, 핵심 로직)에서 이렇게 고쳤다. 위험한 UI 제거, Protego 연동 API 추가, Hook으로 이벤트 알림, Backend DB의 메타 정보를 Protego가 읽어 활용.

DNS Failover. MHA에서는 불가능했던 Replica 활용 요구다. 서비스용 Replica 도메인을 만들어 매핑하고, Orchestrator Backend DB의 Replica 상태를 보다가, 장애가 확인되면 도메인을 다른 Replica로 바꾼다. 다른 작업은 안 하고 도메인만 바꾸니 DNS Failover다. 지금은 5분 정도 텀을 두고 바꾸며 고도화 여지가 있다.

자동화. 최초 구성(git clone부터 빌드·계정·파일 수정까지 7단계 수동 작업)을 스크립트로, 배포와 빌드를 Jenkins로 자동화했다.

운영: slave_net_timeout

이 글에서 가장 실용적인 부분이다. Orchestrator는 세 가지로 상태를 판단한다. Source의 SELECT 1, Replica의 SHOW REPLICA STATUS, Replica의 SHOW SOURCE STATUS. 즉 Source 헬스체크와 Replica의 복제 상태를 함께 보고 페일오버를 결정한다.

  • Source 프로세스가 죽은 경우: Orchestrator가 UnreachableMaster를 감지하고 Replica 복제 상태를 본다. 보통 Source가 죽으면 Replica에 Dead Signal이 가서 IO 스레드가 Connecting으로 바뀌므로 빠르게 확정된다.
  • Source는 멀쩡한데 네트워크만 끊긴 경우: Dead Signal이 안 오므로 Replica는 slave_net_timeout(Source에서 이벤트를 못 받을 때 기다리는 시간)만큼 기다린 뒤에야 연결 끊김을 확정한다. Orchestrator는 그만큼 지연된 뒤 페일오버한다.

그래서 카카오는 MySQL 서버들의 slave_net_timeout을 바꿨고, 네트워크 장애 페일오버가 5~10초 안으로 개선됐다.

결론

현재 Orchestrator와 MHA를 병행 중이고 3년 안에 통합이 목표다. 기대 효과는 네트워크 장애로 인한 페일오버 오류 제거, Replica 모니터링과 후속 처리, 업무 생산성이다.

읽고 남는 질문

  • slave_net_timeout을 얼마로 바꿨는지 값이 없다. 너무 낮추면 일시적 네트워크 흔들림에 복제가 끊겼다 붙었다 하고 불필요한 페일오버가 날 수 있어서, 5~10초라는 결과와 함께 설정값과 오탐 경험이 있으면 좋겠다.
  • Orchestrator의 페일오버는 승격까지고, 애플리케이션이 새 Source를 찾는 경로(VIP, DNS, 프록시)가 무엇인지가 없다. Replica는 DNS Failover라 했으니 Source도 DNS인지 궁금하다.
  • Orchestrator 자체가 openark에서 Percona 포크로 관리 주체가 옮겨 갔다. MHA를 떠난 이유가 “관리되지 않아서”인데, Orchestrator의 유지보수 전망을 어떻게 판단했는지 한 줄 있었으면 설득력이 더했을 것이다.

한 줄로 가져가기

HA 도구를 바꾸는 일의 절반은 도구 선정과 클러스터 구성이고, 나머지 절반은 “그 도구가 장애를 어떻게 판정하는가”에 맞춰 DB 설정을 다시 보는 것이다. Orchestrator는 Replica의 눈으로 보므로 slave_net_timeout이 곧 페일오버 시간이 된다.

시리즈

빅테크 기술 블로그 리뷰

31편 중 6편

이전 시리즈 글 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다 다음 시리즈 글 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Kakao
Tech Blog Review Kakao MySQL High Availability Orchestrator MHA Raft Failover Replication
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다