NFV 도커 컨테이너 초심자 가이드
Faisal Khan

새롭게 등장한 도커(Docker) 컨테이너는 NFV를 혁신할 수 있는 잠재력을 가지고 있습니다.

무엇보다 도커 컨테이너는 가상 머신에 비해 가볍고, 적은 오버헤드와 리소스만을 요구하며, 동일한 운영 체제에서 실행되는 애플리케이션을 격리시킬 수 있습니다.

즉, NFV의 VNF(가상 네트워크 기능)를 완전히 격리시켜 도커 컨테이너에서 실행할 수 있다면 가상 머신이 필요 없을 지도 모릅니다.

하지만 그게 쉬울까요?

가상 머신의 미래는 어떨까요?

실제로 도커 컨테이너가 아직은 성장하는 단계에 있기 때문에 가상 머신의 미래에 대해 뭐라고 말하기에는 너무 이릅니다(NFV도 마찬가지입니다 😊).

하지만 여러분이 이 글을 끝까지 읽는다면 현재 모든 사람들이 이야기하는 도커 컨테이너를 특별하게 만드는 것이 무엇인지 알 수 있습니다.

본 가이드의 주목적은 도커 컨테이너의 아키텍처를 이해하는 데 있어 단계별로 안내하는 것입니다. 이 과정에서 하이퍼바이저 및 가상 머신의 기초도 이해하게 됩니다.

이러한 개념들은 가상 머신 및 하이퍼바이저에 대한 사전 지식이 전혀 없다고 가정하여 설명됩니다.

컨테이너란 무엇인가요?

과거에는 보다 유연하고 민첩한 방식의 애플리케이션 실행 방법으로 컨테이너가 등장했습니다. 리눅스 컨테이너는 리눅스 운영체제 내에서 직접 경량 애플리케이션을 실행할 수 있도록 해주었습니다. 하이퍼바이저와 가상 머신이 없어도 동일한 운영 체제에서 애플리케이션을 격리하여 실행할 수 있습니다.

도커 컨테이너란 무엇인가요?

구글(Google)은 데이터 센터에서 2006년부터 리눅스(Linux) 컨테이너를 사용하고 있습니다. 하지만 컨테이너는 2013년에 도커 컨테이너가 나오면서 더 유명해졌습니다. 이는 이전 버전의 컨테이너에 비해 컨테이너를 보다 단순하고 표준적인 방식으로 실행할 수 있는 방법입니다.

도커 컨테이너는 리눅스에서도 실행됩니다. 하지만 도커만이 컨테이너를 운영하는 유일한 방법은 아닙니다. LXC는 컨테이너를 실행하는 또 다른 방법입니다. LXC와 도커는 모두 리눅스에 뿌리를 두고 있습니다.

도커 컨테이너가 LXC와 같은 경쟁 컨테이너에 비해 더 인기 있는 이유 중 하나는 호스트 운영 체제에서 간단하고 빠르게 “이미지"로 불러올 수 있기 때문입니다. 도커는 클라우드에 이미지로 저장되며, 필요한 경우 간단한 방법으로 사용자가 실행을 요청합니다.

앞으로 “컨테이너"와 “도커 컨테이너"라는 단어를 동일한 의미처럼 사용하겠습니다.

NFV에서의 도커 컨테이너를 이해하기 위해 단계별로 안내합니다.

가상 머신은 좋지만 다음과 같은 문제점이 있습니다.

전용 운영 체제가 필요합니다. 또한 가상화를 구현하려면 가상 머신을 분리하는 하이퍼바이저가 필요합니다.

애플리케이션이 많을수록 소프트웨어 오버헤드가 증가하고 비용이 많이 들며 업데이트 상태를 유지해야 합니다.

하지만 NFV 아키텍처에는 가상 머신이 필요합니다. NFV 아키텍처를 살펴보겠습니다.

1단계: NFV 아키텍처의 하이퍼바이저부터 살펴보겠습니다.

아래 다이어그램에 NFV 아키텍처가 있는데, 아마 여러 번 보셨을 것입니다. (모르시는 분은 여기를 확인해주세요)

hypervisor-in-nfv

이 논의를 위해 세 가지 고유한 구성 요소가 있는 NFVI(NFV Infrastructure)만 살펴보겠습니다.

하이퍼바이저 도메인, 컴퓨팅 도메인 및 네트워크 인프라 도메인입니다.

가상화 계층(Virtualization Layer)은 실제로 컴퓨팅 도메인(물리적 서버 및 x86 서버)의 하드웨어 리소스 분리를 담당하는 하이퍼바이저입니다. 예를 들어 단일 물리 서버(물리 메모리 및 물리 컴퓨팅)가 있을 수 있지만 하이퍼바이저는 각 엔터티가 독립하는 방식으로 이를 여러 가상 메모리 및 가상 컴퓨팅으로 파티셔닝할 수 있습니다.

가상 리소스와 함께 (하이퍼바이저라고 하는) 가상화 계층을 “하이퍼바이저 도메인"이라고 합니다.

2단계: 가상 머신을 자세히 살펴보겠습니다.

이제 가상 머신을 이해하기 위해 하이퍼바이저 도메인을 확장하여 이 도메인 내에 무엇이 있는지 보여드리겠습니다.

아래 두 번째 그림을 확인하세요.

위의 첫 번째 그림과 동일한 하이퍼바이저 도메인이 왼쪽에 있습니다. 오른쪽 그림에는 하이퍼바이저 도메인을 확장하여 가상 머신이 있습니다. 즉, 하이퍼바이저 도메인의 가상 리소스가 이제 가상 머신으로 표시됩니다.

hypervisor-domain-with-vm

간단하게 설명하기 위해 왼쪽의 가상 네트워크 블록 및 네트워크 블록을 제거했습니다. 이 블록들은 여기서 중요하지 않습니다.

가상화 계층이 리소스 관리자 및 네트워크 관리자가 되었습니다. 가상 컴퓨팅 및 가상 메모리가 가상 머신이 되었습니다.

그렇다면 가상 머신이란 무엇일까요?

가상 머신은 VNF(가상 네트워크 기능)가 실행되는 환경을 제공합니다.

다이어그램을 보면 각 가상 머신이 VNF에 연결됩니다.

명확하게 하기 위해 예를 들어 설명하겠습니다. Virtual CPE라는 VNF1과 Virtual Firewall이라는 VNF2가 있습니다. 위의 예에서 각각 고유한 가상 머신으로 실행됩니다. 그런 다음 하이퍼바이저 도메인을 통해 체인으로 연결하고 내부적으로 연결할 수 있습니다.

또한 가상 머신은 논리적으로 서로 분리되어 있습니다. 따라서 각 가상 머신에서 독립적인 운영 체제를 실행할 수 있습니다. 예를 들어 게스트 운영 체제 OS1은 리눅스일 수 있고 게스트 OS2는 솔라리스일 수 있습니다.

또한 게스트 운영 체제 외에도 하이퍼바이저가 실행되는 환경인 호스트 운영 체제가 필요합니다. 다음 단락에서 컨테이너에 대해 논의할 때 이 중요한 점을 명심하세요.

이제 가상 머신을 제거해 보겠습니다.

3단계: 가상 머신을 제거하고 컨테이너를 도입하세요!

이제 가상 머신 대신 완전히 새로운 구성 요소 컨테이너를 도입합니다.

vm-replaced-with-container

이제 VNF1은 컨테이너 1에서 실행되고 VNF2는 가상 머신과 동일한 기능을 제공하는 컨테이너 2에서 실행됩니다.

가상 머신과 동일한 기능을 제공하지만 동일한 OS (여기서는 리눅스) 내에서 제공합니다.

이제 게스트 OS가 필요하지 않다는 것을 알아차리셨나요?

단순한 아키텍처입니다. 그렇죠?

컨테이너로 무엇을 달성했나요?

  1. 호스트 OS가 리눅스인 것을 알 수 있으므로 컨테이너 환경에 게스트 OS가 필요하지 않습니다. 따라서 가상 머신에 비해 가볍고 오버헤드가 적습니다.

  2. 현재 컨테이너가 동일한 호스트 OS 내의 OS 수준에서 충분히 격리 상태를 유지할 수 있으므로 하이퍼바이저를 제거하여 아키텍처를 단순화합니다.

  3. 가상 머신(VM)은 하드웨어 레벨 가상화를 제공하므로 기존의 가상 머신이 하이퍼바이저 소프트웨어를 통해 호스트를 가져오고 파티션을 분할합니다. 이는 기본적으로 VM이 호스트 머신의 OS에서 분리됨을 의미합니다. 리눅스 운영 체제에서 윈도우즈(Windows) 호스트를 실행할 수 있습니다. 반면에 컨테이너는 OS 수준 가상화를 제공합니다. 즉, 동일한 OS에서 애플리케이션은 자체적으로 격리될 수 있습니다. 이는 전체 OS가 중복되지 않기 때문에 VM에 비해 훨씬 적은 오버헤드입니다.

컨테이너 얘기는 여기까지입니다.

NFV용 컨테이너의 미래

현실을 보면 현재의 NFV 아키텍처와 표준은 가상 머신을 기반으로 합니다.

컨테이너는 아직 NFV에서 새로운 개념입니다. 특히 보안 측면에서 여전히 많은 개발이 진행되고 있습니다. 보시다시피 호스트 OS가 모든 컨테이너에 노출되어 있어 멀티 테넌시 보안 문제가 발생할 수 있습니다.

그러나 컨테이너 환경에서 VNF를 쉽고 간단하게 실행할 수 있다는 것을 고려할 때 좋은 미래가 있을 것 같습니다. 또한 가상 머신에서 전체 VNF를 실행하는 대신 마이크로 서비스를 실행할 수 있습니다.

예를 들어 가상 CPE(vCPE, Virtual Customer Premises Equipment)의 경우 많은 구성요소를 작은 컨테이너로 분해하여 체인으로 연결할 수 있습니다. 이 기능을 분해하면 소규모 소프트웨어 벤더가 적은 오버헤드로 VNF의 작은 기능을 쉽게 개발할 수 있습니다.


Last modified on 2020-11-16