스프링 대규모시스템설계 (3)

인기글 요구사항

• 일 단위로 상위 10건 인기글 선정
  • 매일 오전 1시 업데이트
  • 좋아요 수/댓글 수/조회수 기반 점수 계산
    • 점수 = (좋아요 수 * 3) + (댓글 수 * 2) + (조회수 * 1)
• 최근 7일 인기글 내역 조회

설계

• 매일 게시글 생성 트래픽은 수백~수천만 건 이상
• 하루동안 생성된 모든 게시글에 대해서,
  • 점수를 계산하고, 상위 10건을 찾아야하는 작업
  • 이러한 작업은 1시간 만에 처리되어야 한다.
• 대규모 데이터를 빠르고 효율적으로 처리하기 위한 방법이 필요하다.
• 배치 처리를 고려해볼 수 있다.
  1. 오전 12시가 되자마자, 전날 작성된 게시글을 모두 순회
  2. 각 게시글에 대해서 좋아요 수, 조회수, 댓글 수를 조회
  3. 게시글의 점수를 계산
  4. 모든 게시글에 대해서 상위 10건을 선정
• 배치 작업을 통해 문제없이 처리할 수 있지만, 제한사항이 존재한다.
  • 처리해야할 게시글의 개수는 대규모 데이터
    • 1시간 만에 처리하기에는 시간이 촉박할 수 있다.
      • 만약 오전 1시에 업데이트 되는게 아니라,
        • 오전 00시 10분에?, 오전 00시에 즉시 업데이트해야한다면?
    • 빠른 처리를 위해 병렬 시스템을 구축할 수 있다.
      • 하지만 설계와 구현 복잡도가 올라감
      • 병렬 처리하기 위한 장비의 리소스도 고려해야 함
• 병렬로 처리한다고 하더라도
  • 인기글 선정에는 게시글, 좋아요 수, 조회수, 댓글수 데이터가 필요하다.
    • 이러한 데이터는 각각 독립적으로 배포된 마이크로서비스에서 가지고 있다.
  • 1시간 만에 각 서비스에 무수히 많은 데이터가 필요하다.
    • 자정부터 1시간동안 인기글 서비스에 의해 타 서비스이 부하가 폭발적으로 상승할 수 있다.
    • 타 서비스에 영향이 갈 수 있다.
• 시간적인 제약, 개발 복잡성, 노출 시간 정책 등에 따라서 처리에는 한계가 생길 수 있다.
• Stream Processing(스트림 처리) 에 대해 알아보자
• 스트림(Stream)
  • 연속적인 데이터 흐름
  • 실시간으로 발생하는 로그, 센서 감지, 주식 거래 데이터 등과 같이 연속적으로 들어오는 데이터
• 스트림 처리(Stream Processing)
  • 스트림을 처리하는 것
  • 연속적으로 들어오는 실시간 데이터를 처리하는 방식
• 인기글 선정을 위해 스트림 처리 애플리케이션을 구축
  • 게시글 생성/수정/삭제 이벤트
  • 댓글 생성/삭제 이벤트
  • 좋아요 생성/삭제 이벤트
  • 조회수 집계 이벤트
• 위 이벤트를 실시간으로 받아서 처리하면?
  • 별도의 배치 시스템을 구축하지 않고도, 실시간으로 인기글에 필요한 점수를 계산하여 상위 10건을 미리 생성해 둘 수 있을 것

최종 설계

1. 인기글 선정에 필요한 이벤트를 스트림으로 받는다.
2. 실시간으로 각 게시글의 점수를 계산한다.
3. 실시간으로 상위 10건의 인기글 목록을 만든다.
4. Client는 인기글 목록을 조회한다.

1. 스트림 데이터 소스는 스트림 데이터를 생산한다. 스트림 데이터는 실시간으로, 연속적으로 생산된다.
2. 스트림 데이터는 데이터 처리기로 전달된다. 데이터 처리기는 스트림 데이터를 처리한다. 데이터 가공 또는 필터링 또는 집계 등 다양한 방식으로 처리할 수 있다.
3. 작업을 수행한 데이터 처리기는, 결과를 생성한다. 이러한 결과는 Client에 의해 사용될 수 있다.

• 여기서 스트림 데이터 소스는 게시글/댓글/좋아요/조회수 서비스가 될 수 있고, 데이터 변경 사항에 대해서 실시간으로 스트림 데이터를 생산한다.
• 스트림 데이터 소스는 위 이벤트를 스트림 데이터로 생산하는 것이다. 이때, 조회수 이벤트는 트래픽이 많을 수 있으므로 백업 시점(100개 단위)에만 생산해본다. 트래픽이 많은 조회수까지 반드시 정확하게 점수를 계산할 필요는 없다는 관점이다.!

• 인기글 서비스는 이러한 이벤트를 받아서 인기글 선정 작업에 사용한다. 이벤트를 받을 때마다 점수를 계산하고, 상위 10건의 인기글 목록을 생성해 두는 것이다. 이렇게 선정된 인기글 데이터(처리 결과)는 7일간 내역만 관리하면 되므로, 휘발성 데이터이다. 또, 일 단위 상위 10건의 게시글 데이터만 필요하므로, 커다란 저장공간이 필요하진 않다.
• 여기선 Redis를 사용한다. 빠른 저장소로서의 이점도 있고, TTL도 지원하기 때문에 지정된 기간이 지나면 자동 삭제 가능
• 또, 다양한 자료 구조를 지원한다. Sorted Set(=zset) 자료 구조는, 점수를 기반으로 정렬된 집합 데이터를 관리할 수 있다.
• 상위 점수 10건의 게시글을 정렬 상태로 유지할 수 있다.
• 게시글/댓글/좋아요/조회수 서비스는, 실시간 이벤트를 인기글 서비스로 어떻게 전달 가능한가?
  • 인기글 서비스는 자신의 리소스에 알맞게 일기글 선정 작업을 유연하게 처리할 수 있어야 한다.
  • 이러한 이벤트 전달 및 처리 과정은 대규모 데이터에 대해서 안전하고 빠르게 처리되어야 하는 것이다.
  • API vs Message Broker 두 가지 방식에 대해서 알아보자

API

• 데이터 변경이 생기면, 인기글 서비스로 API를 이용한 이벤트 전송
• 간단하게 구현
• 타 서비스에 직접적 의존, 시스템 간 결합도 증가
• 서버 부하 전파
  • 인기글 : 데이터를 실시간으로 push 받음
  • 게시글/좋아요/조회수/댓글 :데이터를 실시간으로 push
  • 장애 전파, 유실등의 위험 높음

Message Broker (✅ 채택)

• 데이터 변경이 생기면, 메시지 브로커는 이벤트 전송, 인기글 서비스에서 이벤트를 가져와서 처리
• 복잡한 구현 : 대규모 데이터를 안전하게 처리하기 위한 시스템이 필요할 수 있음
• 타 서비스에 메시지 브로커를 이용한 간접적 의존성, 시스템 간 결합도 감소
• 서버 부하 전팜
  • 인기글 : 메시지 브로커에서 적적하게 이벤트를 가져와서 비동기 처리가능
  • 게시글/좋아요/조회수/댓글: 메시지 브로커로 이벤트 전송만 하면 됨
  • 장애 전파, 유실 등의 위험 낮음
• 구현은 복잡하나, 대규모 시스템에서 많은 장점을 가짐
• 한번 구축해 두면, 높은 활용도
  • Consumer Group만 달리하여 각 목적에 따라 병렬로 처리 가능
  • 게시글 조회 최적화에도 사용할 예정

Kafka를 사용하여 이벤트 전송을 중개

• 게시글/댓글/좋아요/조회수 서비스 : Producer
• 인기글 서비스 : Consumer

이렇게 이벤트를 주고받으며 마이크로서비스 간에 통신하는 아키텍처를 Event Driven Architecture 라고 한다.

인기글 서비스가 인기글 데이터 생성 과정

• 오늘 날짜 2025년 10월 1일
  • 10월 1일에 작성된 게시글은, 2일 오전 1시부터 제공해야 할 인기글이 된다.
  • 1일 00시 00분 ~ 2일 00시 00분 사이에 작성된 게시글에 대한 이벤트는 각 게시글의 점수를 실시간으로 계산하여 Redis(key=20251001)에 삽입
  • key=20251001은 Sorted Set(zset) 자료구조를 사용한다.
  • 각 게시글의 점수를 기반으로 정렬된 상태를 가지는 것(data = 게시글 ID, score=게시글 점수)
  • 이를 이용하여 Sorted Set에 상위 10건의 데이터만 유지
• 오늘 날짜 2025년 10월 2일
  • 이제부터 작성되는 게시글은 key=20251002의 Sorted Set에 삽입된다.
  • key=20251001은 완성, 더이상 건들일 필요 없음
  • 오전 1시가 되면, 인기글 제공한다. 어제 미리 실시간으로 만들고 있었기에 배치 작업은 불필요, Client가 조회해야하는 데이터만 지정
• 만약 점수 계산에 댓글의 유니크 작성자 수가 필요하다면?
  • 이러한 데이터는 댓글 서비스에서 제공하지고 보유하고 있지도 않음
  • 댓글 서비스가 인기글을 위한 데이터를 생산하고 관리할 책임은 없음, 즉 이러한 데이터를 생산하고 관리할 책임은 인기글
  • 인기글 서비스가 필요한 데이터를 자첵적으로 보관한다면?
    • 이벤트로 전달받은 원본 데이터를 기반으로, 데이터를 자체적으로 가공 및 생산 가능
    • 다른 서비스에 의존하지 않고, 독립적으로 기능 제공 가능
    • 따라서 점수 계산에 필요한 데이터를 실시간으로 각 서비스에 다시 요청하지 않고, 자체적으로 데이터를 가지도록 한다.
    • 이러한 데이터는 하루만 보관하면 되지만, 용량이 크지 않으므로 접근이 빠르고 휘발성을 가지는 Redis를 사용

Producer

• 게시글/댓글/좋아요/조회수 서비스는 Kafka로 이벤트를 전달하는 producer 역할
• Producer는 정의된 이벤트를 Kafka로 잘 전달하면 됨

Transactional Messaging

• 데이터의 일관성, 원자성 관리를 위해 트랜잭션 관리는 중요(모두 실행되거나, 실해되지 않거나)

1. Producer는 비지니스 로직 수행
2. Kafka로 이벤트 데이터 전송
3. Consumer는 Kafka에서 이벤트 데이터를 가져와 처리
4. Producer에서 전송한 이벤트가 Consumer에서 처리하는 과정에는, 네트워크를 통한 복잡한 전송 과정이 필요하다.
   • 네트워크는 언제든 순단될 수 있고, Producer/Consumer/Kafka에서는 장애가 발생할 수 있다.

• 이러한 과정에서 데이터는 유실 없이 처리될까?
  Kafka에 데이터가 정상적으로 전달되었다면, 장애가 발생하더라도 복구 가능하다.
  Consumer는 이벤트 처리를 정상적으로 모두 완료한 이후에는 offset을 commit하면, 데이터 유실없이 처리 가능

Producer가 Kafka에 이벤트를 전달하는 과정에 장애가 발생한다면?

• Producer는 Kafka로의 데이터 전송과 무관하게 정상 동작해야함
• 데이터 전송이 실패한다해서, Producer에 장애가 전파되면 안됨
  • 게시글은 정상 생성되어도, 이벤트를 Kafka에 전달할 수 없는 상황
• 신뢰할 수 있는 시스템(Kafka)로 아직 데이터가 전송되지 못했기 때문에, 이벤트 데이터는 유실
• 이로인해 각 서비스마다 데이터의 일관성이 깨짐
  • Producer에서 게시글이 생성되었지만, Consumer는 이 사실을 전달받지 못한것
• 그래서, 비즈니스 로직 수행과 이벤트 전송이 하나의 트랜잭션으로 처리되어야함
  ⚠️ 비즈니스 로직 수행과 이벤트 전송이 모두 일어나거나, 모두 일어나지 않거나
• 이러한 보장은 꼭 실시간으로 처리될 필요는 없음
• 비즈니스 로직은 우선적으로 처리되더라도, 이벤트 전송은 장애가 해소된 이후 뒤늦게 처리되어도 충분할 수 있음
• 최종적으로 일관성이 유지될수도 있는 것(Eventually Consistency)

1. Transaction start
2. 비즈니스 로직 수행
3. commit or rollback

• 이러한 트랜잭션은 스프링의 @Transactional을 이용하면 손쉽게 적용 가능
• 여기에 단순하게 이벤트 전송 코드를 포함하며?

1. Transaction start
2. 비즈니스 로직 수행
3. publishEvent()
4. commit or rollback

• 지금까지 사용하던 트랜잭션은 MySQL의 단일 데이터베이스(1개 샤드)에 대한 트랜잭션
• MySQL의 상태 변경과 Kafka로의 데이터 전송을, MySQL의 트랜잭션 기능을 이용해서 단일 트랜잭션으로 묶을 수 없음
• 서로 다른 시스템이기에
• 만약 이벤트 전송작업이 Kafka 장애로 인해 블로킹 된다면??
  • Kafka의 장애가 서버 애플리케이션과 MySQL로 전파될수 있음
  • 또는, 트랜잭션 commit이 실패했는데, 이벤트 전송은 이미 완료되었을 수 도...

1. Transaction start
2. 비즈니스 로직 수행
3. publishEventAsync()
4. commit or rollback

• 만약 3번이 비동기로 처리된다면?
  • 비동기로 처리된 이벤트 전송이 실패한다해서, MySQL의 트랜잭션이 자동으로 롤백되지 않는다.
  • 롤백을 위한 보상 트랜잭션을 직접 수행할 순 있지만, 누락될 수 도 있다.
• 2개의 다른 시스템을 어떻게 단일한 트랜잭션으로 묶을 수 있을까?
  • 분산 시스템 간에 트랜잭션 관리가 필요
• Distributed Transaction : 분산 시스템에서트랜잭션을 보장하기 위한 방법
• Transactional Messaging : 메시지 전송과 타 시스템 작업 간에 분산 트랜잭션을 보장하는 방법

Transactional Messaging

1. Two Phase Commit

• 분산 시스템에서 모든 시스템이 하나의 트랜잭션을 수행할 때,
  • 모든 시스템이 성공 : 트랜잭션 commit
  • 하나라도 실패 : 트랜잭션 rollback
• 두 단계로 나뉘어 수행됨
  • Prepare phase(준비 단계)
  • Commit phase(커밋 단계)

1-1. Prepare Phase

• Coordinator는 각 참여자에게 트랜잭션을 커밋할 준비가 되었는지 확인
• 각 참여자는 응답

1-2. Commit Phase

• 모든 참여자가 준비 완료 응답을 보내면, Coordinator는 모든 참여자에게 트랜잭션 커밋 요청
• 모든 참여자는 트랜잭션을 커밋함
• 모든 참여자의 응답을 기다려야 하므로, 지연이 길어질 수 있다.
• Coordinator 또는 참여자 장애가 발생하면,
  • 참여자들은 현재 상태를 모른채 대기해야함
  • 트랜잭션 복구 처리가 복잡해질 수 있음

Transactional Outbox

• 이벤트 전송작업은 일반적인 데이터베이스 트랜잭션에 포함시킬 수 없다.
• 하지만 이벤트 전송 정보를 데이터베이스 트랜잭션에 포함하여 기록 가능
  • 트랜잭션을 지원하는 DB에 Outbox 테이블을 생성하고, 서비스 로직 수행과 Outbox 테이블 이벤트 메시지 기록을 단일 트랜잭션으로 묶는다.

1. 비즈니스 로직 수행 및 Outbox 테이블 이벤트 기록
   1. Transaction start
   2. 비즈니스 로직 수행
   3. Outbox 테이블에 전송할 이벤트 데이터 기록
   4. commit or rollback
2. Outbox 테이블을 이용한 이벤트 전송 처리
   1. Outbox 테이블 미전송 이벤트 조회
   2. 이벤트 전송
   3. Outbox 테이블 전송 완료 처리

1. Client는 데이터 생성/수정/삭제 등의 요청을 받음
2. Client 요청에 의해, 단일 트랜잭션 내에서 Data Table의 상태 변경과 Outbox Table 에 이벤트 삽입이 처리
3. Message Relay는 Outbox Table에서 미전송 이벤트를 조회

Message Relay : Message Broker로 이벤트를 전송하는 역할
4. Message Relay는 이벤트를 Message Broker로 전송
5. Message Relay는 이벤트 전송이 정상적으로 완료되었으면, Outbox Table의 이벤트를 완료 상태로 변경

Transaction Log Tailing Pattern

• Message Broker로 전송하는 작업을 위해 활용
• DB의 트랜잭션 로그를 추적 및 분석하는 방법
  • DB는 각 트랜잭션의 변경 사항을 로그로 기록
  • MySQL binlog, PostgreSQL WAL, SQL Server Transaction Log 등
• 이러한 로그를 읽어서 이벤트를 전송해볼수 있다.
  • CDC(Change Data Capture) 기술을 활용하여 데이터의 변경사항을 다른 시스템에 전송
  • CDC : 데이터 변경 사항을 추적하는 기술

• DB에 의해서 트랜잭션 변경 사항이 로그로 기록
• Transaction Log Miner는 Transaction Log 조회
• Transaction Log Miner는 Message Broker로 이벤트 전송
• Data Table의 변경 사항만 추적해도 충분하다면, Outbox Table은 삭제 가능

Transactional Outbox 설계

• Shard_key의 존재?
  • 샤딩이 고려된 분산 DB 사용중
  • 트랜잭션은 각 사드에서 단일 트랜잭션으로 빠르고 안전하게 수행될 수 있음
  • 여러 Shard 간에 분산 트랜잭션을 지원하는 DB도 있으나, 성능이 다소 떨어짐
  • Outbox Table에 이벤트 데이터 기록과 비즈니스 로직에 의한 상태 변경이 동일한 Shard에서 단일 트랜잭션으로 처리될 수 있도록 함

1. 게시글 서비스로 게시글 생성/수정/삭제 API가 호출
2. 비즈니스 로직을 수행하면서, Article Table 상태 변경과 Outbox Table 이벤트 기록을 단일 트랜잭션으로 처리
3. Message Relay는 Outbox Table에서 미전송 데이터를 주기적으로 polling 하여 조회하고, Kafka로 전송
   간격이 너무 짧으면 DB 부하⬆️, 간격이 너무 길면 이벤트 전송에 지연 발생
   10초 간격으로 polling 하더라도, 여전히 지연이 큼
   게시글 서비스에서 트랜잭션이 commit되면, Message Relay로 이벤트를 즉시 전달. Message Relay는 전달받은 이벤트를 비동기로 Kafka 전송 가능
4. Message Relay는 전송이 실패한 이벤트에 대해서만 Outbox Table에서 polling. 그렇지 않으면, Message Relay로의 이벤트 전달될 수 있는 지점이 2개이므로 중복 처리 될 수 있다.
5. 실패한 이벤트는 장애 상황에서만 발생할 것이고, 정상 상황에서는 10초 정도면 이벤트 전송할 시간으로 충분했을 것
   • 생성된지 10초가 지난 이벤트만 polling
   • 물론, 여전히 이벤트는 중복 처리될 수 있으므로 Consumer 측에서 멱등성을 고려한 개발은 필요
6. 전송완료되었다면, Outbox Table에서 삭제
   • 이벤트는 비즈니스 관점에서 유의미할 수 있고, 이후에도 추적 또는 리플레이가 필요한 상황도 있음(Event Sourcing)
   • 그러나 여기서는 이벤트 전송 용도로만 사용하므로 삭제
7. 게시글 서비스가 여러 서버 애플리케이션에서 동시에 처리될수도 있고, DB 샤딩이 고려된 분산 시스템이다. Message Relay가 Outbox Table의 미전송 이벤트를 polling 하는 작업은 어떻게?
   • 미전송 이벤트를 polling 하는 것은 특정한 샤드 키가 없으므로, 모든 샤드에서 직접 polling
   • 모든 애플리케이션에서 동시에 polling 하면, 중복 처리나 처리에 지연이 발생할 수 있다.
   • 각 애플리케이션이 처리할 샤드를 중복 없이 적절히 분산해야함
8. 각 애플리케이션은 샤드의 일부만 할당받아서 처리하도록 해보자. 이러한 할당은 Message Relay내의 Coordinator가 처리
9. Coordinator는 자신을 실행한 애플리케아션의 식별자와 현재 시간으로, 중앙 저장소에 3초 간격으로 ping. 이를 통해 Coordinator는 실행 중인 애플리케이션 목록을 파악하고, 각 애플리케이션에 샤드를 적절히 분산
10. 중앙 저장소는 마지막 ping을 받은지 9초가 지낫으면, 애플리케이션이 종료되었다고 판단하고 목록에서 제고
    • 중앙 저장소는 Redis의 Sorted Set을 이용
    • 애플리케이션의 식별자와 마지막 ping 시간을 정렬된 상태로 저장 가능