백엔드
Trino로 타임아웃 개선하기
두줄요약
로그 누적으로 발생한 대시보드 타임아웃과 slow query 문제를 Trino 도입으로 개선한 사례를 다뤘습니다. OBS와 Parquet, MySQL tier down 구조를 통해 집계 성능과 저장 효율을 함께 고려했습니다.
문제 상황
- 로그 데이터가 누적되며 조회 속도 저하와 대시보드 타임아웃 발생
- 월 단위 집계 쿼리와 1억 건이 넘는 조회 대상 row로 인한 slow query
원인 분석
- 기존 MySQL 기반 로그 조회의 확장성 한계
- 쿼리 최적화만으로는 로그 증가와 보관 기간 확대 요구를 계속 감당하기 어려운 구조
- 집계 중심 조회에 비해 저장소와 실행 엔진의 성격이 맞지 않는 문제
해결 방법
- 복잡한 집계 쿼리와 여러 데이터 소스 연동에 강한 Trino 도입
- 저장 비용 절감을 위해 OBS와 Parquet 조합을 선택하고, MySQL을 hot tier로 두는 tier down 구조 설계
- micro batch와 hourly batch 대신 MySQL을 중간 저장소로 사용해 실시간 조회와 운영 복잡도를 함께 고려
주의할 점
- Parquet 파일을 직접 다루는 과정에서 페이징과 파일 생성 방식에 대한 고려 필요
- 작은 파일이 많아지면 Trino 조회 성능 저하 가능
- HQL 사용 시 external location, partitioned_by 같은 추가 설정 필요