MSA(Micro Service architecture)

SOA와 MSA란?

SOA는 서비스 지향 설계 방식(Service Oriented Architecture)이다.

SOA는 서비스 단위로 개발을 하고, 개발된 서비스들을 공유함으로써 재가용성을 늘리고 유연성을 확보하는 것을 목표로 한다.

MSA는 마이크로 서비스 설계 방식(Micro Service Archtecture)이다.

MSA 또한 아주 작은 단위의 서비스로 소프트웨어를 구성함으로써 민첩하고 유연한 설계를 할 수 있도록한다.

 

그렇다면 둘의 차이점은?

 

가장 큰 차이점은 재가용성이다.

 

SOA는 서비스를 개발하고, 이를 최대한 재가용한다. 예를 들면, A 팀과 그 옆의 B 팀이 있을 때, A에서 개발한 서비스 a를 B에서도 그대로 사용하는 것이다. 이로써 개발된 서비스 단위로 재가용성을 늘리고, 필요에 따라 유연하게 사용함으로써 효율성을 증진시킬 수 있다.

하지만 MSA는 서비스가 공유되기보다 독립적으로 실행되는 것을 지향한다.

 

즉, 재가용성이 늘어나면 서비스간 결합도가 늘어나기 때문에 아주 작은 서비스 단위를 독립적으로 나누어 구성함으로써 탄력적이고 유연한 구조를 가질 수 있다. 그래서 MSA는 서비스를 공유하기보다 새로 개발하여 구성한다. (SOA에서 언급되는 서비스보다 작은 아주 작은 서비스이기 때문에)

 

두번째로 서비스간 통신 방식이다.

 

SOA는 SOAP, WSDL, UDDI, ESB 등 서비스간 통합적이고 공통적인 방식으로 구성되고 통신한다. 그래서 서비스간 결합도가 증가한다.

하지만 MSA는 Restful API 방식으로 서비스 제공자가 외부로 나타낸 API를 통해 통신한다. 따라서 서비스간 결합없이 독립적인 환경과 통신이 가능하다.

 

SOA와 MSA 모두 서비스 지향 설계 방식이다.

 

하지만 MSA는 (SOA 보다 작은) 아주 서비스 단위로 독립적으로 소프트웨어를 구성하기 때문에, 보다 민첩하고 유연한 구조가 필요한 환경에서 적합한 설계 방식이다.

MSA 장점/단점

장점

• 결함 격리가 잘된다.
• 서비스 독립적 배포/확장 가능하다.
• 크고 복잡한 어플리케이션을 지속 전달/배포 가능하다
• 서비스 규모가 작아 관리가 쉽다.

단점

• 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵다.
• 여러 서비스에 걸친 기능을 배포시 잘 조정해야한다.
• MSA 도입 시점을 결정하기 어렵다.

4+1뷰 모델

• 논리뷰 : 클래스, 패키지
• 구현뷰 : 빌드 결과물 jar, war
• 프로세스 뷰 : 런타임 컴포넌트 프로세스간 통신(IPC)
• 배포뷰 : 머신 간의 관계

분해과정 장애물

• 네트워크 지연
• 서비스간 동기 통신으로 인해 가용성이 떨어짐 → 자기 완비형 서비스 필요
• 데이터 일관성 유지 어려움 → 사가 패턴으로 유지 가능
• 어플리케이션 도처에 숨어 있는 만능 클래스 → DDD 적용 필요

IPC(프로세스 간 통신)

상호 작용 스타일

• 일대일/일대다 방식
• 동기/비동기 방식

RPI 란

클라이언트가 서비스에 요청을 보내면 서비스가 처리 후 응답을 회신하는 IPC이다.

프로토콜 종류는 REST, gRPC 등 여러가지가 있다.

• REST(동기 RPI)
  • 장점
    • 단순하고 익숙하다
    • 포스트맨, curl 등 도구 이용해 테스트 가능
    • 요청/응답 스타일의 통신 직접 지원
    • 중간 브로커가 필요하지 않기 때문에 아키텍처가 단순해진다.
  • 단점
    • 요청/응답 스타일의 통신만 지원한다.
    • 가용성이 떨어진다.
    • 서비스 위치(URL)을 클라이언트가 알고 있어야한다.
    • 요청 한번으로 여러 리소스를 가져오기 오렵다
    • 다중 업데이트 작업을 HTTp 동사에 매핑하기 어려울때가 많다.
• gRPC(동기 RPI)
  • gRPC는 다양한 언어로 클라이언트/서버를 작성할 수 있는 프레임워크이다.
  • 이진 메시지 기반의 프로토콜이므로 API를 우선 정의 해서 설계해야한다.
  • 이진 메시지를 HTTP/2 를 통해 교환한다.
  • 장점
    • 다양한 업데이트 작업이 포함된 API 를 설계하기 쉽다.
    • 양방향 스트리밍 가능
    • 다양한 언어로 작성된 클라이언트/서버 연동 가능
  • 단점
    • 자바스크립트 클라이언트가 하는일이 REST/JSON 기반 API 방식 보다 더 많다.
    • 구형 방화벽은 HTTP/2 지원안함
• 회로 차단기 패턴
  • 연속 실패 횟수가 주어진 임계치를 초과하면 일정 시간 동안 호출을 즉시 거부하는 RPI 프록시다
  • JAVA는 넷플릭스 히스트릯 라이브러리가 있고 닷넷은 폴리라는 러이브러리가 있다.
• 서비스 디스커버리
  • 자가 등록 패턴
    • 자신의 API 레지스트리 위치를 일정 주기로 등록한다.
  • 클라이언트 디스커버리 패턴
    • 서비스 호출전 서비스 레지스트리에 서비스 인스턴스 목록을 요청해 넘겨 받고 연동을 한다.

트랜잭션 로그 테일링

트랜잭션 로그를 테일링하여 DB에 반영된 변경분을 발행한다.

• 디비지움 : DB 변경분을 아파치 카프카 메시지 브로커에 발행하는 오픈소스
• 링크드인 데이터버스 : 링크드인에서는 데이터버스를 이용하여 다양한 파생 데이터 저장소를 레코드 체계와동기화 한다.
• DynamoDB 스트림즈 : DynamoDB 스트림즈는 최근 24시간동안 테이블 변경분에 대해 데이터를 갖고 있는다. 이를 이용해 이벤트로 발행할수있다.
• 이벤추에이트 트램 : Mysql 빈로그(binlog), Postgres WAL 폴링을 응용해서 카프카로 발행한다.
• 이 외에도 Mysql, Postres, MongoDB 에서 제공하는 오픈 소스 프레임워크가 있다.

트랜젝션 사가 패턴

• 코레오그래피 : 의사 결정과 순서화를 사가 참여자에게 맡깁니다. 사가 참여자는 주로 이벤트 교환 방식으로 통신
  • 장점
    • 단순함, 느슨한 결합
  • 단점
    • 이해하기어렵다 : 오케스트레이션 사가와 달리 사가를 어느 한곳에 정의한것이 아니라서 여러 서비스에 구현 로직이 흩어져 있다.
    • 서비스 간 순환 의존성
    • 단단히 결합될 위험성
• 오케스트레이션 : 사가 편성 로직을 사가 오케스트레이터에 중앙화 한다. 사가 오케스트레이터는 사가 참여자에게 커맨드 메시지를 보내 수행할 작업을 지시한다.
  • 장점
    • 의존 관계 단순화 : 오케스트레이터는 참여자에게 의존하지만 그 반대는 성립되지 않는다 순환 의존성은 발생하지 않음
    • 낮은 결합도
    • 관심사를 분리하고 비즈니스 로직을 단순화

비정상 개요

• 소실된 업데이트 : 한 사가의 변경분을 다른 사가가 미처 못 읽고 덮어 쓴다.
• 더티 읽기 : 사가 업데이트를 하지 않은 변경분을 다른 트랜잭션이나 사가가 읽는다.
• 퍼지/반복 불가능한 읽기 : 한 사가의 상이한 두 단계가 같은 데이터를 읽어도 결과가 달라지는 현상.

사가의 구조

• 보상 가능 트랜잭션
• 피봇 트랜잭션
• 재시도 가능 트랜잭션

비격리 대책

• 시맨틱 락 : 레코드에 무조건 플래그를 셋팅
• 교환적 업데이트 : 어떤 순서로도 실행 가능하게 설계(인출 후 입금 등)
• 비관적 관점
• 값 다시 읽기 : 소실된 업데이트를 방지하는 대책
• 버전 파일 : 레코드에 수행한 작업을 하나하나 기록하는 방법
• 값에 의한

애그리거트

도메인간 불분명한 경계를 도메인 모델을 애그리거트로 구성한다. 각 애그리거트는 한 단위로 취급 가능한 객체망이다.

규칙

• 애그리거트 루트만 참조하라
• 애그리거트 간 참조는 반드시 기본키를 사용하라
• 하나의 트랜잭션으로 하나의 애그리거트를 생성/수정하라

이벤트 소싱

이벤트 소싱은 비즈니스 로직을 구성하고 애그리거트를 저장하는 또 다른 방법이다. 애그리거트를 일련의 이벤트 형태로 저장한다.

단점

• 메시징 기반 어플리케이션이라 복잡
• 데이터 삭제가 어렵다
• 이벤트 저장소를 쿼리하기 어렵다
• 이벤트를 개량하기 어렵다

쿼리구현

API 조합 패턴

서비스 클라이언트가 데이터를 가진 여러 서비스를 직접 호출하여 조합하는 패턴

• API 조합기 구성 방법
  • 서비스 클라이언트를 API 조합기로 임명
  • API 게이트웨이를 사용
  • API 조합기를 스탠드 얼론으로 사용
• 단점
  • 오버헤드 증가
  • 가용성 저하 우려
  • 데이터 일관성 결여

CQRS(커맨드 쿼리 책임 분산) 패턴

여러 서비스에 있는 데이터를 가져오는 쿼리는 이벤트를 이용하여 해당 서비스의 데이터를 복제한 읽기 전용 뷰를 유지한다.

RDBMS에 트랜잭션을 걸어 레코드를 관리하고 텍스트 검색 쿼리는 ElasticSearch, 솔라 등의 텍스트 검색 DB를 사용한다.

장점

• MSA 효율적인 쿼리가 가능하다
• 다양한 쿼리를 효율적 구현가능
• 이벤트 소싱 어플리케이션에서 쿼리가 가능

단점

• 아키텍처가 복잡
• 복제 시차(Replication Lag)를 신경 써야한다

API 게이트웨이

요청 라우팅, API 조합, 엣지 기능(인증, 인가, 사용량 제한, 캐싱, 지표수집, 요청 로깅)

넥플릭스 주울, 스프링 클라우드 게이트웨이 등 사용해야함.

장점

• 내부 구조를 캡슐화

단점

• 개발, 배포, 관리를 해야하는 고가용 컴포넌트가 하나 더 늘어난다.

리액티브 프로그래밍 추세

• 자바8 CompletableFutures, 리액터 프로젝트 Mono, RxJava(넥플릭스), 스칼라 Future

테스트 전략

목/스텁을 이용한 테스트

종류

• 단위테스트
• 통합테스트
• 컴포넌트 테스트
• 종단 간 테스트

컨슈머 주도 계약 테스트 : 서비스가 클라이언트의 기대에 부합하는지 확인

프로덕션 레디 서비스

액세스 토큰을 사용하여 API 게이트웨이에서 인증을한다.

• 난독화 토큰(UUID)
• 투명 토큰(JWT)
• Oauth 사용

Oauth 2.0

• 인증서버 : 사용자 인증 및 액세스/리프레시 토큰 획득 API 를 제공
• 액세스 토큰 : 리소스 서버 접근을 허가하는 토큰, 스프링 Oauth 는 JWT 사용
• 리프레시 토큰 : 클라이언트가 새 액세스 토큰을 얻기 위해 필요한 토큰
• 리소스 서버 : 액세스 토큰으로 접근을 허가하는 서비스
• 클라이언트 : 리소스 서버에 접근하려는 클라이언트

서비스 메시

회로 차단기, 분산 추적, 서비스 디스커버리, 부하분산, 롤 기반 트래픽 라우팅 등 다양한 관심사가 구현된 네트워킹 계층을 통해 서비스를 드나드는 모든 네트워크 트래픽을 라우팅한다.

쿠버네티스

컴포넌트

• API 서버 : kubectl CLI 에서 사용하는 서비스 배포/관리용 REST API
• etcd : 클러스터 데이터를 저장하는 키-값 NoSQL DB
• 스케줄러 : 파드를 실행할 노드를 선택
• 컨트롤러 관리자 : 컨트롤러를 실행한다.
• 큐블릿(kubelet) : 노드에서 실행되는 파드를 생성/관리한다.
• 큐브 프록시 : 여러 파드에 부하를 분산하는 등 네트워크를 관리
• 파드 : 어플리케이션 서비스

핵심 개념

• 파드 : 쿠버네티스의 기본 배포단위이다.
• 디폴로이먼트 : 파드의 선언형 명세이다. 롤링 업데이트 / 롤백 기능이 지원
• 서비스 : 정적 네트워크 위치를 제공한다.
• 컨피그맵 : 환경 변수를 정의

 

배포 전략(롤링/카나리/블루그린)

롤링 : 구버전 신버전 서버를 점진적으로 증가시키며 배포하는 일반적인 방법

카나리 : 카나리 배포는 위험을 빠르게 감지 할 수 있는 배포 전략이다 지정한 서버 똔느 특정 user에게만 배포했다가 정상적이면 전체를 배포한다.

블루그린 : 구 버전을 블루, 신 버전을 그린이라고 해서 붙여진 이름이다. 신버전을 배포하고 일제히 전환하여 모든 연결을 신버전을 바라보게 하는 전략이다.