마이크로서비스
frontEnd 조각으로 분리, BackEnd 저장소를 격리
탄력과 확장성를 고도화, 난이도 복잡성 높음
설계 동향 - 리액티브 선언
ACID vs BASE (데이터 처리 유형)
-
ACID
트랜잭션이 종료 -> 일관적이고 안정적으로 디스크에 저장
즉시 일관성, 정확도 중요. 관계형 DB -
BASE
가용성, 어떤 상황에서도 데이터를 빠르게 전달, 약간의 부정확성을 허용, 빠르게 대응 가능
Key-value, document
마이크로 프런트엔드
서버에 각 조각을 모으기 위한 간단한 웹 프레임 서비스 동작
마이크로서비스 통신 패턴
• REST API
마이크로 서비스를 호출할때 기본 통신 방법 (동기호출)
-
동기
요청하면 바로 오는 방식
if 호출 받은 마이크로서비스에서 장애가 온다면?? -> 연쇄적 장애 발생, 답이 안오면, 계속 기다리다가 재호출 -
비동기
Apache Kafka, RabbitMQ, ActiveMQ
이벤트를 생산하는 모듈과 이벤트에 대응하는 모듈을 분리, 상호 독립적으로 동작, 병렬처리
발신자와 수신자를 장소와 시간에 맞게 분리
느슨한 결합으로 인해 확장성, 수정 가능성에 많은 이점 -
에러 처리
탄력성 응답성
리액티브아키텍처패턴(워크플로프로세스패턴)
-
데이터 소실 문제
- 큐에 전달이 안됨, 전달되어도 큐 다운
- 메세지를 꺼내 처리 전에 장애 발생
- 데이터 에러로 인해 메시지 저장 실패
-
저장소 격리
서비스 별 저장소
각각의 마이크로서비스는 각자의 비즈니스 처리를 위한 영구 데이터 소유
다른 서비스에 직접 노출 X, 반드시 API를 통해서 엑세스 가능
-
데이터 공유와 위임
위임 서비스
-
API 조합과 CQRS
-
API 조합
의존성이 높음
-
CQRS
의존성이 낮아지고 확장성 높음
- 분산 트랜잭션 페턴
ACID 적용의 어려움
이벤트 보상 트랜잭션
각각의 service 분리 -> Transaction 정합성
- SAGA
-
코레오그래피(Choreography)
이벤트 기반 아키텍처의 브로커 패턴
보상 트랜잭션
-
Orchestrator (Event 흐름을 조절)
트랜잭션을 구성하는 파트를 하나씩 호출 & 성공 / 실패 여부를 기록 -> 결과 흐름 조정
- CQRS
Command Query Responsibility Segregation : 명령 조회 책임 분리
-> 시스템 상태를 변경하는 명령 CUD
-> 시스템 상태를 가져오는 조회 R (조회 요청이 훨씬 많이 사용)
-
CQRS Event
-
Event Sourcing
상태가 아닌 트랜재견 자체를 저장, 쓰기 최적화
트랜잭션을 저장하는 방식으로 동시성 문제 해결 가능. 변수의 가변성은 경합 교착 상태 동시 update 등의 문제를 발생 -> 트랜잭션을 저장함 -> 가변성 제거
