[인프런 강의] 마이크로서비스 아키텍처 와 MSA 패턴 이해

[SAgiKPJH]

https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard

[SAgiKPJH]

용어

• SOA
  • 서비스 지향 아키텍처(Service Oriented Architecture, 약칭 SOA)
  • DB 하나에 여러 서비스
• 마스터 데이터
  • 기준정보와 같은 마스터 데이터
• 서킷 브레이크 패턴

[SAgiKPJH]

0

1

[SAgiKPJH]

아키텍처

🧾아키텍처 개념

• 아키텍처 결정 (목적 예-가용성 신뢰성,,)
• 아키텍처 특성 (시스템의 제약 조건, 규칙, 스타일)
• 설계 원칙 (표준, 가이드라인)
• 시스템 구조

역할분담

• 아키텍쳐 특성, 구조 담당
• Class 설계 담당
• Source 구현 담당

깨알 지식 MVC

• View <-(Model)-> Controller
• View <-(Model)-> ViewModel

📑아키텍처 순서

• 아키텍처 스타일 (기술 변화 흐름을 반영)
  • 레이어드(표준)
  • 파이프라인 & 피터 (파이프라인 아키텍처)
  • 마이크로커널 (plug-in 아키텍처)
    • 구글 크롬처럼 플러그인(솔루션, 도구)들을 통해 기능 확장, 변경
  • 서비스 기반
  • 이벤트 기반
  • 공간 기반
  • 오케스트레이스 기반 스타일 지향 (역사적으로 실패한 스타일)
  • 마이크로서비스

레이어드 아키텍처

• 관심사 분리
• Layer
  • Presentation -> Buisness -> Persistence -> DataBase Layer
  • 예) HTTP프로토콜 처리 -> 비즈니스 로직 처리 -> 데이터 저장 처리 -> Query문
• 아키텍처 싱크홀 안티 패턴
  • ByPass, 그저 Call하는 것으로써, 비즈니스 없고 바로 호출할 때 Layer들을 타야 하는 게 번거로움

파이프라인 & 피터 아키텍처

• Producer (프로세스 시작점 소스), Transformer, Tester, Consumer(종착, 데이터 저장, 화면 출력)

서비스 기반 아키텍처

• 탄생
  • Component(의미있는 Class들의 묶음)를 서비스별로 묶은 것
  • 이미 만들어놓은 서비스들을 조합해서 만드는 것
  • Product Line Engineering (PLE) : 제품 라인 엔지니어링
    • 제품 라인이라고 불리는 유사한 제품군을 효율적인 방식으로 개발하고 관리하기 위한 방법론.
    • 망함
• DB 구조 스타일
  • 통합 DB
  • 도메인별 DB
  • 조회용 DB
  • 서비스별 DB
• 서비스 내부 설계
  • 레이어드 설계 vs 도메인 설계 (도메인 분할, 기능에 따라 분할)

이벤트 기반 아키텍처

• 확장성이 뛰어난 고성는 애플리케이션 개발에 널리 쓰이는 비동기 아키텍처
  • SOA에 의존성 분리를 위해 사용되고 있다.
  • 장점 : 확장성, 의존성 없음
  • 단점 : 트랜잭션 통제 어려움, 데이터 비일관성(유실시 문제)
• RabbitMQ, Kaffka, ActiveMQ등 경량 메시지 브로커 활용
• 두 가지 스타일
  • 이벤트 활용
  • 중재자 토폴로지 (중간에서 하나가 관리, 확장성이 부족)

공간 기반 아키텍처 스타일

• 높은 확장성, 탄력성, 동시성
• 예측이 어려운 동시 유저수에 대한 애플리케이션에 유용
  • 캐시를 내부에 갖는다.
  • 데이터 일관성 문제는 나중에 처리할 수 밖에 없다.
• 데이터 펌프, 데이터 라이터, 데이터 리더

오케스트레이션 기반 서비스 지향 아키텍처

• 서비스 지향이 맞긴 하지만,,,
• 서비스 기반 은 실패했다는 얘기가 바로 이 아키텍처, SOA가 만한 것이 바로 이 아키텍처를 얘기하는 것.
  • MSA는 서비스기반의 한 유형이다.
• 재사용성을 극대화한 내용 -> 서비스간 의존성 높아짐
• 결국 실패함

마이크로서비스 기반 아키텍처

• 클라우드와 함께 어우러져 성공
  • (어쩌면 클라우드x오케스트레이션 조합도 성공했었을지도)
• 재사용성 보다는 중복을 강조
  • DB간 일관성이 없기 때문에 Event 저장소 필요 -> RabbitMQ, Kaffka가 유망해짐
• 고도의 디커플링을 추구

😀아키텍처 스타일 결정

• 결정 의사
  • 아키텍처 유형은 계속 변한다
  • 결정기준 (도메인, 데이터 아키텍처, 조직 역량, 개발 프로세스)
  • 모노리스 vs 분사
  • 데이터 어디에 둘 것인가
  • 서비스간 통신 방법 (비동기, 동기)
• Trade-off
• 어떻게 보다는 왜가 중요

[SAgiKPJH]

MSA

MSA 아키텍처 구성요소

• 여려개의 서비스간의 연계를 통해 시스템을 구축하는 SOA의 범주에 있다.
  • SOA는 저장소 통합
  • MSA는 저장소 격리
• 내부/외부 아키텍처
  • 

MSA 패턴

• 
  • 하늘색 부분이 MSA 구성하기 위한 패턴들
  • 
  • 내부(application) / 외부 (platform, infra)
• 다양한 MSA 생태계의 제품들을 잘 정리해주는 CNCF 재단
• 패턴들
  • DevOps Infra
  • Cloud Infra
  • Service 운영에 필요한 Infra

[SAgiKPJH]

Infra 패턴

가상 머신, 컨테이너

• IaaS (Infra) vs PaaS (Application) vs CaaS (contrainer) vs FaaS (Func) vs SaaS (Software)
• VM vs Container
• 컨테이너 -> Docker
• 컨테이너 오케스트레이션
  • 스케줄링, 장애복구, 컨테이너 배포, 스케일링, 로드밸런싱, 네트워킹 자동화
  • 예) k8s(Kubernetes), MESOS, Docker Swarm(쿠버네티스가 이김)
• Replica (컨테이너 집합)

컨테이너 오케스트레이션

CI/CD (DevOps)

CSP

[SAgiKPJH]

운영 패턴

• 
• 필요성
  • 
• 과정
  • 
• Netflix와 AWS 그리고 Spring Cloud
• BFF, API GW
• Backend For Frontend
• 라우팅, 로드밸런싱, 서비스 탐색
  • 
• spring cloud slueth

인증

• 인증/인가의 흐름
  • 인증/인가 개별 소지
    • 
  • 인증/인가 서비스
    • 
  • 인증/인가 게이트 웨이
    • 
    • stateless 방식
      • 
      • 
    • stateful 방식
      • 

설정 관리 (Config Management)

• The Twelve-Factor App
  • SaaS를 만들기 위한 방법론, 인프라에 독립적인 서비스 만들기 위한 지침
• 설정 관리
  • k8s는 ConfigMap, Secret를 사용

중앙화된 로깅, 추적, 매트릭, 서킷브레이크

• 추적
  • 
• 서킷 브레이크 패턴
  • 
  • 

서비스 메시

• 서비스 발전

  • 

• Mesh

  • 
  • 
  • 

• 

[SAgiKPJH]

클라우드 전환

• 애플리케이션(요부분)-플랫폼-인프라
  
• Application Modernization
• 전환 방법 제시
  
  
  
  

[SAgiKPJH]

애플리케이션 패턴

리엑티브 선언, Base 개념

마이크로 프론트 엔드

통신 패턴

저장소 분리, 공유, 위임

• 저장소 격리 패턴
  • 독립적인 기능을 위해 기능별 마이크로 서비스 저장소를 분리한다
  • 데이터 정합성 문제 발생
• 위임 패턴
  • 
  • 항공편 테이블은 안티패턴
• (문제) (주문이력 데이터베이스 따로 존재, 동기)
  • command와 query 분배 + 이벤트로 업데이트 (비동기)
  • 

분산트랜젝션 (SAGA), CQRS, 이벤트 소싱

• Saga
  • 
  • 
  • 
  • 예)
• CQRS
  • 
  • 
• 이벤트 소싱
  • 
  • 

[SAgiKPJH]

내부 아키텍처

• 예)
• DI
  • 레이어드 아키텍처 문제
  • DI로 개선
• 헥사고날 아키텍처
  • 
• 클린은 생략
• 예)
  • 

[SAgiKPJH]

[SAgiKPJH]

Microservice 내부 아키텍처 와 EventStorming 설계

• 링크 : https://www.inflearn.com/course/%EB%8F%84%EB%A9%94%EC%9D%B8%EC%A3%BC%EB%8F%84-%EC%84%A4%EA%B3%84-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4

[SAgiKPJH]

• 시스템 복잡성
  • 
• API 설계 Contract
  • REST API
    • 멱등성(Idempotent), Stateless
    • REST API 성숙도 모델 (https://martinfowler.com/articles/richardsonMaturityModel.html)
      • HATEOAS : 한 가지 요청에 대해서 가능한 API 요청 목록을 추가로 반환하는 내용
    • API 설계서, Swagger로도 제공

도메인 주도 설계

• MicroService를 도출할 때 대중적으로 쓰의는 설계
• backend
• 목적: 응집성을 높이고 결합도를 낮춘다.
• 이벤트 스토밍 기법을 통해 쉽게 전략적 설계 진행
  • API
  • DATA
  • EVENT

도메인 주도 설계의 의의

• 마이크로서비스를 어떤 기준으로 분리할 것인가?
• 서비스 간은 어떻게 연계할 것인가?
• 어떤 이벤트에 의해 마이크로서비스는 서로 반응하나?

* 전략적 설계와 내부 설계

도메인 주도 설계

• 그 조직의 비즈니스 전략과 소프트웨어를 통해서 얻고자 하는 가치
• 비즈니스 도메인: 기업의 주요 활동 영역
• 하위 도메인 (Sub Domain) : 비즈니스 활동의 세분화된 영역
  • 핵심(Core)
    • 경쟁업체와 다르게 수행하고 있는 것
    • 복잡하지만 경쟁력
    • 예) 구글 검색 우선순위 알고리즘
  • 일반(Generic)
    • 모든 회사가 같은 방식으로 수행하는 비즈니스 활동
    • 복잡하고 구현이 어려우나, 알려진 영역(경쟁력 적은)
    • 예) 인증
  • 지원(Supporting)
    • 회사 비즈니스 지원, 간단한 기능
    • 예) CRUD
• 하위 도메인 식별을 통해 도메인 유형을 확보하고 설계에 기여하자.
  • 식별 방법 : 이미 존재하는가?

유비쿼터스 언어와 도메인 모델, 바운디드 컨텍스트

• 이전괴 현대
  • 
• 유비쿼터스 언어
  • 
• 문제
  • 
• Bounded Context
  • 
• Bounded Context 내부에 유비쿼터스 언어로 도메인 모델 구성할 것
  • 
• Bounded Context별로 언어 혼동 방지 (Customer에서 변경)
  • 

컨텍스트 매핑

• 파트너쉽
• 공유영역

• 대부분은 공급자-소비자 패턴
  • Conformist (순응주의자) : u(상류)가 d(하류) 모델을 사용
  • ACL (충돌 방지 계층)
    • d(하류)가 모델을 직접 제공하지 않고 변환 과정(Layer)을 거쳐 제공
    • 보통 레거시의 경우 사용
  • OHS (오픈 호스트 서비스)
    • 제공할 모델별(또는 BC별로)로 다르게 제공 (예 사용자별 모델관리)
    • PL(공표된 언어), 공개 프로토콜, 명세가 필요
• 분리형 노선 (협력 안하는 경우)
  • 특정 기능을 중복으로 두는게 더 저렴한 경우 사용
• 매핑관계 예시
  • 
  • 
    • 실선은 동기호출
    • 점선은 비동기 호출

[SAgiKPJH]

전랙적 설계 기법 실습

이펜트 스토밍 워크샵

• 1. 20분동안 도메인이벤트
  • 
• 2. 핫스팟 지정
• 3. 커맨드
  • 없는게 있는 이유 (하나의 커맨드에 여러개의 이벤트가 동작 하기 때문)
  • 
• 4. 엑터
• 5. 정책 (policy)
• 6. 외부 시스템
• 7. 어그리거트
  • 
• 8. 바운드리 컨텍스트
  • 
  • 
• 결과
  • 
  • 

[SAgiKPJH]

도메인 주도설계

• 비즈니스 로직을 표현하는 방법 소개

트랜잭션 스크립트 패턴

• 전통적인 방법(마틴 파울러)
  • 
• 직접 DB Query를 통해 데이터접근
• 절차지향이며, DB 직접 접근 가능
• 장점
  • 간단한 비즈니스인 경우 유리
  • 이해하기 좋다
• 단점
  • 비슷한 sql query가 많아져서 비즈니스 관리 복잡해짐
  • DB, SQL에 종속되어 있다. 기술에 종속되어 있다.

액티브 레코드 패턴 (Active Record Pattern)

• 비즈니스 로직이 단순한 경우
• DB를 바로 조회하는 것이 아니라 객체모델을 통해 접근하도록 구성
  • 
• Anemic Domain Model (빈약한 도메인 모델)
  • 객체에 일부 비즈니스 담고, 서비스에 Flow 및 비즈니스를 담는다. 즉 도메인 모델과 서비스를 구성
  • 각 도메인 객체 (예: 엔티티)에 Get, Set활용. 즉 간단한 데이터 접근 로직만 구현
  • JAP, ORM으로 구현 가능
• DB 접근의 최적화하는 Transaction Script 패턴의 유형.
• 비즈니스는 단순하지만 복잡한 자료 구조인 경우에도 유리

도메인 모델 패턴 (Domain Model Pattern)

• 복잡한 비즈니스는 도메인 모델 패턴
  • 
• 한 도메인 모델이 너무 복잡해지거나 무거워질 수 있기에, 잘 쪼개야 한다. -> Aggregate 패턴
• 비즈니스 로직 구현 : 도메인 모델의 행위 + 자료구조
• 예) Get, Set 뿐만 아니라 주소 변경과 같은 비즈니스 포함

어그리게이트 모델 패턴 (Aggregate Model Pattern)