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. 배운 점
- 분산 시스템 이해 - 멱등성(Idempotency) 설계의 중요성
- 데이터베이스 최적화 - 실행계획 분석, 인덱스 설계 원칙
- 비동기 아키텍처 - 결과적 일관성(Eventual Consistency)