오픈 소스 커널 스케줄러를 활용한 Meta 광고 서비스 현대화
Meta는 광고 서버의 워크로드 특성을 반영한 `sched_ext` 기반 커스텀 스케줄러를 도입해 광고 검색 경로의 p99 지연을 28% 줄이고, 전력 3.28MW를 절감했으며, 순위 매긴 광고 수를 1.1% 늘렸다. 일반 목적 스케줄러 대신 요청의 중요도와 실행 경로를 이해하는 스케줄링 정책을 적용한 결과다. 이후 사용자 공간 BPF 정책만 수정해 p99 지연을 추가로 60% 줄이고 타임아웃 오류도 18% 감소시켰다. ## 광고 서비스에서 지연 시간이 중요한 이유 - Meta의 광고 플랫폼은 초당 평균 500만 건 이상의 요청을 처리하며, 하루 기준 4,000억 건이 넘는다. - p99 지연 시간이 몇 밀리초만 늘어나도 광고의 관련성과 광고주 ROI가 악화될 수 있다. - 기존 Linux 스케줄러인 CFS와 EEVDF는 범용 목적이라 각 스레드의 업무 중요도나 광고 요청 처리 경로를 알지 못한다. - 광고 서비스에서는 어떤 스레드가 사용자 요청의 핵심 경로에 있는지 알고 있으므로, 이를 스케줄러에 직접 반영할 여지가 있었다. ## EEVDF 전환으로 발생한 문제 - Linux 6.6부터 도입된 EEVDF가 최신 커널 6.9에서 광고 서버의 지연 시간을 악화시켰다. - 그 결과 응답에서 검색·순위 지정되는 광고 수가 줄어들었다. - 일부 광고 서버는 성능 회귀를 피하기 위해 Linux 6.4와 CFS에 계속 남아야 했고, 커널 버전이 혼재하는 운영 부담과 기술 부채가 발생했다. - 이미 Meta 내 여러 서비스에서 성능 개선 효과를 보인 `sched_ext`가 이 문제의 해결책으로 선택됐다. ## BPF 기반 `sched_ext`의 구조 - `sched_ext`는 BPF 프로그램으로 스케줄링 정책을 구현할 수 있는 Linux의 확장 가능한 프레임워크다. - Linux 6.12에 공식적으로 포함됐으며, Google의 ghOSt 설계 경험을 바탕으로 업스트림 통합을 고려해 개발됐다. - 커널은 다음과 같은 이벤트가 발생할 때 BPF 스케줄러를 호출한다. - 스레드가 실행 가능 상태가 될 때 CPU 선택 - 실행 큐에 스레드를 넣을 때 - CPU가 유휴 상태가 되어 다음 스레드를 선택할 때 - CPU가 유휴 상태에 진입하거나 빠져나올 때 - 광고 워크로드가 실행되는 호스트에만 광고 최적화 정책을 적용할 수 있다. ## 광고 요청에 맞춘 CPU 분할과 지역성 개선 - CPU를 두 개의 논리적 풀로 나눈다. - 지연 시간에 민감한 광고 요청 처리 스레드용 - 상대적으로 덜 중요한 백그라운드·비핵심 작업용 - 어떤 스레드를 어느 풀에 배치할지는 광고 도메인 지식에 따라 결정한다. - 부하 기반 휴리스틱으로 각 CPU 풀의 크기를 동적으로 조절한다. - 관련 작업을 장기간 같은 CPU에 배치해 L3 캐시 지역성을 높이고 DRAM 접근 비용을 줄인다. - 정책은 사용자 공간 바이너리가 BPF 프로그램을 로드하는 형태로 배포된다. - 정책을 변경할 때 커널을 다시 빌드하거나 설치할 필요 없이 스케줄러 프로세스를 재시작하면 되므로 실험과 배포가 빠르다. ## 성능과 운영 효과 Linux 6.4의 CFS에서 Linux 6.9와 `sched_ext`로 전환한 초기 도입 결과는 다음과 같다. - 광고 검색 경로의 서비스 p99 지연 28% 감소 - 전체 서버 플릿에서 전력 3.28MW 절감 - 가중 광고 순위 지표 1.1% 증가 - 사용자 공간 정책을 두 차례 추가 개선한 뒤: - 서비스 p99 지연이 추가로 60% 감소 - 핵심 경로의 타임아웃 오류 18% 감소 커널 변경이 필요하지 않았기 때문에 후속 개선은 수개월이 아닌 며칠 단위로 배포할 수 있었다. ## 장기적인 전략 자산으로의 확장 - 업스트림 Linux 스케줄러의 변화와 별개로, Meta가 자체 워크로드에 맞는 정책을 병렬적으로 개선할 수 있다. - 커널 패치와 장기간의 검증이 필요했던 기능도 사용자 공간 BPF 업데이트로 빠르게 실험할 수 있다. - 예시로 로컬 캐시 인식 배치, ROI 기반 실행기 라우팅, NUMA 인식 CPU 선택 등을 적용할 수 있다. - `sched_ext`가 Linux에 업스트림되면서 클라우드 사업자, 대규모 서비스 운영자, 임베디드 시스템 등도 커널을 포크하지 않고 특화된 스케줄링 정책을 구현할 수 있게 됐다. ## 향후 방향 - 광고 서비스가 요청의 상대적 중요도 같은 애플리케이션 수준의 정보를 스케줄러에 전달할 수 있다. - 스케줄러는 중요 요청을 처리하는 스레드에 더 긴 실행 시간을 주거나, 실행 큐의 최상단에 유지하는 방식으로 대응할 수 있다. - 이를 통해 단순한 CPU 부하 균형을 넘어, 비즈니스 가치와 요청 우선순위를 반영한 스케줄링이 가능해진다. 워크로드별 우선순위와 실행 특성을 명확히 알고 있는 대규모 서비스라면, 범용 스케줄러만 고집하기보다 `sched_ext` 같은 확장 프레임워크로 지연 시간·전력·처리량을 함께 최적화하는 방안을 검토할 만하다.
원문 읽기(새 탭에서 열림)
