분해 패턴
MSA소프트웨어 아키텍처를 설계함에 있어,
모놀리식 비즈니스 구조를 어떤 판단 기준에 따라 서비스를 분리할 것인지에 대한 패턴
즉, "분해"를 해결하기 위한 패턴
비즈니스 능력에 따른 분해 (Business Ability)
- 복잡한 "비즈니스 능력"을 기준으로 서비스를 분해
- e.g. 송금 서비스, 주문 서비스,...- 장점
- 비즈니스가 복잡하고, 대규모 조직의 경우- 비즈니스 특성으로 인해 내부 서비스간 통신이 매우 빈번할 경우
- 단점
- 서비스 간 응집도, 결합도, 종속성 증가- 서비스, 즉 도메인 별 팀의 구조가 희석될 가능성
하위 도메인 패턴별 분해 (Sub-Domain) from DDD
- 복잡한 비즈니스일지라도, 포함된 내부의 하위 도메인을 단위로 분리.
- e.g. 계좌 도메인, 내부 머니 도메인, 뱅킹(외부 은행과 통신만 담당), ...- 장점
- 서비스 간 독립성, 격리성이 증가 / 결합도 감소- 서비스 간 종속성 최소화, 서비스 간 영향도 감소
- 장애 영향도 최소화
- MSA 철학에 부합하는 패턴
- 단점
- 서비스 간 불필요한 통신 가능성, 성능 이슈(http, grcp, mq....)
- 지나치게 많은 서비스로 분리된 가능성
- 대규모 시스템에서는 비효율성 크게 증가 가능성
트랜잭션 패턴
MSA 설계를 통해 도출된 서비스를 사용하여 트랜잭션을 해결해 주기 위한 패턴 즉, "트랜잭션"을 해결하기 위한 패턴
2PC (2Phase Commit)
"트랜잭션의 완료"를 2(N) 단계를 거쳐서 결정
Commit Request --> (정말 commit? )
->(실패 시) -> Rollback
->(성공 시) -> Commit
Compensating Transactions (보상 트랜잭션)
특정 요청과 그 요청에 대해 정상적이고 완전히 종료된 "행동"(트랜잭션)을 그 이전 상태로 되돌리기 위한 "행동"(트랜잭션)
Saga Pattern(사가 패턴)
트랜잭션의 선, 후 관계를 사전에 정의하고 필요에 따라 Cordinator가 보상 트랜잭션을 이용, 관리하여 분산 시스템 환경에서 트랜잭션을 구현하기 위한 패턴
데이터 쿼리 패턴
- MSA 소프트웨어 아키텍처를 설계하면서 생긴
데이터 쿼리의 어려움을 해결하기 위한 패턴
API Aggregation 패턴
- 필요한 데이터를 얻어오기 위해서, 분리된 서비스들 각각에 각 도메인에 대한 데이터를 요청 후 필요에 맞게 Aggrgation
- e.g. 송금이 최종적으로 성공한 요청 건에 대해서, 같이 실행된 외부 은행에 대한 계좌 요청들의 외부 API 호출 횟수
CQRS 패턴
-
Command(Write, Update, Delete)작업과, Query(Read) 작업의 EndPoint를 분리하고 Command 에서 발생된 데이터의 변경을 이벤트 발행을 통해 원하는 포맷대로 Query를 위한 전용 데이터 구조를 만들어 이곳에 복잡한 Query를 담당
-
e.g. 강남구에 사는 모든 주민들의 잔액 총합을 실시간으로 알고 싶다면?
가시성 (Visibility, Observability)
-
MSA 소프트웨어 아키텍처를 설계하면서 생긴 로깅, 모니터링의 어려움(가시성의 부재)
-
로깅 및 메트릭의 중앙집중 및 필터링 등을 통한 한곳에서의 모니터링
-
하나의 트랜잭션에 대해 여러개의 각 서비스 요청들을 하나의 요청처럼 볼 수 있게 하는
트레이싱
로깅 : 누락없이 왜?, 언제?, 어디서? 어떤 영향을 미쳤는지 알기 위해 사용
메트릭: 외부 지표들을 시리얼 방식으로 저장(프로메테우스, influx)
시간에 따라서 증감하는 수치를 보는 것에 대한 의의구체적으로 어떻게 로깅, 메트릭을 저장하고 인덱싱하여 검색할 지에 집중하는 패턴
신뢰성(Reliability)
- MSA 소프트웨어 아키텍처를 설계하면서, 분리/분해로 인해 떨어진 신뢰성을 해결하기 위한 패턴
- 장애 복구, 자가 치유, 무정지 배포 등을 구현하기 위한 패턴
서킷 브레이커 (Circuit Breaker)
신뢰성을 높이기 위한 패턴의 일종으로, 분산 시스템에서 장애 전파를 막포 피해를 최소화 하기 위한 패턴
