백곰술사의 IT Insight

그렇다면 MSA전환 전략에 따라 금융IT 코어시스템 MSA전환은 어떻게 해야할까요?

3. 금융IT 시스템을 MSA로 전환하기

금융IT의 Legacy 시스템은 대부분 강결합 서비스입니다.

하나의 서비스가 다른 서비스가 제공하는 모듈들을 참조하는 것이 특징입니다.

그렇다면 금융은 어떤 기준으로 기존 Monolithic Service를 Micro Service로 전환해야할까요?

아래와 같이 3가지 기준으로 전환 할 수 있습니다.

[금융시스템 Micro Service 전환기준]

  1) Monolithic Service 중 결합도가 낮은(Loosely Coupled) 서비스

  2) Monolithic Service에 참조되는 Business Component
      (물론 Business Component도 결합도는 낮아야함)

  3) One Transaction이 필수적인 거래(입/출금거래 등)는 일정수준의 결합도를 가진 서비스로 전환

거의 대부분의 Service를 Micro Service로 전환하되

금전Data의 Commit일관성 등이 필요한 서비스는 약간의 결합도를 가진 상태로 구성하는 전략이 필요합니다.

[AS-IS : Monolithic Service]

[TO-BE : Micro Service]

4. 금융IT 코어시스템을 MSA 전환 시 고려할 점

3과 같이 금융 시스템의 MSA전환 전략 기반으로 수행한다 하더라도 기존 시스템을 MSA로 전환하는 것은 굉장히 어렵습니다.

[기술 역량 확보]

 MSA의 가장 큰 특징으로는 서비스 기준으로 아키텍처가 완전히 분리된다는 것입니다.

 대출신청은 Java, RedisDB를 쓰고, 한도확인은 Python, MongoDB를 사용할 수 있습니다.

 각 서비스에 대한 Property만 설정해두면 원활히 사용가능합니다. (Polyglot)

 기존 금융권에서는 Java/C, RDBMS 등의 기술셋 결합이 일반적이기 때문에

 MSA 효과를 배가시키기 위해 다양한 기술역량을 확보하는 것이 필요합니다.

[우선순위 기반 개발/배포]

 금융IT 코어시스템 서비스 기준으로 Risk 우선순위를 정해 개발 및 배포를 수행합니다.

 Less Critical한 서비스 기준으로 개발/배포해 Lessons Leanred를 얻고

 Mission Critical한 서비스를 개발 배포하는 방향으로 나아갑니다.

 MSA는 BigBang방식과는 다르게 각 서비스를 독립적으로 배포할 수 있기에

 유연하게 Risk를 낮추는 관점에서 개발/배포합니다.

[Cross-Functional Team 도입]

 MSA는 서비스 기준 독립적 배포 및 서비스 관리가 가능하기에

 CFT(Cross-Functional Team)도입이 필수적입니다.

 서비스에 관련된 현업/IT/Data/AI 구성원들을 한 팀으로 구성해 더 나은 서비스를

 기획하고 더 빨리 배포하고 결과를 분석하는 체계를 통해 MSA의 효과를 극대화할 수 있습니다.

안녕하세요

금융사의 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) 초연결 및 개방을 하지 않고서는 살아남을 수 없는 비즈니스 생태계

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

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

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

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

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

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

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

[전략 출처]

youtu.be/Fp6wkP3Ofsg

안녕하세요.

Cloud 전환(Mig.) 현실적 문제점 2편에 대해서 적어보려 합니다.

주제는 MSA(Micro Service Architecture) 전환의 한계입니다.

[1. Cloud도입을 위한 MSA 서비스 도입 필요성]

  MSA는 Cloud Native 대표 Archtecture이며, 아래와 같은 필요성에 의해 도입됩니다.

  아래 필요성은 Cloud 도입시 MSA화를 병행해야하는 이유입니다.

  위와 같은 필요성들을 달성하기 위한 MSA도입 시 제일 중요한 고려사항은

  기존 Monolithic Service에서 적절한 수준의 Micro Service 분해입니다.

  하지만 Micro Service의 적절한 분해라는 것은 말처럼 쉽지 않은 한계점을 가지고 있습니다.

[2. Cloud도입을 위한 MSA 서비스 분해 한계]

 MSA 전환을 위해서는 기존 Service를 독립성, 분산성을 가질 수 있게 적절히 Micro화 해야합니다.

 아래 그림은 어느 수준으로 분해하는 것이 MSA에 효율적인가를 고민해야함을 나타냅니다.

  어떤 서비스는 Business Level에서의 Micro Service화가 필요하며

  어떤 서비스는 Process Level에서의 Micro Service화가 필요합니다.

  기존 Monolothic Service를 기반으로 적절한 Micro Service를 찾는 것

  바로 그것이 MSA의 전환의 핵심이자 Cloud 도입의 필수 요건이지만

  실제 필드에서는 아래와 같은 현실적 한계점들이 존재합니다.

[MSA전환 시 현실적 한계점]

  Cloud 도입을 위한 MSA전환은 꼭 필요하지만, 특히 Mission Critical한 금융, 물류, 제조 등의 산업에서는

  위와 같은 현실적 한계점 때문에 도입을 주저하고 있습니다.

  Cloud도입만 하면 되는 줄 알았더니

  MSA 전환에 드는 분석/분해 작업 등은 많은 시간/비용이 들면은 MSA전환 자체를 주저하게 됩니다.

  하지만 위와 같은 현실적인 한계점들을 잘 고려해서

  Cloud와 함께 MSA전환을 같이 수행하게 된다면

  Cloud의 비용/운영/조직적 관점에서 신규 서비스 개발 및 확장성있는 인프라 제공 등을

  최적화하여 사용할 수 있을 것입니다.