AWS IoT Core と AWS のアナリティクスサービスで TR-069 のバルクデータをインサイトに変える

この記事は Turning TR-069 bulk data into insights with AWS IoT Core and analytics services on AWS の日本語訳です。

通信サービス事業者（CSP）は、顧客にサービスを提供するために、数百万台の顧客宅内装置（CPE）を管理することがよくあります。これらのデバイスは、基盤となる通信技術によってさまざまな種類があります。ケーブルモデムや xDSL モデム、セットトップボックス、無線ルーターなどは、顧客環境で目にする機器の種類の一例です。

これらの機器を管理するために、多くの CSP は Broadband Forum の TR-069 プロトコル（CPE WAN Management Protocol、または CWMP としても知られています）を使用しています。このプロトコルは、異なるタイプの CPE 間で CPE オペレーションを管理する標準的な方法を提供し、CSP は Auto Configuration Server（ACS）と呼ばれる管理ソフトウェアを介して、異なるタイプのデバイス間で管理プレーンを再利用できるようにします。多くの ACS ベンダーがこのプロトコルを実装し、CSP がデバイス群を効率的に管理できるようなサービスを提供しています。

TR-069 プロトコルの最初のバージョンは、デバイスのテレメトリ情報を収集する専用の方法を定義していませんでした。当時は、ACS が一定の間隔でデバイスエージェントからいくつかの遠隔測定データを収集するために、GetParameterValues や定期的な通知といったプロトコル定義のオペレーションが使用されていました。しかし、このようなデータ収集方法は、特に数百万台のデバイスを持つデバイス群の場合、スケーラビリティの問題を引き起こしました。この問題に着目した Broadband Forum は、バルクデータ収集という新しいデバイステレメトリの収集方法を導入し、TR-069 の仕様の最新バージョンに含めました。

バルクデータ収集機能は、デバイスからアウトオブバンドのデータ収集チャネルを作成し、ACS 以外の別のエンティティにテレメトリ情報を送信することを目標としています。このアプローチは、懸念事項を取り除き、構成管理とパフォーマンス管理を分離し、機能を独立して拡張することを可能にします。

2021年11月、AWS は TR-069 and AWS リファレンスアーキテクチャを公開し、AWS のサービスを使用してデバイスからテレメトリデータを収集し、そこから洞察を得る方法を紹介しました。

このブログ記事では、業界でよく見られる CPE テレメトリデータのユースケースを説明し、これらのユースケースに対応する TR-069 and AWS リファレンスアーキテクチャの実装を紹介します。

アプローチ

CPE テレメトリデータを CSP が利用する場合、いくつかの一般的なユースケースが存在します。このブログでは、これらのユースケースのうち 5 つについて、AWS のソリューションによる TR-069 バルクデータ処理でどのように対処できるかを説明します。

以下では、これらのユースケースを説明し、それらに対応する AWS アーキテクチャの案を紹介します。

リアルタイムダッシュボード

リアルタイムダッシュボードは、一般的にバルクデータ収集プロジェクトの最初の要件として挙げられます。これらのダッシュボードは、取り込み後できるだけ早く生データまたは処理済みデータを表示することを可能にします。リアルタイムダッシュボードにより、運用担当者はリアルタイムの生のメトリクスと派生のメトリクスを可視化し、運用とトラブルシューティングをサポートすることができます。

ハートビート検出

ハートビート(稼働通知)検出により、CSP はオフラインのデバイスを検出することができます。この検出は、いくつかの方法で実装できます。HTTPS による一括データ収集では、通常、ステートフルストリーミング解析アプリケーションを使用して、特定のデバイスが定義された時間枠内にデータを送信したかどうかを追跡します。実装によっては、リアルタイムダッシュボードソフトウェアも、デバイスの切断を検出するために使用することができます。バルクデータ収集が MQTT を介して実装されている場合、デバイスと MQTT ブローカーとの間に持続的な接続があるため、デバイスの切断を直ちに検出することができます。

異常検知とクローズドループの自動化

異常検出は、テレメトリデータ処理のもう一つの一般的な使用例です。CPU 使用率、メモリ使用率、スループットなどの特定のメトリクスを使用してベースラインを作成し、現在の測定値がベースラインから逸脱している状況下でアラートを作成することが可能です。ML ベースのアプローチを必要としない単発の異常の検出には、単純な閾値ベースのチェックも効果的です。あるインターフェースでエラーレートが増加していることを検出することなどが、異常の一例となります。

異常が検出されたら、それを修正するためのアクションを実行する必要があります。異常に手動で対処する必要がある場合は、通常、CSP の運用サポートシステム（OSS）でアラームまたはトラブルチケットに変換され、追跡および管理されます。異常が自動化されたアクション（デバイスの再起動や Wi-Fi チャネルの変更など）で解決できる場合は、クローズドループ方式で修正を試みることが可能です。この設定では、通常、データ収集システムが構成管理プラットフォーム（ACS）に、問題のあるデバイスに是正措置を開始するよう働きかけます。クローズドループの自動化は、ニアリアルタイムで動作します。

予知保全

予知保全は、問題が発生する前に解決することを目的としています。例えば、バッテリーを搭載したデバイスのバッテリー電圧レベルを継続的に監視することで、ダウンタイムにつながる前にバッテリーの問題を特定することができます。予知保全分析は一般的に過去のデータを必要とし、リアルタイムではなく、バッチで実行されることがあります。無駄な出張修理を回避することで、顧客体験を向上させると同時に、CSP に多くのコスト削減をもたらす事が可能です。

履歴データ分析およびレポート

履歴レポートも一般的な使用例です。デバイスの履歴データは、上で述べた ML ベースのユースケースのための機械学習モデルをトレーニングするために使用することができます。もう一つの用途は、顧客の問題のトラブルシューティングです。例えば、あるお客様がコンタクトセンターに電話をかけてきて、1 週間のうち特定の時間帯に繰り返し発生するパフォーマンスの問題について苦情を言うことがあります。お客様の問題の根本的な原因を特定するには、履歴データの分析が不可欠な場合があります。履歴データの分析は、探索的なデータ分析の用途にも使用されます。デバイスは、多くの場合、何百もの計測値を発しています。これらのうちどれを使えば前述のユースケースを解決できるか、あるいは新しいユースケースを思いつくかを特定するには、手元にある生データを調べる必要があります。

ソリューション

上記のユースケースをカバーするために、以下のソリューションアーキテクチャを使用して CPE データを収集し、分析することになります。先に述べたように、このアーキテクチャはリファレンスアーキテクチャの実装となります。対応したいユースケースに応じて、実装をよりシンプルにも複雑にもできますし、あるいは他のAWSサービスを利用することも可能です。

以下では、提案するアーキテクチャを細分化し、デバイスの構成、データの取り込み、データのフィルタリング、正規化、リッチ化の共通ステップを説明した後、ビジネスユースケース別にセクションにまとめます。

デバイスの構成

TR-069 によるバルクデータ収集の最初のステップは、デバイスのバルクデータプロファイルを有効にすることです。バルクデータプロファイルは TR-098 または TR-181 データモデルの一部であり、ACS によって設定される必要があります。バルクデータプロファイルは、バルクデータコレクターの URL、プロトコル、ポート、認証情報などの接続パラメータを含んでいます。バルクデータプロファイルには、データモデルからどのメトリクスを収集し、コレクターに送信するかについても含まれます。

この例では、HTTPS POST ベースのバルクデータ収集メカニズムを使用しています。このシナリオでは、CPE デバイス群は、特定の間隔で AWS IoT Core HTTPS エンドポイントにバルクデータパラメータを送信するように設定されます。

データの取り込み

データの取り込みには、AWS IoT Core が使用されます。AWS IoT Core は、HTTP ベースのエンドポイントのカスタムオーサライザーとして AWS Lambda 関数を使用することができます。AWS Lambda は、Amazon DynamoDB のテーブルをバックにして、HTTP ヘッダーからユーザー名とパスワードの情報を収集し、検証するために使用されます。

データの取り込みは HTTP のみなので、AWS IoT Core の Basic Ingest 機能も使用しています。この機能により、取り込み経路からメッセージブローカーをバイパスすることができ、より費用対効果の高いデータの取り込み方法を実現することができます。

AWS IoT ルールエンジンのルールが、生のメッセージを Amazon Kinesis Data Streams に配信します。専用の生のストリームは、これらのメッセージを収集し、保持するために使用されます。

データのフィルタリング、正規化、リッチ化

Amazon Kinesis Data Analytics 上で動作する Apache Flink ベースのストリーム分析アプリケーションは、生のデータストリームから新しいメッセージを継続的に取得します。このアプリケーションは、生の JSON ペイロードをフィルタリングし、正規化し、下流のプロセッサーで使用される内部の標準データモデルに変換します。

Kinesis Data Analytics アプリケーションは、データのリッチ化も行います。多くの場合、生のペイロードの中にカウンター型の計測値を見つけることができます。BytesSent や BytesReceived のようなメトリクスは、デバイス側で継続的に増加するカウンターです。このようなタイプのメトリクスを分析で使用するには、それらを処理し、そこから派生したメトリクスを作成する必要があります。例えば、受信スループットは、2 つの連続した BytesReceived データポイントとその間の時間間隔から計算することができます。

データを派生メトリクスでリッチ化したら、別のストリーム（処理済みのストリーム）に書き込むことができます。このストリームは、下流の最初のユースケースであるリアルタイムダッシュボードの入力となります。

ユースケース 1 : リアルタイムダッシュボード

先に説明したように最初のユースケースは、リアルタイムダッシュボードです。提案するアーキテクチャでは、ダッシュボードのニーズに対応するために Amazon Managed Grafana を使用しています。AWS Lambda 関数を使って、処理済みのストリームから受信データを読み取り、Amazon Timestream に書き込んでいます。Amazon Timestream は時系列情報を保持しており、この情報はプラグインを介して Amazon Managed Grafana ダッシュボードから取得することができます。

Amazon Managed Grafana ダッシュボードは、顧客の要件に応じて、多くの詳細を表示することができます。最小値、最大値、平均値などの集計は、より広いタイムスパンに対してダッシュボードレベルで行うことができます。Amazon Managed Grafana ダッシュボードでは、メトリクスに対して閾値を設定し、これらの閾値に違反したときにアラームを表示することも可能です。

ユースケース2：ハートビート検出

提案するアーキテクチャでは、同じ Kinesis Data Analytics アプリケーションを使用して、受信ストリームに入っているべきハートビートの欠落を検出することもできます。というのも、今回は大規模にスケールさせる要件がないので、同じアプリケーションを 1 つのチームがメンテナンスすることを想定しているからです。もし、あなたの環境でそうでない場合は、生のストリームまたは処理済みのストリームから読み取る別のアプリケーションとして設計する必要があります。これは、このブログ記事で定義される将来のユースケースにも当てはまります。

Apache Flink はステートフルなストリーム処理プラットフォームなので、特定のデバイスの状態を維持するために使用することができます。このステートオブジェクトの中で、デバイスから最後に受信したタイムスタンプを保存し、アプリケーションタイマーを使って、設定可能なインターバルの間デバイスから受信しなかった時に検出することができるのです。ハートビート欠落状態が検出されると、アプリケーションは別のストリーム、heartbeat-alarms にアラームイベントを発信します。

同じ Kinesis Data Analytics アプリケーションは、デバイスがオンラインに戻ると、同じストリームに別のイベントであるアラーム解除を発行します。アラームとアラーム解除イベントは、Amazon DynamoDB の heartbeat-missing-devices テーブルを管理する AWS Lambda 関数によって収集されます。

この情報は、ダッシュボードにも表示する必要があるかもしれません。提案するアーキテクチャでは、Amazon Managed Grafana ダッシュボードが Amazon Athena を使用してこのテーブルから情報を取得します。

ユースケース3：異常検知とクローズドループの自動化

前述したように、メトリクスで異常を検出する方法はいくつかあります。しきい値ベースの異常検知は、個々のデータ要素またはタイムウィンドウベースの集計に対して使用することができます。Kinesis Data Analytics アプリケーションは、ランダムカットフォレストベースの検出、または事前にトレーニングされた Amazon SageMaker 推論エンドポイントを呼び出すことによって、機械学習ベースのリアルタイム異常検出を行うこともできます。

検出された異常は、使用されるアルゴリズムや人による承認プロセスの有無にかかわらず、自己修復の自動化を起動するために使用することができます。

提案するアーキテクチャでは、エラーメトリクスの単純な閾値によって検出された単発の異常が、ユーザーの承認を得て自己修復メカニズムをトリガーします。

このサブアーキテクチャでは、イベントの流れは、Kinesis Data Analytics アプリケーションが異常検出イベントを Amazon SNS トピックに発行することから始まります。このイベントには、異常が発生しているデバイスの ID が含まれています。Amazon SNS がイベントを受信すると、Lambda 関数が呼び出されます。Lambda 関数は、デバイス ID を含む DynamoDB のテーブルに問い合わせ、そのデバイスの所有者情報を探します。所有者情報が見つかると、Lambda 関数は電話番号を取得し、Amazon Pinpoint を通じて所有者に SMS を送信し、デバイスの再起動に同意するよう求めます。

Amazon Pinpoint は、双方向 SMS 機能を使用してユーザーの応答を収集し、Amazon SNS トピックに配信します。このトピックは、Amazon SQS の FIFOキュー に情報を渡し、別の Lambda 関数によってポーリングされます。Lambda 関数は、所有者の応答を DynamoDB テーブルに書き込み、応答が肯定的であれば、別の Lambda 関数を呼び出します。その後、ACS のノースバウンドインターフェース（NBI）と対話し、デバイスをリブートします。

異常の種類によって、異なる自己修復メカニズムが必要になります。現在のトラブルシューティングの仕組みとそのトリガーを分析することで、自己修復シナリオの候補となる問題を見つけることができます。

ユースケース 4 および 5：履歴データ分析、レポート作成、および予知保全

過去のデバイスデータは、履歴データ解析とレポート作成のユースケースに対応するために重要な役割を果たします。このデータは、機械学習アルゴリズムのトレーニングに使用することもでき、異常の検出や予知保全活動を行うことができます。

数百万台のデバイスから、収集間隔が数分の遠隔測定データを取り込むには、特にストレージ側でスケーラビリティの問題をもたらします。Amazon S3 は、事実上無制限のスケーラビリティと費用対効果の高い特性を備えており、テレメトリデータの保存に使用できるサービスであるため、提案するアーキテクチャに選ばれました。

Amazon Kinesis Data Streams の生データと処理済みデータは、それぞれ生バケットと処理済みバケットにコピーされます。このコピー操作は、Amazon Kinesis Data Firehose によって行われます。Kinesis Data Firehose は、S3 側で自動的にプレフィックスを付加して YYYY/MM/DD/HH のフォルダ構造にデータを整理します。処理後のデータは Amazon Athena から直接クエリされるため、Amazon Kinesis Data Firehose では最適化されたコスト効率の良い読み込みのために Parquet 形式への変換も行います。生バケットと処理済みバケットの両方について、Amazon S3 のライフサイクルポリシーが有効で、指定された保持期間後にオブジェクトを Amazon S3 標準ストレージクラスからコールドストレージクラスに移動させます。

お客様やパートナーからよく聞く要件として、ACSが管理しているデータをテレメトリデータと組み合わせて分析したいというものがあります。一般的に TR-069 のバルクテレメトリデータには、位置情報、デバイスの機能、その他比較的静的なインベントリー情報などのデバイスメタデータは含まれません。

ACS のデータも同様に Amazon S3 に取り込み、Amazon Athena から発行される SQL クエリ内でテレメトリデータと結合することが可能です。また、このデータは、ストリーミング解析アプリケーションによって、ストリームのリッチ化(情報の付与)を行うために使用することも可能です。提案するアーキテクチャでは、ACS データベースからのメタデータキャプチャに AWS Database Migration Service (AWS DMS) を使用しました。AWS DMS は、Oracle、MS SQL Server、MongoDB など、多くの SQL および NoSQL データベースエンジンをサポートしています。継続的な移行と変更データ取得（CDC）機能により、ACS のデータベースから変更を取得し、ほぼリアルタイムで Amazon S3 に挿入することができます。データが Amazon S3 に到着すると、AWS Glue ジョブがさらに Amazon DMS の出力形式から一般的な読み取り最適化された形式に変換します。

まとめ

このブログでは、CPE テレメトリデータの一般的なユースケースをいくつか定義しました。TR-069 のバルクデータ収集が、取り込みと分析のための様々な AWS サービスと共にどのように使用されるかを、サンプル AWS アーキテクチャで示しました。

サーバーレスの AWS サービスを利用することで、CPE フリートの増加に合わせてシームレスにスケールアウトできるほか、管理コストを削減することも可能です。

TR-069 and AWS のリファレンスアーキテクチャを調べ、CPE のバルクデータ収集の課題を解決するために実装することができます。

また、Telecommunications on AWS では、CSP がどのようにAWSで通信を定義しなおしているかを知ることができます。

この記事はソリューションアーキテクトの三平が翻訳しました。