MYSQL HA & DR 토폴로지 - 토스ㅣSLASH 21

 

 

스크립트 바로가기: https://daglo.ai/share/f6L9Z-uv_szFXfbs

 

 

토스 데이터베이스의 HA 및 DR 솔루션에 대해 설명해 주세요.

 

 

MMM은 MySQL Multi-Master Replication Manager의 약자로 토스 Live SQL 데이터베이스 HA 솔루션으로 사용되고 있다. 구글에서 개발한 솔루션이었으나, 현재는 업데이트가 중단되어 필요에 따라 자체 업데이트를 하며 운영하고 있다. 토스 데이터베이스는 마스터-마스터 노드로 구성되며, MMM을 통해 서로 데이터를 복제한다. 모니터링 데몬은 각 데이터베이스 서버에서 실행되며, 서비스 IP는 MMM 데이터베이스 롤 변경에 따라 이동되어, 애플리케이션 서버에 페일오버한다. 모니터링 항목은 4가지이며 이상이 있을 시 MMM이 스텐바이 마스터로 베이 러버(역할 전환)를 진행한다. 

 

 

 

 

초기 복제 구조에서 대칭 구조로의 업그레이드의 필요성은?

 

초기에는 단방향 복제 구조를 활용하여 각 센터 간 데이터 이동을 처리하고, 데이터 센터 페일오버 시 수작업으로 전환해야 하는 불편함이 있었다. 초기에 페일 오버가 거의 일어나지 않을 것이라고 생각했지만, Toss가 간편 결제 파트너사를 운영하게 되면서 무중단 운영의 필요성이 대두되었고, 대규모 네트워크 작업 역시 데이터 센터 롤링 작업을 통해 이루어지게 되었다. 이를 위해 초기 단방향 설계에서 대칭 구조로의 업그레이드가 이루어졌고 DR 복제 채널도 양방향으로 전환되어, 센터 간 자동 이동이 가능해졌다. 이와 같은 작업을 거치면서 DR 복제 채널과 DR 센터 마스터 슬레이브 복제 채널을 마스터-마스터 대칭 구조로 바꾸어 데이터 이동 작업을 최적화하게 되었다.

 

 

두 가지 이슈 발생

첫 번째 이슈는 BinLog 중복 전송 이슈이다. BinLog의 전송에 의해 ( 확률은 희박하나 ) 무한 루핑이 발생할 수 있다. GTID로 중복 적용을 막는 방법이 있는데, 당시 바로 GTID 전환은 어려운 상황이었고 GTID로 가더라도 빅로그의 전송 루핑은 발생하게 된다. 그래서 생각을 한 방법이 빅로그 필터를 걸어 빅로그 루핑을 막는 것이었다.

두 번째 이슈는 MMM이 복제 채널을 구분하지 못하는 이슈이다. 각 데이터 센터의 공인 이번 서버는 디알 양방향 복제 채널이 추가됨으로 인해서 디알 복제 채널과 로칼 마스터 복제 채널이 동시에 생성된 멀티소스 복제 상태가 된다. 이 경우 MMM은 자기 모니터링해야 할 채널이 어떤 채널인지 알지 못합니다. 이를 해결하기 위해 엠엠 채널에 대해서만 모니터링을 하도록 소스를 수정하였다. 

 

두 가지 이슈를 해결하면서, 데이터베이스 장애가 발생하더라도 커넥션 모니터링 이외에도 특별히 신경 쓸 것이 없어졌다. 무중단 운영이 원활해졌다.

 

 

데이터 센터 간 연결이 실패했을 때 대처 방법은?

 

 

애플리케이션 서버가 DB에 접속할 때 실패 시 자동으로 페일오버를 사용한다. 이후 스탠바이 데이터 센터로 이동하여 데이터 복구 후 라이브로 전환합니다. 데이터 센터 내 백업 인스턴스로 데이터 복원을 하며, 이 상황을 대비한 데이터 센터 구축이 필요하다. 상황에 따라 인스턴스 및 데이터 센터 번호가 변경되므로 대처에 주의해야 한다.

 

데이터베이스 HA 구성 중 불일치 상황 해결 방법은?

 

MMM의 01번이 죽은 상황 때문에 02번 상황에 상관없이 페일오버를 실행해야 하는데, 이로 인해 일부 변경 내역은 싱크 되지 않는 불일치 상황 발생한다. 그러므로 데이터베이스 HA 구성 시, SUPER READ ONLY 상태로 장애로부터 복구되도록 하고, mm2 페일오버 시 슈퍼 리드 오니 상태인 경우 해제하지 않고 매일 오버 대기 상태로 유지하여 문제 상황을 예방해야 한다. 처리하지 못한 데이터 불일치 상황 발생 시, 운영자 개입 후 서비스를 정상화시켜야 한다. 데이터베이스 HA 구성 중, 설정과 구성이 중요하며, 환경에 따라 다른 구성이 필요할 수 있다.