YARN에서 Trino 리소스 최적화하기

YARN 위에 배포된 Trino 클러스터의 리소스 구성을 다시 맞춰, 장비 증설 없이 쿼리에 쓸 수 있는 가용 메모리를 약 40% 늘렸다.

PDL(Place Data Lake House)에서 Iceberg 테이블을 조회하는 엔진으로 Hive와 Trino를 제공하고 있었고, 그중 Trino 사용량이 빠르게 늘면서 리소스 재점검이 필요해졌다. Trino는 인터랙티브 쿼리에 강점이 있어 AdHoc, BI, 탐색적 분석에 많이 쓰이기 때문에, 단순 증설보다 기존 자원을 더 효율적으로 쓰는 방향을 택했다.

운영 환경에서는 Trino를 YARN Service로 배포해 Hadoop 생태계의 이점을 활용했다. 다만 Trino는 요청이 들어올 때만 자원을 쓰는 방식이 아니라 Worker가 항상 리소스를 점유해야 하므로, 전용 queue를 따로 만들고 노드 자원 배분을 세밀하게 조정해야 했다.

리소스 최적화는 세 가지 축으로 진행됐다.

• Hadoop daemon 프로세스를 고려해 노드 전체 메모리에서 운영 안정성을 위한 여유분을 뺀 뒤, YARN application이 쓸 수 있는 메모리를 100GB로 제한
• AM Container의 점유분을 고려해 한 노드에서는 Coordinator를 배치하고, 나머지 노드에 Worker를 배치
• Worker를 최대한 크게 잡되, 노드 자원을 1개의 Worker가 최대한 활용하도록 설계

문제는 Worker를 모두 가득 채우도록 설정했을 때 마지막 Worker가 뜨지 않는 현상이었다. 원인은 YARN의 RESERVED Resource 메커니즘으로, 자원을 할당받지 못한 application이 예약 상태로 남으면서 마지막 Worker가 필요한 리소스를 얻지 못하는 구조였다. 이를 피하려면 Worker 1대분의 리소스를 추가로 고려해 전체 클러스터 리소스를 다시 계산해야 했다.

그 결과 최종적으로 Coordinator 56GB Memory / 29 vCores, Worker 98GB Memory / 47 vCores로 재배치했고, 모든 Worker가 정상 기동되는 것을 확인했다. 재발 방지를 위해 설정된 Worker 수가 올라오지 않으면 알림을 받는 Active Nodes Alert도 추가했다.

리소스 배분을 끝낸 뒤에는 Trino 설정값도 튜닝했다. 핵심은 각 설정이 Coordinator와 Worker 중 어디에 적용되는지 테스트로 확인한 뒤 배치하는 것이었다.

• JVM Max Heap: 공식 권장치(노드 메모리의 70~85%)보다 높게, 할당 메모리의 **90%**까지 설정해 운영
• query.max-memory-per-node: Worker에 적용, JVM Max Heap과 memory.heap-headroom-per-node의 합을 넘지 않도록 조정
• query.max-memory: Coordinator에 적용, 한 사용자가 클러스터 자원의 절반 이상을 쓰지 못하도록 제한
• spill-enabled: Dev Queue에서만 활성화해 메모리 부족 시 디스크 spill로 쿼리 실패를 완화
• spiller-spill-path: Worker에 고정 경로로 지정해 spill 파일 관리 단순화

결과적으로 제한된 YARN 자원 안에서도 Trino의 쿼리 처리에 직접 쓰이는 메모리를 더 크게 확보했고, 사용자별 자원 편중과 메모리 부족 실패도 함께 줄였다. 다만 AM Container와 RESERVED Resource 때문에 전체 자원을 100% 활용할 수는 없었고, 이후에는 Kubernetes 기반 Trino 운영 가능성도 검토할 계획이다.