Elastic Stackは通信監視のパワフルなツールになります。通話切断率（CDR）やネットワーク効率レシオ（NER）、通話成功率（ASR）、SIPトラフィック、発信/受信数、異常検知をはじめとする各種分析を、簡単に実行する方法をご紹介します。

<p>通信データ処理の中核プロセスに<a href="/jp/observability">オブザーバビリティ戦略</a>を適用すると、事業者は以前回答できなかった問いに答えられるようになります。このアプローチが知られるようになり、<a href="/jp/products">Elastic Stack</a>は通信分野にますます普及しています。ドイツテレコム社も例外ではありません。同社はハンス=コンラッド・ロス氏のリーダーシップの下にデジタルトランスフォーメーションを進めており、社内トラフィック監視のソリューションとしてElasticを採用しました。
</p> <strong><h2>Elastic Stackで音声トラフィックデータを監視する</h2></strong><p><a href="/jp/elasticsearch">Elasticsearch</a>で作動するElastic Stackは、3つの情報処理の階層すべてに対応します。最初の階層はIngestパイプライン（<a href="/jp/security">Elastic Endpoint Security</a>、<a href="/jp/beats">Beats</a>、<a href="/jp/logstash">Logstash</a>）です。ユーザーはIngestパイプラインを使い、あらゆるソースからすばやくデータを投入、パース、エンリッチできます。次がElasticsearchです。ユーザーは<a href="/jp/what-is/elasticsearch-machine-learning">設定不要の機械学習</a>など、パワフルな機能でデータの格納、クエリ、分析を実施できます。最後の階層を重視するエンドユーザーが多いかもしれません。3番目は、<a href="/jp/log-monitoring">ログ</a>や<a href="/jp/infrastructure-monitoring">メトリック</a>、<a href="/jp/apm">APM</a>、<a href="/jp/siem">SIEM</a>、<a href="/jp/maps">マップ</a>をはじめとする専用アプリ向けに<a href="/jp/kibana">Kibanaが提供する、洗練された可視化エクスペリエンス</a>です。
</p><p>Elastic Stackを導入して従来型のオペレーション作業効率を大幅に改善できる領域の1つに、転送ネットワーク監視があります。従来のシステムは非常にサイロ化されており、異なるソースのデータを相関付けることは不可能ではないものの、非常に困難です。すなわち、インサイトの生成は単一のデータソース領域に限られ、顧客中心的なビューも提供されません。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5e91fdea479029de/5ee937da6aaf2924fd230671/blog-telecom-traffic-ownership.png" data-sys-asset-uid="blt5e91fdea479029de" alt="" style="display: block; margin: auto;">
</p><figcaption>最も一般的なシステムでは、データオーナーシップが分離されている
</figcaption><p>従来型のアプローチを脱却して、すべての情報を単一の分析プラットフォームに並べることができれば、新手法によるデータ分析を実現できます。つまり、顧客エクスペリエンスをサービス品質に対して、また事後にシステム可用性に対してマッピングで測定し、問題が生じたコンポーネントを詳細なビューで見るといったことが可能になります。同じデータセットと分析能力を使って、不正なアクセスやネットワークの悪用を検知することもできます。&nbsp;
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0314eebd4a7b5095/5ee93969688c1c62a49adb90/blog-telecom-traffic-collocation.png" data-sys-asset-uid="blt0314eebd4a7b5095" alt="" style="display: block; margin: auto;">
</p><figcaption>サイロ化された環境の配置例
</figcaption> <strong><h3>シンプルにデータを投入する&nbsp;</h3></strong><p>KPIや障害管理、インベントリ情報、CDR/EDRデータといったインフラデータの多くは、RDBMSやHadoopの精選されたフォームに格納されています。このような複雑なシステムからデータを取得し、Elastic Stackに手っ取り早く投入する1つの方法として、そのシステムと直接統合するというやり方があります。必要なクエリの記述がとても簡単な上、RDBMSにデータのビューを作成したり、SQLレベルでエンリッチを行うことも可能です。ElasticはElasticsearch-Hadoopコネクタを提供しており、Hadoop統合の場合も同様です。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt752a486ada0910e3/5ee9399d6b547b2c37e3a098/blog-telecom-traffic-rdbms-integration.png" data-sys-asset-uid="blt752a486ada0910e3" alt="" style="display: block; margin: auto;">
</p><figcaption>Elastic RDBMS統合の例
</figcaption><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt20f2a3a02fa59c08/5ee939af688c1c62a49adb94/blog-telecom-traffic-hadoop-integration.png" data-sys-asset-uid="blt20f2a3a02fa59c08" alt="" style="display: block; margin: auto;">
</p><figcaption>Elasticsearch-Hadoop統合
</figcaption><p>中には、この種の高度なデータウェアハウスを導入していない組織もあります。その場合、LogstashやBeatsを使うことで、EDRやCDRなどのデバイスログ、あるいはMMEのようなコアネットワークデバイスの信号情報データを直接投入できます。
</p> <strong><h3>データエンリッチが重視される理由</h3></strong><p>通信業界で使われるシステムの多くは1つの機能領域に特化したもので、限られたビューしか提供しません。しかし現在、システム性能の向上でより多くのデータを格納できるようになり、何より重要なデータ処理速度も上がりました。顧客のトラフィックやプランニング、インベントリ管理、パフォーマンス管理、障害管理、設定管理、ソフトウェア管理、環境監査といった複数の領域を組み合わせることが可能です。&nbsp;
</p><p>１つのドキュメントですべての情報を相関付ければ、分析の新しい可能性が拓かれ、問題の早期解決や新しい発見につながります。
</p><p>その対象となる興味深い領域に、次のようなものがあります。&nbsp;
</p><ul>
	<li>実際の計測値に影響する複数の要素の把握
	<ul>
		<li>エラー率に対する人的要素の寄与</li>
		<li>要素タイプ、ベンダー、位置、インストールタイプ別のネットワーク要素のパフォーマンス把握</li>
		<li>天候および環境的条件が計測値に与える影響</li>
	</ul></li>
	<li>プラットフォームと周辺システムおよび接続の概要
	<ul>
		<li>問題のあるソースの早期特定（MTTRの短縮）</li>
	</ul></li>
</ul> <strong><h3>格納と処理</h3></strong><p>Elastic Stackの核にあるElasticsearchは、データの格納と分析のために設計されています。あらゆるタイプのデータを格納できるため、データセットに設定可能なあらゆる問いに答えるすぐれたオブザーバビリティツールとして使えます。&nbsp;
</p><h2>音声通信データの基本&nbsp;
</h2><p>音声トラフィックに関して、通信事業者がシステムから最も一般的に取得しているのがCDR（call data records、通話データ記録）です。CDRをElasticsearchに投入するには、特にデータエンリッチを中心とした簡単な事前処理が必要です。処理後のデータは、深いインサイトを引き出せるよう、データを理解するために十分な情報を備えたものにする必要があります。&nbsp;
</p><p>そのように処理したデータセットからは、多数のKPIを抽出できます。簡単に作成できる可視化や分析の例を、以下にいくつか挙げてみます。
</p><h3>CDR（call drop ratio、通話切断率）
</h3><ul>
	<li>プラットフォームの問題により切断された通話の数</li>
	<li>システムがルートした通話数</li>
</ul><h3>ACD（average call duration、平均通話時間）
</h3><ul>
	<li>相手先別、およびプロダクト別の平均通話時間</li>
	<li>ACDが相手先別、およびプロダクト別の平均通話時間を上回る顧客の割合</li>
</ul><h3>NER（network efficiency ratio、ネットワーク効率レシオ）
</h3><ul>
	<li>所与の相手先に通話を取り次ぐシステム能力の表現&nbsp;</li>
	<li>所与の相手先についてNERが平均を下回った顧客の割合</li>
</ul><p>以下は、上に挙げた全パラメーターを可視化したものです。&nbsp;
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte6b77815af8cc86c/5ee93a1443f6b42a02431a58/blog-telecom-traffic-voice-kpis.jpg" data-sys-asset-uid="blte6b77815af8cc86c" alt="" style="display: block; margin: auto;">
</p><h3>ASR（answer seizure ratio、通話成功率）&nbsp;
</h3><p>利用できるビューは次の通りです。
</p><ul>
	<li>成功した通話の数</li>
	<li>発信された通話の数</li>
	<li>相手先別、通話方向別のASRが平均より低い利用者の割合</li>
</ul><p>下の可視化は、上位10の通話先ASR / 成功率のトラフィック監視を示しています。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltfae825b5e48da9c0/5ee93a3f1f2ce6607680400e/blog-telecom-traffic-dest-success.jpg" data-sys-asset-uid="bltfae825b5e48da9c0" alt="" style="display: block; margin: auto;">
</p><h3>SIPトラフィック分析
</h3><p>下の可視化は、エラーコード500のサマリーを示しています。&nbsp;
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt62f17b7acb0cd0c3/5ee93a5f688c1c62a49adb98/blog-telecom-traffic-failures.jpg" data-sys-asset-uid="blt62f17b7acb0cd0c3" alt="" style="display: block; margin: auto;">
</p><h3>CLI（calling line identification、発端末識別）
</h3><p>利用できるビューは次の通りです。
</p><ul>
	<li>相手先別、プロダクト別CLI</li>
	<li>非CLIルートに影響を受ける顧客の数と割合</li>
</ul><p>下の可視化は、異なるレベルでCLI別のプロファイルを表現し、トラフィックストリームをわかりやすく示しています。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt53a5fb4ec0f3c0df/5ee93a808d39260a3ded600f/blog-telecom-traffic-cli.jpg" data-sys-asset-uid="blt53a5fb4ec0f3c0df" alt="" style="display: block; margin: auto;">
</p><h3>発信/受信数分析
</h3><p>Elastic Stackを活用すると、非常に詳しいデータビューを構築できます。簡単な手順で発信/受信数から分析したパーセント値を算出できるだけでなく、Elasticsearchを使った高度なアグリゲーションや、データセット内の利用可能なフィールドで分割することも可能です。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb32711db1768c0c9/5ee93a9f8d39260a3ded6013/blog-telecom-traffic-calling-called.png" data-sys-asset-uid="bltb32711db1768c0c9" alt="" style="display: block; margin: auto;">
</p><h3>音声トラフィック分析における異常検知&nbsp;
</h3><p>異常検知を活用すると、あらゆるトラフィックに簡単に単一の機械学習ジョブを設定して、あらゆるパラメーターやデータエンティティを自動で分割できます。エンティティごとに個別の閾値設定が必要となる従来型のアラートとは異なるアプローチです。機械学習ベースのアラートは、ネットワークに固有の挙動に自動的に適応します。さらにネットワークの不具合検知をより簡単に、迅速に実行するだけでなく、異常な振る舞いを正確に示すことができます。このような異常からは、悪意ある行為者による、収益を目的としたネットワーク悪用が多く見つかります。&nbsp;
</p><p>Elastic Stackの機械学習の分析を実施する一般的な手順は次の通りです。
</p><ol>
	<li>ソースからデータを投入する</li>
	<li>データに機械学習検知を適用する</li>
	<li>可視化や解釈のほか、チケット、アラートが生成される&nbsp;</li>
</ol><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltfe259e92478182bd/5ee93ab6dee8140c761c08e2/blog-telecom-traffic-typical-ml.png" data-sys-asset-uid="bltfe259e92478182bd" alt="" style="display: block; margin: auto;">
</p><figcaption>機械学習分析の一般的なアプローチ&nbsp;
</figcaption><p>下の例では、マダガスカルから発信されたトラフィックの異常を確認することができます。システムが接続の著しい増加を検知して、自動のアラートを生成しました。&nbsp;
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt42fe158311a23811/5ee93b21146cc4629e1ac847/blog-telecom-traffic-anomaly-1.png" data-sys-asset-uid="blt42fe158311a23811" alt="" style="display: block; margin: auto;">
</p><p>以下は別のダッシュボードで、ガボン共和国からのトラフィックの異常を示しています。ユーザーはこの異常検知ビューから、ユーザー作成のカスタムダッシュボードに直接移動することもできます。
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaf86bfd88ad4bd08/5ee93b30146cc4629e1ac84b/blog-telecom-traffic-anomaly-2.png" data-sys-asset-uid="bltaf86bfd88ad4bd08" alt="" style="display: block; margin: auto;">
</p><p>このケースで、通信事業者はガボンから発信されるトラフィックアラートの詳細を確認して、異常が個別の番号に起因することをすぐに理解できます。&nbsp;
</p><p>いま、CDRデータ分析のためにElastic Stackを導入するケースが急速に増えています。各通信事業者にとって、利用者の振る舞いを追跡し、異常な挙動が見つかった場合に重要なイベントをすみやかに把握できることは重要です。売上機会の損失や、評判を下げるリスクの軽減に大きく貢献するからです。
</p> <strong><h3>CSSR（call setup success ratio、コールセットアップ成功率）</h3></strong><p>通信事業者が継続的に監視すべきKPIの1つに、CSSR分析があります。迅速な対応能力があれば、収益機会の損失と、顧客満足度の低下を防止できます。多くの場合、特定の値の落ち込みがネットワークエラーによるものか、利益目的でネットワークを悪用（例：通話の大量発信、番号スキャンなど）している利用者によるものかははっきりしません。しかしElastic Stackを使えば、状況はずっとシンプルになります。通信事業者は、通話試行数における、発信者数と受信者数の分布を簡単に確認できます。オペレーションチームは、個々の番号や、番号のグループで絞り込んで、すみやかに仮説を検証できます。運用現場に機械学習の異常検知を活用して、精度を妥協することなく、利用者のトラフィックにおける異常なスパイクを発見することも可能です。&nbsp;
</p><p>下の例では、SS7監視システムが生成するASN1通話データ記録から、データを直接デコードしています。Ingestパイプラインには追加スクリプティングが含まれ、エンリッチ（SPC名、IP名）に使用されています。&nbsp;
</p><p>発信者が存在し、かつ受信者に着信の通知があった場合を“正常”と仮定します。
</p><p>下の図は、4つの異なる統計値を示しています。
</p><ul>
	<li><strong>All：</strong>通話の受信データ記録の数</li>
	<li><strong>distinctCalling：</strong>発信者側のユニークイベント数</li>
	<li><strong>distinctCalled：</strong>受信者側のユニークイベント数</li>
	<li><strong>Attempts：</strong>通話試行数</li>
</ul><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf8a89727ef2c43ff/5ee93b487253820a4364d289/blog-telecom-traffic-calls.png" data-sys-asset-uid="bltf8a89727ef2c43ff" alt="" style="display: block; margin: auto; width:650px">
</p><strong><h2>わずか数分ではじめる</h2></strong><p>本記事では、従来サイロ化されていたデータを一元化し、Elastic Stackのパワフルな分析で、通信事業の分野にすばやくバリューをもたらす<a href="/jp/observability">Elasticオブザーバビリティ</a>のメリットをご紹介しました。&nbsp;音声トラフィックデータの可視化は、<a href="/jp/cloud/elasticsearch-service/signup">無料のElasticsearch Service on Elastic Cloudトライアル</a>を利用してはじめることができます。
</p><p>ドイツテレコム社のElasticプロジェクトについてさらにご興味がおありの方は、2018年にミュンヘンで開催されたElastic{ON}イベントのトーク、&nbsp;「<a href="/jp/elasticon/tour/2017/munich/smart-tracing-at-deutsche-telekom">Smart Tracing at Deutsche Telekom - Revealing the secrets behind modern networks with the Elastic Stack</a>」（ドイツテレコム社のスマートトレーシング - Elastic Stackが明かすモダンネットワークの秘密）も併せてぜひご覧ください。
</p>

AUTHOR

の記事 Piotr Kobziakowski

Elastic Stackで構築する通信オブザーバビリティ - 音声トラフィックデータを監視する

Elastic Cloudの無料トライアルに登録

プロダクト＆ソリューション

Elasticについて

各種資料

ソリューション

Elastic (ELK) Stack

NEW