마이크로서비스 아키텍쳐 (MSA) 구축 하기 - 2

마이크로서비스 아키텍쳐 (MSA) 구축 하기 - 2

Microservices Service Modeling 하기

마이크로서비스 아키텍쳐를 구축하기 위해서는 제일 먼저 monolithic 한 어플리케이션을 나누거나 새로 어플리케이션을 개발 한다면 어떻게 나눠서 개발할 것인지 정의 해야 하는데 이 정의를 어플리케이션의 주 서비스 및 기능을 기반으로 나눠어야 합니다. 여기서 중요한것은 잘못 나눈 서비스 모듈은 향후 변경하거나 Monolithic 어플리케이션으로 다시 합치는데 상당한 비용과 시간 및 노력이 소요됨으로 급하게 나누지 말고 큰 기능 부터 나누고 거기서 다시 세부기능을 나누는 Break down 접근법으로 접근해야 합니다.

예를 들어, E-commerce 사이트를 마이크로서비스로 나누어서 설계한다면 우선 큰 기능별 Break down은 제품, 오더, 지불결재, 장바구니 정도가 있을것 입니다. 우선 이렇게 명확한 부분을 나누고 여기서 다시 제품을 예로 든다면 스포츠의류, 정장 등의 구분이 있을 것이고 스포츠 의류를 또 나눈다면 수영복, 헬스복, 스키복 등으로 나누어질수 있을겁니다. 또, 여기서 사이트의 특성상 스포츠 의류를 기능별로 나누지 않고 브랜드 별로 나눌수도 있을것입니다. 즉, 1편에서 설명해드린데로 회사의 비지니스 또는 업무에 등에 따라 정책, 목적 등에 맞게 나누어야 하며 절대 서둘지 말고 단계별로 충분한 검증을 거치면서 작업해 나가고 중요치 않고 작은 부분 부터 구현을 해서 이상이 없는지 접근해 보는 방법을 권장 합니다.

이상적인 통합 기술 모색

1. MSA 간 통신은 어떤것이 좋을지 고려해야 합니다. 향후 여러가지 이유로 MSA를 변경시 연관된 DB나 상호 동작하는 MSA간 통신은 어떻게 할것인지 등 미래의 scalability (확장성)을 고려하여 표준 API를 사용하고 각 MSA의 주요 내부 구현 아키텍쳐가 상호 연동되는 MSA 변경이나 구현에 종속적이지 않고 독립적으로 구성됨이 중요합니다. MSA구현시 가장 중요하게 고려해야 하는 사항이 MSA 자체의 강한 응징력과 MSA간의 느슨한 결합력 입니다.

2. MSA간 통신 방법을 어떻게 할것인가? 동기식으로 할것인지? 비동기식으로 할것인지 고려가 필요합니다. 이는 어플리케이션 특성 및 작동방식에 따라 동기식의 동작 방식, 즉 요청 MSA가 응답이 올때 까지 대기해야 할것인지? 아니면 비동기식으로 요청을 보내놓고 응답이 오던 말던 자기 할 일이 지속적으로 수행하게 만들지가 고려되야 합니다.