컨테이너 오케스트레이터의 스케줄러가 컨테이너의 높은 시작 지연 시간과 오버헤드를 개선하기 위해 작업의 종속성을 고려하여 작업을 배치하는 종속성 스케줄링을 제안한 연구
Abstract (요약) 🕵🏻♂️
Containers are becoming the canonical way of deploying compute tasks at the edge. Unfortunately, container startup latency and overhead remain high, limiting responsiveness and resource efficiency of edge deployments. This latency comes mostly from fetching container dependencies including system libraries, tools, configuration files, and data files. To address this, we propose that schedulers in container orchestrators take into account a task’s dependencies. Hence, in dependency scheduling, the scheduler tries to place a task at a node that has the maximum number of the task’s dependencies stored locally. We implement dependency scheduling within Kubernetes and evaluate it through extensive experiments and measurement-driven simulations. We show that, for typical scenarios, dependency scheduling improves task startup latency by 1.4-2.3x relative to current dependency-agnostic schedulers. Our implementation of dependency scheduling has been adopted into the mainline Kubernetes codebase.
이 논문을 읽어서 무엇을 배울 수 있는지 알려주세요! 🤔
💡 요약
abstract: 컨테이너 오케스트레이터의 스케줄러가 컨테이너의 높은 시작 지연 시간과 오버헤드를 개선하기 위해 작업의 종속성을 고려하여 작업을 배치하는 종속성 스케줄링을 제안한 연구
introduction: (엣지에서 컨테이너 사용이 보편화 되었지만) 컨테이너의 높은 시작 지연 시간과 오버헤드는 주로 시스템 라이브러리 및 구성 파일과 같은 종속성 가져오기로 인해 발생하며, 응답성과 리소스 효율성을 저해한다는 문제가 있다.
related works:
스토리지 최적화: 독점적인 NFS 구현을 사용하여 컨테이너 이미지 콘텐츠를 느리게 가져오고 시작 지연을 개선 ex) Slacker
스토리지 백엔드의 복잡성을 증가시키고, 인프라 변경이 필요
유니커널: 불필요한 종속성을 제거하여 시작 시간을 단축
컨테이너 재사용: 엣지 컴퓨팅 환경에서 자주 사용되는 컨테이너를 캐싱 == FaaS
엣지 환경에서는 메모리와 같은 제한된 리소스를 과도하게 사용하므로 핫캐싱이 잘 이루어지지 않을 수 있다.
method: 필요한 종속성의 일부 또는 전부를 이미 가지고 있는 노드에 작업을 배치하여 외부 소스에서 종속성을 가져올 필요가 없도록 하여 지연 시간을 최적화한다.
image-match policy: 전체 컨테이너 이미지를 종속성으로 취급하고 캐시된 이미지가 가장 많이 겹치는 노드에 작업을 배치
워커 노드에서 kubelet이 이미지 상태를 검색하고 주기적으로 API 서버에 전달
새 포드 요청에 포함된 각 이미지의 이름을 각 노드에 캐시된 이미지의 이름과 비교해야하는데, 이때 이미지 이름을 정규화함으로써 스케줄러가 글로벌 클러스터 상태에 저장된 노드별 이미지 정보를 사용하여 이미지 매칭을 구현할 수 있도록 확장한다.
layer-match policy: 레이어 단위로 종속성을 추적하고 일치시켜 이미지의 내부 구성을 고려하여 서로 다른 작업의 종속성 간의 중첩을 활용
워커 노드에서 kubelet이 캐시된 레이어를 추적하고 레이어 메타데이터를 수집하여 API 서버로 전달
종속성 스케줄링은 컨테이너를 노드에 할당하기 위해 컨테이너의 레이어 정보가 필요하므로, 스케줄러가 들어오는 파드 요청의 이미지와 해당 레이어의 고유 식별자 간의 매핑을 알 수 있어야 한다.
새로운 이미지가 포함된 파드 요청이 들어올 때마다, 외부 이미지 리포지토리를 쿼리하여 레이어 매핑에 대한 이미지를 가져와서 캐시에 저장하고, 이후에는 캐시된 매핑을 사용하게 된다.
experiment: 총 이미지 및 레이어 수, 이미지 및 레이어 크기의 합계, 평균 이미지 및 레이어 풀 레이턴시, 이미지당 평균 레이어 수와 같은 다양한 메트릭을 포함하여 평가 진행
startup latency: 종속성 스케줄링이 기존의 종속성에 구애받지 않는 스케줄러에 비해 작업 시작 지연 시간을 1.4배~2.3배까지 개선
resource usage: 종속성 스케줄링을 사용하면 각 노드에서 이미지를 더 잘 패킹할 수 있어 노드당 더 많은 이미지를 저장할 수 있다.
conclusion & discussion: 본 논문은 엣지 컴퓨팅의 맥락에서 데이터 로컬리티, 특히 종속성 로컬리티의 문제를 다루는 것을 목표로 하고 있다. 하지만, 종속도가 높은 노드에 대해 로드밸런싱 병목현상은 여전히 존재할 수 있다.
Containers, Images, and Layers:
Container: 애플리케이션에서 사용하는 리소스를 격리하고 관리하는 가상화 기술의 일종으로, 가벼운 리소스 격리와 모든 종속성이 있는 애플리케이션을 컨테이너 이미지라는 표준화된 형식으로 패키징할 수 있는 기능을 제공한다는 특징이 있다.
Image: 읽기 전용이며(copy-on-write) 여러 컨테이너에서 공유할 수 있다. 이미지에는 코드, 바이너리, 시스템 도구 및 구성 파일을 포함한 모든 종속성이 포함된다.
Layer: 컨테이너에서 사용하는 계층화된 파일 시스템을 사용하면 이미지 콘텐츠를 효율적으로 관리할 수 있으며 전체 이미지 캐시에 영향을 주지 않고 이미지 이름을 변경할 수 있다. 이 계층화된 파일 단위를 레이어라고 한다.
컨테이너가 이미지에 변경 사항을 적용하려는 경우:
대상 파일 또는 디렉터리가 컨테이너의 자체 독립 레이어에 복사된다.
이미지를 사용하려면 사용자는 컨테이너 요청에 이미지 이름을 지정한다.
컨테이너 런타임은 지정된 이미지 이름을 정규화한다(예: 기본 일반 이미지 이름을 최신 버전의 특정 이름으로 바꾸는 등).
이미지 이름을 확인하여 구성 레이어를 가져오고 이미지 리포지토리에서 아직 캐시되지 않은 경우 이미지를 가져온다.
전체 이미지가 검색되면 컨테이너가 설치되고 부팅
Kubernetes를 사용한 컨테이너 오케스트레이션:
k8s 마스터 노드: API 서버와 스케줄러로 구성된다.
워커노드: "kubelet" 에이전트와 컨테이너 런타임 엔진이 있다.
포드 요청이라고 하는 작업 실행을 위한 수신 요청이 API 서버로 제출되는 경우:
포드요청 = 하나 이상의 작업으로 구성되며, 각 작업은 별도의 컨테이너에서 실행된다.
API 서버는 필수 이미지 이름을 포함한 요청 매개변수를 스케줄러에 전달
각 워커 노드는 마스터 노드와 상호 작용하는 "kubelet" 에이전트와 컨테이너의 수명 주기(생성, 제거, 일시 중지, 모니터링)를 관리하는 컨테이너 런타임 엔진(Docker)을 실행
컨테이너 런타임은 컨테이너 런타임 인터페이스를 통해 kubelet과 상호 작용
각 워커 노드에는 이미지 캐싱을 위한 자체 로컬 이미지 저장소가 있으며, 필요한 레이어가 캐시되지 않은 경우 외부 이미지 저장소에서 가져온다.
종속성 스케줄링: 이전에 사용된 이미지를 캐싱하고 필요한 종속성이 이미 있는 노드에서 작업을 스케줄링하여 작업의 시작 시간을 줄이는 데 사용되는 기술
작업 시작에 필요한 시간이 작업 완료 시간의 상당 부분을 차지할 때 특히 유용
작업 시간이 짧아지는 추세와 IoT 애플리케이션 배포로 인해 더욱 중요해지고 있다.
종속성 스케줄링의 효과는 인기 있는 레이어의 크기, 각 노드의 캐시 크기, 클러스터의 노드 수와 같은 요인에 따라 달라진다.
어떤 내용의 논문인가요? 👋
컨테이너 오케스트레이터의 스케줄러가 컨테이너의 높은 시작 지연 시간과 오버헤드를 개선하기 위해 작업의 종속성을 고려하여 작업을 배치하는 종속성 스케줄링을 제안한 연구
Abstract (요약) 🕵🏻♂️
Containers are becoming the canonical way of deploying compute tasks at the edge. Unfortunately, container startup latency and overhead remain high, limiting responsiveness and resource efficiency of edge deployments. This latency comes mostly from fetching container dependencies including system libraries, tools, configuration files, and data files. To address this, we propose that schedulers in container orchestrators take into account a task’s dependencies. Hence, in dependency scheduling, the scheduler tries to place a task at a node that has the maximum number of the task’s dependencies stored locally. We implement dependency scheduling within Kubernetes and evaluate it through extensive experiments and measurement-driven simulations. We show that, for typical scenarios, dependency scheduling improves task startup latency by 1.4-2.3x relative to current dependency-agnostic schedulers. Our implementation of dependency scheduling has been adopted into the mainline Kubernetes codebase.
이 논문을 읽어서 무엇을 배울 수 있는지 알려주세요! 🤔
같이 읽어보면 좋을 만한 글이나 이슈가 있을까요?
레퍼런스의 URL을 알려주세요! 🔗
markdown 으로 축약하지 말고, 원본 링크 그대로 그냥 적어주세요!