brunch

You can make anything
by writing

C.S.Lewis

by 흐르는 강물처럼 Jan 19. 2021

방화벽-8 (가상화 기술의 발전)

가상화 기술의 발전방향을 소개해 드리겠습니다.

이번 글에서는 가상화 기술의 발전방향에 대해 소개하겠습니다. 가상화 기술은 하이퍼바이저라는 기능을 통해 발전하였습니다. 물리적인 서버 위에 하이퍼바이저를 설치한 후 VM 대수를 늘리는 방식으로 서비스 능력을 증가시켰습니다. 그런데 동일한 조건의 CPU와 메모리를 사용하는 일반 서버와 VM을 비교 해 보니 VM의 전반적인 성능이 일반 서버에 비해 낮다는 점이 가상 서버의 가장 큰 약점이었습니다. 이 문제는 VM을 사용하기 위해서 Guest OS를 반드시 설치해야 하는 조건 때문에 발생합니다.


고객에게 직접 서비스를 제공하는 프로그램 입장에서는 VM 내의 Guest OS와 서버의 Host OS , 총 2개의 OS를 거쳐야만 CPU, 메모리 등의 자원에 접근할 수 있습니다. OS를 거칠 때마다 응답 시간이 조금씩 늘어나기 때문에 서비스를 받는 고객 입장에서는 서비스가 느려지는 문제가 생깁니다. 서비스 제공자 입장에서는 서비스가 느려지지 않게 하기 위해서 VM의 스펙이나 개수를 증가시키는 방식으로 대응할 수밖에 없습니다. 이 문제는 VM에서 생기는 오버헤드(Overhead)를 최소화해야 해결 가능합니다. 


그래서 나온 기술이 Container(컨테이너) 기술입니다. 하이퍼바이저 대신에 컨테이너 엔진을 이용하여 VM대신에 컨테이너를 만들어서 내부에 별도의 GuestOS를 설치할 필요 없이 바로 프로그램으로만 구성하여 작동시킬 수 있도록 하였습니다. 현재 사실상의 컨테이너 표준 기술은 도커(Docker)라는 기술입니다. 아래 <그림 1>과 같이 고래 위에 컨테이너 박스를 실어서 운반하는 것처럼 여러 가지 프로그램을 박스 화하여 간편하게 사용할 수 있도록 한다는 것을 표현한 이미지입니다. 


<그림 1 > 컨테이너 기술의 사실상 표준이 된 도커(Docker)


<그림 1>에 있는 고래의 오른쪽 그림을 하아 퍼 바이저 기술과 비교해 보면 Hypervisor 계층과 Guest OS 계층이 Docker Engine으로 대체되었습니다. 프로그램과 동작에 필요한 라이브러리, 바이너리 파일을 묶어서 박스화 시켜 하나의 파일로 만든 다음 VM과 동일하게 도커 엔진에서 이 파일을 구동시켜는 방식으로 동작합니다. 


VM과 비교해 보면 OS가 하나 없어진 것 밖에 없지만 응답속도는 획기적으로 개선되었습니다. 그뿐만 아니라 VM의 크기는 GuestOS를 포함하고 있기 때문에 대략 수백 메가에서 수십 기가까지 용량이 컸지만, 컨테이너 파일의 수십 Mbyte에서 200 Mbyte까지 크기가 작아져서 저장 배포가 더 쉬어졌습니다.


부팅속도에서도 VM의 경우 1~3분 정도가 걸렸다면 컨테이너는 OS가 없기 때문에 수초에서 30초 이내에 부팅이 완료되어 사용 가능하기 때문에 클라우드 환경에서 신속하게 서비스 용량을 증가시켜야 할 경우 유용하게 사용 가능한 장점이 있습니다.


그뿐만 아니라 이러한 도커를 효율적으로 관리하고 확장하기 위해 쿠버 네티스(Kubernets:이하 K8s로 호칭)라는 플랫폼이 등장하면서 도커를 이용한 컨테이너 기술의 활용도가 급속이 증가하고 있습니다. K8s는 구글에서 개발한 기술로써 컨테이너화 된 애플리케이션을 자동으로 배포, 스케일링(확장 또는 축소), 생성, 삭제하는 오픈소스 시스템입니다. 


통상 컨테이너 오케스트레이션(Orchestration) 플랫폼이라고 하는데, 어렵게 생각할 필요 없이 교향곡을 연주할 때 지휘자가 여러 명의 연주자를 악보에 맞추어 틀리지 않고 연주할 수 있도록 조정하듯이 여러 개의 컨테이너를 설정한 옵션 값에 맞게 복제하거나 배포하면서 체계적으로 관리하는 기술을 말합니다.


구체적으로 컨테이너의 실행, 배포를 책임지며, 장애에 대비한 이중화 구성을 지원하며, 트래픽의 증가에 대응하기 위한 자동 확장 및 축소 동작을 관리하고, 스케줄링 기능을 통해 서비스 업데이트 및 유지보수 기능을 지원합니다. 그뿐만 아니라 컨테이너가 동작하는 서버의 CPU, 메모리에 대한 관리, 컨테이너의 네트워크 관리, 컨테이너의 health상태 모니터링을 통해 관리자의 직접적인 조작을 최소화하고 사전에 설정된 값에 맞추어 자동화된 서비스가 가능하게 지원하는 서비스로 기회가 된다면 따로 설명하는 글을 올리도록 하겠습니다.


아래 <그림 2>는 PNF, VNF, CNF를 비교하여 표시하였습니다. 기존의 물리적이 네트워크 장비는 PNF(Physical Network Function), 가상화된 네트워크 장비를 VNF(Virtual Network Function), 컨테이너 기반 네트워크 장비를 CNF(Container Network Function)이라고 표현하였습니다.


< 그림 2 >  PNF, NFV, CNF 비교 (출처 : 넷매니아즈)


네트워크 장비의 시작은 PNF로 시작되어 물리적인 전용 장비로 시작되어 대략 1990~2005년까지의 기술이라고 하면, 서버의 멀티코어 기술과 하이퍼바이저 기술을 활용한 NFV 기술은 2005~2020년 현재까지도 현업에서 사용되고 발전하고 있는 기술입니다. 그러나 NFV는 기업단위 가상화 환경에서 시작된 기술이라 사용하면서 발생하는 성능 저하 및 클라우드 환경에서 운영하면서 발생하는 여러 가지 단점을 개선이 필요하여, 이를 위해 등장한 기술이 CNF기술이라고 할 수 있습니다. 


클라우드가 본격적으로 사용되면서, 고객의 요구에 짧은 시간에 대응이 필요한 환경이 되면서 좀 더 경량화되고, 빠른 서비스가 가능하며, 동일 자원에 좀 더 빠른 서비스를 제공하기 위해서 클라우드에 최적화된 영어로 Cloud Native 한 기술이 컨테이너 기술이라고 할 수 있습니다.


현재 클라우드 환경에서는 기존의 VM기반 구조가 컨테이너 기반 구조로 빠르게 대체가 시작되고 있는 상황입니다. 여기에 대응하기 위해 네트워크 벤더에서도 컨테이너 기반의 네트워크 장비를 개발 중이거나 일부 현업 서비스에 부분적으로 적용해 테스트 중이라고 합니다. 머지않은 장래에는 좀 더 용량이 줄어들고 부팅 속도도 빠르며, 같은 조건의 VM에 비해 처리 성능이 향상된 컨테이너 기반 방화벽이 클라우드 환경에서 많이 사용될 수 있을 거라 기대합니다.


이번 글을 마지막으로 방화벽에 대한 설명은 마치고, 다음 글부터는 VPN(Virtual Private Network:가상사설망)에 대해 설명드리겠습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari