전통적인 IP 네트워킹이 클라우드에 맞지 않는 이유

그동안 기업의 클라우드 전환은 놀라운 속도로 이뤄졌다. 불과 몇 년 사이 대부분의 대기업에서 클라우드 전략이 필수 요소가 됐다. 그러나 필자가 접한 고객과 파트너는 클라우드 여정, 특히 클라우드 네트워킹 측면의 어려움을 토로하는 경우가 많았다.
 

가장 큰 문제 중 하나는 레거시 스택의 전통적인 IP 네트워킹이 클라우드를 문제없이 지원할 것이라는 생각에서 비롯된다. 지나고 보니 복잡성만 늘고, 클라우드 제공업체가 서비스를 만들거나 액세스하는 방식과 잘 맞지도 않는다.

전체적인 전략을 보면 그럴듯하다. 기업은 데이터센터 전용으로 만들어진 전통적인 IP 네트워킹 툴을 가져와 그 가상 버전을 클라우드에 풀어놓는다. 그러나 네트워킹은 전체 문제의 절반, 또는 3분의 1 정도에 불과하다. 클라우드로 이전하는 기업은 보안과 애플리케이션 성능, 비용도 고려해야 한다.

VPC, VNET, 방화벽이 복잡하게 뒤얽힌 IP 네트워킹 전략이 클라우드 연결에 적합하지 않은 기술적인 이유, 그리고 기업의 클라우드 네트워킹에 근본적으로 새로운 접근 방식이 필요한 이유를 살펴보자.
 

애플리케이션 관찰 가능성의 제약

물론 IP 네트워킹 계층은 데이터센터를 클라우드에 연결하는 수단을 제공한다. 그러나 레거시 네트워킹이 가진 주요한 한계 중 하나는 오늘날 기업의 핵심 가치이자 클라우드를 도입하는 주된 이유라고도 볼 수 있는 클라우드의 애플리케이션에 대한 시야가 제한적이라는 점이다.

계층 7 또는 애플리케이션 계층에서 기업은 그 수준(애플리케이션과 서비스 모음)과 TCP 및 UDP 포트, IP 엔드포인트와 같은 하위 스택에서 일어나는 일에 대한 전체적인 시야를 얻을 수 있다. 그런데 IP 계층 같은 전통적인 스택만으로 운영하는 경우 스택의 위에 존재하는 요소를 보는 것은 상당히 어렵다. 네트워크 자체에 대한 시야만 있고 그 외의 모든 것이 사각지대가 된다.

이게 왜 문제가 될까? 무엇보다 성능 문제가 발생할 경우 이로 인해 해결 시간이 상당히 길어질 수 있다. 기업은 애플리케이션 성능을 맞추기 위해 애플리케이션 및 A/B 테스트 구성과 관련해 클라우드 인프라가 어떻게 작동하는지 이해해야 한다. 그러나 네트워크 수준에서 기업은 성능과 보안에 대해 전체적인 정책만 적용할 수 있다. 서비스나 애플리케이션의 일부에만 문제가 발생한다면 어떻게 될까? 전체 인프라 스택에 대한 시야가 없으면 정확히 어디에 문제가 있는지 찾아내기가 매우 어려울 것이다.
 

성능은 나중에 생각

비슷한 맥락에서, 기업은 다양한 애플리케이션의 저마다 다른 지연, 성능, 보안 요구사항을 고려해야 한다. 예를 들어 애플리케이션 하나에만 스테이징, QA, 프로덕션 등 성능과 지연 목표치가 다른 3가지 버전이 필요할 수 있다. 스테이징의 애플리케이션에서는 성능 최적화가 불필요할 수 있지만 프로덕션 워크로드라면 당연히 성능 최적화가 필수다.

IP 네트워크 계층에서는 이렇게 여러 갈래로 나뉘는 목표를 달성하는 것이 불가능하다. 반면 애플리케이션 계층에서는 다양한 애플리케이션 유형을 대상으로, 클라우드와 클라우드 제공업체 또는 온프레미스 인스턴스 전반에 걸쳐 일관된 정책을 적용할 수 있다. 실제로 URL 다시쓰기 또는 FQDN 필터링과 같은 클라우드 기능을 DNS 스누핑과 함께 사용하면 IP에 손을 댈 필요도 없이 이와 같은 목표를 달성할 수 있다. 또한 HTTP, HTTPS 등 모든 애플리케이션 유형에 대해 애플리케이션 프로파일을 기반으로 속도 제한 또는 스로틀링을 적용하거나 GSLB 스타일의 기능을 사용해 트래픽을 조정할 수 있다. 거창한 툴은 필요 없다.
 

운영 복잡성의 증대

그 외에 많은 기업과 파트너가 전한 고충은 레거시 네트워킹이 클라우드에서 상당한 운영 복잡성을 유발할 수 있다는 점이다. 예를 들어 데이터센터를 클라우드에 연결하거나 다양한 클라우드 환경을 연결하기 위해 필요한 모든 VPC 또는 VNET에 대해 허브/스포크 게이트웨이를 유지해야 한다.

게다가 이러한 연결 메시에는 부가적인 경로, 정책 조율이 필요하고 이로 인해 복잡성이 가중된다. ICMP 또는 트레이스라우트와 같은 네트워크 툴은 IP 수준 진단만 제공하며 애플리케이션 계층의 문제에는 대처하지 못한다. 앞서 언급했듯이 기업은 네트워크를 최적화하기 위해 애플리케이션에 대한 심층적인 시야가 필요하다. 포트 수준 또는 프로토콜 수준의 시야만으로는 충분하지 않다. 구체적으로, 기업은 실시간 사용자 모니터링(RUM)과 함께 사용자와 애플리케이션 간의 연결에 대한 상세한 내용(문제를 유발했을 가능성이 있는 그 사이의 모든 홉 포함)가 필요하다.

그러나 레거시 네트워킹에서 네트워크 분할은 일반적으로 비즈니스 로직과 연결되지 않는다. 예를 들어 클라우드 IP는 자주 변경된다. 이는 IP 주소가 지속적이지 않고 따라서 불필요한 경로 스케일을 유발함을 의미한다. 결과적으로 중첩된 IP 주소가 발생할 뿐만 아니라 클라우드의 사용자 ID와 애플리케이션 엔드포인트 이름이 바뀌지 않는다고 해도 담당 팀은 끊임없이 IP 범위의 화이트리스트/블랙리스트를 유지관리해야 한다. 마찬가지로 서비스형 플랫폼(PaaS) 툴과 클라우드 네이티브 서비스는 IP로 라우팅되는 것이 아니라 리소스 이름과 URL로 라우팅된다.

마지막으로 지역 및 클라우드 간 연결에 필요한 IPsec 터널은 확장할 수 없으므로 오류와 보안 사각지대가 발생하기 쉽다. 대신 mTLS 또는 HTTPS가 클라우드 및 지역 간 연결에 필요하다. 이와 같은 보안 연결 프로토콜은 더 많은 운영 오버헤드를 일으킨다. 각 클라우드에 대해 네트워킹 전문 기술, 엔지니어링 리소스, 유지보수 비용이 필요하기 때문이다. 또한, 클라우드 내부와 클라우드 간의 네트워크 흐름에 대한 시야를 거의 0에 가깝게 축소한다.
 

보안 측면의 어려움

사각지대의 문제는 클라우드 보안 관리의 심각한 문제이기도 하다. 근본적인 원인은 수많은 클라우드 인스턴스, 지역, 제공업체에 걸쳐 수많은 개별 네트워크 보안 정책과 가상 방화벽을 관리해야 한다는 데 있다. 클라우드 네이티브 워크로드가 확장되고 축소되는 상황에서 보안을 유지하는 것은 거의 불가능한 일이다. 네트워크와 보안 팀은 극심하게 복잡하며 끝나지도 않는 두더지 게임에 직면한다.

물론 클라우드 기반 워크로드는 애플리케이션에 초점을 둔다. 그러나 보안 관점에서 애플리케이션 엔드포인트를 기반으로 네트워크를 분할하는 것은 불가능하다. 또한 레거시 네트워킹 계층으로는 제로 트러스트 네트워크 액세스(ZTNA) 전략의 핵심 구성요소인 사용자와 기기를 지속해서 인증하거나 맥락 또는 행동 인식 데이터를 얻는 것도 불가능하다.

또한, 클라우드 환경 전반적으로 IP 주소가 중복되고 겹칠 가능성이 있는 상황에서 IP 주소 관리는 보안 위험을 야기한다. 근본적으로 IP 주소로는 클라우드 네트워킹을 실현할 수 없다. 클라우드 네트워킹은 ID, 즉 네임스페이스와 서비스 엔드포인트를 사용해 실현된다. 따라서 기업의 클라우드 네이티브 보안에는 애플리케이션 수준에서 이뤄지는 근본적으로 새로운 접근 방법이 필요하다.
 

클라우드 네트워킹의 길

기업은 빠른 속도로 클라우드로 이동하면서 초기에는 전통적인 네트워킹 접근 방식이 안정적인 연결 수단을 제공한다고 생각했다. 그러나 이제는 클라우드를 도입하고 확장하는 과정에서 레거시 네트워킹으로 인해 복잡성이 기하급수적으로 증가하고, 애플리케이션 성능과 보안, 비용을 관리할 마땅한 방법이 없다는 현실에 직면해 있다. 이제 클라우드 네트워킹을 간소화하고 클라우드 네트워킹을 애플리케이션 계층으로 옮겨야 할 시점이다. editor@itworld.co.kr