손용락
리버베드코리아 부장
henryson@riverbed.com
분산 기업 환경은 규모와 형태에 있어 다양한 양상을 보인다. 하지만 기업 조직의 규모가 크든 작든, 네트워크가 단순하든 복잡하든, 분산 기업 환경에서는 해결해야 할 공통의 과제를 안고 있다. 왠(WAN)을 이용해 조직을 효율적으로 통합하는 환경을 구현하는 것이 바로 그것이다. 왠 성능에 영향을 미치는 다양한 요소와 WDS 기술의 개념에 대해 살펴보자. <편집자>

효율적 통합 환경 구축으로 왠 성능 극복
분산 기업 환경 위한 핵심 툴로 활용 … 기업 IT 인프라 근본적 개선 가능

소규모 기업 환경에서도 전세계 여러 지역을 연결하는 네트워크 구성을 종종 찾아 볼 수 있고, 대규모 기업 환경에서는 아무리 단순한 형태의 네트워크를 구성하는 경우에도 결코 단순하지 않은 작업이 수반된다. 또 복잡한 네트워크를 구성할 경우, 다양한 복제 기능과 연계 기능이 서로 얽힌 형태로 구성되기도 한다. 조직의 규모가 크든 작든, 네트워크가 단순하든 복잡하든, 이러한 분산 기업 환경에서는 왠(WAN)을 이용해 조직을 효율적으로 통합하는 환경 구현이 필요하다.
최근의 비즈니스 과제는 왠을 이용한 원격 사무실의 연결 문제와 긴밀한 연관성을 갖고 있다. 왠 환경의 비효율성으로 인해 원격 사무실에서 사용하는 애플리케이션 성능이 저하되거나 정보 관리가 제대로 이뤄지지 않는 경우를 쉽게 찾아 볼 수 있다. 이러한 문제는 생산성 저하와 매출 감소로 이어지기도 한다. 왠 리소스를 효율적으로 활용하지 못해 네트워크 대역폭을 과다한 수준으로 업그레이드하거나 원격 사무실의 IT 환경을 관리하는데 지나치게 많은 인력을 투자하는 경우도 있다.
그렇다면 이러한 문제의 근본적인 원인은 무엇일까? 분산 환경은 일반적으로 네트워크 자원이 풍부한 코어(core)와 상대적으로 빈약한 네트워크를 갖는 변경(fringe)으로 구성된다. 코어에는 대부분의 서버와 클라이언트, 그리고 네트워크 자원이 집중되는 반면 변경에는 상대적으로 빈약한 자원이 존재한다.
코어의 경우, 클라이언트와 서버간의 커뮤니케이션은 랜의 속도로 이뤄지지만, 변경에서는 왠의 속도로 처리된다. 왠의 대역폭은 일반적인 랜 대역폭의 1% 또는 그 이하 수준에 불과하고, 왠 환경에서 수반되는 네트워크 지연(latency)은 랜의 100배 또는 그 이상에 이르기도 한다.
결국 변경의 네트워크는 코어에 비해 1/100에 불과한 대역폭과 100배나 많은 지연을 갖기 때문에 성능 문제가 발생하는 것도 결코 놀랄 일이 아니다. 이러한 사실을 감안한다면 왠이 랜과 같은 수준의 성능을 내도록 함으로써 원격 사무실 환경의 업무 효율성을 개선하는 방안을 고려해 볼 필요가 있다.
과거에는 이와 같은 시도가 매우 제한적인 형태로만 이뤄졌다. 기본적으로 로컬 서버, 캐시, 그리고 압축 및 TCP 최적화를 위한 장비들을 조합하는 방법이 사용됐다.

광역 데이터 서비스 솔루션
왠이 랜과 같은 수준의 성능을 내기 위해서는 기본적으로 다음과 같은 두 가지 조건이 충족돼야 한다. 우선 왠 환경에서 심각한 성능 저하 현상을 보이는 애플리케이션 또는 프로토콜의 성능을 극적으로 개선할 수 있어야 한다. 두 번째로는 네트워크를 통해 전달되는 다양한 프로토콜을 효과적으로 처리할 수 있어야 한다.
왠 환경의 전반적인 성능을 향상시키기 위한 포괄적 솔루션을 광역 데이터 서비스(WDS ; Wide-area Data Servi-ces)라 부른다. 여기서 광역(Wide)이란 단순히 왠을 의미하는 것이 아니며, WDS가 광범위한 영역에 적용될 수 있음을, 그리고 다양한 유형의 성능 문제를 개선할 수 있다는 것을 의미한다. WDS는 비효율성의 문제를 해결하기 위한 방안일 뿐 아니라 다른 방법으로는 성취 불가능한 목표를 달성할 수 있게 하는 솔루션이다.
또 필요하다면 원격 사무실에 구축된 서버와 디바이스를 걷어 내고, 네트워크 서비스와 WDS만으로 원격 인프라를 구축하는 방법으로 비용을 대폭 절감하고 관리 수준 개선이 가능하다. 또한 로컬 서버가 구축되지 않은 원격 사무실에 WDS를 구현함으로써 생산성을 극적으로 향상시킬 수도 있다.

·파일 서버, 메일 서버, NAS(Network Attached Stora-ge), 백업 시스템 등 원격 사무실 환경에 분산된 형태로 존재하는 인프라스트럭처를 원격 사용자에게 영향을 주지 않으면서 통합한다.
·다른 지역, 심지어 다른 대륙에 위치한 대용량 파일을 마치 같은 건물 내에 있는 것처럼 공유할 수 있다.
·장거리 왠 연결을 통해 백업 및 데이터 복제 작업을 수행하고, 주어진 백업 윈도 안에서 작업을 완료한다.
·기존 왠 회선을 업그레이드하지 않고도 보다 많은 서비스를 이용할 수 있다.

성능병목과 왠 성능
성능병목의 문제에 대해 자세히 논의해 보자. 일반적으로 왠 연결은 랜 링크에 비해 낮은 대역폭과 높은 지연을 갖는다. 하지만 이러한 환경이 실제 애플리케이션 성능에 어떤 영향을 미치는 걸까? 성능병목은 크게 4가지 유형으로 나눠 볼 수 있다. 그 중 3가지는 네트워크 지연과, 나머지 한 가지는 대역폭과 관련돼 있다.
대역폭과 관련된 성능병목은 간단하게 설명할 수 있다. 어떤 애플리케이션도 사용 가능한 대역폭을 초과하는 속도로 데이터를 전송할 수 없다. 네트워크 지연에 관련된 3가지 성능병목은 그 개념이 그리 간단치 않으며, 주로 대역폭 문제가 존재하지 않는 환경에서 확인된다. 성능병목이 존재하는 경우, 애플리케이션은 사용 가능한 대역폭이 충분한 경우에도 효율적으로 대역폭을 이용하지 못하게 된다.

성능병목 #1
성능병목의 첫 번째 경우는 TCP 프로토콜의 엔드 투 엔드 검증(acknowledgement) 메커니즘에 그 원인이 있다. TCP는 윈도 사이즈(window size)를 통해 클라이언트-서버간에 한 번에 전송할 수 있는 패킷의 용량을 제한한다. 윈도가 가득 찬 경우, 수신자가 이미 전송된 데이터에 대한 확인 메시지를 보내오기 전까지 전송자는 더 이상의 데이터를 전송할 수 없다.
링크의 실제 처리속도는 TCP 프로토콜이 최대 윈도 사이즈의 데이터를 전송한 후 확인 메시지를 전달받는 속도를 결코 초과할 수 없다. 따라서 최대 윈도 사이즈가 지나치게 작게 설정된 경우 주어진 대역폭을 100% 활용할 수 없게 된다.
이론적으로 보면 이러한 성능 병목이 발생할 가능성은 낮다. TCP에서 높은 수치의 윈도 사이즈를 설정하기 위한 메커니즘이 잘 정의돼 있을 뿐 아니라 대부분의 운영체제가 이러한 메커니즘을 내부적으로 구현하고 있기 때문이다. 하지만 실제 환경에서 클라이언트 및 서버의 설정은 일반적으로 왠보다는 랜 환경에 적합하도록 설정돼 있으며, 왠의 지연율을 감안한 TCP 설정을 사용하는 경우는 찾아보기 어려운 것이 현실이다.
<그림 2>는 T1(1.544Mb/s) 링크 상에서, 64KB의 최대 윈도 사이즈를 갖는 TCP 연결의 처리속도(throughput)와 네트워크 지연의 관계를 분석한 결과다. 지연이 낮은 경우에는 대역폭이 100% 활용되지만, 40ms 이상의 지연이 발생하는 시점부터 지연병목의 효과가 대역폭 병목을 넘어서는 경향이 나타난다.
<그림 3>은 <그림 2>의 결과와 T3(45Mb/s) 링크에서의 테스트 결과를 비교한 그래프다. 이 그림에서 T1 환경의 그래프는 거의 일직선처럼 보인다. 하지만 놀라운 사실은 네트워크 지연이 증가함에 따라 T3 링크에서의 처리속도가 매우 급격하게 저하된다는 것이다. 지연율이 40ms를 넘어서는 시점 이후의 T3 처리속도는 T1과 비교해 전혀 나을 것이 없다.

성능병목 #2
두 번째 성능병목은 TCP의 슬로우-스타트(slow-start) 알고리즘과 혼잡-제어(congestion-control) 알고리즘이 원인이다. 앞서 설명한 첫 번째 성능병목은 최대 윈도 사이즈의 제한으로 인해 발생한다. 두 번째 성능병목은 TCP 프로토콜이 항상 최대 윈도 사이즈를 사용하는 것은 아니라는 사실이 원인이 된다.
TCP는 이전의 전송 작업이 성공적인 경우 윈도 사이즈를 점진적으로 증가시키는 반면 이전 전송 작업이 실패한 경우에는 윈도 사이즈를 급격하게 줄인다. 대역폭이 충분하고 네트워크 지연이 높은 환경에서 이러한 동작방식은 주어진 대역폭을 충분히 활용하지 못하게 만드는 결과를 초래한다. 하지만 이러한 현상은 일반적으로 LFN (Long Fat Network) 환경에서 주로 발생하며, T1 연결과 같은 환경에서는 문제가 되지 않는다.

성능병목 #3
세 번째 성능병목은 TCP의 상위에서 동작하는 애플리케이션 프로토콜에 의해 발생한다. 앞에서 TCP 프로토콜의 윈도 사이즈가 충분히 높게 설정되지 않은 경우, 대역폭이 아무리 충분해도 이를 효과적으로 활용할 수 없다고 설명한 바 있다. 마찬가지로 링크의 실제 처리속도는 애플리케이션 프로토콜이 최대 윈도 사이즈의 데이터를 전송한 후 ACK 메시지를 전달받는 속도를 결코 초과할 수 없다.
왠 환경을 감안해 설계된 애플리케이션 프로토콜(예 : HTTP, FTP)에서는 이러한 문제가 거의 발견되지 않는다. 하지만 랜 환경만을 가정해 설계된 프로토콜(예 : 마이크로소프트의 CIFS 파일 공유 프로토콜)에서 세 번째 성능병목으로 인해 성능이 심각하게 저하되는 경우가 발견되곤 한다.
<그림 4>는 T1 링크에서 CIFS (Common Internet File System)와 TCP 프로토콜을 테스트한 결과를 비교하고 있다. 두 프로토콜 모두 네트워크 지연이 증가함에 따라 처리속도가 급격하게 감소하는 경향을 보인다. 하지만 CIFS의 경우 그 변화가 더욱 두드러지게 나타남을 확인할 수 있다.
왠 환경에 최적화된 애플리케이션의 경우에는 TCP 프로토콜이 성능병목의 원인으로 작용할 가능성이 높다. 그러나 CIFS와 같은 프로토콜의 경우, TCP 프로토콜이 완벽하게 최적화돼 있고 대역폭이 아무리 충분하다 해도 네트워크 지연에 따른 성능 저하를 피할 수는 없다.

WDS : 광범위한 적용 범위
과거의 왠 성능 관련 기술은 <표 1>처럼 성능병목 현상의 일부 또는 몇 가지 프로토콜에 제한적으로만 적용 가능한 솔루션으로 개발됐다.
다양한 프로토콜과 성능병목 문제를 포괄적으로 관리할 수 있는 솔루션은 최근까지 존재하지 않았다. WDS는 과거 개별적으로 존재하던 기술들을 논리적으로 조합하고 일반화한 기술로 멀티-프로토콜, 멀티-애플리케이션 기술로 다양한 종류의 성능병목 현상에 대한 포괄적인 대처 방안을 제공한다.

·고성능, 디스크 기반 데이터 축약
·TCP 최적화
·애플리케이션/프로토콜 최적화
·캐싱

리버베드와 WDS
리버베드는 왠 환경의 애플리케이션 성능 문제 해결을 목표로 설립됐다. 애플리케이션에 독립적이고, 클라이언트 및 서버 관점에서 투명하게 동작하고, 왠 환경에 상존하는 네트워크 지연 문제를 극복할 수 있는 솔루션을 개발하는 것이 리버베드가 설정한 지상 과제였던 것이다.
지난 2004년 5월 발표된 리버베드의 스틸헤드(Steel-head) 어플라이언스는 일부 애플리케이션의 성능을 최대 100배까지 개선할 수 있음이 입증됐고, 왠 트래픽이 60~95%까지 감소하는 결과가 나타났다. 더불어 기존 캐시 기반 아키텍처에서 지적되던 문제점이 존재하지 않음이 확인되며 포괄적인 WDS 솔루션으로 인정받고 있다.

리버베드 WDS 아키텍처
리버베드의 스틸헤드 어플라이언스 아키텍처에는 다른 접근방식과 차별화되는 몇 가지 핵심적인 요소가 존재한다.

·디스크 기반 시스템 : 최초 설계 단계에서부터 디스크 아키텍처를 기반으로 개발됐다. 이것은 2002년 당시의 일반적인 TCP 프로세싱 시스템 환경을 감안했을 때 대담한 선택이었다. 디스크에 네트워크 트래픽을 저장하는 경우, 반복되는 데이터 패턴을 찾아내는 기능을 대폭적으로 향상시킬 수 있다.
심지어 며칠 전 또는 수개월 전에 사용된 데이터를 재활용하는 것도 가능하다. RAM 기반으로 구현된 디바이스는 트래픽 레벨 또는 파일 크기가 큰 경우 버퍼 공간의 부족으로 인해 성능이 저하될 가능성이 높다.

·애플리케이션 독립적 기반 환경 : 캐시 솔루션과 달리 애플리케이션 독립적인 2가지 기술 기반으로 구현된다. SDR(Scalable Data Referencing)과 VWE(Virtual Window Expansion)은 중복적인 TCP 트래픽과 TCP 라운드 트립 요소를 제거해 준다. 따라서 TCP 기반으로 실행되는 애플리케이션에 적용하는 경우, 대폭적인 왠 트래픽 감소와 처리속도의 증가를 확인할 수 있다.
더불어 기존 데이터 압축 어플라이언스와 달리 리버베드의 TCP 최적화 기능은 TCP 기반 애플리케이션에 수반되는 높은 지연으로 인한 성능 문제를 해결할 수 있고, SDR과 함께 조합해 사용하는 경우 로터스 노츠, FTP, 백업, 데이터 복제, 웹 기반 애플리케이션 등의 성능을 극적으로 개선하는 것이 가능하다.

·애플리케이션 지연 최적화 : 애플리케이션 독립적인 기능을 기반으로 HTTP, FTP 등의 개별 애플리케이션을 위한 최적화 기능을 구현한다. 애플리케이션 최적화 기능 중에서도 가장 중요한 것이 바로 트랜잭션 예측이라 불리는 지연 최적화 기능으로 스틸헤드는 CIFS와 MAPI를 위한 트랜잭션 예측 모듈을 탑재하고 있으며, 향후 다양한 모듈이 추가로 구현될 예정이다.

WDS 적용 범위
WDS는 다양한 형태의 엔터프라이즈 네트워크에 적용할 수 있다. 오늘날 왠은 분산 기업 환경의 핵심적인 인프라스트럭처 구성요소로 활용되고 있으며, 핵심 비즈니스 프로세스에 지대한 영향을 미치는 한편 기업의 목표 달성에 심각한 장애 요소로 부각되기도 한다. WDS 솔루션이 제공하는 혜택은 다음과 같다.

·애플리케이션 가속화 : 많은 비즈니스 프로세스가 왠 환경을 기반으로 하는 애플리케이션을 통해 구현되고 있다. 사용되는 애플리케이션은 윈도 파일 공유와 같은 단순한 기능에서 매우 복잡한 커스텀 애플리케이션에 이르기까지 다양하다. 어떠한 경우든 왠이 중간에 자리잡고 있는 경우 애플리케이션이 기대한 만큼의 성능을 보여주는 경우는 매우 드물다.
WDS 솔루션은 윈도, 익스체인지, FTP, 백업 등의 애플리케이션 실행속도를 최대 100배 수준으로 향상시켜 준다. 사용자는 위치에 관계없이 랜과 동등한 수준의 성능을 경험할 수 있다.

·원격 사무실의 데이터 백업 : 원격 사무실의 데이터를 백업하는 과정에서 처리해야 하는 데이터의 양은 실제로 그리 많지는 않다. 하지만 낮은 대역폭과 높은 지연율을 갖는 왠 링크에서 백업 데이터를 전송하는 경우, 처리속도가 급격하게 저하되고 주어진 백업 윈도 내에서 작업을 완료하지 못하는 경우가 자주 발생한다.
이러한 이유 때문에 대부분의 IT 관리자들은 각 원격 사무실에 테이프 오토로더와 같은 백업 디바이스를 개별적으로 설치하는 방법을 선택하곤 한다. 그러나 개별 사무실별로 설치된 백업 환경에서 발생되는 성능 문제, 디바이스 장애 등에 대처하기란 쉽지 않다. 따라서 WDS 솔루션은 왠 링크를 통한 백업에 소요되는 시간을 극적으로 단축할 수 있을 뿐 아니라 전혀 새로운 형태의 데이터 보호 환경을 구현할 수 있다.

·데이터 복제 : 데이터 복제 기술은 재해 복구 또는 데이터 익스포트(export) 등의 용도로 활용되고 있다. WDS 솔루션은 데이터 복제 프로세스의 실행 속도를 10배 이상 향상시키는 효과를 제공한다. 스냅미러(SnapMirror)처럼 이미 성능적으로 최적화된 솔루션을 이용하는 경우에도 왠 링크를 통해 전달되는 중복적인 트래픽을 제거하고 TCP 계층을 최적화함으로써 극적인 성능 개선을 가능하게 한다.

·사이트 통합 : 데이터센터 내부의 통합을 위한 툴은 다양하게 존재하지만 최근까지도 원격 사무실의 인프라스트럭처를 데이터센터와 통합하기 위한 솔루션은 찾아보기 어려웠다.
WDS 솔루션은 파일 서버, 이메일 서버, NAS, 로컬 테이프 백업 등의 인프라스트럭처 통합을 용이하게 한다.
따라서 기업은 각각의 인프라스트럭처 컴포넌트를 순차적으로 데이터센터 내부로 마이그레이션하거나 모든 인프라를 일괄적으로 통합해 서버리스(serverless) 오피스 환경을 구현할 수 있다.

·인소싱(In-sourcing) : 분산 환경을 관리하다 보면 어떤 사이트에서는 자원이 심하게 부족한 반면 또 다른 사이트에서는 자원이 남아도는 경우를 종종 발견하게 된다. WDS 솔루션은 보다 유연한 정보/애플리케이션 공유 환경을 구현하고, 외부 컨설턴트 또는 기술지원 인력을 사용하는 대신 내부의 유휴 리소스를 효과적으로 활용할 수 있는 방안을 제시한다. 이러한 인소싱을 통해 비용을 절감하고 자원의 균등한 배분을 실현하는 것이 가능하다.

·대역폭 최적화 : 단순히 왠 회선의 업그레이드 시기를 늦추는 것을 목적으로 하는 경우에도 WDS 어플라이언스가 도움이 될 수 있다. WDS 솔루션은 왠 트래픽의 60~80%를 경감하는 효과를 제공, 기존 왠 회선을 통해 더 많은 사용자에게 서비스를 제공하고, VoIP 등과 같은 새로운 애플리케이션을 추가하고, 왠 업그레이드 비용을 절감할 수 있다.