토스페이먼츠의 결제 시나리오
- 원장: 회계에서 원장은 기업의 모든 거래 내역을 기록하는 공식적인 장부
- 결제 원장: 고객이 결제하거나 취소한 거래내역을 보관하는 DB(테이블)
문제 1: 일관성 없는 구조
카드 취소/부분 취소는 각각의 테이블에 저장되고 있었고 계좌이체 취소/부분취소는 한 테이블에 저장되고 있었다.
문제 2: 다양한 도메인 사이의 강한 의존성
하나의 카드 테이블을 각각 다른 도메인 팀들이 각자 다르게 컬럼에 의미를 부여해 쓰고 있었음
문제 3: 비즈니스 확장을 가로막는 구조
결제 - 결제수단 1:1 → 여러번 나누어 결제가 불가한 구조. 더치페이, 분리결제 등
왜 MySQL로 전환했는가?
기존 오라클에서 테이블을 추가한다거나 하는것도 되지만 신규 원장을 새롭게 구축하기로함. 다음과 같은 이유
- 이미 다른팀 쓴다. 시스템 안정을 위해서임
- 유지보수. 기존에는 오라클, 마이바티스로 관리. 디버깅 오래걸리고 오라클 전용함수, 동적쿼리 많았다. 마이는 JPA 라서 유지보수 용이
- 유연한 확장과 실험. 오픈소스와 도구 연동 부담없었고 이미 내부에 테스트환경이 있어 부담이 없다.
해결 1: 일관성 있는 구조
인서트만 허용
해결 2: 도메인 간 결합도 낯추기
신규 결제원장은 API를 제공시도했으나 배치작업시 API 과부하 생길수있다. 결국 카프카 도입
도메인간 의존성 제거, 각 팀 각자 개발 가능
해결 3: 확장성 있는 구조
핵심
신규원장 전환: 비동기 쓰레드풀 설정
- 7분
- 이파트에서 여러 설정나오고 비동기 세팅도 나옴 적용해볼만한 주제다!!!
신규원장 마이그레이션: 서버 분리
병렬로 처리해도 병목이 있으면 그래로다.
신규원장 마이그레이션: bulk insert
