코딩성장스토리

MSA 추상적인 개념 잡아가기 본문

백 엔드

MSA 추상적인 개념 잡아가기

까르르꿍꿍 2024. 5. 28. 16:06

마이크로서비스 아키텍쳐 (MicroService Architecture , MSA)

각각을 마이크로하게 나눈 독립적인 서비스를 연결한 구조

마이크로 서비스와 모놀리식 비교

MSA의 장점 

  • 변경된 서비스만 빌드,배포하면 되므로 배포시간이 단축 됩니다.
  • 일부 서비스의 오류가 다른 서비스에 영향을 안끼치므로 다른 서비스는 사용이 가능합니다. 
  • 다른 서비스와 독립적으로 확장(scale-out) 가능 합니다.

 

MSA의 단점 

  • 마이크로서비스에 대한 내부 경험 부족
  • 복잡성이 늘어남 ( 다른 서비스와 함꼐 트랜잭션 관리)
  • 구축에 소요되는 기간 및 비용에 대한 불확실성 

위에 까지는 그냥 잠깐 공부하면 아는 내용이었습니다. 개념적으로는 이해가 안되고 제가 받아들이기 힘든 부분이 몇가지 있었습니다.

  1. 각 서비스 DB에 연관되어 있는 데이터 처리 (조인쿼리)
  2. 트랜잭션 관리는 어떻게 하는지
  3. 각 서비스 간의 통신 과정을 어떻게 하는지 

이제 위에 대한 궁금증을 해결해준 글들을 정리해보겠습니다. (다른 글들 참고를 많이 했습니다... 이미 좋은 글이 많기에)

아래에 들어가기 전에 아래 글 시리즈 정독하면 추상화 개념을 좀 구체화시킬수 있을 것 같습니다. (Spring 기반 MSA) 

https://sjh9708.tistory.com/120

 

[Spring Cloud] Microservice(MSA) 구축 : (2) Eureka Server와 Gateway, Microservice 서버들의 연결

이전 포스팅에서 MSA 아키텍쳐의 구조와 Spring Cloud에 대한 소개를 하였었다. 이번 포스팅에서는 이전에 소개했던 아키텍쳐의 구성 요소들인 Gateway, Naming Server, MSA Service들을 만들어보고 연동하는

sjh9708.tistory.com

 

1. 각 서비스 DB에 연관되어 있는 데이터 처리(조인쿼리)

연관 데이터 처리를 위한 두가지 패턴 

1. API Aggregation Pattern

API Aggregation Pattern은 여러 서비스로부터 정보를 모아서 하나의 응답으로 제공하는 패턴이다.

  • 장점
    • 클라이언트는 여러 서비스로부터 데이터를 요청하는 대신 한 번의 요청으로 필요한 모든 데이터를 얻을 수 있다.
    • 클라이언트의 로직이 단순해진다. 서비스 간의 상호작용이 API 게이트웨이 내에서 수행되기 때문이다.
      • 프론트는 어차피 API 게이트웨이를 통해서 받기에 프론트가 고민해야할 문제는 아니다.
    • 각각의 마이크로서비스는 독립적으로 진화하며, API 게이트웨이만 적절히 업데이트하면 됩니다.
  • 단점
    • API 게이트웨이가 병목 지점이 될 수 있습니다.
      • MSA에 모든 트래픽이 API 게이트웨이를 지나기에 여러 서비스에 대한 요청을 하면 네트워크 지연이 있을 가능성이 높다.
    • 여러 서비스의 응답을 모아 처리하는 로직이 복잡해질 수 있습니다.

2. CQRS(Command Query Responsibility Segregation) Pattern

CQRS는 시스템의 명령(Command) 부분과 조회(Query) 부분을 명확히 분리하는 패턴이다.

MSA 환경에서 도메인 복잡성을 관리하고 확장성을 향상시키기 위해 사용된다.

  • 장점
    • 명령과 조회를 분리함으로써 각각의 부분을 독립적으로 확장할 수 있다
    • 읽기와 쓰기 모델을 분리함으로써 각 모델에 최적화된 성능 튜닝이 가능한다.
    • 읽기 전용 모델을 따로 설계할 수 있기 때문에, 조회 성능과 구조를 최적화할 수 있다.
    • CQRS는 이벤트 소싱과 잘 결합됩니다. 이로 인해 시스템의 상태 변경 내역을 추적하고 재생할 수 있다.
  • 단점
    • 전통적인 CRUD 패턴보다 구현이 복잡해질 수 있다.
    • 명령과 조회 모델을 동기화하는 것이 도전적일 수 있다.

구체화한 참고 링크  -> 이미 구현해주시고 좋은 글인거 같아 읽어보면 좋을 것 같습니다.

https://velog.io/@devty/MSA-Phase-8.-CQRS

 

MSA Phase 8. CQRS

MSA의 태생적인 한계모든 서비스는 각 프로덕트로서 도메인을 책임진다.서비스/도메인 간 협럽과 디펜던시가 지양된다.또한 각 서비스의 DB는 각 서비스를 통해서 접근해야한다. (데이터 오너쉽)

velog.io

 

2. 트랜잭션 관리는 어떻게 하는지 

트랜잭션 관리를 위한 두가지 패턴 

1. Two-Phase Commit

분산 트랜잭션을 구현하는 데 널리 사용되는 패턴이며, Prepare 단계와  Commit 단계로 구성된다. 

  • Prepare Phase : 관련된 모든 서비스는 Commit을 준비하고, Transaction Coordinator에 트랜잭션을 시작할 준비가 되었음(Commit 할 준비가 되었음)을 알린다.
  • Commit Phase : 이전 단계에서 트랜잭션을 시작할 준비가 되었다면, Coordinator는 Commit을 요청한다. 만약 서비스 하나라도 실패가 발생한다면, Coordinator는 관련된 모든 서비스에 해당 트랜잭션을 롤백하도록 요청한다.

 

다음은 Two-Phase Commit 방안을 적용한 예시이다.

  1. 사용자가 요청을 보내면, Transaction Coordinator는 모든 콘텍스트 정보를 기반으로 트랜잭션을 시작한다.
  2. OrderMicroservice에 Prepare 명령을 보낸다.
  3. 그 후 InventoryMicroservice에 Prepare 명령을 보낸다.
  4. Coordinator가 두 서비스가 트랜잭션 처리 준비가 되었음을 확인하면, Commit을 요청한다.

성공 처리
실패처리

정리

two-phase commit은 분산 트랜잭션 처리를 위한 전통적인 방법이지만, Transaction Coordinator에 의존하여 모든 서비스에 대해 준비 상태를 확인하고 Rocking 상태로 변경하는 등 성능 측면에서 효율적인 방법이 아니다. 또한 NoSQL 등 일부 구현에도 지원하지 않아 제약이 있다.

 

2. Saga Pattern

2-1 .Choreography-based saga

각 로컬 트랜잭션이 다른 서비스의 로컬 트랜잭션을 이벤트 트리거 하는 방식이다. 중앙 집중된 지점 없이 이벤트를 교환하며, 모든 서비스가 메시지 브로커를 통해 이벤트를 Publish/Response 한다.

장점 

서비스가 많지 않은 간단한 워크플로우에 적합하다.

단점

새로운 서비스 추가가 필요할 시 서비스 간 연계성 파악이 중요하다. 서비스 간 이벤트를 주고받기 때문에 Cyclic Dependency 발생에 주의해야 한다.

(관련 프레임워크 : Axon Saga, Eclipse MicroProfile LRA, Eventuate Tram Saga, Seata)

 

2-2.Orchestration-based saga

Orchestrator가 중앙 집중식 컨트롤러 역할을 하고, 각 서비스에 실행할 트랜잭션을 알려주는 방법이다.

Orchestrator는 요청을 실행, 각 서비스의 상태를 확인, 실패에 대한 복구 처리한다.

장점

비교적 많은 서비스가 있는 복잡한 워크플로우에 적합하다. 서비스 및 워크플로우의 제어가 필요한 경우 또한 적합하다.

단점

Orchestrator가 전체 워크플로우를 관리하여 실패 지점이 될 수 있다.

 

참고링크

https://blog.neonkid.xyz/243

 

[MSA] 6. MSA의 트랜잭션 이야기 2 - Two-Phase commit과 Saga

이전 글에 이어서 MSA 내에서 트랜잭션을 원활히 하는 방법 2가지를 소개해드리고자 합니다. 관계형 데이터베이스와 더불어 모놀리틱 아키텍처를 도입한 서버 애플리케이션은 DB 서버에서 제공

blog.neonkid.xyz

 

3. 각 서비스 간의 통신 과정을 어떻게 하는지 

1. API 기반 통신

MSA 아키텍처에서 가장 일반적인 서비스 간 통신 방법은 API를 통한 통신입니다. RESTful API는 HTTP 프로토콜을 사용하여 서비스 간에 데이터를 교환하는 방법입니다.

장점

  • RESTful API는 간단하고 이해하기 쉽다.
  • 다른 플랫폼과 연결하기 쉽다.(대중적)

단점

  • 서비스가 서로의 위치를 알아야 함
  • 통신 오버헤드가 발생할 수 있다

2. 이벤트 기반 통신

이벤트 브로커를 사용하여 서비스 간에 이벤트를 전달합니다.

장점

  • 서비스가 서로를 직접 알 필요 없이 메시지를 교환할 수 있다.
  • 시스템의 확장성과 유연성을 크게 향상시킵니다.

단점

  •  이벤트 기반 통신은 이벤트의 추적과 관리가 복잡해질 수 있다

3. 메시지 큐를 활용한 비동기 통신

메시지 큐를 사용한 비동기 통신도 MSA 아키텍처에서 널리 사용되는 방법입니다. 메시지 큐는 서비스 간 메시지를 저장하고 전달하는 역할을 합니다.

장점

  • 서비스 간의 통신을 비동기적으로 처리할 수 있어 시스템의 부하를 분산
  • 시스템의 안정성을 높이는 데 도움이 됩니다.

단점

  • 메시지의 순서와 처리 상태를 관리해야 한다

위의 내용들을 정리 해보았는데 솔직히 아직 감이 잘 안잡히는 거 같습니다.

실제로 구현을 해보면서 구체화시키는게 제일 좋은 것 같습니다.

저작자표시 비영리 변경금지