Cloud 전환(Mig.) 현실적 문제점 - 2. MSA 전환의 한계

안녕하세요.

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

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

 

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

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

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

필요성	요소	설명
비용 효율성	- Micro Service 별 복제	- Micro Service 별 서버 구성/확장으로 Pay-Per-Use 비용 효율화
확장성/가용성	- Scale Out - Data Replication	- 상황에 맞는 가상서버(ex. EC2) Scale Out으로 가용성 제공 - Data Replication을 통한 가용성 제공
개발 효율성	- Polyglot Architecture - DevOps 체계 지원	- 다양한 개발언어 및 DB 연계로 인한 개발 편의성 제공 - DevOps조직과 연계된 서비스 별 즉시 개발 가능

 

MSA 전환 개념도

 

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

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

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

 

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

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

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

 

 

MSA를 위한 적절한 서비스 분해는?

 

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

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

 

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

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

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

 

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

한계	요소	설명
결합도 분석 한계	- 기존 서비스 로직 파악 미비	- 복잡한 결합도 분해가 필요하지만 기존 서비스 로직   파악 미비로 인한 한계 존재
필수 결합 모듈 존재	- 핵심 결합 모듈 필요	- One Transaction 필수 모듈 존재   ex. 대외기관 연계(금전 연동), 실시간 처리 모듈 등
Micro Service 분해 수준 모호	- 성능 이슈 존재	- 낮은 수준의 모듈화는 모듈 간 I/F 비용 증대
	- 관리 이슈 존재	- 선/후 필요한 Transaction은 모듈 간 관리 필수   (개발자가 직접 모듈간 호출 관계를 설정 필요)
DB Join 한계	- 독립적 DB로 인한 I/O비용 증대	- 각 서비스 별 DB 독립화로 인한 DB Join 불가하며   그에 따른 DB Transation 증대
	- DB 정규화 작업 필요	- 각 독립 서비스 별 DB 정규화을 통한 DB 독립화

 

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

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

 

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

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

 

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

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

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

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