TIL - 20241109

카카오 빌링 MySQL DB 샤딩 적용 세션

카카오 빌링 시스템의 소개

카카오 빌링 시스템은 일종의 마트의 계산대와 같은 역할을 함. 사용자가 선물하기, 쇼핑하기 등에서 결제를 시도하면 해당 서비스에서 빌링 시스템을 호출하고 빌링 시스템은 외부 PG사를 통해서 결제를 수행하며 해당 결제에 대한 내용을 ERP 시스템으로 전송하는 역할을 하고 있음.

카카오 빌링의 특성

• 외부 시스템과 연동되는 부분이 많음
• 카드 정보와 같은 민감한 정보가 많음
• 개인정보, 회계, 보안, 망분리 등의 규제 및 감사가 많음
• 강성 CS가 많으며 해당 시스템 장애시 피해가 큼

문제점

크게 용량 문제와 퍼포먼스/안정성 문제가 있었음.

결제 건수가 지속적으로 증가하면서 해당 데이터가 빌링 DB에 적재되는데 쌓이는 속도가 데이터를 삭제하는 속도보다 훨씬 빨라서 저장 용량이 부족해짐
하나의 DB를 사용하고 있어서 특정 서비스로 인해 장애가 발생하면 영향을 많이 받게 됨

2021년 11월 11일 빼빼로데이 때 대장애가 발생했음. 이전에는 카카오톡 선물하기 서비스가 죽거나 혹은 카카오 페이가 죽어서 장애가 발생했었는데 두 시스템이 개선되고 난 이후에 빌링 시스템에서 장애가 발생하였으며 주된 장애 원인은 DB 이슈였음

해결을 위한 과정

늘어나는 결제 건수로 인한 용량 문제와 빼빼로데이와 같은 트래픽이 많이 발생하는 이벤트를 버틸 수 있는 퍼포먼스 문제를 해결해야 했으며, 일부 서비스의 과도한 트래픽으로 인한 다른 서비스(ex 카카오택시)의 영향을 줄여야 했음.

용량은 결제 데이터 전용 DB 서버를 기존 1대에서 12대로 늘려서 해결. 서버군을 나누어서 해당 서버군별 전용 DB세트를 할당하여 특정 서버군의 장애로 인해 다른 서버군이 영향을 받지 않게 해서 안정성과 퍼포먼스를 해결함

다만 해당 과정을 빠르게 해결하면서 장애 없이 넘어가야 했음.

샤딩을 하는 방법의 경우 애플리케이션 레벨에서 하는 방법과 고급 솔루션을 사용하는 방법이 있음.

여기서 고급 솔루션 도입의 경우 운용 경험이 없었기 때문에 장애 발생 가능성이 있었으며 장기간의 테스트가 필요했어서 애플리케이션 레벨에서 하는 방법을 선택함.

애플리케이션 레벨의 구현의 경우 샤드키로 쓸만한 부분이 없었으며 샤딩전 데이터를 마이그레이션 해야하는 문제와 샤딩후 DB가 추가되었을 때 데이터 재배치 이슈가 있었기 때문에 해당 방법도 어렵다고 판단했음.

빌링 DB의 경우 Auto Increment 값을 PK로 사용하고 있었고, 시스템 변경을 줄이기 위해서는 해당 로직을 바꾸면 안되는 사항이 있었음.
핵심적인 아이디어로 샤드별로 PK 가 겹치지 않도록 테이블 생성시에 AUTO_INCREMENT 값을 적절하게 설정하였음. 물론 결제 건수가 많이 쌓이게 되면 해당 범위가 겹칠 수 있지만 그정도로 쌓이기 전에 Disk full 이 발생하므로 이는 물리적으로 불가능함.
PK 앞자리에 특정 의미를 부여해서 첫 숫자는 phase를 의미하고, 2-3번째는 샤드 넘버를 4~5번째는 테이블 넘버를 의미하도록해서 PK만으로 샤드 및 테이블을 알아낼 수 있도록 구성함.
그래서 이를 기반으로 자식 기반의 데이터는 부모의 ID를 기반으로 같은 샤드에 들어갈 수 있게 함

config를 통해서 배포 없이 샤딩 설정을 바꿀 수 있도록 해서 서비스별 DB분리 작업을 1분 이내로 할 수 있게 시스템을 구성함

효과

DB 샤딩을 통해 DB 별 용량을 줄일 수 있었고, 로드 분산 및 평균 QPS가 감소했음.

개인적인 생각

해당 세션을 보기전에는 샤딩을 하는 방법이 특정 키를 기반으로 범위기반의 샤딩과 해시기반의 샤딩에 대해서만 알고 있었는데, 해당 세션을 통해 AUTO_INCREMENT 의 시작값을 범위가 겹치지 않도록 생성하는 방법을 통해서도 가능하다는 내용을 알 수 있었음.
그리고 해당 PK 값에 샤딩 테이블에 대한 정보를 같이 포함시켜서 DB를 조회하지 않고도 어떤 샤딩테이블에 있는지에 대한 정보를 알 수 있도록 하는 아이디어가 대단하고 생각했음.

참고: youtube, slide