|
|
|
|
왠 최적화 어플라이언스 |
| 더 크게 ‘No’ … 더 똑똑하게 ‘Yes’
압축·캐싱·가속 등 기술혼합 … ‘보안·데이터 관리 계획’ 수반돼야 |
 |
2007년 08월 21일 00:00:00 |
|
 |
|
|
너무 오랜 세월 동안 IT 그룹에서는 바로 바닥나는 대역폭을 계속 추가시켜야 했다. 포레스터리서치에 따르면 데이터 서비스는 이미 기업 텔레콤 예산의 52%를 소모시키고 있다. 문제는 용량 추가도 대기시간이나 애플리케이션 행동 같은 한계 요소들이 개입되기 시작하면 소용이 없다는 사실이다. 업체들이 부하조절 기술이나 AFE 같은 해결책을 제시하고 있지만 모두 저마다의 문제를 안고 있다. 그렇다면 방법은? 바로 왠 최적화 기술을 이용해 파이프를 더 크게가 아니라 더 똑똑하게 만드는 것이다.
회사의 IT 조직에서 관리하고 있는 지사들이 모두 캐리어 이더넷(Carrier Ethernet)과 같은 혁신적인 왠 서비스를 향유하고 있다면 좋겠지만 그렇지 못할 가능성이 크다. 당신은 가격 인상폭이 큰 조립 라인의 광역 서비스로 버텨 나가야한다. 그러는 동안에도 왠을 가로지르는 데이터의 양은 급격히 증가하고 있으며, 속도가 느린 경우도 너무 많다. ERP 시스템에 수백만 달러를 투자한다고 해도 직원들이 응답시간이 느리다는 이유로 이것을 사용하지 않는다면 무용지물이다.
너무 오랜 세월 동안 IT 그룹에서는 금새 바닥나는 대역폭을 계속 추가시켜야 했다. 포레스터리서치에 따르면 데이터 서비스는 이미 기업 통신 예산의 52%를 소모시키고 있다. 문제는 용량 추가도 대기시간이나 애플리케이션 행동 같은 한계 요소들이 개입되기 시작하면 소용이 없다는 사실이다. 업체들은 부하조절 기술, AFE(Application Front Ends), 콘텐츠 배포, WAFS(Wide Area File Systems) 및 캐싱 등을 해결책으로 제시하고 있지만, 모두가 저마다의 문제를 안고 있다.
왠 접속에서 랜 활용도 높여
그렇다면 해결책은 무엇일까? 바로 왠 최적화 기술을 이용해 파이프를 더 크게가 아니고 더 똑똑하게 만드는 것이다. 이것은 WAFS에서 개발된 것으로, TCP 및 애플리케이션 최적화, 압축 및 데이터 축소(data reduction) 같은 방식을 혼합, 적용시켰다. 단순히 파일 지원만이 아니라, 모든 TCP 흐름에 걸쳐 회사 데이터로 만든 정말 큰 사전에서의 압축을 생각하면 된다.
우리가 테스트한 제품들은 무기력한 T1을 힘이 넘쳐 보이는 10Mbps 왠처럼 만들거나, T3를 소방 호스 같은 OC-3로 바꿔줄 수 있는 것들이다. 회사 전체에 중대한 발표를 하고 싶은가? 원격 어플라이언스에 동영상을 미리 포지셔닝한 다음, 약속된 시간에 액세스를 허용하라. 어떤 최적화기(optimizer)들은 심지어 UDP(User Datagram Protocol) 패칫이 약간 더 빠르게 이동하도록 도와줄 수도 있다. 그리고 이 기술의 혜택을 보는 것은 지사뿐이 아니다. 가정 사용자나 이동 근로자들도 클라이언트만 설치돼 있다면 진보를 볼 수 있다.
물론 여기에도 조심해야 할 것들은 있다. VoIP나 라이브 동영상처럼 왠 트래픽이 대부분 랜덤한 비트일 경우에는 왠 최적화가 문제가 되지는 않겠지만 그렇다고 큰 도움이 되지도 않는다. 게다가 민감한 데이터를 포함하고 있는 전혀 다른 어플라이언스의 보안 문제도 처리해야 한다. 암호화된 네트워크 트래픽은 압축이 불가능하고, 사용자마다, 그리고 접속마다 바뀌기 때문에 최적화가 될 수 없다. 그리고 우리가 테스트한 왠 옵티마이저들은 완전한 기능을 발휘하기 위해서는 시간과 튜닝을 필요로 했다.
하지만 본지 시러큐스 대학 리얼월드 랩에서 이번에 평가한 네 가지 시스템, 즉 블루코트시스템즈(Blue Coat Systems) SC 어플라이언스, 시스코시스템즈의 와이드 에어리어 애플리케이션 서비시즈(Wide Area Application Services), 시트릭스시스템즈(Citrix Systems)의 완스케일러(WANScaler), 그리고 실버피크시스템즈(Silver Peak Systems)의 NX 어플라이언스는 모두 추천할 만했다. 이들은 매우 잘 수행됐으며, 최적화되거나 되지 않은 트래픽용의 대기시간에 부정적인 영향을 미치지 않으면서 대역폭 압박을 받는 왠 접속에서 랜의 활용도를 높였다.
8개월이 손익분기점
대부분의 사람들은 회사의 어느 한 곳보다도 집에 더 많은 대역폭을 두고 있을 것이다. ISP들이 소비자에게 대역폭 판매를 강력히 추진하고 있는데, 그 이유는 인프라가 이미 존재해 있고 이것이 모두 베스트 에포트(best effort)기 때문이다.
한편, 기업의 대역폭 필요조건은 높아지고 있다. 회사에서 6개월 이내에 왠을 통해 약 150Mbps, 하나의 OC-3 정도를 전송할 필요가 있다고 하자. 그런데 지금 있는 것은 T3다. 왠 옵티마이저를 파일로팅한 후 평균적으로 이 제품이 왠 용량을 150Mbps 이상으로 늘릴 수 있다는 사실을 알게 됐다. T3를 OC-3로 늘리는 데 연간 13만7천달러 이상의 비용이 든다면, 그리고 필요한 용량을 지원하는 한 쌍의 왠 최적화기가 9만달러 아래라면, 더 이상 생각할 필요도 없는 일이다. 손익분기점은 8개월이 될 것이며, 3년간의 ROI는 298%다.
여기서 분명히 우리는 많은 것을 전제로 했다. 즉 최적화는 평균 4회 이뤄지며, 트래픽 양과 믹스는 시간이 지나도 같은 수준으로 유지된다. 그리고 운영비는 관리 가능한 수준이다. 하지만 그렇다고 하더라도 단 하나의 T3라도 추가하는 데 드는 비용을 생각한다면 왠 최적화를 마다하겠다는 말은 하지 못할 것이다.
문제는 ‘속도’
클라이언트는 원격 사용자가 집에서 일을 하든 커피 숍이든 호텔이든 관계없이 왠 최적화의 혜택을 받을 수 있게 해준다. 여기서는 용량이 큰 문제가 되지는 않는다. 오늘날의 광대역 회선은 다 채우기가 엄청나게 힘이 들기 때문이다.
병목은 채티(chatty) 애플리케이션 프로토콜에 의해 만들어지는 네트워크 지연이다. RTT(Round-Trip Time)가 150ms인 왠 접속에서는 대역폭에 관계없이 원격으로 766KB 엑셀 스프레드시트를 여는 데 자그마치 40초가 걸리며, 2천개 이상의 패킷이 전송된다. CIFS(Common Internet File System)를 최적화해 패킷의 라운드 트립을 줄이면 속도는 훨씬 빨라질 수 있다.
마이크로소프트가 롱혼을 내놓을 때까지 기다렸다가 이것을 비스타와 나란히 배치할 수도 있을 것이다. TCP 스택 최적화와 CIFS에 추가되는 최적화는 둘 다 패킷 RTT를 줄여줄 것이다. 하지만 MAPI 같이 다른 채티 랜 프로토콜들이 여전히 속도 저하를 가져올 것이다. 블루코트와 스탬피드 같은 업체들이 현재 왠 최적화 클라이언트를 출시하고 있으며, 리버베드테크놀로지는 클라이언트를 제공할 의향이 있음을 발표했다.
블루코트의 경우 최초의 클라이언트 버전은 TCP 및 애플리케이션 레벨 프로토콜 최적화, 파일 캐싱 및 압축을 수행하지만, 데이터 축소는 다음 버전까지 기다려야 할 것 같다. 일단 설치가 되면 클라이언트는 사용 가능한 디스크 용량을 이용해 네트워크에서 전송되는 파일뿐만 아니라, 디렉토리 리스팅으로부터 메타데이터를 캐싱한다. 이러한 로컬 캐시는 앞뒤로 오가는 패킷 수를 줄임으로써 파일 브라우징 속도를 높여 준다.
마법의 양념
왠 최적화의 마술은 거의 전적으로 회선 상의 비트 수를 줄임으로써 이뤄진다. 그 비결은 왠에 있는 TCP 트래픽을 최적화하는 것이며, 이는 주로 수신측 창을 조정하고, 송신자 측의 정체에 보다 적극적으로 반응하는 것을 통해 가능하다. 익스체인지 MAIP나 SMB/CIFS 파일 전송기 같은 엔터프라이즈 프로토콜이나 애플리케이션은 주로 오브젝트 캐싱에 의해, 그리고 핑퐁 효과를 줄임으로써 최적화된다.
그러나 가장 큰 수확은 데이터 축소를 통해 얻을 수 있다. 이 방식은 압축과 매우 유사하지만 보다 규모가 크고 맞춤화된 사전들을 이용한다. 압축 어플라이언스는 하나의 고정된 비트 블록을 보다 큰 블록을 나타내는 작은 비트 세트로 대체한다. 보통 압축만으로도 파일 종류에 따라 회선 상의 비트 수를 2~4배까지 줄일 수 있다. 예를 들어 텍스트 파일과 비트맵 이미지는 압축률이 높은 반면, 비디오나 바이너리 파일은 훨씬 낮다. 그 이유는 비디오나 오디오 같은 포맷은 반복성이 없으며, 압축 알고리즘의 사전 크기가 비교적 작기 때문이다.
데이터 축소에서 사전은 회사의 데이터로부터 만들어진다. 그 크기는 수백, 혹은 수천 기가바이트가 될 수 있으며, 회사의 이용 패턴이 변하는 데 따라 달라진다. 데이터 축소는 많은 조직에서, 왠을 통해 전달되는 데이터가 반복성이 있다는 사실을 이용한다. 즉 한 사람 이상이 같은 파일을 읽거나 쓰게 되며, 아마도 누군가는 하나의 파일을 읽고, 몇 가지 변경을 한 다음, 이것을 대부분 바뀌지 않은 왠을 통해 다시 보내기도 할 것이다.
왠 옵티마이저에는 사전이 없다. 파일이 왠을 통해 처음 풀링(pulling)이 되면, 두 개의 옵티마이저가 파일을 독립적으로 분석해 동일한 블록 인덱스를 만든다. 그 다음 번에 파일이 풀링이 되면, 파일 서버에 가장 가까이 있는 어플라이언스는 이것을 검토해서 특정 블록과 관련된 인덱스만을 보낸다. 클라이언트에 가장 가까운 어플라이언스는 파일을 재구성한 다음, 이것을 사용자에게 전송한다. 시간 면에서 어플라이언스는 속도 이점을 갖게 된다. 왠 옵티마이저를 통과하는 데이터가 많아짐에 따라, 하나의 파일 블록이 다른 데이터 전송장치를 최적화할 수 있도록 사전이 만들어지기 때문이다.
이것을 캐시라고 생각하면 착각이다. 캐시는 파일 카피를 단일 객체로 로컬에서 저장하는 방식이다. 그 다음 사용자가 파일을 요청할 때 캐시는 바뀐 부분을 확인하고, 달라진 게 없을 경우 파일을 엔드 유저에게 보낸다. 파일이 편집이 되고 왠을 거쳐 파일 서버에 저장됐을 경우에는 전체 파일이 전송이 된다. 로컬 읽기는 더 빨라지며, 쓰기는 그렇지 않다.
데이터 축소 엔진도 또한 왠을 거쳐 전체 파일을 이동시키지만, 모든 비트를 보내는 게 아니라 대표(representation) 파일 블록만이 전송된다. 따라서 편집된 파일이 원격 파일 서버에 저장될 때는 변경된 블록만 전달하면 되고, 나머지 파일은 대표로서 전송된다. 원격 어플라이언스는 이것을 랜에 내놓기 이전에 인덱스를 실제 데이터로 대체시킴으로써 파일을 복원한다.
왠 옵티마이저에는 캐시와 구분되는 세 가지 큰 특성이 있다. 첫째, 클라이언트와 서버간 접속이 유지보수된다. 어떤 사용자에게 읽기나 쓰기 허가가 없으면, 그는 읽기나 쓰기를 할 수 없을 것이다. 마찬가지로, 파일이 잠기면 파일은 열릴 수가 없다.
나아가 데이터 블록은 비트 패턴이 같에 유지되는 한 파일 포맷과 관계없이 교체될 수 있다. 예를 들어 한 회사의 로고가 HTTP, 이메일 첨부파일이나 파일에서 같은 비트 패턴을 갖고 있으면 왠에 있는 데이터가 결과적으로 줄어들게 된다.
마지막으로 데이터는 파일이 아니라 블록으로 저장이 된다. 변경된 파일은 변경된 블록이 인덱싱돼 있겠지만, 원래의 블록도 여전히 남아 있다. 파일이 다시 바뀌면 최적화가 그 상태로 유지가 된다.
네트워크에 미치는 영향
본지 독자 설문조사의 응답자들 가운데 40% 가까이는 패킷을 변경하거나 캡슐화(encapsulating)하는 게 협상을 망치는 원인이라고 답했다. 우리의 생각은, 네트워크의 투명성(이 경우에는 TCP/UDP/IP 헤더를 그대로 두는 것)은 경계 라우터(border router)에서 트래픽 쉐이핑(traffic shaping)을 사용하느냐, 아니면 ACL을 사용하느냐에 따라 생사를 가늠하는 문제가 될 수도 있고 되지 않을 수도 있다는 것이다. 패킷 헤더를 바꾸지 않는 제품을 선호하는 것은 우리도 마찬가지다. 다만 이것이 큰 범죄를 저지르는 일이라기보다는 선택에 대한 책임을 져야 하는 일이라는 얘기다.
네트워크 투명성은 라우터나 방화벽 같은 업스트림 장비가 헤더 정보를 기반으로 패킷을 처리할 때만 중요하다. 예를 들어 경계 라우터가 QoS 마크를 적용시키거나, 혹은 기존의 QoS 마킹을 패킷에서 시행할 경우 이 정보는 반드시 볼 수 있게 돼 있어야 하는데, 이는 액세스 제어 결정이 소스 및 목적지 어드레스와 포트 번호를 기반으로 이뤄지는 방화벽에서와 마찬가지다. 패킷을 진행 중에 캡슐화하거나 NAT하는 것은 네트워크 엔지니어링을 비효율적으로 만들 수 있다. 회사에서 어느 쪽도 사용하지 않고 있다면 신경을 쓸 필요가 없다.
우리가 이번에 테스트한 것 같은 왠 옵티마이저는 투명 프록시들로서 클라이언트와 서버 사이에 놓인다. 이들은 어플라이언스가 SMB(Server Message Block)나 HTTP 같은 프로토콜을 최적화할 수 있게 해준다. 랜에서는 투명성이 클라이언트와 서버에 어떤 변경도 필요치 않다는 것을 의미하는 경우가 많지만, 왠에서는 어떨까? 이것은 어플라이언스가 트래픽을 어떻게 전달하냐에 따라 달라진다. 어떤 왠 옵티마이저는 변경(alternation)을 하기도 하는데, 리버베드의 스틸헤드 어플라이언스는 이들이 처리하는 패킷에서 어드레스 번역을 수행하는 한편, 실버피크의 NX 어플라이언스는 패킷을 GRE(Generic Routing Encapsulation) 터널로 캡슐화한다. 이 두 업체는 기존의 네트워크 엔지니어링을 시행하거나 복제할 수 있는 기능을 제품에 포함시켰다. 블루코트, 시스코 및 시트릭스는 헤더를 교체하지 않고 패킷을 최적화하고 전달한다.
트래픽을 엔지니어링할 때는 왠 최적화를 염두에 둬야 한다. 우리가 테스트한 모든 장비는 기존의 패킷에서 QoS 태그를 처리할 수 있는 기능이 있었으며, 심지어 장비를 통과하는 패킷에 QoS 태그를 적용시킬 수도 있었다. 그리고 그 대신 모든 장비는 트래픽을 셰이핑할 수 있으며, 많은 원격 어플라이언스를 집합시키거나, 대역외 방식을 취하거나, 혹은 정책 기반 라우팅을 수행하는 어플라이언스는 이런 패킷만 최적화되도록 전달할 수 있다.
ACL 이행 쪽은 약간 더 위험하다. 소스 및 목적지 어드레스와 포트 필터링 같은 기본적인 방화벽 기능은 사용 가능하지만, 왠 최적화기가 방화벽을 대체할 수 있는 것은 아니며, 따라서 방화벽과 랜 사이에 왠 최적화기를 통합시키는 데는 얼마간의 계획 작업이 필요할 것이다. 물론 VPN을 사용하고 있다면 네트워크간을 이동하는 트래픽은 반드시 암호화되기 이전에 최적화돼야 한다.
결론적으로 말해, 왠 최적화는 네트워크를 파괴하지 않지만 리엔지니어링이 필요할 가능성이 많다. 그리고 대부분의 경우에는 그렇게 할 만한 가치가 있다.
통합 문제
우리가 테스트한 왠 옵티마이저들은 대역내와 대역외 설치 모두에 대해 유연한 네트워크 통합 옵션들을 갖고 있었다. 예를 들어 모두가 정책 기반 라우팅뿐만 아니라 WCCP(Web Cache Communication Protocol)를 지원하는데, 이것은 원래 라우터가 HTTP 트래픽을 캐시로 방향조정하는 방식을 표준화하도록 만들어진 것이었지만 지금은 어떠한 TCP 세션이든 방향조정할 수 있도록 범용화됐다. 이는 곧 라우터가 왠 옵티마이저로 향하도록 흐름의 방향을 조정하도록 라우터를 설정하거나, 장비를 인라인으로 설치할 수 있다는 것을 의미한다.
데이터센터나 집선용으로는 WCCP나 정책 기반 라우팅을 사용할 것을 추천한다. 그래야 장비 오류시 어플라이언스가 전체 네트워크 트래픽에 영향을 주지 않을 수 있기 때문이다. 그보다도 최적화된 접속은 분리될 것이며, 원격 사무소에서는 네트워크 구성으로 인해 인라인 설치가 한층 간편해질 것이다.
테스트한 모든 어플라이언스는 페일오버(failover) 기능을, 그 가운데 어떤 것들은 고급 기능도 제공하는데, 예를 들어 블루코트와 시스코 장비에서는 클러스터링이 가능하다.
투명 프록시
우리는 업체측에 어플라이언스 오류나 정전시 어떤 일이 발생하는지 물어 보았다. 모든 업체들이 장비가 트래픽을 브리징한다고 답했으며, 테스트 결과 이것은 사실로 확인됐다. 하지만 왠 옵티마이저는 클라이언트나 서버에서 어떠한 구성도 필요로 하지 않는 투명한 인라인 TCP 프록시로 작동하기 때문에 어느 쪽 어플라이언스든 다운되면 최적화가 되고 있는 접속은 다시 만들어져야 할 필요가 있다. 파일 서버로 가는 하나의 접속은 실제로는 클라이언트와 로컬 왠 옵티마이저 사이의 접속 하나, 왠 옵티마이저 한 쌍간의 접속 하나, 그리고 원격 왠 옵티마이저와 목적지 사이의 접속 하나 등 세 가지 접속으로 구성된 것이다.
투명 프록시는 이런 어플라이언스들이 IP로부터 모든 것을 최적화할 수 있게 해준다. 윈도 클라이언트는 예를 들어 랜에서 잘 먹히는 아주 작은 TCP 수신 측 창을 갖고 있는 경향이 있지만, 왠에서는 네트워크 성능을 제한한다. 왠 옵티마이저는 접속을 프록싱함으로써 로컬로 통신을 하는 한편, 왠에서는 용량의 마지막까지 짜내 쓸 정도로 훨씬 더 적극적이다.
왠 옵티마이저는 또한 애플리케이션에 따른 최적화를 수행할 수 있다. 예를 들어 윈도 클라이언트가 파일 서버의 파일을 전송하기 위해 윈도 SMB를 사용하면, 제어 프로토콜은 토크쇼 진행자보다 더 수다스럽다. 서버는 64비트만 보내고 나면 서버로부터 확인응답(acknowledgement)을 기다려야 할 것이며, 왠 작업처리량이 제한을 받게 된다. SMB/CIFS 프록시는 랜 쪽에서 트래픽을 추가하는 한편, 왠에서는 SMB 명령 및 제어(command-and-control) 트래픽을 보다 적은 패킷들로 연합시킴으로써 RTT를 줄여 성능을 향상시킨다. SMB/CIFS 프록싱에는 또한 읽기 선/쓰기 후 기능(데이터의 다음 블록을 요청되기 이전에 불러오는 것)과 디렉토리 리스팅 같은 메타데이터 캐시에 대한 지원이 포함돼 있다.
그 외에 흔히 지원되는 프로토콜들로는 오라클 SQLnet, MAPI, RPC 및 NFS 등이 있으며, 이들 모두가 애플리케이션 최적화와 데이터 축소를 통해 왠에서 최적화가 가능하다.
인라인이 아닌 인라인
‘투명 인라인’이라는 말이 왠 가속기가 잘못됐을 경우에도 TCP 접속이 방해받지 않고 계속 흐를 수 있다는 의미로 착각해서는 안 된다. 그리고 앞서 언급한 것처럼, 옵티마이저는 처음 설치됐을 때 보통 기존의 접속을 최적화하지 않는다. 이들은 설계상 기존의 TCP 세션만 남겨두는데, 그 이유는 TCP 상태를 중간에 판단할 수 있는 방법이 없기 때문이다. TCP 흐름에 있는 패킷이 서로 다른 경로를 취하는 비대칭 라우팅을 생각해 보라. 왠 옵티마이저가 비대칭 TCP 접속을 인터셉팅하려 하면 이것과 클라이언트가 계속해서 세션을 시도하기 때문에 ACK 폭풍이 유발될 가능성이 많다.
다행히도 대부분의 TCP 접속은 비교적 짧으며, 이 문제는 어플라이언스가 설치되거나 재시동될 때만 해당된다. 보다 빠른 최적화를 원한다면, 클라이언트나 서버를 재부팅함으로써 기존의 TCP 접속을 끊으라. 테스트를 하는 동안 우리는 TCP 접속을 질서있게 유실시킨 후에 다음 번 성능 테스트를 수행함으로써 모든 트래픽이 최적화될 수 있도록 했다. 단 실버피크의 NX 어플라이언스는 예외적으로 기존의 TCP 세션에서 계속 데이터 축소를 수행했지만, 다른 최적화들은 전혀 그렇지 않았다.
UDP 트래픽 최적화
지금까지 이야기한 것들은 모두 TCP 애플리케이션을 중심으로 한 것들이었는데, 그 이유는 대부분의 엔터프라이즈 애플리케이션이 TCP에서 돌아가고, TCP에 세션 제어 기능이 내장돼 있기 때문이다.
UDP는 DNS, VoIP 및 스트리밍 미디어 같은 기간 애플리케이션용으로 사용되지만, 최적화와 데이터 축소에 훨씬 덜 호의적이다. 우리는 사람들을 우리가 원하는 만큼 빨리 말하도록 만들 수는 없다. 하지만 실버피크나 블루코트 제품은 UDP 트래픽을 어느 정도까지 최적화해낼 수 있으며, 테스트한 모든 장비는 VoIP와 라이브 비디오 및 오디오 패킷을 가능한 빠른 속도로 이동시킨다.
실버피크의 NX 어플라이언스는 회선 상의 비트를 조사하며, 데이터 축소를 수행한다. 블루코트의 SC 장비는 한 단계 더 나아가 데이터 축소가 아니라 스트림 분할(stream spliiting) 기법을 이용해 스트리밍 오디오와 비디오를 최적화한다. 여러 사용자가 같은 비디오 스트림을 보고 있으면 이들은 소스로부터 같은 콘텐츠를 풀링한다. 그러면 이 때 SC 게이트웨이가 원격 서버에서 하나의 스트림을 풀링하여, 요청하는 모든 클라이언트에게 이것을 분할하는 방식이다.
튜닝 작업 필요
물론 네트워크에 한 쌍의 왠 옵티마이저를 던져 두고, 최소한의 구성을 하고, 결과를 지켜볼 수도 있다. 하지만 최고의 성능을 얻기 위해서는 튜닝이 필요하다. 즉 최적화 기능을 세팅하고, 새로운 애플리케이션을 추가하고, 예비 대역폭을 남겨두는 등의 일을 해야 한다. 데이터 축소에는 시간과 자원이 필요하며, 정책을 만드는 데 집중을 할수록 하드웨어 투자를 극대화할 수 있는 가능성도 커진다.
예를 들어 FTP, NFS 및 SMB/CIFS 같은 벌크 파일 전송 프로토콜들은 모든 최적화의 혜택을 받겠지만, 텔넷이나 SSH 같은 실시간 프로토콜들은 데이터 축소의 덕을 많이 보지 못할 것이다. 텔넷에서는 어쨌든 패킷의 크기가 작으며, SSH에서는 데이터가 암호화되기 때문이다.
간단히 말해, 회선 상에서 비트를 재생해내는 활동들은 데이터 축소나 왠 최적화에 잘 맞는다. 회선 상에서 비트를 재생하지 않는 활동들은 데이터 축소용으로는 좋지 못하지만 다른 최적화의 혜택은 볼 수 있다.
예를 들어 블루코트 SG 어플라이언스에서는 특정 프로토콜을 인터셉트한 다음, 어떤 최적화를 적용할지 지정하도록 프록시를 구성할 수 있었다. 어플라이언스로 들어오는 트래픽은 가장 전문적인 정책을 받았다. SSH나 암호화된 백업 같이 데이터 축소를 원치 않는 프로토콜에서는 우회를 설정해서 어플라이언스의 부하를 줄일 수 있었다. 디폴트 규정이 나머지 모든 것을 잡아주고 있다. 일반적인 프록시 설정들 외에도, SC 어플라이언스는 HTTP 같은 애플리케이션 전용 설정도 갖고 있는데, 여기서는 임베딩된 객체가 프리페칭(pre-fetching) 및 파이프라이닝(pipelining)돼 왠에서의 라운드 트립 트래픽을 줄여줄 수 있다.
시스코와 블루코트에서 제공하는 SMB/CIFS 캐싱은 데이터 축소와는 다른데, 그 이유는 문서 같은 실제 객체들이 로컬 어플라이언스에서 캐싱됨으로써 성능 이점과 향상된 유용성을 제공하기 때문이다. 예를 들어 시스코의 SMB/CIFS 프록시는 파일을 왠에서 불러와 데이터 축소를 수행하는 게 아니라 캐시로부터 지원하도록 구성될 수 있다. 디폴트에서는 억제돼 있는 읽기 전용 액세스는 원격 링크가 잘못됐을 경우 서버당 기반에서 파일을 캐싱하는 데 허용될 수 있다. 하지만 이 기능은 조심해서 허용해야 한다. 일단 사용자가 캐싱된 파일에서 작업을 시작하면 충돌이 발생할 것이기 때문이다. 몇몇 사용자들이 같은 파일을 변경하려 할 경우, 어떤 변경을 적용시킬지 누가 결정하겠는가?
왠 최적화로부터 최상의 것을 얻기 위해서는 이와 같은 문제들을 해결해야 하겠지만, 통신사업자에게 돈을 덜 줘도 되는 데서 얻을 수 있는 만족감은 말할 것도 없이, 엔드유저 생산성으로 돌아오는 보답을 통해 투자에 대한 가치는 충분히 실감할 수 있을 것이다.
NWC 보고서: 왠 최적화 어플라이언스
우리는 전형적인 분산형 기업에서 부족하고 정체되는 왠 회선을 최적화해주는 하드웨어나 소프트웨어 제품을 요청했다. 시나리오는 미 대륙 내에 여러 개 사이트들이 T1과 T3를 통해 연결돼 있는 것으로 설정했다. 회사에서는 분산된 애플리케이션 성능을 향상시키기를 원하고 있으며, 향후에는 하나의 중앙 사이트로 애플리케이션을 통합시킬 계획을 갖고 있다. 제품들은 애플리케이션과 네트워크 레벨에 투명해야 하며, 데스크톱이나 서버에서, 혹은 애플리케이션에 어떤 변경도 이뤄지지 않아야 한다. 마찬가지로 우리는 애플리케이션을 인라인으로 두는 것 이상으로 네트워크 토폴로지에 큰 변화를 만들고 싶지도 않았다. 최적화기는 또한 중앙에서 관리할 수 있어야 하며, 보고 기능을 제공해야 한다.
참가 업체 : 블루코트 시스템즈, 시스코시스템즈, 시트릭스시스템즈, 실버피크시스템즈
테스팅 시나리오 : 우리는 시러큐스 대학 리얼월드 랩에서 왠 옵티마이저를 테스트해서 네트워크 작업처리량이 크게 증가할 수 있는지 여부를 확인했다. TCPerf 등 다양한 툴을 이용해 불연속적인 흐름, FTP, DOS 파일 카피, 그리고 VBA 스크립트를 만들어서 랜 측의 성능이 4~10배까지 향상이 되면서 대기시간은 낮게 유지되는 것을 지켜 보았다. 션라(Shunra)의 VE 왠 시뮬레이터를 통해 패킷을 돌림으로써 우리 왠의 기준선은 T3로 잡고 파일 전송 시간이 100KB~500KB 파일에서 수 분대로 늘어날 때까지 왠을 오버섭스크라이빙(oversubscribing)했다. 왠 옵티마이저를 배치하자 랜 측 처리속도는 300Mbps에서 500Mbps 이상까지 향상되는 경우가 많았으며, 파일 전송 시간은 1초 아래로 떨어졌다. NetQoS 수퍼에이전트(SuperAgent)와 리포터애널라이저(ReporterAnalyzer)를 이용해 클라이언트 랜에서의 처리속도와 대기시간을 측정했으며, 처리속도를 실시간으로 보고 패킷 캡처를 보는 데는 플루크 옵티뷰 시리즈 III 인티그레이티드 네트워크 애널라이저(Flukes OptiView Series III Integrated Network Analyzer)를 사용했다.
분석 부문 : >> 성능: 처리속도와 대기시간에서 향상된 정도 평가
>> 최적화 구성: 최적화 정책의 정의, 트래픽 셰이핑 및 ACL에 대해
>> 보고: 각 제품에 있는 보고 기능과 트렌딩(trending) 도구들을 검토했다. 명확한 보고서, 히스토리 분석, 장애관리 툴,
그리고 흐름 데이터를 엑스포팅할 수 있는 능력이 있으면 좋다.
>> 가격: 이 돈으로 어떤 기능과 성능이 제공되는가?
>> 관리: 첫 설치에서부터 구성 가능한 옵션들에 이르기까지, 배치 및 관리에 대한 모든 것을 평가
>> 네트워크 투명성: 투명성이란 어드레싱이나 QoS 태그를 포함해, 진행 중에 패킷에 있는 헤더 데이터를 바꾸지 않는
것을 의미한다.
결과 : 테스트한 모든 장비들은 잘 작동했다. 왠 최적화에서는 제품들간에 별 차이가 없었는데, 드러난 차이의 대부분은 주로 구성과 보고/장애관리 부문에서였다. 모든 제품이 추천할 만했지만, 최고 가치상은 시스코 장비에게 돌아갔다.
에디터스 초이스는 블루코트의 SC 어플라이언스의 몫이었다. 이 장비는 고도로 구성이 가능하며, 풍성한 프로토콜 최적화 프록시, 좋은 보고 기능, 그리고 SSL 트래픽을 처리하고 이동 중인 데이터를 암호화하는 보안 기능을 제공한다.
시스코의 WAAS 소프트웨어는 자신의 WAE 어플라이언스에서 가격에 비해 좋은 가치를 제공함으로써 최고 가치상을 받았다. WAAS의 중앙 관리는 최고지만 보고 부문에서 블루코트나 실버피크 제품보다 정보력이 떨어졌다.
시트릭스의 완스케일러 어플라이언스는 성능은 강력하지만 옵션이 가장 적었으며, 따라서 정밀한 구성 작업을 할 수가 없었다. 완 스케일러는 시스코의 WAAS와 마찬가지로 클러스터링을 지원하며, 비대칭 네트워크도 지원하고 있다.
실버피크의 NX 어플라이언스는 보안을 생각하는 회사들에게 좋은 선택인데, 그 이유는 이들이 하드웨어 가속화 IPSec VPN을 이용해 어플라이언스들간의 모든 트래픽을 암호화할 수 있으며, 하드 드라이브도 또한 암호화되기 때문이다.
용어의 정확한 의미
WAFS(wide-area file systems)를 이끌었던 원칙은 왠 최적화에도 적용이 된다. 차이가 있다면 왠 최적화는 파일만이 아니라 왠을 가로지르는 모든 데이터에 적용이 된다는 것이다. 또한 왠 최적화를 부하조절이나 AFE(application front ends), 캐싱, 혹은 콘텐츠 배포와 같이 네트워크나 서버 성능을 향상시켜 주는 다른 방안들과 혼동해서도 안 된다. 이들은 각각 특정 유형의 병목을 최적화해주는 것들이다. 즉 부하 조절기와 AFE는 서버 부하를 줄여주는 한편, 캐싱과 콘텐츠 전달은 데이터를 소모되고 있는 장소에 한창 가깝게 가져다 준다. 왠 최적화는 왠에서의 비트 수를 줄이는 기술이다.
노출의 위험
왠 최적화는 암호화된 트개픽을 처리할 수 없다는 점 외에도, 회사의 사적인 데이터가 이제 완전히 다른 하드 드라이브에 놓이게 됨으로써 정보 보안 노출의 위험을 안고 있다.
파일들은 연속적인 블록으로 저장되지 않으며, 따라서 왠 옵티마이저에서 드라이브를 뽑아 내면 “contract.doc"를 찾을 수가 없게 된다. 하지만 디스크에 배포된 ”contract.doc"에서 데이터를 찾을 수 있으며, “contract.doc"에 배치된 파일 보호책들은 블록에 적용되지 않는다. 따라서 누군가 어플라이언스를 훔쳐서 이것을 이배이(ebay)에서 팔거나, 혹은 디스크를 지우지 않고 중개상에게 보낼 경우 정보 누출의 위험이 있다.
모든 회사들, 특히 규제를 받는 업계에 종사하는 회사들은 반드시 보안 및 장애 복구 게획에 이러한 추가 스토리지의 관리도 포함시켜야 한다. 아무리 못한다고 하더라도 수리나 교체를 위해 어플라이언스를 보낼 때 모든 왠 옵티마이저의 내용을 깨끗이 청소하도록 하는 규정은 만들어야 한다. 본지의 보안 담당 테스터는 실버피크의 NX 시리즈 장비에 좋은 점수를 주었는데, 이것은 모든 디스크 드라이브를 암호화함으로써 파워가 나갔을 때 데이터에 액세스를 할 수 없게 한다. 다른 업체들도 앞으로 버전에서는 디스크 암호화를 추가하기를 바라는 바다.
보안 트래픽의 최적화
본지 설문조사에서는 절반에 가까운 독자들이 웹 애플리케이션 최적화를 원한다고 답했다. 하지만 ERP나 협업 애플리케이션 같은 엔터프라이즈 애플리케이션들이 웹 프론트 엔드를 채택함에 따라 네트워크에서는 SSL과, 그 사촌인 TLS(Transport Layer Security)가 훨씬 더 많이 사용되고 있다. 문제는 SSL의 장점, 즉 종단간 암호화가 이 트래픽을 건드리고 싶어하는 어떤 장비에게든 독이 된다는 것이다.
SSL은 SMTP, IMAP 및 POP3 같은 다른 프로토콜들을 보안하며, 윈도 파일 쉐어링(Windows File Sharing)을 하나의 사양으로 포함시킨 SSL VPN들이 늘어나고 있다. 간단히 말해 SSL은 빠른 속도로 선택의 보안 전송수단이 되고 있다. 하지만 암호화된 네트워크 트래픽은 최적화될 수가 없다. 이것은 압축이 불가능하며, 본성상 사용자와 네트워크 접속별로 변경이 된다. 키 관리도 주름살을 또 하나 늘려줄 것이다.
블루코트 시스템즈와 리버베드테크놀로지스는 클라이언트와 서버 사이에 들어가 SSL 세션의 암호를 해독하고, 최적화한 다음 다시 암호화를 함으로써 SSL 트래픽을 최적화하는 방식을 이용하고 있다. 블루코트의 프로세스는 프록시 같은 SSL을 처리하며, 서버 인증서가 각각의 SC 어플라이언스에게 푸싱된다.
브라우저가 SSL 세션을 시작하면, SG와 브라우저는 세션을 협상하며, 그런 다음 SG가 타깃 웹 서버와 SSL 세션을 협상한다. 이것이 유효하게 하려면 CA(Certificate Authority)를 만들고 CA 서버 인증서를 모든 클라이언트에게 배포하거나, 혹은 SG 클라이언트에서 자체 서명 인증서를 만들어 이들을 배포해야 한다. 앞의 방식이 훨씬 간단하며, 윈도 서버에는 잘 돌아가는 CA 소프트웨어가 함께 포함돼 있다.
리버베드는 스플리트 터미네이션(Split Termination)이라는 방식을 사용하는데, 여기서는 웹 서버에 가장 가까운 스틸헤드 어플라이언스에 서버 인증서와 전용 키가 설치된다. 클라이언트 소프트웨어가 SSL 세션을 수립하기를 원하면, 클라이언트가 원격 스틸헤드와 협상을 한다. 일단 세션 키가 만들어지면 원격 어플라이언스는 세션 키를 로컬 스틸헤드로 보안 전송하며, SSL 협상이 완료된다. 비록 클라이언트에 어떠한 추가 인증서도 배포되지 않지만, 서버 전용 키는 스틸헤드에 파퓰레이팅돼야 한다.
혹시 SSL 서버 키를 네트워크 어플라이언스에 둔다는 생각이 위험해 보이는가? 현재 당신의 전용 키는 어디에 보관돼 있는가? 키를 하드웨어에 안전하게 보관할 수 있는 엔사이퍼의 netHSM 같은 하드웨어 보안 모듈에 깊숙이 숨겨져 있는 게 아니라면 당신의 키는 웹 서버의 하드 드라이브에 있을 것이고, 노출된 상태라고 할 수 있다. 키를 어플라이언스로 푸싱한다고 해서 더 나아질 것도, 나빠질 것도 없다는 얘기다.
전용 키를 어플라이언스에 복사하거나 자신의 인증서를 발급하는 게 싫다면 SSL 최적화를 할 수 없다. |
|
|
|
|
|
|
|
|
|
| ⓒ 데이터넷(http://t564.ndsoftnews.com) 무단전재 및 재배포금지 | 저작권문의 |
|
|
|
|
|
|
| |
| 가장 많이 본 기사 |
|
|
 |
|
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
