2021.09.10

“필요한 것은 나만의 SD-WAN” 주요 설정과 고려사항

Tom Nolle | Network World
어째서 우리는 아무리 혁신적인 기술이라도 그냥 사서 연결만 하면 사용할 수 있다고 생각하는 것일까? 게다가 기술 분야의 모든 것이 갈수록 더 정교해지고 복잡해지고 있다는 부정할 수 없는 사실에도 불구하고 이 생각엔 변함이 없다. SD-WAN도 그런 기술이다. SD-WAN은 제각기 다르므로 자기만의 SD-WAN을 만들기 위해서는 얼마간의 노력이 필요하다.  
 
ⓒ Getty Images Bank
 

SD-WAN 오버헤드 

SD-WAN의 원래 임무는 전통적인 MPLS VPN이 너무 비싸서 사용할 수 없거나 아예 제공되지 않는 소규모 사이트를 기업 VPN에 연결하는 것이었다. SD-WAN은 작동을 위해 IP 위의 네트워크라고 할 수 있는 라우팅 오버레이를 생성한다. 

SD-WAN 소프트웨어와 애플리케이션은 이를 위해 일반적으로 IP 패킷에 가상 네트워크 헤더를 추가한다. 헤더의 크기는 구현에 따라 다르지만 적게는 몇 바이트부터 많게는 몇십 바이트까지 패킷에 추가된다. SD-WAN 디바이스는 이 오버레이 헤더 주소를 기반으로 라우팅하는데, 주소는 MPLS VPN에 사용되는 것과 동일한 주소 공간에 포함될 수 있으므로 SD-WAN은 사실상 회사 VPN에 사이트를 추가하게 된다. 

SD-WAN 헤더가 비즈니스 애플리케이션에서 문제가 되는 경우는 드물지만, 작은 패킷을 생성하는 애플리케이션에서는 문제가 될 수 있다. VoIP 패킷의 길이는 약 200바이트이므로 예를 들어 12바이트의 SD-WAN 오버헤드는 패킷의 크기를 약 6% 늘린다. IoT 패킷은 그보다 훨씬 더 작아서 30~50바이트도 있으므로 똑 같은 헤더라도 이 경우 패킷의 크기가 24~40%까지 커질 수 있다. 패킷 오버헤드의 증가는 그 비율만큼 유효 연결 대역폭을 줄이는 효과로 이어지므로 대역폭이 제한된 소규모 사이트의 경우 오버헤드로 인해 속도가 더 떨어질 수 있다. 

고려 중인 SD-WAN 솔루션 업체에 이 오버헤드, 그리고 패킷 라우팅 방법에 대해 물어보는 것이 중요하다. 극소수 SD-WAN 솔루션 업체는 라우팅 헤더를 모든 패킷이 아니라 사용자와 애플리케이션 간의 모든 세션에 추가하는데, 이 방법의 오버헤드가 가장 작다. 따라서 최적의 SD-WAN을 선택하려면 세션 또는 패킷이 라우팅되는지 여부, 어떤 오버헤드가 추가되는지에 대한 정확한 데이터를 구해야 한다. 
 

패킷 우선순위 부여 

대부분의 사용자는 사용할 일이 없는 기능으로 인해 SD-WAN 성능이 영향을 받는 경우도 있다. 음성, 비디오 및 일부 IoT 애플리케이션은 지연에 민감하다. 트래픽이 무겁고 패킷이 소스에서 백업되는 경우 지연은 들쭉날쭉할 수 있다. 애플리케이션 중에서도 중요도가 높은 애플리케이션이 있고, 많은 사용자는 이와 같은 중요한 애플리케이션의 패킷이 우선 순위가 낮은 다른 패킷보다 먼저 전송되기를 원할 것이다. 패킷 우선순위는 일부 SD-WAN 구현에서 제공되는 기능이지만 그 효과는 특정 애플리케이션의 우선순위를 얼마나 효과적으로 식별하느냐에 따라 좌우된다. 

대부분의 SD-WAN은 단순히 패킷 유형 또는 TCP/UDP 포트 번호를 확인한다. 이는 모든 음성 패킷 또는 특정 애플리케이션의 모든 패킷이 동일한 우선순위를 갖는다고 전제하는 방식이다. 하지만 많은 경우 사용자는 특정 애플리케이션의 모든 사용자가 아니라 특정 사용자와 애플리케이션 관계를 더 중시하므로 우선순위가 제공하는 가치는 생각보다 크지 않을 수 있다. 

헤더 오버헤드가 크거나 원하는 우선순위 조정 기능이 없는 SD-WAN을 어떤 이유로 선택해야 하는 상황이라면, 대역폭이 높은 액세스 링크를 사용하는 방법으로(가능한 경우) 두 가지 문제의 영향을 줄일 수 있다. 그 방법을 사용할 수 없고 액세스 대역폭을 효율적으로 사용해야 한다면, 오버헤드 및 우선순위 문제와 관련한 솔루션 업체의 옵션을 신중하게 검토해야 한다. 

보안의 경우도 마찬가지다. SD-WAN이 특정 사용자-애플리케이션 관계를 인식할 수 있다면 중요한 관계에 높은 우선순위를 부여할 수 있을 뿐만 아니라 가능한 모든 사용자-애플리케이션 관계 중에서 실제로 허용되는 관계를 인식할 수도 있다. 이는 SD-WAN으로 더 나은 보안을 구축할 수 있음을 의미한다. 일부 SD-WAN 구현에는 이 정도 수준의 관계 인식이 포함되며, 일부는 보안 계층을 추가해서 이런 기능을 제공할 수 있다. SASE 기술을 추가하는 것이 대표적인 예다.

추가 애플리케이션 및 관계 인식은 도움이 될 수 있지만, 이 정보로 무엇을 할 수 있는지를 아는 것이 중요하다. 예를 들어 부가적인 애플리케이션 인식 또는 SASE 기능은 보안을 개선할 수 있지만, 우선순위에 영향을 미치거나 SD-WAN 패킷에 대해 다른 경로를 선택해서 혼잡을 피할 수 있는가? 이런 모든 기능이 함께 기능한다면 정말 좋지만 그렇지 않은 경우도 있다. 
 

SD-WAN 오프램프 성능 

SD-WAN에서 잘 드러나지 않는 또 다른 문제는 트래픽이 SD-WAN 오버레이에서 나와 데이터센터로 들어가는 방법이다. “올라간 것은 반드시 내려와야 한다”는 말처럼, SD-WAN으로 올라간 것은 그 소규모 사이트가 연결하고자 하는 지점(클라우드 또는 데이터센터)에 이르면 내려와야 한다. 바로 오프램프(Off-ramp)이다. 오프램프 성능은 SD-WAN 구현마다 천차만별이다. 또한 성능 제약에 따라 모든 트래픽을 실어나를 여러 오프램프 요소도 필요하다. 이는 비용과 운영 복잡성을 늘리므로 얼마나 많은 오프램프 요소가 필요하고 무엇을 대상으로 이것을 실행할지를 사전에 파악해야 한다. 
 

관리형 서비스 또는 직접 운영  

마지막으로 고려할 질문은 “어떻게 관리할 것인가?”이다. 네트워크 운영 센터를 위한 숙련된 인력 채용에 어려움을 겪고 있다면, 방금 연결한 소규모 사이트의 문제를 해결하는 데 도움이 될 수 있는 최소한의 지식을 갖춘 현장 인력을 구하는 것이 얼마나 어려울지 상상해 보라. 

관리 기능은 SD-WAN의 성공을 위해 매우 중요하며, 전 세계를 포괄하는 SD-WAN 애플리케이션에는 이 기능만으로는 부족할 수 있다. 하드웨어와 소프트웨어를 구매해 직접 구축하는 대신 서비스 업체 또는 매니지드 서비스 업체(MSP)의 SD-WAN을 이용하는 방법도 고려해야 한다. 최근 컴캐스트(Comcast)의 MSP 매서지(Masergy) 인수를 통해 알 수 있듯이 관리형 SD-WAN 옵션은 발전 및 변화하고 있으므로 잘 살펴보는 것이 좋다. 

그저 SD-WAN을 구매하고 싶다고 생각한다면 잘못된 생각이다. ‘나만의’ SD-WAN을 구매한다고 생각해야 한다. 나의 모든 요구사항, 미처 생각하지 못한 요구사항까지도 충족하는 SD-WAN이 필요하다. 요구사항과 기능을 대조해가면서 사전에 살펴보면 값비싼 실수를 미연에 방지할 수 있다. editor@itworld.co.kr


2021.09.10

“필요한 것은 나만의 SD-WAN” 주요 설정과 고려사항

Tom Nolle | Network World
어째서 우리는 아무리 혁신적인 기술이라도 그냥 사서 연결만 하면 사용할 수 있다고 생각하는 것일까? 게다가 기술 분야의 모든 것이 갈수록 더 정교해지고 복잡해지고 있다는 부정할 수 없는 사실에도 불구하고 이 생각엔 변함이 없다. SD-WAN도 그런 기술이다. SD-WAN은 제각기 다르므로 자기만의 SD-WAN을 만들기 위해서는 얼마간의 노력이 필요하다.  
 
ⓒ Getty Images Bank
 

SD-WAN 오버헤드 

SD-WAN의 원래 임무는 전통적인 MPLS VPN이 너무 비싸서 사용할 수 없거나 아예 제공되지 않는 소규모 사이트를 기업 VPN에 연결하는 것이었다. SD-WAN은 작동을 위해 IP 위의 네트워크라고 할 수 있는 라우팅 오버레이를 생성한다. 

SD-WAN 소프트웨어와 애플리케이션은 이를 위해 일반적으로 IP 패킷에 가상 네트워크 헤더를 추가한다. 헤더의 크기는 구현에 따라 다르지만 적게는 몇 바이트부터 많게는 몇십 바이트까지 패킷에 추가된다. SD-WAN 디바이스는 이 오버레이 헤더 주소를 기반으로 라우팅하는데, 주소는 MPLS VPN에 사용되는 것과 동일한 주소 공간에 포함될 수 있으므로 SD-WAN은 사실상 회사 VPN에 사이트를 추가하게 된다. 

SD-WAN 헤더가 비즈니스 애플리케이션에서 문제가 되는 경우는 드물지만, 작은 패킷을 생성하는 애플리케이션에서는 문제가 될 수 있다. VoIP 패킷의 길이는 약 200바이트이므로 예를 들어 12바이트의 SD-WAN 오버헤드는 패킷의 크기를 약 6% 늘린다. IoT 패킷은 그보다 훨씬 더 작아서 30~50바이트도 있으므로 똑 같은 헤더라도 이 경우 패킷의 크기가 24~40%까지 커질 수 있다. 패킷 오버헤드의 증가는 그 비율만큼 유효 연결 대역폭을 줄이는 효과로 이어지므로 대역폭이 제한된 소규모 사이트의 경우 오버헤드로 인해 속도가 더 떨어질 수 있다. 

고려 중인 SD-WAN 솔루션 업체에 이 오버헤드, 그리고 패킷 라우팅 방법에 대해 물어보는 것이 중요하다. 극소수 SD-WAN 솔루션 업체는 라우팅 헤더를 모든 패킷이 아니라 사용자와 애플리케이션 간의 모든 세션에 추가하는데, 이 방법의 오버헤드가 가장 작다. 따라서 최적의 SD-WAN을 선택하려면 세션 또는 패킷이 라우팅되는지 여부, 어떤 오버헤드가 추가되는지에 대한 정확한 데이터를 구해야 한다. 
 

패킷 우선순위 부여 

대부분의 사용자는 사용할 일이 없는 기능으로 인해 SD-WAN 성능이 영향을 받는 경우도 있다. 음성, 비디오 및 일부 IoT 애플리케이션은 지연에 민감하다. 트래픽이 무겁고 패킷이 소스에서 백업되는 경우 지연은 들쭉날쭉할 수 있다. 애플리케이션 중에서도 중요도가 높은 애플리케이션이 있고, 많은 사용자는 이와 같은 중요한 애플리케이션의 패킷이 우선 순위가 낮은 다른 패킷보다 먼저 전송되기를 원할 것이다. 패킷 우선순위는 일부 SD-WAN 구현에서 제공되는 기능이지만 그 효과는 특정 애플리케이션의 우선순위를 얼마나 효과적으로 식별하느냐에 따라 좌우된다. 

대부분의 SD-WAN은 단순히 패킷 유형 또는 TCP/UDP 포트 번호를 확인한다. 이는 모든 음성 패킷 또는 특정 애플리케이션의 모든 패킷이 동일한 우선순위를 갖는다고 전제하는 방식이다. 하지만 많은 경우 사용자는 특정 애플리케이션의 모든 사용자가 아니라 특정 사용자와 애플리케이션 관계를 더 중시하므로 우선순위가 제공하는 가치는 생각보다 크지 않을 수 있다. 

헤더 오버헤드가 크거나 원하는 우선순위 조정 기능이 없는 SD-WAN을 어떤 이유로 선택해야 하는 상황이라면, 대역폭이 높은 액세스 링크를 사용하는 방법으로(가능한 경우) 두 가지 문제의 영향을 줄일 수 있다. 그 방법을 사용할 수 없고 액세스 대역폭을 효율적으로 사용해야 한다면, 오버헤드 및 우선순위 문제와 관련한 솔루션 업체의 옵션을 신중하게 검토해야 한다. 

보안의 경우도 마찬가지다. SD-WAN이 특정 사용자-애플리케이션 관계를 인식할 수 있다면 중요한 관계에 높은 우선순위를 부여할 수 있을 뿐만 아니라 가능한 모든 사용자-애플리케이션 관계 중에서 실제로 허용되는 관계를 인식할 수도 있다. 이는 SD-WAN으로 더 나은 보안을 구축할 수 있음을 의미한다. 일부 SD-WAN 구현에는 이 정도 수준의 관계 인식이 포함되며, 일부는 보안 계층을 추가해서 이런 기능을 제공할 수 있다. SASE 기술을 추가하는 것이 대표적인 예다.

추가 애플리케이션 및 관계 인식은 도움이 될 수 있지만, 이 정보로 무엇을 할 수 있는지를 아는 것이 중요하다. 예를 들어 부가적인 애플리케이션 인식 또는 SASE 기능은 보안을 개선할 수 있지만, 우선순위에 영향을 미치거나 SD-WAN 패킷에 대해 다른 경로를 선택해서 혼잡을 피할 수 있는가? 이런 모든 기능이 함께 기능한다면 정말 좋지만 그렇지 않은 경우도 있다. 
 

SD-WAN 오프램프 성능 

SD-WAN에서 잘 드러나지 않는 또 다른 문제는 트래픽이 SD-WAN 오버레이에서 나와 데이터센터로 들어가는 방법이다. “올라간 것은 반드시 내려와야 한다”는 말처럼, SD-WAN으로 올라간 것은 그 소규모 사이트가 연결하고자 하는 지점(클라우드 또는 데이터센터)에 이르면 내려와야 한다. 바로 오프램프(Off-ramp)이다. 오프램프 성능은 SD-WAN 구현마다 천차만별이다. 또한 성능 제약에 따라 모든 트래픽을 실어나를 여러 오프램프 요소도 필요하다. 이는 비용과 운영 복잡성을 늘리므로 얼마나 많은 오프램프 요소가 필요하고 무엇을 대상으로 이것을 실행할지를 사전에 파악해야 한다. 
 

관리형 서비스 또는 직접 운영  

마지막으로 고려할 질문은 “어떻게 관리할 것인가?”이다. 네트워크 운영 센터를 위한 숙련된 인력 채용에 어려움을 겪고 있다면, 방금 연결한 소규모 사이트의 문제를 해결하는 데 도움이 될 수 있는 최소한의 지식을 갖춘 현장 인력을 구하는 것이 얼마나 어려울지 상상해 보라. 

관리 기능은 SD-WAN의 성공을 위해 매우 중요하며, 전 세계를 포괄하는 SD-WAN 애플리케이션에는 이 기능만으로는 부족할 수 있다. 하드웨어와 소프트웨어를 구매해 직접 구축하는 대신 서비스 업체 또는 매니지드 서비스 업체(MSP)의 SD-WAN을 이용하는 방법도 고려해야 한다. 최근 컴캐스트(Comcast)의 MSP 매서지(Masergy) 인수를 통해 알 수 있듯이 관리형 SD-WAN 옵션은 발전 및 변화하고 있으므로 잘 살펴보는 것이 좋다. 

그저 SD-WAN을 구매하고 싶다고 생각한다면 잘못된 생각이다. ‘나만의’ SD-WAN을 구매한다고 생각해야 한다. 나의 모든 요구사항, 미처 생각하지 못한 요구사항까지도 충족하는 SD-WAN이 필요하다. 요구사항과 기능을 대조해가면서 사전에 살펴보면 값비싼 실수를 미연에 방지할 수 있다. editor@itworld.co.kr


X