| MSA에서는 비교적 간단한 비즈니스 로직만 포함되더라도 패턴을 고려해야하는 상황 발생
기존 모놀리스 환경에서 SQL Join을 활용했던 부분에서
MSA 환경이 되면서 다른 DB를 활용하게 되어 Join 불가능해지는 상황이 존재
1. 각 서버에서 가져온 데이터를 Join 할 때
다른 서버에서 데이터를 가져오기 위해서 다른 서버의 DB에 직접 접근하는 것은 지양해야한다
즉 서비스/도메인 간 협업과 디펜던시가 지양된다 (데이터 오너십)
- Membership server -> banking server api를 통한 DB 접근
ex) money data + banking data ???
DB 테이블간의 Join이 필요할 때
적은 부하, 적은 데이터량에서는 adapter를 생성하여 각각 필요한 데이터를 API 요청을 통해 필요한 작업을 수행하는것도 괜찮지만, 합산이나 데이터를 가공해야할 때는
e.g
특정 기간동안 충전시 일정 금액 이상의 송금 내역의 합을 구하라
방법 1. API Aggregation Pattern
각각의 서버에서 데이터를 조회한 뒤 가공하여 만드는 것 (API Aggregation pattern) : 부하가 없다. 데이터가 적다. 실시간이 아니다 하는 경우에는 고려해볼 수 있음
- 많은 동작을 수반해야한다.
비즈니스 로직이 포함된 API의 호출 빈도를 파악해야한다. 너무 자주 호출되는 경우 Aggregation을 위한 각 서비스의 API가 부하를 받기 어려울 수 있다.- 대용량 DB의 경우 추가적으로 호출되는 API로 인해
다른 서비스에 장애를 전파할 수 있다. : 예를 들어 충전은 됐으나 머니 추가가 안되는 경우 (서킷브레이커 고려) api의 중요도- N번의 요청중 한번의 실패로 인해 자원 낭비
- 여러번의 호출로 인해 다른 서비스 API보다 훨씬 긴 latency를 가지게 된다 (N번 호출 + 내부 로직 실행 시간)
- 가장 쉽지만 가장 주의해야할 패턴 중 하나
- 최악의 경우 고객 전체 수 만큼 정보 조회가 필요하다
장단점
장점
- 쉽고 직관적이다
단점
- 전체 시스템 영향도를 꼭 파악해야한다
방법 2. CQRS 패턴
command와 query를 분리하는 패턴
API를 위해서 이벤트를 활용하여 command와 query를 분리하고
query를 위한 별도의 서비스 식별
- money 값 변동
- membership: 강남구 거주 확인
잔액 변동 감지- DB 저장
=> 데이터 오너십을 위반하는가?
데이터에 접근(query)은 하지만 변동 시키지는 않는다.
장단점
장점
- 장애 전파를 막을 수 있다
단점
- 구현이 어렵다
하루 일지 보단 행동 고찰 과정에 대한 개발 블로그