통신사를 위한 Kubernetes 맞춤화
IT 세계에서는 쿠버네티스가 어디에나 있습니다. 43,000명 이상의 기여자의 지원을 받은 이 오픈소스 시스템은 클라우드에서 최신 애플리케이션을 배포하는 기본 방법이 되었습니다. 왜? 간단히 말해서, 쿠버네티스는 개발자의 삶을 훨씬 편리하게 만들어 앱 출시 속도를 높이고, 최종 사용자를 위한 기반 플랫폼의 가치를 높여줍니다.
쿠버네티스(k8s라고도 함)는 통신사들이 폐쇄형 플랫폼에서 개방형 플랫폼으로 전환을 모색함에 따라 최근 통신 업계에서 주목을 받고 있습니다. 이 시스템은 단독형 5G 네트워크의 장점을 최대한 활용하는 데 필요한 유연한 클라우드 네이티브 아키텍처의 본질적인 부분이 될 예정입니다. 진정한 클라우드 네이티브 네트워크는 신속한 서비스 및 자동화 배포부터 훨씬 더 높은 복원력과 효율성까지 수많은 이점을 제공합니다. 예를 들어 Google은 Kubernetes의 전신인 내부 플랫폼인 Borg를 사용하여 주당 20억 개가 넘는 컨테이너를 배포합니다.
이러한 유연성과 확장성은 통신사 클라우드 비전의 기본입니다. 즉, 5G 네트워크가 타사가 개발한 다양한 서비스와 앱을 위한 다재다능한 플랫폼이 된다는 아이디어입니다. 쿠버네티스를 사용하면 통신사가 휴대용 컨테이너에 앱을 배포할 수 있으므로, 예를 들어 서비스를 네트워크 가장자리, 최종 사용자에게 더 가깝게 가져와서 대기 시간을 줄일 수 있습니다.
개발자에게 추상적이고 매력적
그렇다면 쿠버네티스는 실제로 무엇을 하는가? 최신 애플리케이션은 일반적으로 다양한 마이크로서비스로 구성되며, 각각은 주문 관리, 보고, 지불 등 특정 기능을 처리합니다. 마이크로서비스가 컨테이너에 패키징되면 쿠버네티스는 배포, 확장 및 관리를 자동화합니다. 쿠버네티스는 마이크로서비스 클러스터에 장애가 발생하는 경우 자동 복구를 지원할 수도 있습니다.
가장 중요한 점은 쿠버네티스가 앱 개발자를 위해 기본적인 내부 네트워킹 복잡성 중 일부를 추상화한다는 것입니다. 이는 일반적인 앱 개발자의 작업을 훨씬 더 수월하게 만들어줍니다. 본질적으로 쿠버네티스를 사용하면 간단하고 직관적인 방식으로 앱에 외부 액세스를 제공할 수 있습니다.
쿠버네티스 인그레스 컨트롤러는 최종 사용자가 HTTP 프로토콜을 통해 웹 애플리케이션과 상호작용하는 통로입니다. 인그레스 컨트롤러는 또한 트래픽 관리를 제공하여 사용자 요청이 Kubernetes 클러스터 내의 올바른 마이크로서비스로 라우팅되도록 보장합니다.
통신사들은 다르게 생각해야 합니다
이러한 모든 이점은 5G 네트워크의 서비스 기반 아키텍처를 통해 활용할 수 있지만, 이는 통신사가 새로운 사고방식을 채택하는 경우에만 가능합니다. 쿠버네티스는 많은 이점을 제공하지만, 이 시스템은 통신 엔지니어가 익숙한 것과는 다소 동떨어져 보일 수 있습니다. 통신사는 네트워킹에 종사하고 있기 때문에 네트워킹 장비의 IP 주소를 수동으로 구성하고 라우팅 및 부하 분산에 대한 자체 규칙을 설정하며, Kubernetes가 추상화하도록 설계된 기타 매개변수도 편안하게 처리할 수 있습니다.
그러나 이런 종류의 수동 구성은 Kubernetes의 전체적인 요점을 훼손합니다. AWS와 Azure와 같은 주요 클라우드 플랫폼의 특징인 빠른 배포와 자동 확장을 구현할 수 없게 됩니다. 통신사들이 4G 네트워크에 구축한 최초의 네트워크 기능 가상화(NFV) 솔루션은 수동 스크립팅을 사용하는 경향이 있었으며, 결과적으로 현대 IT 아키텍처의 역동성과 자동화가 부족했습니다.
둥근 구멍에 사각형 못이 박혔나?
5G 핵심 네트워크의 출시로 통신사들은 새로운 미래를 맞이하게 되었습니다. 하지만 불행히도 표준 Kubernetes 시스템을 그냥 이식할 수는 없습니다. 대다수의 통신사는 4G 네트워크와 함께 5G 네트워크를 구축하고 있으므로 HTTP뿐 아니라 SCTP, Diameter, GTP와 같은 표준 통신사 프로토콜도 지원할 수 있는 Kubernetes 인그레스가 필요합니다. 그 이유는 5G 서비스를 프런트엔드하는 Kubernetes 인그레스가 HTTP를 통해 사용자와 직접 인터페이스하지 않고 대신 다른 4G 및 5G 핵심 요소에 연결하기 때문입니다. 어떤 경우에는 HTTP/2 메시지를 Diameter 메시지로 변환하거나, 반대로 변환하는 상호 운용 기능이 필요합니다.
또 다른 문제는 애플리케이션 클러스터 내에서 내부 통신을 지원하는 방법입니다. 표준 쿠버네티스 배포에서는 일반적으로 서비스 메시를 사용하여 서로 다른 마이크로서비스 간의 통신을 안전하게 관리하고 추적합니다. 이러한 서비스 메시는 IT 중심 추적 기능을 지원하지만, 통신사들은 관련 기능이 자사 요구 사항에 맞게 최적으로 조정되지 않았다는 사실을 알게 되었습니다.
세 번째 문제는 쿠버네티스 클러스터 내의 5G 기능이 외부 세계와 어떻게 통신할 것인가입니다. Kubernetes가 할당한 동적 내부 IP 주소를 공개하는 것은 좋은 생각이 아닙니다. 주소는 시간이 지남에 따라 변경되며, 이 수준의 가시성을 외부에 공개하는 것은 심각한 보안 위험이 될 수 있습니다. 통신사들은 특정 5G 기능에 대한 IP 주소 할당을 완벽하게 제어하고 싶어합니다. 이는 5G 기능을 구성하는 기본 컨테이너에서 사용하는 IP 주소와는 독립적이어야 합니다. 이를 달성하려면 스마트한 Kubernetes 이그레스 기능이 필요합니다.
왜 지름길을 가는 것이 나쁜 생각인가
한 가지 옵션은 쿠버네티스를 사용하지 않고 외부에서 접근할 수 있는 정적 IP 주소가 있는 컨테이너에 5G 기능만 배포하는 것입니다. 하지만 이런 식으로 비용을 절감한다면 확장성과 유연성 측면에서 큰 대가를 치르게 될 것입니다. 예를 들어, 버튼 하나만 눌러도 네트워크 어디에도 5G 기능을 배포할 수는 없습니다. 미래가 될 그 수준의 자동화를 원한다면 Kubernetes를 사용하여 지름길을 갈 수 없습니다.
F5는 오랫동안 통신 및 IT 업계에 종사해 왔으며, 통신사가 Kubernetes의 광범위한 이점을 활용할 수 있도록 돕는 방법을 알아냈습니다. 여기에는 Kubernetes 인그레스가 HTTP뿐만 아니라 통신사 프로토콜도 지원할 수 있도록 하는 BIG-IP SPK 솔루션이 포함됩니다. 또한 네트워크 주소 변환(NAT) 및 라우팅을 사용하여 Kubernetes 송신부가 클러스터의 내부 역동성에 영향을 주지 않고 외부에 정적인 사전 정의된 IP 주소를 제공할 수 있습니다. 클러스터 내부에서 무슨 일이 일어나더라도 항상 외부 엔터티에 동일한 IP 주소를 제공할 수 있습니다. 또한, Aspen Mesh 서비스 메시는 '통신사 수준'의 관찰 및 추적을 지원합니다. 이를 통해 통신사는 5G 마이크로서비스 간 트래픽 흐름에 대한 완전한 가시성과 추적을 확보하여 보안을 강화할 수 있습니다.
올바르게 접근하면 쿠버네티스는 통신사에 진정한 혁신을 가져올 수 있습니다. 클라우드 기반 아키텍처의 많은 이점을 활용할 수 있고, 통신사가 외부 세계와 상호 작용하기가 훨씬 쉬워질 수 있습니다. 이 오픈소스 시스템이 통신 환경에 완벽히 맞춰지면 5G 미래에 없어서는 안 될 부분이 될 것입니다.
이 기사는 2부로 구성된 시리즈의 첫 번째 기사입니다. 다음 시간에는 F5 기술이 다양한 플랫폼에서 실행되는 수많은 Kubernetes 클러스터에서 IT 및 통신사 워크로드를 관리하는 운영상의 어려움을 어떻게 해결할 수 있는지 살펴보겠습니다.