note

응답하라 2000년

Network Processor Era

Intel에서 요즘 한창 주가를 올리고 있는 SDN, NFV 관련해서 어떻게 하든 입자를 굳히려고 노력하고 있다. Intel은 2000년 초반 Digital Semiconductor라는 회사로부터 인수한 기술을 이용해서 IXP라는 Network Processor를 앞세워 네트웍 시장에 진입하려고 노력했다1. 당시에는 그 전까지 있던 Asic 기반에서 벗어나 programmable processor를 이용한 네트웍 장비를 만드는 것이 유행이었는데 당시만 해도 괜찮았던 Motolora도 C-port라고 불리는 Network Processor를 판매하고 있었다.2 C-port는 C5, C3e등의 제품이 있었는데 당시에 C를 이용해서 프로그래밍할 수 있는 장점을 가지고 있었다. 하지만 몇 년 후에 사업을 접어버렸다. PowerPC 계열의 시장 점유율 확대 실패가 원인이었던 걸로 기억한다. 기억에는 이렇게 Network Processor 시장을 정리하면서 핸드폰 사업과 나머지 네트웍 사업 그리고 Processor 사업을 분리한 듯.

아무튼 Intel IXP는 1200, 2400 계열을 거쳐 2800, 2350, 2805까지 만들고 역시 사업을 접어버렸다. 1200, 2400,280x 계열은 주로 micro-code로 코드를 작성했다. 나중에 나오고 상대적으로 낮은 성능을 보여주는 IXP2300 계열은 고객 대상 자체가 달라 microC로 작성했다. microC는 말 그대로 C 문법을 사용하는데 Network Processor상황에 맞게 일부 제약을 가진 언어였다.

인생은 쓰다

그 전까지 desktop 시장에서의 절대적인 우위를 바탕으로 새로운 시장인 Network 시장으로 시장 지배력을 확대하려던 Intel의 노력은 아무튼 2007년 IXP를 Netronome에 매각하면서 실패로 끝났다. 3

그 후에 Intel은 handheld나, HPC등 desktop 외의 시장에 들어가려고 지속적으로 노력했지만 딱히 성공한 것은 없다. nVidia와 경쟁하기 위해 manycore인 Phi processor도 만들고 있지만 시장에서의 반응은 그닥인 듯.

하지만 주로 Arm processor를 사용하는 모바일 시장의 확대로 줄어드는 desktop 시장과 달리 Intel에게 유리한 시장 변화는 바로 서버 시장이 커진다는 점이었다. 종종 외계인을 잡아서 일을 시켰다고 하는 Xeon 기반의 고성능 x86 CPU 시장은 어느새 x86 경쟁업체였던 AMD와는 비교조차 할 수 없을 정도로 독보적인 위치가 되었다. 모바일 단말기가 늘어나는 만큼 그 단말기를 이용하는 서비스를 제공하는 서버들은 대부분 Intel 서버를 이용하고 있다.

절치부심 – I’ll be back

Intel은 IXP를 이용한 network 시장 진출에 대한 아쉬움을 그대로 삭힐 수 없었는지 다시 시장 진출을 노린다. 전문이 아닌 다른 업체를 인수하기 보다는 자기가 가장 잘하고 강점을 갖는 Xeon Processor를 기반으로.
시장의 대세는 Intel CPU + Linux 조합인데, 서버 쪽은 Linux가 제공하는 네트웍 기능을 그대로 이용하고 그 위에 Java 등을 이용해 서버 앱을 만들어도 충분(?)하지만 Network 시장은 그 정도의 성능으로는 어림도 없는 곳이었다. 그래서 Intel은 Linux를 아예 걷어내거나(Bare-metal) 혹은 Linux app을 동작하지만 성능 제약의 근본적인 원인이 되는 interrupt 기반/General networking stack/Memory copy between kernel and user space를 회피한 방법을 사용한 네트웍 S/W 개발용 framework을 내놓는다. 이게 Intel DPDK(Data Plane Development Kit)이다.

시장의 변화 – 천우신조

때마침 최근 시장은 서버 + 가상화 + COTS(Commodity Off The Shelf)로 점점 진화하고 있는 상황이다. 덕분에 이 3가지 측면에서 모두 강점을 갖고 있는 Intel은 Desktop 시장의 폭발적인 성장 이래 처음으로 호기를 맞이한다. 통신 시장에서 업체가 만드는 전용 하드웨어를 기반으로 하는 제품을 사야하고, 새로운 기능이 추가되거나, 제품의 모델이 바뀔 때마다 제품의 교체 사이클을 제조업체에 의존해야 했던 통신 서비스 업체는 상용 H/W를 사용하고, (부가적인 H/W accelerator를 이용하는) S/W만으로 구현되는 장비를 갈구하게 된다. 그 결과 NFV(Network Function Virtualization)이라는 규격을 만들게 된다. NFV의 핵심은 장비를 이용한 혁신의 주도권을 장비 업체가 아니라 통신 업체가 완전히 가져가겠다는 의도이고, 아울러 상용 하드웨어를 사용하여 장비 업체에 대한 의존성을 줄여 비용도 줄이겠다는 의도에서 시작되었다. 장비 업체 입장에서는 아쉽지만 물건을 구매하는 쪽인 갑들이 모여 단결하여 시장을 의도적으로 몰아가고 있어 장비 업체로써는 저항하기가 쉽지 않다. 거기에 장비 업체에서도 선두 업체들이 시장의 변화를 인정하고, 새로운 시장을 선점하기 위해 노력하기에 2위, 3위 업체 등은 쉽게 대세를 거스를 수 없는 상황이다. 거기에 대세를 거스른 다는 것은 결국 제품을 구매하는 통신 업체의 의도를 거스르겠다는 것이므로, 더더욱 쉽지 않은 상황이다.

이렇게 통신 업체가 열심히 NFV를 미는 이유는 앞에서 말한 대로 장비 업체로부터의 주도권을 더욱 가져오겠다는 의도이다. 물론 통신업체가 돈을 지불하는 입장이므로 ‘갑’의 위치에 있는 것은 사실이지만, 어떤 면에서는 통신 업체가 요구하는 혁신적인 기능이 장비 업체의 이익과 대치되는 경우 쉽게 원하는 혁신을 얻기 어려운 점도 있을 것이다. 큰 시장 점유율을 가지는 장비 업체일 수록 그 만큼 자신의 입장을 주장하는 경우도 있을 테니.

그러나 앞에서 말한 것과 같이 장비 업체가 아닌 일반 서버 기반 위에 S/W만으로 원하는 제품을 만들 수 있다면 극단적으로 서버는 HP, Dell 등의 업체로부터 공급받고, S/W는 시장 진출을 엿보는 작은 업체로부터 공급받을 수 있는 것이다. 그것이 통신 업체가 원하는 혁신이다.

Intel로써는 이런 시장의 변화를 예측(?)하고 준비한 덕에 자사의 x86 processor를 이용하면서 고속 성능을 제공할 수 있는 DPDK를 핵심 전략으로 삼고 있다.

NFV – 새로운 기회

NFV에서는 기존 Network Function들을 VNF(Virtual NF)로 부르고, 모두 VM(Virtual Machine)에서 동작하는 것으로 정의한다. 이때 필요한 기능 중 하나가 VM과 서버 외부 혹은 VM간의 고속 switching이다. ‘고속’이란 말만 제외하면 이미 Linux 커널에 포함되어 있는 KVM에서 제공하는 vSwitch 가 존재한다. vSwitch는 Virtual Switch로 서버 내에서 S/W로 구현되는 switch다. OVS(Open VSwitch)가 많이 사용되는 커널내에서 동작하고 기본적으로 발생하는 VM – Host간 오버헤드 덕에 낮은 성능을 보인다. NFV를 통해 이미 다진 서버 시장과 네트웍 시장에서의 선점을 원하는 Intel로써는 해결해야 할 문제점이다. (그렇다고 다른 Processor가 대안을 가지고 있는 것은 아니다. 모바일 단말기에서의 절대적인 시장 점유율을 기반으로 서버 시장까지 진출하려는 ARM processor 역시 근본적으로는 동일한 제약을 갖는다)
이를 해결하기 위해 Intel은 직접 자원을 투자하여 OVS를 이용하여 성능을 높이는 작업을 진행한다. 커널내에서 동작하는 OVS의 switch 기능을 DPDK 기반으로 구현하여 고속의 스위칭 기능을 제공하는 것이다. S/W 기반이기 하지만 다양한 기능을 제공하기 위해 복잡하게 만들어진 Linux Networking stack과 달리 필요한 일만 하도록 만들어진 그 결과 많은 제약을 갖지만 높은 성능을 제공하는 DPDK-OVS가 만들어진 것이다.

앞에서 말한 VM-Host간의 통신에 성능 저하를 유발하는 여러가지를 해결하기 위해 그리고 VM-Host Kernel Switch가 아니라 VM – Host user level switch(DPDK로 구현된 DPDK-OVS 는 user-space에서 동작)간 통신으로 인해 추가로 발생하는 overhead를 줄이기 위해 IVSHMEM(Inter-VM Share Memory)를 사용한다.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s