삼쩜삼이 5월 종합소득세 신고 시즌에 급증하는 트래픽을 처리하기 위해 AWS Aurora MySQL 성능 병목을 분석하고 모니터링 개선, Multi Source Replication, 파라미터 최적화를 통해 DML 처리량을 30% 이상 향상시킨 과정을 정리한다.
핵심 포인트- 5월 피크 트래픽에서 aurora_redo_log_flush와 MYSQL_BIN_LOG 두 wait event가 병목으로 확인됨
- OpenSearch + Logstash JDBC 플러그인으로 DB 쿼리 데이터를 실시간 분석 가능한 통합 모니터링 구축
- Aurora MySQL MSR(Multi Source Replication)로 최대 15개 마스터를 단일 레플리카로 집약해 프로덕션/분석 트래픽 분리
- innodb_flush_log_at_trx_commit=0 설정으로 redo log 동기 플러시를 비동기(1초 배치)로 전환해 I/O 부하 감소
- 파라미터 최적화 결과 DML 처리량 30%+ 향상, aurora_redo_log_flush wait event 제거
상세 정리- 삼쩜삼은 MSA 전환 후 CloudWatch 단독으로는 분산 서비스 DB 리소스 가시성 부족 문제가 있었음
- Logstash JDBC 플러그인은 RDB에서 SQL 쿼리 데이터를 추출해 OpenSearch로 전송, 임계값 기반 알림 가능
- MSR은 Aurora MySQL 기능으로 여러 마스터 서버 데이터를 단일 레플리카에 통합, 분석 쿼리를 레플리카로 분리
- Aurora MySQL은 커뮤니티 MySQL과 달리 로그 기록을 스토리지 레이어에 오프로드하므로 비동기 커밋 설정이 상대적으로 안전
- innodb_flush_log_at_trx_commit=1(기본)은 매 트랜잭션마다 redo log 동기 기록, =0으로 변경 시 최대 1초 데이터 손실 가능성
- binlog_format=ROW를 특정 읽기 전용 인스턴스에서 비활성화해 Base64 인코딩 오버헤드 제거
- Aurora v3에서 innodb_trx_commit_allow_data_loss=1 설정이 데이터 손실 가능성 인정 요구사항으로 추가됨
- 리스크 완화: MSA 구조의 서비스별 데이터 검증 메커니즘으로 일시적 불일치 보완
- RDS → Databricks → QuickSight 파이프라인으로 비즈니스 지표 분석 인프라도 병행 구축
왜 읽나계절성 트래픽 급증에 대응하는 Aurora MySQL 성능 튜닝 실전 사례로, wait event 분석부터 파라미터 최적화, 아키텍처 분리까지 DB 관리자와 백엔드 엔지니어에게 실용적인 가이드를 제공한다.