AWS 비용 최적화 (feat 거래소 캔들 데이터)
📌 개요
캔들 데이터를 제공하는 시스템은 거래량 증가에 따라 데이터 누락과 불필요한 비용 증가 문제가 발생했습니다.
이에 따라 캔들 서비스 전반에 걸쳐 최적화 작업을 수행하여 연간 약$12,000 절감 사례를 소개합니다.
🚨 문제점 분석
1. 데이터 무결성 문제
증분 동기화 로직의 치명적 결함
문제 상황
- 거래량이 많은 시간대(초당 1,000건 이상)에서 거래 데이터 누락 발생
- PostgreSQL → ClickHouse 동기화 Lambda 함수의 증분 로직 결함
- 증분 로직이 무한 루프에 걸리며 데이터 증분이 되지 않는 현상 발생
문제가 되는 쿼리
SELECT market_id, seq, price, quantity, cost, time
FROM pg_trade
WHERE time >= TIMESTAMP_ADD(toStartOfSecond(toDateTime64({max_time: String}, 3)), INTERVAL -1 MINUTE)
ORDER BY time, market_id, seq
LIMIT 1000
문제 발생 메커니즘
- 잘못된 윈도우 설계
max_time기준 1분 전부터 데이터 조회- 매 실행마다 동일한 시간 범위 반복 조회
- LIMIT 1000의 한계
- 1분 내 1,000건 초과 시 나머지 데이터 무시
- 같은 1,000건만 반복 처리
- 무한 루프 증분 정체
- 데이터 손실
- 1분 윈도우 내 1,000건 초과 데이터는 영원히 처리되지 않음
max_time이 앞으로 진행하지 못해 증분 프로세스 멈춤
2. 비용 구조 문제
| 구분 | 문제 내용 | 월 비용 |
|---|---|---|
| Lambda | 1분마다 호출되는 2개의 Lambda, 비효율적인 복제-삭제 로직 반복 | $330 |
| EBS 볼륨 | ClickHouse 로그 레벨이 debug로 설정되어 과도한 로그 발생, 볼륨 과할당 | $480 |
| EC2 | c5a.8xlarge 인스턴스의 CPU/Memory 대부분 유휴 상태 | $659 |
| API Gateway | Lambda 호출로 인한 게이트웨이 트래픽 비용 | $93 |
| Data Transfer | ClickHouse(Subnet B) ↔ RDS(Subnet A) 간 서브넷 분리로 인한 전송 비용 | $20 |
총 월 비용: 약 $1,582
3. 운영 복잡도 문제
- 리소스 분산으로 인한 관리 포인트 증가
- 비용 파악 및 추적의 어려움
- 복잡한 데이터 증분 파이프라인 (View Engine → tmp 테이블 → trade 테이블)
🔧 개선 작업 상세
1. Lambda → EKS 통합
변경 전 구조
- Lambda 1: API Gateway 트리거 (캔들 데이터 제공)
- Lambda 2: PostgreSQL → ClickHouse 증분 동기화 (1분마다 실행)
개선 내용
📍 API Lambda → EKS API 서버 통합
- 기존 API 역할 Lambda 코드를 EKS 내 API 서버 Pod에 이식
- 엔드포인트 변경:
- 기존:
candle.probit.com(API Gateway) - 신규:
probit.com/api/.../candle
- 기존:
- 점진적 전환 전략 채택
- 배포된 앱의 사이드 이펙트 방지를 위해 두 엔드포인트 병행 운영
- 앱 배포율 증가 및 강제 업데이트 후 Gateway/Lambda 완전 폐지 예정
📍 증분 Lambda → EKS 배치 서버 통합
- 거래 데이터 삽입 Pod에 증분 동기화 로직 통합
- 네트워크 최적화: EKS 서브넷 = EC2(ClickHouse) 서브넷 통일 → Data Transfer 비용 완전 제거
📍 증분 로직 전면 개선
기존 비효율적 프로세스:
1. PostgreSQL View Engine 테이블 조회 (1,000개)
2. tmp 테이블로 복제
3. tmp 테이블 → trade 테이블 복사
4. tmp 테이블 비우기
5. 1,000개 미만이면 종료, 이상이면 반복 (최대 55초)
개선된 프로세스:
1. PostgreSQL 데이터를 삽입 할 때, ClickHouse 테이블도 같이 삽입
핵심 개선 사항
- View Engine 테이블 & tmp 테이블 완전 삭제
- 복잡한 복제-삭제 과정 제거
- 단일 Bulk Insert로 단순화
- 데이터 누락 문제 근본적 해결
결과
비용: 월 $330 → $70 (79% 절감)
효율: 동기화 속도 개선, 데이터 누락 문제 해결
운영: 관리 포인트 감소, Lambda 제거
2. EBS 볼륨 최적화
문제점
- ClickHouse 로그 레벨이
debug수준으로 설정 - 불필요한 상세 로그가 디스크 공간 대량 소비
- EBS 볼륨이 실제 필요량 대비 과할당
개선 내용
- 로그 레벨 조정:
debug→info- 운영에 필요한 수준의 로그만 유지
- 디버그용 상세 로그 비활성화
- 볼륨 사용률 분석
- 실제 데이터 사용량 측정
- 로그 감소 후 필요 용량 재계산
- 볼륨 다운사이징 실행
- 적정 크기로 축소
결과
비용: 월 $480 → $96 (80% 절감)
효과: I/O 성능 유지, 스토리지 낭비 제거
3. EC2 인스턴스 최적화
문제점
- ClickHouse를 Docker로 운영 중인 EC2 인스턴스의 자원 활용률 저조
- CPU/Memory 대부분이 유휴 상태로 낭비
- Lambda 개선 이후 처리 부하 감소로 과잉 스펙 불필요
개선 근거
- 로그 레벨 하향으로 CPU 사용량 감소
- 증분 로직 개선으로 ClickHouse 부하 감소
- 실제 워크로드 분석 결과 절반 스펙으로 충분
다운사이징 실행
변경 전: c5a.8xlarge (32 vCPU, 64GB RAM)
변경 후: c5a.4xlarge (16 vCPU, 32GB RAM)
검증
- 다운사이징 후 ClickHouse 쿼리 성능 모니터링
- 피크 타임 CPU/Memory 사용률 확인
- 안정적 동작 유지 확인
결과
비용: 연 $7,910.28 → $3,959.52 (50% 절감, 1년 약정 기준)
효율: 자원 활용률 향상, 안정성 유지
4. API Gateway 최적화
문제점
- Lambda 호출 구조로 인한 API Gateway 비용 발생
candle.probit.com과probit.com/api/.../candle이중 운영
개선 내용
- 신규 요청은 기존 API 서버 엔드포인트로 전환
- Lambda 호출 빈도 자연 감소
- 앱 배포율 고려한 점진적 폐지 계획
결과
비용: 월 $93 → $33 (65% 절감)
효과: 트래픽 단일화, 유지보수 단순화
5. 네트워크 아키텍처 개선
Data Transfer 비용 제거
문제점
ClickHouse (EC2, Subnet B) ↔ RDS (PostgreSQL, Subnet A)
→ 서로 다른 서브넷으로 인한 Data Transfer 비용 발생
→ View Engine 쿼리로 인한 추가 전송 비용
개선 결과
1. View Engine 쿼리 제거 → Transfer 비용 제거
2. EKS = ClickHouse (EC2) 서브넷 통일
→ INSERT/SELECT 시 Data Transfer 비용 $0
네트워크 토폴로지 단순화
- 레이턴시 감소
- 비용 $0으로 투명성 향상
📊 최종 성과 요약
비용 절감 효과
| 항목 | 변경 전 | 변경 후 | 절감액 | 절감율 |
|---|---|---|---|---|
| Lambda | $330/월 | $70/월 | $260/월 | 79% ↓ |
| EBS 볼륨 | $480/월 | $96/월 | $384/월 | 80% ↓ |
| EC2 | $659/월 | $330/월 | $329/월 | 50% ↓ |
| API Gateway | $93/월 | $33/월 | $60/월 | 65% ↓ |
| Data Transfer | $20/월 | $0/월 | $20/월 | 100% ↓ |
| 월간 총계 | $1,582 | $529 | $1053 | 67% ↓ |
| 연간 총계 | $18,984 | $6,348 | $12,636 | 67% ↓ |
성능 및 안정성 개선
| 영역 | 개선 내용 | 효과 |
|---|---|---|
| 데이터 무결성 | 증분 로직 개선, Bulk Insert 방식 도입 | 데이터 누락 문제 해결 |
| 동기화 속도 | 복제-삭제 과정 제거, 직접 INSERT | 처리 시간 단축 |
| 시스템 복잡도 | Lambda 제거, View/tmp 테이블 삭제 | 관리 포인트 감소 |
| 레이턴시 | 서브넷 통합, 네트워크 홉 감소 | 응답 속도 향상 |
💡 회고 및 교훈
1. 서버리스의 양면성
- 지속적인 워크로드에는 EKS/컨테이너 기반 아키텍처가 더 효율적
- 간헐적/이벤트 드리븐 워크로드 → Lambda 적합
- 지속적/주기적 워크로드 → EKS/컨테이너 적합
2. 리소스 Right-Sizing의 중요성
- 초기 과할당된 리소스는 지속적인 비용 낭비 초래
- 실제 사용률 기반의 주기적 검토 필요
4. 네트워크 아키텍처의 숨은 비용
- Data Transfer 비용은 눈에 잘 띄지 않지만 누적되면 상당액
- 서브넷 설계 단계부터 비용 고려 필요
🎯 결론
AWS 자원은 비싸니 신중하게 사용하자