Beenslab Blog

데이터베이스와의 전쟁: 암호화폐 거래소 성능 개선기 2편

beenchangseo·2025년 10월 27일Hits

암호화폐 거래소 DB 성능 개선기 (2편) - 해결 과정 및 결과

들어가며

1편에서는 37TB 규모의 데이터베이스로 인한 성능 저하 문제를 분석하고, 2가지 해결 시나리오를 검토했습니다. 이번 편에서는 **2안(테이블 Rename 방식)**을 선택한 상세한 이유와 실제 점검 과정, 그리고 성능 개선 결과를 공유합니다.

최종 시나리오 선택: 왜 2안인가?

1편에서 검토한 시나리오 중 **2안(테이블 Rename 방식)**을 최종 선택했습니다.

선택 이유: 롤백의 속도와 안정성 및 비용

비교 항목1안 (신규 클러스터 전환)2안 (테이블 Rename)
롤백 소요 시간약 5분약 5분
롤백 방법기존 클러스터로 환경 변수 변경 + Pod 재시작테이블 rename + Pod 재시작
추가 비용신규 클러스터 비용 발생스토리지 및 데이터 복제 I/O 비용
사이드 이펙트EKS 환경 변수 변경 필요없음
스냅샷 필요필요 (20분 소요)불필요

핵심: PostgreSQL RENAME은 메타데이터 연산

ALTER TABLE booktxn RENAME TO booktxn_old;  -- 0.1초 미만
ALTER TABLE booktxn_old RENAME TO booktxn;  -- 롤백도 0.1초

PostgreSQL의 테이블 RENAME은:

  • 시스템 카탈로그의 메타데이터만 변경
  • 실제 데이터 파일은 그대로 유지
  • 수 TB 데이터여도 즉시 완료
  • 롤백 시 단순히 이름만 다시 바꾸면 됨

2안을 선택한 결정적 이유

  1. 사이드 이펙트 제로

    • 1안은 EKS 환경 변수 변경 필요 (RDS 엔드포인트 전환)
    • 네트워크 설정, 커넥션 풀, DNS 캐시 등 예상치 못한 문제 발생 가능성
    • 2안은 데이터베이스 내부에서만 작업 완료 → 안정성 최우선

  2. 점검 시간 단축

    • 1안: 신규 클러스터용 스냅샷 생성 필요 (20분)
    • 2안: _old 테이블 자체가 백업 역할 → 20분 절약

  3. 추가 비용 제로

    • 1안: 신규 클러스터 생성 시 온디맨드 비용 발생
      • 37TB 스토리지 비용
      • 데이터 복제 I/O 비용
      • 인스턴스 비용 (점검 기간 동안)
    • 2안: 기존 클러스터만 사용 → 추가 비용 없음

사전 준비 작업

Staging 환경 검증

프로덕션 적용 전 Dev / Staging 환경에서 철저히 리허설했습니다:

1. PostgreSQL 버전 업그레이드 테스트 (15.4 → 15.10)

  • 애플리케이션 호환성 검증
  • 파라미터 설정 변경 사항 확인
  • 업그레이드 소요 시간 측정

2. 데이터 클렌징 시뮬레이션

  • 프로덕션 스냅샷으로 복원한 클러스터에서 실제와 동일하게 테스트
  • 클렌징 스크립트 실행 시간 측정: 최소 2시간 30분 소요
  • 데이터 정합성 검증 스크립트 작성

3. 거래 기능 QA

  • 주문 접수/취소
  • 체결 처리
  • 정산 로직
  • 잔고 업데이트
  • 모든 시나리오 통과 확인

결과: Dev / Staging에서 모두 성공

점검 계획 수립

점검 일시: 09:30 ~ 15:30 (6시간) 거래 재개: 16:00 (필요 시 연장 가능)

세부 일정

시간작업 내용예상 소요비고
09:30서비스 차단10분Cloudflare, Nginx 설정
09:40전체 Pod 중지10분EKS Deployment replicas=0
09:50RDS 백업 (15.4 버전)20분DB 버전 업그레이드 롤백용
10:10DB 버전 업그레이드 (15.4→15.10)50분trading, trading_web 동시 진행
11:00버전 업그레이드 검증10분버전 및 파라미터 확인
11:10데이터 클렌징 작업2시간 30분테이블 rename & 데이터 마이그레이션
13:40Pod 복구30분전체 서비스 순차 기동
14:10거래 봇 테스트30분주문/체결/정산 검증
14:40서비스 차단 해제30분단계적 오픈
15:10모니터링50분Datadog, CloudWatch 지표 확인
16:00거래 재개-정식 서비스 시작

성능 개선 결과

스토리지 감소

  • 37 TB -> 13 TB(65% 감소)

처리 성능 개선

체결 정산 시간

클렌징 전에는 체결 정산 처리 시간이 길어지면 30초 이상 소요되는 경우가 빈번했으나, 클렌징 후에는 대부분 1~2초 내외로 처리되는 것을 확인했습니다.

Deadlock 및 5xx 에러 발생률

Datadog 지표상 deadlock으로 인한 5xx 에러 발생률이 현저히 감소한 것을 확인했습니다. 다만, 정확한 개선 수치를 산출하기 위해서는 더 정밀한 지표 수집과 장기간 모니터링이 필요해 보였습니다.

정성적 개선 효과:

  • 체결 정산 처리 시간 대폭 단축
  • Deadlock으로 인한 서비스 오류 감소
  • 전반적인 시스템 응답 속도 향상

운영 비용 절감

trading DB 비용 변화 (6월 기준)

구분AS-ISTO-BE (클렌징 + I/O-Optimized)절감액
스토리지37TB → $4,44613TB → $3,600$846
I/O$6,465 (59%)$0 (I/O-Optimized)$6,465
인스턴스$4,000$5,200 (+30%)-$1,200
월 합계$14,911$8,800$6,111 (41% 절감)

연간 절감액: 약 $73,332

I/O-Optimized의 효과: 인스턴스 비용은 30% 증가하지만, I/O 비용이 전체 청구서의 40%를 차지했기 때문에 전체적으로는 큰 절감 효과가 있었습니다.

결론

4. 비용 최적화 = 성능 최적화

데이터 클렌징으로:

  • 성능: 체결 처리 시간 개선
  • 안정성: Deadlock 감소
  • 비용: 25% 절감 (연간 $73,332)

두 마리 토끼를 모두 잡을 수 있었습니다.

마무리

37TB의 데이터베이스를 13TB로 줄이고, 체결 처리 시간을 약 15배 개선하며, 연간 약 $73,000의 비용을 절감한 프로젝트였습니다.

참고 자료