네트워크

IDG 블로그 | 터널 네트워크의 13가지 기술 부채

Patrick MeLampy | Network World 2018.07.19
네트워킹에서 터널(Tunnel)은 몇 가지 문제점을 해결했지만 결국에는 전부 치러야만 하는 엄청난 수의 장기적인 기술 부채를 유발했다.

네트워킹용 터널은 좋지 않다. 우리는 수면 아래에서 통행을 가로막고 있는 매우 협소한 공간이 있는 터널 끝에 갇혀 있던 12명의 태국 소년들에게서 실제 사례를 볼 수 있다. 터널은 소년들에게 하나의 출구만을 제공했는데, 바로 그 길을 지나갈 수 없었다. 이런 상황이 네트워크에서 일어나고 있다. 우리는 이 용감한 소년들의 영웅적인 구출에 감사하지만, 네트워크가 항상 그렇게 잘 돌아가는 것은 아니다.

Image Credit : GettyImagesBank

터널 기반 가상 네트워크가 네트워킹 영역에서 경이로운 차세대 트렌드라는 이야기를 들어봤을 것이다. 사실, 한 애널리스트는 필자에게 터널은 대단하다고 말했다. 물론 터널은 대단하다. 처음 의도된 목적으로 사용할 때는 그렇다. 하지만 패킷의 집합체(Aggregate)를 다른 방법으로는 가지 않을 곳으로 이동하기 위해 터널을 사용하는 것은 위험하며, 이는 기술적인 부채를 더 쌓는 일이 될 것이다.

다음에서 설명하는 대부분 사례에서 사용자, 플로우, 그리고 애플리케이션의 집합체용으로 터널이 사용되고 있다. 이런 방식으로 터널을 사용하면, 우리는 엄청난 기술적 부채를 지게 되는 것이며, 필자는 언젠가 심판의 날이 올 것이라고 예상한다.

하나. 하나의 집합체로 라우팅하고 단 하나의 경로만 사용
안전한 터널은 백본 라우터에 대한 오랫동안 지속되는 하나의 네트워크 플로우처럼 보인다. 라우터와 스위치는 단일 터널 플로우를 단일 경로로 “해시(Hash)”한다. 해당 경로 상에 다른 무엇이 있는지, 또는 시간 경과에 따른 현재의 상태를 알지 못하기 때문에, 터널 성능은 아주 오랜 기간 동안 단일 경로에 종속되어 있다. 경로의 성능이 저하되어도 더 나은 경로로 우회할 수 있는 능력을 상실한다.

둘. 터널은 흐름 제어(Flow Control) 기능이 없어 다중 미디어에 취약
지점(Branch Office)과 데이터센터는 네트워크보다 훨씬 더 빠르게 네트워크 데이터를 송수신 할 수 있다. 이때 애플리케이션 속도를 늦추기 위해 라우터는 패킷을 폐기(Drop)한다. 애플리케이션은 패킷이 폐기되면 속도를 늦춰야 한다는 것을 안다. 터널 프로토콜에는 흐름 제어, 윈도우 크기 제어, 또는 재전송 기능이 없다. 터널은 내부 애플리케이션이 스스로의 이익을 위해 자체적으로 이 기능을 제공할 것을 요구한다. 그래서 터널에 하나의 애플리케이션만 있다면, 완벽하게 동작할 것이다. 네트워크가 애플리케이션을 늦추고 싶은 경우, 그냥 터널 패킷을 폐기하면, 해당 애플리케이션이 늦어진다. 애플리케이션의 집합체용으로 터널이 사용될 경우, 다중 미디어(음성/비디오 그리고 웹 트래픽)의 경우, 그 결과는 매우 부정적이고 예측 불가능한 것이 될 수 있다.

SD-WAN 업체는 터널에 “진입할 때 QoS를 지정해서 제공하고 있다”고 말할 것이다. 이런 방식은 효과가 없을 뿐이다. 100개의 고유 세션을 가지고 있는 터널을 생각해보자. 101번째 세션이 추가되면, 네트워크가 “속도를 늦춰지기”를 기다리면서 자신의 “대기 상태”를 거치는 데, 네트워크는 기존 세션의 패킷을 폐기할 가능성이 높아서 엉뚱한 세션을 늦춰버린다. 코어 라우터는 “세션을 늦추기 위해” 집합체 플로우에서 패킷을 폐기하는데, 터널에서 “늦춰야 하는” 세션의 패킷이 아닐 가능성이 높다. 결국 엉뚱한 세션을 늦춰서, 새로운 플로우가 “가속화되게” 만든 것이다. 각각의 고유 세션이 커널에 있지 않았다면, 코어 라우터는 각각의 세션을 개별적으로 취급해서 올바른 플로우의 올바른 패킷을 폐기했을 것이다. 미디어 플로우는 일관성 있고 예측가능 하지만, 버스티(Bursty: 간헐적으로 트래픽이 폭주하는) 웹 트래픽과 섞이면, 패킷 폐기 가능성은 극적으로 증가한다. SD-WAN 공급업체는 이를 알고 있으며 솔루션으로 미디어 패킷 복제나 미디어에 대한 FEC(Forward Error Correction: 순방향 오류 정정)를 제공하고 있다. FEC는 기술적 부채에 대역폭을 추가한다.

셋. 네트워크 용량의 30% 낭비
터널은 송신되는 패킷당 많은 대역폭을 부가한다. 표준 인터넷 트래픽 혼합체의 경우, 추가 대역폭이 30% 이상이라는 사실은 잘 알려져 있다. 전체 전송 비용에 1.3을 곱하라. 그것이 터널 사용에 따른 장기 비용이다.

넷. 유효 패킷 크기 감소
많은 최신 프로토콜은 송신할 수 있는 최대 크기의 패킷을 알아낸다. 터널이 사용될 경우, 최대 가용 패킷 크기가 줄어든다. 커다란 파일이나 많은 양의 데이터를 이동할 필요가 있을 경우, 더 많은 수의 패킷이 필요하게 되어 동일한 양의 데이터를 전송하는 데 더 많은 시간이 든다.

다섯. 패킷 파편화(Fragmentation) 증가
하나의 패킷이 터널에서 지원되는 것보다 더 큰 경우, 터널에 들어가자마자, 해당 패킷은 2개 이상의 패킷으로 쪼개진다. 패킷 조각은 2개 또는 그 이상의 패킷으로 송신되고, 나중에 반대편에서 재조립된다. 이는 처리 성능, 메모리, 그리고 추가 CPU를 차지한다. 라우터가 쪼개진 조각 중 하나를 폐기하기라도 하면, 많은 부작용이 따른다.

여섯. 터널 설정 지연으로 회선 복구 속도 저하
터널이 설정될 때, 보안 키 협상을 위한 물리적인 시간이 필요하다. 보통은 문제가 되지 않지만, 커널 커넥션을 폐기하거나 이동할 필요가 있는 경우, 지연으로 인해 모든 내부 애플리케이션의 재시작을 유발할 수 있다.

일곱. 네트워크 라우팅 기능 비활성화
터널은 모든 내부 플로우를 모호하게 만들어서 네트워크 코어에 유용한 정보를 거의 제공하지 않게 된다. 사실 설계상 의도된 것이다. 그렇지만, 이는 코어 네트워크가 라우팅이나 보안 기능을 제공하지 못하게 한다. 예를 들면, 통신 사업자가 차등화 서비스를 제공하는 경우, 해당 터널 소유자가 이런 서비스를 활용하지 못하게 될 것이다. 터널 내부에서 DoS(Denial of Service: 서비스 거부) 공격이 감행될 경우, 코어 네트워크는 그것을 막는 데 줄 수 없게 된다.

여덟. 쓸모 없어진 네트워크 툴
네트워킹 엔지니어들은 네트워크가 동작하지 않는 이유를 알아내기 위해 종종 여러 가지 툴을 사용한다. 이런 툴 대부분은 터널이 있는 데서는 올바르게 동작하지 않거나 매우 오해의 소지가 있는 결과를 제공할 수 있다. 네트워크 프로브(Probe)는 대개 터널 내부에서는 데이터를 확보할 수 없어서 프로브 사용을 무용지물로 만든다.

아홉. 집합체 사용 터널의 기본 보안 규칙 위반
네트워크를 브리지(Bridge)하지 말지어다! 터널은 네트워크 간의 주소 공간을 쌍방향으로 결합한다. 이는 기본적으로 2개의 네트워크 간의 문호를 개방한다. 그 결과 더 많은 부작용을 낳으므로 터널 사용에 따른 보안 위험을 관리하기 위해 조치를 취해야만 한다.

열. 재암호화로 인한 불이익
모든 최신 소프트웨어 애플리케이션은 암호화를 사용하고 있다. 암호화는 이제 거의 무료이며, 암호화를 사용하지 않는 것은 태만한 일일 것이다. IPSec 터널도 암호화를 사용하고 있다. 그러므로, 터널화된 대부분의 최신 애플리케이션의 경우, 암호화가 2번 수행되어서, 아무 이득도 없이, CPU와 대역폭만 낭비한다.

열하나. 현행 베스트 프랙티스가 요구하는 2개의 터널
터널을 지원하고 있는 네트워크도 장애를 일으키기 때문에, 대부분의 터널 사용자들은 각 통신 경로에 대해 2개의 터널이 존재할 것을 요구하고 있다. 이는 AWS와 애저를 사용하는 네트워킹에서 표준 관행이기도 하다. 각 터널은 사용 준비 상태를 유지하기 위한 오버헤드를 가지고 있으며, 이는 이미 누적된 채무에 부채를 추가한다. 2개의 터널을 가짐으로써 몇 가지 라우팅 문제가 발생한다. 현재 베스트 프랙티스는 라우팅 루프(Routing Loop)를 방지하기 위해 터널에 BGP를 구동하는 것이다. 터널 내부에서 BGP 실행하는 비용도 누적 채무에 추가된다.

열둘. 터널은 망 분리를 지원하지 않음
IPSec 터널은 VLAN을 지원하지 않는다. 안전한 망 분리(Network Segmentation)을 모색하고 있는 고객들은 흔히 사용자 그룹을 서로 분리하기 위해 각 세그먼트 별로 개별적인 터널을 사용하거나 MP-BGP와 VRF를 사용할 수밖에 없다. 지점 숫자가 많지 않더라도, 금방 불안정해진다.

열셋. 허브 앤 스포크(Hub-and-Spoke)
모든 사이트들 간의 n 제곱 개의 터널 집합을 관리하는 복잡성을 회피하기 위한, 현 베스트 프랙티스는 브랜치 분지(Spoke)를 가지고 있는 데이터센터 거점(Hub)을 제안하고 있다. 이 방식은 한 지점에서 다른 지점으로 움직이는 실시간 미디어를 제외한, 모든 상황에서 잘 동작한다. 하지만 점증적 지연시간과 낭비된 대역폭은 기술 부채에 추가된다.

터널 개수가 커지고 기술 부채가 너무 많아지면, 터널을 사용하지 않는 네트워킹 해결책을 모색하기 바란다. 네트워킹 전문가들은 터널 없이, 그렇지 않으면 가지 않을 곳으로 패킷을 보낼 수 있는 방법을 찾아냄으로써 문제를 해결해야 한다. 필요한 것은 라우팅 계층에서의 혁신이다.

*Patrick MeLampy는 128 테크놀로지(128 Technology)의 공동 설립자 겸 COO이다.  editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.