애플리케이션 프록시 이해
애플리케이션 프록시는 애플리케이션 데이터 스트림(일반적으로 OSI 모델의 4~7계층 사이에서 작동)의 중간에 삽입되어 WAN 연결에서 애플리케이션의 성능을 저하시키는 애플리케이션의 특성을 ‘수정’하는 심으로 사용되는 소프트웨어 조각입니다. 이러한 ‘수정’은 두 가지 유형으로 나타나는 경향이 있었습니다:
- 애플리케이션 데이터의 데이터 중복 제거를 허용하는 데 도움이 되는 것 또는
- WAN 연결을 통해 두 애플리케이션 엔드포인트에 필요한 총 통신량(“채팅량”)을 줄이는 데 도움이 되었습니다.
애플리케이션 프록시(리버베드와 같은 기존 WAN 최적화 공급업체에서 사용)는 오래된 기술이며, 오늘날 WAN 최적화 영역에서 사용 빈도가 낮아지고 있습니다.
이러한 전환이 필요한 5가지 이유는 다음과 같습니다:
1) 애플리케이션 프록시는 도움을 준다고 주장하는 많은 애플리케이션을 ‘망가뜨리는’ 경향이 높습니다.
이것이 WAN 최적화 기술이 ‘레이어 7 프록시’ 모델에서 크게 벗어난 가장 큰 이유입니다.
애플리케이션 프록시는 애플리케이션 프로토콜의 정확한 사양에 따라 작성해야 합니다. 이는 일반적으로 SSL과 같은 안정적이고 낮은 수준의 프로토콜에서는 괜찮지만, MS-SQL 또는 Citrix ICA와 같은 높은 수준의 독점 프로토콜에서는 문제가 됩니다. 이러한 프로토콜은 자주 변경되며 변경 사항은 게시되지 않습니다.
네트워크 관리자의 세계에서 자주 일어나는 일이지만, 어딘가의 서버가 업그레이드되고 애플리케이션 프로토콜이 변경되었다는 첫 번째 단서는 애플리케이션이 더 이상 제대로 작동하지 않는다는 사용자 불만이 쏟아지기 시작할 때입니다.
애플리케이션 프록시가 중단의 원인으로 확인되면 프록시를 새 애플리케이션 버전과 호환되도록 업그레이드해야 합니다. 또한 이러한 프로토콜은 프록시 제공업체에서 리버스 엔지니어링해야 하는 경우가 많기 때문에, 이러한 중단에 대한 ‘수정’이 제공되기까지 수개월 또는 그 이상(“널리 사용되는” 프로토콜인지 여부에 따라 다름)이 걸릴 수 있습니다.
따라서 네트워크 관리자는 두 가지 선택 사항만 남게 됩니다: 1) 서버 관리자에게 네트워크가 새 애플리케이션 버전을 지원하지 않는다고 알리거나, 또는 2) 애플리케이션 프록시가 새 애플리케이션을 무시(우회)하도록 설정하여 기본적으로 애플리케이션을 최적화하지 않고 렌더링합니다.
2) 특정 프로토콜이 서서히 사용을 중단하는 경우.
이러한 유형의 전환의 예는 오늘날 MAPI와 같은 일부 독점적인 암호화 프로토콜에서 볼 수 있습니다. MAPI는 Microsoft의 독점적인 Exchange Server 이메일 프로토콜이지만, 클라우드 기반 및 SaaS 애플리케이션의 발전으로 SSL은 소호 및 모바일 사용자가 선택하는 기업용 프로토콜로 빠르게 자리 잡고 있습니다. 또한 Microsoft는 Exchange 이메일 전송을 위한 SSL도 지원하기 때문에 많은 회사들이 MAPI에서 비독점적인 SSL로 전환하고 있습니다. 애플리케이션이 독점 프로토콜에서 벗어나 진화함에 따라 이러한 유형의 프록시는 더 이상 사용되지 않게 됩니다.
3) WAN 최적화 기술은 더 이상 특정 프록시가 필요하지 않을 정도로 발전했습니다.
NFS가 좋은 예입니다. 파일 공유 프로토콜인 NFS v3는 WAN 지연 시간과 관련된 처리량 및 최종 사용자 응답 시간에서 특정 제한이 있었습니다. 이는 주로 프로토콜이 설계된 방식 때문에 애플리케이션 응답을 받지 않고 한 번에 전송할 수 있는 데이터의 양이 제한되었기 때문입니다.
동시에 기존 WAN 최적화 기술은 주로 WAN을 통해 주고받아야 하는 총 데이터를 줄이고 혼잡을 제거하여 응답 시간을 개선하는 방법으로 데이터 중복 제거에 중점을 두었습니다. 그러나 이러한 구형 WAN 최적화 기술은 데이터 블록을 일치시키기 위해서는 전송의 데이터 부분이 어디서 시작되는지 알아야 하기 때문에 NFS 트래픽에서는 잘 작동하지 않는 블록 수준 중복 제거 방식을 사용했습니다. NFS 프로토콜 전송 내 데이터 부분의 위치는 다양할 수 있습니다.
당시 NFS WAN 문제를 ‘해결’하기 위한 최선의 해결책은 애플리케이션 프록시를 작성하여 프로토콜에 필요한 통신량을 인위적으로 줄이고 블록 수준의 중복 제거를 효과적으로 수행할 수 있도록 NFS 전송의 데이터 부분이 어디에 있는지 파악하는 것이었습니다.
기존 WAN 최적화 공급업체는 여전히 오래된 중복 제거 기술을 사용하기 때문에 NFS 최적화를 위해 심이 필요하지만, 최신 공급업체는 애플리케이션별 프록시 없이도 NFS 트래픽을 최적화할 수 있으며 최소한의 프록시 최적화로 네트워크에 장애가 발생하는 일이 줄어듭니다!
4) 10년 전에는 WAN 연결에서 잘 작동하지 않던 일부 애플리케이션이나 프로토콜이 진화하거나 재설계되어 중개 심 없이도 WAN에서 작동할 수 있게 되었습니다.
다시 NFS를 살펴보겠습니다. 최신 버전의 NFS v4.x에서는 채팅 및 처리량과 관련된 대부분의 프로토콜 제한 사항이 수정되었습니다. 나머지 제한은 애플리케이션별 심 없이 일반 TCP 최적화를 통해 해결됩니다.
5) ‘애플리케이션 프록시’ 기술 아키텍처는 비즈니스 및 개발 관점에서 지속 가능한 모델이 아닙니다.
첫째, 유지 관리 비용이 매우 많이 듭니다. 애플리케이션 공급업체에서 애플리케이션의 새 버전 또는 업데이트를 출시할 때마다 애플리케이션 프록시를 위한 새로운 특정 최적화 메커니즘을 개발해야 합니다.
프로토콜을 소유하고 있으며 릴리스 간 또는 서비스 팩 업데이트 중에도 언제든지 프로토콜 사양을 변경할 수 있는 Citrix ICA를 예로 들어 보겠습니다. 이러한 모든 애플리케이션 프록시를 추적하고 더 이상 사용되지 않는 프로토콜을 계속 지원하는 것은 매우 효율적인 비즈니스 모델이 아닙니다.
또한 향후 확장성을 제한합니다. 프록시의 본질은 원격 서버를 대신하여 작동하는 것입니다. 이를 위해 프록시는 각 애플리케이션 세션을 종료하고 추적해야 합니다. 이로 인해 하드웨어 요구 사항 측면에서 매우 높은 오버헤드가 발생하여 점점 더 큰 상자가 필요하게 됩니다.
다행히도 애플리케이션 수준 프록시로 해결되었던 문제들이 이제는 보다 효율적인 방식으로 해결되어 기존 프록시 기술의 장점 중 일부는 더 이상 쓸모없게 되었습니다. 이전 버전의 CIFS 또는 SMB와 같은 일부 애플리케이션 계층 프로토콜은 여전히 WAN을 통한 최적화를 위해 특정 프록시를 사용하는 이점이 있지만, 그 목록은 계속 줄어들고 있습니다. 특정 애플리케이션 계층 프록시에 대한 의존도를 줄임으로써 오늘날의 기술은 안정성을 개선하고 잠재적인 장애 지점을 제거하면서 더 나은 최적화를 제공할 수 있습니다.
