Meta는 스팀 덱에 적용된 리눅스 스케줄러를 자사 서버에 적용했습니다

도쿄 리눅스 플럼버스 컨퍼런스(Linux Plumbers Conference 2025)에서 재밌는 이야기가 나왔다고 합니다. Facebook의 운영사인 Meta에서 스팀 덱(Steam Deck)에 설계된 리눅스 스케줄러를 Meta 자사 서버에 이용하고 있다고 하는데요. 재밌는 점은 이 스케줄러가 대형 서버에 매우 효율적으로 동작하는 걸 알았다고 전했죠.

스팀 덱은 게이머들이 언제 어디서나 고품질 게임을 즐길 수 있도록 설계된 장치입니다. 특히 반응 속도와 지연 시간 최소화에 초점을 맞춘 SCX-LAVD 스케줄러는 게임 경험을 원활하게 만들기 위한 핵심 기술이었습니다.

대규모 서버 인프라는 안정성과 확장성만이 중요한 것이 아닙니다. 사용자 경험의 핵심은 바로 반응 속도입니다. 페이스북이나 인스타그램에서 사진을 업로드하거나 댓글을 남길 때, 사용자들은 즉각적인 피드백을 기대합니다. 메타는 이 스케줄러를 테스트한 결과, 기존 시스템에 비해 상당한 성능 개선을 확인했습니다. 특히 고부하 상황에서도 안정적인 응답 시간을 유지할 수 있다는 점이 결정적인 요인이 되었습니다.

SCX-LAVD 스케줄러란 무엇인가

SCX-LAVD는 ‘Latency-Aware Virtual Deadline’의 약자로, 지연 시간에 민감한 작업을 우선적으로 처리하는 스케줄링 알고리즘입니다. 이 스케줄러는 각 태스크의 행동 패턴, 슬립 상태, 웨이크업 빈도, 블로킹 빈도를 지속적으로 관찰하여 어떤 작업이 레이턴시에 민감한지를 추정합니다. 레이턴시에 민감하다고 판단된 작업에는 더 이른 ‘가상 데드라인’을 부여하여, 시스템이 혼잡한 상황에서도 해당 작업이 빠르게 실행될 가능성을 높입니다. 이러한 방식은 기존의 CFS(Completely Fair Scheduler)가 공정성을 우선시하는 것과는 달리, 실시간 반응성이 중요한 환경에서 특히 효과적입니다.

SCX-LAVD는 sched_ext라는 비교적 새로운 Linux 커널 프레임워크 위에 구축되어 있습니다. sched_ext는 대규모 커널 수정 없이도 대체 스케줄러를 커널에 플러그인 방식으로 추가할 수 있도록 하는 기능으로, 기업들이 Linux를 포크하거나 대규모 패치 세트를 유지 관리할 필요 없이 다양한 스케줄링 전략을 안전하고 점진적으로 시도할 수 있게 해줍니다. 이 프레임워크는 BPF(Berkeley Packet Filter) 프로그램을 통해 사용자 공간에서 스케줄러를 동적으로 로드할 수 있어, 런타임에 스케줄러를 교체하거나 조정하는 것이 가능합니다. 

Valve와 Igalia가 개발한 게이밍 최적화 기술

SCX-LAVD 스케줄러는 Linux 컨설팅 회사인 Igalia가 Valve의 의뢰로 개발한 기술입니다. Valve는 Steam Deck이라는 휴대용 게임 콘솔을 위해 반응성을 극대화하고 프레임 드랍을 최소화할 수 있는 스케줄러가 필요했습니다. 게임 환경에서는 스케줄링 데드라인을 놓치면 프레임이 떨어지고, 화면이 끊기며, 입력 반응 시간이 느려지는 문제가 발생합니다. 이러한 문제는 특히 플랫포머 게임이나 격투 게임처럼 정밀한 타이밍이 요구되는 장르에서 치명적입니다.

Igalia의 커널 팀 소속인 Changwoo Min은 게이밍에 특화된 맞춤형 CPU 스케줄러를 개발하는 과정에서 LAVD를 설계했습니다. 이 스케줄러는 스팀 뿐만 아니라 CachyOS Handheld Edition과 Bazzite 같은 다른 게이밍 기기와 Linux 배포판에서도 다양한 형태로 사용되고 있습니다. LAVD는 데드라인 스케줄링의 기반 위에 구축되었으며, BPF 부분과 Rust 부분으로 구성되어 있습니다. BPF 부분은 모든 스케줄링 결정을 내리고, Rust 부분은 CPU 토폴로지와 같은 고수준 정보를 BPF 코드에 제공하며 스케줄링 결정을 샘플링하여 출력하는 등의 기타 작업을 수행합니다.

코스피, ‘또 역대 최고’ 엿새째 올라 4580대 마감

752만명 받는 국민연금 수령액, 이달부터 2.1% 인상

한중 회담 이어 방일…이 대통령, 중·일 갈등 중재자로 우뚝 서나

AD

Meta가 Steam Deck 스케줄러를 도입한 이유는?

Meta는 데이터센터에서 수백 개의 CPU 코어를 가진 대규모 머신을 운영하며, 매우 다양한 워크로드와 엄격한 레이턴시 목표를 관리하고 있습니다. 이러한 환경에서 Meta는 각 서비스마다 맞춤형 스케줄러를 구축하기보다는, 수동 설정 조정 없이도 자동으로 적응할 수 있는 범용 스케줄러를 원했습니다. 기존의 CFS는 공정성을 중시하는 설계로 인해 Meta의 다양한 워크로드 환경에서 한계를 드러냈습니다. 서버 환경은 처리량 지향적이지만, 실시간 추천 시스템과 인터랙티브 서비스와 같이 레이턴시에 민감한 구성 요소들도 점점 더 많이 포함되고 있었습니다.

Meta 엔지니어들은 내부 벤치마크를 통해 EEVDF(Earliest Eligible Virtual Deadline First) 알고리즘을 기반으로 한 스케줄러가 공정성을 희생하지 않으면서도 스케줄링 지연을 최소화할 수 있다는 점을 확인했습니다. SCX-LAVD는 바로 이러한 요구사항에 완벽하게 부합했습니다. 더욱이, 이 스케줄러는 스팀 덱에서 수백만 사용자의 실제 텔레메트리 데이터를 통해 검증된 기술이었기 때문에, Meta는 이를 자사의 대규모 서버 환경에 적용하는 실험을 시작했습니다. Meta는 이를 ‘새로운 기본 스케줄러(New Default Scheduler)’로 명명하며 플릿 전반에 걸친 배포를 진행하고 있습니다.

Meta가 SCX-LAVD를 대규모 서버에 적용하는 과정은 순탄하지만은 않았습니다. 초기에는 수십 개의 코어가 단일 스케줄링 큐를 공유하는 머신에서 문제가 발생했습니다. 특정 코어에서만 실행될 수 있는 스레드인 ‘pinned tasks’가 불필요한 간섭을 일으키는 문제가 있었습니다. Meta는 이러한 문제를 해결하기 위해 캐시 로컬리티를 개선하고, 네트워크 인터럽트로 인해 과부하가 걸린 코어를 ‘느린’ CPU로 취급하여 보상하는 로직을 추가했습니다. 중요한 점은 이러한 수정 사항들이 서비스별 설정이나 수동 우선순위 태그 지정 없이도 구현되었다는 것입니다. 스케줄러는 관찰된 행동을 바탕으로 자동으로 적응했습니다.

배포 메트릭은 구체적인 성과를 보여주고 있습니다. 부하 상황에서 마이크로서비스의 p99 레이턴시가 최대 20~30% 감소했으며, 높은 전체 CPU 사용률을 유지하면서도 ‘노이지 네이버(noisy neighbor)’ 효과가 줄어들었습니다. 또한 이 스케줄러는 x86_64와 ARM64 플릿 모두에서 작동하여 Meta의 다중 아키텍처 전략에도 부합합니다. SCX-LAVD는 LLC(Last-Level Cache)별, 코어 유형별(예: Intel의 P 또는 E 코어, ARM의 big 또는 LITTLE), NUMA 도메인별로 별도의 스케줄링 도메인을 생성하기 때문에, 기본 밸런스 프로파일이나 오토파일럿 모드에서도 성능이 뛰어납니다. CPU와 메모리 구성이 증가하는 서버 환경에서도 SCX-LAVD는 전반적으로 우수한 성능을 보이고 있습니다.

인간은 10ms 이상의 지연을 쉽게 감지할 수 있으며, 이는 게임 경험을 크게 저하시킵니다. 마찬가지로 데이터센터의 실시간 추천 시스템이나 메시징 서비스 역시 밀리초 단위의 지연에 민감합니다. 두 환경 모두 단일 포그라운드 프로세스나 서비스가 빠르게 반응해야 하고, 백그라운드 작업이 이를 방해해서는 안 됩니다. LAVD 스케줄러는 바로 이러한 공통된 요구사항을 해결하기 위해 설계되었으며, 그 결과 게이밍과 데이터센터 양쪽에서 모두 효과적으로 작동할 수 있었습니다. 이는 워크로드의 특성을 정확히 이해하고 적절한 우선순위를 자동으로 부여하는 스케줄러의 지능적인 설계 덕분입니다.

이번 사례는 또한 특정 사용 사례를 위해 개발된 기술이 전혀 다른 분야에서도 효과를 발휘할 수 있다는 가능성을 보여주고 있죠.

게이밍과 데이터센터는 표면적으로는 다르지만, 레이턴시와 반응성이라는 공통된 기술적 과제를 공유하고 있었고, SCX-LAVD는 이를 해결하는 보편적인 솔루션임이 입증되었습니다. Meta는 이 스케줄러를 지속적으로 개선하고 있으며, 다양한 하드웨어와 사용 사례에 대응하는 기본 플릿 스케줄러로 자리매김시키고 있습니다. 앞으로 Ubuntu를 비롯한 다른 Linux 배포판들도 sched_ext와 EEVDF를 채택하면서, 이러한 스케줄러 진화가 더욱 가속화될 것으로 예상됩니다.