[논문 리뷰] An Analysis and Empirical Study of Container Networks -(2)

An Analysis and Empirical Study of Container Networks -(2) 부터는 실제 실험을 통해 성능을 분석한다

 

The Performance of Container Network

환경 세팅은 다음과 같다. 소프트웨어는 UBUNTU 16.10 과 리눅스 커널 4.95를 사용하였다.

하드웨어는 Dell 서버 두 대와 Gigabit Ethernet으로 연결되었다는 특징이 있다.

벤치마크는 다음과 같다.

다음과 같은 환경 아래 실험을 수행한다.

 

Containers in a single VM

먼저 하나의 VM 안에서 컨테이너의 성능을 분석한다.

Baseline은 컨테이너를 띄우지 않은 상황이다.

 

 

•  컨테이너를 띄우지 않은 Baseline 상황과 비교를 해보았을 때, 오직 컨테이너 모드와 호스트 모드와 달리 bridge 모드만 유의미한 overhead를 기록했음을 알 수 있다. 
• 컨테이너 모드와 호스트 모드는 하나의 network namespace를 공유하기 때문이다.
• 또한 호스트 모드는 baseline과 동일하게 host OS의 network stack을 공유하기 때문에 오버헤드를 무시할 정도로 적다.
• 허나 bridge 모드는 개별적인 namespace를 갖고, docker 0을 통해 통신을 해야되기 때문에 오버헤드가 발생함을 알 수 있다.

Containers in a  multiple VM

하나의 PM에서 두 개의 VM을 띄워 실험을 진행하였다.

 

• host mode의 경우 이전 실험과 같이 host OS의 network stack을 공유하므로 오버헤드가 적음을 알 수 있다.
• NAT와 BGP의 경우 address translation과 packet routing 때문에 각각 오버헤드가 발생 했음을 알 수 있다.
• 허나 overlay network의 경우 상당한 성능 감소를 보였는데, 캡슐화와 디캡슐화 과정에서 프로토콜 스택을 여러번 거쳐야 하기 때문에 발생하고, NAT와 BGP에 비해 expensive한 과정임을 알 수 있다.
  • host OS가 캡슐화된 패킷 발견-> 원래대로 복구된 패킷이 이더넷 interface을 통해 전달 -> 전달 받고 interrupt handler 실행-> 컨테이너로 전송되고 프로토콜 다시 실행의 과정 거침

Packet Size

패킷 크기는 네트워크 성능에 중요한 요소이다.

일정한 데이터 전송 속도가 주어진다면 패킷 size가 커지면 전송되는 패킷의 수는 적어질 것이다.

전송되는 패킷의 수가 일정하다면 패킷 size가 커지면 데이터 전송 속도가 증가할 것이다. 

Sockperf는 패킷 개수가 정해져 있으므로 패킷 size가 커지면 데이터 전송 속도도 증가한다.

y축 스케일이 다름에 주의!!

 

• baseline과 host는 TCP, UDP의 경우 모두 패킷 size가 커질수록 throughput이 비례해서 크게 증가함을 알 수 있다.
• 허나 NAT과 BGP는 적은 오버헤드가 발생하여 적은 폭으로 증가함을 알 수 있다.
• 반면 overlay network는 TCP에서 비례하여 증가하지 않는다.
• 기존에 containers in a multiple VM에서 설명했던 이유와 동일하다.

 

이 둘의 처리량과, 증가 양상이 다른 이유는 프로토콜 때문이다.

Network Protocol

전반적으로 TCP의 throughput이 UDP에 비해 높음을 알 수 있다. 

아래 두 가지가 이유라고 알 수 있다.

• Sliding Window Protocol은 동적으로 data sending rate을 수정을 한다.
• Nagles 알고리즘을 통해 작은 패킷들을 묶어서 전송을 하기에 link 효율성이 좋아진다.

반면 UDP에 비해 TCP는 throughput이 scale하게 증가하지 않는 모습을 보인다.

•  위에서 언급한 방법을 실행하기 위해 CPU의 처리량이 많기에 패킷 size가 증가함에 따라 오버헤드도 증가함에 따라 생긴 문제임을 알 수 있다.

---

Impact of Virtualization

 

컨테이너는 다음과 같이 4가지 방법으로 배치가 될 수 있다.

1. containers on the same PM
2.  containers in different VMs on the same PM
3. containers on different PMs
4. containers on different VMs on different PMs

기존의 방식으로 1번과 2번에 대해 다루었고 3번,4번에 대해 다룬다.

• 가상화의 결과 3번 상황에 비해 4번 상황에서 추가적인 오버헤드가 발생하였음을 알 수 있다.

Interference

• 낮은 오버헤드로 인해서 컨테이너는 동일한 물리적 자원 대비 많은 활용률을 보인다. 네트워크에서 interference는 중요한 부분이기에 임의의 두 환경을 구축하여 interference의 영향을 측정하였다.

4-vCPU, 4GB server VM 환경에서 실험을 진행하였다.

1. five containers, each executing a busy loop, to emulate workloads with persistent demand(100%의 CPU 활용률)
2. five containers, each running a program periodically demanding 10% CPU, to emulate frequent container launch and termination. (10%의 CPU활용률)

• interference가 없는 상황에 비해 overhead가 있음을 알 수 있는데, 이는 벤치마크가 컨테이너와 CPU 할당을 나눠받아서 생기는 문제이다.
• interference가 있는 상황에서 BGP만 높은 throughput을 유지하는것은 커널과 관련이 있다.

BGP는 패킷을 in-kernel network에서 수행을 하기에 user-level에 비해 높은 우선순위를 지닌다.

반면 다른 네트워크는 user-space 데몬에서 처리를 하기에 우선순위에서 밀려 처리량이 적음을 알 수 있다.

 

CPU overhead 측정

한개의 v-CPU,4GB memory로 이루어진 VM 두개를  각기 다른 두 개의 PM에 배치를 하였다.

Client Server는 각각 같은 형식으로 네트워킹이 이루어진다.

 

CPU Utilization은 userspace,kernel space,I/O 대기 시간을 포함하며,퍼센트로 측정하였다.

Service demand는 UDP_RR을 완료하기 위한 wall-clock timed이다.

 

• overlay가 캡슐화와 디캡슐화로 CPU 활용률이 높아 성능저하가 심함을 알 수 있다.

Scalability 측정

yarn 등과 같은 빅데이터 프레임워크는 하나의 작업을 완료하기 위해 병렬화를 하며 load balancing 등을 위해서도 필요하다.

scalability 측정을 위해 논문에서는 OSU 벤치마크의 osu_alltoall 프로그램을 사용하여 latency를 측정하였다.

1024바이트의 패킷 크기를 사용하고, 8vcpu,4GB memory 두 개의 VM에 나눠서 컨테이너들을 배치하였다.

default bridge모드를 이용하여 측정을 하였고, MPI program 실행중인 컨테이너의 성능을 측정하였다.

http://hpcschool.kr/usc/wp-content/uploads/sites/10/2014/04/MPI.pdf

 

• single VM 에서 실행하였을 때 latency가 10배 정도 적은 것을 알 수 있다.
• 하나의 VM에 컨테이너를 하나 배치하고 다른 하VM에 N-1개를 배치한 경우가 동등하게 N/2개 배치한 경우보다 latency가 적음을 알 수 있다. 
  • 다른 VM과 통신하기 위해서는 overlay를 거쳐 가야되기 때문에 latency가 증가함을 알 수 있다.

Network Launch Time

 

• Container Create 명령어 사용 시간과 네트워크 ping request가 응답한 시간 사이 간격을 의미한다고 한다.
• single host에서는 큰 차이가 없음을 알 수 있다
• Multiple host에서는 컨테이너를 KV store에 등록하거나 routing table을 만드는데 오랜 시간이 걸림을 알 수 있다.