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

Abstract

VM보다 가벼운 단계의 가상화를 제공하는 컨테이너의 등장은 많은 변화를 가져왔다.

가상화의 단계가 줄어들었기에, 공유하는 자원이 증가하였고, 이로 인해 오버헤드는 감소하고 하나의 host에서 기존의 VM에 비해 많은 컨테이너를 띄울수 있게 되어 통합하여 관리를 할 수 있게 되었다.

 

허나 컨테이너 기반 가상화에서 핵심적인 역할을 하는 컨테이너 네트워크는 아직 연구가 부족하며, 상대적인 장점과 한계점, 그리고 클라우드 환경에서의 성능에 대한 이해도가 부족하다.

 

그렇기에, 이 논문에서는 컨테이너 네트워크에 대한 통합적인 연구를 진행한다.

 

예상 가능한 상황에 대한 질적 비교를 진행하며, 보안과 관련된 isolation 단계, 오버헤드 측정을 한다.

이후에는 양적 비교를 진행하여, throughtput(처리량),latency(지연 속도),scalability(확장성),그리고 실제 클라우드 환경에 적용하기 위한 초기 비용을 비교한다.

 

결론적으로 physical network에 비해 무시 못할 수준의 오버헤드가 발생하며, 워크로드의 특성에 맞는 컨테이너 네트워크를 정해야 된다는 것이 결론이다.

 

---

Introduction

컨테이너는 OS 기반의 가상화를 제공하기에, 오버헤드는 무시할 수 있을 정도로 작고, 심지어 네이티브 환경과의 차이가 없는 수준이다.

수초 내에 launch가 되기에, event-driven microservice에 적합하다.

https://taeng-develop.tistory.com/36

Event Driven MicroService란 무엇인가?

Event Driven Micro Service를 사용하므로, 하나의 물리적인 기기는 수 백개에서 수천개의 컨테이너를 띄우고, 종료 시킨다.

Linux Container의 가장 큰 이용자인 Google Search의 경우 매초마다 7000개의 컨테이너를 띄운다고 한다.

 

이렇듯 많은 컨테이너를 띄우는 동적인 클라우드 환경에서 네트워크로 연결성을 유지하는 것은 상당한 도전이다.

이유는 다음과 같다.

1. OS 레벨의 가상화는 컨테이너가 외부 환경과 연결하는데에 여러가지 방법을 제시한다. 해당 컨테이너의 workload에 무엇이 가장 적합한지를 결정하는 일은 복잡하다.
2. 싱글 서버에서 여러개의 컨테이너를 올릴 때에 네트워크 성능 저하가 하나의 연결만 했을때에 비해 적어야 하며, 확장 가능하여야 한다.
3. 컨테이너는 내부에서 컨테이너 간 연결이 되기 전에는 사용을 할 수 없다. sub-second latency와 함께 실행될수 있지만, short-lived 컨테이너에게 이러한 딜레이들은 치명적이다.
4. VM에 비해 낮은 isolation level을 제공하는 컨테이너 특성상, AWS등과 같은 클라우드 제공자들은 VM 안에서 컨테이너를 돌린다.컨테이너 네트워크와 VM 네트워크 사이의 연관성은 쉽게 이해되지 않는다.

 

 

 

-> Computing 성능이나 memory intensive workload는 베어메탈에 비해 성능저하가 없음을 알 수 있으나 VM 네트워크에 비해 컨테이너 네트워크의 경우 성능 저하가 심함을 알 수 있다.

 

single VM에서 Loopback Network interface를 사용하여 통신을 한다.( Loop Back Network Interface 127.0.0.1 IP 주소를 목적지로 전송하면 외부로 전송하지 않고 자신이 다시 받은 것처럼 처리되는 것).

 

 

 

multiple Vm에서는 VM들의 IP 주소를 활용하여 통신을 한다.

 

Loop Back이란?

https://taeng-develop.tistory.com/38

---

 

이 논문에서는 도커에서의 컨테이너 네트워크 성능에 대한 분석을 제시한다.

내용들은 다음과 같다.

 

1. Single host에서 Performance와 Security Isolation은 Tradeoff 관계에 있다
2. Mulit-host network에서는 Single host에서와는 다르게 복합적인 요인에 의한 tradeoff 관계에 있다.
3. 컨테이너 네트워크 혼자서도 오버헤드를 유발하지만, VM 위에서 작동을 할 때에도 처리량 감소 및 latency 증가가 유발된다.
4. 컨테이너 네트워크는 startup 하는데 소요 되는 시간이 크게 다르므로 고려가 필요하다.

---

 

Available Container Networks in the Public Cloud

Network on a single host는 하나의 host내 에서의 네트워크를 얘기하며 Network on mulitple host는 외부의 다른 호스트와의 소통을 위해 external network가 사용되는 경우를 의미한다.

 

도커의 경우 network on a single host에서 bridge가 default 값이고, network on multiple host에서는 overlay가 default 값임일 기억하고 있는 것이 중요하다.

---

Container Network on a Single Host

Container Network on a single host에는 4가지 네트워크가 쓰인다.

각각 None, Bridge, Container, Host 모드이다.

 

None Mode 설명

None Mode는 Closed Network Stack을 가진다. 이 말은 즉슨 loopback interface만을 가지고, host 내의 다른 컨테이너나 외부의 네트워크와도 통신을 못함을 의미한다.

 

 

Bridge Mode 설명

• Bridge 모드는 도커 컨테이너의 default 네트워크 설정이다.
• 도커는 도커 데몬이 실행되면 docker0 bridge를 생성을 한다.
• 새로운 컨테이너가 생성이 될 때마다 , veth(virtual ethernet)이 생성이 되어 docker 0을 통해 연결이 된다.
• docker 0에 연결된 모든 컨테이너는 하나의 virtual subnet에 속하며, private IP address로 소통을 할 수 있다.

 

 

 

Bridge Mode 단점

• NAT,Overlay 도움 없이는 external network를 사용할 수 없으며, 다른 호스트와 통신하는 inter-host communication도 불가하다. 
• 같은 호스트 내에서도 isolated된 namespace를 갖고, docker0를 통해야지 통신이 되기 때문에 많은 오버헤드가 발생한다(허나 이는 오히려 적절한 수준의 보안이 제공됨을 의미하기도 한다.)

한 줄 정리 :각자가 isolated 된 network namespace를 갖고 있고, 내부에서의 통신을 위해 docker 0을 거쳐야 된다!!

---

Container Mode 설명

• Bridge Mode와 다르게 여러개의 컨테이너가 그룹을 이뤄 하나의 network namespace를 공유한다.
• 하나의 컨테이너가 proxy 컨테이너(대표 컨테이너)로 지정이 되며, 다른 컨테이너는 프록시 veth interface를 통해 external network를 사용함.
• 하나만의 IP 주소를 사용하며,포트 번호를 이용하여 각각의 컨테이너를 구분함
• IPC를 이용하여 통신을 할 수 있다는 장점이 있다.

Container Mode 단점

• 같은 그룹에 속하면 isolation이 제공되지 않아 보안의 수준이 비교적 낮다.
• 대규모의 컨테이너 단계에서는 다른 Machine들과 통신을 해야되기 때문에 IPC 및 IP를 모두 사용해야된다는 단점이 있다.

한 줄 정리 : 같은 그룹에 속하면 하나의 IP address를 사용하여 IPC로 통신이 가능. 허나 규모가 커지면 IP와 복합적으로 사용

---

Host Mode 설명

• 모든 컨테이너들이 host OS의 네트워크 namespace를 쓰게 한다.
• 서로 IPC를 통해 통신을 할 수 있으며, 모든 컨테이너가 서로를 식별하는 것이 가능하다.

Host Mode 단점

• 당연하게도 가장 낮은 수준의 보안을 제공한다.

---

Container Network on Multiple Host

Container Network on a Multiple host에는 4가지 형태의 네트워크가 쓰인다.

각각 Host, NAT, Overlay, Routing 모드이다.

 

Host Mode 설명

• Single Host에서의 예시와 같이 host의 OS에서 NameSpace를 공유 받으므로 IP를 통해 통신하면 된다

Host Mode 단점

• bridge mode container에서는 host mode container의 destination IP 주소를 통해 통신을 할 수 있지만, host mode container에서는 bridge mode container의 Destination IP 주소만으로는 통신을 할 수가 없다.
•  

---

Network Address Translation

• NAT는 컨테이너의 private ip 주소를 포트 번호와 매핑해준다. 
• host의 public ip 주소와 변환된 포트 번호를 통해 통신이 이루어진다.
• 컨테이너에서 패킷을 전송을 하면 위의 내용을 바탕으로 host machine이 패킷 헤더를 수정을 한다.
• destination host에서는 포트 번호를 private ip 주소로 변환을 하여 컨테이너에 전달한다
• 포트번호와 private ip 주소 간의 변환은 docker0 브릿지에서 이루어진다.
• 복잡하지 않고 third-party software의 도움이 필요가 없다는 장점이 있다.

Network Address Translation 단점

• 모든 packet마다 ip 주소와 포트 번호 간의 변환이 필요하기에 오버헤드가 발생한다.
• private ip 주소를 포트로 변환을 하여 host의 public ip주소와 함께 사용을 하기에, 컨테이너의 public ip 주소가 host의 ip 주소에 종속적인 셈이다. 이는 short-lived인 동적 네트워크에서 포트 번호의 충돌을 야기할 수 있다.

---

Overlay Network

• Overlay Network는 다른 네트워크의 상위에서 노드들 간의 customized된 가상 링크를 생성하는 것을 의미한다.
• 컨테이너들은 자신의 private IP 주소와 호스트 Ip의 매핑을 Key Value 스토어(KV)에 저장을 하고, 이는 모든 host들로 부터 접근이 가능하다.
• private IP 주소를 바탕으로 전송을 하면, overlay layer에서는 private Ip를 바탕으로 KV를 통해 host의 IP 주소를 알아낸다.
• 이후 private IP 주소를 가진 패킷을 payload로 하는 새로운 패킷을 생성하며, destination은 host의 IP 주소이다.
• destination에 도달하면 decapsulation을 거쳐 컨테이너의 private 주소를 통해 전달된다.
• NAT와 비교하여 isolated 주소 공간을 주고, private IP 주소를 통한 통신을 허용한다는 장점이 있다.

 

Overlay Network 단점

• 패킷을 캡슐화하고 분해하는 과정은 값비싼 과정이며, 핵심적인 경로를 늘린다.
• 패킷의 크기를 변형시키기 때문에 MTU(Maximum transmission unit)을 넘길 수 있다.

Overlay Network Hierarchy

---

Routing 설명

Calico의 (BGP)는 라우팅을 이용한 네트워크를 제공한다.

 

host kernel에서 virtual router을 생성하여, 패킷 라우팅에 BGP를 활용한다.

 

Routing 단점

제한된 숫자의 네트워크 프로토콜만을 지원하며, 데이터 센터 네트워크에서는 아직 폭 넓게 지원되지 않고 있다는 단점이 있다.

---

 

Multiple Host에서의 컨테이너 네트워크 정리