システム アプローチ 今月のコラムは、キャリア グレードのネットワークを作成するオープン ソース プロジェクトである Magma の主任開発者である Amar Padmanabhan 氏と、同プロジェクトの技術諮問委員会メンバーである Bruce Davie 氏が共同で執筆しました。
モバイルおよびワイヤレスネットワークに関する議論は、特に5Gへの移行に伴い、バズワードで溢れかえっています。そのため、モバイルネットワーク機器の「クラウド化」が盛んに行われています。コンテナ、マイクロサービス、制御プレーンとユーザープレーンの分離などがその例です。
しかし、アーキテクチャをクラウドネイティブにすることは、単なるバズワードの適用ではありません。スケール、障害耐性、運用モデルなど、様々な原則が絡み合っています。実際、アーキテクチャを何と呼ぶかは重要ではありません。重要なのは、本番環境でどれだけうまく機能するかです。
この投稿では、あまり発展していない地域のモバイル ネットワーク向けにコスト効率が高く、操作が簡単なソリューションを追求する中で、Magma の開発を導いたいくつかの決定的な特徴を明確にしようと試みました。
市販のハードウェア
従来のネットワーク機器の多くはプロプライエタリであり、厳密に仕様・設定されたハードウェアにソフトウェアがバンドルされています。しかし、Magmaは、他の多くのクラウドネイティブシステムと同様に、低コストのコモディティハードウェアを活用しています。パフォーマンスはスケールアウトアプローチによって実現され、信頼性は信頼性の低いハードウェアの障害に対処するソフトウェア技術によって実現されます。スケールアウトと障害への対応計画は、後述するように、クラウドネイティブアーキテクチャの重要な原則です。
Magmaは、その誕生以来、汎用ハードウェア上で多様な環境で容易に運用できるよう設計されています。あらゆるコンポーネントは、最小限のコストとネットワークの中断で交換可能です。
スケールアップではなくスケールアウト
クラウドネイティブシステムは通常、個々のモノリシックシステムの容量をスケールアップするのではなく、コモディティデバイスを水平方向に追加することでスケールアウトを実現します。Magmaは、スケールアウト可能な分散アーキテクチャに基づいています。ネットワーク全体に小型デバイスを追加することで容量を拡張します。例えば、従来のEPC（Evolved Packet Core）設計ではコアに大型の機器を数台追加するのが一般的でしたが、Magmaは無線塔の周囲に数百台のアクセスゲートウェイを配置できます。この分散アーキテクチャは、次の点である「障害対応設計」においても重要です。
小さな断層領域
あらゆるクラウドシステムでは、個々のコンポーネントに障害が発生することが想定されており、障害はシステムの運用フローの一般的な一部として扱われます。Magmaの設計上の決定の多くは、この前提に基づいています。一方、従来の通信事業者のアーキテクチャでは、障害は稀に発生するものと想定され、ホットスタンバイや完全冗長サービスといった特定の例外パスを通じて処理されます。
障害は可能な限り少数のユーザー（つまり、障害ドメインは小さく）に影響を及ぼす必要があり、他のコンポーネントにも影響を与えないようにする必要があります。例えば、小規模なアクセスゲートウェイの障害は、数百人の顧客に影響を与える程度にとどまる可能性があります。逆に、2つの大規模なコアで構築されたネットワークの1つのコアに障害が発生した場合、顧客の半数がサービスを受けられなくなる可能性があります。
巨大なモノリスを小さなコンポーネントに分割するだけでは不十分です。障害の影響を最小限に抑えるには、コンポーネント内の状態を局所化する必要があります。Magmaは、任意のユーザー機器（UE）に関連付けられた状態を単一のアクセスゲートウェイに局所化することでこれを実現します。これにより、コンポーネント障害の影響は限定的になります。影響を受けるのは、特定のアクセスゲートウェイによってサービス提供されているUEのみです。アクセスゲートウェイは、UEごとの「ランタイム状態」の保存場所であり、UEの電源投入や新しい基地局のカバレッジエリアへのUEの移動などのイベントに依存します。一方、従来の3GPP実装では、UEのランタイム状態は複数のコンポーネントに分散される傾向があります。
ランタイム状態は関連するアクセスゲートウェイに局所化されますが、構成状態はMagmaオーケストレータに集中的に保存されます。これは、構成がネットワーク全体のプロパティであり、中央APIを通じて提供されるためです。オーケストレータのコンポーネントに障害が発生した場合、構成の更新が妨げられるだけで、ランタイム状態には影響しません。そのため、オーケストレータが再起動してもUEは動作を継続できます。
簡素化された操作
クラウドネイティブシステムのスケーラビリティは、パフォーマンスだけでなく運用にも大きく影響します。ソフトウェア定義ネットワーク（SDN）に見られるような集中型コントロールプレーンは、ネットワーク運用を簡素化する手段として登場しました。実際、MagmaはNiciraのSDNシステム構築の経験から影響を受けています。かつて集中型制御は、許容できない単一障害点やスケーリングのボトルネックと見なされていましたが、現在では、コモディティサーバーの集合体から、信頼性が高く論理的に集中化されたコントローラーを構築できることが広く理解されています。ネットワーク全体を中央制御点から見ると、各ネットワークデバイスを個別に構成する方法を決定するよりも、はるかに簡単に運用できます。
マグマの分散アクセスゲートウェイと論理的に集中化された制御のアーキテクチャ
Magmaにおける論理的に集中化された制御ポイントはオーケストレーターであり、これはSDNシステムのコントローラーに大まかに相当します。オーケストレーターは複数のマシン（通常は3台）上に実装されており、そのうちの1台に障害が発生してもオーケストレーターは停止しません。このマシン群は単一のAPIを公開しており、このAPIからネットワーク全体の設定と監視を行うことができます。ネットワークの規模が拡大し、アクセスゲートウェイが追加されても、オペレーターはネットワークの単一の集中ビューを維持できます。
アクセスゲートウェイは分散データプレーン実装を表し、ローカルコントロールプレーンコンポーネントも備えています。フェデレーションゲートウェイは、Magma対応システムが標準的なセルラーネットワークと相互運用できるように、一連の標準プロトコルインターフェースを実装しています。
SDNシステムと同様に、Magmaはコントロールプレーンとデータプレーンを分離します。これは簡素化された運用モデルに不可欠ですが、信頼性にも影響を及ぼします。コントロールプレーン要素の障害はデータプレーンの障害にはつながりませんが、新しいデータプレーン状態の作成（例えば、新しいUEのオンライン化）を妨げる可能性があります。これは、前述の3GPPのCUPS仕様で提供されているものよりも完全な分離です。
アクセスゲートウェイで実行されるMagmaのデータプレーンは、ハードウェアに依存しない、明確に定義された安定したインターフェース（原理的にはOpenFlowに類似）を介してソフトウェア制御およびプログラミングされます。これもSDNと同じアプローチであり、データプレーンは汎用ハードウェアを活用し、時間の経過とともに容易に進化させることができます。
望ましい状態モデル
多くのクラウドネイティブシステム（Kubernetesなど）と同様に、Magmaは「目的状態」設定モデルを採用しています。APIはユーザーや他のソフトウェアシステムが意図した状態を設定できるようにし、コントロールプレーンはその状態が実現されることを保証する役割を担います。コントロールプレーンは、オペレーターの意図した状態をアクセスゲートウェイの実際の実装にマッピングする役割を担い、大規模ネットワークの管理における運用上の複雑さを軽減します。
望ましい状態モデルは、コンポーネントが現在の状態と望ましい状態を単純に比較し、必要に応じて調整できるため、他のクラウドネイティブ環境でも有効であることが実証されています。例えば、2つのセッションがアクティブであることが望ましい状態である場合、コントロールプレーンはシステムを監視して要件を満たしていることを確認し、不足しているセッションがあればアクティブ化するためのアクションを実行します。（Kubernetesにおける望ましい状態の仕組みについて、Joe Bedaによる私のお気に入りの説明はこちらです。）
対照的に、従来の3GPP実装では「CRUD」（作成、読み取り、更新、削除）モデルが採用されており、一連のアクション（例えば、新しいセッションの作成やセッションの更新など）によって状態が決定されます。メッセージの損失やコンポーネントの障害が発生した場合、コンポーネントの現在の状態が正しいかどうかを判断することが困難になります。
これらの設計上の決定の多くは当然のことのように思えるかもしれませんが、標準的な3GPPアーキテクチャの原則とは大きく異なります。例えば、3GPPにはCUPSという概念がありますが、制御プレーン要素は多くの場合、ユーザープレーン（データプレーン）の状態を保持しています。制御プレーンとデータプレーンを適切に分離することで、より堅牢なアーキテクチャが実現し、アップグレード性も向上します。
結局のところ、アーキテクチャを何と呼ぶかは重要ではありません。重要なのは、どれだけ拡張性が高く、障害にどれだけ対処し、どれだけ運用しやすいかです。Magmaは、クラウドサービスの技術と原則を採用することで、堅牢で、コモディティハードウェアを活用し、小規模から大規模までスムーズに拡張でき、運用を簡素化する集中管理ポイントを備えたモバイルネットワークソリューションを提供しています。この記事を執筆中、運用データを収集中です。今後の記事で、これらの主張を定量化することを目標としています。®
