[MSA] MSA 의 태생적 한계 - 데이터 쿼리 패턴 (CQRS, API Aggregation)

목차

 

🧨 MSA 의 태생적 한계

• 모든 서비스는 각 프로덕트로서, 도메인을 책임진다. -> 서비스/도메인 간 협업과 의존성이 지양되는 구조임.
• 각 서비스의 DB 는 각 서비스를 통해서 접근해야만 한다. (data Ownership)
  • 여기서 생기는 문제 -> 여러 서비스의 데이터를 조합해서 보고 싶으면 어떻게 해야 할까? (모놀리스 였으면 join 으로 해결)

 

 

 

📱 여러 서비스의 데이터의 조합이 필요한 예 - API Aggregation 패턴

예를 들어 "특정 기간" 동안, "충전" 이 동반된 일정 금액 이상의 "송금" 내역의 합을 알고 싶다면 어떻게 해야할까?

이때 Money service 의 머니 충전 내역 DB에 송금 시도 건에 대한 ID가 존재한다고 가정해보자.

 

API Aggregation 패턴을 이용해서 해결해볼 수 있을 것 같다.

API Aggregation 패턴은 말 그대로 여러 API 요청을 통해 가져온 데이터들을 가공하고 조합하여 정보를 만드는 것이다.

1. 특정 기간 동안의 성공한 송금 내역 Get
2.특정 기간 동안의 성공한 머니 충전 내역 Get
3. 머니 충전 내역 내, 정상 송금 ID 가 포함된 내역을 검색
4. 검색된 내역 중 일정 금액 이상 충전 내역들의 충전 금액 총합을 Sum
5. RETURN!

 

위 그림처럼 머니 서비스, 송금 서비스에 요청을 통해 데이터를 구하고 그 데이터들을 조합하고 가공하여 결과를 리턴할 것이다.

일반적으로 제한적이지 않은 상황에 적합할 수도 있다. 여기서 제한적이지 않은 상황은 대용량 데이터가 아니고, 실시간 부하도 크지 않고, 데이터도 많지 않은 경우를 의미한다.

 

 

⚠️ API Aggregation 패턴 사용시 주의 사항

1) 비즈니스 로직이 포함된 API 의 호출 빈도를 파악해야 한다.

• 너무 자주 호출되는 경우라면, Aggregation을 위한 각 서비스의 API 가 부하를 받아주기 어려울 수도 있다.
• 대용량 DB의 경우, 추가적으로 호출되는 API 로 인해 DB의 부하 또는 부하가 발생할 가능성이 있는 서비스를 사용하는 다른 서비스들에 장애를 전파시킬 수도 있다.

 

2) Aggregation API의 중요도

• 여러 번의 API 호출 중, 한 번이라도 실패 시 그 호출은 실패가 되어야 한다. 이를 고려해야 한다.
• 그리고 여러번의 호출로 인해, 다른 서비스 API 보다 훨씬 긴 Latency 를 가지게 될 것이다.
  • N번 호출 + 내부 로직 실행 시간

 

 

정리해보자면 API Aggregation 패턴은 "쉽고, 직관적이다" 라는 아주 큰 장점이 있다.

사실 이 장점은 대규모 환경에서 조직과 팀으로 일해야 하는 기업에서는 빠른 비즈니스를 해야하는 상황에서는 웬만한 성능적인 부분보다 더 큰 장점이 될 수도 있다.

 

다만, 그만큼 주의해야 하고 전체 시스템의 영향도를 꼭 파악해야만 하는 까다로운 패턴 중 하나이다.

 

또, 아래 케이스와 같이 아예 불가능한 경우와 요구사항이 생길 수도 있다.

"실시간으로 '강남구' 에 거주 중인 회원들의 머니 총 잔액이 어떻게 변동되는지 알고 싶다."

 

 

‼️ 복잡한 요구사항이 있다면..?

아래에서 요구사항을 엔지니어링적으로 분석해보자.

• 실시간으로 앱의 홈 화면에 ➡️ 홈 화면 -> 높은 부하
• 고객이 거주하는 곳의 "구"에 (예. 강남구) ➡️ 홈화면에 로그인 한 "고객 정보"를 기준으로
• 거주중인 회원들 전체의 ➡️ 로그인 한 고객의 주소 정보와 동일한 주소를 가진 "전체 고객 정보"를 확인하여
• 머니 총 잔액이 ➡️ 필요한 정보의 중심 서비스 도메인은 "머니" 서비스
• 어떻게 변동되는지 알려주고 싶어요. (비즈니스적으로 경쟁심 유발하기 위함) ➡️ 비교적 덜 중요한 비즈니스일 수도 있음

대규모 서비스라는 가정하에 이러한 데이터를 쿼리로 지원한다는 것은 시간이 굉장히 오래 걸리고 DB 인덱싱을 한다고 해도 인덱스 크기가 어마어마 해서 비효율적일 것이다. -> RDB 를 사용해서 해당 정보를 활용하기 어려운 상황이다.

 

 

⚡️ 복잡한 요구사항 구현 - API Aggregation 패턴

1. 고객이 소속된 "구" 정보 확인
2. "강남구" 주소를 가진 고객들 정보를 확인 (30만명이라 가정)
3. 주소 변경 등으로 실시간 변경 가능성 존재
4. 포함된 모든 고객들의 "머니" 정보를 확인
5. 100개씩 묶어서 호출한다 해도 3,000 번 call 을 해야 한다. 
6. 모든 머니 잔액을 확인 sum
7. RETURN

-> 대규모 시스템의 홈화면에서 호출되어야 할 하나의 API 가 다른 서비스에 3,000 번 콜을 해야하는 말도 안되는 상황이 발생한다.

 

정리해보자면 아래와 같은 문제가 있다.

• 최악의 경우, 고객 전체 수만큼 Money 정보를 GET 해줘야 할 수도 있다.
  • 그만큼 Money 서비스에 엄청난 부하가 가해진다. 이로 인해 Money 서비스를 이용하는 다른 서비스에게도 장애가 전파될 수 있다.
• Latency 도 지나치게 길어지고 실시간 부하를 감당하지 못할 가능성이 크다.

 

 

☘️ 복잡한 요구사항 구현 - CQRS 패턴

그렇다면 요구사항을 다시 직관적으로 생각해보자.

강남구 고객의 머니 잔액 변동이 생길 때에만
강남구 전체 머니 총 잔액 값을 변동 시켜주고
요청 시, 이렇게 변동 중인 최종 값을 Get 해주면 되는 게 아닐까?

 

위와 같이 설계를 해보자면 아래와 같은 그림으로 흘러갈 것이다.

• 이벤트가 발생할 때마다 특정한 저장소에 값을 업데이트 해준다면 GET 요청 시 다른 서비스에서 데이터를 가져오지 않고 특정 저장소에서 값을 읽어오기만 하면 된다.

 

여기서 의문인 점이 있을 수 있다.

'모든 데이터는 데이터 오너십을 가진 서비스에서만 그 데이터를 관리해야 한다.' 라는 원칙에 어긋나는 것처럼 보이기 때문이다.

중요한 점은 "???" 는 Money 데이터에 접근(Query) 은 하지만, 변동 시키지는 않는다.
-> 사실상 다른 도메인이며, 다른 서비스라고 생각할 수 있다.

 

당연히 모든 Money 의 정보를 변동(Command) 시키는 주체는 Money 서비스여야만 한다.

 

 

이러한 패턴을 CQRS(Command and Query Responsibility Segregation) 패턴이라고 한다.

아래와 같은 특징을 가진다.

• 데이터를 변동시키는 Command 와 데이터에 접근하는 Query 를 분리한다.
• 장애전파에 비교적 자유로운 편이다.
• Query 를 위한 별도의 서비스를 식별하고 Query 서비스에서는 이벤트를 받아 처리한다.

 

이제는 아까 비어있던 "???" 에 뭐가 들어가야 할 지 알 수 있을 것이다. 바로 "MoneyQueryService" 이다.

그림을 완성시켜보자!

 

MoneyQueryService 는 CQRS 패턴을 구현하는 로직과 Query 서빙을 담당한다.

 

 

📗 결론

기존 모놀리스 환경에서는 비즈니스 로직이 포함된 API 를 구현하기 위해 SQL Join 을 활용했으나,

MSA 환경이 되면서 다른 DB를 활용하게 되어 join 이 불가능해졌다.

이러한 문제 해결을 위한 가장 간단한 해결 방법으로 API Aggregation, CQRS Pattern 이 무엇인지 알아보았다.

• API Aggregation Pattern은 직관적이고 간단하지만, 신경써야 할 부분이 많다.
• CQRS 패턴은 Query 와 Command 를 분리하는 패턴으로 구현은 조금 어렵지만, 많은 부분의 해결이 가능하다.