오늘 학습한 내용
- MSA 프로젝트 과제 기술 질문
- 고객 주문 시 예상치 못한 오류로 인해 상품 서비스에서 재고를 차감 하였으나, 주문 서비스에서 에러가 발생해 주문이 정상적으로 완료되지 않았을 경우 어떻게 할 수 있을까요?
- 마이크로서비스 간의 통신에 대한 보안을 어떻게 보장할 수 있나요?
- MSA 환경에서 서로의 서비스를 의존하게 되는 의존성 순환이 발생했을때 어떻게 해결할 수 있을까요?
- 분산 시스템에서의 데이터 일관성을 어떻게 유지할 수 있을까요?
- 레거시 모놀리식 서비스를 MSA 로 전환한다고 할 때, 어떠한 이유가 있을까요?
MSA 프로젝트 과제 기술 질문
MSA 프로젝트를 제출하면서 함께 제출해야 하는 기술 질문들에 대해 정리해 보았다.
고객 주문 시 예상치 못한 오류로 인해 상품 서비스에서 재고를 차감 하였으나, 주문 서비스에서 에러가 발생해 주문이 정상적으로 완료되지 않았을 경우 어떻게 할 수 있을까요?
데이터 일관성을 어떻게 유지할 수 있는지에 대한 질문이다. 분산 트랜잭션이 적용되어야 하는데, 이를 위해 다양한 방법을 적용할 수 있다.
2PC(Two-Phase Commit)
분산 트랜잭션을 관리하는 프로토콜로, 준비(Prepare) 단계와 커밋(Commit) 단계로 나누어 트랜잭션을 처리한다.
- 준비 단계(Prepare Phase): 각 참여 노드는 트랜잭션 준비 상태를 확인하고, 준비 완료를 마스터 노드에 알린다.
- 커밋 단계(Commit Phase): 마스터 노드는 모든 참여 노드가 준비되었음을 확인하고, 트랜잭션을 커밋하도록 지시한다. 만약 준비가 완료되지 않은 노드가 있다면 트랜잭션을 롤백한다.
즉, 커밋 단계에서 주문이 에러 발생으로 인해 준비되었음을 알리지 못하게 되므로, 모든 트랜잭션은 롤백되게 되어 데이터 일관성이 유지된다.
사가 패턴(Saga Pattern)
트랜잭션을 여러 단계로 나누어 처리하고, 각 단계가 독립적으로 커밋된다. 실패 시 보상 트랜잭션을 실행하여 상태를 롤백한다.
- 주문 생성 단계: 사용자가 주문을 생성
- 결제 처리 단계: 결제 서비스가 주문 결제를 처리
- 재고 감소 단계: 재고 서비스가 주문된 상품의 재고를 감소
- 각 단계가 성공적으로 완료되면 다음 단계로 넘어가고, 실패하면 이전 단계에서 수행된 작업을 취소
이벤트 소싱, CQRS
이벤트 소싱은 시스템 상태를 이벤트로 기록하고, 이 이벤트들을 재생하여 현재 상태를 계산하는 방식이다. 상태 변경은 이벤트로만 기록되고, 상태 자체는 저장되지 않는다.
CQRS (Command Query Responsibility Segregation)는 명령(Command)과 조회(Query)를 분리하는 패턴이다. 상태를 변경하는 명령과 데이터를 조회하는 쿼리를 별도로 처리하여 성능을 최적화한다.
이벤트 소싱
주문 서비스: 고객의 주문이 들어오면, 주문 생성 이벤트(주문 생성됨)가 기록되며, 주문 상태는 이 이벤트를 통해 추적됨
상품 서비스: 주문이 생성되면, 상품 서비스에서 재고를 차감하는 이벤트(재고 차감됨)가 기록됨. 상태 변화는 이벤트로 관리
CQRS
명령 (Command): 주문 생성 및 재고 차감과 같은 상태 변화를 요청하는 작업은 명령으로 처리
예를 들어, 주문 생성, 재고 차감 명령을 처리하는 서비스가 각각 존재
조회 (Query): 주문 내역이나 재고 상태를 조회할 때는 별도의 읽기 모델을 사용하여 빠르고 효율적으로 데이터를 제공
예를 들어, 주문 내역을 조회하는 OrderView 모델을 만들어 최적화된 쿼리로 데이터를 반환
- 데이터 변경 이력 추적:
- 모든 상태 변화를 이벤트로 기록하므로, 데이터 변경 이력을 완벽하게 추적할 수 있음. 이는 감사와 디버깅에 유용
- 복구 및 재생:
- 이벤트를 재생하여 시스템의 현재 상태를 복구할 수 있음. 이는 데이터 손실이나 시스템 장애 시 유용
- CQRS와의 자연스러운 통합:
- 이벤트 소싱은 CQRS(Command Query Responsibility Segregation)와 잘 어울림. 명령과 조회를 분리하여 성능과 확장성을 최적화할 수 있음.
마이크로서비스 간의 통신에 대한 보안을 어떻게 보장할 수 있나요?
API Gateway를 사용해 각 서비스들로의 접근은 Gateway에서 중앙 관리한다. 하나의 접근점만을 두고 있으므로 Gateway를 제외한 서비스로의 외부 접근은 불가능하다. 또한 이벤트 기반 통신과 메시지 큐를 활용할 수도 있다.
MSA 환경에서 서로의 서비스를 의존하게 되는 의존성 순환이 발생했을때 어떻게 해결할 수 있을까요?
서비스 간의 의존성을 최소화하기 위해 API Gateway를 사용하여 서비스 간 직접적인 의존 관계를 끊고, 중앙 집중식 서비스 호출을 관리할 수 있다.
Apache Kafka, RabbitMQ 이벤트 기반 아키텍처 라이브러리를 사용하면 서비스를 직접 호출하는 대신 이벤트를 발생시키고, 다른 서비스가 이를 구독하여 비동기적으로 처리할 수 있다. 이 방식은 서비스 간의 동기적 호출을 줄이고, 순환 의존성 문제를 해결하는 데 유용하다.
분산 시스템에서의 데이터 일관성을 어떻게 유지할 수 있을까요?
첫 번째 질문에서 언급한 2PC, Saga 패턴, 이벤트 소싱, CQRS를 통해서 유지할 수 있다.
레거시 모놀리식 서비스를 MSA 로 전환한다고 할 때, 어떠한 이유가 있을까요?
모놀리식 서비스는 모든 코드가 하나의 코드베이스에 포함되어 있어 배포가 단순하고, 하나의 데이터베이스를 사용하여 데이터 일관성을 쉽게 유지할 수 있다는 장점이 있습니다. 하지만 특정 기능을 확장하려면 전체 애플리케이션을 확장해야 하고, 작은 변경 사항도 전체 애플리케이션을 다시 배포해야하며, 새로운 기술 도입이 어렵고, 특정 모듈에 종속적이라는 문제가 있습니다. 이러한 서비스를 MSA로 전환하면, 특정 서비스만 확장하여 성능을 최적화 할 수 있고, 개별 서비스의 변경 사항을 독립적으로 배포할 수 있습니다. 따라서 필요한 서비스만 다시 배포해 다른 서비스는 중단 없이 유지할 수 있습니다. 또한 서비스별로 적합한 기술 스택을 선택할 수 있습니다.
