공부 기록

💡 요약
- abstract: 딥러닝 모델을 학습하는 컨테이너의 리소스 사용량을 분석하는 방법에 관한 연구
- introduction: 딥 러닝 클라우드 서비스에 컨테이너를 배치할 때, 동적으로 배치 시 최적의 리소스 요구량을 자동으로 예측하기 어렵다. 
- related works: 
- method: 모니터링을 통해 서로 다른 DL 모델을 학습하는 컨테이너의 반복되는 패턴과 리소스 사용의 유사성을 관찰하여, 반복 패턴을 스케줄러 또는 리소스 오토스케일러에서 활용한다.
- experiment: 통계 기반 사후 대응 대책과 비교했을 때, CPU 및 메모리 할당을 최대 30% 줄일 수 있었다.
- conclusion & discussion: 리소스 사용 메트릭에서 컨테이너 변화를 측정하고, 리소스 수요를 추정하여 딥 러닝 워크로드에 대한 컨테이너 자동 확장 정택을 고안하는 메커니즘을 구축했다. 

Introduction

기존 고성능 컴퓨팅 환경에서는 특정 학습 작업마다 전용 머신을 리소스 요구량에 맞는 서버를 설정(프로비저닝)했다면, 

IBM DLaaS 또는 Google Cloud AI Platform, Kubeflow 등의 클라우드의 네이티브 머신러닝 서비스는 동일한 머신에 여러 개의 컨테이너를 함께 배치할 수 있는데, 만약 각 컨테이너에 고정된 양의 리소스를 할당하면 리소스가 과도하게 할당될 수 있다. 왜냐하면 각 컨테이너마다 필요한 리소스양이 다를 수 있기 때문이다.

각 컨테이너에 리소스를 동적으로 프로비저닝하려면 과소 프로비저닝 및 서비스 품질(QoS) 저하 방지를 위한 사전 예방적 정책이 필요하다. 모든 컨테이너는 서로 다른 모델에 대한 트레이닝을 실행한다고 가정하면, 보편적으로 알맞은 정책은 찾기 어려울 것이다. 또한, 복잡하고 변화하는 리소스 요구량은 기존의 시계열 알고리즘(ARIMA, ARMA 등)만으로는 모델링하기 어렵다. 

본 논문에서는 Conditional Restricted Boltzmann Machine을 사용하여 리소스 사용량의 다변량 시계열을 인코딩하고, 비지도 클러스터링 방법을 적용하여 컨테이너의 리소스 변화량을 자동으로 발견할 것을 제안했다. 

• DL 워크로드와 같은 무작위적이고 복잡한 패턴의 burst 및 spike를 학습함으로써 패턴을 발견할 수 있다.
• 트리와 그래프를 사용하여 컨테이너에서 학습한 모든 단계 시퀀스를 기반으로 컨테이너 작동 단계를 모델링한다.

Backgrounds

Autoscaling: 실제 사용량이 정점에 도달하기 전 미래의 리소스 수요 촉증을 사전에 예측하고 이에 대비할 수 있다.

ex) AWS Autoscaling 동작 원리

Related Works

• 과거 리소스 사용량의 통계적 특징을 기반으로 시계열 ML 기법을 사용하여 애플리케이션 리소스 수요를 예측하는 데 중점을 두었다. => 워크로드의 애플리케이션에 초점을 맞추고 예측모델을 선택하여 범용적인 워크로드에 적용하기에는 어려움이 있었다.
• 리소스 사용에 대한 패턴을 발견하고 애플리케이션을 분류하기 위해 워크로드를 모델링한 연구 => 패턴을 식별하기 위해 DL 모델을 학습하는 여러 컨테이너에서 관찰되는 리소스 사용 데이터가 필요하다. 
• 워크로드 모델링의 경우 기존에는 작업의 도착이 리소스의 수요를 결정한다고 가정하며, 추세와 계절성을 포함한 시간 의존적 구조를 잘 포착하는 ARMA 및 ARIMA 모델을 사용했다. => DL 학습 중 리소스 사용량이 급증하는 패턴을 포착하기 어렵다.
• 분산 DL 학습에는 네트워킹 리소스가 중요한 부분을 차지하므로, 학습 태스크의 배치를 최적화 하기 위해 다양한 토폴로지 기반 정책을 적용했다. 기존에는 코드에 수동으로 라벨을 지정하거나, 해당 DL 아키텍처의 일부를 식별하도록 했다. => 클라우드 사용자들은 DL 모델이나 특정 구성에 대한 정보를 공유하기 꺼릴 수 있으며, 훈련 세션마다 서로 다른 유형의 데이터와 모델을 사용하므로 사용자 및 실행에 따라 다양한 정책을 적용하기 어렵다. 

주요 클라우드 서비스 제공업체의 ML 플랫폼(IBM WML, Amazon Sagemaker, Microsoft Azure ML, Google Cloud AI Platform 등)과 클라우드 네이티브 머신 러닝을 위한 오픈 소스 솔루션(Kubeflow, FfDL 등)에 대한 공개 문서를 보면, 위 플랫폼 대부분이 컨테이너화된 클라우드 네이티브 환경에서 모델 학습 워크로드를 목표로 한다는 것을 알 수 있다.

만약 모든 DL 작업의 최대 사용량만큼 컨테이너에 리소스를 할당하면, 클러스터의 할당 가능한 리소스가 빠르게 고갈될 수 있으며 실제 사용량에 비해 낭비될 수 있다. 따라서 ML 워크로드의 리소스 사용 패턴을 이해하고, 컨테이너를 동적으로 자동 확장함으로써 전반적인 리소스 효율성을 개선하는 것이 중요하다.

Method

1. 컨테이너 리소스 사용량(CPU와 메모리) 수집
2. Conditional Restricted Boltzmann Machine에서 컨테이너 리소스 사용량 메트릭을 인코딩
   • Conditional Restricted Boltzmann Machine: 신경망의 일종으로, 다차원 데이터를 특징 벡터로 인코딩함으로써, 시계열 패턴 분석을 유용하게 한다. 유사한 패턴은 유사한 인코딩 결과값을 가진다.
3. k-means 과 같은 클러스터링 방법을 사용하여 유사한 동작을 phase 별로 그룹화한다.
   • Memory load - Intensive CPU - Memory unload
   • 컨테이너가 어떤 동작을 하는지, 얼마나 많은 리소스가 필요한지, 어떤 순서로 리소스를 소비하는지 분석
4. 컨테이너의 전체 수명 주기를 일련의 phase로 표현하며, 이를 트리 또는 그래프로 모델링하여 컨테이너가 수행하는 동작의 유형과 필요한 리소스의 양을 파악한다.
   • 동적 리소스 할당 정책: 특정 기간동안 애플리케이션 사용량을 미리 파악하여 리소스 할당 => 리소스 사용량을 예측하는 데 효과적일 수 있지만 갑작스러운 변경이나 예기치 않은 수요 급증을 고려하지 못할 수 있다.
   • 적응형 리소스 할당 정책: 이전 시간대를 기준으로 관찰된 수요에 따라 리소스 할당 => 갑작스러운 변화에 더 잘 대응하고 예기치 않은 수요 급증을 더 잘 처리할 수 있지만, 이 접근 방식은 반응형 특성으로 인해 새 리소스를 프로비저닝할 때 지연이 발생
   • phase 기반 리소스 할당 정책: 현재 단계에 대해 검색하고, 통계를 사용하여 리소스 할당 => 각 단계의 통계 정보를 기반으로 리소스 프로비저닝을 동적으로 조정할 수 있으며, 컨테이너 요구사항의 약 95%를 충족함

본 논문에서는 실험을 통해 5000개의 DL 애플리케이션의 리소스 요구량이 약 6개의 형태의 클러스터로 나뉨을 관찰할 수 있었다.

Experiments

내부 연구자로부터 제공된 IBM DLaaS 서비스를 제공하는 클러스터에서 DL 모델을 학습하는 컨테이너 리소스 사용량 메트릭 5000개를 사용하고, 테스트 및 모델링 프로세스에는 500개의 컨테이너 트레이스를 사용했다. 평가 결과, 컨테이너를 실행하는 동안 phase를 감지함으로써 리소스 프로비저닝을 동적으로 조정하여, 단순한 적응형 정책보다 더 나은 리소스 활용도를 달성할 수 있는 것으로 나타났다.

• Conditional Restricted Boltzmann Machine: CRBM 모델 훈련은 아키텍쳐와 숨겨진 유닛 수가 미리 정의된 일반 신경망 훈련과 유사하다. 
• Clustering Behaviors: 리소스의 사용 패턴을 sliding time window 단위로 클러스터링 함으로써 리소스 사용 패턴에 대한 유사성을 학습할 수 있다. 단순성을 위해 k-means를 사용하며, 본 논문에서는 k=5가 최적임을 확인했다.

• Phase Information: 각 execution에 대해 phase sequence를 생성하여, phase별로 리소스 사용의 추세와 다양한 변동성을 관찰했다. => 특히, 워밍업 단계의 리소스 사용량은 변동성이 높아 충분한 메트릭 데이터가 확보될 때까지 매커니즘이 패턴을 식별하기 어렵다.
  
  1. CPU와 메모리를 안정적으로 사용하는 단계
  2. 메모리 로딩 및 언로딩 단계
  3. 워밍 업 단계
  4. CPU 스파이크와 함께, 메모리 사용량이 점진적으로 증가하는 단계
  5. 메모리를 집중적으로 사용하지만, CPU 사용량이 가변적인 단계

4.2 Phase 기반 리소스 할당

• ground.truth: 모든 컨테이너의 실제 리소스 사용량
• current.step.max 및 current.step.rules(maximum 및 stat.rulesfor current.step): 오라클이 향후 기간의 리소스 사용량을 미리 알고 있는 경우, 적용할 두가지 리소스 할당 정책 => 선험적 지식에 의존하기 때문에 비실용적
  • current.step.max: 향후 최대 사용량에 따라 프로비저닝
  • current.step.rules: 평균 제곱 표준편차를 더한 값에 따라 프로비저닝
• prev.step.max 및 prev.step.rules: 이전 주기에서 관찰된 정보(사후 지식)을 사용하여 다음 주기를 프로비저닝 하며, 현재 패턴이 다음 자동 확장 주기에서도 계속될 것으로 예상한다.
• phase.rule: 프로비저닝 주기 직전의 단계를 감지하고, 해당 단계의 리소스 사용량 정보를 얻은 후, 다음 주기에 그에 따라 리소스를 프로비저닝

4.3 동작 예측 가능성

아래 그림과 같이, 확률 그래프에서 위상 시퀀스를 표현하기 위해 각각의 고유한 위상을 노드로, 위상 간의 전환을 전환 확률을 나타내는 속성을 가진 방향이 지정된 에지로 모델링한다.

Discussion

GPU도 사용하는 딥러닝 태스크겠지..? GPU도 함께 리소스 클러스터링을 하면 좋을 것 같다.

컨테이너에서 트레이스를 뽑는 방법에 대해 조금 더 조사해봐야겠다.

- https://github.com/amrabed/strace-docker

- Why strace doesn't work in Docker

💡 요약
- abstract: 대형 딥 뉴럴 네트워크 모델을 효율적으로 모델 병렬화 하는 방법에 관한 연구
- introduction: 큰 용량의 모델은 일반적으로 모델 병렬화하여 학습을 진행하는데, 범용적으로 효율적인 알고리즘을 적용하기 쉽지 않다는 문제가 있다.
- related works: 기존에 모델 병렬처리를 통해 네트워크를 서로 다른 계산 단위로 분할 후 이를 서로 다른 장치에 배치했는데, 낮은 하드웨어 활용률과 통신 병목 현상이 문제가 되었다. 이후, Single Program Multiple Data 및 파이프라인 병렬화가 제안되었는데, 병렬화된 각 행렬 곱셈의 결과값을 결합(AllReduce)하는데 사용되는 연산이 통신 오버헤드의 원인이 되었으며 특정 네트워크 아키텍쳐에 종속적이었다.
- method: Pipeline Model Parallelism(micro-batch) & Rematerialization
- experiment: 이미지 분류(AmoebaNet)과 기계번역(Transformer) 모델로 테스트 해 본 결과, Rematerialization 에 의해 단일 가속기에서도 메모리 요구량을 줄일 수 있었으며 모델 병렬화를 통해 모델을 확장할 수 있었다.
- conclusion & discussion: GPipe는 전체 미니 배치에 대해 단일 동기식 그라데이션 업데이트를 적용하기 전에, 마이크로 배치의 실행을 파이프라인화하는 Rematerialization과 결합한 새로운 파이프라인 병렬 처리를 도입했으며, 추가적인 통신 오버헤드가 없어 가속기 수에 따라 거의 선형적으로 확장할 수 있다. 단, 모델을 분할할 때 레이어의 파라미터가 불균형하게 분포하는 경우 가속기 수에 따라 완벽하게 선형 확장되지 않는다.

Introduction

딥 러닝이 발전하면서 모델의 파라미터 사이즈가 증가함에 따라 정확도가 비례하도록 개선되는 것을 관찰할 수 있었다.

하지만, 하드웨어적인 한계로 인해 큰 모델을 학습하는 것은 상당한 제약을 따른다. 

일반적으로 학습의 양이 많을 때, 분산 학습을 하게 되는데 두 가지 처리 방식이 있다.

• Model Parallelism: 모델의 자체의 크기가 커서 메모리가 부족할 때 사용한다. 각 디바이스는 모델의 일부분을 가지며, 결과값을 다른 디바이스에 넘겨주며 학습을 진행한다.
• Data Parallelism: 데이터 셋의 크기가 커서 메모리가 부족할때 주로 사용한다. 각 디바이스는 각각 전체 모델의 사본을 가지고 있으며, 분할된 데이터로 각자 학습 시킨 후 결과를 취합한다.

본 논문에서는 모델 병렬화에서 다루고 있는데 모델 병렬화는 효율적인 알고리즘을 구현하기 어렵고, 만약에 효율적인 알고리즘을 구현하더라도 특정 아키텍쳐나 태스크에 종속된다는 단점을 가진다. 또한, 예시 그림을 살펴보면 모델 병렬화는 데이터가 device1 -> (device2, device3) -> device4 으로 전달된다. 즉, 훈련 시 이전 레이어가 끝날때까지 기다려야 한다.

Method

GPipe는 각 레이어에서 일어나는 계산을 (1)파이프라이닝하여 병렬 처리하며, (2) Rematerialization을 활용하여 메모리 효율을 높인다.

## Pipeline Model Parallelism

모델 학습 시에는 각 레이어에서 forward propagation을 통해 loss를 계산하고, backward propagation에서 loss가 최소가 되도록 gradient를 구한다. 이 레이어를 각 디바이스에 나누면 그림 (b)와 같이 배치되는데, 앞쪽에서 결과값이 업데이트 될 때까지 기다려야하는 bubble time이 존재한다.

이 bubble time을 줄이기 위해서 본 논문에서는 그림 (c)와 같이 N개의 mini batch를 각각 M개의 동일한 micro batch로 나누어 학습을 진행한다. 그림 (c)를 보면 micro batch만 계산 후 결과값을 다음 레이어로 넘기기 때문에 다른 디바이스가 계산을 보다 빨리 시작할 수 있다. 

만약 네트워크에서 batch normalization이 이루어지는 경우, 각 계산은 micro-batch에 대한 통계를 사용하지만, evaluation을 위해 mini-batch 통계를 축적한다.. 그리고 장치 간 통신은 모든 micro-batch의 파티션 경계에서만 이루어진다. 이때, 디바이스간 데이터 전송 오버헤드가 있을 수 있지만, activation tensor만 전달하면 되기 때문에 통신 오버헤드는 무시할 수 있을만큼 작음을 관찰할 수 있었다.

bubble time은 O((K-1)/(M+K-1)) 으로 M>=4K일때 거의 무시할 수 있음을 실험을 통해 관찰할 수 있었다.

• K: partition 개수
• M: device 개수
• 이전 Layer의 계산이 끝날때까지 기다리지 않고도 backward pass 중 재 계산을 더 일찍 스케줄링 할 수 있기 때문

## Rematerialization

sequential layer 입력값을 제외하고 이후 back propagation에서 재사용 될 가능성이 있는 중간 계산 값들을 메모리에 store&load 하는 대신, 값을 일단 버리고 나중에 다시 필요할 때 재계산한다. 그 결과 메모리 요구량은 O(N*L) -> O(N+(L/K)*(N/M)) 으로 줄어든다.

• L: layer 갯수
• K: partition 갯수
• N: mini batch 갯수
• M: 디바이스 갯수
• N/M: micro batch 크기
• L/K: 파티션 당 레이어 수
• 메모리 요구량 = 그래디언트(bi)를 계산하는 데 상위 레이어 그래디언트(bi+1)와 캐시된 activation(fi(x))가 모두 필요

하지만 forward computation을 2번 계산 해야하기 때문에, 약 25% 정도 시간이 더 걸린다. 이 대기 시간을 더욱 줄이기 위해서 아래 그림과 같이 pipeline을 조정할 수 있다.

Experiment

• Naive-1: GPipe가 없는 sequential 한 버전
• Pipeline-k: k개의 가속기에 분할하여 학습
• AmoebaNet-D(L,D): cloud TPUv2s (8GB memory each)
  • L: 일반 셀 레이어 갯수
  • D: 필터 크기
  • 입력 이미지 크기 (224,224), 미니배치 크기 128
• Transformer-L: cloud TPUv3s (16GB memory each)
  • L개 layer, 각 레이어의 dimension 2048, feed-forward hidden dimensions 8192, attention heads 32 
  • 어휘 크기 32k, 시퀀스 길이 1024, 배치 크기 32

Rematerialization의 결과

- AmoebaNet: Gpipe는 back propagation과 batch splitting에 의해 중간에 계산되는 activation memory 요구량을 6.26GB->3.46GB(Peak Activation Memory)로 줄여 단일 가속기에서 318M 파라미터 모델을 구현할 수 있다.

- Transformer: 단일 가속기에서 2.7배 더 큰 모델을 훈련할 수 있다.

Model Parallelism의 결과

- AmoebaNet: 모델 병렬화를 통해 8개의 가속기에서 아메바넷을 18억개의 파라미터로 확장할 수 있었다. (약 25배)

- Transformer: 128개의 파티션으로 구성된 GPipe를 사용하면 839억개의 파라미터까지 확장할 수 있다 (약298배)

* AmoebaNet와 Transformer의 확장이 차이나는 이유는?

뉴럴 넷 모델의 경우 레이어마다 메모리 요구 사항 및 계산량이 불균형한 경우가 있는데, 이러한 경우에는 불완전한 파티셔닝 알고리즘으로 인해 부하 불균형이 발생할 수 있다. 표에서 살펴볼 수 있듯이, 마이크로 배치 수(K)가 많을수록 성능이 향상하며, 아메바넷은 모델 파라미터의 불균형한 분포로 인해 최대 모델 크기가 완벽하게 선형적으로 확장되지 않았다. 이는 아메바넷의 여러 레이어에 걸쳐 모델 파라미터가 불균형하게 분포되어 있기 때문이다. 트랜스포머 모델의 경우는 각 레이어의 파라미터 수와 입력 크기가 동일하기 때문에, 최대 모델 크기는 Transformer의 가속기 수에 따라 선형적으로 확장될 수 있었다.

이 표에서 관찰할 수 있는 것은, M이 상대적으로 작은 경우 대기 시간을 더 이상 무시할 수 없게 된다는 점이다. M=1이면 사실상 파이프라인 병렬화가 존재하지 않아 사용되는 가속기 수에 관계없이 비교적 일정한 처리량을 관찰할 수 있었다. (주어진 시간에 한 대의 장치만 계산=병렬화X)

Discussion

결론적으로 GPipe의 세 가지 핵심 속성은 아래와 같다

1) 효율성: 새로운 배치 분할 파이프라이닝 알고리즘을 사용하는 GPipe는 장치 수에 따라 거의 선형적인 속도 향상을 달성한다.

2) 유연성: GPipe는 모든 순차적 신경망을 지원한다.

3) 신뢰성: GPipe는 synchronous gradient descent을 활용하며, 파티션 수에 관계없이 일관된 훈련을 보장한다.

stochastic gradient descent - https://light-tree.tistory.com/133

RMSProp - https://box-world.tistory.com/69

카카오에서 TPU 대신 CUDA를 사용하는 pytorch용 gpipe를 구현해둔게 있어서 한번 보면 좋을 것 같음 - https://github.com/kakaobrain/torchgpipe

💡 요약
- abstract: "단일" 엣지 서버에서 애플리케이션의 실행 효율을 향상시키기 위한 연구
- introduction: 엣지 서버의 경우 리소스가 제한되어 있으며 다양한 물리 환경을 가지기 때문에 가벼운 컨테이너 가상화가 적합한데, 컨테이너 간 통신 및 데몬 프로세스에 의한 컨테이너 관리로 인해 상당한 CPU 리소스가 소모되는 문제가 있다.
- related work: 엣지 서버들과와 클라우드에서의 워크로드 스케줄링을 통해 태스크 실행 효율을 향상시키는 조사 & 베어메탈 기반 머신에서의 시나리오 조사 -> 단일 엣지 서버에서 컨테이너에 대한 효율 향상에 관한 연구는 없었음
- method: 공동 태스크 스케줄링 및 컨테이너화 기법을 제시
- experiment: 광범위한 시뮬레이션을 통해 평가한 결과, 비효율적인 컨테이너 운영을 줄이고 애플리케이션의 실행 효율을 60%까지 향상
- conclusion & discussion: JTSC 체계는 비효율적인 컨테이너 운영을 줄이고 다양한 요구사항을 충족하면서 애플리케이션의 실행 효율성을 향상시키는 것을 보였지만, 더 복잡한 시나리오에서 테스트 할 여지가 있다.

Introduction

엣지 서버의 경우 리소스가 제한되어 있으며 다양한 물리 환경을 가진다. 또한 지능형 교통, 비디오 분석, 증강 현실, 스마트 홈 등 다양한 애플리케이션을 지원하므로 소프트웨어 종속성 충돌을 피하기 위해 가상화가 좋은 방법이 될 수 있다. 

컨테이너는 가상화 기술의 한 종류로, 하나의 운영 체제 커널을 공유하면서 독립적인 파일 시스템과 환경을 갖는 프로세스를 격리하여 실행하는 기술이다. 이러한 컨테이너 기술을 엣지 환경에서 사용하는 경우,

• 경량화된 실행 환경: 컨테이너는 가상화 기술 중에서 가장 경량화된 기술이기 때문에, 엣지 디바이스와 같이 자원이 제한된 환경에서도 효율적으로 실행될 수 있다.
• 격리된 실행 환경: 컨테이너는 독립적인 파일 시스템과 환경을 갖기 때문에, 서로 다른 애플리케이션을 격리된 환경에서 실행할 수 있다. 이를 통해 애플리케이션 간의 상호작용을 방지하고, 보안성을 강화할 수 있다.
• 확장성: 컨테이너는 쉽게 생성, 복제, 이동, 삭제 등의 작업을 수행할 수 있기 때문에, 엣지 환경에서 애플리케이션을 확장하거나 축소하는 것이 용이하다.

가벼운 컨테이너 가상화를 통해 소프트웨어 의존성을 피할 수 있는는데, 컨테이너 간 통신 및 데몬 프로세스에 의한 컨테이너 관리로 인해 상당한 CPU 리소스가 소모되는 문제가 있다.

예비 실험을 통해 확인해 본 결과, (a) 컨테이너 간 통신의 경우 컨테이너 내 통신과 비슷한 전송 속도일때, CPU 사용률이 낮다. (b) 더 많은 태스크가 컨테이너에서 시작될 때, 데몬 프로세스가 더 많은 리소스를 소비한다.

컨테이너의 효율성을 개선하기 위해서는 두 가지가 있는데, 이 논문에서는 기존 컨테이너 시스템을 변경할 필요가 없는 후자의 방법을 택한다.

1. 커스터마이징 된 컨테이너를 통해 컨테이너 작업에 소모되는 CPU 리소스를 줄이는 방법

2. 비효율적인 컨테이너 작업의 사용량을 줄이는 방법

비효율적인 컨테이너 작업은 애플리케이션 작업의 스케줄링과 작업-컨테이너 간의 매핑 체계에 따라 달라지므로, 비효율적인 컨테이너 작업을 줄이기 위해서는 스케줄링과 컨테이너화를 함께 고려해야 한다.

예를 들어, 이미지 인식 애플리케이션 (a)는 (b)와 같은 다양한 작업으로 이루어져 있다. 각 작업을 컨테이너로 나눌 때, 오른쪽 방식이 왼쪽 방식에 비해 컨테이너 간 통신을 74%, 데몬 프로세스에서 사용하는 CPU 리소스를 29% 줄일 수 있다. 또한, 오른쪽 방식이 왼쪽 방식보다 작업 시간이 더 짧게 걸린다.

따라서 본 논문은 컨테이너 작업을 최적화 하기 위해 애플리케이션의 구성(태스크 간의 관계)을 나타내는 애플리케이션 모델을 구축하고, 태스크와 컨테이너에 의한 각각의 CPU 자원 사용률과 태스크의 실행 시간을 보여주는 실행 모델을 구축한다. 그리고 이러한 모델을 기반으로 공동 작업 스케줄링 및 컨테이너화(JTSC) 체계를 설계하고 있다.

논문이 기여한 바는 아래와 같다:

• 단일 엣지 서버에서 컨테이너 작업에 사용되는 CPU 리소스를 정량화하고, 작업 실행에 미치는 영향을 분석한다.
• 컨테이너화 프레임워크 및 알고리즘은 컨테이너화 체계와 작업 스케줄링을 결정함으로써, 컨테이너 작업량 및 애플리케이션의 실행 시간을 낮게 유지하도록 설계했다.

Backgrounds

2.1.1. 컨테이너

컨테이너와 가상 머신은 단일 리소스를 '가상화'하여 여러 리소스로 나타낼 수 있는 프로세스이다. 

가상 머신이 전체 머신을 하드웨어 계층까지 가상화하고, 컨테이너는 운영 체제 레벨 위의 소프트웨어 계층만 가상화한다.

따라서 컨테이너는 가상 머신에 비해 호스트와 OS 커널을 공유하기때문에 더 가볍다. 격리된 환경은 namespace와 cgroup이라는 두 가지 OS 매커니즘을 통해 제공된다.

• namespace: 호스트 이름과 도메인 이름, 파일 마운트 지점, 프로세스 간 통신(IPC) 관련 정보, 프로세스 ID(PID), 네트워크 스택, 사용자 등 서로 다른 컨테이너에 대한 리소스를 서로 격리된 상태로 유지한다.
• cgroup: 서로 다른 컨테이너의 프로세스에서 사용하는 시스템 리소스를 제한하고, 프로세스의 일시 중단/재개를 제어한다.

2.1.2. 데몬

데몬은 백그라운드 프로세스로 계속 실행되고, 종종 원격 프로세스에서 오는 주기적인 서비스 요청을 처리하기 위해 깨어나는 프로그램이다. 데몬 프로세스는 컨테이너의 시작 및 중지, 이미지 관리 등과 같은 컨테이너 관리 프레임워크에서 실행된다.

Containerd는 호스트에서 컨테이너의 수명 주기를 관리하는 컨테이너 런타임으로, 컨테이너를 생성, 시작, 중지 및 파괴한다. 또한 컨테이너 레지스트리에서 컨테이너 이미지를 가져오고, 스토리지를 마운트하고, 컨테이너에 대한 네트워킹을 활성화할 수 있다. Containerd 는 아래와 같이 구성되며, 각 구성 요소는 서로 협력하여 컨테이너 작업을 수행한다.

containerd는 대화식 사용자가 직접 제어하지 않고 백그라운드 프로세스로 실행되는 데몬으로, 위와 같은 작동 방식을 가진다.

2.1.3. 네트워크

서로 다른 컨테이너의 네임스페이스가 격리되어 있기 때문에, 공유 메모리를 통한 IPC는 서로 다른 컨테이너의 프로세스 간에 데이터를 전송하는 데 직접 사용할 수 없다. 따라서 Docker는 컨테이너 간 데이터 전송을 위해 서로 다른 네트워크 세그먼트를 연결하는 가상 스위치, 브리지를 사용한다.

데몬 프로세스가 초기화되면, 브리지 인스턴스가 시작되며, Veth(가상 이더넷)는 네임스페이스 사이의 터널 역할을 한다. Veth는 일반적으로 컨테이너에 하나, 브리지에 다른 하나 등 쌍으로 생성되는데, 그 결과 브리지와 연결된 Veth 디바이스가 있는 모든 컨테이너는 동일한 서브넷 내에 있게 되어 서로 데이터를 전송할 수 있게 된다. 이러한 브리지를 통한 데이터 전송은 데이터 패킹 및 언패킹 등의 절차가 필요하기 때문에 IPC에 비해 비효율적이라는 단점이 있다.

Preliminary Experiments

EXPERIMENTS ABOUT CONTAINER OPERATIONS

최신 컨테이너 관리 프레임워크 Docker와 일반적인 컴퓨팅 플랫폼인 X86 및 ARM 상에서 실험이 이루어졌다.

3.1. 컨테이너 간 통신

Netperf의 클라이언트와 서버를 두 개의 컨테이너(브리지를 통한 통신) 또는 동일한 컨테이너(IPC와 통신)에 배치하여 두 호스트간에 네트워크 대역폭을 측정한다. 클라이언트는 다양한 CPU 사용률(10~100%)을 가지며, 180초 동안 서버로 데이터 패킷을 계속 보낸다. 위 그래프에서 볼 수 있듯이, 브릿지 네트워크 또는 IPC의 전송 속도는 할당된 CPU 리소스에 따라 선형적으로 증가하며, 이는 전송 속도가 소모된 CPU 리소스의 양과 밀접하게 연관되어 있음을 나타낸다.

그리고 그림 5에 따르면, 네트워크 가상화 방식에 관계 없이, 데이터 전송 속도가 거의 동일한 것으로 나타났다.

3.2. 데몬 프로세스에 의한 컨테이너 관리

컨테이너 작업이 수행될 때 데몬 프로세스의 CPU 리소스 사용량을 기록하며 실험을 진행한다.

그림 6에서 볼 수 있듯이, 컨테이너 20개를 시작하기 위해 데몬 프로세스가 사용하는 CPU 리소스가 컨테이너 모니터링에 사용되는 리소스보다 훨씬 많다. 그 이유는 아래와 같다.

• 컨테이너 시작: 리소스 제한 설정, 네트워크 구성, 볼륨 마운트 등 많은 작업이 포함된다.
• 모니터링: 주기적으로 컨테이너의 상태만 확인하면 된다. 

위 예비 실험을 통해 컨테이너 간 통신이 컨테이너 내 통신보다 효율성이 떨어진다는 것을 알 수 있었다. 하지만, 서로 다른 컨테이너에 할당된 태스크 간의 데이터 전송을 위해서는 컨테이너 간 통신이 불가피하기 때문에 이러한 작업을 실행하는 경우, 데이터 전송 속도가 느려서 컨테이너가 없는 경우보다 실행 시간이 더 길어진다. 따라서 컨테이너화 방식을 신중하게 결정하여 컨테이너 간 통신량과 그에 따른 애플리케이션 실행 시간에 미치는 영향을 줄일 수 있도록 해야 한다.

컨테이너를 시작할 때 데몬 프로세스는 작업 실행을 위한 리소스를 선점하는 데 상당한 CPU 리소스를 소비하며, 애플리케이션의 총 컨테이너 시작 시간은 총 컨테이너 수와 각 컨테이너 시작 횟수라는 두 가지 요소에 따라 달라진다. 컨테이너 수는 컨테이너화 체계에 따라 결정되며, 컨테이너를 시작하는 횟수는 컨테이너에 있는 작업의 일정에 따라 달라진다. 따라서 컨테이너 애플리케이션을 최적화하기 위해서는 작업 스케줄링과 컨테이너화를 함께 고려하는 것이 필수적임을 알 수 있었다.

Methods

실험에 사용된 애플리케이션은 너무 단순하여 실제 애플리케이션을 대표하기에는 부족하기 때문에, 본 논문에서는 실험 결과를 일반적인 애플리케이션으로 확장하기 위해 애플리케이션 모델과 실행 모델이라는 두 가지 시스템 모델을 구축한다.

• 애플리케이션 모델: 일반적인 엣지 컴퓨팅 애플리케이션의 구성을 설명한다.
  • 일반적으로 애플리케이션은 표준 API로 연결된 여러 모듈로 구성되며, 이 모듈이 입력 데이터를 처리한 후 출력 데이터를 생성하는 과정을 태스크라고 한다. 태스크 간에는 종속성이 있으며, 고려해야 할 태스크 종속성에는 소프트웨어 종속성, 데이터 종속성, 커플링의 세 가지 유형이 있다.
    • 소프트웨어 종속성: 소프트웨어 구성 요소에 의존
    • 데이터 종속성: 한 작업이 다른 작업의 출력에 의존
    • 커플링: 전역 변수와 같은 공유 처리 구성 요소 등에 두 태스크가 상호 의존
  • 위 의존성에 기반하여, 결합 수준이 낮은 태스크는 태스크 오류의 영향 범위를 줄이기 위해 다른 컨테이너에 분산하는것이 좋으며, 의존성이 높은 태스크는 동일한 컨테이너에 실행하도록 한다.
• 실행 모델: 애플리케이션(태스크와 컨테이너 작업 모두 포함)의 CPU 리소스 사용률과 엣지 서버에서 태스크의 실행 시간을 나타낸다.
  • 실행중인 태스크의 라이프사이클은 크게 세 단계로 나눌 수 있다. 태스크가 blocked되면, 입력 데이터를 메모리에 캐싱하고 CPU 리소스를 사용하지 않는다. 태스크가 모든 데이터를 입력받고 난 후에는, 태스크는 다음에 실행될 수 있도록 스케줄링된다. 태스크가 완료되면, 출력 데이터는 즉시 하위 태스크로 전송되며, 데이터 전송 기간동안 CPU 리소스를 사용하게 된다. 
    • blocked: 일부 입력 데이터를 사용할 수 없거나 예약되지 않은 경우
    • running 
    • transmitting: 출력 데이터를 전송

즉, 비효율적인 작업의 양(상호 의존적인 작업)을 줄이고, 애플리케이션 실행 시간을 낮게 유지하기 위해 규칙을 설정한다.

• 컨테이너 간 통신은 비효율적이므로, 데이터 전송량이 많은 작업을 동일 컨테이너에 할당한다.
• 적절한 작업 스케줄링을 통해 컨테이너의 수를 줄임으로써, 컨테이너의 시작 횟수를 줄인다.
• 컨테이너 간 통신을 위해 두 태스크 사이에 CPU idle time을 활용한다.
  • idle time: 병렬 컴퓨팅에서는 1) 모든 상위 작업과 2) 동일한 프로세서에서 예약된 이전 작업이 완료되기 전에는 작업을 시작할 수 없기 때문에, 이 원칙에 따라 프로세서의 idle time이 존재한다. 이 idle time 동안 컨테이너 간 통신이 제대로 수행될 수 있다면 동일한 프로세서에서 후속 작업이 지연되지 않을 수 있다.
• 실행 기간에 큰 영향을 미치는 작업 중에는 컨테이너 간 통신을 피한다.

그리고 위 규칙을 따르는 공동 스케줄링 및 컨테이너화 체계를 제안한다. 

1. 먼저 할당된 프로세서에서 작업을 스케줄링하여 '초기 스케줄'을 얻는다.
   • 이 작업에서는 컨테이너 작업이 고려되지 않는다.
2. 비효율적인 작업을 줄이기 위해, 초기 스케줄을 기반으로 태스크를 컨테이너에 매핑한다.
   • 이 작업에서 컨테이너화 체계(태스크-컨테이너 간의 매핑)가 결정된다.
3. 컨테이너 간 통신으로 인해 작업의 실행 시간이 변경될 수 있으므로 초기 스케줄을 적용할 수 없다. 따라서 컨테이너화 체계에서 얻은 새로운 작업 실행 기간을 기반으로 작업 스케줄이 업데이트 된다.

Evaluation

본 논문에서는 실제 워크플로우를 사용하여 작업과 작업 간의 종속성으로 구성된 JTSC를 평가했다. 각 태스크는 데이터 처리를 위한 일정량의 CPU 리소스 계산량 대 컨테이너 간 통신 비율(0.1, 0.5, 1, 5, 10)을 가진다. 작업 간의 종속성은 행렬로 표현되었으며, 일부 요소는 종속성 충돌을 나타내기 위해 무한대로 설정되었다.

JTSC의 성능은 컨테이너 간 전송량, 컨테이너 시작 횟수, 특정 애플리케이션의 실행 기간, JTSC의 실행 시간 등 특정 메트릭을 기반으로 평가된다.

• CPF: critical path first algorithm
• STO: start timestamp order
• ICRO: Idle-time-to-communication ratio order algorithm
• Rand: randomly search for a feasible containerization scheme
• SFD: smallest ICP
• SFC: smallest CST
• SFE: smallest NED

본 논문에 따르면 컨테이너화 알고리즘마다 컨테이너 간 통신과 컨테이너 시작 횟수를 줄이는 측면에서 장단점이 있는 것으로 나타났다. 

• 통신 집약적인 작업에는 CPF와 ICRO가 더 나은 성능을 발휘한다.
• 컨테이너를 자주 시작하고 중지해야 하는 작업에는 STO가 더 나은 성능을 발휘한다.

서로 다른 성능을 강조하는 세 가지 컨테이너화 알고리즘이 포함된 JTSC 체계를 설계하여 애플리케이션의 작업 스케줄과 컨테이너화 체계를 결정했다. 그 결과 시뮬레이션을 통해 엣지 서버의 CPU 자원, 의존도 요구사항, 다양한 스케일의 애플리케이션, 다양한 초기 스케줄 등 다양한 조건에서 비효율적인 컨테이너 운영을 줄이고 애플리케이션의 실행 효율을 지속적으로 향상시킨다는 목표를 달성했다.

단, 본 논문에서 고려한 시나리오는 단일 엣지 서버에서 FaaS 애플리케이션만을 고려한 것이므로, 보다 복잡한 환경의 시나리오를 추가하는 것이 좋을 것으로 보인다. 예를 들어,

1) 이기종 연산 능력을 갖추고 무선 네트워크를 통해 연결된 여러 엣지 서버가 있는 엣지 컴퓨팅 시스템

2) 여러 애플리케이션을 동시에 고려

3) 작업의 워크플로우로 설명할 수 없는 애플리케이션 등

Discussion

애플리케이션의 워크플로우를 생성하는 것을 내가 직접 해서 연구에 적용해보기는 어려울 것 같다.

실험 방법 등이 좀 더 자세히 나왔으면 좋았을 것 같은데 조금 아쉽다.