NFV의 이해(1) : 기본

NFV란?

안녕하세요. 김민욱입니다.

 

이번 포스팅에서는 5G 네트워크의 주요 키워드인 NFV에 대해 말씀드리고자 합니다. 이제는 많이 익숙하고 알려져 있지만, 그래도 앞으로의 연구 결과들이나 내용을 설명하기 위해 간단하게 NFV에 대해 기술해도 좋을 것 같다는 생각이 들어서 포스팅하게 되었습니다. 

 

먼저 NFV는 Network Functions Virtualisation의 약자로 네트워크 기능들을 가상화한다는 의미입니다. 이때 가장 중요한 키워드는 하드웨어와 소프트웨어의 분리입니다. 원래 네트워크 기능들은 특정 하드웨어에 특정 소프트웨어가 올라간 하나의 묶음이었습니다. 그러나 NFV 및 가상화가 도입되면서, 하드웨어는 범용적인 x86 서버를 사용하고 네트워크 기능은 소프웨어로 구현하였습니다. 비유드리자면, 원래는 콜라를 마시려면 무조건 콜라 컵이 필요하였고 사이다를 마시려면 사이다 컵이 필요하였습니다. 하지만 이제는 컵만 있으면 콜라든 사이다든 마실 수 있게 되었습니다.2012년 ETSI(European Telecommunications Standards Institute)에서 NFV의 표준을 정의하였습니다. [1] NFV는 주로 통신사에서 사용하는 개념으로 가상화된 네트워크 기능들을 정확하고 안전하게 제공하기 위한 여러 가지 기능들이 정의되어 있습니다.

 

또한 각 컴포넌트들 사이에 어떤 데이터가 어떤 포맷으로 송수신되는지, 보안, 에지 컴퓨팅 등 ETSI의 여러 그룹들이 지속적으로 관련 내용을 정의하고 문서를 배포하고 있습니다. 

 

* 혹 추가 내용이 필요하시거나, 수정 사항이 있다면 말씀해주시면 즉시 반영하겠습니다. 감사합니다 : )

* 현재 포스팅에서 모든 그림의 출처는 [1][2][3][4] 임을 밝힙니다.(하단참조)

NFV Architecture

이번 내용에서는 ETSI GS NFV 002(v1.1.1) 문서를 기준 NFV의 구조에 대해 설명하겠습니다.(그림출처 : [2]) 먼저 ETSI GS NFV 002 문서는 NFV의 아키텍처에 대해 설명하고 있는데 가장 일반적으로 알려진 구조는 그림 1과 같습니다.  또한 주요 컴포넌트들의 약어를 보면 표 1과 같습니다. 

 

그림 1. NFV 아키텍쳐 

표1. NFV 컴포넌트 약어

NFV를 구성하는 여러 컴포넌트들은 각자의 확실한 역할을 가지고 있습니다.  또한 이러한 컴포넌트들은 ETSI에 의해 각각의 문서로 자세하게 설명되어있으니 꼭 참고하시기 바랍니다.

 

NFVO는 NFV 환경에서 모든 컴포넌트들이 원활하게 실행되기 위해 리소스 사용 승인을 결정하게 됩니다. 따라서 전체적으로 NFV 컴포넌트들을 조율하고 리소스 사용에 대한 여부를 결정하는 결정권자입니다.

 

VNFM의 경우 약어에서 알 수 있듯이 VNF의 라이프사이클을 관리합니다. 만약 VNF 라이프사이클에 대해 어떤 요청이 오는 경우 VNFM은 해당 VNF를 생성하거나, 삭제하는 등의 액션을 취하기 위해 먼저 NFVO에게 해당 동작을 수행할 수 있는 리소스가 가능한지 승인 요청을 보내고 NFVO는 이를 확인하여 VNFM에게 트리거를 보내게 됩니다. 이처럼 VNF의 라이프사이클을 관리하는 NFVO와 VNFM을 묶어서 MANO 즉 Management And Orchestration이라고 합니다. 

 

VNF는 가상화된 네트워크 기능을 의미합니다. 기존의 경우 방화벽, 라우터 등과 같은 네트워크 기능들은 특정 하드웨어 위에서 동작하게 됩니다. 따라서 방화벽이나 라우터 기능을 필요하면 네트워크 장비를 사야 하므로 비용 소비가 많았습니다. 그러나 이러한 방화벽이나 라우터를 소프트웨어로 구현하고 일반적인 x86 서버 위에서 가상 머신 형태로 이들을 운용하게 됨으로써 비용을 효과적으로 줄일 수 있었습니다. VNF는 이렇게 소프트웨어로 구현된 네트워크 기능을 의미합니다. 

 

하지만 VNF=VM이라고 오해할 수 있습니다. VNF는 엄연히 네트워크 기능에 대한 논리적인 범위이고 하나 이상의 VNFC 즉 VNF Component로 이루어져 있습니다. 한마디로 VNF는 하나의 VNFC일 수도 있고 여러 개의 VNFC가 하나의 VNF일 수도 있습니다. 만약 방화벽을 운용하기 위해 4개의 VNFC가 필요하다면 방화벽 VNF 하나는 4개의 VM으로 구성된다라고 생각하실 수 있습니다.  본 내용은 ETSI 문서에 설명되어 있으니 내용이 더 필요하시다면 꼭 확인하시길 바랍니다. 

 

NFVI는 하드웨어, 하이퍼바이져, 가상화 기능 등을 하나로 묶어 NFV에서 리소스를 제공하는 인프라로 볼 수 있습니다. NFVI를 실제로 본다면 x86 서버입니다. 따라서 NFVI는 H/W 서버 위에 하이퍼바이져와 같은 가상화 기능이 포함된 OS가 올라가고(H/W위에 바로 클라우드를 올리는 베어 메탈도 있습니다.) 그 위에 클라우드와 관련된 여러 프로세스들이 운용됩니다.  그렇다면 가상 머신은 어디에 있을까요? NFVI에 있습니다. 

 

VIM은 클라우드 OS의 역할을 합니다. 관리자에게 인터페이스를 제공하고 NFVI의 리소스를 관리하고, 여러 가상화 프로세스들을 관리합니다. 또한 보안, 인증과도 같은 여러 API 접근을 보호합니다. 대부분의 클라우드들은 모두 이 VIM으로써 역할을 합니다. 여기서 많은 분들이 NFVI에 VIM이 설치가 되는데 왜 별도의 컴포넌트로 구성되어 있는지 궁금하실 수 있습니다. NFV는 하이레벨 아키텍처로 일종의 개념입니다. 따라서 VIM 역할의 소프트웨어들은 모두 NFVI의 H/W에 설치되고 이를 컨트롤하게 됩니다. 예를 들어 VNF를 생성하기 위해 MANO에서 요청이 온다면, VIM은 실질적으로 가상 머신을 생성하게 됩니다. VIM이나 MANO는 다뤄야 할 범위가 넓기 때문에 추후 글들을 통해 더욱 자세히 작성하도록 하겠습니다. 

 

EMS는 저 또한 굉장히 이해하기가 어려웠던 컴포넌트였습니다. 예를 들어 VNF 생성 절차 문서를 보게 되면 EMS가 MANO 쪽으로 요청을 보내는 것으로 되어 있으나 별도의 설명에서는 다수의 VNF 벤더들이 제공하는 VNF를 적용하기 위해 필요한 여러 기능들의 집합체라고 합니다. EMS는 관리자의 명령 MANO에게 전달하는 역할일 수도 있고 VNF를 구성하는 VNFC를 모니터링하는 역할을 할 수도 있습니다. 만약 인프라에 대한 모니터링 정보를 받기 위해서는 MANO에게 모니터링 데이터 구독 요청을 보내 데이터를 수신한다고 명시되어 있기도 합니다.  위에 언급한 컴포넌트들 중 가장 이해가 어려운 컴포넌트였던 것 같습니다.

 

NFV 프로젝트

NFV는 미래 네트워크를 위해 가상화 기반의 표준을 제정한 것입니다. 그렇다면 5G가 나온 지금 NFV를 실현하기 위해 어떤 프로젝트들이 진행되었을까요? 지금부터는 대표적인 NFV 프로젝트 2가지에 대해서 아키텍처를 기준으로 간략하게 설명드리고자 합니다.

 

OPFNV

먼저 OPNFV는  Open Platform for NFV Project의 약자로  2014년 리눅스 재단과 AT&T, 시스코와 같은 여러 통신사와 네트워크 장비 회사들이 NFV를 실현하기 위해 공통의 플랫폼이 필요하다는 것을 인지하고 리눅스 파운데이션 재단을 기반으로 프로젝트를 오픈소스로 시작하기 시작하였습니다.

 

OPNFV는 NFV를 표준 그대로 구현하고 실현하기 위해 여러 오픈소스 프로젝트들을 지속적으로 통합하고 6개월의 주기마다 알파벳 순의 강이름을 따서 새 버전을 릴리스하기 시작하였습니다. 

 

그림 2. OPNFV 아키텍쳐(그림출처: [3])

OPNFV 프로젝트 상당히 많은 수의 프로젝트들이 포함되어 있습니다. NFV에서 VIM의 역할로 Openstack, Kubernetes를 포함하고 있고 FD.io, DPDK 같은 데이터 가속화 프로젝트, Doctor라고 불리는 Fault Management 등 각자의 역할을 가지는 여러 오픈소스 프로젝트들을 하나로 통합하여 제공하는 플랫폼입니다. 

 

하지만 제가 직접 OPNFV를 구성하면서 느낀 점은 여러 프로젝트들을 통합으로 설치하고 구성하다 보니 버전, 네트워크 구성, 기타 리눅스와의 상호 작용 등으로 인해 구성이 상당히 까다롭다고 느꼈습니다. 실 적용은 어렵지 않을까라는 생각이 조금 들기도 하였습니다. 방대한 양의 코드와 프로젝트들을 소수의 인력을 관리하기 어렵지만, 그래도 충분히 연구하고 공부해볼 만한 가치가 있는 프로젝트라고 생각합니다.  

 

ONAP

 

OPNFV 이후로 릴리즈 된 ONAP 프로젝트는 Open Networking Automation Platform의 약자로 2017년 2월 리눅스 재단에 의해 호스팅 되었습니다. ONAP은 OpenECOMP와 Open-O 프로젝트를 합쳐 하나의 플랫폼으로 완성하였습니다. (그림출처 : [4] )

 

그림 3. ONAP 아키텍쳐

제가 확인해본 바로는 ONAP은 주로 중국의 ZTE, 화웨이 같은 기업들이 많이 참여하고 주도적으로 프로젝트들을 이끌어 가고 있었습니다. ONAP 또한 크게 그룹으로 여러 컴포넌트들을 나누고 그 안에 오픈소스 프로젝트들이 포함되어 있습니다. 제가 주로 연구했던 DCAE 컴포넌트에는 데이터 수집, RCA(Root Cause Analysis), 모니터링 등을 담당하는 여러 오픈소스 프로젝트들이 포함되어있습니다. 이처럼 ONAP은 크고 작은 여러 오픈소스들이 하나의 기능을 이루는 초 거대 플랫폼으로 생각할 수 있을 것 같습니다.

 

다만, ONAP을 설치하기 위해서 고사양의 서버가 필요하였고 따라서 실제로 프로젝트를 배포해보는 것이 쉽지 않았습니다. 

 

결론

 

이번 포스팅에서는 이제는 꽤나 흔한 주제인 NFV에 대해서 간략하게 설명하고 ONAP, OPNFV와 같은 NFV 플랫폼에 대해서도 간략하게 설명하였습니다. 아마 ONAP이나 OPNFV를 구성하는 프로젝트 하나만으로도 긴 장문의 포스팅이 나올 것으로 예상됩니다.  따라서 OPNFV, ONAP에 대해서 공부하실 때 큰 그림으로 먼저 접근하시고 관심 있는 컴포넌트를 집중적으로 보는 것이 현실적일 것 같다는 생각이 듭니다.

 

부족한 내용이지만 조금이나마 도움되시길 바라겠습니다. 감사합니다. 

 

 

인용글

[1] ETSI White Paper(2012) :  https://portal.etsi.org/NFV/NFV_White_Paper.pdf
[2] ETSI GS NFV 002(2013) : https://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.01.01_60/gs_NFV002v010101p.pdf

[3] OPNFV : https://wiki.opnfv.org

[4] ONAP : https://en.wikipedia.org/wiki/ONAP

업데이트로그

------------------------------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한  주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.