파일 스튜디오

01

이벤트 유실을 막기 위한 Outbox + CDC 구조

DB 저장과 MQ publish 사이의 이중쓰기 문제를 해결하였습니다.

Debezium Outbox

RabbitMQ

SITUATION상황

파일 업로드 후 API에서 DB 저장 + MQ publish를 직접 수행할 경우 이중쓰기 문제가 발생할 수 있었다. 또한 polling 방식은 불필요한 DB 조회가 발생했다.

TASK과제

이벤트 유실 없이 정합성 보장
DB polling 없이 변경 기반 이벤트 처리
API와 MQ 간 결합도 제거

ACTION실행

DB polling — 주기적 SELECT로 작업 확인, 실시간성 저하 및 불필요한 DB 부하 증가 → 제외
API에서 직접 MQ publish — DB 저장과 MQ publish 중 한쪽만 실패하면 이중쓰기 문제 발생 → 제외
Transactional Outbox + CDC — DB 저장과 outbox_event 저장을 같은 트랜잭션으로 묶어 원자성 보장, Debezium이 변경 감지 후 MQ 발행 → 선택

RESULT결과

이중쓰기 문제 해결

이벤트 유실 가능성 감소

DB polling 제거

서비스 결합도 감소

💡 배운 점: 분산 환경에서는 MQ 발행보다 이벤트 기록이 먼저이고, CDC는 polling을 대체하는 강력한 방식이다.

포스팅 보기

02

큐 깊이와 ALB 요청 수 기반 자동 확장 구조

비즈니스 메트릭으로 API·Worker를 각각 다른 방식으로 자동 스케일링하였습니다.

ASG Lambda CloudWatch

Terraform

SITUATION상황

요청이 몰릴 경우 두 서버의 부하 특성이 달라 동일한 스케일링 방식을 적용하기 어려워, 각 서버에 맞는 자동 확장 구조를 사전에 설계했다.

TASK과제

Worker: RabbitMQ 큐 깊이를 기준으로 부하에 비례한 단계적 확장
API: ALB 요청 수를 기준으로 인스턴스당 처리량 목표를 유지하는 자동 확장
신규 인스턴스 기동 시 최신 이미지 자동 배포

ACTION실행

- Worker 서버

CPU 기반 스케일링 — CPU가 낮아도 큐가 쌓일 수 있고 CPU가 높아도 큐가 비어있을 수 있어 실제 부하와 괴리 발생 → 제외
RabbitMQ 큐 깊이 기반 스케일링 — Lambda가 messages_ready 수를 1분마다 수집해 CloudWatch 커스텀 메트릭으로 퍼블리시, CPU와 달리 실제 처리 대기량과 직결 → 선택

- API 서버

Step Scaling — 구간별 증감을 직접 정의해야 해서 트래픽 패턴을 미리 예측해야 함, 예측이 어긋나면 대응 미스 가능 → 제외
Target Tracking — 목표값(인스턴스당 100 req/s)만 지정하면 AWS가 자동으로 증감 계산, ALB 메트릭이 AWS 제공이라 완벽 지원 → 선택

RESULT결과

스케일 아웃·인 자동화

오버프로비저닝 방지

Worker 인프라 Terraform 코드화

재현 가능한 환경 구성

💡 배운 점: 스케일링 메트릭은 CPU가 아닌 실제 부하(큐 깊이·요청 수)와 직결된 비즈니스 메트릭을 써야 하고, 스케일 아웃은 빠르게·스케일 인은 천천히 가져가는 비대칭 설계가 불필요한 인스턴스 순환을 막는다.

03

Redis Pub/Sub으로 파일 변환 상태를 실시간 반영한 구조

Redis Pub/Sub + SSE로 실시간 상태 처리를 구현하였습니다.

Redis SSE Pub/Sub

SITUATION상황

변환 진행 상태를 DB polling 방식으로 제공한다면 요청이 증가할수록 DB read 부하가 급격히 증가하고 실시간성이 떨어지는 문제가 있었다.

TASK과제

변환 진행 상태를 실시간으로 사용자에게 전달
DB 부하를 최소화하면서 낮은 지연으로 상태 동기화
Pub/Sub 방식을 구성해 다수 요청 상황에서도 확장 가능한 구조 설계

ACTION실행

DB polling — 요청이 늘수록 DB read 부하 선형 증가 → 제외
서버 메모리 — 인스턴스가 여러 대면 상태 불일치 발생 → 제외
WebSocket — 단방향 전달만 필요한 구조에 오버스펙, 연결 유지 비용 부담 → 제외
Redis Pub/Sub + SSE — DB 조회 없이 실시간 전달 가능 → 선택

RESULT결과

DB read 부하 감소

상태 전달 지연 최소화

실시간에 가까운 처리 구현

💡 배운 점: "실시간" 문제는 DB보다 메시지 기반 구조로 풀어야 하고, 상태 데이터는 저장보다 전파가 중요하다.

04

대용량 업로드에서 서버를 거치지 않게 만든 구조

Presigned URL 기반 직접 업로드로 병목을 대비하였습니다.

S3 Presigned URL

SITUATION상황

파일 업로드 시 API 서버를 통해 S3로 업로드하는 구조를 고려했으나, 대용량 파일 처리 시 서버 리소스 사용량 증가 및 병목 가능성이 존재했다.

TASK과제

서버 부하 없이 파일 업로드 처리
업로드 경로 및 파일명은 서버가 통제
확장 가능한 구조 설계

ACTION실행

API 서버를 통한 업로드 — 파일 크기만큼 서버 메모리를 점유하고 네트워크를 두 번 타는 구조, 대용량일수록 병목 가능성 증가 → 제외
Presigned URL 직접 업로드 — API 서버는 URL만 발급, Client가 S3에 직접 업로드해 서버가 파일을 거치지 않는 구조, 병목 가능성을 구조적으로 제거 → 선택

RESULT결과

API 서버 파일 스트림 제거

대용량 업로드 안정화

병목 가능성 감소

확장성 향상

💡 배운 점: 서버는 파일 전달이 아니라 경로와 권한을 관리해야 하고, 대용량 처리에서는 데이터 경로 최적화가 핵심이다.

05

실시간성과 안정성을 함께 확보한 통계 보정 구조

Redis와 DB 보정 전략으로 실시간 통계를 운영 가능하게 만들었습니다.

Redis

MySQL Flush

SITUATION상황

전역 통계를 Redis 기반으로 실시간 제공했지만, 메모리 특성상 장애 발생 시 데이터 유실 가능성이 존재했다.

TASK과제

실시간성과 데이터 안정성 동시에 확보
Redis 장애 시 fallback 구조 필요

ACTION실행

DB 직접 조회 — 조회마다 SELECT, 동시 요청 많아지면 hot row 문제 및 부하 증가 → 제외
Memcached — 영속화 기능 부재로 DB에 따로 저장하는 로직 구현이 필요함, 이미 Redis를 운영 중이라 별도 인프라를 추가할 이유가 없음 → 제외
Redis + 주기적 DB flush — 인메모리로 빠른 읽기/쓰기, 주기적 DB 저장으로 영속성 확보, 장애 시 DB 기준 재집계 가능 → 선택

RESULT결과

실시간 + 영속성 확보

장애 시 데이터 복구 가능

hot row 문제 완화

안정적 통계 유지

💡 배운 점: Redis는 빠르지만 영속성은 없고, 실시간 시스템에는 반드시 보정 전략이 필요하다.

프로젝트 핵심 사항

이벤트 유실을 막기 위한 Outbox + CDC 구조

큐 깊이와 ALB 요청 수 기반 자동 확장 구조

Redis Pub/Sub으로 파일 변환 상태를 실시간 반영한 구조

대용량 업로드에서 서버를 거치지 않게 만든 구조

실시간성과 안정성을 함께 확보한 통계 보정 구조

트러블 슈팅

Redis 재기동 시 Thundering Herd → Hikari 풀 고갈

Debezium 크래쉬 루프 해결