이종관
Back to Projects

DB 아키텍처 개선 및 분산처리

Celery 기반 분산처리로 서버 부하 대폭 감소

에이오팜·2025.01 - 2025.04·백엔드 개발
Celery
PostgreSQL
Redis
Django

1. 문제

시스템 규모가 커지면서 CPU 사용량이 높은 작업들이 메인 프로세스를 블로킹하는 문제가 심각해졌습니다.

기존 상황

  • 동기 처리로 인한 응답 지연
  • CPU-intensive 작업이 API 응답을 블로킹
  • 단일 서버에서 모든 작업 처리

2. 내가 맡은 역할

분산처리 시스템 전체 설계 및 구현을 주도했습니다.

| 영역 | 담당 업무 | |------|----------| | 아키텍처 | Celery 기반 분산처리 설계 | | DB 최적화 | PostgreSQL 인덱스 및 쿼리 튜닝 | | 모니터링 | 작업 모니터링 및 오류 처리 자동화 |

3. 핵심 기술 선택

메시지 브로커: Redis vs RabbitMQ

| 항목 | Redis | RabbitMQ | |------|-------|----------| | 설정 복잡도 | 단순 | 복잡 | | 성능 | 매우 빠름 | 빠름 | | 추가 활용 | 캐시 겸용 | 브로커 전용 |

선택: Redis - 이미 캐시로 사용 중, 운영 복잡도 최소화

4. 성능 결과

PostgreSQL 최적화 결과

| 쿼리 유형 | Before | After | 개선 | |-----------|--------|-------|------| | 목록 조회 | 2.3초 | 0.15초 | 93% ↓ | | 상세 조회 | 0.8초 | 0.05초 | 94% ↓ |

분산처리 도입 효과

| 지표 | Before | After | 개선 | |------|--------|-------|------| | API 응답시간 | 3초+ | 0.2초 | 즉시 응답 | | 서버 부하 | 90% | 40% | 50% ↓ | | 동시 처리량 | 5 req | 50 req | 10x ↑ |

5. 배운 점

  1. 분산 시스템 이해 - 멱등성(Idempotency) 설계의 중요성
  2. 데이터베이스 최적화 - 실행계획 분석, 인덱스 설계 원칙
  3. 비동기 아키텍처 - 결과적 일관성(Eventual Consistency)