[MSA] 5. MSA 설계 동향과 기술 개념 설명

steve·2024년 3월 4일

msa

Backend

목록 보기

12/17

개요

MSA 설계 동향을 알아본다
저장소 격리 및 분산 트랜잭션 SAGA 패턴 학습
비동기(EDA) 호출
Service Mesh의 개념 및 Istio 활용 방법에 대해 배운다

어플리케이션 현대화 유형과 클라우드 전환 프로세스

Cloud Modernization 전략
일반적으로 대부분(80%)의 규모가 큰 기업에서 클라우드 전환 시 Rearchitect 단계까지 진행
Rebuild는 마이크로서비스를 새로 개발하는 고도화 단계임
단계별 상세 설명 도표
1. Rehost
- 아키텍처 변화 없이 인프라만 Cloud로 변경
1. Refactor
  - 컨테이너화 및 DevOps 인프라 구축
  - 수평 확장이 가능하도록 Application 리팩토링
  - 세션 공유 처리, 내부 파일 시스템 의존 제거, 서드 파티 솔루션 클라우드 지원 확인 등
2. Rearchitect (Re-platform)
  - 클라우드 스토리지의 Backing 서비스, 오브젝트 DB 등 클라우드 서비스 제공 플랫폼 활용
  - 장애 고려 설계, 모니터링, Metric 기반 서비스 활용 등
3. Rebuild
  - Application 기능별 서비스로 분리하여 재개발 수준의 작업 필요
  - 저장소 격리
MSA 패턴 가이드

설계 동향 - 리액티브 선언

리액티브 선언문 (www.reactivemanifesto.org/ko)
- 사용자 입장의 응답성 가치가 중요하다
- 메시지 기반으로 이벤트 주도 아키텍처를 구현하여 유연성과 탄력성을 갖춰야 한다
응답성 vs 성능
- 프론트에서 게시글 작성 시 서버의 응답을 받는 것이 아닌 작성한 텍스트를 그대로 먼저 보여주고 비동기로 서버에서 처리하는 형태
- ACID vs BASE 일관성 모델
- Atomic, Consistent, Isolated, Durable
  - 위 사진의 좌측 도표
  - Locking 걸리는 시간동안 정확한 데이터를 얻을 수 있다
- Base Availability, Soft-state, Eventual consistency
  - Read/Write를 분리하여 가용성을 우선시 하여 당장 데이터가 안맞더라도 빠르게 대응 가능

마이크로서비스 간 비동기 호출(EDA)

별도의 분산 트랜잭션들이 각각 수행하고 흐름은 비동기 이벤트를 통해 처리 (Event Driven Architecture)
리액티브 선언은 이벤트 주도 설계를 추구함
비동기 관련 문제 고려 필요
- 워크플로 프로세스 패턴
  - 에러 발생 시 워크플로 프로세스에 보내고 다음 메시지를 처리
  - 워크플로 프로세스가 에러를 받아서 조치를하여 메시지를 수정하여 메시지큐로 다시 던짐
  - 워크플로 프로세스가 자동으로 해결하지 못한 에러에 대해서는 대시보드로 전달하여 관리자가 수동으로 확인 후 처리하는 프로세스
- 데이터 소실 처리
  
  1. 큐가 다운된 경우 → 퍼시스턴트 큐를 사용하여 메시지를 브로커서버 스토리지에 저장
  2. 메시지 처리 전 장애 발생 → 큐가 전달되었는지 여부만 확인하기 위한 첫 단계만 동기 처리
  3. 데이터 에러로 인한 메시지 저장 실패 → ACID 트랜잭션

저장소 격리

독립적인 배포에 대한 MSA의 장점을 가져가려면 저장소 격리를 해야 함
저장소 격리 준비 단계에서 고려할 수 있는 위임서비스
- 각 마이크로서비스가 저장소가 격리되지 않은 하나의 테이블을 같이 사용하게 되는 경우, 위임서비스를 두어 특정 마이크로서비스에서만 해당 저장소를 접근할 수 있도록 위임서비스 활용
저장소 격리에 따른 데이터 정합성 문제를 해결하기 위한 패턴
- 좌측 각 제품/주문/고객/배송 서비스의 이벤트를 비동기로 처리하여 최종적으로 주문이력서비스에서 처리
- 동기 처리 및 비동기 처리를 적절하게 선택

분산 트랜잭션 처리 및 이벤트 소싱

분산 트랜잭션 패턴
- ACID 적용이 어려움 (Two Phase Commit)
SAGA 패턴
- 로컬 트랜잭션을 걸어놓고 이벤트를 전달하여 다른 마이크로서비스의 트랜잭션이 문제가 없을 시 트랜잭션 완료처리하여 비즈니스 정합성을 높임
- 이벤트 기반 메시지브로커를 사용하는 패턴을 코레오그래피라고도 함
- 보상트랜잭션을 고려해야 함
중재자 패턴
- 솔루션 도입 필요
도식화
CQRS
- CUD와 R의 분리를 통한 최적화 전략
이벤트 소싱
- 상태가 아닌 트랜잭션 자체를 저장하는 전략 (쓰기 최적화)
- 동시성 문제 해결 가능
- 이벤트 소싱을 위한 프레임워크 사용 필요 (쓰기 작업의 최적화 까지는 필요하지 않기 때뭄에 실무에서 이벤트 소싱 적용하지는 않음)
- 실무 CQRS
  - 마이페이지의 데이터들을 읽기전용으로 조회하는 서비스를 만들어 CQRS 적용 함
Service Mesh
- AWS의 경우 여러 마이크로서비스간 호출이 점점 많아짐에 따라 인스턴스 수도 증가하게 되고 복잡해짐
- 초창기 1.0 마이크로서비스는 스프링클라우드로 구현하여 각종 오픈소스도구를 활용해 개선점 보완
  - 이후 2.0 세대부터 컨테이너 환경이 탄생하게 되면서 스프링클라우드 뿐만 아니라 노드 등 다른 서버엔진으로도 구동하고, 오픈 시프트와 쿠버네티스가 대세로 자리잡음
  - 3.0세대부터 이스티오가 쿠버네티스와 임베디드되어서 기능을 지원
- istio를 활용하면 서비스메쉬라는 패턴을 지원함
  - 탄생 배경 : 마이크로서비스 개발 시 여러 오픈소스도구를 사용할 때 필요한 정보들을 제공해줘야 하기 때문에 필요한 라이브러리를 설치해야하는 부담이 있기 때문에 비즈니스로직에 집중할 수 없는 상황 발생
  - pod에서 사이드카 프록시가 서비스 간 호출 설정을 담당함
  - 비즈니스 로직과 사이드프록시의 역할 분리
    - 녹색: 비즈니스 로직
    - 파란색 : 사이드프록시
  - 서비스 로직과 통신의 분리
    - Istio와 k8s 를 사용하면 스프링클라우드 없이도 MSA 구현 가능
  - 아키텍트는 어떤 아키텍쳐 스타일을 선택할 건지 결정을 해야함
    - 아래 도표 참고하여 필요한 항목에 대해 커버할 수 있는 아키텍쳐스타일을 선택해야 함