NTT Communications' Initiatives to Utilize Infrastructure Data
4 likes2,288 views
We will guide you on the status of utilization of the big data analysis infrastructure for infrastructure data, centering on initiatives at the Next Generation Platform Promotion Office.
![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](https://image.slidesharecdn.com/nttcommunications-181018201233/85/NTT-Communications-Initiatives-to-Utilize-Infrastructure-Data-17-320.jpg)
NTT Communications' Initiatives to Utilize Infrastructure Data
- 1. インフラデータ活用に向けた NTT コミュニケーションズ の取り組み 2018.10.16 技術開発部 Data Science TU / Cutting Edge SU 経営企画部次世代PF推進室 亀井聡 DataWorks Summit Tokyo 2018@赤坂インターシティカンファレンス
- 2. 概要 自己紹介，弊社の事業ドメインの紹介 データサイエンスチームの立ち上げ インフラデータの活用に向けて 今後の課題
- 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
- 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を見ながらサービスを改良できる意志決定に