1. インフラデータ活用に向けた
NTT コミュニケーションズ
の取り組み
2018.10.16
技術開発部 Data Science TU / Cutting Edge SU
経営企画部次世代PF推進室
亀井聡
DataWorks Summit Tokyo 2018@赤坂インターシティカンファレンス

2. 概要
 自己紹介，弊社の事業ドメインの紹介
 データサイエンスチームの立ち上げ
 インフラデータの活用に向けて
 今後の課題

3. 自己紹介，弊社の事業ドメインの紹介

4. 自己紹介
 亀井聡
 NTT コミュニケーションズ 株式会社
 技術開発部 Cutting Edge SU, Data Science TU
 経営企画部 次世代PF推進室 兼務
 〜2012.06 NTT サービスインテグレーション基盤研究所
 ネットワーク品質計測・トラフィック制御技術の研究に従事
 2012.07〜 NTT コミュニケーションズ 技術開発部
 インターネット可視化
 Data Science チーム・解析基盤の立ち上げ
 解析基盤の商用化に向けた検討

5. NTTコミュニケーションズの紹介と
事業ドメイン
 営業拠点: 40+ Countries/Regions, 110+ Locations
 SI, Managed Service, Security (WideAngle/MSS)
 ネットワークサービス: 190+ Countries/Regions
 Global Internet Transit(GIN), OCN, MobileOne, Enterprise VPN(UNO)
 データセンタ: 20+ Countries/Regions
 Nexcenter
 クラウドサービス: 15+ Countries/Regions
 CloudN, Enterprise Cloud (ECL)

6. NTTコミュニケーションにおける
データ解析の主要な目的
インターネットの変化を捉
えた意志決定
•主要通信の運び手がキャリ
アからITジャイアントに．
•サービス開発，設備投資を
適切に行うことが困難に．
•どこに回線を増設するか，
データセンタを配置するか．
Infrastructure Operation
Company として
•自動化やコスト削減．品質
向上等きめ細かなサポート．
•自営インフラの効率化．
•アウトソースされたエンタ
プライズNW・エッジNWの
運用効率化．付加価値生成．
新たなサービスを産み出す
•CDN / DDoS / SeCaaS w/
VxF基盤 / Data解析基盤
•領域・組織横断で連携した
意志決定を容易に，データ
ドリブンで実施する．
•解析基盤そのものの外販
6

7. データサイエンスチームの立ち上げ

8. データサイエンスチームの立ち上げ
 研究所でトラフィック解析業務→コムに異動して実トラフィックを対象に
 最初のテーマは Internet の可視化
 計測環境の立ち上げや社内データ調整の日々
 調整に際しては比較的高度な知識(技術だけじゃなく)が要求される
 人が足りない，優秀なインフラエンジニアは奪い合い
 データベースやマイニング，マーケティング部隊を統合
 社外に向けてコンサルティングを売っていくチームを方針転換
 まずは社内データ活用に舵を切って，うまくいったら外販する方針に

9. 苦難(?)の歴史 1/4
 手動分析と職人芸のチーム(excel, spss, perl, …)
 個別案件(営業支援案件がほとんど)を個人のスキルで解決
 人によってツールも得意分野も異なり，異動とともに終了
 DB技術(かつてはHadoopも)の検討経験者もいた
 が，基盤としての検証がほとんどで活用経験が少ない．
 基盤の立ち上げ
 メモリをたくさん積んだマシンを用意してRに一度寄せる
 処理コードを git(lab) に載せて再現できるように(Reproducible Analytics)

10. 初期アーキテクチャ
 ESXi
 docker(0.9ぐらいの頃)
 gitlab / rstudio
 Jenkins + Rmd でレポート

11. 苦難(?)の歴史 2/4
 中心的なデータ
 Internet 計測データ
 Xflow データ
 tweet や web access データ
 オンメモリ処理だけじゃ苦しくなってきた
 データ取得組織からデータ授受すればいいと思っていたが，意外とやってると
ころなかった
 データ収集から可視化までひととおり動く環境を作って見せる必要が発生
 Elasticsearch を使ってみることにした
 Kibana が幹部陣に見せるには好評
 サービス側でいろいろいじれる

12. Elasticsearch 採用時のアーキテクチャ
 CoreOS
 docker
 rabbitmq / Elasticsearch-Kibana / logstash
 rstudio で解析

13. 苦難(?)の歴史 3/4
 Kibana のダッシュボードが属人的に高度化
 Elasticsearch の大規模運用が意外とたいへん
 Elasticsearch/Lucene クエリが独特
 もう少し「固い」基盤を使いたい
 Hadoop 採用に至る
 container 上で動くもの，クラウドにも持っていけるもの，の観点で HDP 採用

14.  CoreOS
 Docker w/ swarm
 Ambari / Hadoop (HDP) / Kafka / Elasticsearch-Kibana
 presto
 redash / metabase
 rstudio / jupyterhub
 gitlab / gitlab-ci

15. Python
TensorFlow
Chainer
hivemall
Kibana
Presto
EMC Isilon
HDFS
Elasticsearch
R Markdown
/
Shiny
Hive
Connector
in Presto
Queue
File
Hive
Hadoop
ES-
Hadoop
MySQL/Postgr
eSQL
RDB
Connector
metabase
R
(Jenkins)
RPresto
Jupyter
Ambari
Spark
or
RPresto
es-hadoop
Logstash
Spark-Streaming
Storm
kafka-connect-es
elastic
Package
PyHive
PyHive
kafka-connect-hdfs
Kafka
(Confluent)
kafka-connect-amqp
filebeat
kafka-connector in Presto
NFS
Que/Store Analysis VisualizationData Shipment

16. 苦難(?)の歴史 4/4
 ？？？「商用基盤にしようか」私「え？」
 商用レベルの運用を検討することに
 HDP/HDF ラインセンス購入
 データパイプライン(logstash や kafka の流量監視，HA化等)の検討開始
 Spark (Structured) Streaming にして HDP/HDF に組み込む案
 k8s の High Availability, Self Healing 機能による自律性の獲得

17. NTT Communications CONFIDENTIAL
[Document ID] [Distribution number]
L2/L3SW
L2/L3SW
Isilon
(NFS/HDFS Storage)
Isilon
(NFS/HDFS Storage)
yokozuna
幕張DC 25台
大手町DC 4台
Testbed Network
kubem
amb01 〜 03
kafka01 〜 07
tesla01 〜 04core01 〜 03
note01 〜 03
coredev01 〜 07
Internet

18. Cloud
Compute
Engine
Cloud
Storage
Container
Engine
Cloud
Dataproc
Cloud
Pub/Sub
On-premise
multi bare metals
Internet
Install
Option 1
Option 2
Option 3
User

19. インフラデータの活用に向けて

20. インターネットの計測の取り組み
 traceroute 等のアクティブ測定を用いたもの
 経路情報(BGP)データセットを用いたもの
 特定組織を通過するトラフィックをパッシブ計測したもの．
↓
 アクティブ測定では網羅的な評価が困難．
 経路情報データセットでは測定点から離れるほど不正確に．
 パッシブデータは取得可能な組織が限られる．
 日本国内を対象とした分析データがほとんど存在しない．
20

21. ◼ ISP wars
• 国内主要トランジット事業者7社と契約し、各ASに経路広告を実施
◼ 各ASのcustomer ASとして、多様な分析が可能
• マルチホーム環境でのトランジットの引きの強さの調査
✓ 広告経路を利用した下りtrafficの調査
• peer経路も含めた各ASの隣接関係の調査
✓ customer ASのみに公開される情報の利用
21
IIJ KDDI GIN OCN Pacnet
-> Telstra
Softbank
/ODN
full
full full full
full
full
計測基盤
フルルート
測定用広告経路
トランジット比較環境

22. • インターネット上の様々なコンテンツに対する利用者の体感品質を測定する
• さまざまな回線を、パートナー会社のスタッフ宅等に設置
• 2013年11月から台数、測定エリア、回線、システムを更改しながら測定中
• 現在国内300箇所．Probe x ISP は 500．日々の計測数は20万程度．
internet
各ISP
一般家庭
プログラム配布
データ収集
データ分析・
可視化
NTTコム with パートナー会社
測定サイト①
他社回線
測定サイト②
・・・
測定端末の配布・回収測定に関する問い合わせ、
状況・契約確認等々
データ測定
回線契約・設
置・支払い
端末設定・状況確認・謝礼支払い等々
＋NTTコムビル
でも測定
空いている
ポートを利用
OpenBlocks
101（W） x 142.1（D） x 41（H） ゴム足含まず
測定機器と
測定ソフト
22
インターネット計測システム

23. OCN＋他社ISP(10以上)
フレッツ光＋他社回線
Internet
測定サイト①
測定サイト②
Measure
Cloud n(Public Cloud)
Collector1 – 6
(fluentd)
Controller1-2 (Python)
db1(MySQL)
Queue1 – 3
(Kafka)
……
Collect
Wrangling
Language
Storage（NFS+HDFS)
＠Makuhari, Otemachi
Core01-XX
@Makuhari, Otemachi
Wget LTSV
Ping Raw Log
Probe Master
@hive
Elasticsearch
Probe
Datamart
@hive
Wget Raw Log
Ping LTSV
Queue1 – 3
(Kafka)
Probe Attribute
@MySQL
SQL-Based OSS BI
Analyze
Ingest
Spark Streaming
Gitlab CI
Fluentd
…
rsync
Python
HiveQL
R
R
23
LB
Kibana
Control
Transfer
全体構成

24. 計測状況

25. 品質計測結果
 スループットと遅延でグラフ上にプロット．
 ひとつの点がひとつの計測器によるひとつ
のISPの計測結果を表わす．
 遅延が小さいほどスループットは高い傾向
はあるが，ばらつきは大きい．
x軸:平均遅延
y軸:最悪スループット
大きさ:データ数
•150M×300台/day(raw) 30TB
•500MB/day(変換後json/ltsv) 10TB

26. Windows Update での CDN 利用状況
from Akamai Cache
from Level3
from LimeLight
from Microsoft
from Akamai Transit
Windows10
▽
from Other
マルチCDNから自前化？

27. インターネットの計測
 インターネットは成長を続けている
 変化の中でうまく波に乗れたか，乗り遅れたかで明暗がわかれることも
 ハイパージャイアントのデータ寡占化が進む中，何かできないか？

28. インフラ運用で得られる主なデータ
計測系データ
•Flow / DPI / Capture
•どこからどこへ通信がされているか．
•サンプリング・識別後データ・生データ．
•汎用性はあるが全体で取ると量が膨大．装置負荷も高い．
•Application Log / Syslog
•装置ログ・サーバログ．
•粒度がバラバラ．非構造化．
•SNMP/MIB/Telemetry
•装置が持つ統計値
•汎用性は高いが，装置の接続構造がわからないと扱いが困難．
•Active Measurement / Probe
•実際にパケットを投げてみた結果
•ブラックボックステスト．他社設備も含めた結果が得られる．
•測定計画が自明ではない．
教師系データ
•網構成情報
•近年は論理構成がダイナミックに変化することも多く，必ずしも事前に与
えられない．
•故障・障害情報
•サービスによって粒度がバラバラ．
•場合によっては時期によって異なる場合も．
•インフラの組み換えも頻繁に行うため，学習データとしての単純な利用は
困難．
28

29. 運用高度化の
取り組み
運用者のふるまい
• 障害に気付く
• チケット・アラート / ユーザ反応
• 障害箇所を探す
• データによる切り分け / 追加での計測
• 原因を探る
• 装置ログ / 追加での計測
• アクション
• 交換・再起動
• 接続先への連絡
複数ドメインやレイヤをまたぐことが多い
• ひとつひとつ解いても使い物になりにくい．
• データが足りない
• なにか起きた時に追加データを取る必要．
• 教師データが足りない
• 構成情報や障害情報が不十分．

30. 障害時のWebアクセスの可視化

31. 周期性を持つデータの異常検知
元データ 周期成分分解 + 異常検知
周期成分
周期成分を取り除いたデータに対して確率を求める

32. 運用の高度化
 可視化するだけでも意味がある領域は結構ある
 高度なデータサイエンス手法の適用前にまずはデータを扱えるように
 インフラじゃないデータとの突合により得られるものも多い
 必ずしも運用目的とは限らない．ウェブアクセスとネットワーク品質，とか．
 自分達の強みでお客さまに貢献できるところを探している．

33. 今後の課題

34. NTTコミュニケーションにおける
データ解析の主要な目的
インターネットの変化を捉
えた意志決定
•主要通信の運び手がキャリ
アからITジャイアントに．
•サービス開発，設備投資を
適切に行うことが困難に．
•どこに回線を増設するか，
データセンタを配置するか．
Infrastructure Operation
Company として
•自動化やコスト削減．品質
向上等きめ細かなサポート．
•自営インフラの効率化．
•アウトソースされたエンタ
プライズNW・エッジNWの
運用効率化．付加価値生成．
新たなサービスを産み出す
•CDN / DDoS / SeCaaS w/
VxF基盤 / Data解析基盤
•領域・組織横断で連携した
意志決定を容易に，データ
ドリブンで実施する．
•解析基盤そのものの外販
34

35. 今後の課題
 データサイエンスチームとしての課題
 基盤人材不足→外注を併用
 アナリストはいるがコンサルタントが足りない→ドメイン知識を磨く
 R/SQL は書けるが CI/Stream のようなシステムコードが苦手→頑張る？
 社内での活用から社外での活用に向けて
 強みを発揮できるところで暗黙知を形式知に
 運用分野等，社内できっちり使って社外展開を
 KPIを見ながらサービスを改良できる意志決定に