QoS 관리 기능은 온라인 및 오프라인 애플리케이션을 균일하게 예약하여 리소스 활용도를 크게 향상시킬 수 있습니다.

출처 | ByteDance 인프라 팀

오픈 소스 | github.com/kubewharf/godel-scheduler

이 기사는 최고의 국제 클라우드 컴퓨팅 컨퍼런스인 SoCC 2023에서 Bytedance 인프라 오케스트레이션 및 스케줄링 팀이 출판한 논문 " Gödel: Unified Large-Scale Resource Management and Scheduling at Bytedance "를 해석합니다.

논문 링크: dl.acm.org/doi/proceedings/10.1145/3620678

본 논문에서는 대규모 데이터센터에서 다양한 유형의 작업에 대한 자원 할당 문제를 효과적으로 해결하고 개선하는 것을 목표로 하는 ByteDance가 제안하는 Kubernetes 기반의 높은 처리량 작업 스케줄링 시스템을 소개합니다. 데이터 센터의 리소스 활용도, 탄력성 및 일정 처리량.

현재 스케줄링 시스템은 수만 개의 노드로 구성된 초대형 클러스터 관리를 지원하고, 마이크로서비스, 배치, 스트리밍 작업, AI 등 다양한 유형의 작업에 대한 리소스 풀링 기능을 제공합니다. 2022년부터 ByteDance의 내부 데이터 센터에 배치로 배포되었습니다. Gödel 스케줄러는 피크 기간 동안 60% 이상의 CPU 사용률 과 95% 이상의 GPU 사용률을 제공하며 최대 예약 처리량은 거의 5,000 포드/초 에 달하는 것으로 확인되었습니다 .

소개

지난 몇 년 동안 ByteDance 비즈니스 라인의 급속한 발전과 함께 마이크로서비스, 프로모션 검색(추천/광고/검색), 빅데이터, 머신러닝, 스토리지 규모 등 회사 내부 비즈니스 유형이 점점 더 다양해졌습니다. 등의 사업이 급속도로 확장되고 있으며, 이에 필요한 컴퓨팅 자원의 양도 빠르게 확대되고 있습니다. 초기에는 바이트댄스의 온라인 사업과 오프라인 사업이 독립적인 자원 풀을 갖고 있었고, 사업 간 별도의 풀 관리가 채택되었습니다. 중요한 축제 및 주요 이벤트 기간 동안 온라인 비즈니스 요청의 폭발적인 증가에 대처하기 위해 인프라 팀은 사전에 계획을 세우고 일부 오프라인 비즈니스 리소스를 온라인 비즈니스 리소스 풀에 빌려야 하는 경우가 많습니다. 이 방법은 일시적인 요구를 충족할 수 있지만 서로 다른 자원 풀 간의 자원 대여 프로세스는 길고 복잡하며 비효율적입니다. 동시에, 독립적인 자원 풀은 오프라인 기업 간의 코로케이션 비용이 높고, 자원 활용도 향상의 한계도 매우 제한적입니다. 이러한 문제를 해결하기 위해 본 논문에서는 동일한 스케줄러 세트를 사용하여 오프라인 서비스를 균일하게 예약 및 관리하고 자원 풀링을 실현함으로써 자원 활용도와 자원 탄력성을 향상시키고 비즈니스 비용을 최적화하는 것을 목표로 하는 통합 오프라인 스케줄러 Gödel을 제안합니다. 경험하고 운영 및 유지 관리 압력을 줄입니다. Gödel 스케줄러는 Kubernetes 플랫폼을 기반으로 하며 Kubernetes 기본 스케줄러를 원활하게 대체할 수 있으며 성능 및 기능 측면에서 Kubernetes 기본 스케줄러 및 커뮤니티의 다른 스케줄러보다 우수합니다.

엔진 시동

ByteDance는 수십 개의 초대형 다중 클러스터 데이터 센터를 운영하며 매일 수천만 개의 컨테이너화된 작업이 생성되고 삭제됩니다. 저녁 피크 시간 동안 단일 클러스터의 평균 작업 처리량은 >1000 Pods/초입니다. 이러한 작업의 비즈니스 우선 순위, 운영 모드 및 리소스 요구 사항은 서로 다릅니다. 고품질 작업 SLA 및 다양한 작업 리소스 요구 사항을 보장하면서 높은 리소스 활용도 와 탄력성을 유지하기 위해 이러한 작업을 효율적이고 합리적으로 예약하는 방법은 매우 어려운 작업입니다.

연구를 통해 커뮤니티에서 일반적으로 사용되는 클러스터 스케줄러 중 어느 것도 ByteDance의 요구 사항을 제대로 충족할 수 없다는 사실을 발견했습니다.

Kubernetes 네이티브 스케줄러는 마이크로서비스 스케줄링에 매우 적합하고 다양하고 유연한 스케줄링 의미를 제공하지만, 동시에 Kubernetes 네이티브 스케줄러의 스케줄링 처리량이 낮기 때문에(< 200 포드/초) 오프라인 서비스에 대한 지원은 만족스럽지 않습니다. ), 지원되는 클러스터 크기도 제한되어 있으며(일반적으로 <= 5000노드) ByteDance 내에서 대규모 온라인 비즈니스 일정 요구 사항을 충족할 수 없습니다.
CNCF 커뮤니티의 Volcano는 주로 오프라인 서비스를 목표로 하는 스케줄러로, 오프라인 서비스(예: 배치, 오프라인 교육 등)(예: 갱 스케줄링)의 예약 요구 사항을 충족할 수 있습니다. 그러나 스케줄링 처리 속도도 상대적으로 낮으며 동시에 온라인 서비스를 지원할 수 없습니다.
YARN은 널리 사용되는 또 다른 클러스터 리소스 관리 도구이며 과거 오랫동안 오프라인 비즈니스 일정 관리를 위한 첫 번째 선택이었습니다. 배치 및 오프라인 훈련과 같은 오프라인 서비스에 필요한 스케줄링 의미론을 잘 지원할 뿐만 아니라 스케줄링 처리 속도가 높고 대규모 클러스터를 지원할 수 있습니다. 그러나 가장 큰 단점은 마이크로서비스와 같은 온라인 비즈니스를 제대로 지원하지 못하고, 온라인과 오프라인 비즈니스의 일정 요구 사항을 동시에 충족할 수 없다는 점입니다.

따라서 ByteDance는 Kubernetes와 YARN 의 장점을 결합하여 리소스 풀을 개방하고 모든 유형의 비즈니스를 균일하게 관리하는 스케줄러를 개발하기를 희망합니다. 위의 논의를 바탕으로 스케줄러는 다음과 같은 특성을 가질 것으로 예상됩니다.

통합 리소스 풀

클러스터의 모든 컴퓨팅 리소스를 볼 수 있으며 온라인과 오프라인 모두에서 다양한 작업에 할당할 수 있습니다. 리소스 조각화 비율과 클러스터 운영 및 유지 관리 비용을 줄입니다.

자원 활용도 향상

클러스터 및 노드 차원에서 다양한 유형과 우선순위의 작업을 혼합하여 클러스터 리소스 활용도를 높입니다.

높은 자원 탄력성

클러스터 및 노드 차원에서 컴퓨팅 리소스는 서로 다른 우선순위의 서비스 간에 유연하고 신속하게 전송될 수 있습니다. 자원 활용도를 향상시키는 동시에 자원 우선순위 할당권과 고품질 서비스의 SLA가 항상 보장됩니다.

높은 스케줄링 처리량

Kubernetes 기본 스케줄러 및 커뮤니티의 Volcano 스케줄러와 비교할 때 온라인 및 오프라인 서비스 모두 예약 처리량을 크게 향상시켜야 합니다. 비즈니스 요구 사항을 > 1000개 포드/초로 충족합니다.

토폴로지 인식 스케줄링

kubelet이 승인할 때가 아닌 스케줄링 결정을 내릴 때 후보 노드의 리소스 마이크로토폴로지가 식별되며, 비즈니스 요구에 따라 스케줄링을 위해 적절한 노드가 선택됩니다.

괴델 소개

Gödel Scheduler는 온라인 및 오프라인 서비스를 균일하게 예약할 수 있는 Kubernetes 클러스터 환경에서 사용되는 분산 스케줄러로 오프라인 비즈니스 기능 및 성능 요구 사항을 충족하면서 우수한 확장성과 예약 품질을 제공할 수 있습니다. 아래 그림과 같이 Gödel Scheduler는 Kubernetes 네이티브 스케줄러와 유사한 구조를 가지며 Dispatcher, Scheduler 및 Binder의 세 가지 구성 요소로 구성됩니다. 차이점은 더 큰 클러스터를 지원하고 더 높은 예약 처리량을 제공하기 위해 Scheduler 구성 요소가 다중 인스턴스일 수 있고 낙관적 동시 예약을 채택할 수 있는 반면 Dispatcher와 Binder는 단일 인스턴스에서 실행된다는 것입니다.

핵심 구성요소

Dispatcher는 전체 스케줄링 프로세스의 입구이며 주로 작업 대기열, 작업 분배, 노드 분할 등을 담당합니다. 주로 정렬 정책 관리자, 파견 정책 관리자, 노드 셔플러, 스케줄러 유지 관리자 등 여러 부분으로 구성됩니다.

Sort Policy Manager : 큐잉 작업을 주로 담당하며 현재 FIFO, DRF, FairShare 등의 큐잉 전략을 구현하고 있으며, 향후 우선순위 값 기반 등 더 많은 큐잉 전략이 추가될 예정입니다.
정책 관리자 파견 : 주로 다양한 Scheduler 인스턴스에 작업을 배포하고 플러그인 구성을 통해 다양한 배포 전략을 지원하는 역할을 담당합니다. 현재 기본 전략은 LoadBalance를 기반으로 합니다.
Node Shuffler : Scheduler 인스턴스 수에 따라 클러스터 노드를 분할하는 역할을 주로 담당합니다. 각 노드는 하나의 파티션에만 있을 수 있습니다. 각 스케줄러 인스턴스는 파티션에 해당합니다. 스케줄러 인스턴스는 자체 파티션의 노드에 우선 순위를 부여합니다. 요구 사항을 충족하는 노드가 없으면 다른 파티션의 노드를 찾습니다. 노드 추가, 삭제 등 클러스터 상태가 변경되거나 스케줄러 수가 변경되는 경우 노드 셔플은 실제 상황에 따라 노드를 다시 분할합니다.
스케줄러 유지관리자 : 스케줄러 인스턴스 상태, 로드 상태, 파티션 노드 수 등을 포함하여 각 스케줄러 인스턴스의 상태를 유지 관리하는 일을 주로 담당합니다.

Scheduler는 Dispatcher로부터 작업 요청을 받고 작업에 대한 특정 일정 예약 및 선점 결정을 담당하지만 실제로 실행하지는 않습니다. Kubernetes 기본 스케줄러와 마찬가지로 Gödel의 스케줄러도 다양한 링크에서 일련의 플러그인을 통해 예약 결정을 결정합니다. 예를 들어 요구 사항을 충족하는 노드를 찾는 데 다음 두 플러그인이 사용됩니다.

플러그인 필터링: 작업 기반 리소스 요청, 요구 사항을 충족하지 않는 노드 필터링
채점 플러그인: 위에서 필터링한 노드의 점수를 매기고 가장 적합한 노드를 선택합니다.

Kubernetes 기본 스케줄러와 달리 Gödel의 스케줄러를 사용하면 여러 인스턴스를 분산 방식으로 실행할 수 있습니다 . 높은 처리량이 필요한 대규모 클러스터 및 시나리오의 경우 요구 사항을 충족하도록 여러 스케줄러 인스턴스를 구성할 수 있습니다. 이때 각 스케줄러 인스턴스는 독립적으로 병렬로 예약됩니다. 노드를 선택할 때 인스턴스가 속한 파티션에서 먼저 선택됩니다. 이는 성능이 더 좋지만 적합한 것이 없는 경우에만 로컬 최적성을 보장할 수 있습니다. 로컬 파티션의 노드는 인스턴스가 속한 파티션에서 선택됩니다. 다른 인스턴스의 파티션에서 노드가 선택되지만 이로 인해 충돌이 발생할 수 있습니다. 즉, 여러 스케줄러 인스턴스가 동시에 동일한 노드를 선택합니다. .스케줄러 인스턴스가 많을수록 충돌 가능성이 높아집니다. 따라서 인스턴스 수를 적절하게 설정해야 하는 경우가 많을수록 좋습니다.

또한 온라인 및 오프라인 작업을 모두 지원하기 위해 Gödel Scheduler는 2단계 스케줄링 의미 체계를 채택합니다 . 즉, Pod Group 또는 ReplicaSet와 같은 비즈니스 배포를 나타내는 Scheduling Unit 및 Pod 실행 단위의 2단계 스케줄링을 지원합니다. 구체적인 사용법은 나중에 소개하겠습니다.

바인더는 주로 낙관적 충돌 검사, 특정 선점 작업 수행, 스토리지 볼륨 동적으로 생성 등 바인딩 전 작업 준비, 최종 바인딩 작업 수행을 담당합니다. 일반적으로 Kubernetes Binder 워크플로와 유사하지만 Gödel에서는 Binder가 여러 Scheduler 인스턴스로 인해 발생하는 더 많은 충돌을 처리해야 합니다. 충돌이 발견되면 즉시 다시 전화하여 일정을 변경하십시오. 선점 작업의 경우 Binder는 동일한 인스턴스(예: Victim Pod)를 선점하려는 Schduler 인스턴스가 여러 개 있는지 확인합니다. 이러한 문제가 있는 경우 Binder는 첫 번째 선점만 처리하고 나머지 Schduler 인스턴스에서 발행한 선점 요청을 거부합니다. 갱/공동 스케줄링의 경우 바인더는 포드 그룹의 모든 포드에 대한 충돌(있는 경우)을 처리해야 합니다. 모든 포드 충돌이 해결되고 각 포드가 별도로 바인딩되거나 전체 포드 그룹의 예약이 거부됩니다.

CNR은 Custom Node Resource의 약자로, 노드 실시간 정보를 보완하기 위해 ByteDance가 생성한 CRD입니다. Gödel Scheduler 자체의 일부는 아니지만 Gödel의 스케줄링 의미를 향상시킬 수 있습니다. 이 CRD는 노드의 리소스 양과 상태를 정의할 뿐만 아니라 듀얼 소켓 노드의 각 소켓에서 CPU/메모리 소비 및 리소스 남은 양과 같은 리소스의 마이크로 토폴로지를 정의합니다. 이를 통해 스케줄러는 마이크로토폴로지 선호도 요구 사항이 있는 작업을 예약할 때 CNR에서 설명하는 노드 상태에 따라 적절한 노드를 선택할 수 있습니다.

토폴로지 관리자만 사용하는 네이티브 Kubernetes와 비교할 때, CNR을 사용하면 토폴로지 제한 사항을 충족하지 않는 노드에 Pod를 예약할 때 kubelet에서 발생하는 예약 오류를 피할 수 있습니다. 노드에 Pod가 성공적으로 생성되면 Katalyst 에 속한 노드 에이전트에 의해 CNR이 업데이트됩니다 .

관련 자료: " Katalyst: Bytedance Cloud 기본 비용 최적화 실습 "

2계층 스케줄링

Bytedance가 Gödel을 설계할 때 주요 목표 중 하나는 온라인 및 오프라인 서비스 모두의 일정 요구 사항을 충족하는 것이었습니다. 이 목표를 달성하기 위해 괴델은 스케줄링 단위(Scheduling Unit)와 실행 단위(Running Unit)라는 두 가지 수준의 스케줄링 의미론을 도입했습니다.

전자는 배포된 작업에 해당하며 하나 이상의 실행 단위로 구성됩니다. 예를 들어 사용자가 Kubernetes 배포를 통해 작업을 배포하면 작업은 예약 단위에 매핑되고 작업을 실행하는 각 포드는 실행 단위에 해당합니다. 기본 Kubernetes의 직접적인 포드 지향 스케줄링과 달리 Gödel의 2단계 스케줄링 프레임워크는 항상 스케줄링 단위의 전체 상태를 승인 원칙으로 사용합니다. 스케줄링 단위가 스케줄 가능한 것으로 간주되면 여기에 포함된 실행 단위(예: 포드)가 순서대로 스케줄됩니다.

스케줄링 단위가 스케줄링 가능한지 여부를 판단하는 규칙은 스케줄링 조건을 충족하는 >= Min_Member 실행 단위가 있다는 것입니다. 즉, 스케줄러가 작업에서 충분한 포드에 대한 리소스 요구 사항을 충족하는 노드를 찾을 수 있는 경우 작업은 다음으로 간주됩니다. 일정이 가능해야 합니다. 이때 각 Pod는 스케줄러에 의해 지정된 노드에 차례로 예약됩니다. 그렇지 않으면 모든 포드가 예약되지 않고 전체 작업 배포가 거부됩니다.

Scheduling Unit의 Min_Member가 매우 중요한 파라미터임을 알 수 있다. 다른 Min_Member를 설정하면 다양한 시나리오의 요구 사항을 충족할 수 있습니다. Min_Member의 값 범위는 [1, 실행 단위 수]입니다.

예를 들어 마이크로서비스 비즈니스를 지향하는 경우 Min_Member는 1로 설정됩니다. 각 Scheduling Unit에서 하나의 Running Unit/Pod의 리소스 요청이 충족될 수 있는 한 스케줄링이 수행될 수 있습니다. 이 시점에서 Gödel 스케줄러는 기본적으로 기본 Kubernetes 스케줄러와 동일하게 실행됩니다.

Gang 의미 체계가 필요한 배치 및 오프라인 교육과 같은 오프라인 서비스에 직면할 때 Min_Member의 값은 Running Units/Pods의 수와 동일합니다(일부 서비스는 실제 필요에 따라 1과 Number of Running Units 사이의 값으로 조정될 수도 있음) ) 즉, 모든 포드가 리소스 요청을 충족할 수 있을 때만 예약이 시작됩니다. Min_Member 값은 비즈니스 배포 템플릿의 비즈니스 유형 및 매개변수에 따라 자동으로 설정됩니다.

성능 최적화

ByteDance의 자체 비즈니스 요구로 인해 처리량 예약에 대한 요구 사항이 높습니다. Gödel의 설계 목표 중 하나는 높은 처리량을 제공하는 것입니다. 이를 위해 Gödel 스케줄러는 필터링 노드 중 가장 시간이 많이 걸리는 부분을 동시에 실행될 수 있는 다중 인스턴스 스케줄러에 배치합니다. 한편으로는 여러 인스턴스가 충돌을 겪기 때문에 Schduler 인스턴스 수가 항상 더 좋은 것은 아닙니다. 반면에 여러 인스턴스만으로 가져온 성능 향상은 저녁 피크인 1000-2000개 포드/개를 처리하기에 충분하지 않습니다. 단일 클러스터의 처리량 요구 사항입니다. 스케줄링 효율성을 더욱 향상시키기 위해 Gödel은 다음 측면에서 추가 최적화를 수행했습니다.

캐시 후보 노드

노드를 필터링하는 과정에서 Filter와 Prioritize는 가장 시간이 많이 걸리는 두 가지 부분입니다. 전자는 리소스 요청에 따라 사용 가능한 노드를 필터링하고, 후자는 후보 노드에 점수를 매겨 가장 적합한 노드를 찾습니다. 이 두 부분의 실행 속도를 높일 수 있다면 전체 일정 주기가 크게 압축될 것입니다.

ByteDance 개발팀은 컴퓨팅 리소스가 다양한 사업부의 다양한 애플리케이션에서 사용되지만 특정 비즈니스 사용자의 애플리케이션 포드 전체 또는 대부분이 일반적으로 동일한 리소스 요구 사항을 갖는다는 사실을 관찰했습니다.

예: 소셜 앱은 20,000개의 HTTP 서버를 생성하는 데 적용됩니다. 각 서버에는 4개의 CPU 코어와 8GB의 메모리가 필요합니다. 빅 데이터 팀은 각각 1개의 CPU 코어와 4GB의 메모리가 필요한 10,000개의 하위 작업이 포함된 데이터 분석 프로그램을 실행해야 합니다.

이렇게 대량 생성된 작업에 포함된 대부분의 Pod에는 동일한 리소스 애플리케이션, 동일한 네트워크 세그먼트, 기기 선호도 및 기타 요구 사항이 있습니다. 그런 다음 필터 플러그인에 의해 선택된 후보 노드는 첫 번째 포드의 요구 사항을 충족하고 이 작업에 대한 다른 포드의 요구 사항도 충족할 가능성이 높습니다.

따라서 Gödel 스케줄러는 첫 번째 Pod를 예약한 후 후보 노드를 캐시하고, 다음 예약 라운드에서는 캐시에서 사용 가능한 노드를 우선적으로 검색합니다. 클러스터 상태가 변경되거나(노드 추가 또는 삭제) 리소스 요구 사항이 다른 포드가 발생하지 않는 한 매 라운드마다 클러스터의 노드를 다시 검색할 필요가 없습니다. 예약 프로세스 중에 할당할 리소스가 없는 노드는 캐시에서 제거되고 클러스터 상태에 따라 정렬이 조정됩니다. 이 최적화는 동일한 비즈니스 사용자를 위해 Pod 그룹을 예약할 때 노드 선별 프로세스를 크게 최적화할 수 있으며 이상적으로는 시간 복잡성을 O(n)에서 O(1)로 줄일 수 있습니다 .

스캔된 노드의 비율 줄이기

위의 최적화를 통해 후보 노드의 구축 프로세스를 줄일 수 있지만 클러스터 상태나 리소스 적용이 변경되면 클러스터의 모든 노드를 다시 검색해야 합니다.

시간 오버헤드를 더욱 줄이기 위해 Gödel은 후보 목록의 스캐닝 비율을 조정하고 전역 최적 솔루션의 대략적인 대체 방법으로 로컬 최적 솔루션을 사용했습니다. 예약 프로세스 중에 모든 실행 단위/포드에 대해 충분한 후보 노드를 찾아야 하므로 Gödel은 기록 데이터 분석을 기반으로 최소 #개의 실행 단위 노드를 스캔합니다. 기본적으로 Gödel은 # 개의 실행 단위 + 50개의 노드를 스캔합니다. 후보를 찾으려면. 적합한 번호가 발견되지 않으면 동일한 번호가 다시 검색됩니다. 후보 노드 캐싱과 결합된 이 방법은 Pod에 적합한 노드를 찾는 데 스케줄러의 시간 오버헤드를 크게 줄여줍니다.

데이터 구조 및 알고리즘 최적화

위의 두 가지 최적화 외에도 Gödel 스케줄러는 데이터 구조와 알고리즘을 지속적으로 최적화합니다.

후보 노드 목록을 저렴한 비용으로 유지하고 노드 목록을 자주 재구성하여 발생하는 오버헤드를 방지합니다. Gödel은 기본 Kubernetes 스케줄러의 NodeList 유지 관리 메커니즘을 재구성하고 노드 목록을 분할하여 초대형 프로덕션 클러스터의 성능 문제를 해결했으며 더 낮은 오버헤드로 더 나은 노드 분할 효과를 달성했습니다.

전반적인 리소스 활용도를 높이기 위해 ByteDance는 고품질 온라인 작업과 품질이 낮은 오프라인 작업을 혼합하여 배포합니다. 장사의 조수 특성으로 인해 저녁 피크 시간대에는 온라인 업체의 복귀가 많아 품질이 낮은 오프라인 업체의 선점이 빈번하게 필요한 경우가 많습니다. 선점 프로세스에는 많은 양의 검색 계산이 포함되며, 빈번한 선점은 스케줄러의 전반적인 작업 효율성에 심각한 영향을 미칩니다. 이 문제를 해결하기 위해 Gödel 스케줄러는 선점 처리량을 빠르게 복구하고 선점 지연을 크게 줄일 수 있는 포드 및 노드 기반의 다차원 가지치기 전략을 도입합니다.

실험 결과

이 논문에서는 스케줄링 처리량, 클러스터 크기 등의 측면에서 Gödel 스케줄러의 성능을 평가합니다.

첫째, 마이크로서비스 비즈니스의 경우 ByteDance는 Gödel(단일 인스턴스)을 Kubernetes 기본 스케줄러와 비교했습니다. 클러스터 규모 측면에서 기본 Kubernetes는 기본적으로 최대 5,000개 노드의 클러스터만 지원할 수 있으며 최대 예약 처리량은 200 Pods/s 미만입니다. Byte의 고성능 키-값 저장소 오픈 소스인 KubeBrain을 사용하면 기본 Kubernetes가 더 큰 클러스터를 지원할 수 있고 예약 처리량도 크게 향상됩니다. 그러나 Kubernetes + KubeBrain 조합의 성능은 여전히 Gödel보다 훨씬 낮습니다. Gödel은 5,000개 노드 클러스터에서 2,600개 포드/초의 성능을 달성할 수 있습니다. 20,000개 노드에서도 여전히 약 2,000개 포드/초가 있으며 이는 기본 Kubernetes 스케줄러 성능의 10배 이상 입니다 .

더 높은 스케줄링 처리량을 달성하기 위해 Gödel은 여러 인스턴스를 활성화할 수 있습니다. 아래 오른쪽 그림은 10,000개의 노드로 구성된 클러스터에서 1~6개의 스케줄러 인스턴스가 순차적으로 열리는 것을 보여줍니다. 초기 단계에서 처리량이 점차 증가하며 최대 값은 약 4,600 Pods/s에 도달할 수 있습니다. 하지만 인스턴스 수가 5개를 초과하면 성능이 저하됩니다. 그 이유는 인스턴스가 많아질수록 인스턴스 간 충돌이 많아져 스케줄링 효율성에 영향을 미치기 때문입니다. 따라서 스케줄링 인스턴스가 많을수록 좋은 것은 아닙니다.

Gang 의미론적 요구 사항이 있는 오프라인 작업의 경우 이 백서는 Gödel을 오픈 소스 커뮤니티에서 일반적으로 사용되는 YARN 및 K8s-volcano와 비교합니다. Gödel의 성능은 K8s-volcano보다 훨씬 높을 뿐만 아니라 YARN의 성능보다 거의 두 배나 높다는 것을 분명히 알 수 있습니다. Gödel은 온라인 및 오프라인 작업의 동시 예약을 지원합니다. 이 문서는 시스템에 제출된 오프라인 작업의 비율을 변경하여 여러 비즈니스가 혼합된 경우의 시나리오를 시뮬레이션합니다. 오프라인 서비스의 비율에 관계없이 Gödel의 성능은 상대적으로 안정적이며 처리량이 약 2,000 Pods/s 로 유지되는 것을 볼 수 있습니다 .

Gödel이 이렇게 큰 성능 향상을 이룬 이유를 입증하기 위해 이 문서에서는 " 후보 노드 캐싱 "과 " 스캔 비율 감소 "라는 두 가지 주요 최적화 의 기여도를 분석하는 데 중점을 둡니다. 아래 그림과 같이 Gödel 정식 버전, 노드 캐시 최적화만 켠 Gödel, 스캔 비율 감소만 켠 Gödel을 사용하여 이전 실험을 반복한 결과, 이 두 가지 주요 최적화 항목이 에 기여한다는 것이 입증되었습니다. 각각 60% , 60 % 성능 향상.

벤치마크를 사용하여 Gödel의 뛰어난 성능을 평가하는 것 외에도 이 백서는 생산 환경에서 Gödel 스케줄러를 사용한 ByteDance의 실제 경험을 보여주어 Gödel이 리소스 풀링, 탄력성 및 순환에 있어 우수한 능력을 가지고 있음을 보여줍니다.

아래 왼쪽 그림은 일정 기간 동안 특정 클러스터의 온라인 작업과 오프라인 작업의 자원 할당을 설명합니다. 처음에는 온라인 작업이 리소스를 거의 소비하지 않으며 우선 순위가 낮은 오프라인 작업에 많은 양의 컴퓨팅 리소스가 할당됩니다. 특별한 이벤트(긴급상황, 핫서치 등)로 인해 온라인 작업에 리소스 수요가 급증하면 괴델은 즉시 온라인 작업에 리소스를 할당하고, 오프라인 작업에 대한 리소스 할당량은 급격히 감소합니다. 피크가 지나면 온라인 작업은 리소스 요청을 줄이기 시작하고 스케줄러는 리소스를 다시 오프라인 작업으로 이동합니다. 오프라인 풀링과 동적 리소스 전송을 통해 ByteDance는 항상 높은 리소스 활용도를 유지할 수 있습니다. 저녁 피크 시간대에는 클러스터의 평균 자원 비율이 60% 이상에 도달하며 , 낮 시간대에도 40% 내외를 유지할 수 있습니다.

요약 및 향후 전망

이 문서에서는 ByteDance 오케스트레이션 및 일정 관리 팀이 오프라인 리소스 풀을 통합하기 위해 설계하고 개발한 일정 관리 시스템인 Gödel을 소개합니다. 스케줄링 시스템은 초대형 클러스터에서 온라인 및 오프라인 작업의 동시 스케줄링을 지원하고 자원 풀링, 탄력성 및 순환을 지원하며 높은 스케줄링 처리량을 갖습니다. Gödel은 2022년 ByteDance 자체 데이터 센터에서 일괄 출시된 이후 대부분의 내야 비즈니스의 코로케이션 요구 사항을 충족하여 저녁 피크 시간 동안 평균 리소스 활용도가 60% 이상 , 예약 처리량은 약 5,000개 포드/팟 입니다. s .

앞으로 오케스트레이션 및 스케줄링 팀은 계속해서 Gödel 스케줄러의 확장 및 최적화를 촉진하고, 스케줄링 의미를 더욱 풍부하게 하며, 시스템 응답성을 개선하고, 다중 인스턴스 상황에서 충돌 가능성을 줄이면서 초기 스케줄링을 최적화할 것입니다. 또한 시스템 재라우팅 기능, 설계 및 개발 Gödel Rescheduler를 구축하고 강화할 것입니다. Gödel Scheduler와 Rescheduler의 공동 작업을 통해 전체 주기에 걸쳐 클러스터 리소스의 합리적인 할당이 달성됩니다.

Gödel 스케줄러는 현재 오픈 소스 입니다 . 커뮤니티 개발자와 기업이 커뮤니티에 참여하고 프로젝트 공동 구축에 참여하는 것을 진심으로 환영합니다. 프로젝트 주소는 github.com/kubewharf/godel-scheduler 입니다 !

QR 코드를 스캔하여 ByteDance 오픈 소스 커뮤니티에 참여하세요

SoCC 논문 해석: ByteDance가 대규모 클러스터에서 통합 리소스 스케줄링을 구현하는 방법

소개