부하조절의 시대인 1990년대 후반을 돌이켜 보면, 서버간에 트래픽을 분배하는 최고의 메커니즘은 각 패킷의 목적지 포트를 기반으로 한 것이었다. 웹 스위칭은 포트 80으로 향하게 된 모든 트래픽을 하나의 서버 세트에 분배하는 간단한 일례였으며, 그 후 누군가가 포트만에 의해서가 아니라 패킷의 궁극적인 목적지, 즉 URI(Universal Resource Identifier)에 따라서도 트래픽을 구분하는 것이 현명하다는 판단을 내린 것이다.
제품 과다로 선택 혼선
하지만, 웹사이트의 실질적인 호스팅은 이미 존재하고 있었다. 6개, 혹은 그 이상의 웹 호스트 어드레스들이 같은 IP로 용해되겠지만, 어쨌거나 웹 서버는 요청이 향하고 있는 것이 어떤 호스트인지를 파악하고 이것을 사이트로 보내주었다. 그 비결은? 물론 요청에 있는 호스트 헤더를 검토함으로써 가능했던 것이다.
그리고 난 후(아마 새벽 두 시경에) 누군가 이 기능을 부하조절기(load-balancer)에 두면 좋겠다는 생각을 했다. 결국 부하조절기(다른 프로세싱을 처리해야 하는 필요에 의해 족쇄가 풀린)는 웹 기반 서비스와 관련이 없는 과다한 프로세스들을 짊어진 웹 서버보다도 효율적으로 이 기능을 수행할 수 있었다.
하지만, 시스코시스템즈(애로우포인트 커뮤니케이션즈 인수), F5 네트웍스, 파운드리 네트웍스 및 노텔네트웍스(알테온 웹시스템즈 인수) 등은 다른 생각을 제기했으며, 이것은 괜찮은 생각이었다. 컨텐츠 스위치는 레이어 7(OSI 모델의 애플리케이션 계층)을 기반으로 트래픽을 라우팅할 수 있는 능력을 제공, 제공되는 컨텐츠 및 서비스를 기반으로 라우팅함으로써 서버팜의 최적화를 향한 길을 열었다.
좋다. 이제 당신은 컨텐츠 스위치가 주는 혜택은 알고 있겠지만, 과연 어떤 스위치를 선택해야 하는 것일까? 현재 이 시장은 시스코, F5, 파운드리 및 노텔뿐만 아니라 클릭어레이 네트웍스(ClickArray Networks), 익스트림 네트웍스(Extreme Networks), 하이드라웹 테크놀로지즈(HydraWeb Technologies), 인텔(Intel), 넷스케일러(NetScaler), 기타 등등의 업체들이 내놓는 제품들이 넘쳐흐르고 있다. 그렇다면 이 혼란의 와중에서 제대로 된 선택은 어떻게 할 수 있을까?
세 가지 기본 사항, 즉 장비의 로직 세트, 오류내구성 및 관리를 염두에 둘 필요가 있다. 그 다음에는 오늘날의 장비에서 발견되는 모든 부가 기능들, 즉 802.1p QoS(Quality of Service), SSL 가속화 및 캐시 방향조정 기능들의 지원 등을 꼼꼼히 따져 보라. 그리고 나면 언제나처럼 네트워크로 제공되는 인터페이스의 수와 유형을 참작해야 한다. 그리고 마지막으로 가격이 있다.
컨텐츠 스위치의 로직(logic) 및 규정(rule) 설정 기능은 이 장비의 중심에 있다. 이런 기능들이 없다면 이 장비는 단순히 하나의 부하조절기로 그쳤을 것이다. 규정은 특정 RUL이나 URL 패턴을 서버의 클러스터나 풀에 묶어둔다. 그러한 규정의 일례로 ‘.cgi 확장자를 가진 모든 것이 클러스터 X로 라우팅되면서 다른 모든 것은 클러스터 Y로 갈 것’이 있다.
