massive-board-learning

Inflearn Lecture Link

학습 목표 · 목차

1. 대규모 시스템의 본질
   1. 문제 상황 · 정의
   2. 기술적 · 비기술적 요구사항
   3. CAP 정리
   4. 강한 일관성 vs. 최종 일관성
   5. 병목의 식별 전략
   6. 장애 전파 방식
2. 트래픽 특성에 따른 설계 전략
   1. 읽기 · 쓰기 트래픽이 비대칭적인 상황의 설계
   2. CQRS
   3. 캐시 전략
   4. 이벤트 기반 비동기 처리
   5. Projection 설계 전략
3. 아키텍처의 선택
   1. 모놀리식 vs. MSA
4. 데이터 계층 설계
   1. RDB | MySQL
      1. 스키마 설계
      2. 인덱싱 전략
      3. 샤딩 전략
      4. 분산 환경에서의 유일성 보장
      5. 트랜잭션 격리 수준
   2. In-Memory | Redis
      1. 캐싱 대상 데이터 선정
      2. 고려사항
      3. 구현
5. Message Broker | Kafka
   1. 메시지 브로커의 역할
   2. 메시지 브로커의 필요성
   3. 전송 보장 수준
   4. Transactional Outbox 구현
6. 정합성 전략
   1. Consumer 멱등성 설계

대규모 시스템의 본질

문제 상황 · 정의

• 트래픽이 예측할 수 없게 증가할 수 있음.
• 일부 기능에만 부하가 집중될 수 있음.
• 특정 서비스의 장애가 다른 서비스에 영향을 줄 수 있음.
• 데이터의 규모가 단일 장비의 한계를 초과함.

병목과 장애 전파를 어떻게 통제할 것인가?

데이터베이스의 한계

• Connection 수 제한.
• IOPS 제한.
• SPOF.
• API 조합 비용 증가.

기술적 · 비기술적 요구사항

비기술적 요구사항

1. 고가용성
   1. SLA 충족.
   2. 장애 발생 시 자동 복구 가능.
   3. replication, failover 전략.
2. 확장성
   1. 트래픽 증가에 따라 수평적으로 확장 가능.
   2. Stateless 기반 설계.
   3. 샤딩 전략 수립
3. 복잡성 통제
   1. 마이크로서비스 경계 명확화.
   2. 마이크로서비스 간 책임의 분리.
   3. 이벤트 브로커를 이용하여 순환 참조, 런타임 의존성 제거.
   4. 조직 규모 증가에 따른 관리 가능성의 유지.
4. 일관성
   1. 도메인에 따라 일관성 수준을 다르게 유지할 수 있음.

기술적 요구사항

1. 읽기 · 쓰기 분리
   1. CQRS.
   2. Query Model 구성.
   3. Redis 캐싱.
2. 비동기 메시징
   1. 메시지 발행 보장.
   2. 서비스 간 직접 의존성 감소.
   3. 장애 전파 차단.
   4. 최종 일관성 보장.
3. 데이터 확장 전략
   1. Horizontal Sharding.
   2. 분산 PK 전략.
4. 동시성 제어
   1. 도메인에 따라 이하의 방식 중 선택.
      1. 비관적 락.
      2. 낙관적 락.
      3. 비동기 직렬화 처리.
5. 캐싱 전략
   1. 도메인에 따라 배치 처리적용.
   2. 도메인에 따라 Cache-Aside 적용
   3. TTL 활용.
   4. Cache Stampede 제어할 것.

CAP 정리

분산 시스템의 한계

분산 시스템은 이하의 속성을 전부 온전히 충족시킬 수 없음. 추가적으로, Partition Tolerance의 경우, 네트워크 단절이 언제든지 발생할 수 있는 시스템의 특성을 고려할 때, 시스템의 정합성을 보장하기 위해 필수불가결한 특성임. Consistency와 Availability 중 도메인 특성에 맞춰 조절할 필요가 있음.

Consistency(C)

• 선행된 쓰기가 모든 후행 읽기에 즉각적으로 반영됨. | 강한 일관성
• 사용자는 항상 최신 데이터를 조회할 수 있음.

Availability(A)

• 일부 노드에 장애가 발생해도 시스템은 계속 응답해야 함.
• 모든 요청에 대해 응답을 반환함.

Partition Tolerance(P)

• 네트워크의 단절에도 시스템이 동작해야 함.
• 이벤트 기반 아키텍처는, 메시지의 발행과 실제 트랜잭션이 원자적으로 처리되지 않기 때문에 네트워크 단절 상황에서도 최종 일관성을 보장하기 위한 추가적인 설계가 필요함.

Partition Tolerance의 구현 전략

필요성

• 이벤트 기반 아키텍처에서는 메시지의 발행과 DB의 트랜잭션이 원자성을 가지지 않음.
• 네트워크 유실이 발생할 경우, 메시지의 발행 또는 DB의 트랜잭션이 실패하여 시스템 간 불일치가 야기됨.
• 네트워크 장애 상황에서도 비즈니스 로직은 수행하되 메시지를 최종적으로 전달하는(At-least-once delivery) 설계가 필수적임 | 최종 일관성

전략

2-Phase Commit (강한 일관성 모델, 비채택)

1. Prepare Phase
   1. Coordinator가 모든 Participant에게 준비 상태를 쿼리함.
   2. Participant는 로컬 트랜잭션 후, 성공적으로 완료할 수 있는지 확인하고 Lock.
   3. 준비가 되었을 경우 Yes, 아니면 No.
2. Commit Phase
   1. 모든 Participant가 Yes라고 응답할 경우, Coordinator가 Commit 명령을 내림. 단 하나라도 No, 또는 Timeout이 발생할 경우 Rollback.
   2. Participant는 Coordinator의 명령에 따라 커밋하거나 롤백함.
   3. 모든 보고가 완료되면 트랜잭션이 종료됨.

• Coordinator가 SPOF로 기능함.
• 응답 속도가 늦으며, 시스템의 가용성이 낮아짐.
• 인프라 단에서의 지원 필요함.
• Lock 점유 시간이 늘어남.

Transactional Outbox (최종 일관성 모델, 채택)

1. 서버가 이벤트 매니저로 메시지를 발행하기 이전에, 서버가 DB의 Outbox 테이블에 이벤트 전송 정보를 기록한다.
2. Message Relay | common:outbox-message-relay
   1. 별도의 Message Relay 프로세스가 Outbox 테이블을 폴링하여 이벤트 매니저로 이벤트를 발행한다.
   2. 이벤트가 발행되었을 경우, 해당 레코드를 삭제하거나 상태를 변경한다.
3. Transaction Log Tailing(CDC)
   1. DB가 각 트랜잭션의 로그를 기록한다. 별도의 에이전트가 로그를 추적하다가 Outbox 테이블에 로그가 기록될 경우, 감지하고 실행한다.

Transactional Outbox 특징

• 애플리케이션 단에서의 구현이 가능함.
• 2PC 기법에 비하여, 응답속도가 우수하고 가용성이 높음 | 최종 일관성
• 이벤트의 발행과 Consumer가 처리하기까지 지연이 발생할 수 있음.
• 모든 메시지의 최소 한 번의 발행을 보장함.
• 재시도 메커니즘으로 인한 중복발행이 발생할 수 있어 Consumer 측에서 별도의 멱등성 설계가 필요함.

Message Relay 특징

• 애플리케이션 단에서 구현이 가능함.
• DB로부터 독립적임.
• 메시지를 자유롭게 구성할 수 있음.
• DB에 지속적인 부하를 유발함.
• 실시간성 낮음.

적용

좋아요 | service:like

• 서비스 내부적인 원자성 · 유효성 체크.
• 네트워크 유실 상황에서도 At-least-once 발행을 보장하여 최종 일관성 보장.

서비스 내부적인 최종 일관성 보장, 시스템 관점에서 최종 일관성.

조회수 | service:view

• Redis를 주 저장소로, RDB를 백업으로 활용.
• 고빈도 쓰기 작업으로 인한 Write-Back + 배치 전략.
• 정합성보다 시스템 가용성과 응답 속도를 우선시하여 약간의 오차 허용.

공격적인 AP 추구, 최종 일관성.

인기글 집계 | service:hot-article

• 가중치 기반 스코어링 적용.
• 실시간 JOIN 대신, 비동기 이벤트 소비를 통한 스트리밍 처리.

시스템 전체의 처리량 · 읽기 성능 극대화를 위해 최종 일관성.

강한 일관성 vs. 최종 일관성

강한 일관성 (Strong Consistency)

• 쓰기 완료 후, 모든 읽기는 최신 값을 반환해야 함.
• 쓰기 완료 후, 이후의 모든 읽기에 대해 적용됨.
• 락, 동기화 비용 발생.
• 데이터의 일관성을 보장.
• 성능을 저하시키고, 확장 비용 증대.
• 분산 환경에서 구현 난이도가 높음.

최종 일관성 (Eventual Consistency)

• 일시적인 데이터 불일치를 허용하고, 시간이 지나면 수렴함.
• 데이터의 변경이 즉시 수정되지 않을수도 있음.
• 비동기 기반.
• 확장성이 높고, 가용성이 높음.
• 네트워크가 단절된 상황에서 유리함.
• 일시적으로 불일치가 발생하고, 설계가 복잡해질 수 있음.

적용

도메인	일관성 수준	사유
게시글 생성	시스템 차원의 최종 일관성. 다만, 서비스 내부적으로는 강한 일관성 보장함.	서비스 내부적으로는 @Transactional 어노테이션을 활용하여 DB와 직접 통신하나, 조회는 별도의 서비스가 담당하여(후술) 즉각적으로 반영되지 않을 수 있음. 조회 관점에서는 Transactional Outbox 패턴으로 최종 일관성 보장함.
좋아요	시스템 차원의 최종 일관성. 다만, 서비스 내부적으로는 강한 일관성 보장함.	서비스 내부적으로는 @Transactional 어노테이션을 활용하여 DB와 직접 통신하나, 조회는 별도의 서비스가 담당하여(후술) 즉각적으로 반영되지 않을 수 있음. 조회 관점에서는 Transactional Outbox 패턴으로 최종 일관성 보장함.
조회수	최종 일관성, 다만, 조회 시점에 Redis 실시간으로 참조함.	조회수 특성상 쓰기 빈도가 매우 높아 읽기 모델에 포함할 경우 캐시 무효화 비용이 과다하므로, Redis를 직접 참조함.
인기글	최종 일관성	여러 도메인의 이벤트를 소비하여 스코어링을 수행하므로 데이터 반영에 지연 발생.

구현

강한 일관성

• @Transactional 어노테이션을 통해 비즈니스 로직과 통계 업데이트(카운트), Outbox 기록을 하나의 원자적 작업으로 묶음.
• ArticleLikeService 등에서 비관적 락을 사용하여 동일 자원에 대한 경합 발생 시에도 데이터 정합성을 강제함.

최종 일관성

• 이벤트 발행을 외부 메시지 브로커가 아닌 로컬 DB의 Outbox 테이블에 위임하여 비즈니스 로직과의 원자성을 확보함.
• AFTER_COMMIT 시점의 즉시 발행과 스케줄러를 통한 미발행 데이터 재처리를 통해, 네트워크 장애 상황에서도 At-least-once을 보장함.

정리

도메인 특성과 서비스 간의 통신 여부 등에 따라, 일관성의 수준을 조절할 수 있음.

병목의 식별 전략

병목의 종류 #1

CPU 병목

• 서버의 연산량 과다.
• JSON 직렬화 · 역직렬화 비용 누적.
• 복잡한 비즈니스 로직.

메모리 병목

• 캐시 미스 증가.
• GC 빈도 증가.
• 과도한 객체 생성.

네트워크 병목

• 잦은 DB 호출.
• 마이크로서비스 간 호출.
• 외부 API 호출.

디스크 I/O 병목

• 인덱스가 적용되지 않는 쿼리.
• 집계 쿼리 과다.
• Full Table Scan

병목의 종류 #2

조회수 증가 로직

• 매 요청마다 UPDATE 쿼리 발생.
• 다수의 노드에서 동일한 행에 대한 접근 발생.

Redis 기반 배치 처리로 완화 가능.

인기글 집계 쿼리

• SELECT GROUP BY, ORDER BY, LIMIT 절 쿼리 발생.
• 대량의 데이터 스캔.
• 디스크 I/O 집중.

스트림 · 배치 처리 · 비정규화 · 캐싱 활용하여 완화 가능.

좋아요 처리

• 중복 방지 로직 필요함.
• 트랜잭션 충돌.
• 인덱스 설계에 따라 성능 저하 발생 가능.

병목 식별 방법

지표 수집

• CPU 사용률.
• 메모리 부하.
• DB 커넥션 수.
• SLOW QUERY 로그.

부하 테스트

• TPS · QPS 측정.
• 임계점 파악.

로그 기반 분석

• 특정 API에 대한 응답 지연.
• 타임아웃 발생 구간.
• 예외 빈도.

정리

확장 이전에 병목 지점 식별 필요함.

장애 전파 방식

장애 전파의 원인

동기 호출 구조

A -> B -> C

• C의 장애가 A, B에게로 전파됨.
• C의 장애가 시스템 전체의 장애로 이어짐.

커넥션 풀의 고갈

• DB 응답 지연.
• 외부 API 지연.
• 쓰레드 블로킹 증가.
• 커넥션이 반환되지 않을 경우, 대기 요청이 증가해 가용성이 저하됨.

자원 경합

• 단일 DB
• 단일 캐시 서버
• 공통 메시지 브로커
• 한 지점의 장애가 전체 기능에 영향을 주게 됨.

적용

인기글 집계의 지연

• 메인 페이지의 로딩 지연.
• DB 부하 증가.
• 전체 조회 API에 영향을 줌.

인기글 집계를 비동기로 분리.

좋아요 처리 지연

• 트랜잭션 간 동일한 행에 대한 락 경합.
• DB 커넥션 대기 증가.
• 전체 API 응답속도 저하.

장애 전파 방지 전략

비동기 처리

• 이벤트 기반.
• 메시지 큐 활용.

타임아웃 설정

• 외부 호출에 대한 타임아웃을 설정.
• 무한 대기 방지.

격리 전략

• 읽기 · 쓰기 분리. -> CQRS
• 기능 단위의 분리.

정리

장애를 국소화하여, 전체적인 가용성을 확보.

트래픽 특성에 따른 설계 전략

읽기 · 쓰기 트래픽이 비대칭적인 상황의 설계

읽기 중심 서비스의 특성

• 조회 요청 > 쓰기 요청.
• 동일 데이터에 대한 반복 조회 빈도 높음.
• 조회 요청이 일부 데이터에 대해 집중됨.

문제점

• 단일 DB에 대한 부하 집중.
• 쓰기 락이 읽기 지연으로 나타남.
• 확장 복잡도 높음.

설계 전략

캐시 계층 도입

• Redis 기반 Cache-Aside 전략 적용.
• DB I/O 감소.
• 응답 속도 개선.
• 캐시 무효화 전략 필요.
• 데이터 일관성 고려 필요.

집계 데이터 비정규화

• 조회수
• 인기글
• 통계성 데이터 -> 이러한 데이터를 비정규화하여 캐싱.

정리

트래픽이 집중되는 방향으로 확장한다.

CQRS

• Command: 상태를 변화시키는 요청(쓰기)
• Query: 데이터를 조회하는 요청(읽기) -> 두 모델을 분리하여 독립적으로 설계.

적용

Write Model

• 정규화 유지.
• 트랜잭션 중심 설계.
• 데이터 정합성 우선.

Read Model

• 조회가 잦은 데이터에 대한 비정규화 적용.
• 집계 데이터 포함.

장점

• 읽기 · 쓰기 독립적으로 확장 가능.
• 복잡도가 감소함.
• 장애가 전파되는 범위가 축소됨.
• 비동기 이벤트 기반으로 설계할 수 있음.

단점

• 구현 상의 복잡도 증가.
• 이벤트 처리 필요함.
• 최종 일관성 고려 필요.

적용 상황

• 읽기 트래픽이 압도적으로 높은 경우.
• 집계 조회가 잦은 경우.

정리

도메인 특성에 따라, 모델을 바꿔 성능을 최적화할 수 있음.

캐시 전략

데이터의 사본을 메모리 계층에 저장하여 디스크 I/O를 줄이고, 응답속도를 개선하여 읽기 트래픽으로 인한 병목을 완화하는 전략.

목적

• DB 부하 경감.
• 응답 속도 개선.
• 병목 완화.
• Hot-Data 반복조회 최적화.

대상

게시글 상세 조회

• 동일한 게시글에 대한 반복 조회 빈도 높음.
• 변경 빈도 낮음.

게시글 목록

• 페이지 단위로 발생.
• 인기 게시글에 대한 집중 트래픽 발생.
• ID 목록과, 개별 게시글을 캐싱하여 페이지 사이즈의 변경, 무한스크롤 방식에도 유연하게 사용할 수 있음.

인기글 집계

• 실시간성 낮음.
• 반복 조회 빈도 높음.
• 집계 쿼리(GROUP BY, ORDER BY)는 기타 서비스에 지속적인 I/O 유발하여 DB 부하를 누적시킴.

종류

Cache-Aside

1. 캐시 조회.
2. 없을 경우, DB 조회.
3. 결과를 캐시에 저장.
4. 응답 반환.

• 게시판 조회에 활용.

장점

• 구현이 단순함.
• 필요한 데이터만 캐시됨.

단점

• 캐시 미스 시, DB 부하 발생.
• 무효화 전략 추가 필요.

Write-Back

반복적인 쓰기를 캐시하고, 배치 단위로 DB에 저장. 조회수 집계에 활용.

장점

• 쓰기 성능 향상.
• DB 부하 감소.

단점

• 데이터 유실 가능.
• 일시적인 데이터 불일치 발생.

무효화 전략

TTL

일정 시간 후, 자동으로 캐시를 삭제함.

장점

• 단순하고, 안전함.

단점

• 만료 직후에 트래픽이 집중될 경우, 동시다발적인 DB 접근 발생함.

이벤트 기반 무효화

이벤트가 발생할 경우, 관련된 캐시를 갱신함.

장점

• 일관성 제어 가능.
• 데이터 변경 시점과 캐시 변경 시점을 동기화시킬 수 있음.
• TTL 의존도 저하 가능.

단점

• 이벤트 처리 복잡도.

정리

읽기 집약적 서비스에서는 캐시가 실질적으로 1차 데이터 소스로서 기능함. 아키텍처 설계 단부터의 융화가 필요함.

이벤트 기반 비동기 처리

메시지 브로커를 매개로, 서비스 간의 상태 변화를 발행(Publish), 구독(Subscribe)하여 전파하고, 이를 비동기적으로 처리하여 시스템 간의 결합도를 낮추는 설계 전략.

목적

• 서비스 내부적으로 발생하는 핵심 비즈니스 로직(예: 게시글의 저장)과 서비스가 통신하며 발생하는 부가적인 작업(예: 조회 모델 갱신, 집계)을 분리하여 응답속도를 개선함.
• 직접적인 API 호출을 제거하고, 이벤트를 통해 느슨하게 결합하여 각 마이크로서비스의 독립적인 확장을 가능하게 함.
• Consumer 서비스의 장애가 Producer 서비스의 비즈니스 로직에 영향을 주지 않도록 보호함.

구현

Transactional Outbox 패턴

• 비즈니스 로직의 DB 변경과 이벤트 데이터 저장을 하나의 트랜잭션으로 묶어 데이터 유실을 차단.

Kafka 기반 비동기 메시징

• 트래픽 폭증 시 이벤트를 Kafka에 적재하여 Consumer가 자신의 처리 속도에 맞춰 소비하게 함으로써 시스템 안정성 유지.

고려사항

• 발행과 소비 사이 시간 지연이 발생할 수 있음을 인지하고, 도메인 특성에 따라 반영할 것.
• MessageRelay의 재시도로 인해 동일한 이벤트가 중복 수신될 수 있으므로, Consumer 측에서 멱등성 설계할 것.

Projection 설계 전략

개념

커맨드 모델의 데이터를 읽기에 최적화된 구조로 변환한 것. 응답 시 필요한 데이터를 비정규화하여 저장해 다른 서비스로의 JOIN을 최소화하고, 프로그래머의 편의성을 증대함.

예시 | ArticleQueryModel

종류	필드/ 메서드명	상세
Long	articleId	* 이하 Article 클래스 필드
String	title	``
String	content	``
Long	boardId	``
Long	writerId	``
LocalDateTime	createdAt	``
LocalDateTime	modifiedAt	``
Long	articleCommentCount	ArticleCommentCountRepository로부터 fetch한 좋아요 수.
Long	articleLikeCount	ArticleLikeCountRepository로부터 fetch한 댓글 수.
팩토리 메서드	create	Kafka가 생성한 이벤트, 또는 DB에서 fetch한 내용을 기반으로 ArticleQueryModel을 생성하는 팩토리 메서드.
Setter	updateBy	Kafka가 생성한 이벤트를 기반으로 ArticleQueryModel을 갱신하는 메서드.

• 조회수 역시 조회 모델 생성에 필요하지만,
  • 실시간성이 높으며,
  • Redis를 주 저장소로 쓰기 때문에, 서비스 단에서 직접 결합하는 형태로 설계함.

설계 원칙

불변성

데이터를 변경하기 위한 모델이 아님. 외부에서 값을 조작할 수 없게할 것.

결합도 분리

DB의 스키마 변경과 모델의 변경을 분리할 것.

API 단위 설계

조회 API에 맞춰 설계할 것.

JOIN 제거

필요한 데이터는 미리 포함할 것.

집계 비정규화

댓글수, 좋아요수, 조회수 등의 집계값은 미리 포함할 것.(* 변동성이 큰 데이터는 모델에서 제외하고, 실시간 병합 등을 사용할 수 있음.)

동기화 방식

동기 업데이트

• 쓰기 시, 조회 모델을 즉시 업데이트함.
• 강한 일관성.
• 쓰기 성능 저하될 수 있음.

이벤트 기반 비동기 업데이트

• 이벤트를 소비한 뒤, 조회 모델을 업데이트함.
• 최종 일관성.

장점

• 읽기 성능 최적화.
• DB 부하 감소.
• API 구조 단순화.

단점

• 데이터 중복 증가.
• 동기화 복잡도 증가.
• 일시적인 불일치 발생 가능.

정리

트래픽 특성에 따라 정규화의 강도를 조절할 수 있음.

아키텍처의 선택

시스템의 규모, 팀의 구조, 도메인 복잡도에 따라 비용 대비 최적의 효율을 낼 수 있는 아키텍처를 선택해야 함. 본 프로젝트에서는 확장성, 도메인 간 격리를 위해 MSA를 채택함.

모놀리식 vs. MSA

Scale-Up & Scale-Out

Scale-Up

• 개별 서버의 CPU, Memory, Disk 성능 증가.
• 별도의 구조 변경 없음.
• 물리적인 한계 존재함.
• 임계점 이후부터는 비용 대비 효율이 급격히 감소함.

Scale-Out

• 서버 수의 횡적인 증가를 통해 처리량을 확장함.
• Load Balancer와 같은 별개의 디바이스를 통해 트래픽을 분산함.
• 추가적인 구조 변경이 필수적으로 수반됨.
• 비용 대비 효율이 Scale-Up 전략보다 우수함.

모놀리식

• 모든 기능이 단일 코드 베이스에 있음.
• 개발 · 배포가 간단함.
• 특정 컴포넌트의 부분적인 확장이 불가능함.
• 각각의 컴포넌트가 강하게 결합됨.
• 특정 컴포넌트의 장애가 시스템 전체로 전파됨.

MSA

• 기능 단위로 서비스를 분리함.
• 서비스 별로 독립적인 배포가 가능함.
• 특정 서비스만 개별적으로 확장할 수 있음.
• 네트워크 비용이 증가함.
• 분산 트랜잭션 문제가 발생함.
• 테스트 · 운영 복잡성이 크게 증가함.

MSA는 도메인 복잡도 · 트래픽 · 조직 규모가 충분히 클 때만 유의미한 아키텍처임. 복잡성과 확장성의 Trade-Off.

어떤 상황에 MSA를 적용하는가?

• 특정 기능에 트래픽이 집중돼, 해당 모듈만 추가 자원이 필요한 경우.
• 단일 코드 베이스 내에서, 모듈 간 참조가 얽혀 유지보수가 어려워지고, 작은 수정이 예기치 못한 부작용을 만드는 경우.
• 다수의 개발 팀이 서로의 배포주기에 간섭받지 않고 독립적으로 개발해야하는 경우.

어떤 상황에 MSA를 적용하면 안되는가?

• 비즈니스 모델이 고착화되지 않아 서비스 간의 경계가 불분명한 상황에서는, 분산 시스템의 복잡성이 생산성을 저해함.
• 분산 환경의 모니터링, 로그 추적, CI/CD 인프라가 미비한 경우 운영 비용이 크게 상승함.
• 단일 서버의 Scale-Up만으로 대처할 수 있는 규모에서는 MSA 도입의 이득보다 오버헤드가 더 큼.

서비스 경계의 확정

• 비즈니스 요구사항을 기준으로 응집도가 높은 기능을 하나의 서비스로 묶음.
  • 게시글, 댓글, 좋아요, 조회수를 각각 독립적인 서비스로 획정하여 데이터와 로직을 격리함.
• 데이터 산재로 인한 조회 성능 저하를 방지하기 위해 article-read와 같은 읽기 전용 서비스를 별도로 두어 경계를 최적화함.

서비스	역할
service:article	게시글 생명주기 제어
service:comment	댓글 계층구조 정의 · 비즈니스 로직
service:like	좋아요 중복방지 제어 · 비즈니스 로직
service:view	Redis 중심 조회수 배치 처리
service:hot-article	이벤트 스트리밍 및 HotArticleScoreUpdater 스코어링
service:article-read	CQRS Read 전용 서비스

데이터베이스 분리 전략

• 각 서비스는 자신만이 제어할 수 있는 전용 저장소를 가져야 함. 타 서비스의 데이터베이스에 직접 접근하는 것은 결합도를 높이므로 지양함.
• 도메인 특성에 따라 view 서비스는 고성능 처리를 위해 Redis와 RDB를 병행하고, article-read는 프로젝션 모델을 위해 Redis를 주 저장소로 사용하는 등 서비스별 최적의 스택을 선택할 수 있음.
• 분리된 DB 간의 일관성은 MessageRelay와 Kafka를 활용한 이벤트 기반 비동기 처리를 통해 최종 일관성으로 해결함.

데이터 계층 설�계

RDB | MySQL

스키마 설계

• 서비스 간 결합도를 완전히 제거하기 위해 게시글, 댓글, 좋아요 등 각 마이크로서비스별로 독립적인 데이터베이스 스키마를 할당함.
• 분산 환경에서의 유일성 보장 및 시간 순 정렬을 위해 모든 주요 엔티티의 기본키(PK)로 Snowflake를 채택함. 이는 Auto-increment의 보안 취약성과 UUID의 성능 저하 문제를 동시에 해결함.
• 고빈도 조회가 발생하는 게시글 당 댓글 수, 좋아요 수 등을 엔티티 내에 필드로 두지 않고 BoardArticleCount, ArticleLikeCount 등 별도 통계 테이블로 분리하여 관리함. 이는 메인 테이블의 쓰기 잠금(Write Lock) 경합을 줄이기 위함임.

댓글 계층 구조 모델링

• V1: 부모 댓글 ID를 참조하는 전형적인 계층 구조로 구현.
• V2: CommentPath 엔티티를 도입하여 댓글의 계층 경로를 문자열 등으로 관리, 복잡한 트리 구조 조회 성능을 최적화.

인덱싱 전략

• PK로 Snowflake를 사용하여, 데이터 삽입 시 시간 순으로 정렬함. 이는 삽입 시 인덱스 페이지 분할을 억제하고 쓰기 성능을 보존함.
• 집계 쿼리 발생 시, 실제 데이터 페이지에 접근하지 않고 커버링 인덱스 활용할 수 있도록 인덱스 구성.

페이징 최적화

• 페이지 번호가 뒤로 갈수록 발생하는 성능 저하를 방지하기 위해 PageLimitCalculator를 활용하여 스캔 범위를 상수로 제한함.
• 무한 스크롤 구현, lastArticleId를 조건절에 사용하여 인덱스 상의 현재 위치부터 즉시 스캔을 시작하도록 설계하여 일정한 조회 성능을 확보함.

복합 인덱스 구성

• 좋아요 중복 여부 확인(findByArticleIdAndUserId)을 위해 articleId와 userId를 묶는 유니크 복합 인덱스를 적용하여 검색 및 무결성 검증 속도를 높임.
• 게시판별 게시글 조회 성능을 위해 boardId와 articleId 조합에 대한 인덱스 고려.

샤딩 전략

데이터 규모가 단일 장비의 저장 용량, 처리 성능(IOPS)를 초과하는 상황을 해결하기 위한 데이터 분산 전략.

종류

Horizontal Sharding (채택)

• 행 단위 분리.
• 높은 확장성.
• JOIN, 트랜잭션 복잡도 높음.

Vertical Sharding

• 열 단위 분리.
• 확장성이 열의 수에 의해 제한됨.

Shard Key

• Range 기반 -> 범위 조회 유리함. 데이터가 쏠릴 수 있음.
• Hash 기반 -> 균등 분산. 범위 조회에 불리함.

어플리케이션 단위 샤딩 | AssignShard

분산 환경에서 DB에 정상 발행에 실패한 메시지가 남아 있으며, 복수의 MessageRelay 인스턴스가 존재할 경우, 발행 작업의 중복을 방지하고 부하를 분산함. | Load Balancer

• 샤드 코디네이터 | MessageRelayCoordinator
  • 분산 환경에서 MessageRelay가 동일한 이벤트를 중복 처리하지 않도록 인스턴스별 처리 범위를 할당함.
  • assignShards() 메서드를 통해 프로세스 별로 샤드를 지정하여 시스템의 처리량을 선형적으로 확장할 수 있음.
  • 3초마다 ping() 메서드를 통해 각 인스턴스의 APP_ID, 타임스탬프를 갱신함.
  • 9초간 응답이 없는 인스턴스는 자동으로 목록에서 제거됨.
• 샤드 기반 폴링 및 처리 | MessageRelay
  • @TransactionalEventListener(phase=TransactionPhase.BEFORE_COMMIT) 어노테이션을 이용해, 각각의 서비스가 메시지를 발행할 경우, 각 서비스의 비즈니스 로직과 이벤트의 저장을 원자화함.
  • @Async("messageRelayPublishEventExecutor") @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 어노테이션을 활용해, 폴링을 기다리지 않고 즉시 메시지를 발행한 뒤, �Kafka로 전송하고 삭제함.
    • 위 경로로 발행된 경우, 어플리케이션 인스턴스가 자신이 생산한 메시지를 직접 처리하기 때문에 AssignShard를 할당받지 않고 즉시 처리함.
    • 위 경로로 발행되지 못한 경우,publishPendingEvent() 쓰레드를 이용하여 At-least-once delivery를 보장함. 이 경우, 여러 MessageRelay가 공동으로 처리하기 때문에 AssignShard를 할당받아 처리함.

물리적 샤딩 | Shard Key

엔티티를 물리적으로 그룹화하고, 처리 순서를 보장함.

• MessageRelay는 Kafka로 메시지를 보낼 때, shardKey를 메시지 키로 사용함.
• 동일한 shardKey를 가진 메시지는 동일한 Kafka 파티션에 적재되므로, Consumer가 이벤트를 발생 순서대로 처리할 수 있게 하여 최종 일관성의 정합성을 높임.
  • 단, publishPendingEvent() 스케줄러로 발행된 메시지의 경우, 순서가 어긋날 수 있음.

엔티티	샤드 키	사유
service:article:Article, BoardArticleCount	boardId	개별 Article은 Board 단위로 조회되기 때문에, 게시판 단위로 일관성을 유지하기 위함.
service:comment:CommentV2, ArticleCommentCount	articleId	논리적으로 개별 Article에 종속되기 때문에, 통계 갱신 및 조회 모델과의 일관성을 게시글 단위로 유지하기 위함.
service:like:ArticleLike, ArticleLikeCount	articleId	논리적으로 개별 Article에 종속되기 때문에, 통계 갱신 및 조회 모델과의 일관성을 게시글 단위로 유지하기 위함.
service:ArticleViewCount	articleId	논리적으로 개별 Article에 종속되기 때문에, 통계 갱신 및 조회 모델과의 일관성을 게시글 단위로 유지하기 위함.

분산 환경에서의 유일성 보장

Auto Increment

• 분산 환경에서 유일성 보장 못함.
• 보안상 취약함.

UUID

• 랜덤 I/O 증가함.
• Clustered Index 성능 저하.

Snowflake

• 시간 순 정렬
• 분산 환경에서 유일성을 보장함.
• ID 상위 비트에 타임스탬프를 배치하여, 클러스터드 인덱스가 시간순 정렬로도 기능함.

트랜잭션 격리 수준

수준	Dirty Read * 커밋되지 않은 데이터 조회	Non-Repeatable Read * 한 트랜잭션 내부에서, 같은 값을 조회할 때 같은 값이 유지되는가?	Phantom Read * 같은 조건으로 재조회했을 때, 처음에는 없던 레코드가 나타나는 현상	상세
Read Uncommitted	O	O	O	커밋되지 않은 데이터도 읽음.
Read Committed	X	O	O	커밋된 데이터만 읽음.
Repeatable Read	X	X	O	트랜잭션 안에서, SELECT를 반복하더라도 같은 값 보장.
Serializable	X	X	X	완벽하나, 극심한 성능 저하.

MySQL 기본 격리 수준

• 기본적으로, 트랜잭션 내부에서 동일 데이터를 반복 조회할 때, 항상 같은 결과를 보장함. | Repeatable Read
• MVCC를 사용하여 대부분의 Phantom Read를 방지함.
  • 읽기 작업 시, 트랜잭션 시작 시점의 스냅샷을 기준으로 읽으며, 별도의 락 없음.
  • 쓰기 작업 시, Next-Key Lock을 통해 다른 트랜잭션의 삽입을 방지함.
  • SELECT FOR UPDATE, 다른 트랜잭션에서 삽입한 데이터를 UPDATE하는 경우와 같은 특수한 상황에서 Phantom Read 발생 가능.

동시성 제어 전략

• 비관적 락: 데이터 수정 시점에 DB 락을 획득하여 정합성을 강제함.
• 낙관적 락: 버전 정보 칼럼을 활용하여 실제 수정 시점에 충돌 여부를 확인하여 잠금 유지 시간을 최소화함.

분산 환경의 트랜잭션 한계

• Spring의 @Transactional 어노테이션은 단일 DB 인스턴스 내부적인 원자성만 보장함.
• 서버가 물리적으로 분산된 MSA 환경에서는 모든 서비스의 상태를 동시에 제어할 수 없음.

분산 환경의 트랜잭션

• 2PC 방식은 강한 일관성을 보장하나 지연 시간, SPOF 문제로 지양함.
• Transactional Outbox 패턴을 활용하여, 약간의 불일치를 감수하고 최종 일관성 모델을 사용함.

In-Memory | Redis

캐싱 대상 데이터 선정

유의사항

• 메모리의 저장공간은 디스크의 저장공간에 비해 작음.
• 캐시와 원본 사이의 정합성에 관한 오버헤드가 추가적으로 발생함.

타겟

• 조회 빈도가 높은 데이터
• 읽기/쓰기 비율이 비대칭적인 데이터.
• 연산 비용이 높은 데이터
• 일시적인 불일치가 허용되는 데이터

적용

읽기 전용 모델 | ArticleQueryModel

• CQRS 패턴에 따라 게시글, 좋아요 수, 댓글 수 등을 하나로 묶어 캐싱.
• 서비스 간의 API 호출 비용, 데이터 조립 비용을 제거하여 조회 성능 극대화함.

게시글 ID 목록 · 페이징 데이터 | ArticleIDList

• 객체 전체가 아닌 PK 목록만을 캐싱.
• 페이지 사이즈 변경, 데이터 수정 시 캐시 무효화 범위를 최소화하여 메모리 효율성, 유연성을 확보함.

고빈도 쓰기 데이터 | ArticleViewCount

• DB 데이터를 직접 업데이트하는 대신, Redis에 먼저 기록하고 배치 단위로 DB에 반영하는 Write-Back 전략.
• RDB 락을 최소화하여 쓰기 병목을 해결함.

실시간 집계 데이터 | HotArticleList

• 가중치에 따른 스코어링 결과를 ZSet을 이용해 관리함.
• 스트리밍 처리를 통해 추가적인 집계 쿼리, I/O 처리를 제거함.

고려사항

Cache Stampede

TTL 만료 직후 동시다발적인 DB 접근이 발생해 시스템이 마비되는 현상.

목표

• 논리적인 TTL과 실제 TTL을 분리하여, 논리적인 TTL은 만료되었으나 물리적인 TTL은 남는 구간을 두어, 데이터가 완전히 만료되기 전에 갱신할 기회를 확보함.
• 분산 락을 획득한 하나의 쓰레드만 DB에 접근하여 캐시를 최신화함.
• 락 획득에 실패한 나머지 요청의 경우, 대기하지 않고 과거 데이터를 즉시 반환하여 응답성을 유지함.

구현

Cache Stampede

• OptimizedCacheTTL: 논리적 TTL과 실제TTL을 분리함.
• @OptimizedCacheable: 캐시 대상 메서드에 적용하는 커스텀 어노테이션. 종류와 논리적 TTL 설정.
• OptimizedCacheAspect: @OptimizedCacheable가 선언된 메서드 실행 시, OptimizedCacheManager로 처리를 위임.
• OptimizedCacheManager: Redis를 우선 조회하여,
  • 캐시가 없을 경우 또는 물리적 만료 시, 원본 DB를 조회하고 Redis에 저장함.
  • 논리적으로 유효할 경우, 즉시 반환.
  • 논리적 만료 시, OptimizedCacheLockProvider 로 락을 요청.
    • 획득한 경우, 원본 DB를 조회하고 캐시를 갱신함.
    • 획득하지 못한 경우, 다른 쓰레드에서 갱신 중인 것으로 간주하고 과거 데이터를 즉시 반환함.

장점

• 분산 락을 통해, 논리적 만료 이후의 동시다발적인 요청을 방지함.
• 장애 상황에서도 물리적으로 남아있는 자료를 반환하여, 가용성을 극대화함.

Message Broker | Kafka

메시지 브로커의 역할

• Producer가 생산한 메시지를 적절한 Consumer에게 전달함.
• Producer, Consumer 사이에서 데이터를 버퍼링하며, 둘 사이의 입출력 속도 차이에 의한 병목을 완화함.
• 소비한 메시지를 즉시 삭제하지 않고 보관하여 장애 복구 시 재처리할 수 있도록 지원함.
• 메시지를 파티션 별로 분배하여 데이터 순서의 정합성을 보장하고 병렬 처리를 가능하게 함.

메시지 브로커의 필요성

• 서비스간 디커플링
  • Producer는 Consumer의 상태와 무관하게 메시지를 발행할 수 있음.
  • 시스템 확장 시, Consumer에 새로운 기능을 유연하게 추가할 수 있음.
• 장애 전파 방지
  • Producer가 Consumer의 장애로부터 자유로워짐.
  • 장애 복구 이후 메시지를 다시 소비하여, 최종 일관성을 유지할 수 있음.
• 트래픽 서지 대응
  • 트래픽이 폭증하는 상황에서, 메시지를 Kafka에 보관하여 Consumer의 처리 능력을 초과하는 부하로부터 시스템을 보호함.

전송 보장 수준

At-Least-Once Delivery

• 메시지가 유실되지 않음을 보장함.
• 중복 발행될 가능성 있음.

Exactly-Once

• 메시지가 중복 없이 정확하게 한번만 처리됨을 보장함.
• 시스템 오버헤드가 크고, 구현 복잡도가 높음.

Transactional Outbox 구현

흐름

1. 이벤트 캡쳐: 서비스 계층에서 비즈니스 로직 수행 중에OutboxEventPublisher::publish() 호출 -> ApplicationEvent 발생.
2. BEFORE_COMMIT: MessageRelay::createOutbox()가 DB의 Outbox 테이블에 기록함.
   • . @TransactionalEventListener(phase = BEFORE_COMMIT) 어노테이션을 통해 커밋 직전에 수행됨으로써 원자성을 보장함.
3. AFTER_COMMIT: MessageRelay::publishEvent() 쓰레드가, 커밋 후 Kafka로 메시지를 전송함.
   • @Async()어노테이션을 통해 별도 쓰레드에서 비동기 처리함. 응답성을 보존하고 지연을 최소화함.
   • 전송에 성공한 경우, Outbox 레코드를 삭제함.
4. 실패하거나 서버 중단으로 남은 데이터는 MessageRelay::publishPendingEvent() 스케줄러가 주기적으로 재발행함.

구성

OutboxEventPublisher

• 서비스 계층에서 트랜잭션 내부적으로 호출함.
• 내부적으로 ApplicationEventListener를 호출하여 Spring 이벤트를 발생시킴.

MessageRelay

• @TransactionalEventListener어노테이션의 phase 설정을 통해 DB 커밋 직전과 직후에 메시지를 저장하고 발행함.
• AFTER_COMMIT 시점의 발행은 별도의 비동기 쓰레드(messageRelayPublishEventExecutor)에서 처리하여, 서버의 응답성을 보존함. 추가적으로, 실제 비즈니스 로직과 메시지 발행 간의 지연을 최소화함.
• publishPendingEvent() 메서드가 MessageRelayCoordinator로부터 할당받은 샤드 내의 미발행 메시지를 조회하여 At-least-once delivery를 구현함. MessageRelayCoordinator
• 서버 인스턴스와 주기적으로 ping() 메서드를 통해, 서버 인스턴스의 생존 여부를 관리함.

특징

• 발행 완료된 데이터는 상태를 변경하는 대신 삭제함. Outbox 테이블의 크기를 일정 이하로 유지함.
• shardKey를 Kafka 전송 시 파티션 키로 사용하여, 엔티티에 대한 이벤트 처리 순서를 보장함.
• MessageRelay::publishPendingEvent()에 의해 동일 메시지가 중복 발행될 수 있으므로, Consumer에는 멱등성 처리가 요구됨.

정합성 전략

Consumer 멱등성 설계

Consumer에게 동일한 메시지가 여러 번 전달되더라도, 시스템의 상태가 최초 1회 처리된 것과 동일하게 유지되도록 하는 설계.

중복 발생의 원인

• MessageRelay는 메시지 전송 후, 수신 확인을 받지 못할 경우 성공할 때까지 재전송함. 이 과정에서 네트워크 지연 등으로 인해 동일한 메시지가 중복 발행될 수 있음.
• Kafka Consumer 그룹 내에서 파티션 소유권이 변경될 경우, 마지막으로 커밋된 오프셋 이후 메시지가 중복 소비될 수 있음.

멱등성 확보 전략

Unique Key Constraint

• ArticleCreatedHandler
• ArticleQueryModelRepository가 Key로 articleId를 사용하여 기존 데이터를 덮어쓰도록 설계됨.
• 메시지 수신 순서가 뒤바뀌는 Out-of-Order 문제가 있으나, 프로젝션 모델 특성상 치명적인 문제가 아니라고 판단함.

Unique Index Constraint

• ArticleLikeCountRepository
• DB의 UNIQUE INDEX 제약 조건 활용함.
• DB 엔진에 종속적임.

상태 기반 업데이트

• ArticleViewCountBackUpProcessor
• 수치를 더하는 연산 대신, 집계된 결과값을 덮어쓰는 방식을 사용하여 멱등성을 유지함.

고려사항

• 명시적인 멱등성 제어 대신, 인프라의 제약 조건을 사용함.
• service:hot-article, service:article-read과 같은 부가적인 데이터, 또는 프로젝션 모델에서 발생하는 문제는 기타 서비스에 비해 중요도가 낮다고 판단하고 인프라 수준에서만 제어함.