MSA로 전환1

[참고](https://toss.tech/article/slash23-corebanking)

토스 코어뱅킹 시스템 중 지금 이자받기 서비스를 MSA로 전환하는 과정입니다.

현재 은행 시스템

채널계 + 코어뱅킹(계정계)

• 채널계 : 고객의 요청을 코어뱅킹 서버로 전달
• 코어뱅킹 : 금원과 관련된 메인 비즈니스 로직을 처리
• 모바일 트렌드와는 맞지 않는 20년 전의 모놀리식 아키텍처를 대부분의 은행에서 사용 중, 점점 모놀리식 형태로 몸집을 불려가고 있음

 

토스뱅크 현재 시스템

채널계 + 코어뱅킹

• 채널계 : MSA 아키텍처
• 코어뱅킹 : Redis, kafka 등 모던한 기술을 사용하고는 있었지만, 모놀리틱

 

모놀리식 아키텍처 장단점

• 장점
  • 트랜잭션 관리 용이
  • 여러 하위 도메인의 데이터를 ACID하게 변경할 수 있음
  • 개발의 단순성
  • 모든 코드가 단일 코드 베이스므로 단순
  • 보편성
  • 대부분의 코어뱅킹 시스템이 모놀리식이라서, 인력 수급과 개발이 용이
• 단점
  • 특정 코어뱅킹 서비스만 스케일 아웃을 하는 전략을 못함
  • 1개의 장애가 다른 서비스 장애에 영향을 줌

 

모놀리식 to MSA

고객도 많아지고, 서비스도 많아지면서 대량 트래픽에 특화되어 있고, 각 업무별 서비스 영향도를 분리할 수 있는 MSA로 전환하기로 결정

토스뱅크 서비스 중 트래픽이 많으면서, 대표 서비스 중의 하나인 지금 이자 받기 서비스를 바꾸기로 결정

 

개발 방법

기술 스택 선정

채널 서버에서 사용하고 있는 기술들 대부분 사용

• Kubernetes
• Spring boot
• Kotlin
• JPA
• Kafka : 비동기 메시지 처리
• Redis : 캐싱

 

AS-IS 흐름도

MSA의 장점을 살리기 위해서 도메인 단위로 서비스를 나눔

• 고객 정보
• 상품 약관
• 이자 계산
• 세금 계산
• 이자 송금

 

TO-BE 흐름도

 

트랜잭션으로 엮이지 않아도 되는 도메인은 별도의 마이크로 서버로 구성

• 고객 마이크로서비스
• 상품 마이크로서비스
• 이자 지급 마이크로 서비스
  • 이자 계산
  • 세금 계산
  • 이자 송금

 

동시성 제어

잔액을 갱신하는 트랜잭션의 채널이 많으므로 이와 같이 Lock을 구성

Redis Global Lock + 이자지급 마이크로 서비스 + JPA @Lock

 

비동기 처리

이자 지급 마이크로 서비스(이자 DB) -> 비동기처리 서버(세금 DB)

1. Kafka 비동기 메시지 처리
2. 트랜잭션 종료 -> 카프카 토픽에 메시지르 Produce -> 비동기 처리 서버가 Consume -> DB에 저장
3. dead letter queue
4. 카프카 메시지가 정상적으로 처리되지 않을 경우, DB에 대한 트랜잭션을 안정적으로 보장
5. 재처리
6. 재처리시 중복으로 세금이 업데이트 안되도록 API도 멱등하게 설계

결과 : 세금 DML을 이자 받기 트랜잭션에서 분리 -> 이자 받기 트랜잭션이 줄음(80->50) -> 성능 개선

 

캐싱

• 사용한 이유
  • 고객은 하루에 1번 밖에 이자를 못받음 즉, 이자데이터는 변경이 적은 데이터라서 Redis Cache 사용
• 설정
  • Cache 데이터 만료일자 하루
  • 이자금액이 잘못 계산되는 케이스도 방지
  • 매일 자정 이후 계좌 상세탭에 처음 접근 할 때만 이자예상조회의 결과를 캐싱
  • 이자 데이터의 정합성 보장

 

기존 시스템을 안정적으로 전환하는 방법

실시간 검증을 통한 건별 검증 방식

1. 코어뱅킹 서버와 이자 조회 서비스를 호출하고, 동시에 이자 지급 마이크로 서버의 API 호출

1. 이자 값 비교, 불일치하면 해당 내용을 내부 모니터링 채널에 알림으로 받도록 설정
2. 로직 수정

 

배치를 활용한 대량 검증 방식

1. 실제 운영환경과 동일하게 구성된 내부 API 테스트용 환경에서 채널계 배치를 활용해 매일 대량 검증 대상 목록을 출력
2. 온라인 검증 방식과 동일하게 코어뱅킹 서버와 이자 지급 마이크로 서버 값 각각 호출
3. 대상 목록에 대한 검증
4. 이자 리턴 값 비교, 불일치한 거 내부 모니터링 채널에 알림으로 받기
5. 로직 수정

 

테스트 시나리오 작성을 통한 E2E 통합 테스트 수행하기

 

잔액 구간별 차등 계산되어 이자가 지급되었는지 검증이 필요해서 진행

• 고객의 상태에 따른 검증

• 계좌의 상태 및 출금/입금 정지 상태에 따른 검증

 

순차 배포를 통한 안정적인 마이그레이션

대상 모수를 점차 늘려감 -> 기존에 운영하고 있던 시스템을 중단하지 않고독 안정적으로 전환 가능했음

1. 토스뱅크 수신개발팀에게 오픈
2. 토스뱅크 내부 팀원에게 오픈
3. 일부 고객에게 오픈
4. 전체 고객에게 오픈

 

성과

• 코어뱅킹 시스템의 세대 전환
• 오픈소스 기반의 개발 환경 변화에 따르 유연성 및 확장성 증가
• 지금 이자 받기 거래의 성능 170배 개선
• 코어뱅킹 서버로부터 독립적인 서버를 구축함으로써 안정성 증가
• 지금 이자 받기에 개별적으로 서버 스케일 아웃 가능
• 도메인 단위로 분리하여 효율적인 MSA 코어뱅킹 시스템 구축
• 빅뱅 배포 방식을 탈피하여 무중단 시스템 전환 가능

 

알게 된거

모놀리식 -> MSA 해야하는 이유

• 성능 개선(대량 트래픽)
• 독립적인 서버(장애, 스케일 아웃)
• 유연성, 확장성
• 도메인 단위로 분리하여 효율적인 시스템 구축

MSA 개발 방법

• DDD
• 트랜잭션으로 엮이지 않아도 되는 도메인은 별도의 마이크로 서버로 구성
• 트랜잭션 처리
• 이벤트 비동기처리
• 캐싱

배포

• 실시간 검증
• 배치 활용
• 테스트 시나리오 작성
• 순차 배포