MSA 간 API 조회 최적화

기존 서비스(모놀리식)를 MSA 로 변경하며, 

테이블간의 복잡한 Join으로 작성되어 있던 조회 쿼리를 어떻게 변경해야 하나 고민해보았다.

 

A. MQ를 이용하여 Join에 필요한 데이터를 동기화

가장 처음으로 생각하던 방법이다.

해당 방식은 기존에 사용하던 쿼리를 수정하지 않아도 되는 장점이 있었으나 

많은 문제를 가지고 있다.

단, 복사를 한다고 해도 해당 MS 필요한 데이터만 동기화 해야 한다.

 

 

장점

• 쿼리 수정 불필요

단점

• MSA 의 근본적 목표에 반하는 방법이다.(MS 간 결합도 상승으로 독립점 운영이 어렵다)
• 동기화 빈도 상승 및 전송 효율 저하
• 불필요한 데이터 변경이 발생

 

B. 해당 도메인 MS에 데이터를 요청하여 조회 후 조립 

처음에는 하나의 쿼리로 작성하던 것을 Application 로직으로 대체하는 것에 거부감이 과 의문이 있었다.

 

의문점) 

• 대용량 데이터를 처리해야 하는데 서버 메모리가 이것을 버틸까?
• 속도가 빠를까?

해당 의문점은 하기 블로그 글에서 대부분 풀어주었다.

요약하자면

• 대용량 데이터를 처리해야 하는데 서버 메모리가 이것을 버틸까?
  • => 서버 메모리 보다 DB 메모리 사용이 더 돈이 많이든다....
  • => 따라서 요즘에는 서버 메모리를 더 사용하고 DB 메모리를 적게 사용하는 것이 좋다
• 속도가 빠를까?
  • => 여러 최적화를 사용하면 차이가 거의 없거나 더 빠른 경우도 있다.

 

여기서 여러 최적화에 대해서 작성해보겠다.

1. 타 MS 에 데이터 요청 시,  건 별로 하는 것이 아닌 일괄로 조회

예를 들어 

1000 건의 상품을 조회 하는데 이때, 

해당 상품들을 판매하는 판매자 정보가 필요하다고 한다면 

상품 별로 판매자 정보를 조회 하는것이 아닌

필요한 판매자 정보를 리스트업 하고, 한번에 조회하는 것

 

2. 로컬 캐시 사용

위의 예시에서 로컬 캐시를 사용하여,

매번 판매자 정보를 매번 조회하는 것이 아닌,

로컬 캐시에 해당 정보를 저장해두고, 없는 판매자의 정보만 조회 요청하고 

다시 로컬 캐시에 저장하는 방식

 

저장 가능한 캐시의 종류 

• 로컬 캐시 
  • 서비스를 실행하는 프로세스의 힙 메모리
  • 가장 빠르다
  • 데이터 크기에 제약이 있다. 
  • 동기화 X
• 복제 캐시
  • 인스턴스 별로 동일한 데이터를 가진다
  • 로컬 캐시와 동일한 읽기 속도를 가진다
  • 하지만 인스턴스 간의 데이터 동기화 작업이 추가 되므로 데이터 쓰기는 느리다.
  • 또한 인스턴스 수가 많고 스케일 아웃이 동반 되는 경우 부담 상승
  • 클라우드 환경에 부적합
• 분산 캐시
  • 별도의 캐시 서버를 실행하고 네트워크로 접근하므로 로컬 캐시에 비해 느리다.

 

해당 정보가 자주 변하지 않고, 자주 참조

=> 로컬 캐시

 

데이터가 자주 변경 되고, 이 변경 사항이 모든 인스턴스에 즉각적으로 적용 되어야 한다.
데이터 건수가 매우 많다.

=> Redis 와 같은 분산 캐시(단, 단일 장애 지점이 될 수 있으므로 해당 장애가 전체 시스템에 문제가 없도록 고려 필요)

 

구현

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

---

참조

https://m.blog.naver.com/PostView.naver?blogId=wharup&logNo=223188187194&fromRecommendationType=category

MSA 서비스간 API 참조 가이드 (성능 튜닝) - Part1 일괄 조회

https://blog.naver.com/wharup/223195089165

MSA 서비스간 API 참조 가이드 (성능 튜닝) - Part2 로컬 캐시

https://m.blog.naver.com/PostView.naver?blogId=wharup&logNo=223230695973&fromRecommendationType=category

MSA vs 모놀리식 결과 분석 및 제약 사항 (API 참조 가이드 Part4)