안녕하세요

금융사의 IT직원으로 코어시스템을 어떤 방향으로 기획할 것인지? 최신 기술 및 동향을 어떻게 접목해 발전을 이룰것인지?

비록 제가 주니어 직급이며 기획팀은 아니지만 항상 고민이 됩니다.

 

20.04월 한화생명이 자사 코어 기간계 시스템을 Cloud로 전환 시 MSA로 전환했다는 소식을 듣고(with NBP)

대략 2주간 굉장히 고민했습니다. AWS 다니는 친구에게도 MSA 지식에 대해 물어보고..

 

어떻게 결합도가 최상이라는 금융 기간계 서비스를 MSA로 전환했지..?

구글링을 통해서는 명확한 프로젝트 내용을 알 수 없었지만, 저를 굉장한 고민을 빠뜨린 기사인 것은 확실합니다.

 

그러면서 금융사의 MSA 전환에 대해서 다시 한번 생각해보았습니다.

 

1. 금융사 같은 Mission Critical 산업을 왜 MSA로 전환해야 하는가?

금융IT는 중앙집중화로 인한 안정성이 가장 중요한 특징입니다.

따라서 MSA에 대한 유행이 2015년정도부터 시작되었음에도 불구하고 아직 금융사는 SOA를 유지하고 있습니다.

하지만

아래와 같은 배경은 금융사를 MSA로 갈 수 밖에 없게 만들고 있습니다.

 

  1) Fintech 등장으로 인한 기존 금융사의 서비스 다양화 및 빠른 출시(배포) 필요

  2) 중앙화된 시스템 수준으로 올라온 분산시스템의 안정성 확보

  3) 초연결 및 개방을 하지 않고서는 살아남을 수 없는 비즈니스 생태계

 

구분 AS-IS TO-BE
서비스
다양성
금융 서비스 변화 미미 Fintech등장으로 인한 다양한 서비스 경쟁력 필요
거래
안정성
안정적 거래 제어를 위한 중앙집중형 구조 Circuit Breaker, FallBack 등의 기능 제공으로
분산 시스템 거래 안정성 확보
거래
개방성
일정한 내부 평균 거래량으로 인한
즉각적 Scale Out 불필요
Open API, 스크래핑 등 외부 참조 거래 증가로 인한
즉각적 Scale Out 필요

 

2. MSA 전환 전략은 어떻게 할 것인지?

그렇다면 우리는 어떻게 MSA전략을 만들어야 할까요?

금융사의 MSA전환을 생각해보기 전에 MSA전환 전략에 대해 기획과 관리자의 관점에서 구글링 해본 결과

AWS Korea 박선용 솔루션아키텍트님이 2018 AWS Summit Seoul에서 발표한 전략이 가장 좋다고 판단되어 소개드립니다.

[출처가 되는 해당 영상은 아래 첨부해 두었습니다.]

 

DevOps, CI/CD 등의 Cloud Native는 차치하고

철저히 서비스 분할 관점에서 현 운영되는 Monolithic Service를 어떻게 Micro Service로 전환할 것인가에 대한 전략입니다.금융사는 강결합된 서비스의 분할이 가장 큰 핵심이기 때문입니다.

 

MSA전환의 4단계

전환 단계 요소 설명
발견 서비스/모듈의 API표현 - 운영되고 있는 강결합의 서비스들을 독립적 API로 생각해보기
- 서비스 수정 시 타 서비스 수정이 필요하다면 그것은 MSA가 아님
DB기준 분할 서비스 발견 - 운영되고 있는 DB Model관점에서 서비스를 생각해보기
- DB관점에서 FK 제거 등으로 마이크로 서비스를 구성해보기
패턴 API GW, Circuit Breaker - MSA 적용 아키텍처에 대한 구성
서비스별 스키마/DB - Micro Service 기준 각자 다른 Stack구성
분할 발견기준 App/DB 분할 - 발견단계에서 구성된 마이크로서비스별 API 분할/생성
- FK등을 제거 후 서비스 별 Attribute로 DB 재구성
DataPump 도입 - I/O 비용을 줄이기 위해 배치성의 Data전송
매핑 컨테이너 기반 매핑 - MSA기준 서비스를 컨테이너 기반으로 매핑
서로 다른 App Stack 구성 - 각 Micro Service 별 개발언어/DB/OS/패턴 등의 Stack을 구성하여 매핑(Polyglot)

 

[전략 출처]

youtu.be/Fp6wkP3Ofsg

Monolith에서 MSA로의 전환전략

 

+ Recent posts