Making fetch happen: Building a general-purpose query and render scheduler (새 탭에서 열림)
데이터독(Datadog)은 복잡한 대시보드의 성능 최적화를 위해 쿼리와 렌더링 작업을 효율적으로 관리하는 범용 스케줄러를 개발했습니다. 기존의 복잡한 규칙 기반 시스템을 단순화하고 브라우저 네이티브 API를 활용함으로써, UI 응답성을 높이고 백엔드 부하를 안정화하는 성과를 거두었습니다. 이 글은 기존 스케줄러의 한계를 극복하고 모든 애플리케이션에 적용 가능한 유연한 스케줄링 모델로 전환한 과정을 다룹니다. ### 기존 스케줄러(v1)의 문제점 * **지나친 복잡성:** 약 20여 개의 매개변수가 얽힌 복잡한 휴리스틱(heuristics)으로 운영되어, 개발자가 시스템의 동작 방식을 예측하거나 추론하기 어려웠습니다. * **로직의 결합:** 쿼리(데이터 호출)와 렌더링(화면 표시) 스케줄링이 명확히 분리되지 않았습니다. 예를 들어, 렌더링 대기 작업이 많다는 이유로 연관 없는 쿼리 요청이 지연되는 등의 비효율이 발생했습니다. * **낮은 범용성:** 대시보드 환경에만 특화되어 설계되었기 때문에, 데이터독의 다른 제품군이나 일반적인 위젯 컴포넌트에서 재사용하기 어려운 구조적 한계가 있었습니다. ### 데이터 쿼리 스케줄링의 단순화 * **가시성 기반 우선순위:** 화면에 보이는(visible) 위젯의 쿼리는 요청 즉시 실행하고, 화면 밖(offscreen) 위젯은 별도의 대기열에 추가하여 지연 처리합니다. * **고정 시간 윈도우 알고리즘:** 복잡한 계산 대신 2,000ms라는 고정된 시간 창(window) 동안 최대 10개의 태스크만 실행하도록 제한하여 작업 분포를 평탄화했습니다. * **대기열 관리 최적화:** 백엔드에 펜딩된 요청이 너무 많으면 실행을 일시 중단하며, 화면 밖 작업들은 대기열에 들어온 순서대로 처리하여 공정성을 유지합니다. * **도입 결과:** 로직이 단순해졌음에도 불구하고 서버의 '429(Too many requests)' 에러가 크게 감소했으며, 쿼리 재시도 횟수가 줄어들어 전체적인 데이터 로딩 속도가 향상되었습니다. ### Browser Scheduling API를 활용한 렌더링 최적화 * **자원 상태 인지:** 기존 스케줄러는 브라우저의 CPU나 메모리 가용 상태를 알지 못한 채 작업을 할당했으나, 새로운 시스템은 브라우저 네이티브 기능을 활용합니다. * **우선순위 세분화:** 최신 `Browser Scheduling API`의 `postTask` 메서드를 도입하여 작업의 성격에 따라 우선순위(user-blocking, user-visible, background)를 부여합니다. * **효율적인 메인 스레드 사용:** 브라우저가 직접 작업의 우선순위를 제어하게 함으로써, 중요한 UI 업데이트는 즉시 처리하고 덜 중요한 렌더링은 브라우저가 유휴 상태일 때 실행하도록 최적화했습니다. 복잡한 웹 애플리케이션에서 성능을 확보하려면 스케줄링 로직을 최대한 단순화하고 브라우저가 제공하는 표준 API를 적극적으로 활용해야 합니다. 이는 개발자에게는 시스템에 대한 통제력을 제공하며, 사용자에게는 더 매끄러운 인터랙션 경험을 선사합니다.