AWS 클라우드 환경에서 5G 코어 네트워크 재해 복구 시스템 구축

이 글은 AWS for Industries Blog에 게시된 Disaster Recovery 5G Core Network on AWS을 한국어로 번역 및 편집하였습니다.

통신 산업에서 통신 서비스 제공자(Communication Service Provider, 이하 CSP) 고객들은 퍼블릭 클라우드를 적용하여 활용할 수 있는 유즈케이스를 찾고 있습니다. 새롭게 5G 네트워크를 구축하거나 기업 고객을 위한 프라이빗 네트워크를 구축하는 등의 유용한 활용 사례를 통하여, 퍼블릭 클라우드와 AWS 상에 5G 코어 네트워크를 배포하는 것에 대한 관심이 커지고 있습니다. “AWS 환경에서의 5G 네트워크 진화” 백서에서 강조된 것 처럼, 리전, 가용영역, AWS Local Zones, AWS Outposts 등의 AWS 글로벌 인프라는 각 NF(Network Function)에서 필요로 하는 요구사항에 맞게 효과적이고 탄력적인 5G 코어 네트워크 구축에 필요한 환경을 제공합니다. 예를 들어, 사용자 데이터 패킷을 저지연(Low Latency)으로 처리 하기 위해 UPF(User Plane Function) NF를 AWS Local Zones 또는 AWS Outposts에 둘 수 있습니다.

AWS에 5G NF를 배포/운영하는 다양한 활용 사례들 중에서 5G 코어 네트워크를 이미 구축하여 운영하고 있는 CSP에게 가장 흥미로운 케이스는 재해 복구(Disaster Recovery, DR) 시스템이나 재해 상황에도 복원력 높은 네트워크 구축입니다. 이런 5G DR 네트워크는 전체 데이터 센터가 중단되는 장애 또는 유지 보수 기간(Maintenance Window) 동안 온프레미스(On-premise) 5G NF가 중단되는 상황에도 확장 가능하고 즉각적인 조치를 가능하게 합니다. 이러한 DR 네트워크는 재해와 같은 예기치 못한 장애나 계획된 중단과 같은 경우에만 운영되는 환경이기 때문에 빠른 스케일-인 또는 스케일-아웃 전략을 통해 비용을 최소화하여야 합니다. 기존 통신 국사 내에 모든 구성요소를 이중화 하여 DR 구성하는 것과 비교하여, AWS는 CSP의 비용 및 에너지 소모를 최소화 할 수 있습니다. 이를 통해 트래픽 급증 및 운영 중의 유지 관리와 같은 네트워크 변경이 필요로 하는 요구에 신속하게 대응할 수 있습니다.

이 게시물에서는 AWS를 5G 네트워크의 또 다른 가상 데이터 센터 환경으로 활용하여 “재해 복원력” 및 “재해 복구” 목표를 달성하는 방법을 설명합니다. 오토스케일, 자동화 도구 및 네트워크의 비용 최적화 측면과 같은 AWS 환경 내에서 3GPP 고가용성 개념을 구축/활용하는데 중점을 둡니다. 특히 Amazon Elastic Compute Cloud(Amazon EC2) 오토스케일그룹(Auto Scaling Group)이나 Amazon Elastic Kubernetes Service (Amazon EKS) 환경 내 수평적 파드(Pod) 오토스케일링, 클러스터 노드 오토스케일링 등과 같은 AWS에서 제공하는 오토스케일링 기능을 활용하면 DR 구성을 위한 VPC(Virtual Private Cloud) 내 컨테이너 기반 NF(Container Network Function, CNF)의 평상시 배포 규모를 최소화할 수 있습니다. 그리고 갑작스러운 트래픽 증가 상황이 발생한 경우 빠른 스케일-아웃을 통하여 급증된 트래픽을 처리합니다.

또한 AWS Graviton 인스턴스를 활용하여 5G 코어 NF를 구축하고 기존 온프레미스 환경으로 라우팅되던 트래픽을 AWS 내 구성된 NF으로 전환하여 비용과 에너지를 절감할수도 있습니다. 이 게시물은 AWS 클라우드 환경 내 일반적인 애플리케이션을 위한 DR 구성 모델 및 전략에 대해 설명하고, 이런 모델 및 전략이 5G 네트워크 상황에 어떻게 적용되는지 설명합니다. 뿐만 아니라 3GPP 아키텍쳐가 DR 목적을 위해 어떻게 활용이 될 수 있고, 몇개의 오픈소스 샘플을 통해 EC2 오토스케일링 및 클러스터 오토스케일링 등을 포함한 AWS 기능이 이런 구성을 구현하는데 어떻게 도움을 드릴 수 있을 지에 대해 설명합니다.

AWS 5G 코어 네트워크의 DR 모델

클라우드 환경 내 재해 복구(DR)에 대해 소개된 게시물과 백서에서 설명한 것처럼 DR에는 복구 시간 목표(RTO, Recovery Time Objective)와 복구 지점 목표(RPO, Recovery Point Objective)라고 하는 두 가지 목표가 있습니다. RTO는 서비스 중단 시점과 서비스 복원 시점 간에 허용되는 최대 지연 시간을 의미합니다. RPO는 마지막 데이터 복구 시점 이후 허용되는 최대 시간을 의미합니다. AWS 내 운영되는 일반적인 애플리케이션의 경우, DR을 목적으로 알려진 AWS 서비스는 AWS Elastic Disaster Recovery(AWS DRS)와 AWS Route 53 Application Recovery Controller(Route 53 ARC)가 있습니다.

그러나 이 게시물에서 집중적으로 다루는 5G 코어 네트워크 애플리케이션은 3GPP 표준을 기반으로 하는 네트워크 인터페이스와 프로토콜에 대한 엄격한 요구사항을 가지고 있습니다. 더군다나 이런 AWS DR 관련 서비스들은 코어 네트워크의 모든 컴퍼넌트에 항상 적용할 수 없습니다. 따라서 이런 서비스들은 NF의 일부 구성요소에 적용될 수 있지만 이 게시물에서는 보다 전체적인 관점에 초점을 두고 있습니다. 해당 글은 3GPP 표준 아키텍쳐의 맥락에서 AWS 서비스들이 DR 구현을 어떻게 지원할 수 있는지에 초점을 맞춥니다.

대부분의 5G NF 구성에서 AMF(Access and Mobility Management Function), SMF(Session Management Function), UPF 등과 같이 가장 핵심적인 역할을 수행하는 NF는 RTO가 중요합니다. 이런 컴퍼넌트들은 5G 음성과 데이터 서비스의 빠른 복구 및 복원에 핵심적인 역할을 하기 때문입니다. 반면에 가입자 프로파일과 정보를 담당하는 UDM(Unified Data Management) NF은 RPO와 RTO가 모두 중요합니다. 각 NF는 서로 다른 목표에 초점을 두고 있기 때문에 DR 전략 또한 서로 다른 전략이 적용될 수 있습니다. 아래 그림은 DR 백서에서 강조된 4가지 전략을 보여줍니다. 왼쪽에서부터 오른쪽으로 해당 그림은 각각의 DR 전략이 다른 RTO와 RPO를 목표로 하고 있는 것을 보여주고 있습니다. 텔코 5G 코어 네트워크 애플리케이션은 미션 크리티컬한 서비스를 담당하고 있기 때문에, 아래 그림에서 표현된 RTO보다 적은 시간을 복구 목표로 하여야 합니다.

그림 1: 일반적인 (Non-Telco) 애플리케이션 DR 전략

예를 들어 앞에서 언급한 것과 같이 UDM은 실시간에 가까운 RTO와 RPO를 필요로 합니다. 그러므로 AWS 환경에서 UDM의 DR 시스템을 구축하고자 하는 경우, AWS 상의 DR용 UDM이 기존 운영 중인 UDM과 항상 데이터를 동기화하는 것을 고려해 볼 필요가 있습니다. 이 경우 Hot-standby(Active-Active) 전략이 가장 적합할 것입니다.

반면 NF의 사용 사례 또는 특성에 따라 다른 NF은 Warm-standby, Pilot Light, Backup & Restore과 같은 전략 등이 활용할 수도 있습니다. Backup & Restore 전략은 RTO가 엄격하지 않은(1시간 내) 미션 크리티컬하지 않고 우선순위가 낮은 사용 사례에 적용할 수 있습니다. 온프레미스 데이터센터와 AWS 사이에 Amazon Direct Connect (DX)가 미리 구성(또는 대역폭과 안정성에 크게 영향이 없을 경우, Site-to Site VPN을 통하여 구성도 가능) 되어 있다면, AWS CloudFormation, AWS Cloud Development Kit (AWS CDK), AWS CodePipeline과 같은 자동화 툴을 활용하여 이런 NF들을 즉각적으로 배포할 수 있습니다. 또한 Infrastructure-as-Code (IaC) 도구의 이점을 활용합니다. 이런 DR 전략에 대한 보다 자세한 내용은 DR Architecture on AWS, Part II의 게시물을 참고하십시오. 또한 AWS 환경에서 빠른 5G 서비스의 복구를 위한 NF 배포 CI/CD 파이프라인에 대해서는 AWS 백서인 CI/CD for 5G Networks on AWS 참고하십시오.

Cold-standby 전략은 미션 크리티컬하지 않은 5G 네트워크 유즈케이스에 대해 비용 효율적인 DR 사이트를 제공하는 옵션이 될 수 있습니다. 이 전략은 평상시에는 모든 EC2 인스턴스가 미리 생성되어 종료된 상태로 네트워크 트래픽을 처리하지 않기 때문에 Backup & Restore보다 빠르게 시스템 복구가 가능하며, 또한 Warm-standby 전략보다 비용 효율적일 수 있습니다. 반면에 Warm-standby 전략은 미션 크리티컬한 광역적인 음성 및 데이터 서비스에 대한 RTO를 고려하여 AWS에서 5G DR 네트워크를 구축하는 가장 실용적인 방법이 될 수 있습니다. 이 전략은 AWS DR 사이트에 있는 대부분의 5G NF가 최소한의 구성을 통해 최소한의 트래픽을 처리하도록 만드는 것을 의미합니다. 그리고 나서 스케일링 정책에 따라 AWS DR 사이트로 트래픽 전환이 필요한 경우 더 많은 트래픽을 처리하도록 확장합니다. 이를 통해 서비스 연속성을 유지하면서 재난에 대한 복원력을 갖춘 5G 네트워크를 구축할 수 있습니다. 5G NF가 Amazon EKS에 구현된 경우 일반적인 오토스케일링 그룹(EC2 Auto Scaling Group) 기반 기능으로는 급증하는 트래픽을 흡수하기 위한 즉각적인 수요를 처리하기에 충분하지 않을 수 있습니다. 요구되는 RTO가 Kubernetes 오토스케일링의 일반적인 작업 시간보다 짧기 때문입니다. 따라서 이 게시물의 후반부에서는 Amazon EKS 환경에서 더 빠른 Warm-standby 전략을 달성하기 위한 몇 가지 효과적인 구현 기술을 자세히 소개합니다. 마지막으로 비용 최적화를 위해 Graviton 인스턴스는 가격 대비 성능 측면에서 상당한 이점을 제공하고, 향상 된 에너지 효율성을 통해 지속 가능성 측면에도 도움을 줍니다.

3GPP 정의 복원 메카니즘과 AWS 클라우드 활용

3GPP는 TS23.501에서 NF Set라고 하는 5G 코어 네트워크에 대한 개념을 정의하여 네트워크 복원력을 구축하도록 가이드하고 있습니다. 이 개념에서는 하나의 NF는 단일 인스턴스 또는 여러 인스턴스를 NF Set로 정의합니다. 이렇게 하면 NF 인스턴스가 NF Set 내의 대체 NF 인스턴스로 교체되어 장애 발생 시 요청된 서비스를 제공하고 갑작스러운 버스트(burst) 서비스 요청를 처리할 수 있으므로 이중화와 확장성이 향상 됩니다. 5G 코어 네트워크에는 AMF, SMF, UDM 등 NF Set의 개념을 지원하는 많은 NF가 있지만, DR 사례에서는 AMF Set에 대해서 알아보겠습니다. AMF Set는 gNodeB(3GPP에서 정의한 5G 이동통신 기지국)에서 N2 트래픽을 수신하거나 AWS DR 사이트 내 다른 NF의 서비스와 통신 할 수 있습니다. 다음 그림에서 설명된 대로, 특정 TAC (Tracking Area Code)에 대한 AMF Set 구성을 통해, 각 데이터센터의 AMF 트래픽 부하를 분산하고 장애 복구 작업에 따른 전환 트래픽을 공유할 수도 있습니다. AMF Set에 관하여, 3GPP는 AMF 로드밸런싱의 개념을 정의하고, 각 데이터센터의 AMF 용량에 따른 가중치에 비례하여 UE (User Equipment, 사용자 단말) Registration 트래픽을 제어합니다.

그림 2: 여러 데이터센터 환경 내 3GPP NF Set 배포

NF Set 개념과 같은 AMF Set는 전체 데이터센터 환경에 걸쳐 트래픽 부하를 공유할 수 있도록 하지만, NRF(Network Repository Function, 동적으로 변경되는 5G 코어 NF의 서비스 상태 모니터링과 연동 정보 관리 기능 수행)는 AMF 이외의 나머지 NF에 대한 트래픽 부하를 내부에서 처리하는 역할을 수행할 수 있습니다. 보다 구체적으로 3GPP 표준에 따라 NRF는 “Nnrf_Management(nnrf-nfm)”와 “Nnrf_Discovery(nnrf-disc)”를 통해 Consumer NF들에게 서비스를 제공하는 각각의 Producer NF의 상태 정보를 관리하고 제공하는 역할을 수행합니다. NRF 내 “Nnrf_Management” 서비스는 모든 5G 코어 네트워크 NF가 NRF에 각각의 프로파일을 등록하는데 사용하는 “NFRegister”의 작동을 지원합니다. Registration 프로세스 중에 NF는 NFProfile의 일부로 NF 인스턴스 ID, NF 타입, NF 상태, FQDN, 그리고 IPv4/IPv6 주소와 같은 필수 정보를 NRF에 보내고, 선택적으로 우선순위 및 지역성과 같이 자신이 속한 NF Set와 관련된 정보를 제공할 수 있습니다.

그림 3: NRF에서 NF 등록 처리 및 NF 디스커버리

NRF 서비스 중 하나인 Nnrf_NFDiscovery는 Consumer 5G NF가 원하는 서비스를 제공하는 Producer에 대한 정보를 검색하기 위한 NFDiscover 기능을 지원합니다. 일반적으로 CSP는 상용 네트워크의 복원력을 더 높이기 위해, 여러 인스턴스를 배포하여 Producer NF를 구성합니다. 3GPP 표준에서는 Consumer NF가 특정 Producer NF를 검색하기 위한 여러 옵션을 정의하였습니다. 소비자는 원하는 서비스 기준과 일치하는 모든 생산자 NF의 전체 목록을 요청할 수도 있고, 쿼리 파라미터에 추가 정보를 제공하여 응답받는 공급자 목록 범위를 필터링 할 수도 있습니다. Producer NF를 선택하기 위해 Consumer NF가 사용할 수 있는 쿼리 파라미터 중 하나는 NRF가 전해주는 Producer NF에 대한 우선순위 정보입니다. Consumer NF가 활용할 수 있는 다른 정보는 preferred-locality(지리적 위치 및 데이터센터 등 선호하는 Target NF의 위치)입니다. AMF Set와 NRF preferred-locality라는 이 두 가지 주요 개념은 특히 DR 시나리오의 Pilot Light, Warm-standby 또는 Hot-standby 전략을 통해 AWS 상에 가상 데이터센터를 구성하는 데 활용될 수 있습니다. 예를 들어, 온프레미스 데이터센터와 AWS의 가상 DR 데이터센터에 동일한 값으로 AMF 가중치를 구성된 경우 해당 DR 사이트가 Hot-standby 모드로 작동하게 됩니다.

이벤트 발생 시, 데이터센터에서 AWS 로 트래픽 전환

일반적인 온프레미스 상용 환경에서 5G 코어 네트워크는 최소 하나의 DR 사이트와 함께 배포됩니다. 네트워크의 DR 사이트 수는 CSP가 채택한 전략에 따라 1+1, N+1 또는 N+K 등으로 구성될 수 있습니다. 또한 DR 사이트 수와 별개로 온프레미스 DR 사이트에 할당된 리소스는 장애 상황에서 전환되는 트래픽을 대체하기에 충분하도록 운영 중인 사이트의 리소스와 동일하거나 그 이상으로 할당됩니다.

CSP는 상용 네트워크 환경(온프레미스 데이터센터)과 DR 환경(AWS 내 가상 데이터센터)에 NF 인스턴스 그룹을 분배할 수 있도록 NF Set의 메커니즘을 활용할 수 있습니다. AWS DR 사이트의 경우, 3GPP의 NF Set 구성을 지원하는 5G NF는 이미 배포된 온프레미스 NF Set의 일부가 될 수 있습니다. NF Set의 일부로 추가할 수 없는 5G NF의 경우는 새 인스턴스 형태로 배포할 수 있습니다. NRF 배포 모델이 중앙 집중된 형태이거나 분산 형태인지에 따라 DR 환경 NF들은 온프레미스 NRF(중앙집중식) 또는 AWS 환경 내 로컬 NRF(분산환경)에 등록할 수 있습니다. 그러나 어떤 NRF 배포옵션을 사용하더라도 Warm-standby 전략을 사용하는 경우에는 DR 환경 NF들은 온프레미스 내 NF들 보다 낮은 우선순위(AMF 경우 낮은 가중치 요소)로 등록되어야 합니다. 이렇게 하면 평상시에는 온프레미스 환경에서 트래픽을 처리하고, NF장애나 유지보수시간과 같은 재해 이벤트 상황에서는 AWS 내 DR 환경으로 트래픽을 전환할 수 있습니다.

DR 환경이 활성화되면 AWS의 확장성과 탄력성을 활용하여 NF의 용량을 늘리는 것도 중요합니다. 다음으로는 NF 등록 과정에서 지역선호도 정보를 사용하면 통신이 DR 환경 5G NF 내에서 유지될 수 있습니다. 이는 지연시간을 줄이고 서비스 요청에 대한 응답 시간을 개선 할 수 있습니다.

그림 4: AWS 환경 내 5G 코어 네트워크 DR 구성

5G 네트워크 환경이 모두 이상없이 정상적인 경우에는 대부분의 트래픽은 온프레미스 내 상용망 구성을 통해 처리되므로, CSP는 최소한의 필수 요소만 AWS 내 구성할 수 있습니다. 장애가 발생하면 장애의 유형에 따라 NF는 필요한 리소스를 확보하기 위해 오토스케일링 메카니즘을 활용할 수 있습니다. 이런 전략은 전체 데이터센터 장애와 같은 경우에도 효과적이지만, 온프레미스 내 일부 NF에서 장애가 발생하거나 NF 유지보수기간 동안에도 활용될 수 있습니다.

급증하는 트래픽을 처리하기 위한 빠른 오토스케일링

앞에서 설명했듯이 평시에는 AWS 내에 최소한의 구성만 배포가 되고 “Warm-standby”의 경우 일부 사용자 트래픽이 AWS 환경에서 처리됩니다. 그러나 온프레미스 환경의 하나의 데이터센터에 재해 상황이 발생하면, 사용자 트래픽이 AWS 내 DR 환경으로 전환  되면서 AWS 내로 유입되는 트래픽이 급증될 것입니다. 이런 시나리오에서는 5G NF과 AWS 플랫폼 용량을 모두 빠르게 자동확장하는 것이 중요합니다. 5G NF 오토스케일링은 주로 Kubernetes HPA(Horizontal Pod Autoscaler, 컨테이너 파드의 수평적 오토스케일링 지원)를 기반으로 합니다. 하지만 컨테이너 파드의 확장만으로 클러스터 노드 확장을 처리할 수 없습니다. 5G NF가 Amazon EKS를 통해 배포되고 있다면 이는 “Cluster Autoscaler” 기반의 EC2 오토스케일링 그룹을 통해 해결할 수 있습니다. Amazon EKS는 “Cluster Autoscaler” 사용하여 노드 오토스케일링을 적용하는 경우 오토스케일링 그룹(Auto Scaling Group)을 활용하여 클러스터 워커 노드를 배포하고, 자동으로 스케일링하고 관리합니다.

그러나, “Cluster Autoscaler” 기반의 EKS 클러스터 노드 오토스케일링은 5G NF가 요구하는 RTO 요구사항을 만족시키지 못할 수 있습니다. 이는 “Cluster Autoscaler”가 본질적으로 어떤 컨테이너 파드가 “Unschedulable” 상태일 때 트리거되기 때문입니다. 대신에 오토스케일링 그룹의 “Cold-standby” 기능을 사용하면, AWS로 유입되는 트래픽이 급증하는 경우에도 효과적으로 EKS 클러스터 노드를 빠르게 확장할 수 있습니다.

그림 5: Cold-standby 모델의 빠른 자동확장 기능을 위한 Amazon EKS 워커 노드 상태 변화

또한 Cold-standby를 사용하면 Amazon EKS 클러스터 노드를 설정하고 워크로드를 호스팅하기 위한 준비를 사전에 수행할 수 있을 뿐 아니라 사용중이 아닌 상태에서는 비용을 줄이기 위해 노드를 멈춰 놓을 수도 있습니다. 이는 Multus CNI 또는 DPDK를 사용해야하는 것과 같이 특수한 사전 설정(보통 user-data 스크립트를 통해 실행)이 필요한 경우에 특히 유용합니다. 이런 워커 노드를 빠르게 구성하기 위해서 Amazon ECR(Elastic Container Registry)과 같은 컨테이너 이미지 저장소에서 컨테이너 이미지를 미리 다운로드합니다. 이런 구성은 컨테이너 파드가 “준비” 상태까지 걸리는 시간을 줄일 수 있습니다. 이런 Cold-standby 전략에서 워커 노드의 자동화는 Git 리파지토리에서 제공하는 샘플과 같이 람다 함수를 호출함으로써 처리할 수 있습니다.

그림 6: Cold-standby 전략에서 Amazon EKS 워커노드 Wake-up 자동화

커스텀 메트릭 기반의 오토스케일링 자동화

Warm-standby 전략의 경우, 유지보수 기간이나 장애 발생 시 AWS DR환경으로 트래픽이 급증하는 것을 커스텀 메트릭을 통해 확인할 수 있습니다. 예를 들어, AMF 메트릭 중에서 유입 가입자 등록을 시도하는 메트릭 지표가 크게 증가할 것입니다. EKS 환경에서 ADOT (Amazon Distro for Open Telemetry)를 통해 수집되는 메트릭 지표를 통해 Cold-standby 노드를 활성화하는 동작을 트리거할 수 있습니다. 아래 그림에서는 KEDA(Kubenetes 기반 이벤트 드리븐 오토스케일러)에서 Amazon Managed Prometheus 서비스에서 수집된 커스텀 메트릭을 기준으로 특정 기준치를 넘어가는 경우에 스탠바이 상태인 노드를 활성화 하도록 트리거하는 API를 호출합니다.

그림 7: 커스텀 메트릭 및 KEDA를 통한 빠른 오토스케일링

Hot-standby와 Warm-standby DR 전략의 비용 비교

AWS 환경과 온프레미스 데이터 환경에 구성된 5G 코어 네트워크의 직접적인 TCO 비교는 복잡할 수 있지만, Warm-standby 전략과 위에서 언급한 AWS Cold-standby를 조합하여 기본적인 비용 절감을 검토할 수 있습니다. 예를 들어, 상시 운영되며 트래픽 로드를 처리하는 Hot-standby 를 구성할 경우 6개의 m5.8xlarge EC2 인스턴스가 필요하고, 전체 트래픽 중 일부만을 처리하는 Warm-standby로 구성할 경우 2개의 m5.8xlarge EC2 인스턴가 필요하다고 가정해 봅니다. 또한 AWS의 DR 환경으로 100% 트래픽 이동이 매월 평균 4시간 발생하다고 가정해 보겠습니다. 이 경우에는 매월 4시간 동안 DR 환경에서 모든 사용자 트래픽을 처리하기 위해 추가적으로 4개의 m5.8xlarge 인스턴스가 필요합니다.

AWS 비용 계산기를 통해 서울 리전에서 상시 6개의 m5.8xlarge EC2 인스턴스가 필요한 Hot-standby 옵션에서 예상되는 비용은 연간 $58,131.12 입니다. 그러나 Warm-standby 모델을 기준으로 AWS 비용 계산기에서 비용을 계산해보면 $20,458.68 정도의 비용이 예상됩니다. 이 경우 상시 운영되는 2개의 m5.8xlarge EC2 인스턴스와 매월 4시간동안 필요한 4개 m5.8xlarge EC2 인스턴스의 온디맨드 비용, 그리고 4개의 64GB EBS 볼륨에 대한 비용이 포함되어 있습니다.

다음 그래프에서 볼 수 있듯이 Warm-standby 전략을 사용하는 경우 Hot-standby 전략을 사용하는 경우보다 65% 가량 비용을 절감할 수 있습니다.

그림 8: 6개의 m5.8xlarge 인스턴스로 구성한 Hot-standby와 Warm-standby 비용 비교

CSP들은 AWS EC2 요금 계산기에 각 DR 모델에서 필요한 EC2 인스턴스의 수량을 입력하여 5G 코어 네트워크 DR 구성을 위해 비용이 얼마나 필요한 지 예측하고 비교할 수 있습니다.

요약

5G 모바일 코어 네트워크는 음성 통화 및 데이터 스트리밍과 같은 미션 크리티컬한 서비스를 제공하기 때문에 서비스의 재해 복원력을 점검하고 네트워크 구성 요소의 신속한 재해 복구 기능을 갖추어야 합니다. 더 나아가, 장애 및 재해로부터 확실하게 격리하기 위해서는 기존 CSP 데이터 센터가 아닌 클라우드 환경에 5G 네트워크 DR 구축을 고려하는 것이 효과적 입니다. 또한 이 5G DR 네트워크가 주로 제한된 시간 동안(서비스 복구 또는 트래픽이 급증하는 경우)만 사용 된다면, 클라우드의 “사용하는 만큼 지불(pay-as-you-go)” 과금 정책은 DR 워크로드의 TCO를 줄이는데 도움이 될 것입니다.

AWS는 이런 DR 가상 데이터센터를 구축하기 위한 인프라를 제공할 뿐만 아니라, Github에 제공되는 샘플 코드 등을 통해 자동화 및 확장성을 구현하는데 도움을 드릴수 있습니다. AWS는 Graviton을 포함한 다양한 인스턴스 타입과 크기를 제공할 뿐만 아니라 빠른 스케일-아웃 기능을 제공하여, CSP 고객들이 5G 네트워크를 구축하기 위한 비용 및 에너지 절감을 극대화할 수 있습니다. AWS 클라우드 환경에서 Telecom 5G 사례에 보다 자세한 내용을 알고 싶으신 경우, thinkwithwp.com/telecom/contact-us를 방문해 주십시오.