클라우드 네이티브 네트워킹 여정 탐색의 주요 고려 사항

클라우드 네이티브 네트워킹으로의 이동은 선도적인 통신업체 및 네트워킹 공급업체가 웹 스케일 세계의 성공에서 교훈을 얻은 후 이를 ​​비즈니스 및 네트워크 발전에 적용할 수 있다는 깨달음에서 시작되었습니다. 5G 코어, 에지 컴퓨팅, SASE 배포 또는 엔터프라이즈 디지털 변환 등 모두 네트워크 설계에 클라우드 네이티브 원리를 수용하고 있습니다. 네트워킹 산업은 하이퍼 컨버지드 인프라, 클라우드 네이티브 네트워크 기능(CNF), 서비스 메시 계층, SDN 지원 네트워크 오케스트레이션 및 자동화 솔루션을 제공하여 클라우드 시대의 네트워크를 실현하고 있습니다.

클라우드 네이티브 원리와 이를 클라우드 네이티브 네트워크에 적용하는 방법

서비스, 애플리케이션 및 마이크로 서비스가 분산된 도메인 전체에 나타나 이러한 애플리케이션에 대한 탁월한 최종 사용자 경험을 선사하므로 우수한 확장성, 탄력성, 민첩성 및 보안 네트워크 연결이 있어야 클라우드 네이티브 네트워킹의 가능성을 실현할 수 있습니다.

다음은 클라우드 네이티브 네트워킹에서 고려해야 할 세 가지 주요 원리입니다.

1. 소규모 스테이트리스(Stateless) 마이크로 서비스 "빅 아이언" 어플라이언스 또는 본질상 모놀리식이었던 가상 어플라이언스는 이제 CNF를 구성하며 기능에 따라 분리된(종속성이 거의 없음) 소형(코드 크기, 계산 공간) 소프트웨어 요소로 구성된 마이크로 서비스 아키텍처로 전환되고 있습니다.

가능한 경우 이러한 개별 기능은 스테이트리스(즉, 마이크로 서비스를 호스팅하는 컨테이너는 컨테이너가 아닌 공통/공유 데이터베이스 또는 저장소에 상태를 저장)이며 변경 불가능한 구성 요소(즉, 컨테이너가 실행되면 이를 수정하지 않음)가 될 것입니다. 이러한 특성으로 인해 확장 및 업그레이드/다운그레이드를 훨씬 빠르고 효율적으로 수행할 수 있습니다. 서비스에 문제가 있을 때 서비스를 마지막으로 알려진 상태로 복원할 필요가 없기 때문입니다.

또한 마이크로 서비스 아키텍처는 모놀리식 애플리케이션과는 달리, 확장이 필요한 서비스만 확장할 수 있는 유연성을 자랑합니다. 더 작은 구성 요소가 컨테이너에 배포되기 때문에 결과적으로 축소 및 확장이 VM에서보다 훨씬 빠릅니다.

업그레이드와 마찬가지로, 업데이트된 소프트웨어로 새 컨테이너 인스턴스를 시작하고 이전 인스턴스를 끄면 중단 시간 없이 원활한 프로세스가 진행됩니다. 스테이트풀(Stateful) 서비스는 상태의 일관성 및 이동성을 해결해야 합니다. 이는 일반적으로 확장 및 업그레이드 중에 상태의 일관성을 유지하면서 하나 이상의 컨테이너에 복제를 요구합니다.

2. DevOps 및 자동화

민첩성과 점진적인 혁신을 가능하게 하려면 클라우드 네이티브 네트워크가 DevOps 모델을 채택해야 합니다.

앞에서 설명한 것처럼 스테이트리스 마이크로 서비스 아키텍처를 사용하는 클라우드 네이티브 네트워크 기능은 훨씬 더 많은 요소로 구성되는 경향이 있습니다. 또한 각 마이크로 서비스는 독립적으로 확장 및 축소되도록 설계되어 CNF 부하를 처리하기 위해 배포되는 각 마이크로 서비스에 여러 개의 인스턴스가 발생합니다.

이는 CNF를 인스턴스화하려면 수십 또는 수백 개의 컨테이너를 배포해야 한다는 것을 의미합니다. 이러한 배포를 수동으로 수행하는 것은 불가능하므로 CNF는 항상 배포 프로세스를 자동화하는 방식으로 조정됩니다. 마찬가지로 서로 다른 마이크로 서비스의 확장, 실패한 인스턴스 복구 등의 작업을 자동화하려면 오케스트레이션이 필요합니다. 수동으로 수행하기에는 너무 복잡하고 번거롭기 때문입니다.

일반적으로 네트워크 기능은 CLI 및 API로 조작되는 수백 또는 수천 개의 구성 옵션을 제공합니다. 기존 네트워크 구성은 원하는 구성 상태를 향한 일련의 단계를 따라 절차적으로 정의됩니다.

반대로 배포 및 구성에 대한 클라우드 네이티브 접근 방식은 선언적입니다. 원하는 배포 및 구성은 구조화 문서(YAML 및 HELM)에 자세히 설명되어 있으며 컨테이너 오케스트레이터에서 사용할 수 있습니다. 구성에 대한 선언적 접근 방식은 변경 사항을 훨씬 더 잘 제어하고 잘못된 구성이 네트워크에 주입될 가능성을 줄이며 DevOps 파이프라인에서 자동화할 수 있으므로 복구 속도를 크게 높입니다.

강력한 DevOps를 보장하기 위한 또 다른 중요한 측면은 서로 다른 공급업체의 CNF뿐만 아니라 서로 다른 마이크로 서비스를 상호 연결하여 엔드 투 엔드 서비스망을 생성하는 데 사용할 수 있는 잘 정의된 API를 보유하는 것입니다.

3. 플랫폼에 구애받지 않는 배포

결국 가장 중요한 것은 통신사와 기업이 벤더에 종속되지 않고 어디에나 배포할 수 있는 솔루션을 찾고 있다는 것입니다. 이론적으로 클라우드 네이티브 컨테이너 아키텍처는 COTS "플랫폼에 구애받지 않는" 방식으로 하드웨어, 온프레미스 또는 퍼블릭 클라우드에서 직접 애플리케이션과 네트워크를 실행하기 위한 밑그림을 제공합니다.

클라우드 네이티브 네트워크 사업자가 직면한 주요 과제

클라우드 네이티브 네트워킹은 분명 유망한 변화이지만 모든 혁신이 그러하듯 어려움이 없는 것은 아닙니다. 다음 섹션에서는 클라우드 네이티브 네트워크 사업자가 직면한 몇 가지 주요 과제에 대해 논의해 보겠습니다.

1. 레거시가 남긴 것 처리하기– 하룻밤 사이에 모든 것이 클라우드 네이티브가 될 수 없는 것이 현실입니다. 많은 사업자가 전환을 수행하면서 레거시 가상 네트워크 및 네트워크 기능을 다루고 있습니다. 또한 클라우드 네이티브 네트워크 기능은 충분히 분리된 마이크로 서비스가 아니기 때문에 네트워크 확장 및 운영이 더뎌집니다.

2. 움직이는 많은 부분, 많은 오류 발생 지점– 플랫폼에 구애받지 않는 여정은 모든 것을 분해하여 필요에 따라 네트워크를 변경할 수 있음을 의미합니다. 이러한 유연성은 네트워크 운영자에게 여러 벤더의 다양한 CNF 옵션과 함께 컴퓨팅, NIC, 컨테이너 오케스트레이터(OpenShift, TANZU, Kubernetes), 클라우드 인스턴스(AWS EKS, GCP GKE, Azure AKS)에 대한 다양한 옵션을 제공하여 오류가 발생할 수 있는 지점이 늘어날 수 있습니다. 최신 CPU, Kubernetes CNI 또는 Linux의 새로운 배포 버전으로 간단한 업그레이드를 실행할 때도 성능에 예기치 않은 결과를 초래할 수 있습니다. 움직이는 부분이 너무 많아 문제 해결과 근본 원인 분석이 훨씬 더 어려워집니다.

3. 탄력적인 확장의 영향 – 클라우드 네이티브 인프라는 로드 및 수요에 따라 워크로드를 동적으로 확장할 수 있습니다. 워크로드의 총 수명은 과거 몇 달, 몇 년의 주기와 비교했을 때 몇 분, 몇 시간으로 줄어듭니다. 이는 클라우드 기반 네트워크 및 서비스를 배포할 때 최종 사용자의 QoE(체감 품질) 저하를 최소화하면서 클라우드 인프라의 크기를 조정하고 비용을 최적화한다는 일련의 새로운 과제를 만듭니다. 또한 클라우드 네이티브 환경에서 네트워크 기능은 기본 인프라를 다른 서비스와 공유합니다. 이는 CNF 및 서비스의 성능을 보장할 때 멀티 테넌시("혼잡한 주변")에 대한 영향의 특성을 파악해야 그 영향을 보상할 수 있음을 의미합니다.

4. 보안 기능 내장 – 네트워크 보안 패러다임도 변화하고 있습니다. 컨테이너화된 환경의 민첩한 특성은 환경에 서비스를 제공하거나 이를 보호하는 미들 장비가 일련의 고유한 문제에 직면한다는 것을 의미합니다. 클라우드 네이티브 애플리케이션에는 수백 개의 서비스가 연결되는 경향이 있기 때문에 이제 컨테이너의 탄력적이고 동적인 특성을 더 빠른 속도로, 더 큰 규모로 처리해야 합니다. 네트워크 운영자는 애플리케이션 자산이 생성되는 즉시 보안 및 애플리케이션 정책이 자동으로 확장 및 축소되도록 하여 해당 리소스가 더 이상 존재하지 않을 때까지 모든 변경 사항을 추적해야 합니다. DevSecOps는 보안의 일부를 CI/CD 파이프라인에 통합하여 팀이 개발 단계에 보안을 도입하도록 권장합니다. 또한 이러한 정책이 성능 및 사용자 경험에 미치는 영향의 특성을 파악해야 합니다.

5. 복원력 발휘 – 복원력은 클라우드 네이티브 아키텍처의 또 다른 주요 과제입니다. 이 동적 환경에서는 문제 발생이 불가피하므로 분산된 마이크로 서비스 솔루션을 설계하고 클라우드 플랫폼 또는 컨테이너 오케스트레이션 엔진이 인프라 문제를 감지 및 완화할 수 있도록 하는 것이 필수입니다. 마이크로 서비스는 재시작 및 확장할 수 있으며 다른 노드로 다시 배포될 수도 있습니다. 마이크로 서비스가 작동할 것이라는 막연한 믿음을 가져서는 안 됩니다. 대신, CNF에서의 마이크로서비스 손상(예: 포드 오류, 노드 재부팅, 네트워크 지연, CPU 스파이크 등)에 따른 영향의 특성을 파악해야 합니다. 목표는 사전 프로덕션 중에 실제 오류를 에뮬레이션하여 문제를 선제적으로 발견한 후 CNF를 프로덕션 네트워크에 배포하는 것입니다. 이를 통해 복원 조치가 적용되는 적절한 임계값을 설정할 수 있습니다.

6. 지속적인 변화에 발맞추기 – 마지막으로, 클라우드 네이티브 환경의 변화 속도는 레거시 네트워크보다 10배 더 빠릅니다. 클라우드 플랫폼, NFVI 및 CNF를 제공하는 공급업체는 시장에 이전보다 훨씬 빠른 속도로 새로운 혁신을 계속해서 선보이고 있습니다. 네트워크 사업자는 업데이트 전의 기본 성능과 업데이트 후의 새로운 성능을 비교하여 인프라 구성 요소를 검증 및 최적화해야 통합 중인 변경 및 업데이트의 영향을 이해하고 강력한 지속적인 통합, 지속적인 개발 및 지속적인 테스트(CI/CD/CT) 사례를 확인할 수 있습니다.

클라우드 네이티브 환경 변화의 영향 이해

사전 예방적 테스트 및 지속적인 검증의 구현은 위에서 언급한 과제를 해결하는 데 매우 중요합니다. Spirent CyberFlood는 이제 컨테이너화된 환경에서 애플리케이션 성능 및 보안 테스트를 지원하여 온프레미스, VM, 퍼블릭 클라우드 및 컨테이너 환경에서 확장 가능하고 사실적인 애플리케이션 워크로드 에뮬레이션을 제공하고 클라우드 네이티브 네트워킹 솔루션의 성능, 사용자 경험 및 보안을 최적화하도록 지원합니다.

다음은 CyberFlood가 클라우드 네이티브 네트워크 준비를 지원하는 일부 핵심 사용 사례입니다.

1. OpenShift, AWS EKS 등과 같은 다양한 Kubernetes 구현의 성능을 테스트하여 적절한 크기의 클라우드 인프라, 클라우드 인스턴스를 만들고 올바른 NIC 드라이버, Linux 배포판 및 CNI로 최적화합니다.

2. 외부 대 클러스터 트래픽 에뮬레이션(북-남)을 실행하여 인그레스 컨트롤러의 성능과 규모를 검증합니다.

3. 실제 애플리케이션 워크로드로 NGFW, WAF, ELB CNF의 성능 및 탄력적 확장성을 벤치마킹합니다.

4. CNF의 복잡한 분산형, 하이브리드, 컨테이너형 배포를 검증합니다.

5. 성능 및 사용자 경험에 대한 보안 정책의 영향과 보안 효율성을 검증합니다.

6. 새로운 애플리케이션 또는 서비스의 배포 단계에서 반복 가능한 자동 테스트를 위해 포괄적인 API 지원을 제공하여 모든 CI/CD "파이프라인"에 원활하게 통합할 수 있도록 합니다.

CyberFlood가 사전 예방적 테스트 및 지속적인 검증을 통해 클라우드 네이티브 네트워킹 여정의 문제를 해결하는 방법을 알아보세요.