All Honey Tip

MSA(MicroService Architecture) 전환 1편 – Toss Bank

MSA

마이크로서비스 아키텍처(Microservices Architecture, MSA)는 최근 인기를 끌고 있는 혁신적인 아키텍처 패턴입니다. 기존의 모놀리식(Monolithic) 아키텍처의 한계를 극복하고, 높은 유연성확장성을 제공하기 위해 여러 개의 독립적인 작은 서비스애플리케이션을 분리하여 개발하는 접근 방식입니다. 많은 기업들이 MSA로의 전환을 시도하고 있으며 국내 금융 기업 Toss Bank의 Core Banking 시스템의 일부를 기반으로 알아보도록 하겠습니다.

MSA





기존의 Monolithic Architecture

Banking System의 대략적인 구조는 다음과 같습니다. 고객의 요청을 받아 코어뱅킹 서버로 전달하는 채널계, 금원 관련 Business Logic을 수행하는 코어뱅킹이 존재합니다.

모바일 뱅킹, 웹 뱅킹, 텔레 뱅킹 등의 다양한 거래 요청을 하나의 Server에서 정확하게 처리할 수 있으며 안정성이 보장됩니다.

image 53
SLASH 23



Monolithic Architecture을 고집하는 이유?

보수적인 금융권 특성상 이미 검증된 Architecture는 쉽게 바뀌지 않습니다. 데이터는 사용자의 금전과 직결되며, 안정성과 신뢰성, 그리고 인증 과정이 매우 엄격하기 때문입니다.

개발자 입장에서 유지보수 하기 수월(일부분)하다는 특징도 있습니다. 1개의 Server, 1개의 DB는 네트워크 구조가 단순하며 Transaction 처리에 용이합니다. 시스템 비용 또한 저렴하고 구현과 배포가 비교적 간단하다고 볼 수 있죠.

MSA
SLASH 23
  • MCI / MCA (Multi Channel Interface, Integration / Multi Channel Architecture): 채널계와 통신.
  • FEP (Front End Processor): 대외 연결.
  • EAI (Enterprise Application Integration): 대내 단위 시스템 연결.




Monolithic Architecture의 한계점

하지만, 이런 Monolithic 구조에도 한계점이 분명히 존재합니다. 이용자가 늘고 Traffic이 증가하면 적절하게 대응할 수가 없게 되죠. 이유는 아래와 같습니다.


1. 규모와 복잡성

모든 기능이 단일 Code base로 이루어지기 때문에, 시간이 지남에 따라 크기와 복잡성이 증가합니다. 빌드, 배포 시간이 길어지고 Code 변경 또한 어려워집니다.


2. 장애 대응 및 안정성

시스템 일부에 문제가 발생하면 시스템 전체에 영향을 끼칠 수 있으며, 특정 기능이 많은 자원을 사용하거나 지연될 경우에도 전체 시스템의 성능이 감소되기 쉽습니다.


3. 확장성

단일 Unit으로 동작하기 때문에 특정 기능의 확장이 다른 기능의 확장에 영향을 줄 수 있습니다. SOLID 원칙 중 OCP에 어긋나는 특징이기도 하죠.

  • OCP, Open/Closed Principle(개방 폐쇄 원칙) : 소프트웨어 요소는 확장에는 열려있으나, 변경에는 닫혀 있어야 한다.


즉, Scale-out이 어렵거나 제한적일 수 있게 되죠. 이러한 한계점들을 극복하기 위해 MSA 전환은 하나의 도전 과제가 됩니다. 국내 Fintech기업 Toss Bank의 “지금 이자받기” 서비스를 기반으로, 전환 과정을 알아보겠습니다.

image 55
고객이 원하는 시점에 이자를 지급받을 수 있는 서비스




MSA 전환: 지금 이자받기 서비스

“지금 이자받기” 서비스는, 한 달에 한 번 받던 이자를 고객이 원하는 시점에 지급받을 수 있는 서비스입니다. 매일 70만 명 이상이 이용하는 서비스이기 때문에 가장 높은 Traffic이 발생했다고 합니다.

image 56
Monolithic – 지금 이자받기

이 Traffic은 위에서 언급한, Monolithic의 한계점으로부터 발생하는 문제들을 야기했습니다. 전체 토스뱅크 서비스에 Delay가 발생한 것이죠. 특정 기능만을 위한 대한 대응으로 Server를 Scale-out 하는 것도 비효율적이며 불필요한 비용이 크게 발생한다는 것이 자명했습니다. 그리고 그렇게 MSA 전환이 시작됩니다.



마치며

MSA 전환을 주제로 Monolithic과 그에 대한 특징, 그리고 한계점을 알아보았습니다. 예시로 언급된 Toss Bank는 Monolithic의 한계로부터 발생한 Trouble을 겪고, MSA를 도입합니다. 금융 도메인에서 Architecture를 바꾼다는 것은 매우 도전적이며 까다로운 과제라고 할 수 있습니다. 다음 시간에 MSA 전환 과정에 대해 상세하게 알아보도록 하겠습니다.

M vs MSA

토스 SLASH 23 참고


코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다