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

다음 특징을 갖는 서비스들의 조합으로 이뤄진 설계

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

 

서비스로서의 컴포넌트화

• 컴포넌트: 독립적으로 대체하거나 업그레이드 가능한 소프트웨어 단위
• 컴포넌트화: 시스템을 구성 요소(Component)를 나누고 이를 연결하여 구축하는 것
• 컴포넌트화는 어떻게?: 소프트웨어를 여러 서비스로 분리하는 것

 

라이브러리 vs. 서비스

 

비즈니스 수행에 따른 구성, 프로젝트가 아니라 제품

before: 기술적 계층에 따른 팀 분류

 예) UI팀, business 팀, 데이터베이스 팀

 > 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함

 

after: 비즈니스 수행 능력(업무 도메인)에 따른 팀 분류

도메인?

• 하나의 온전한 시스템의 단위
• 예) 쇼핑몰의 경우 회원/상품/배송

 

팀이 하는 일이 하나의 서비스로 나뉨 → 마이크로서비스

이로 인한 장점으로는,

• 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적
• 이를 달성하기 위해서,
  • 각 팀은 서비스에 대한 책임을 가져야 한다
  • 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 함

조직과 아키텍처의 연관성

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

 > 따라서 마이크로서비스로 소프트웨어를 작성할 때에는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 한다.

 > 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있다

 

현명한 엔드포인트와 바보 파이프라인

특징

 > "서비스(엔드포인트)는 일을 하게 하고, 통신(파이프라인)은 최대한 단순하게 한다"

 

• 마이크로서비스에서의 프로세스 간 통신은, "현명한 엔드포인트와 바보 파이프라인" 접근 방식을 따름
  • 리눅스 파이프라인의 철학과 흡사
• 서비스와 서비스 사이(결합도)는 느슨(decoupled)하게, 응집성은 높게

 

대표적인 방법

1. REST API (HTTP)
2. 메시지 버스를 이용한 메시지 전달 (메시지 큐)

 

분산화 거버넌스, 분산화된 데이터 관리

문제점

 > 중앙 집중적인 시스템은 기술을 표준화하는 경향이 있음

"우리 회사는 Java 9와 Oracle만 사용합니다" "간단한 리포트 만드는 서비스가 필요한데, node.js로 금방 하는 걸 Java를 꼭 써야 해?"

문제 해결에 오히려 방해가 될 수 있다

 

 

해결책

• 분산화된 시스템
  • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
    • 데이터에 대한 분산 책임이 따름
    • 서비스 데이터베이스 간의 일관성이 중요 → 트랜잭션 협조가 중요
  • 분산화된 응용 프로그램 설계 → 도메인 주도 설계(DDD, Domain-Driven Design)
    • 도메인 경계를 분명하게 해야 함

 

장애 방지 설계

(모놀리틱 설계에 비해 불리한 지점)

• 서비스는 언제든지 실패할 가능성이 있음
• 신속하게 장애를 감지하고 가능하면 자동으로 서비스를 복구할 수 있어야 함
  • 예) 아키텍처 요소(데이터베이스가 받는 1초당 요청 수)와 비즈니스 관련(1초당 받는 주문 번호와 같은) 부분을 모두 확인
• 대시보드와 모니터링은 필수적임

 

진화하는 설계

• 컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
• 장점
  • 모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 함
  • 마이크로서비스: 변경한 서비스만 다시 배포하면 됨
  • 간단하고 신속한 출시 프로세스

• 단점
  • 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경 써야 함