Kubernetes 또는 Docker SWARM과 같은 컨테이너 오케스트레이션 프레임워크에서 컨테이너를 예약하는 프로세스는 단순히 런타임 리소스를 워크로드에 할당하는 것으로 설명할 수 있습니다. 무제한(또는 최소한 충분한) 리소스가 있고 모든 워크로드가 동일한 세계에서는 현재 컨테이너 스케줄링 시스템이 적절한 것으로 간주됩니다. 그러나 엔터프라이즈 컴퓨팅의 실제 세계에서는 모든 워크로드가 동일하지 않으며 대부분의 조직에 리소스 제약이 있음을 알고 있습니다. 또한 대규모 조직에는 고유한 요구 사항이 있고 특정 방식으로 워크로드를 실행하기를 원하므로 고급 스케줄링에 대한 비즈니스 사례를 만듭니다.
Kubernetes 또는 Docker SWARM과 같은 컨테이너 오케스트레이션 프레임워크에서 컨테이너를 예약하는 프로세스는 단순히 런타임 리소스를 워크로드에 할당하는 것으로 설명할 수 있습니다. 무제한(또는 최소한 충분한) 리소스가 있고 모든 워크로드가 동일한 세계에서는 현재 컨테이너 스케줄링 시스템이 적절한 것으로 간주됩니다. 그러나 엔터프라이즈 컴퓨팅의 실제 세계에서는 모든 워크로드가 동일하지 않으며 대부분의 조직에 리소스 제약이 있음을 알고 있습니다. 또한 대규모 조직에는 고유한 요구 사항이 있고 특정 방식으로 워크로드를 실행하기를 원하므로 고급 스케줄링에 대한 비즈니스 사례를 만듭니다.
컨테이너를 실험하거나 몇 가지 소규모 파일럿 프로젝트를 실행할 때 컨테이너 스케줄링은 실제로 매우 간단할 수 있습니다. 그러나 사소한 사용 사례를 넘어서면 컨테이너 예약이 훨씬 더 복잡해지고 매우 중요한 과제가 됩니다.
다음 섹션에서는 내재된 복잡성에 대해 자세히 설명하고 강력하고 자동화된 컨테이너 스케줄링의 필요성을 설명합니다.
컨테이너 환경은 정적이 아닌 동적입니다.
서비스 기반 아키텍처는 정적이며 전혀 변경되지 않는 장기 실행 서비스를 포함하는 것처럼 보일 수 있지만 이는 사실과 다릅니다. 복제 컨트롤러 및 동적 부하 분산을 포함하는 구성 요소의 동적 특성으로 인해 서비스 구성 요소 실행의 수와 특성은 하루 종일 여러 번 변경될 수 있습니다. 아래 나열된 것과 같은 요구 사항 및 경계 조건은 언제든지 변경될 수 있습니다. 일반적으로 다음과 같은 이유로 워크로드 배치를 변경해야 합니다.
- 시스템 장애로 인해 서비스 또는 해당 구성 요소의 일부를 다시 예약해야 할 필요성
- 리소스 재할당, 추가 또는 제거(예: 클라우드 환경)
- 워크로드의 수요와 우선 순위는 특히 다른 워크로드와 관련하여 변경될 수 있습니다(예: 수요의 시간 변화).
특정 서비스 또는 일부 구성 요소에 대한 소프트웨어 업데이트로 인해 환경도 동적으로 변경될 수 있습니다. 또한 서비스가 아닌 보다 일시적인 작업 부하에는 우선 순위가 필요하고 리소스 제약이 발생할 수 있습니다. 배치 작업, 대화형 작업, 소프트웨어 빌드(예: CI/CD 프레임워크를 통해 트리거됨) 또는 CI/CD 프레임워크에서 발생하는 테스트 스위트 작업과 같은 워크로드도 경합을 일으킬 수 있으며 워크로드를 재조정해야 할 수 있습니다.
컨테이너 스케줄링은 매우 복잡하고 단순하지 않습니다.
컨테이너를 사용하면 기존의 모놀리식 애플리케이션 개발 접근 방식보다 훨씬 더 많은(그리고 훨씬 더 작은) 움직이는 부분이 있습니다. 예를 들어 마이크로서비스 애플리케이션 구성 요소는 상호 종속성과 다양한 요구 사항을 갖고 있으며 서비스 구성 요소의 복제본을 활용하여 확장성을 달성합니다. 네트워킹 및 스토리지에 대한 소프트웨어 정의 계층에 대한 종속성도 더 많습니다. 엔지니어가 체크인할 때마다 구축/배포/테스트 단계와 자동화된 오케스트레이션이 쇄도하여 서비스 준비 상태와 상태가 필요에 따라 서비스 구성 요소를 생성하거나 종료하도록 보장할 수 있습니다. DevOps가 관련되면 운영에 영향을 미치는 더 많은 이해 관계자가 있습니다. 모든 애플리케이션 엔지니어와 모든 단일 개발 단계가 운영에 직접 영향을 미칠 수 있습니다. 이러한 움직이는 퍼즐 조각을 기반으로 일관되고 신뢰할 수 있는 서비스 제공은 특히 더 높은 서비스 요율과 더 많은 서비스로 규모를 확장하고 확장할 때 문제가 됩니다.
컨테이너 스케줄링은 리소스 제약을 처리해야 함
클라우드 컴퓨팅의 세계는 리소스 가용성이 무한하다는 착각을 불러일으키지만 이러한 클라우드 리소스는 본질적으로 제약이 있는 경우가 많습니다. 일반적으로 예산이나 원하는 노드의 가용성 및 마력에 의해 제약을 받습니다. 워크로드의 확장성으로 인해 제한이 발생할 수 있으며 비용/이점 절충으로 인해 특정 임계값을 초과하는 경제적 수익이 제한될 수 있습니다. 수용할 수 있는 리소스보다 더 많은 작업을 실행해야 하는 경우 스케줄링은 "누가 실행하고 누가 실행하지 않습니까?", "누가 먼저 실행하고 다음으로 실행합니까?"라는 어려운 의사 결정 프로세스가 됩니다. 그리고 "누가 더 많이 받고 누가 덜 받습니까?"
강력하고 자동화된 스케줄링의 필요성
컨테이너가 기록적인 속도로 채택되고 있으며 대부분의 조직이 여전히 파일럿, 개발 또는 테스트 모드에 있는 동안 배포가 프로덕션에 도달하고 궁극적으로 확장됨에 따라 제약 조건으로 인해 고급 및 자동화된 스케줄링 도구가 필요하다는 것은 비밀이 아닙니다. .
- 리소스 제약, 복잡한 컨테이너 사용 사례 또는 동적으로 변화하는 환경 및 경계 조건과 같은 모든 문제 조합을 처리하기 위해 의사 결정을 자동화하는 것이 컨테이너 오케스트레이션의 가장 큰 과제입니다.
- 자동화된 스케줄링에는 강력한 정책과 효율적인 구현이 필요합니다.
- 강력하고 자동화된 스케줄링 없이는 리소스 낭비를 감수하거나 최적의 결과를 얻지 못한 채 항상 수동으로 조정해야 합니다.
따라서 고급 스케줄링 없이는 시간, 노력 및 비용을 낭비하게 됩니다. 그리고 환경이 더 동적으로 변하고(클라우드를 생각하면) 사용 사례가 고급화될수록 더 많은 것을 낭비하게 됩니다.
Navops Command 소개 – Kubermetes를 위한 강력한 기능
쿠버네티스 생성에 참여한 Google의 엔지니어들은 초기에 고급 스케줄링이 필요하다는 것을 알고 쿠버네티스 모듈식 아키텍처에서 쿠버네티스 스케줄러를 쉽게 교체하거나 여러 스케줄러를 병렬로 활용할 수 있는 기능을 고려했습니다. Univa는 고성능 컴퓨팅 및 기술 컴퓨팅 애플리케이션 분야에서 다년간의 스케줄링 경험을 보유하고 있습니다. 우리는 입증된 전문성을 바탕으로 구축하고 있으며 매끄러운 컨테이너 지향 웹 인터페이스와 API 및 명령줄 인터페이스를 통해 Kubernetes를 인식할 수 있도록 Navops Command 스케줄링 기능을 설계했습니다. 이 시스템은 비례 리소스 공유 관리, 리소스 할당량, 액세스 제어 목록 및 리소스 인터리빙과 같은 컨테이너 개념의 세계를 가져옵니다. 방문하다 www.navops.io/command.html 자세한 내용을 알아보고 조기 액세스를 신청하십시오.
Fritz Ferstl, EMEA CTO 및 비즈니스 개발, 유니바
Fritz는 23년 이상 분산 워크로드 및 리소스 관리 분야의 선도적인 전문가로 활동하고 있습니다. 그의 경험은 그리드 컴퓨팅에서 클라우드 컴퓨팅, 고성능 컴퓨팅, 가상화 및 컨테이너 최적화에 이르기까지 다양합니다. Univa Corporation의 CTO로서 그는 모든 산업 분야에서 수백 명의 대기업 고객을 지원하고 워크로드 관리 요구 사항을 대신하여 Univa의 제품 및 기술 방향을 정의하고 있습니다. 이러한 고객 내에서 세계 최대 규모의 컴퓨팅 환경 기업을 찾을 수 있습니다.
