네트워크 성능의 제약 사항

1990년대 인터넷 초창기 시절에는 캠퍼스 전체에 연결된 56Kbps 인터넷을 통해 E-Mail이나 IRC(Internet Relay Chat)와 같은 텍스트 중심이었지만 컴퓨터를 통해 지구 반대편의 남아프리카 학생과 통신을 할 수 있다는 것이 마냥 신기하기만 했었다. 30여년이 지난 지금 기가(Giga)급 초고속 인터넷이 집집마다 연결되어 있고, IPTV를 통해 Netflix UHD 방송 시청하고 실시간 VR 프로그램으로 세계 곳곳의 유명 관광지를 실감있게 체험하는 시절이 되었다.

이렇듯 우리 일상 속의 많은 일들이 중간에 보이지 않는 수많은 컴퓨터 네트워크에 의해 처리되는데, 바로 응답이 오지 않아 컴퓨터 화면의 모래시계를 멍하게 바라보거나, 전송 작업이 종료될 때까지 커피를 마시거나 핸드폰을 열어 카톡이나 확인하고 있는 일들이 매일 일어난다.

그렇다면, 사용자들이 네트워크 어플리케이션이 느리다고 느끼는 이유는 무엇일까?

첫 번째는 중간의 네트워크 인프라 자체가 느린 환경일 수 있다. 실질적으로 사용자의 단말과 서버간 네트워크 환경의 차이에 따라 유효한 트래픽이 수십 배씩 차이가 난다.

두 번째는 어플리케이션이 사용자들의 다양한 네트워크 환경을 고려하지 않고 비효율적으로 개발된 경우이다. 개발 단계에서 파악하지 못한 성능 문제가 실제에서는 수백 배의 속도저하로 나타나는 경우가 많다.

세 번째는 1990년 중반 이후 거의 변경되지 않은 TCP/IP 커널의 구조적인 한계 때문이다. 극단적인 저지연이나 대용량 트래픽을 요구하는 경우 기존 TCP/IP 커널구조를 그대로 사용해서는 구현 자체가 불가능 경우이다.

영화 속 이야기지만, 아이언맨의 토니스타크가 수백Km/h로 날아다니면서 원격에 있는 AI비서인 자비스와 실시간으로 그 많은 트래픽을 지연도 없이 처리될 수 있는 “네트워크”를 구축할 수 있을까?
다가올 이러한 미래의 킬러앱을 위해서는 네트워크의 대용량 전송 및 저지연(low latency)은 필수 요소라고 할 수 있겠다. 그렇다면 이러한 네트워크 성능 문제를 극복하기 위해 어떻게 해 왔는지 살펴보기로 하자.

네트워크 성능의 개선 방안 및 사례

첫 번째로 전송 속도 및 응답 속도 개선에 대해서는 오래 전부터 많은 테크닉들이 개발되어 왔다.
병렬 전송(Parallel Transfer)에 의한 트래픽을 배수화하는 테크닉이 가장 일반적이다. 가령 10Mbps로 보내는 것을 5개를 동시에 보내 50Mbps로 증폭을 시키는 방법이다.
짧은 시간에 수백GB의 데이터를 보내야 하는 방송사, 유전체 연구 등 많은 곳에서 이런 기술이 적용된 솔루션을 사용하고 있다. 느린 환경 자체를 빠르게 변경하는 방법도 있다. CDN/ADN 업체를 통해서 서버(컨텐츠)의 기능을 단말과 가까운 곳(Edge서버)에 위치시키는 방법이다. 사용자들이 전 세계에 흩어져 있는 경우 분산된 서버들 중에 가장 가까운 위치의 서버와 연결되어 빠르게 서비스를 받게 된다.
전송할 데이터를 압축(Compression)하거나 중복되어 전송하는 것들을 미리 제거(Data De-duplication)하여 전송되는 데이터 자체를 경량화하여 보내는 방법이 있다. 이러한 기능의 WAN Optimizer 제품을 사용하여 WAN 트래픽을 70% 까지도 절약할 수 있다.
중복 트래픽을 제거하다 보면 데이터 특성상 중복이 많은 백업(DR)이나 메일 등은 70~90% 이상 절약되며 응답 속도도 20배이상 빨라지는 경우들도 많다.

두 번째는 어플리케이션 자체의 비효율성을 개선하는 방식이다.
초기에 설계된 프로토콜 자체가 Chatty하게 설계된 경우에는 느린 네트워크 환경에서는 체감하는 속도는 훨씬 느려 진다. 연결을 자주 맺고 끊는 경우도 초기 TCP 연결지연 때문에 늦어진다. 특히, 보안 연결(TLS, Transport Layer Security)에 대해서는 개발자가 LAN 환경에서 개발한 경우보다 실제 한국의 사용자가 미국 AWS에 있는 서버에 접속하는 환경으로 서비스가 이루어진다면 100 ~ 200배 정도는 느려 진다.
이를 개선하기 위해서는 프로토콜의 특성에 따라 다양한 솔루션 및 테크닉들이 나오고 있다. 구글이 HTTP 1.1 프로토콜을 개선하여 HTTP 2.0에 기여를 하였는데, 이때 많은 기술적인 진보가 있었다. SPDY나 Pagespeed 기술을 통해 브라우저와 Web Site 최적화에 유용한 많은 것들을 오픈소스로 제공하고 있다.

세 번째는 1990년대 이후 거의 변경되지 않은 TCP/IP 커널의 구조적인 한계점을 극복하는 것이다.
당시에는 네트워크 비용과 컴퓨터 비용은 매우 고가였기 때문에 1대의 컴퓨터를 통해 동시에 네트워크를 이용하는 수백 개의 어플리케이션 요청을 스케줄링 하여 처리하는 기능을 커널(Kernel)에 구현하는 게 효율적 이었다.

하지만, 지금은 개인 단말 위에서 프로야구 중계방송이나 VR 서비스를 하는 메인 어플리케이션이 동시에 1개만 화면에서 동작하면 된다. 이런 상황이면 굳이 비효율적인 시스템 커널을 통해서 전송할 필요가 있을까? 네트워크를 사용하는 프로그램에 최적화된 네트워크 전송을 구현하면 어떨까? 라는 물음에서 출발한 것인 사용자-레벨 네트워크 스택(user-space network stack)이다.

표준을 위해 필요한 TCP/IP 핵심 프로토콜 형태는 맞추지만 불필요한 스케줄링/큐잉 등을 자체 할당된 CPU/전용 버퍼로 대체하고, 커널에서 하던 많은 불필요한 기능들 (Firewall, QoS, Bridge, …)을 최소화하여 최상의 성능을 내도록 최적화하는 것이다.
일례로 고성능 NoSQL Database인 ScyllaDB의 경우 Intel의 DPDK를 활용하여 네트워크 성능을 개선하여 전체 Database의 성능을 극대화한다.
참고자료: http://www.scylladb.com/product/technology/networking/ Scylla DB 네트워킹

NUSE(Network Stack in Userspace), mTCP(Scalable User-level TCP Stack), mOS(middlebox OS) 등 다양한 사용자 레벨 네트워크 스택에 대한 연구가 활발하게 진행되고 있다.

미래 킬러앱을 위한 네트워크 성능의 한계 극복

다가 올 미래 사회는 도시 전체가 수 억 개의 사물인터넷 네트워킹에 의해 자율적으로 동작하게 될 것이다.
자율 주행차는 자동차들끼리 그리고 주변의 교통 시스템들과 1~2 ms 안에 서로 통신을 하면서 충돌을 방지하고 목적지까지 최적화하면서 주행할 것이다.
달리는 응급차 내에서 수술 로봇을 원격에 있는 의사가 아바타처럼 실시간으로 수술을 집도하는 세상이 올 것이다. 야구장이나 공연장에서 벌어지는 퍼포먼스를 수십만 명이 동시에 VR로 시청하며 현장에서 보는 것과 똑같이 보고 느낄 수 있는 세상이 올 것이다. 이러한 모든 것들이 가능하기 위해서는 현재 네트워크의 한계를 뛰어 넘어야 한다. 인간의 시각, 청각, 촉각 등의 처리에 있어 어색함이 느껴지지 않을 수준인 1-3 ms 수준의 저지연을 목표로 5G 모바일 네트워크가 곧 가능해 것이다.

하지만, 물리적인 네트워크가 빨라 졌다고 앞서 언급했던 미래의 킬러 앱이 저절로 구현되지는 않는다. 고객들의 단말에서 동작하는 어플리케이션과 그런 서비스를 제공하고자 하는 서버들 사이에는 아직도 수 많은 리거시 네트워킹 컴포넌트들이 존재하며 이들은 앞서 언급했던 수 많은 문제점들을 내포하고 있다. 이런 와일드한 환경에서 원하는 네트워크 성능을 내기 위해서는 앞서 언급했던 수 많은 네트워크 성능 개선 방법으로 최적화하는 설계 및 작업을 지속적으로 해야 할 것이다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.