コアネットワークの障害は、必ずしも処理能力不足によって発生するわけではありません。実際には、状態情報が問題になることが少なくありません。あるネットワーク機能が停止しても、ユーザーコンテキストが信頼できる場所に残っていれば、別の機能がサービスを継続できる可能性があります。反対に、障害ノードとともにコンテキストも失われると、復旧ははるかに難しくなります。これが、5GCにおける重要な設計思想の一つ、すなわちコンピュート資源とストレージ資源を分離する理由です。
モバイルコアネットワークのユーザーコンテキストには、登録状態、モビリティ情報、一時識別子、セッション関連データ、位置参照情報、その他のサービス状態が含まれる場合があります。これらの情報により、ネットワークはUEが誰で、どこに存在し、どのセッションを利用し、その後のシグナリングをどのように処理すべきかを把握できます。このようなコンテキストが一つのローカルなネットワーク機能インスタンスに強く結び付くと、そのインスタンスは単なる処理ノードではなく、サービス継続性における単一障害リスクになります。
5GCは、より多くのステートレスなネットワーク機能をサポートすることで、このリスクに対応します。これは、ネットワーク機能が動作中に状態を一切使用しないという意味ではありません。重要なのは、長期間保持される状態や復旧可能な状態を、一つのローカルなコンピュートインスタンスの内部に閉じ込めないことです。UEコンテキストのような非構造化データをUDSF経由で保存・取得できるようにすることで、5GCはAMFやその他のネットワーク機能に、より柔軟な復旧モデルを提供します。
ローカル状態がリスクになる理由
4GのMMEを例にすると問題を理解しやすくなります。LTE/EPCネットワークでは、UEがMME1経由でアタッチを完了すると、そのMMEがUEコンテキストを生成し、ローカルに保存します。このコンテキストには、UE位置、GUTI、UEのIPに関連するパラメータなど、モビリティ管理やセッション管理の情報が含まれる場合があります。
MME1が予期せず停止しても、MMEプール内ではMME2が物理的に利用可能な場合があります。しかし、別のMMEが存在するだけでは、サービス継続性は自動的には確保されません。UEコンテキストがMME1にしか存在しない場合、MME2にはUEへのサービスを円滑に継続するための十分な情報がありません。サービスを復旧するには、ユーザーが端末の電源を入れ直したり、再度アタッチを実行したりする必要が生じることがあります。ユーザー体験の観点では、これは好ましくない復旧モデルです。
従来の回避策の一つが、アクティブ／スタンバイ同期を備えた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におけるコンピュートとストレージの分離は、単なるデータベース調整ではありません。コアネットワークが状態、障害、復旧をどのように捉えるかを変える設計です。UEコンテキストのような非構造化データをUDSFに保存することで、ネットワーク機能はローカルストレージへの依存を減らし、耐障害性の高いクラウドネイティブ展開に適応しやすくなります。本質的な考え方は単純です。コンピュートインスタンスは停止したり入れ替わったりしても、ユーザー状態は復旧可能でなければなりません。
