상명대학교 / 서광규 교수
3. 비즈니스 모델 및 설계 고려 사항
NFV 아키텍처를 사용하고 네트워크 가상화 및 클라우드 컴퓨팅을 위한 비즈니스 모델을 기반으로 NFV 환경의 5개 주요 플레이어를 식별하고 이들 간의 가능한 비즈니스 관계를 설명하는 참조 비즈니스 모델을 설명하면 다음과 같다.
3-1. 비즈니스 모델
1) 인프라 제공자(Infrastructure Provider): 인프라 제공자는 데이터 센터 및 물리적 네트워크 형태로 물리적 자원을 배포하고 관리한다.
가상 리소스는 프로그래밍 인터페이스를 통해 하나 이상의 TSP에 프로비저닝 및 임대될 수 있다.
인프라 제공자는 또한 사용 가능한 자원 풀이 TSP에 할당되는 방법을 결정할 수 있다.
NFV에서 인프라 제공자의 예로는 Amazon과 같은 공퍼블릭 데이터 센터 또는 TSP가 소유한 개인 서버가 있을 수 있다.
특정 인프라 제공자가 특정 TSP에 리소스를 전부 또는 부분적으로 제공할 수 없는 경우 다중 도메인 VNF를 제공하기 위해 다른 인프라 제공자와 협상 및 연합을 형성할 수 있다.
[그림3. NFV 비즈니스 모델]
2) TSP(통신 서비스 제공업체): TSP는 하나 이상의 인프라 제공자로부터 리소스를 임대하여 VNF를 실행하는 데 사용한다. 또한 최종 사용자를 위한 서비스를 생성하기 위해 이러한 기능의 연결을 결정한다.
보다 일반적인 경우, TSP는 자신의 가상 자원을 다른 TSP에 재임대할 수 있다. 이 경우 재판매 TSP가 인프라 제공자의 역할을 맡게 된다.
인프라 제공자가 개인 또는 사내인 경우. TSP 네트워크 노드나 서버에 의해 제공되는 경우 인프라 제공자와 TSP는 하나의 개체일 수 있다.
3) VNFP(VNF Providers) 및 SP(Server Providers): NFV는 기존 네트워크 장비 공급업체(Cisco, Huawei, HP, Alcatel-Lucent 등)의 역할을 VNFP와 SP로 나뉜다. VNFP는 NF를 위한 소프트웨어 구현을 제공한다.
이러한 기능은 TSP에 직접 제공되거나(인터페이스 1을 통해) VNFP가 이를 인프라 제공자에 제공하고(인터페이스 2를 통해) 인프라와 VNF를 모두 TSP에 제공할 수 있다.
TSP가 자체 NF(소프트웨어)(일부)를 개발하는 것도 가능한다. 이 경우 VNFP와 TSP는 하나의 개체가 된다.
같은 방식으로 SP는 VNF를 배포할 수 있는 업계 표준 서버를 제공한다. 이러한 서버는 인프라 제공자(기능이 클라우드에서 실행되는 경우) 또는 TSP(기능이 TSP의 네트워크 노드에서 실행되는 경우)에 제공될 수 있다.
이러한 법인(VNFP 및 SP)이 실제로 하나의 회사일 수 있다는 점은 주목할 가치가 있다.
가장 큰 차이점은 이들이 제공하는 기능이 특수 기능을 갖춘 장비에서 실행되거나 특정 공급업체가 만든 장비에서 실행되는 것과 관련이 없다는 것이다.
즉, TSP는 한 엔터티에서 VNF를 구매하고 다른 엔터티에서 서버를 구매할 수 있다.
4) 브로커: 경우에 따라 TSP는 여러 VNFP에서 단일 서비스를 구성하는 기능을 구매하거나 여러 인프라 제공자의 리소스에서 실행되는 최종 엔드투엔드 서비스를 배포 및 관리해야 할 수도 있다.
이 경우 중개 역할이 필요할 수 있다.
브로커는 TSP로부터 리소스 및/또는 기능 요구 사항을 수신한 다음 여러 인프라 제공자, VNFP 및 SP에서 리소스 및 기능을 검색, 협상 및 집계하여 TSP에 서비스로 제공한다.
이 역할은 NFV 생태계의 모든 경우에 필요하지 않을 수 있으므로 완전성을 위해 모델에만 포함된다.
5) 최종 사용자(End User): 최종 사용자는 TSP가 제공하는 서비스의 최종 소비자이다.
경쟁 TSP의 여러 서비스가 존재하여 이들이 다양한 서비스 중에서 선택할 수 있다는 점을 제외하면 기존 인터넷의 최종 사용자와 유사한다. 최종 사용자는 다양한 서비스를 위해 여러 TSP에 연결할 수 있다.
마지막으로, <NFV 비즈니스 모델>의 화살표는 서로 다른 엔터티 간의 비즈니스 관계 또는 인터페이스를 나타낸다.
예를 들어, VNFP 및/또는 SP는 인터페이스 1과 2를 사용하여 각각 VNF 및 상용 서버를 TSP 및 인프라 제공자에 협상 및/또는 제공하는 반면, TSP는 브로커 및 사용자와의 상호 작용을 위해 인터페이스 3 및 4를 각각 사용한다.
3-2. 설계 고려 사항
NFV가 성숙해짐에 따라 가상화된 인프라에 NF를 배포하는 것만으로는 충분하지 않다는 점에 유의하는 것이 중요한다. 네트워크 사용자는 일반적으로 기본 네트워크의 복잡성(또는 기타)에 관심이 없다.
사용자에게 필요한 것은 네트워크가 필요할 때 필요한 애플리케이션에 액세스할 수 있도록 하는 것이다.
따라서 NFV는 아래에 식별된 주요 고려 사항을 충족하는 경우에만 TSP에 허용되는 솔루션이 된다.
1) 네트워크 아키텍처 및 성능: NFV 아키텍처가 허용되려면 전용 하드웨어에서 실행되는 기능에서 얻은 것과 유사한 성능을 달성할 수 있어야 한다.
이를 위해서는 스택의 모든 계층에서 발생할 수 있는 모든 잠재적인 병목 현상을 평가하고 완화해야 한다.
예를 들어, 동일한 서비스에 속하는 VNF가 서로 다른 VM에 배치된 경우 이 두 VM 사이에 연결이 있어야 하며, 이 연결은 지속적으로 집계된 고대역폭 네트워크 트래픽을 VNF에 제공해야 한다.
이를 위해서는 네트워크가 데이터 이동을 위한 DMA(직접 메모리 액세스) 같은 프로세서 오프로드 기술로 인해 고대역폭과 낮은 대기 시간을 제공하는 네트워크 인터페이스에 대한 연결을 활용할 수 있는 것이 중요할 수 있다.
또한 DPI(Deep Packet Inspection)와 같은 일부 VNF는 네트워크 및 컴퓨팅 집약적이며 성능 목표를 충족하려면 NFVI에서 제공하는 일종의 하드웨어 가속이 필요할 수 있다.
최근의 VNF 실행을 위해 DPDK(데이터 플레인 개발 키트) 활용의 의미를 연구했으며 소규모 및 대규모 패킷 처리에 대해 네이티브에 가까운(즉, 비가상화와 유사한) 성능을 달성할 수 있음을 보여주었다.
또한 FPGA(Field-Programmable Gate Array)도 VNF의 성능을 향상시키는 것으로 나타났다.
마지막으로 VNF에는 필요한 스토리지 및 계산 리소스만 할당되어야 한다. 그렇지 않으면 NFV 배포에 더 많은 리소스가 필요할 수 있으므로 NFV로 전환할 이유가 없다.
2) 보안 및 탄력성: NFV의 동적 특성으로 인해 보안 기술, 정책, 프로세스 및 관행이 유전적 구조에 내장되어야 한다. 특히 NFVI 설계에는 고려해야 할 두 가지 중요한 보안 위험이 있다.
(1) 서로 다른 가입자의 기능이나 서비스는 서로 보호/격리되어야 한다. 이는 한 기능/서비스의 실패나 보안 위반이 다른 기능/서비스에 영향을 미치지 않기 때문에 기능이 결함 및 공격에 대한 복원력을 갖도록 하는 데 도움이 된다.
(2) NFVI(물리적 및 가상 자원)는 제공되는 가입자 서비스로부터 보호되어야 한다. NFVI를 보호하는 한 가지 방법은 가상 환경 내에 내부 방화벽을 배포하는 것이다.
이를 통해 NFV MANO는 고객 네트워크에서 NFVI로 악성 트래픽을 허용하지 않고 VNF에 액세스할 수 있다.
마지막으로, 서비스 배포를 탄력적으로 만들기 위해서는 동일한 서비스를 구성하는 기능이 배포 중에 동일한 장애 또는 보안 도메인의 물리적 리소스에 의해 호스팅되지 않아야 할 수도 있다.
3) 신뢰성 및 가용성: IT 도메인에서는 몇 초 동안 지속되는 중단이 허용될 수 있고 일반적으로 사용자가 재시도를 시작하는 반면, 통신에서는 중단이 인식 가능한 수준(예: 밀리초 단위) 미만일 것이라는 기본 서비스 기대가 있다.
복구가 자동으로 수행된다. 또한 서비스 중단에 영향을 미치는 서비스는 특정 수의 사용자(예: 특정 지역)로 제한되어야 하며 네트워크 전체의 중단은 허용되지 않는다.
이러한 높은 신뢰성 및 가용성 요구 사항은 고객 기대일 뿐만 아니라 TSP가 중요한 국가 인프라의 일부로 간주되고 서비스 보증/비즈니스 연속성에 대한 각각의 법적 의무가 적용되므로 규제 요구 사항이기도 한다.
그러나 모든 기능이 동일한 복원력 요구 사항을 갖는 것은 아니다.
예를 들어 전화 통신은 일반적으로 가용성 요구 사항이 가장 높은 반면 다른 서비스(예: SMS(단문 메시징 서비스)의 경우 가용성 요구 사항이 더 낮을 수 있다.
따라서 NFV 프레임워크에서 지원해야 하는 여러 가용성 클래스가 정의될 수 있다.
다시 말하지만, 소프트웨어나 하드웨어 오류로부터 복구하기 위해 기능을 중복하여 배포할 수 있다.
4) 이질성 지원: NFV의 주요 판매 포인트는 독점 하드웨어 기반 서비스 제공으로 인한 장벽을 무너뜨리는 데 있다.
그러므로 개방성과 이질성이 NFV 성공의 핵심이 될 것이라는 점은 말할 필요도 없다.
공급업체별 하드웨어 및 플랫폼 기능을 갖춘 공급업체별 NFV 솔루션은 원래의 NFV 개념과 목적을 무너뜨리게 된다. 따라서 허용되는 NFV 플랫폼은 다양한 공급업체의 애플리케이션을 실행할 수 있는 개방형 공유 환경이어야 한다.
인프라 제공자는 자유롭게 하드웨어 선택 결정을 내리고, 하드웨어 공급업체를 변경하고, 이기종 하드웨어를 처리할 수 있어야 한다. 또한 이러한 플랫폼은 기본 네트워킹 기술(예: 광학, 무선, 센서 등)의 세부 사항으로부터 VNF를 보호할 수 있어야 한다.
마지막으로, 마찬가지로 중요한 것은 플랫폼이 제한 없이, 특정 기술 솔루션이 필요 없이 하나 이상의 인프라 도메인 위에 엔드투엔드 서비스를 생성할 수 있는 가능성을 허용해야 한다는 것이다.
단일 인프라 제공자 내의 가상화는 비용을 절감하는 반면, 공급자 간 NFV는 동일한 내부 소프트웨어 기능의 "제품화"를 가능하게 하여 수익 성장 기회를 제공한다.
예를 들어, 특정 TSP에 가입한 모바일 사용자가 다른 TSP의 서비스 지역으로 로밍하는 경우 사용자는 음성, 데이터 및 단순 메시징 서비스로 제한되어서는 안 된다.
NFV의 진정한 힘은 사용자가 현재 TSP에서 방화벽이나 보안 서비스를 선택할 수 있거나, 호스트 TSP와 자신이 담당하는 TSP의 다른 기능을 조합하여 사용할 수 있다면 실현될 수 있다.
5) 레거시 지원: 이전 버전과의 호환성은 모든 신기술에서 항상 높은 관심을 받는 문제이다. NFV도 예외는 아니다.
NFV로 전환하기로 결정한 특정 사업자의 경우에도 일부 사업자가 다른 사업자보다 더 빨리 전환한다는 사실은 말할 것도 없고 전환을 완료하는 데 시간이 걸릴 수 있다는 점을 고려하면 통신 산업에서는 더욱 중요하다.
따라서 일정 기간 동안 가상화된 기능과 함께 레거시 물리적 자산을 관리해야 할 수 있으므로 NFV로 전환하는 사업자에게는 물리적 및 가상 NF에 대한 지원이 중요하다.
이를 위해서는 레거시 서비스와 NFV 간의 격차를 줄이는 조정 전략이 필요할 수 있다. 사업자의 현재 네트워크 투자를 그대로 유지하면서 NFV로의 마이그레이션 경로를 유지하는 것이 중요하다.
인프라 제공자는 가상화된 네트워크 기능과 물리적 네트워크 기능이 모두 네트워크에서 동시에 작동하는 환경에서 작동할 수 있어야 한다.
6) 네트워크 확장성 및 자동화: NFV의 이점을 최대한 활용하려면 확장 가능하고 반응성이 뛰어난 네트워킹 솔루션이 필요하다.
따라서 위의 설계 고려 사항을 충족하는 동시에 NFV는 수백만 명의 가입자를 지원할 수 있도록 확장 가능해야 한다.
예를 들어, 최신 NFV 개념 증명은 VNF를 호스팅하기 위한 VM 배포를 기반으로 한다.
단일 VM이 특정 기능의 요구 사항을 충족하지 못할 수 있는 것처럼, NFV당 VM을 배포하는 것은 경제적이지 않다.
결과적으로 VM 공간이 너무 커지고 가상화 계층에서 확장성 문제가 발생할 수 있기 때문이다.
그러나 NFV는 모든 기능을 자동화할 수 있는 경우에만 확장된다.
따라서 프로세스의 자동화는 NFV의 성공에 가장 중요한다.
또한 동적 환경이 필요하기 때문에 필요에 따라 VNF를 배포 및 제거하고 변화하는 트래픽에 맞게 확장할 수 있어야 한다.
참 고 문 헌
- Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba, “Network Function Virtualization: State-of-the-Art and Research Challenges”, IEEE Communications Surveys & Tutorials, Vol. 18, No. 1, pp 236?262, 2016.
- B. Han, V. Gopalakrishnan, L. Ji, and S. Lee, “Network function virtualization: Challenges and opportunities for innovations,” Communications Magazine, IEEE, vol. 53, no. 2, pp. 90?97, Feb 2015.
- R. Guerzoni, “Network Functions Virtualisation: An Introduction, Benefits, Enablers, Challenges and Call for Action. Introductory white paper,” in SDN and OpenFlow World Congress, June 2012.
- ETSI Industry Specification Group (ISG) NFV, “ETSI GS NFV 002 V1.2.1: Network Functions Virtualisation (NFV); Architectural Framework,” 2014.
- ETSI, “European Telecommunications Standards Institute, Industry Specification Groups (ISG) - NFV,” 2015.
저작권 정책
K-ICT 클라우드혁신센터의 저작물인 『네트워크 기능 가상화(Network Function Virtualization: NFV)의 비즈니스 모델과 기술개발 동향』은 K-ICT 클라우드혁신센터에서 상명대학교 서광규 교수에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.