03 MSA Data 구조

1. Note

• MSA에서는 컨텍스트마다 DB를 선택가능함
  • 따라서 컨텍스트에 맞는 최적화된 Data구조를 선택할 수 있게됨
  • 추가적으로 RDB는 각 DB마다 락, 트랜잭션이 어떻게 흘러가는지 추가적인 공부가 필요할듯.
  • 그런데 너무 다양한 DB를 선택하게 되면 복잡해질 수가 있어서 경계 필요!

2. Monolith & MSA 데이터 구조 비교

1. Monolith 데이터 구조

• 모든 기능이 하나의 애플리케이션 + 하나의 DB를 공유
  • 모든 테이블이 하나의 DB에 존재
  • User, Order, Payment 모두 같은 DB 접근
  • JOIN이 자유롭고 트랜잭션도 하나로 처리 가능
• 한계점
  • 결합도 증가 / 스키마 변경이 전체 시스템 영향
  • 확장성 한계 / 트래픽 많은 서비스만 따로 scale 불가
  • 배포 비효율 / 하나 수정해도 전체 배포 필요
  • 장애 전파 / DB 장애 = 전체 장애

2. MSA 데이터구조

• 서비스 기준으로 데이터가 분리함(Database-per-service)
  • 서비스마다 DB 독립
  • 다른 서비스 DB 직접 접근 금지
  • 데이터 소유권이 서비스에 있음
• 구조

  User Service     → User DB
  Order Service    → Order DB
  Payment Service  → Payment DB
  

3. Database-per-Service

1. Database-per-Service

• 각 마이크로서비스가 독립된 데이터베이스를 소유하는 구조.
• 서비스 간 데이터베이스 공유를 금지하고, 데이터의 소유권을 서비스 단위로 명확히 분리
• 데이터 조회 패턴
  • API 호출 / Order 서비스 → User 서비스 호출
  • 이벤트 기반 동기화 / User 변경 → 이벤트 발생 → Order가 복제 데이터 저장

2. 이점

1. 완전한 데이터 독립성 및 배포 자율성 보장

• 각 서비스는 자신의 데이터베이스 구조를 독립적으로 변경할 수 있음
• 따라서 특정 서비스의 스키마 변경이 다른 서비스에 영향을 주지 않음
• 각 팀은 서로 간섭 없이 독립적으로 기능을 개발하고 배포할 수 있으며, 배포 주기도 서비스 단위로 분리됨

2. 폴리글랏 데이터베이스(Polyglot Persistence) 지원

• 각 서비스는 자신의 도메인 특성에 가장 적합한 데이터 저장 기술을 선택할 수 있음
  • 주문 / 결제 서비스 → MySQL, PostgreSQL (트랜잭션 중심)
  • 상품 추천 / 카탈로그 서비스 → MongoDB (유연한 스키마, 대용량 읽기)
• 하나의 시스템에서 여러 DB 기술을 혼합하여 최적화된 구조를 구성할 수 있음

3. 완벽한 장애 격리 (Fault Isolation)

• 모놀리식 구조에서는 하나의 DB 장애가 전체 시스템 장애로 이어질 수 있음
• Database-per-Service 구조에서는 각 서비스의 DB가 독립되어 있음
• 장애 영향 범위가 서비스 단위로 제한됨
  • 결제 DB 장애 발생 → 결제 기능만 영향
  • 상품 조회 / 장바구니 기능은 정상 동작 유지

3. 한계점

1. 데이터 중복 및 동기화 비용 발생

• 여러 서비스에서 공통으로 사용하는 데이터(예: 사용자 정보 등)는 각 서비스 DB에 중복 저장될 수 있음
• 이 경우 데이터 변경 시 모든 관련 서비스에 반영해야 하므로,
• 데이터 동기화를 위한 이벤트 기반 처리 또는 별도 아키텍처가 필요

2. 분산 환경의 데이터 일관성(Data Consistency) 유지 어려움

• 단일 DB 환경에서 사용하던 JOIN, Foreign Key, ACID 트랜잭션을 그대로 사용할 수 없음
  • 서비스 간 JOIN 불가능
  • 분산 트랜잭션 불가
  • 즉시 일관성 보장 어려움
• 문제를 해결하기 위해 Saga 패턴이나 Event-driven 구조를 코드 레벨에서 직접 설계해야함
• 시스템 복잡도가 크게 증가

3. 운영 및 인프라 복잡도 증가

• 서비스 수만큼 데이터베이스가 증가하므로 운영 부담이 커짐
• DevOps 및 인프라 관리 비용이 크게 상승함
  • DB 인스턴스 수 증가
  • 백업 및 복구 전략 분리
  • 모니터링 대상 증가
  • 커넥션 풀 및 성능 튜닝 개별 관리
  • HA 구성 복잡도 증가

4. 서비스 간 데이터 흐름

1. API 기반 조회 (동기 통신)

• 필요한 데이터를 실시간으로 다른 서비스에게 요청하는 방식
• 흐름

  Order Service
  ↓ 회원 정보 필요
  User Service API 호출
  ↓
  회원 데이터 반환
  

• 케이스
  • 주문 서비스 → 회원 등급 조회
  • 결제 서비스 → 주문 상태 확인
  • 배송 서비스 → 배송지 조회
• 특징
  • 즉시 최신 데이터 조회 가능
  • 구현 단순
• 한계
  • 서비스 간 강한 의존성 발생
  • 연쇄 장애(Cascading Failure) 위험
  • 응답 지연 증가

2. 이벤트 기반 데이터 동기화 (비동기 통신)

• 다른 서비스 데이터를 미리 복제하여 사용하는 방식
• 서비스 변경 사항을 이벤트로 발행하고, 필요한 서비스가 이를 구독하여 자신의 DB에 저장
• 흐름

  User Service
  ↓ 회원 등급 변경
  회원 변경 이벤트 발행
  ↓ Kafka
  Order Service 수신
  ↓
  Order DB 업데이트
  

• 특징
  • 서비스 간 결합도 낮음
  • 장애 전파 감소
  • 성능 및 확장성 우수
• 한계
  • 데이터 동기화 복잡
  • 즉시 일관성 보장 어려움
  • eventual consistency 발생

5. 서비스별 DB 선택 전략 (RDBMS)

1. MySQL

1. 특징

• 가장 널리 사용되는 오픈소스 관계형 데이터베이스로, 단순한 구조와 높은 접근성을 기반으로 많이 사용
• 기본적으로 InnoDB 엔진을 사용하며, 트랜잭션과 외래키(Foreign Key)를 지원하여 관계형 데이터 모델을 안정적으로 처리
• 읽기 중심의 워크로드에서 높은 성능을 보이며, 캐싱 구조와 인덱스 최적화가 잘 되어 있어 일반적인 CRUD 기반 서비스에 적합
• 클라우드 환경(AWS RDS, GCP Cloud SQL 등)에서 기본적으로 지원되어 운영 편의성이 높음

2. 적합한 컨텍스트 유형

• 일반적인 웹 서비스 (CRUD 중심)
• 트래픽이 크지 않거나 중간 규모 서비스
• 읽기 비중이 높은 서비스
• 빠른 개발/배포가 중요한 스타트업 환경
• 커머스 기본 구조 (상품 조회, 주문 기본 처리 등)

3. 장단점

구분	내용
장점	- 설치 및 운영이 매우 쉬움 - 읽기 중심 서비스에서 높은 성능 - 오픈소스로 비용 부담 없음 - 클라우드 지원이 매우 좋음 - 커뮤니티 및 자료가 풍부함
단점	- 복잡한 쿼리 최적화 기능은 상대적으로 약함 - 고급 분석 기능 부족 - 대규모 트랜잭션/분석 처리에는 한계 - PostgreSQL 대비 SQL 기능 다양성 부족

2. PostgreSQL

1. 특징

• 표준 SQL에 가장 가까운 구조를 가진 고급 RDBMS
• 윈도우 함수, CTE(Common Table Expression) 등 고급 SQL 기능을 강력하게 지원하며, 복잡한 쿼리 처리에 최적화됨
• JSON, 배열 타입, GIS(PostGIS) 등 다양한 데이터 타입을 지원하여 관계형 + 비정형 데이터를 함께 처리할 수 있음
• 확장(Extension) 구조를 통해 기능을 추가할 수 있어, 매우 유연한 아키텍처 구성이 가능
• VectorDB 활용가능함.

2. 적합한 컨텍스트 유형

• 복잡한 비즈니스 로직이 필요한 서비스
• 데이터 정합성과 무결성이 중요한 시스템
• 분석/조회 기능이 함께 필요한 서비스
• JSON 기반 유연한 데이터 구조가 필요한 서비스
• 확장성이 중요한 MSA 환경

3. 장단점

구분	내용
장점	- SQL 기능이 매우 강력함 (CTE, 윈도우 함수 등) - 데이터 무결성 및 정합성 우수 - JSON, 배열, GIS 등 다양한 데이터 타입 지원 - 확장성(Extension) 구조로 기능 확장 가능 - 복잡한 쿼리 처리에 최적화
단점	- MySQL 대비 학습 난이도 높음 - 설정 및 튜닝 복잡도 존재 - 운영 초기 진입 장벽 있음

3. Oracle DB

1. 특징

• 대표적인 상용 엔터프라이즈 RDBMS로, 안정성과 성능이 최상위 수준
• 대규모 트랜잭션 처리에 최적화
• 고급 보안 기능, 자동 장애 복구, RAC(Real Application Clusters) 같은 고가용성 기능을 제공
• 라이선스 비용이 매우 높고, 운영 구조가 복잡하여 일반 서비스보다는 엔터프라이즈 환경에 집중되어 있음

2. 적합한 컨텍스트 유형

• 금융권 / 은행 / 보험 시스템
• 대기업 핵심 미션 크리티컬 시스템
• 초고가용성(HA)이 필요한 서비스
• 대규모 OLTP 시스템
• 엄격한 데이터 보안이 필요한 환경

3. 장단점

구분	내용
장점	- 대규모 트랜잭션 처리에 최적화 - 매우 강력한 안정성 및 고가용성 기능 - 고급 보안 기능 제공 - 엔터프라이즈급 성능 최상위
단점	- 라이선스 비용 매우 높음 - 운영 및 관리 복잡도 높음 - 벤더 종속성 강함 - 개발/테스트 환경 구축 부담 큼

6. NoSQL 및 In-memory DB 전략

1. MongoDB

1. 특징

• 대표적인 Document 기반 NoSQL 데이터베이스로, 데이터를 JSON과 유사한 BSON(Binary JSON) 형태로 저장
• RDBMS처럼 고정된 스키마를 강제하지 않기 때문에, 서비스 요구사항 변화에 따라 필드 구조를 유연하게 수정할 수 있음
• 수평 확장(Sharding)에 강점을 가지며, 대량 데이터 처리 환경에서 유연하게 scale-out이 가능
• 특히 상품 정보처럼 속성이 자주 변하거나, 사용자별 데이터 구조가 달라질 수 있는 환경에서 강력한 장점

2. 적합한 컨텍스트 유형

• 데이터 구조가 자주 변경되는 서비스
• 유연한 스키마가 필요한 서비스
• 대규모 읽기/쓰기 트래픽 처리
• 상품 카탈로그, 콘텐츠 관리 시스템(CMS)
• 추천 시스템 및 사용자 행동 로그 저장

3. 장단점

구분	내용
장점	- 스키마 변경이 매우 유연함 - JSON 기반 데이터 구조로 개발 생산성 높음 - 대규모 트래픽 처리 및 수평 확장에 강함 - 비정형 데이터 처리 적합
단점	- JOIN 기능이 제한적임 - 복잡한 관계형 데이터 모델링에 불리함 - RDBMS 대비 강한 정합성 처리에 한계 존재 - 트랜잭션 중심 서비스에는 부적합

2. Redis (In-memory DB)

1. 특징

• 메모리(In-memory) 기반 Key-Value 저장소로, 매우 빠른 읽기/쓰기 성능을 제공한
• 디스크가 아닌 RAM 기반으로 동작하기 때문에 일반 RDBMS 대비 압도적으로 빠른 속도를 가짐
• 또한 TTL(Time To Live)을 지원하여 일정 시간이 지나면 데이터를 자동 삭제할 수 있어, 세션이나 임시 데이터 관리에 적합
• String, Hash, List, Set, Sorted Set 등 다양한 자료구조를 제공하여 단순 캐시 이상의 활용이 가능

2. 적합한 컨텍스트 유형

• 초고속 응답이 필요한 서비스
• 캐시(Cache) 시스템
• 로그인 세션(Session) 저장
• 실시간 랭킹 시스템
• 장바구니, 토큰, 인증 정보 관리

3. 장단점

구분	내용
장점	- 매우 빠른 읽기/쓰기 속도 - TTL 지원으로 임시 데이터 관리 편리 - 다양한 자료구조 제공 - DB 부하 감소 및 성능 개선 효과 큼
단점	- 메모리 기반이라 비용 부담 존재 - 서버 재시작 시 데이터 유실 위험 (설정에 따라 완화 가능) - 영구 저장소(Persistent DB) 용도로는 부적합 - 대용량 데이터 저장에 비효율적

7. 검색/조회 전용 저장소 (Elasticsearch)

1. ELS

1. 특징

• Apache Lucene 기반의 분산 검색 엔진으로, 대량 데이터에 대한 빠른 검색과 분석에 특화된 저장소
• Document 기반(JSON 형태)으로 데이터를 저장하며, 역색인(Inverted Index) 구조를 사용
• 일반 RDBMS의 LIKE 검색보다 훨씬 빠른 Full-text Search 성능을 제공
• Aggregation 기능을 통해 실시간 통계 및 데이터 분석이 가능하며, 로그 분석 플랫폼(ELK Stack) 구성에도 널리 활용
• MSA 환경에서는 주로 검색과 조회 성능을 분리하기 위한 Read Model 또는 조회 전용 저장소로 사용
• 내부적으로는 NoSQL 계열이 맞지만, 용도가 달라서 별도로 판단

2. 적합한 컨텍스트유형

• 상품 검색 시스템
• 대용량 Full-text Search
• 실시간 로그 분석 시스템
• 검색 성능이 중요한 서비스
• 데이터 집계(Aggregation) 및 통계 조회
• 추천 검색어 및 자동완성 기능

3. 장단점

구분	내용
장점	- Full-text Search 성능이 매우 뛰어남 - 대용량 검색 처리에 강함 - Aggregation 기반 실시간 분석 가능 - 수평 확장(Scale-out)에 유리함 - 로그 분석 및 검색 서비스 구축에 적합
단점	- Primary DB 용도로는 부적합 - 데이터 정합성 유지 어려움 (Eventual Consistency) - 데이터 동기화 아키텍처 추가 필요 - 메모리 사용량이 높고 운영 난이도 존재