토스뱅크는 어떻게 코어뱅킹을 MSA로 바꿨나

지금 이자 받기 서비스는 토스뱅크의 대표적인 서비스다. 한 달에 한 번 이자 지급하던 것을, 고객이 원할 때 언제든 이자를 지급할 수 있도록 했다. 현재 매일 70만명 이상이 지금 이자 받기 서비스를 사용하고 있다.

IT 관리자 입장에서 지금 이자 받기는 골치아픈 서비스다. 갑작스럽게 트래픽을 높이는 서비스가 등장했기 때문이다. 실제로 이금 이자 받기는 토스뱅크 서비스 중에서  가장 트래픽이 높은 서비스다.

트래픽 몰림으로 인한 성능 저하 문제를 해결하기 위해서 토스뱅크가 선택한 것은 마이크로 서비스 아키텍처(MSA)다. 유연하게 스케일아웃할 수 있고 다른 서비스의 장애로 이어지는 것을 막기 위해서다.

8일 토스뱅크는 토스의 테크 컨퍼런스 ‘슬래시23’에서 코어뱅킹 MSA 전환기를 소개했다. 이날 발표는 장세경, 조서희 토스뱅크의 코어뱅킹 개발자가 맡았다. 

토스뱅크는 기존 은행들과 같은 모놀리식(Monolithic) 아키텍처를 갖췄었다. 모놀리식으로 구성된 코어뱅킹 시스템은 1개의 서버, 1개의 데이터베이스(DB)를 사용했다. 이는 네트워크 구조가 단순해서 트랜잭션 처리가 용이하다는 장점이 있다. 그러나 트래픽이 갑자기 몰렸을 때 특정 서비스만 스케일아웃을 하는 전략을 가져갈 수 없는 단점이 있다. 또 에러가 발생했을 때 원인이 된 서비스 외에 다른 서비스에도 영향을 주기 때문에 안정성이 부족하다는 단점이 있다. 

그러나 모바일위주의 대량의 트래픽을 안정적으로 서비스해야 하는 토스뱅크의 경우 모놀리식 아키텍처로 한계가 있다는 점을 느꼈다. 이에 토스뱅크는 현재의 차세대 코어뱅킹 아키텍처를 모바일과 대량 트래픽에 특화된 마이크로 서비스 아키텍처(MSA)로 바꿨다. 

가장 먼저, 토스뱅크는 기술 스택을 바꿨다. 쿠버네티스 위에 스프링 부트, 코틀린, JPA 등을 기반으로 개발했고, 비동기 메시지 처리와 캐싱은 카프카와 레디스를 채택했다.

이어 도메인 단위로 서비스를 구분했다. 예를 들어 이자지급을 위해 고객 금리조회, 이자의 회계처리를 위한 회계정보 등으로 구분했다. 당초 고객의 지금 이자 받기 요청은 과거 고객 정보 조회를 거쳐 금리조회와 이자계산, 이자 송금, 회계처리를 한 개의 트랜잭션으로 처리했으나, 새로운 코어뱅킹 아키텍처에서는 트랜잭션으로 묶지 않아도 되는 도메인은 별도의 마이크로 서버를 구성했다. 각 서버의 애플리케이션프로그래밍인터페이스(API) 호출을 통해 비즈니스 의존성을 느슨하게 가져가도록 구성했다.  

아울러, 잔액조회의 동시성, 중복 문제를 해결하기 위해 토스뱅크는 계좌 단위 현재 잔액 데이터에 대해서만 고유한 로우 락킹(row locking)이 걸리도록 개발해 동시성을 보장하도록 구현했다. 또 동시성이 발생했을 때 거래를 끝날 때까지 기다릴 수 있도록 재시도할 수 있는 로직과 타임아웃을 적용해, 고객관점에서 락(Lock)이 걸렸는지 모르게 안정적으로 이자를 받을 수 있도록 구현했다. 

두 번째는 카프카를 활용한 비동기 트랜잭션 구현이다. 기존 코어뱅킹 시스템에서는 한 번의 이자를 지급받기 위해 20개의 테이블에 80번의 업데이트가 이뤄지는 복잡한 구조였다. 따라서 이자받기의 평균 속도도 전체 코어뱅킹 서비스 중에서 느린 편에 속한다. 이에 토스뱅크는 지금 이자 받기 트랜잭션에서 분리할 수 있는 테이블은 카프카를 이용해 트랜잭션에서 분리했다. 분리 기준은 고객의 잔액과 통장 데이터 관점에서 DB 쓰기 지연이 발생할 때, 실시간으로 문제가 발생하는지 접근했다. 

결과적으로, 세금 DML(데이터 조회, 삽입, 수정, 삭제)을 지금 이자 받기 트랜잭션에서 분리, 기존 80회의 DML이 이뤄지던 지금 이자 받기 트랜잭션을 50회의 DML로 줄이는 개선 효과를 얻을 수 있었다. 

-어떻게 기존 시스템과 안정적으로 마이그레이션 했나? 

지금 이자 받기 거래를 코어뱅킹 서버에서 이자지급 마이크로 서버로 전환하기 위해 순차 배포 과정이 필요했다. 토스뱅크는 API의 안정적인 전환을 위해, 이자 조회 거래를 적용한 후 지금 이자 받기 거래를 적용했다. 

이자 조회 거래는 산출된 이자 금액에 대한 검증이 필요했기 때문에 3단계에 걸쳐 진행됐다. 

먼저 정기 이자지급일인 1일부터 1개월간 앱에서 거래를 일으키면 실시간으로 기존 코어뱅킹 서버에 API 호출과 동시에 이자지급 마이크로 서버로 이자조회 API를 호출하도록 했다. 코어뱅킹 서버의 이자값과 이자지급 마이크로 서버의 이자값을 각각 받아, 값이 서로 불일치하면 모니터링 채널에 알림을 받고 원인 확인 후 로직을 수정해주는 과정을 거쳤다. 

그리고 모니터링을 진행했다. 모니터링이 완료 됐을 때 이자조회 API를 코어뱅킹 서버에서 이자지급 마이크로 서버로 완전히 전환했다. 

그러나, 실제 계좌에 이자를 입금받는 이자받기 거래는 내부적으로 거래내역이 올바르게 쌓이는지 계좌의 잔액이 갱신되는지 등 데이터에 대한 상세검증이 필요했다. 이를 위해 토스뱅크는 수신개발팀의 팀원들을 대상으로 API를 전환해 직접 이자받기 거래를 일으키면서 이자 입금, 회계처리가 맞게 갱신됐는지 검증했고, 이후 토스뱅크 내부 팀원들에게 오픈해 모니터링을 진행했다. 그렇게 내부에서 검증이 완료된 후에 일부 고객을 대상으로 오픈했고, 대상 모수를 점차 늘리며 순차 오픈해 API를 완전히 전환할 수 있었다. 

글. 바이라인네트워크
<홍하나 기자>0626hhn@byline.network