안녕하세요. 저는 토스코어 데이터 서비스팀에서 DBA로 일하고 있는 김피터입니다. 이번에 발표할 주제는 토스 데이터베이스의 에이치에이 그리고 디알 토폴로지입니다. 먼저 MMM은 HAO픈소스 솔루션 이름인데요. 마인슈켈 멀티마스터 리플리케이션 매니저의 약자입니다. 토스의 라이브 마이슈켈 데이터베이스 에이치에이 솔루션으로 사용되고 있습니다. 구글에서 개발된 슬루션인데요. 버전 업데이트는 중지되어서 필요에 따라 자체 업데이트를 하면서 사용하고 있습니다. 저희는 마스터마스터 0 1 0 2 5드만 MMM이 관리하도록 구성해서 사용하고 있습니다. 공 3번 슬레이브도 MMM 관리하에 포함시키는 구성이 가능하지만 신규 마스터로 페이로브 하는 과정에서 대응되지 않는 몇 가지 케이스가 있어 이 구성은 쓰고 있지 않습니다. 기본 구성은 모니터링 에이전트 두 가지 대문과 애플리케이션 서버 페이로버를 위해 각 데이터베이스 서버에 올라간 서비스아이피로 되어 있습니다. 모니터링 데모는 별도의 호스트에서 모든 모니터링 및 의사결정과 명령을 수행합니다. 에이전트 데모는 각 데이터베이스 서버에서 실행이 되고, 모니터링 대문에서 내려온 명령을 수행하게 됩니다. 서비스 아이피들은 MMM이 데이터베이스 롤 변경에 따라 이동시켜 애플리케이션 서버의 페이로버가 이루어지게 합니다. 모니터링 대문이 하는 주요 모니터링 항목은 흰 박스에 나와 있는 네 가지인데요. 핑은 호스트 자체가 살아있는지에 대한 확인이고 마이스케일은 마요스케일 인스턴스가 살아있는지에 대한 확인이고 리플스레즈는 복제스레드가 정상 작동 중인지에 대한 확인이고 리플백로그는 복제스레드의 지연이 정해진 쓰레시 홀드를 넘어섰는지를 확인합니다. 이 모니터링 항목에서 이상이 있을 시 MMM이 스탠바이 마스터로 페이러버를 진행하게 됩니다. MMM 자체에 대한 내용은 이 정도로 마치도록 하겠습니다. 처음 구성했을 때의 모습입니다. 데이터 센타 원이 액TV고 데이터 센터 투가 스탠바인데요. 스탠바이 데이터 센터의 마스터가 액티브 데이터 센터 마스터의 슬레이브로 단방향 복제로만 구성되어 있습니다. 데이터 센터 간에도 단방향이고 스탠바이 데이터 센터 내에 로컬 마스터 간에도 단방향 복제 구성이었기 때문에 데이터 센터 페이로벌을 할 경우 롤 전환하는 작업들을 해줘야 했습니다. 신규 액티브 데이터 센터의 마이스킬 서버를 마스터 구성으로 전환해야 하고 데이터 센터 간 마이 스킬 서버의 마스터 슬레이브 관계도 전환해야 합니다. 그리고 신규 스탠바이 데이터 센터의 마요스킬 서버는 마스터 슬레이브 단방향으로 전환해야 합니다. 하나하나 봤을 때는 어려운 작업은 아닌데, 은근히 번거롭고 부담스러운 작업입니다. 하지만 디알 센터의 본 목적이 재난시 비즈니스 연속성 보장이기 때문에 데이터 센터 페이로벌을 해야 할 사항이 거의 발생 발생하지 않을 거라고 생각했습니다. 그런데 토스의 간편결제 파트너사가 늘어나면서 무중단 운영의 필요성이 점점 커졌습니다. 이런 상황에서 대규모 네트워크 작업이 무중단 데이터 센터 롤링 작업으로 계획이 되었고 데이터베이스 서버도 데이터센터 페이로보가 필요했습니다. 그래서 진행을 했는데 데이터 센터 롤링 시마다 데이터베이스 롤 전환 작업에 대한 부담이 많았고 작업 시 실수로 복제가 깨지는 경우도 발생하였습니다. 이 작업 외에도 다운타임이 필요하거나 온라인으로 하기에는 위험부담이 큰 작업이 발생하기 때문에 기타 센터 전환과정을 최대한 간소화시킬 필요가 있었고, 이를 위한 고민을 하게 되었습니다. 이게 원하는 모습이었습니다. 양쪽 데이터 센터를 대칭구조로 만들어서 데이터 센터 페이로봇 시에 애플리케이션 서버 커넥션만 옮겨 다니고 데이터베이스 레벨에서는 따로 작업할 것이 없는 구조로 만들고 싶었습니다. 기존의 단방향으로 있던 디알 복제 채널과 디알 센터 내에 마스터 슬레이브 복제 채널이 마스터 양방향으로 바뀌는 완전한 대칭이 되는 구성입니다. 그런데 원하는 구성으로 하려다 보니 두 가지 이슈가 있었습니다. 첫 번째가 빅로그 중복 전송 이슈인데요. 010이번의 경우 로그 슬레이브 업데이트 옵션을 키고 운영을 하게 되는데요. 이것은 SQL 쓰레드가 적용한 트랜젝션도 빅로그에 기록하는 옵션입니다. 이 상황에서 빅로그 흐름의 예시를 하나 보면 액티브 데이터 센터 공 1번에서 발생한 트랜젝션의 빅로그가 생성이 되면 디알 채널을 따라 스탠바이 데이터 센터 공 1번으로 전송이 되고, 적용이 됩니다. 적용이 된 후 스탠바이 덴터센터의 공 1번 서버는 이 트랜젝션에 대한 빅로그를 생성하게 되는데 이때 공 1번의 슬레이브로 있는 공이 공 3번에서 이 빈로그를 복제하고 적용하게 됩니다. 여기까지는 단방향으로 구성했을 때와 동일한 빈로그 복제의 흐름입니다. 그런데 공 이 번에서 최고다 최종 적용한 빅로그가 자체 빅로그로 생성이 되고, 공 1번은 공 이 번의 마스터이면서 슬레이브이기 때문에 이 빅로그를 복제해야 하는지 판단하게 됩니다. 이 판단은 해당 빅로그가 처음 생성된 서버의 서버 아이디와 자신의 서버 아이디가 다른지 비교해서 이루어지는데요. 다를 경우 복제를 하게 됩니다. 이 빅로그는 액티브 데이터센터 공 1번에서 처음 생성되었기 때문에 서버 아이디 일공일 을 계속 유지하고 있는 상황이고 서버 아이디 1000일인 공1번으로 다시 복제가 됩니다. 여기서 적용이 되면 다시 또 공 삼 공 이 번으로 복제가 되는 상황이 나올 수 있는데, 실제 갑 변경이 없을 경우 빅로그가 생성이 되지 않는데 동일 빅로그가 적용된 지 1초도 지나지 않은 상황이기 때문에 4번의 상황까지 나올 확률은 적습니다. 하지만 이론적으로는 무한 루핑이 가능합니다. 두 번째 이슈는 MMA 복제 채널을 구분하지 못하는 이슈입니다. 각 데이터 센터의 공인 이번 서버는 디알 양방향 복제 채널이 추가됨으로 인해서 디알 복제 채널과 로칼 마스터 복제 채널이 동시에 생성된 멀티소스 복제 상태가 되는데요. 이 경우 MMM은 자기 모니터링해야 할 채널이 어떤 채널인지 알지 못합니다. 첫 번째 이슈의 경우 GTID로 중복 적용을 막는 방법이 있는데, 당시 바로 GTID 전환은 어려운 상황이었고 GTID로 가더라도 빅로그의 전송 루핑은 발생하게 됩니다. 그리고 다시 빅로그 포지션 방식으로 전환 시 이슈가 되기 때문에 중복 전송 자체를 막을 방법이 필요했습니다. 그래서 생각을 한 방법이 빅로그 필터를 걸어 빅로그 루핑을 막는 것이었습니다. 두 번째 이슈의 경우는 엠엠 채널에 대해서만 모니터링을 하도록 소스를 수정했습니다. 이게 현재 디알 구성의 모습입니다. 그림을 보시면, 빅로그 필터가 각 데이터 센터의 공1번에서 생성된 디알 복제 채널 채널에 걸려 있는 것을 확인할 수 있는데요. 각 채널의 필터 설정 조건은 디알 채널의 경우 로컬 데이터 센터에서 발생된 트랜젝션에 대한 빅로그는 받지 않는 것 엠엠 채널의 경우 디알 채널이 있는 마스터 서버의 엠엠 채널은 원격 데이터 센터에서 발생한 트랜젝션에 대한 블로그는 받지 않는 것입니다. 이 조건으로 필터가 적용이 되면 빅로그 중복 전송이 방지되어서 각 데이터 센터에서 로컬 엠엠 구조와 데이터 센터 간 엠엠 구조를 유지할 수가 있습니다. 이 구조로 되면서 데이터 센터 페이로봇이 디빌레이어에서는 커넥션 모니터링 외에는 특별히 전환 작업을 해야 할 일이 없게 되었습니다. 그래서 무중당 운영 작업 시 예전에는 로컬 데이터 센터 내에서의 롤링만을 고려했는데 이제 적은 부담으로 데이터 센터 페이로브가 가능해지면서 좀 더 많은 무중당 운영 작업이 가능해졌습니다. 그런데 스팀바이 데이터센터는 디알로스의 역할을 해야 하기 때문에 동시에 라이트를 양쪽 데이터센터에서 받지 않고 디알 센터의 모든 서버에 대해서는 슈퍼 리드 온리 상태를 유지하여 혹시나 깨질 수 있는 가능성을 차단해 두고 있습니다. 장애 케이스별 페이로봇 시나리오입니다. 이 KC는 액티브 데이터 센터 마스터 인스턴스 장애가 발생한 케이스이고요. 공 1번의 장애가 발생하면 엠엠의 모니터가 이를 감지합니다. 그리고 페이로버를 수행하는데요. 스탠바이 마스터가 전송받은 모든 빅로그를 적용한 것을 확인 후 스탠바이 마스터의 리드 온리를 해제시킵니다. 그리고 공 1번에 있는 서비스 아이피를 스탠바이 마스터로 이동시키면 이후 앱 서버 커넥션이 스탠바이 마스터로 들어오면서 서비스가 정상화됩니다. 이 케이스는 액티브 스탠바이 마스터 양쪽 모두 장애가 난 상황으로 데이터 센터 장애와 동일한 수준의 상황입니다. 애매엠에서 장애를 감지하지만 스탠바이 마스터도 장애가 난 사항으로 회의로보가 불가합니다. 이 상황에서의 커넥션이 엘세븐을 통해서 DB 서버 커넥션을 맺고 있는 상황이면 엘세븐 페이로버로 어플리케이션 서버의 커넥션은 바로 스탠바이 데이터 센터로 넘어가게 됩니다. 그런데 아직 평상시에는 에세븐을 통해 DB 접속을 하고 있지는 않아서 도메인 타겟 변경을 통한 페이로버로 진행하게 됩니다. 도메인이 변경이 다 적용되면 어플리케이션 서버가 데이터베이스로의 재접속을 시도할 때 DNS 리졸브가 새로 되면서 커넥션이 스탠바이 데이터 센터 마스터로 맺어지게 됩니다. 플랜드 페이로버의 경우에는 평상시에는 어플리케이션 서버가 바라보는 데이터베이스 커넥션 도메인이 서비스 아이피를 직접 가리키고 있습니다. 엘 세븐 VIP가 데이터베이스 서비스 아이피로 라우팅이 되도록 설정을 하고 어플리케이션 서버의 커넥션 도메인은 엘세븐을 가리키도록 DNS 변경을 해줍니다. 모든 커넥션이 일세븐을 통해 맺어진 것 확인이 되면 계획된 시점에 엘세븐 페이로버 기능을 통해서 한 번의 커넥션을 스탠바이 데이터 센터로 페이로버 시켜줍니다. 이때 액티브 데이터 센터에 맺어진 커넥션이 끊기고 재접속 시에 스탠바이 데이터 센터로 맺어지게 됩니다. 그래서 어플리케이션 서버 쪽 영향성도 기존에 맺어져 있던 데이터베이스 커넥션이 한 번 끊어졌다가 다시 맺어지는 정도의 영향성이라고 보시면, 됩니다. 이 경우는 데이터 삭제 등의 논리적 장애 발생 시 복 9절차입니다. 백업을 위한 인스턴스가 각 데이터 센터에 존재를 하고 해당 인스턴스는 지연 복제가 설정이 되어 있는데요. 액티브 데이터 센터는 한 시간이고 스탠바이 데이터 센터는 세 시간으로 설정되어 있습니다. 그리고 공이번 서버에서는 데일리 당일 백업본을 유지하고 있습니다. 복구를 위한 복제본과 백업본이 단계적으로 준비되어 있기 때문에 장애 이슈가 빨리 공유될수록 더 빠른 시간 내에 복구가 가능하도록 되어 있습니다. 시점 복구가 완료되면 상황에 맞게 라이브에 적용하여 데이터 복구를 진행합니다. 이 시나리오는 MMM을 운영하면서 발생할 수 있는 시나리오를 테스트한 내용인데요. 드물지만 실제 발생할 경우 복구가 힘들어지는 장애상황으로 이에 대한 조치사항을 정리한 내용입니다. 현재 공 1번이 리드라이트이고 공이 번이 리드 온리입니다. 타임원은 정상 복제사항으로 010이 번의 데이터 싱크가 유지되고 있는 상황입니다. 타임 튜는 공익원에서 장애가 발생해서 인스턴스가 죽었다가 재시작이 되고, 복제가 중지된 상황입니다. 공 1번으로 라이트는 계속 들어오고 있고 공 일 및 공 이 번은 데이터 불일지가 점점 심해지고, 있는 상황입니다. 타임 3번은 공 이 번의 복제 중지 상황이 해결이 되지 않은 상황에서 공 이 번 인스턴트 장애의 원인이 된 쿼리가 공 1번으로 들어오는 상황입니다. 이로 인해서 공1번에도 장애가 발생하고 재시작이 됩니다. 이에 따라 엠엠이 공이 번으로 페이로벌을 실행합니다. 공 1번이 죽은 상황이기 때문에 MMM은 공이 번 상태에 상관없이 페이로버를 진행하게 되고 공이 번은 복제 중지된 후 공 1번에서 일어난 변경 내역을 싱크하지 못한 채로 라이트를 받게 됩니다. 불일치 데이터를 수동으로 모두 복구해야 하는 상황이 발생하는 것입니다. 화폐 상황을 방지하기 위해 두 가지를 적용했는데요. 첫 번째는 데이터베이스 인스턴스가 장애로 재시작될 때 슈퍼리도니 상태로 올라오도록 적용을 했고 두 번째는 MMM 및 페이로봇 시에 데이터베이스가 슈퍼리드 온리 상태인 경우에는 이를 해제하지 못하고 페이로버 대기 상태에 머물도록 해체하였습니다. 적용한 후 다시 동일한 장애 상황 시나리오인데요. 타임원이고 장애전 상태로 공 1번 공이 번 데이터 싱크가 유지되고 있는 상황입니다. 타임 투 에서 공 이 번 장애로 인스턴스가 재시작 시 슈퍼리도니 상태로 올라오게 됩니다. 중지 상태로 데이터 불일치는 점점 증가합니다. 타임 쓰리 에서 공이 번 복제 중지가 해결되지 않은 상황에서 공 1번 이 장애로 재시작이 됩니다. 공 1번도 슈퍼리더니, 상태로 올라오게 되고 MMM은 공이 번으로 페이로버를 시도하는데 공이 번이 슈퍼리더니, 상태임을 확인하고 페이로버를 진행하지 않습니다. 로그의 슈퍼리도니 상태로 페이로브 불가하다는 메시지만 기록하고 페이로버 대기 상태로 읽게 됩니다. 이렇게 되면 애플리게이션에서 들어오는 라이트가 막히고 장애 상태가 지속이 되지만 010이 번 데이터 불일치 상황에서의 라이트 발생으로 인한 복구 불가 데이터 불일치 상황은 막을 수 있습니다. 이때 운영자가 개입을 해서 상황을 해결하고 서비스를 정상화하게 됩니다. 제 발표는 여기까지인데요. 데이터베이스의 HADR은 데이터베이스뿐 아니라 어플리케이션 서버 네트워크 쪽도 필요한 설정과 구성이 잘 되어 있어야 하는 여전히 어려운 주제라고 생각합니다. 그리고 환경 따라 적합한 구성이 다를 수 있는데요. 오늘 발표 내용이 마야스킬과 MMM으로 구성 시에 하나의 케이스로 참고 및 도움이 되셨으면 좋겠습니다. 감사합니다.