[MSA] 분산 데이터 액세스 패턴(분산된 데이터에 어떻게 접근할 것인가)

MSA에서 서비스를 분리하게 되면 기존 통합되어 있던 데이터도 함께 분리가 된다. 이렇게 분산된 서비스 환경에서 서비스가 자신이 소유하지 않는 데이터에 접근하는 방법들에 대해 알아본다.

 

1. 서비스 간 통신 패턴

• 다른 서비스에 필요한 데이터를 요청하는 가장 일반적인 패턴(타 서비스 API 호출)
• 단순하고 직관적이나, 서비스 간 동적 커플링이 발생 함

출처: 소프트웨어 아키텍처 The Hard Parts

장점	단점
단순하고 직관적	네트워크, 데이터, 보안 Latency가 발생(성능 저하)
데이터 용량 문제가 없음	확장성/처리량 이슈(타 서비스와 함께 확장 필요)
	결합도에 따른 내고장성/가용성 저하
	서비스 간 계약이 필요(API명세 등)

 

2. 컬럼 스키마 복제 패턴

• 필요한 컬럼을 분산된 서비스의 여러 테이블에 복제해서 다른 바운디드 컨텍스트에서 자급자족적으로 사용
• 서비스 간 커플링 제거 가능
• 동기화와 데이터 일관성 문제(큐, 토픽, 이벤트 스트리밍 등 비동기통신으로 처리)
• 데이터 집계, 리포팅 또는 다른 패턴으로 해결이 곤란한 경우 적합

출처: 소프트웨어 아키텍처 The Hard Parts

장점	단점
데이터 액세스 성능 좋아짐	데이터 일관성 이슈
확장성, 처리량 이슈가 없음(단독 확장 가능)	데이터 오너십 이슈
내고장성이 좋아짐(결합도 없음)	데이터 동기화 필요
서비스 의존성이 없음

 

3. 복제 캐싱 패턴

• 데이터를 다른 서비스에 요청하지 않고, 각 서비스가 메모리 캐시에 데이터를 복제해 사용하는 기법
• 일반적으로 데이터양이 많지 않고, 변경 빈도가 낮은 경우 적합
• 일반적인 [캐싱 모델]의 종류
  • 단일 메모리 캐싱 모델(로컬 캐싱):
    - 각 서비스가 내부 메모리 캐시를 자체 보유.
    - 데이터 동기화 없음, 응답성/확장성은 좋으나 데이터가 공유(동기화) 되지 않음
  • 분산 캐싱 모델:
    - 외부 캐시 서버를 활용,
    - 서비스가 캐시 서버에 커플링 발생, 데이터 오너십 문제, 네트워크 Latency 발생
  • 복제 캐싱 모델:
    - 서비스간 동기화된 데이터를 각 서비스 자신이 가지고 있는 모델
    - 백그라운드/비동기적 데이터 동기화 필요(ex. Hazelcast 등)
    - 서비스가 캐시 데이터(캐시 데이터 오너십을 가진 서비스)와 시작 타이밍에 의존하게 됨
    - 데이터양의 제한, 캐시 데이터 변경 빈도가 높은 경우 부적합

출처: 소프트웨어 아키텍처 The Hard Parts

장점	단점
데이터 엑세스 성능이 좋음	클라우드, 컨테이너 환경에서 설정이 어려울 수 있음  (TCP/IP 브로드캐스팅, lookup 등의 방식으로 복제하여 동적 IP 등의 환경에서 제약 고려)
확장성/처리량 이슈 없음	대량의 데이터 치리에 부적합(캐시 복제 성능 및 리소스 과도한 사용)
내고장성 괜찮은 편	업데이트 빈도가 높은 경우 서비스 간 동기화 어려움
데이터 일관성 보장	초기 서비스 시작 디펜던시(초기 캐싱 데이터 복제 작업에 의한 의존성)
데이터 오너십 유지

 

4. 데이터 도메인 패턴

• 여러 서비스가 공유하는 테이블을 하나의 스키마에 집어넣고 관리하는 방법(데이터 통합 방법)

출처: 소프트웨어 아키텍처 The Hard Parts

장점	단점
데이터 액세스 성능 좋음	데이터 변경에 대한 바운디드 컨텍스트 넓어짐 (관리 및 영향도 범위 증가)
확장성/처리량 이슈 없음	데이터 오너십 관리 문제
내고장성 이슈 없음	데이터 액세스 보안 처리 분리 안됨
서비스 의존성 없음
데이터 일관성 보장

 

 

관련글:

 

[MSA] 서비스 분리 해야할 때와 통합 해야할 때(서비스 분해와 통합 요인)

 

[MSA] 모놀리식 어플리케이션 분해 전략(서비스 분리)

[MSA] 데이터베이스 분해인과 통합인 - 어떤 이유로 분해 또는 통합해야하는가?