brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Nov 30. 2021

실전 마이크로서비스 아키텍처 적용

MSA 기술과 적용 연구 4

링크드인에서 지인 공유로 읽은 기사 How do microservices fit into enterprise software platforms? 는 나에게도 읽을 가치가 있는 글이었다.


마이크로서비스 아키텍처의 이점

기업용 프로그램(enterprise applications)을 맥락으로 Chanaka Fernando는 다음 다섯 가지 역량(capabilities)을 마이크로 서비스 아키텍처에서 얻을 수 있다고 말한다.

비즈니스 전개 속도 개선(Improved time to market)

실패를 고려한 견고함

높은 가용성 (다른 쪽의 장애가 퍼져나가지 않음)

사람의 실수 피해를 막는 DevOps영역 자동화

컨테이너를 이용한컴퓨팅 자원 사용

꽤 정교하게 쓰여진 내용으로 저자의 경험이 묻어나는 요약이다.


Integration Plaform

글에 하나의 구성도가 등장한다. 다른 데서 쉽게 보기 어려운 부분이 하나 있는데, 바로  integration Platform 이라 표현한 부분과 Developer Experience 영역이다.

그림에서 integration Platform은 각각 네 개의 서로 다른 부분(혹은 계층)에 나뉘어 속해 있다.


API Gateway

첫 번째 요소는 API Gateway 이다. API Gateway 하면 흔히 떠오르는 인증과 보안을 담당하고, 소비자 채널(consumer channels) 상호작용을 다룬다. 포트와 어댑터가 딱 어울리는 부분이다. 그리고, API Gateway가 속한 층을 저자는 Experience APIs 라고 부르는데, 그의 설명을 보면 주요 관심사(concerns)를 분리하라는 원칙이라는 점에서 얼마전 다뤘던 헤드리스 커머스가 떠오른다.

A set of experience APIs are developed and deployed at this component to hide the complexity of the internal implementation details of the backend services.        


Integration Services

두 번째 요소는 미들웨어 성격의 다양한 서비스로 포장하거나 적어도 그렇게 다루도록 유도하는 층이다.

This is another runtime component that is used develop intermediate services by orchestrating, transforming and mapping different services that provide core business functions and data


Connectors

세 번째, 커넥터는 핵심적인 비즈니스 기능이 외부 제조사나 특정 제품 버전에 종속적인 부분이 있을 때 이를 느슨한 연결(loosely-coupling)을 제공하기 위한 부분이다.

These are wrappers of the core business functions that are implemented at different vendor specific applications at the core services layer.


Developer Experience

마지막으로 develper experiece는 Open API 제공과 같은 외부 개발자 협력을 위한 요소이고, 흔히 개발자 포탈을 통해 노출된다.

A developer portal can help in this process by exposing the APIs in a discoverable platform to the developers (internal and external)

그림을 감상하고 마는 차원을 넘어서 실용적으로 쓰기 위해 우리 상황에 적용하는 방법이나 다른 관심사와 연결해 생각해봤다.


실전 마이크로서비스 아키텍처 적용

두 가지 생각을 그림에 덧붙일 수 있다. 하나는 예전에 <마이크로서비스 도입 이렇게 한다>에 나온 마이그레이션에 대해 우리회사 CTO가 했던 말이다.

마이그레이션을 하지 말아야지

책 저자가 말하는 마이그레이션과 베터코드 CTO의 마이그레이션 정의가 달랐다. 우리나라에서는 아무래도 마이그레이션이라고 하면 과거 시스템에서 새로운 시스템으로 1:1 로 옮기는 것을 지칭하는 경우가 많다. 하지만, 저자인 샘 뉴먼이 말하는 마이그레이션은 신구 시스템을 모두 합쳐서 변경해가는 과정 전체를 말한다. 우리나라에서는 마이그레이션을 그렇게 쓰지는 않지만, 그런 틀로 IT 자산 전체를 바라보는 관점이 바람직하다. 흔히, 거버넌스(Convernance)라는 표현을 쓸 때, 필요한 관점이 그런 것이다.  


Chanaka Fernando 의 그림을 두고 그러한 기존 시스템이 있는 상태에서 MSA로 아키텍처를 현대화 할 때어떻게 해야 하는가를 다뤄볼 수 있다. 앞서 말한 거버넌스 관점으로 마이그레이션 하는 전략이 그림이 등장한다.

이미 돌아가고 있는 시스템 흔히 말하는 레거시가 있을 때, 어떻게 MSA 즉, 마이크로서비스 아키텍처를 도입할 것인가? 먼저, 검은색으로 표현한 부분은 '새롭게 짜면 되는' 영역이다. 반면에 붉은 색으로 표현한 부분은 어떤 종류의 레거시나 외부 시스템이 있을 경우에 해당한다. 이들의 새로 작성하는 프로그램과 연결할 수 있는 Connector 층을 고려하면 굳이 어렵게 레거시를 분석해서 변경하는 수고를 할 필요는 없다. 실제로 북경에서 나도 똑같은 전략으로 성공적인 MSA 마이그레이션(?)을 실행한 바 있다.


여기까지 생각하고 나니 매우 실용적인 글임을 더욱 실감했다. 참조 아키텍처로 활용해보자.




브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari