Amazon Web Services ブログ

ワイヤレスサービスプロバイダー向けの AWS でクラウドネイティブのネットワークパフォーマンス分析ソリューションを構築する

この記事では、AWS のサービスを使用してネットワークパフォーマンス分析ソリューションを構築するサーバーレスのクラウドベースアプローチを紹介します。従量課金制の AWS サービスでコストを抑えながら優れた柔軟性とパフォーマンスを提供できます。

ネットワークパフォーマンスが優れていないと、リアルタイムの低レイテンシーサービスと、顧客が使用する総帯域幅を増やすといった課題に直面するため、苦労することになります。

最適なパフォーマンスモニタリングのために毎秒取り込み、保存や処理を行う必要がある大量のデータを考えると、標準のオンプレミスモニタリングアプローチはもう効率的ではありません。

クラウドネイティブのアプローチでは、ビジネスバリューを生み出すソリューションに投資し、初期費用と過剰なインフラのプロビジョニングを避けることで、通常の資本支出モデルから運用支出モデルに移行できます。

モバイルサービスプロバイダー向けのデータおよび音声ネットワークの複雑さ

Cisco のグローバルモバイルデータトラフィック予測によると、2023 年までにモバイル接続デバイスを 131 億台備え、そのうち 14 億台が 5G 対応であると予測されています。

モバイルサービスプロバイダーは、アクセスネットワークとコアネットワークにおける正確なネットワーク計画とサイズ調整を行う方法について理解している必要があります。

ネットワークスループットに対する世界的な需要の増加、およびモバイルネットワークでの VoLTE、IoT、ビデオストリーミングなどのサービス数の増加により、モバイルサービスプロバイダーは、目的のサービス品質 (QoS) に一致する新しいアーキテクチャを実装する必要性に迫られています。

統合ネットワークで多数のサービスを実行しているときに、最適な QoS に対処することは簡単な作業ではありません。ワークフローは複雑です。多数の異なるネットワーク要素からカウンターと統計データを収集することから始め、ネットワークを介して提供される複数のサービスのいずれかの品質にリンクできるよう、収集したデータを重要業績評価指標 (KPI) に変換します。

4G、5G、および IoT サービスの導入による最新のモバイルネットワークでは、テリトリーに導入されるセルの数が増加しているため、カウンターを収集し、何千もの異なるネットワーク要素で KPI を生成する必要があります。

すべてのネットワーク要素が数千のカウンターを生成できることを考えると、ネットワークパフォーマンスシステムは、すべての収集サイクルで数百万の測定値を管理する必要があります。

高コストのソリューションなしでは、オンプレミスデプロイで大規模の管理を行うことは困難です。代わりに、AWS サービスを使用して、通信サービスプロバイダー (TSP) のさまざまな部門ですべての要件をカバーする、最新のネットワークパフォーマンス分析ソリューションを設計できます。

データと音声のネットワークアーキテクチャ

サービスプロバイダーとして直面する主な問題は、最新のモバイルネットワークによる複雑さです。これは、過去数十年間に進化を遂げてきた一部の通信規格 (データコアでは 2G から 5G、音声コアでは CS から VoLTE) と、ハードウェアやネットワーク要素の機能に由来しています。

次の図は、現在デプロイされているモバイルワイヤレスネットワーク要素の簡略化されたスキーマを示しています。

  • 2G から 5G の範囲に必要なネットワーク要素を備えたネットワークにアクセス
  • コアネットワークには、ネットワーク上のすべてのユーザーに対してサービス、認証、データベースを提供するために必要なすべての機能でのネットワーク要素が含まれています。
  • 音声 (PSTN/PLMN)、インターネット (データサービス) およびアプリケーションサービスを含め、ネットワークによって提供されるサービス

IoT ネットワークアーキテクチャとサービスの差別化

IoT トラフィックパラダイムは、スマートフォンやタブレットのトラフィックパターンとはまったく異なります。これらのモバイルデバイスは通常、常時接続セッション (PDP コンテキストまたはベアラー) を開き、かなりの量のユーザープレーントラフィックを生成します。IoT デバイスは、セッションを開いて数バイトを送信し、セッションを閉じて電力消費を制限し、不要な場合はセルにリソースを割り当てないようにします。

次の図では、サービスプロバイダーが IoT サービスをデプロイする実際のユースケースを示しています。ほとんどの場合、IoT トラフィックは次の理由で別の 4G コアに配信されます。

  • IoT トラフィックを管理するために必要な EPC 最適化
  • セキュリティ上の理由から、顧客のトラフィックでの同じコアネットワークによって管理される IoT トラフィックを回避する
  • IoT デバイスは大量のコントロールプレーントラフィックを生成し、同じネットワークで管理されている場合、顧客のパフォーマンスに影響を与える可能性があります。

この使用パターンでは異なるトラフィックモデルが必要であります。モバイルサービスプロバイダーは、現在のセルへのファームウェアアップグレードを実行するか、新しいセルをネットワークにデプロイする必要があります。これは、カウンターとセルの数が増えたことにより、QoS に影響を与えます。

ネットワークパフォーマンスとは何ですか? ネットワークパフォーマンスが重要な理由は何ですか?

ネットワークパフォーマンスのモニタリングシステムを使用して、レポートと洞察を生成し、ネットワークパフォーマンスを追跡できます。運用、ネットワーク計画、エンジニアリングなどの複数の組織がこれらのツールを使用して、ネットワークとサービスの全体的な品質を表示し、可用性、応答時間、ダウンロード速度とアップロード速度などの重要な KPI をコントロールします。

ネットワークパフォーマンスは、QoS と厳密に関連しています。QoS は、定義により、通信サービスのパフォーマンス、信頼性、および使いやすさをコントロールするメカニズムです。

サービスプロバイダーの問題点

ネットワーク要素のすべてのベンダーは、通常、ハードウェアの要素マネージャーも提供します。これらのシステムは独自の仕様になっていますが、ほとんどの場合、ネットワークパフォーマンスを正確に測定するために必要なカウンターをエクスポートするパフォーマンス測定 (PM) ファイルの XML ファイル形式については、第 3 世代パートナーシッププロジェクト (3GPP) が提供する標準に準拠しています。

サービスプロバイダーは通常、コアネットワーク要素とアクセスネットワーク要素に複数のベンダーを使用するため、今日の導入における主要な課題の 1 つは非異種環境のモニタリングです。

データ型と 3GPP 標準

ネットワーク要素のパフォーマンスに関するカウンターと統計情報は、PM ファイルにエクスポートされます。3GPP は、3GPP ウェブサイトからダウンロードできる特定のドキュメントでフォーマットを標準化しました。

ネットワークベンダーはこの標準に準拠しているとは限りませんが、カスタマイズされているとしても、ほとんどの場合、その構造と形式がオープン標準と非常によく似ています。

次の 3GPP のスキーマは、ネットワーク要素からエクスポートされる PM の XML 形式を示しています。

XML スキーマのルート要素は「measCollectFile」であり、3 つの子要素があります。

  1. 「fileHeader」: ファイル送信者や測定開始時刻などの情報が含まれます。
  2. 「fileFooter」: 測定終了時刻を含みます。
  3. 「measData」: 測定タイプやその値など、すべての測定情報が含まれます。

最も重要なタグは次のとおりです。

  • measInfo – 各 measValue 測定値のファミリー、粒度、およびカウンターリストが含まれています
  • measValue – 測定結果を含む複数の measResults を含みます

AWS でのネットワークパフォーマンスソリューションの構築

このセクションでは、サーバーレスアプローチ通り AWS にソリューションを実装するために使用できるアーキテクチャについて説明します。

前提条件

このソリューションを実装するには、次の前提条件が必要です。

  • 同じリージョンに AWS アカウントがあること。
  • AWS アカウントに AdministratorAccess ポリシーが付与されていること (本番環境の場合、必要に応じてアクセスを制限する必要があります)。

この記事では欧州 (アイルランド) リージョンを用いています。ただし、次のサービスを利用できる場合は、別のリージョンを選択できます。

AWS リージョンと AWS サービスが利用可能な場所については、リージョン表を参照してください。

次の図では、高レベルでエンドツーエンドのソリューションと、そのソリューションで使用する AWS サービスを示しています。ワークフローは、SFTP または Kinesis Data Firehose を使用したファイルの取り込みから始まります。データは S3 に保存され、Lambda 関数と Glue で処理されてからデータカタログが作成されます。データのクエリは、Athena と Quicksight のビジュアルデータを使用して行われます。

Kinesis Data Firehose または AWS SFTP を使用したデータの収集

要素マネージャーを介した PM ファイルの収集については、3GPP ウェブサイトの技術仕様 3GPP TS 31.432 の第 5 章を参照してください。

要素マネージャーは、ネットワーク要素が提供する XML 測定ファイルのコレクターとして機能します。AWS SFTP または Kinesis Data Firehose を介してファイルを S3 バケットに送信できます。

データ転送については、Kinesis Firehose Delivery Stream の作成Kinesis Firehose Delivery Stream へのデータの送信に関する次のドキュメントを参照してください。SFTP 転送を使用する予定の場合は、AWS Transfer for SFTP の仕組みをこちらからお読みいただけます。

Lambda 関数を使用したデータの変換

この記事は、送信先 S3 バケットの rawxml プレフィックス (s3://wireless-pm/rawxml) の ObjectCreated イベントタイプに関連付けられた Lambda 関数を提供します。この関数は、新しい XML ファイルがこの場所に保存されるたびに実行されます。

Lambda 関数は Python 3.7 で記述されています。このブログ記事の GitHub リポジトリからダウンロードできます。この関数は、レイヤーを使用して、コードで使用されている xmltodict ライブラリの依存関係を解決します。

AWS マネジメントコンソールの次のスクリーンショットは、Lambda 関数の主なプロパティの一部を示しています。

  1. Lambda 名とそれに関連する Lambda レイヤー。
  2. ObjectCreated イベントの S3 バケットトリガーイベント。

関数は XML ファイルを転置し、CSV または JSON に変換し (関数の output_format 環境変数に設定された値に応じて変換)、測定ごとに 1 つのレコード (measData)、測定タイプ、および値 (measInfo) でファイルをフォーマットします。3GPP ウェブサイトの技術仕様 3GPP TS 32.435 のドキュメントでは、付録セクションに 3 つの XML ファイルの例が記載されています。

次のコードは、A.1 XML ファイルの例です。

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl"?>
<measCollecFile xmlns="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec">
    <fileHeader fileFormatVersion="32.435 V7.0" vendorName="Company NN" dnPrefix="DC=a1.companyNN.com,SubNetwork=1,IRPAgent=1">
        <fileSender localDn="SubNetwork=CountryNN,MeContext=MEC-Gbg-1,ManagedElement=RNC-Gbg-1" elementType="RNC"/>
        <measCollec beginTime="2000-03-01T14:00:00+02:00"/>
    </fileHeader>
    <measData>
        <managedElement localDn="SubNetwork=CountryNN,MeContext=MEC-Gbg-1,ManagedElement=RNC-Gbg-1" userLabel="RNC Telecomville"/>
        <measInfo>
            <job jobId="1231"/>
            <granPeriod duration="PT900S" endTime="2000-03-01T14:14:30+02:00"/>
            <repPeriod duration="PT1800S"/>
            <measTypes>attTCHSeizures succTCHSeizures attImmediateAssignProcs succImmediateAssignProcs</measTypes>
            <measValue measObjLdn="RncFunction=RF-1,UtranCell=Gbg-997">
                <measResults>234 345 567 789</measResults>
            </measValue>
            <measValue measObjLdn="RncFunction=RF-1,UtranCell=Gbg-998">
                <measResults>890 901 123 234</measResults>
            </measValue>
            <measValue measObjLdn="RncFunction=RF-1,UtranCell=Gbg-999">
                <measResults>456 567 678 789</measResults>
                <suspect>true</suspect>
            </measValue>
        </measInfo>
    </measData>
    <fileFooter>
        <measCollec endTime="2000-03-01T14:15:00+02:00"/>
    </fileFooter>
</measCollecFile>

Lambda 関数は、前述のファイルを次の JSON 形式に変換します (このコード例は、変換されたデータセットと転置されたデータセットの最初のレコードのみを示しています)。

{
    "fh_file_format_version": "32.435 V7.0",
    "fh_vendor_name": "Company NN",
    "fh_dn_prefix": "DC=a1.companyNN.com,SubNetwork=1,IRPAgent=1",
    "fh_fs_local_dn": "SubNetwork=CountryNN,MeContext=MEC-Gbg-1,ManagedElement=RNC-Gbg-1",
    "fh_fs_element_type": "RNC",
    "fh_mc_begin_time": "2000-03-01T14:00:00+02:00",
    "ff_mc_end_time": "2000-03-01T14:15:00+02:00",
    "md_me_local_dn": "SubNetwork=CountryNN,MeContext=MEC-Gbg-1,ManagedElement=RNC-Gbg-1",
    "md_me_user_label": "RNC Telecomville",
    "md_me_sw_version": "",
    "md_mi_meas_info_id": "",
    "md_mi_job_jobid": "1231",
    "md_mi_gp_duration": "PT900S",
    "md_mi_gp_end_time": "2000-03-01T14:14:30+02:00",
    "md_mi_rp_duration": "PT1800S",
    "md_mi_meas_obj_ldn": "RncFunction=RF-1,UtranCell=Gbg-997",
    "md_mi_meas_name": "attTCHSeizures",
    "md_mi_meas_value": 234,
    "md_mi_meas_p": null,
    "md_mi_meas_suspect": null
}

Lambda 関数で定義されている GPPXml クラスの静的メソッド get_record_header で出力フィールド名を変更できます。フィールド md_mi_meas_name および md_mi_meas_value には、それぞれメジャー名とメジャー値が含まれます。

変換された CSV ファイルと JSON ファイルは、S3 バケットの raw_transform_csv および raw_transform_json プレフィックスにそれぞれ保存されます (output_format 環境変数の値に応じて、各実行で 1 つの形式のみが作成されます)。次のスクリーンショットは、Amazon S3 コンソールでの S3 バケットの概要を示しています。

この使用例では、新しい XML ファイルが到達するたびに、変換タスクの Lambda 関数がトリガーされます。XML ファイルのボリュームとサイズに応じて、AWS BatchAmazon ECS、または Amazon EKS を使用するコンテナなど、適切な適合に基づいて AWS で他のコンピューティングオプションを選択できます。Amazon ECS を使用したプロセスの設定と実行については、AWS Fargate を使用してコンテナ化されたアプリケーションの構築、デプロイ、操作を参照してください。

または、Lambda 関数がアタッチされた Kinesis Firehose ストリームを使用して未加工の XML ファイルを取り込み、データを JSON に変換して、Kinesis Firehose のレコード形式変換機能を使用して、Parquet または ORC 形式で Amazon S3 に直接出力することもできます。データの変換に使用するスキーマ、シリアライザー、およびデシリアライザーを含むデータカタログ内のテーブルを事前定義する必要があります。

AWS Glue を使用してデータカタログを構築する

データカタログに AWS Glue テーブルを作成するには、まず AWS Glue クローラを作成します。次の手順を実行します。

  1. AWS コンソールのサービスから AWS Glue を選択します。
  2. 左側のメニューで [クローラ] を選択します。
  3. [クローラを追加] ボタンをクリックします。
  4. [クローラ名] に、ご使用のクローラ名を入力します (例: Wireless_PM_crawler)。
  5. [次へ] を選択します。
  6. [データストアを選択] で、[S3] を選択します。
  7. [データのクロール先] では、[アカウントで指定されたパス] を選択します。
  8. [インクルードパス] に、入力ファイルへのパスを CSV 形式で入力します。
  9. [次へ] を選択します。
  10. [IAM ロールを選択する] セクションで、[既存の IAM ロールを選択する] を選びます。
  11. [IAM ロール] に、S3 バケットにアクセスするための読み取り権限を付与するロールの名前を入力します。
  12. [次へ] を選択します。次のコードは、この記事の AWSGlueServiceRole-S3 IAM ポリシーです。
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:GetObject",
                    "s3:PutObject"
                ],
                "Resource": [
                    "arn:aws:s3:::npm-blog/raw_transform_csv/Parquet*",
                    "arn:aws:s3:::npm-blog/raw_transform_csv/*"
                ]
            }
        ]
    }
  13. [クローラの出力を選択] セクションの [データベース] で、データカタログテーブルが作成されるデータベースを選択します (例: wireless_pm)。
  14. [次へ] を選択します。次の手順では、CSV から Parquet (列形式のファイル形式) に変換し、Parquet ファイルを S3 バケットに書き込む ETL ジョブを作成します。Parquet のファイル形式は、データのダウンストリームを使用するパフォーマンスを向上させます。Parquet に変換するには、AWS Glue で生成されたスクリプト (この記事で使用) を使用するか、独自の PySpark または Scala スクリプトを使用できます。
  15. [ジョブプロパティを設定] セクションの [名前] に、[wireless_pm_parquet_conversion] と入力します。
  16. [IAM ロール] に、[AWSGlueServiceRole-wirelesspm] と入力します
  17. [タイプ] には [Spark] を選択します。
  18. [Glue バージョン] で、Spark 2.4、Python 3 (Glue バージョン 1.0) を選択します。
  19. [このジョブの実行] で、[AWS Glue によって生成された提案スクリプト] を選択します。
  20. [スクリプトファイル名] に、[wireless_pm_parquet_conversion] と入力します。
  21. [データターゲットを選択] セクションで、[データターゲットにテーブルを作成する] を選択します。
  22. [データストア] では、[Amazon S3] を選択します。
  23. [形式] では、[Parquet] を選択します。
  24. [ターゲットパス] に、S3 バケットへのパスを入力します。
  25. [次へ] を選択します。

クローラ後にジョブを実行する AWS Glue でワークフローを作成することにより、ジョブを開始するトリガーを設定できます。ジョブが完了すると、新しい Parquet ファイルのセットが送信先 S3 バケットに保存されます。

AWS Glue で作成されたデータベースを選択し、AWS Glue テーブルからデータを分析することにより、処理されたデータを Athena で直接分析できます。

次のスクリーンショットは、AWS Glue データベースと作成された 2 つのテーブルを示しています。

次のスクリーンショットは、Athena クエリの例を示しています。これにより、いくつかの列を選択して実行し、作成したデータカタログテーブルのデータを検証できます。

Amazon RedshiftAmazon EMR などの他の AWS サービスを分析に使用して、さらにデータからの処理、分析、KPI 計算を行うこともできます。

Amazon QuickSight を使用してデータを可視化

Amazon QuickSight は、視覚化の構築、アドホック分析の実行、およびデータからのビジネスインサイトの取得に使用できるビジネス分析サービスです。詳細については、Amazon QuickSight とはをご参照ください。

Amazon QuickSight は、Athena ですぐに使用できる統合を提供します。これにより、データカタログのメタデータ上で SQL クエリを実行できます。詳細については、Amazon Athena データを使用したデータセットの作成を参照してください。

次のスクリーンショットは、Amazon QuickSight データセットから作成された Amazon QuickSight 分析を示しています。データセットは AWS Glue が定義したテーブルに基づいており、Athena を介してクエリを行います。

PM カウンターのサンプルデータセットを読み込むことにより、ビジュアルデータを作成できます。たとえば、次のスクリーンショットは、GPRS SuccessAttach と AbortedAttach の測定値を示すことで、問題を強調しています。

まとめ

この記事では、ワイヤレスサービスプロバイダーの主な問題点について説明しました。また、AWS サービスを使用して、前払いコストなしでネットワークの成長に合わせて拡張するサーバーレスソリューションを構築する方法についても説明しています。

このソリューションは、データの視覚化と分析にも役立ちます。さらに、運用およびネットワーク計画部門では、現在および将来の規格とサービス通りにネットワークを管理して発展させるのに役立つ洞察を提供しました。

いつものように、AWS では皆さんのフィードバックをお待ちしています。ご意見や質問については、コメント欄にお寄せください。

 


著者について

Angelo Sampietro はアマゾン ウェブ サービスのシニアパートナーソリューションアーキテクトです。Angelo はクラウドコンピューティングに強いバックグラウンドを持っています。また、米国と欧州の通信業界で 20 年の経験を積んでいます。彼は、ビッグデータや Machine Learning のスペシャリティを含む 5 つの AWS 認定を取得し、現在はシニアパートナーソリューションアーキテクトとして働いています。また、グローバルシステムインテグレーターが AWS とパートナーシップを結んで成功を収められるよう支援しています。彼は同僚や友人と新しいアイデアを共有し、すぐに使える新しい解決策を提案するのを好んでいます。

 

 

Francesco Marelli は、アマゾン ウェブ サービスのシニアソリューションアーキテクトです。 彼はロンドンで 10 年間働いた後、イタリア、スイス、および欧州、中東、アフリカの他の国で仕事をしてきました。主にエンタープライズおよび FSI の顧客向けに、分析、データ管理、ビッグデータシステムの設計と実装を行うことを専門としています。Francesco は、システム統合と、ウェブアプリケーションの設計や実装においても豊富な経験を持っています。彼は専門知識の共有、レコード盤の収集、そしてベースの演奏を楽しんでいます。