마이크로서비스(Microservice) 아키텍처와 특징

마이크로 서비스 아키텍처란?

middleware blog

• 유지보수에 유리하고 테스트가 가능해야한다.
• 느슨하게 결합되어야 한다.
• 독립적으로 배포할 수 있어야한다.
• 비즈니스 역량을 중심으로 구성해야 한다.
• 작은 팀 단위로 소유되어야 한다.

서비스의 컴포넌트화

컴포넌트는 독립적으로 대체하거나 업그레이드가 가능한 S/W 단위다. 여기서 컴포넌트화는 시스템을 구성 요소별로 나누고 이를 연결해서 구축하는 것을 말한다. 쉽게말해서 S/W를 여러 서비스로 분리하는 것이다.

모놀리식 vs 모듈식(Microservice)의 팀 분류

모놀리식 팀 구성

기존에는 UI팀, 미들웨어 팀, DB팀으로 나누어서 구성하기 때문에 S/W의 단순한 변경이 필요한 경우 팀 간의 협업 비용과 시간이 증가한다. 

그러나 비즈니스 수행 능력(업무 도메인)에 따른 팀분류의 경우,

비즈니스 수행 능력에 따른 팀 분류

팀이 하는 일이 하나의 서비스 단위로 나뉘어진다. 이를 '마이크로 서비스'라고 한다. 이렇게 팀을 구성하게 되면 S/W스택, DB, 프로젝트 관리 등이 팀 별로 독립적으로 존재하게 된다.

당연히 수정에 의한 협업의 비용과 시간은 줄어들지만, 팀은 서비스에 대한 책임감이 요구되고, 각 서비스가 메시지 버스(통신 인터페이스)를 통해서 원활히 통신해야 한다.

조직과 아키텍처의 연관

시스템을 설계하는 조직은 자신의 조직이 가진 커뮤니케이션 구조를 복제하는 아키텍처 디자인을 만들어 낸다.
Mevlyn Conway

마이크로서비스로 S/W를 만들 때는 S/W 작성에 앞서 팀의 일하는 방식을 더욱 독립적으로 구성해야한다. 마이크로서비스 아키텍처을 활용한다면 티므이 일하는 방식을 더욱 독립적으로 만들어낼 수 있다.

현명한 앤드포인트(Endpoint)와 바보 파이프라인

서비스(앤드포인트)는 일을 하게 만들고, 통신(파이프라인)은 최대한 단순하게 한다. 이는 마이크로서비스에서 프로세스간의 통신이 '현명한 엔드포인트와 바보 파이프라인' 접근 방식을 활용한다.

쉽게 말해서 서비스와 서비스 사이는 느슨하게, 응집성은 높게 하는 리눅스 파이프라인의 철학과 흡사하다.

ex REST API(HTTP), 메시지 버스를 이용한 메시지 전달

마이크로서비스 아키텍처 구현 단계

구분	Level 0 전통방식	Level 1 기본	Level 2 중급	Level 3 고급
어플리케이션	모놀리식	서비스 지향 통합	서비스 지향 어플리케이션	API 중심
데이터베이스	어떤 경우에도 맞는 크기의 엔터프라이즈 DB	엔터프라이즈 DB + NoSQL, 경량 DB	폴리글랏, 서비스의 DB	Data Lake, 준실시간 분석
인프라스트럭쳐	물리적 서버	가상화	클라우드	컨테이너
모니터링	인프라스트럭쳐	어플리케이션, 인프라스트럭처	어플리케이션 퍼포먼스	APM, 중앙화된 로그 관리 시스템
개발 프로세스	워터폴	애자일 및 CI	CI & CD	DevOps

항상 모든 경우에 마이크로서비스 아키텍처가 필요하진 않다. 또한, Level 3단계라고 해서 더 좋다고도 볼 수 없다. 그래서 각 단계가 가지는 특징과 Legacy 시스템의 작동 방식 및 현재 요구사항에 따라서 도입해야한다.