마이크로서비스

마이크로 서비스란 무엇인가?!

마이크로서비스 == 마이크로서비스 아키텍쳐

- 애플리케이션을 서비스 모임으로 구성하는 아키텍쳐 스타일

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

서비스로서의 컴포넌트화

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

라이브러리 VS 서비스

조직의 팀 분류

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

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

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

#도메인 : ex) 쇼핑몰의 경우 회원/상품/배송이 각각의 도메인, 하나의 온전한 시스템의 단위

팀이 하는 하나의 일이 서비스로 나뉘어짐 -> 마이크로서비스
- 소프트웨어 스택, 데이터베이스 선택, 프로젝트 관리 등이 팀 별로 독립적이다
각팀은 서비스에 대한 책임을 가져야 한다
각 서비스는 메세지 버스(통신 인터페이스)를 통해 통신해야 한다

조직과 아키텍쳐의 연관성

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

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

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

엔드포인트와 파이프라인

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

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

#대표적 방법

1. REST API(HTTP)

2. 메세지 버스를 이용한 메시지 전달(메시지 큐)

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

!문제점

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

- 특정 플랫폼만 이용하면 다른 서비스를 쉽게 만들 수 있는 플랫폼을 이용하지 않고 어렵게 만들어야 함

- 문제 해결에 오히려 방해가 됨

!해결책

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

장애 방지 설계

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

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

진화하는 설계

컴포넌트 핵심: 컴포넌트가 개별적으로 대체 가능해야하고, 업그레이드를 할 수 있어야 함

장점

모놀리스: 작은 변경 사항도 응용 프로그램 전체의 재배포를 필요로 한다
마이크로서비스: 변경한 서비스만 다시 배포하면 된다
간단하고 신속한 출시 프로세스

단점

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

Rake_in_*