Faisal Khan의 A Beginner’s Guide to Docker Container in NFV를 번역한 글입니다.

저자의 허락을 받고 번역했습니다.

2016년 3월 3일에 쓰여진 글입니다.

떠오르는 도커(Docker) 컨테이너는 NFV를 혁신할 잠재력을 가지고 있습니다. 무엇보다 도커 컨테이너는 가상 머신에 비해 가볍고, 적은 오버헤드와 리소스만을 요구하며, 동일한 운영체제에서 실행되는 애플리케이션을 격리시킬 수 있습니다. 즉, NFV에서 VNF(가상 네트워크 기능)이 도커 컨테이너에서 완전히 격리된 상태로 실행될 수 있다면, 가상 머신이 필요 없을 지도 모릅니다. 하지만 그게 그렇게 쉬울까요?

그렇다면 가상 머신의 미래는 어떻게 될까요? 사실 도커 컨테이너는 아직 성장하는 단계에 있기 때문에 가상 머신의 미래에 대해 뭐라고 말하기에는 너무 이릅니다(NFV도 마찬가지입니다 😊). 하지만 여러분이 이 글을 끝까지 읽는다면, 왜 모두가 도커 컨테이너에 대해 이야기하는지, 도커 컨테이너를 특별하게 만드는 것이 무엇인지 알 수 있을 것입니다.

본 가이드의 주요 목적은 도커 컨테이너의 아키텍처를 이해하는 데 있어 단계별로 이해할 수 있도록 돕는 것입니다. 이 과정에서 하이퍼바이저와 가상 머신의 기초에 대해서도 이해하게 될 것입니다. 이 개념들은 하이퍼바이저와 가상 머신에 대한 사전 지식이 전혀 없다고 가정하고 설명됩니다.

컨테이너란 무엇인가요?

애초에 컨테이너는 애플리케이션을 더 유연하고 기민하게 실행하는 방법으로 등장했습니다. 리눅스 컨테이너는 리눅스 운영체제 내에서 경량 애플리케이션을 직접 실행할 수 있도록 해주었습니다. 하이퍼바이저와 가상 머신이 필요하지 않기 때문에 애플리케이션은 동일한 운영체제 내에서 격리된 상태로 실행될 수 있습니다.

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

구글(Google)은 2006년부터 자사 데이터 센터에서 리눅스(Linux) 컨테이너를 사용해왔습니다. 하지만 2013년 도커 컨테이너의 등장과 함께 컨테이너는 더 널리 알려지게 되었습니다. 도커는 이전 버전의 컨테이너에 비해 더 간단하고 표준화된 방식으로 컨테이너를 실행할 수 있게 해줍니다.

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

도커 컨테이너가 LXC와 같은 경쟁 컨테이너보다 더 인기를 끈 이유 중 하나는 호스트 운영체제에서 “이미지"로 간단하고 빠르게 불러올 수 있기 때문입니다. 도커는 클라우드에 이미지 형태로 저장되며, 사용자가 필요할 때 간단하게 호출하여 실행할 수 있습니다.

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

NFV에서 도커 컨테이너를 이해하기 위한 단계별 가이드

가상 머신은 유용하지만 몇 가지 문제점이 있습니다.

전용 운영체제가 필요합니다. 또한 가상화를 달성하기 위해 가상 머신을 분리할 하이퍼바이저가 필요합니다.

애플리케이션이 많아질수록 소프트웨어 오버헤드가 증가하고 비용이 더 많이 들며, 지속적으로 업데이트를 유지해야 합니다. 그럼에도 불구하고 NFV 아키텍처에는 가상 머신이 필요합니다.

이제 NFV 아키텍처를 살펴보겠습니다.

1단계: NFV 아키텍처에서 하이퍼바이저 살펴보기

아래 다이어그램은 여러분이 여러 번 봤을 법한 NFV 아키텍처를 보여줍니다. (모르시는 분은 여기를 확인해주세요)

hypervisor-in-nfv

그림 1

이 논의를 위해 NFVI (NFV Infrastructure) 부분만 확대해서 살펴보겠습니다. NFVI는 세 가지 주요 구성 요소로 나뉩니다.

하이퍼바이저 도메인
컴퓨팅 도메인
네트워크 인프라스트럭처 도메인

가상화 계층(Virtualization Layer)은 실제로 하이퍼바이저를 의미하며, 이는 컴퓨트 도메인(물리적/x86 서버)의 하드웨어 리소스를 추상화하는 역할을 담당합니다. 예를 들어 단일 물리적 서버(물리적 메모리와 물리적 컴퓨트)가 있다고 가정해 봅시다. 하이퍼바이저는 이를 여러 개의 가상 메모리와 가상 컴퓨트로 분할할 수 있으며, 각 엔티티는 독립적으로 작동하게 됩니다.

이 가상화 계층(하이퍼바이저)과 가상 리소스를 함께 묶어서 “하이퍼바이저 도메인"이라고 부릅니다.

2단계: 가상 머신 자세히 살펴보기

가상 머신을 이해하기 위해 이번에는 하이퍼바이저 도메인을 확장하여 이 도메인 내부를 보여드리겠습니다.

아래 그림 2를 확인해 주세요.

왼쪽에는 앞서 그림 1에서 보았던 하이퍼바이저 도메인이 동일하게 표시되어 있습니다. 하지만 오른쪽 그림에서는 하이퍼바이저 도메인을 확장하여 가상 머신을 보여줍니다. 즉, 하이퍼바이저 도메인의 가상 리소스가 이제 가상 머신으로 표시된 것입니다.

hypervisor-domain-with-vm

그림 2

간단히 설명하기 위해 왼쪽의 가상 네트워크/네트워크 블록은 제거했습니다. 이 논의에서는 중요하지 않기 때문입니다. 여기서 가상화 계층은 리소스/네트워크 관리자가 되었고, 가상 컴퓨트/메모리는 가상 머신(VM)이 되었습니다.

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

가상 머신은 VNF(가상 네트워크 기능)이 실행되는 환경을 제공합니다. 다이어그램을 보면 각 가상 머신이 하나의 VNF와 연결되어 있는 것을 확인할 수 있습니다.

명확하게 하기 위해 예를 들어 설명하겠습니다. VNF1이 Virtual CPE라고 하고, VNF2가 Virtual Firewall이라고 가정해 봅시다. 위의 예시에서 각각은 자신의 가상 머신에서 실행됩니다. 그리고 이들은 하이퍼바이저 도메인 내부에서 서로 체이닝되어 연결될 수 있습니다.

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

게스트 운영체제 외에도 호스트 운영체제가 필요하다는 점에 주목하세요. 호스트 운영체제는 하이퍼바이저가 실행되는 환경입니다. 이 중요한 점을 기억해 두세요. 다음 단락에서 컨테이너에 대해 이야기할 때 다시 언급될 것입니다.

이제 가상 머신을 제거하고 다음 단계로 나아가 봅시다.

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

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

vm-replaced-with-container

그림 3

이제 VNF1은 컨테이너 1에서 실행되고, VNF2는 컨테이너 2에서 실행되어 가상 머신과 동일한 기능을 제공합니다. 우리가 달성한 것은 가상 머신과 동일한 기능이지만, 동일한 운영체제 내에서 실행된다는 점입니다. 여기서 운영체제는 리눅스입니다. 눈치채셨나요? 이제 게스트 운영체제가 필요하지 않습니다! 더 간단한 아키텍처입니다. 그렇죠?

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

컨테이너 환경에서는 게스트 운영체제(OS)가 필요하지 않습니다. 보시다시피 호스트 OS는 리눅스입니다. 따라서 가상 머신에 비해 더 경량이며 오버헤드가 적습니다.
아키텍처가 간소화되었습니다. 하이퍼바이저를 제거하고 컨테이너가 동일한 호스트 OS 내에서 OS 수준의 충분한 격리를 유지할 수 있기 때문입니다.
가상 머신은 하드웨어 수준의 가상화를 제공합니다. 즉, 전통적인 가상 머신은 하이퍼바이저 소프트웨어를 통해 호스트를 분할합니다. 이 말은 가상 머신이 호스트 머신의 OS와 격리된다는 것을 의미합니다. 예를 들어, 리눅스 운영체제 위에서 윈도우 호스트를 실행할 수 있습니다. 반면, 컨테이너는 OS 수준의 가상화를 제공합니다. 즉, 동일한 OS 내에서 애플리케이션이 서로 격리된 상태를 유지할 수 있습니다. 이것은 가상 머신에 비해 오버헤드가 훨씬 적은 방식입니다. 왜냐하면 전체 OS를 중복해서 실행할 필요가 없기 때문입니다.

컨테이너에 대한 설명은 여기까지입니다.

NFV를 위한 컨테이너의 미래

솔직히 말해서, 현재 NFV 아키텍처와 표준은 가상 머신을 기반으로 하고 있습니다.

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

그럼에도 불구하고 컨테이너는 이러한 환경에서 VNF를 실행하는 데 있어 간단하고 효율적인 방식을 제공하기 때문에 유망한 미래를 약속합니다. 또한, 가상 머신 위에서 전체 VNF를 실행하는 대신, 마이크로서비스를 실행할 수 있습니다.

예를 들어 가상 CPE(vCPE, Virtual Customer Premises Equipment)의 경우 많은 구성요소를 작은 컨테이너로 분해하고 서로 연결(체이닝)할 수 있습니다. 기능을 분해하면 소프트웨어 벤더들이 VNF의 작은 기능을 더 쉽게 개발할 수 있고 오버헤드도 줄일 수 있는 기회를 제공합니다.

최종 수정: 2020-11-16