마이크로서비스 - msa

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

https://microservices.io/

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

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

서비스로서의 컴포넌트화

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

라이브러리 vs. 서비스

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

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

• 예) UI 팀, 비즈니스 로직 팀, 데이터베이스 팀
• 단순한 변경이 필요한 경우에도 팀 간의 협업 비용이 증가함
  

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

• 도메인?
  • 예) 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인이 된다.
  • 하나의 온전한 시스템의 단위
• 팀이 하는 일이 하나의 서비스로 나뉨 → 마이크로서비스
  • 이로 인한 장점으로는,
    • 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다.
  • 이를 달성하기 위해서,
    • 각 팀은 서비스에 대한 책임을 가져야 한다
    • 각 서비스는 메시지 버스(통신 인터페이스)를 통해 통신해야 한다

조직과 아키텍처의 연관성

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

따라서 마이크로서비스로 소프트웨어를 작성할 때에는, 소프트웨어 작성에 앞서 팀의 일하는 방식을 보다 독립적으로 만들어내야 한다. 혹은 마이크로서비스 아키텍처를 통해, 팀의 일하는 방식이 보다 독립적으로 만들어질 수 있다. (Dev와 Ops가 함께 만들어가야 함)

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

특징

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

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

대표적인 방법

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

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

문제점

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

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

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

해결책

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

장애 방지 설계

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

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

진화하는 설계

• 컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야 하고, 업그레이드를 할 수 있어야 한다.
• 장점
  • 모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 합니다.
  • 마이크로서비스: 변경한 서비스만 다시 배포하면 됩니다.
  • 간단하고 신속한 출시 프로세스
• 단점
  • 기존 서비스에 대한 변경이 이 서비스를 이용하고 있는 다른 서비스에 영향을 주는지 여부를 신경 써야 한다.

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

• 항상 모든 경우에 마이크로서비스 아키텍처가 필요한 것은 아닙니다.
• 성숙도 모델 중 어떠한 방식을 Level 3단계로 전환한다고 해서 더 나은 서비스가 되는 것은 아닙니다.
• 무작정 마이크로서비스 아키텍처를 도입하기 전에 다음을 이해한 후에 도입해야 합니다.
  • 각 단계에 있어서 해당 방식이 갖는 장단점
  • 기존(Legacy) 시스템의 작동 방식
  • 현재 시점의 요구사항