글 : 마티아스 코콧 주니퍼 네트웍스 데이터센터 프로덕트 라인 매니지먼트 부문 부사장

요즘 대규모 네트워크 관련 설문조사를 실시하면 분산(Distribution)과 분리(Disaggregation)가 갈수록 지배적이라는 것을 알 수 있다. 앞서가는 조직들은 이동통신사 RAN(Radio Access Network)에서 서비스 프로바이더의 거대한 하이퍼스케일 에지 네트워크에 이르기까지 고급 서비스를 사용자에게 더 가깝게 배치하고 있다.

이 과정에서 중앙 클라우드 제어를 유지하면서 고객과 가까운 수천 개의 소규모 사이트에서 일부 기능을 실행하는 보다 유연하고 경제적인 방식으로 네트워크를 구축하고 있다. 이러한 분산 클라우드 아키텍처는 특정 사용 사례에서 서비스 프로바이더와 기타 대규모 네트워크 오퍼레이터에게 중요한 이점을 제공한다.

하지만 동시에 새로운 문제를 야기시키기도 한다. 분산 네트워킹 기능을 수용하는 지점은 대개 소규모이고 원격이며 공간 및 전력 제약이 많다. 이전에는 이 문제에 대해 단 하나의 해결책이 존재했었다. 바로 막대한 비용으로 수천 개 사이트 각각에 새로운 물리적 라우팅 어플라이언스를 배포하는 것이다.

그러나 오늘날 서비스 프로바이더와 네트워크 오퍼레이터에게는 또 다른 옵션이 있다. 바로 라우터를 클라우드 네이티브 소프트웨어로 배포하고, 기존 물리적 서버에서 실행하는 방법이다. O-RAN DU(Distributed Unit) 같은 다른 분산 애플리케이션과 동일한 물리적 서버를 사용하는 방식이다. 이는 대단히 효과적인 대안이다.

주니퍼 네트웍스는 J-CNR(Juniper Cloud-Native Router)을 통해 서비스 프로바이더가 이 옵션을 활용하도록 지원한다. 이 소프트웨어 전용 솔루션은 진화하는 대규모 분산 네트워크에 완벽하게 부합되는 완전한 클라우드 네이티브 패키지 형태로, 고객들이 선호하는 주니퍼와 주노스(Junos) 소프트웨어의 모든 장점을 제공한다.

주니퍼 클라우드 네이티브 라우터는 컨테이너화된 클라우드 네이티브 솔루션에서 하드웨어 기반 플랫폼과 동일한 다수의 고급 소프트웨어 기능과 주노스 경험을 전달한다.

J-CNR은 주노스 라우팅의 클라우드 네이티브 버전에 cRPD(containerized Routing Protocol Daemon)라는 관리 구성 요소와 x86 및 ARM 프로세서를 위한 콘트레일 DPDK(Data Plane Development Kit) 가상 라우터 포워딩 플레인이 결합된다.

클라우드 네이티브 환경에 배포된 J-CNR은 설계에 따라 쿠버네티스(오퍼레이터 및 컨트롤러 프레임워크를 활용하고, 쿠버네티스 CNI(Container Network Interface)를 통해 전체 네트워킹 기능을 보여준다.

J-CNR을 통해 서비스 프로바이더와 네트워크 오퍼레이터는 자본지출(CapEX)와 운영비영(OpEx) 절감이 가능하다. 이는 특히 수만 개의 사이트가 있는 분산 RAN 및 에지 네트워크의 경우 기존 하드웨어 어플라이언스보다 자본 투자가 훨씬 적게 요구되기 때문이다.

또한, J-CNR은 주니퍼의 물리적 라우터와 동일한 운영 모델을 지원하기 때문에, 운영팀은 동일하고 익숙한 소프트웨어 경험으로 다른 CNR 및 대규모 사이트의 물리적 라우터를 비롯한 전체 주니퍼 구축을 관리할 수 있다. 동시에 철저하고 강력한 클라우드 네이티브 솔루션으로 미래를 대비하고, 조직을 포지셔닝할 수 있다.

완전한 쿠버네티스 CNI 호환 솔루션인 J-CNR은 쿠버네티스 오케스트레이션을 통해 관리할 수 있다. 이는 클라우드 하이퍼스케일러가 개척한 운영 모델과 유사하며, 기존 가상화 솔루션보다 훨씬 간단한 구축 및 운영 모델을 제공한다.

소규모 사이트에서 주니퍼 고급 라우팅 기능을 클라우드 네이티브 소프트웨어로 배포해 효과적인 처리도 가능하다.

이제 서비스 프로바이더가 5G RAN 여정을 시작할 때 얼마나 많은 변화를 수행해야 하는지 생각해 보자. 5G는 이전 네트워크보다 훨씬 더 높은 RAN 밀도를 요구하기 때문에 4G 셀 사이트를 업그레이드하는 것만으로 대응이 충분치 않을 수 있다.

서비스 프로바이더와 네트워크 오퍼레이터는 훨씬 더 많은 사이트가 필요하다. 아마 추가적으로 수만 개의 사이트가 요구될 것으로 예상된다. 사용자는 이러한 사이트를 최대한 효율적으로 연결하기 위해 D-RAN(Distributed RAN) 아키텍처 적용을 고려할 것이다.

문제는 이러한 사이트가 전력과 공간 제약이 극심하고, 대부분 셀 타워 아래에 소형 설비함이 있는 형태라는 점이다. 하지만 분산 5G 클라우드 RAN의 복잡한 특성을 고려할 때, 여전히 고급 라우팅 기능이 필요하다. 또한 서비스 프로바이더는 수천 개 사이트를 관리해야하기 때문에 프로그래밍 방식으로 구동되는 라우팅 기능이 요구된다. 따라서 이러한 경우 J-CNR이 필요하다.

J-CNR은 DU 및 인텔 플렉스RAN 같은 기타 RAN 구성 요소를 실행하는 동일한 물리적 서버에 구축된 D-RAN/5G 클라우드 RAN 전략에 최적화 돼 있다. 두 개의 박스를 하나로 통합해 공간, 전력 등을 절약하면서 물리적 어플라이언스에 비해 자본지출을 대폭 낮춰 준다.

하이퍼스케일러-텔코 VPC(Virtual Private Cloud) 상호 연결과 같은 사용사례도 살펴볼 필요가 있다. 클라우드 네이티브와 관계없이 J-CNR은 기본적으로 주니퍼 라우터다. 따라서 적당한 수준으로는 충분하지 않고, 최고 수준의 작동이 수반돼야 한다. 즉, 현재와 미래 모두의 구축, 구성, 수명 주기 관리를 위한 고객 운영 프레임워크에 완벽하게 부합돼야 한다.

이는 사소한 작업이 아니다. 최신 클라우드 네이티브 환경에서는 제어할 개별 소프트웨어 구성 요소의 수가 기하급수적으로 증가한다. 이는 기존 네트워크보다 훨씬 더 많은 규모다. 그리고 이러한 환경에는 변경하고, 커스터마이즈할 수 있는 측면이 너무 많기 때문에 기존 방식을 사용해 이를 자동화하려는 시도가 순식간에 무너진다.

클라우드 네이티브 복잡성이 통제 불능 상태로 커지는 일을 방지하는 유일한 방법은 확장 가능하고, 상품화된 자동화를 이용하는 것이다. 오늘날 클라우드 네이티브 소프트웨어에서 이는 쿠버네티스 오케스트레이션을 의미한다.

주니퍼는 전체 소프트웨어 패키지에 대한 CNI 추상화 구현과 간편한 관리를 지원하는 풀 쿠버네티스 오퍼레이터 확장 프로그램 개발을 비롯해 쿠버네티스를 통한 J-CNR 제어에 많은 노력을 기울여 왔다.

쿠버네티스에게 J-CNR은 다른 쿠버네티스 CNI와 유사하지만 매우 강력한 기능을 가져다준다. 동시에 전적인 오퍼레이터 지원은 불투명한 쿠버네티스 워크로드에 대한 풍부한 라우팅 관련 컨텍스트를 제공한다. 그 결과 고객은 쿠버네티스를 통해 J-CNR을 완전히 구성 및 제어하고, 수명 주기 관리할 수 있다.

그리고 기존 요소 관리 시스템에서 탈피해 자동화된 클라우드 네이티브 운영 모델로 전환할 수 있다. 적어도 당분간은 클라우드 네이티브 라우터가 네트워크의 많은 부분에서 기존 고성능 라우팅 어플라이언스를 대체할 수 없을 것이다. 그러나 클라우드 네이티브 라우터는 기존 인프라를 확장하는 유연하고 새로운 방법과 분산되고 세분화된 네트워크의 이점을 얻을 수 있는 강력한 전략을 제공한다.