코어 네트워크 장애가 항상 처리 능력 부족 때문에 발생하는 것은 아닙니다. 실제로는 상태 정보가 더 큰 문제가 되는 경우가 많습니다. 네트워크 기능이 중단되더라도 사용자 컨텍스트가 신뢰할 수 있는 위치에 남아 있다면 다른 기능이 서비스를 이어갈 수 있습니다. 반대로 장애 노드와 함께 컨텍스트도 사라지면 복구는 훨씬 어려워집니다. 이것이 5GC의 중요한 설계 원칙 중 하나인 컴퓨팅 자원과 스토리지 자원의 분리 논리입니다.
모바일 코어 네트워크의 사용자 컨텍스트에는 등록 상태, 이동성 정보, 임시 식별자, 세션 관련 데이터, 위치 참조 정보, 기타 서비스 상태가 포함될 수 있습니다. 이러한 값은 네트워크가 UE가 누구인지, 어디에 있는지, 어떤 세션을 사용 중인지, 이후 시그널링을 어떻게 처리해야 하는지를 파악하는 데 도움을 줍니다. 이 컨텍스트가 하나의 로컬 네트워크 기능 인스턴스에 강하게 묶이면 해당 인스턴스는 단순한 처리 노드를 넘어 서비스 연속성의 단일 위험 지점이 됩니다.
5GC는 더 많은 무상태 네트워크 기능을 지원하여 이 위험을 줄입니다. 이는 네트워크 기능이 동작 중에 상태를 전혀 사용하지 않는다는 뜻이 아닙니다. 핵심은 장기간 유지되거나 복구 가능한 상태가 하나의 로컬 컴퓨팅 인스턴스 안에 갇히지 않도록 하는 것입니다. UE 컨텍스트와 같은 비정형 데이터를 UDSF를 통해 저장하고 조회할 수 있게 함으로써 5GC는 AMF와 다른 네트워크 기능에 더 유연한 복구 모델을 제공합니다.
로컬 상태가 위험해지는 이유
4G MME 사례를 보면 문제를 쉽게 이해할 수 있습니다. LTE/EPC 네트워크에서 UE가 MME1을 통해 attach를 완료하면 해당 MME가 UE 컨텍스트를 생성해 로컬에 저장합니다. 이 컨텍스트에는 UE 위치, GUTI, UE IP 관련 파라미터 등 이동성 관리 및 세션 관리 정보가 포함될 수 있습니다.
MME1이 예기치 않게 장애를 일으켜도 MME 풀 안의 MME2는 물리적으로 계속 사용 가능할 수 있습니다. 그러나 다른 MME가 존재한다고 해서 서비스 연속성이 자동으로 보장되는 것은 아닙니다. UE 컨텍스트가 MME1에만 있다면 MME2에는 UE 서비스를 원활하게 이어갈 충분한 정보가 없습니다. 서비스가 복구되기 전에 사용자가 단말 전원을 껐다 켜거나 다시 attach해야 할 수 있습니다. 사용자 경험 관점에서 이는 바람직하지 않은 복구 모델입니다.
전통적인 대안 중 하나는 액티브-스탠바이 동기화를 적용한 MME 클러스터입니다. 이 구조에서는 UE 컨텍스트가 액티브 MME와 스탠바이 MME 사이에서 실시간으로 동기화됩니다. 액티브 MME가 장애를 일으키면 스탠바이 노드가 동기화된 컨텍스트를 이용해 서비스를 인계할 수 있습니다. 이 방식은 서비스 중단을 줄일 수 있지만 한계도 있습니다. 공급업체별 구현에 의존할 수 있고 폭넓은 표준 지원이 부족할 수 있으며, 비용을 높이고 서로 다른 시스템 환경 간 이식성을 낮출 수 있습니다.
더 근본적인 문제는 로컬 상태가 서비스 인스턴스와 해당 데이터를 밀접하게 결합한다는 점입니다. 컴퓨팅 노드가 사용자 컨텍스트의 사실상 유일한 보유자가 되면 장애 전환이 복잡해집니다. 5GC는 복구 가능한 상태를 권한이 있는 네트워크 기능이 접근할 수 있는 별도의 저장 기능에 배치함으로써 더 명확한 모델로 이동합니다.
UDSF가 바꾸는 점
UDSF는 비정형 데이터 저장 기능(Unstructured Data Storage Function)을 뜻합니다. UDSF를 통해 모든 5GC 네트워크 기능은 UE 컨텍스트를 포함한 비정형 데이터를 저장하고 조회할 수 있습니다. 이 모델에서 AMF 또는 다른 NF는 컴퓨팅 기능으로 시그널링을 처리하고, UDSF는 선택된 상태 정보를 보관하는 독립적인 위치를 제공합니다.
개념적으로는 디스크리스 워크스테이션과 비슷합니다. 디스크리스 워크스테이션은 CPU, 메모리, 네트워크 인터페이스 및 기타 실행 하드웨어를 갖추지만 작업 데이터를 로컬 하드디스크에 저장하지 않습니다. 네트워크 서버에서 부팅하고 데이터를 받아옵니다. 워크스테이션은 연산을 수행하고 스토리지는 분리됩니다. 5GC에서도 NF가 시그널링과 서비스 로직을 실행하고 컨텍스트 데이터는 로컬 인스턴스 밖에 저장하는 방식으로 네트워크 기능을 설계할 수 있습니다.
UDSF의 가치는 단순히 데이터베이스처럼 동작하는 데 있지 않습니다. 아키텍처적 가치는 무상태 NF 설계, AMF 복구, 더 유연한 클라우드 네이티브 배치를 지원하는 데 있습니다. 상태가 UDSF를 통해 접근 가능하면 AMF 인스턴스가 중단되더라도 UE 컨텍스트가 반드시 영구적으로 손실되는 것은 아닙니다. 새로 선택된 AMF는 필요한 컨텍스트를 조회하고 다음 트랜잭션이 발생할 때 처리를 이어갈 수 있습니다.
UDSF는 가상화 및 클라우드 네이티브 코어 네트워크라는 더 큰 방향에도 부합합니다. 클라우드 환경에서 네트워크 기능 인스턴스는 확장, 축소, 재시작 또는 인프라 간 이동이 발생할 수 있습니다. 각 인스턴스가 로컬 상태를 강하게 소유하면 자동화가 어려워집니다. 컴퓨팅과 스토리지를 분리하면 확장과 복구를 더 쉽게 관리할 수 있습니다.
데이터 유형은 어떻게 다른가
UDSF를 정확히 이해하려면 구조화 데이터와 비정형 데이터를 구분해야 합니다. 5GC 용어에서 구조화 데이터는 3GPP 규격에 구조가 정의된 데이터를 의미합니다. 가입자 데이터는 리소스 구조와 접근 모델이 명확하게 기술되어 있으므로 대표적인 구조화 데이터입니다.
비정형 데이터는 내부 구조가 3GPP 규격에 정의되지 않은 데이터를 뜻합니다. UE 컨텍스트가 대표적인 예입니다. UE 컨텍스트는 서비스 연속성에 매우 중요하지만 정확한 내부 구성은 가입자 데이터와 같은 방식으로 표준화되어 있지 않습니다. 따라서 UDSF를 통한 저장에 적합합니다.
이 차이는 엔지니어링 설계에 영향을 줍니다. 구조화 데이터는 정의된 리소스 모델을 갖는 표준 데이터 서비스를 통해 관리할 수 있습니다. 비정형 데이터는 일반적으로 서비스 로직을 소유한 네트워크 기능이 생성하고 해석합니다. UDSF는 내부 형식 전체를 표준 데이터 트리로 변환하도록 강제하지 않으면서 해당 기능이 데이터를 저장하고 조회할 수 있는 위치를 제공합니다.
배치 계획에서 엔지니어는 모든 5GC 데이터를 하나의 범주로 취급해서는 안 됩니다. 가입자 데이터, 정책 데이터, 세션 상태, 임시 사용자 컨텍스트, 복구 관련 정보는 접근 빈도, 지연 민감도, 구조, 소유권, 복구 요구사항이 서로 다를 수 있습니다. UDSF는 주로 네트워크 기능이 복원력과 연속성을 확보하는 데 필요한 비정형 상태를 저장합니다.
AMF 복구 동작 방식
UDSF를 사용하는 일반적인 AMF 복구는 명확한 순서로 진행됩니다. 먼저 5G UE가 AMF1을 통해 등록합니다. AMF1은 액세스 및 이동성 관리에 필요한 UE 컨텍스트를 생성합니다. 이후 AMF1은 UE 컨텍스트를 UDSF에 저장합니다. 이 시점부터 사용자 상태는 로컬 AMF 인스턴스 안에만 갇혀 있지 않습니다.
AMF1이 장애를 일으키면 5G 액세스 네트워크 또는 피어 제어 평면 기능이 장애를 감지합니다. 장애가 발생한 AMF는 더 이상 선택 대상이 아닙니다. 네트워크가 동일한 AMF 세트에서 다른 AMF를 선택해야 할 때 AMF2를 선택할 수 있습니다. 이 지점에서 UDSF가 복구 동작을 바꿉니다.
AMF2는 UE를 완전히 알 수 없는 단말로 취급할 필요가 없습니다. UE와 트랜잭션이 발생하면 AMF2는 UDSF에서 UE 컨텍스트를 조회할 수 있습니다. 조회에는 SUPI, 5G-GUTI 또는 AMF UE NGAP ID와 같은 식별자를 사용할 수 있습니다. 컨텍스트를 확보한 뒤 AMF2는 UE 메시지를 처리하고 필요할 경우 UE의 5G-GUTI를 갱신할 수 있습니다.
실질적인 결과는 서비스 연속성 향상입니다. 네트워크에는 여전히 정확한 장애 감지, AMF 재선택, 컨텍스트 조회 로직이 필요하지만, 모든 사용자 컨텍스트를 장애 노드 내부에만 저장하는 모델보다 복구 기반이 더 강합니다. 사용자 관점의 이상적인 결과는 단말 재시작, 수동 재접속 또는 체감 가능한 서비스 중단 없이 복구되는 것입니다.
엔지니어링 가치와 한계
컴퓨팅과 스토리지 분리의 가장 큰 엔지니어링 가치는 복원력입니다. AMF 인스턴스가 중단되어도 서비스 상태는 UDSF를 통해 계속 이용 가능할 수 있습니다. 이는 로컬 노드 상태 의존성을 낮추고 네트워크가 더 적은 영향으로 복구하도록 돕습니다. 또한 새 네트워크 기능 인스턴스를 추가하기 전에 모든 과거 상태를 로컬로 미리 동기화할 필요가 없어 탄력적 확장도 지원합니다.
두 번째 가치는 아키텍처 이식성입니다. 공급업체별 액티브-스탠바이 동기화와 비교하면 UDSF는 5GC 아키텍처의 일부이며 표준화된 클라우드 네이티브 코어 설계에 더 잘 부합합니다. 고가용성을 폐쇄형 클러스터 메커니즘에 묶는 대신 상태 저장과 복구를 더 개방적으로 설계할 수 있습니다.
그러나 UDSF가 모든 복잡성을 없애는 것은 아닙니다. UDSF는 복구 체인의 핵심 구성요소가 됩니다. UDSF가 느리거나 사용할 수 없거나 데이터가 불일치하거나 보호가 부족하면 새로운 병목이 될 수 있습니다. 따라서 UDSF 자체도 고가용성, 빠른 읽기·쓰기 성능, 신뢰성 있는 복제, 안전한 접근 제어, 재해 복구 능력을 갖춰야 합니다.
데이터베이스 선택도 중요합니다. 공급업체 구현과 시스템 요구사항에 따라 UDSF 관련 설계에는 관계형 데이터베이스와 비관계형 데이터베이스가 모두 사용될 수 있습니다. 핵심 질문은 어떤 데이터베이스 유형을 사용하느냐뿐 아니라 전체 스토리지 계층이 통신급 지연, 신뢰성, 일관성, 복구 요구사항을 충족할 수 있느냐입니다.
엔지니어가 중점적으로 확인할 항목은 UE 컨텍스트가 적절한 시점에 UDSF에 기록되는지, 새로 선택된 AMF가 이를 정확히 조회할 수 있는지, AMF 세트 선택이 예상대로 동작하는지, 식별자가 일관되게 처리되는지, 장애 전환이 사용자에게 실제로 보이지 않거나 거의 느껴지지 않는지입니다. 전체 복구 경로를 종단 간 시험해야만 분리 구조의 가치가 입증됩니다.
자주 묻는 질문
UDSF는 AMF만 사용하나요?
아닙니다. UDSF는 비정형 데이터를 저장하고 조회해야 하는 모든 네트워크 기능을 위해 설계되었습니다. UE 컨텍스트를 이용한 AMF 복구는 가장 이해하기 쉬운 사례 중 하나일 뿐입니다.
UE 컨텍스트를 비정형 데이터로 보는 이유는 무엇인가요?
UE 컨텍스트는 중요하지만 내부 구조가 표준화된 3GPP 데이터 구조로 완전히 정의되어 있지 않습니다. 따라서 비정형 데이터 형태로 저장하기에 적합합니다.
UDSF가 네트워크 기능 내부의 모든 로컬 상태를 대체하나요?
완전히 대체하지는 않습니다. 네트워크 기능은 처리 중 임시 로컬 상태를 계속 사용할 수 있습니다. UDSF는 주로 하나의 컴퓨팅 인스턴스와 함께 손실되어서는 안 되는 복구 가능한 비정형 데이터를 보존하는 데 사용됩니다.
UDSF만으로 서비스 중단이 전혀 없다고 보장할 수 있나요?
UDSF만으로는 보장할 수 없습니다. 복구 기반을 강화하지만 실제 연속성은 장애 감지, AMF 재선택, 데이터 최신성, 시그널링 동작, UDSF 가용성에도 좌우됩니다.
UDSF를 상용 환경에 배치하기 전에 무엇을 시험해야 하나요?
시험 항목에는 컨텍스트 기록 시점, 컨텍스트 조회, AMF 장애 감지, AMF 세트 재선택, 데이터베이스 장애 전환, 읽기·쓰기 지연, 접근 보안, 복구 중 실제 UE 체감 품질이 포함되어야 합니다.
5GC의 컴퓨팅·스토리지 분리는 단순한 데이터베이스 조정이 아닙니다. 코어 네트워크가 상태, 장애, 복구를 바라보는 방식을 바꾸는 설계입니다. UDSF를 이용해 UE 컨텍스트와 같은 비정형 데이터를 저장하면 네트워크 기능은 로컬 스토리지 의존도를 낮추고 복원력 있는 클라우드 네이티브 배치에 더 적합해질 수 있습니다. 핵심 원리는 간단합니다. 컴퓨팅 인스턴스는 실패하거나 변경될 수 있지만 사용자 상태는 계속 복구 가능해야 합니다.
