IOT2016, 2016/12/2

1. 運用自動化に向けての
現場からの課題
日本ネットワークイネイブラー株式会社
石田慶樹

2. 本日の内容
• イントロダクション
• 運用自動化の障壁
• 運用自動化の今後

3. Disclaimer
• 今日の講演はこれまでの経験を通して、ネットワーク運
用の自動化に向けての課題についてお話しする予定で
す。内容はネットワークとDNSに偏っています。
• 松本氏曰く
「内容は機械が学習してネットワークを自動運用する未
来の可能性とその難しさについて、過去のご経験から
お話頂けないかなあと…」
「20年以上の厳しいキャリア品質のビジネスをやってこ
られた方の口から、属人化したものの塊みたいなもの
は…」

4. 自己紹介
• 氏名：石田慶樹(いしだよしき)
• 所属：
• 日本ネットワークイネイブラー株式会社
• 経歴：
1988年 東京大学助手
1994年 九州大学講師
1998年 インターネット事業会社へ転職
2005年 株式会社パワードコムに入社
2006年 合併によりKDDI株式会社に所属
2006年 日本インターネットエクスチェンジ株式会社に出向
2007年 同社代表取締役社長
2016年 日本ネットワークイネイブラー株式会社代表取締役社長
4
2006年～
日本DNSオペレーターズグループ代表幹事

5. 日本ネットワークイネイブラー株式会社
JPNE紹介
当社はVirtual Network Enabler
(VNE)※としてISP事業者様のネットワ
ーク設備構築・運用をお手伝いさせてい
ただきます。
主な役割は以下3つとなります。
IPv6ネットワーク構築・運用を当社で担
当いたしますので、ISP事業者は新たに
IPv6ネットワークの構築・運用を行う必
要はありません。
※VNEとは、ISP事業者に対してインター
ネットサービス提供に必要となるネットワ
ーク設備や、その他・システム・運用機
能等を提供する事業者のことです。
http:://www.jpne.co.jp/

6. 本日の内容
• イントロダクション
• 運用自動化の障壁
• 運用自動化の今後

7. インターネットの「かたち」
ISP ISP ISP
ISP
グローバル Tier-1
国内バックボーン
ローカルアクセス
プロバイダ
Mobile
IXIX
ISP
ISP
ISPISP
ISP
ユーザ
ハイパー・
ジャイアント

8. インターネットの「かたち」
ISP ISP ISP
ISP
グローバル Tier-1
国内バックボーン
ローカルアクセス
プロバイダ
Mobile
IXIX
ISP
ISP
ISPISP
ISP
ユーザ
ハイパー・
ジャイアント
コンテンツ
アイボール
Traffic

9. 昨今のトラフィックの伸び
1700017700192002120023400252002740031300
35900382003720040200441004600049300
54000
64200
72200
80400
98100
123500
144500
181300
12800134001470015600166001760019700218002500026500
223002110020200184001880018900217002330025200257002930028000
34900
0
20000
40000
60000
80000
100000
120000
140000
160000
180000
200000
2005年5月
2005年9月
2006年1月
2006年5月
2006年9月
2007年1月
2007年5月
2007年9月
2008年1月
2008年5月
2008年9月
2009年1月
2009年5月
2009年9月
2010年1月
2010年5月
2010年9月
2011年1月
2011年5月
2011年9月
2012年1月
2012年5月
2012年9月
2013年1月
2013年5月
2013年9月
2014年1月
2014年5月
2014年9月
2015年1月
2015年5月
2015年9月
2016年1月
2016年5月
MOBILE/DOWN MOBILE/UP FIXED/DOWN FIXED/UP
情報通信統計データベース：分野別データ：通信：トラヒック
http://www.soumu.go.jp/johotsusintokei/field/tsuushin06.html より作成

10. トラフィックのDownload/Upload比
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
2010年5月
2010年7月
2010年9月
2010年11月
2011年1月
2011年3月
2011年5月
2011年7月
2011年9月
2011年11月
2012年1月
2012年3月
2012年5月
2012年7月
2012年9月
2012年11月
2013年1月
2013年3月
2013年5月
2013年7月
2013年9月
2013年11月
2014年1月
2014年3月
2014年5月
2014年7月
2014年9月
2014年11月
2015年1月
2015年3月
2015年5月
2015年7月
2015年9月
2015年11月
2016年1月
2016年3月
2016年5月
MOBILE FIXED
情報通信統計データベース：分野別データ：通信：トラヒック
http://www.soumu.go.jp/johotsusintokei/field/tsuushin06.html より作成

11. モバイルトラフィックの伸び
513.7567.6642.2
799.6919.9
1127.1
1287.1
1620.0
1858.4
2182.52270.2
2672.9
2932.0
3362.7
3523.0
3906.8
4160.6
4601.34599.4
4912.6
5118.7
5734.65655.2
5968.8
50.2 58.4 66.6 83.4 98.4 123.8143.3179.1204.5242.7257.7312.4344.5388.5441.7528.1589.1 608 693.9 716 810.3862.9912.5962.7
0.0
1000.0
2000.0
3000.0
4000.0
5000.0
6000.0
7000.0
2010年6月
2010年8月
2010年10月
2010年12月
2011年2月
2011年4月
2011年6月
2011年8月
2011年10月
2011年12月
2012年2月
2012年4月
2012年6月
2012年8月
2012年10月
2012年12月
2013年2月
2013年4月
2013年6月
2013年8月
2013年10月
2013年12月
2014年2月
2014年4月
2014年6月
2014年8月
2014年10月
2014年12月
2015年2月
2015年4月
2015年6月
2015年8月
2015年10月
2015年12月
2016年2月
2016年4月
MOBILE/DOWN MOBILE/UP
情報通信統計データベース：分野別データ：通信：トラヒック
http://www.soumu.go.jp/johotsusintokei/field/tsuushin06.html より作成

12. ネットワーク管理のモデルの一例
ネットワーク管理システムの設計で使用する
共通フレームワーク
「Open Systems Interconnection (OSI)」における
FCAPSモデルの定義
•障害管理(Fault Management)
•構成管理(Configuration Management)
•課金管理(Accounting Management)
•性能管理(Performance Management)
•機密管理(Security Management)

13. ネットワーク管理モデル
自動化の容易性
障害管理
(Fault Management)
構成管理
(Configuration Management)
課金管理
(Accounting Management)
性能管理
(Performance Management)
機密管理
(Security Management)
◎
◎
△
△
×

14. 障害管理
•障害管理の目的は、ネットワーク障害の検出、ログ、ユーザーへの通
知、障害からの回復、ネットワークの可用性（必要なときに必要な人
が使用できること）の向上
障害管理(Fault Management)
•障害の現象把握
•障害の切り分け
•システム上の重要な修正を確認
•障害の復旧
•障害報告書の作成(障害内容と復旧作業の記録)
•再発防止策の策定・実施
障害管理の実態

15. ネットワークの運用管理
定常業務
•健全性維持
•機密性維持
•課金業務
(従量課金)
準定常業務
•開通作業
•増速作業
•更新作業
緊急業務
•イベント
対応
•障害対応

16. 運用体制の進化
属人化の段階
•ネットワーク設計・構築と運用が一体化して進行
マニュアル化の段階
•ネットワーク設計・構築と運用の分離
•手順書作成
隠れ属人化の発生
•すべてが明文化されることはないので一部分が属人化
•運用者の中にキーマンが発生
属人化の積極的推進
•システムの高度化に伴い知識・経験を伴う属人化を肯
定
技術者(営業日対応)と運用者(24時間365日対応)
運用者から技術者へ緊急時エスカレーション体制の確立
技術者は自ら対応行う場合／対応の承認を出す場合

17. 本日の内容
• イントロダクション
• 運用自動化の障壁
• 運用自動化の今後

18. 運用自動化の障壁
人間の関与

19. 運用自動化の障壁
障害対応
イベント対応
•イベント対応
•DoS対応
脆弱性対応 「運用でカバー」

20. 運用自動化の障壁
障害対応
イベント対応
•イベント対応
•DoS対応
脆弱性対応 「運用でカバー」

21. 障害の種類(対象による分類)
ハードウェア故障
•予備系への切り替え
•ハードウェアの交換
ソフトウェア・バグ
•再現性の問題
•発現から修正まで時間が必要

22. 障害の種類(原因による分類)
作業ミス
•システム高度化によってリスクの増加
時限爆弾型
•別名「n日問題」
•n=24.8, 49.7, 208.5, 248, 497, 828, 994, 1243
n日問題 - はてなダイアリー「３流（技術屋 and 本読み）」より
http://d.hatena.ne.jp/marujx/20151205
ドミノ型
•あるイベントが別の障害を誘起

23. 障害対応(実例紹介)
作業ミス
•実例
時限爆弾型
•実例1：稼働後一定時間経過後
•実例2：機器の新規導入
ドミノ型
•実例1：データセンター
•実例2：DDoS契機

24. 障害対応
障害対応の
そもそも論
回復を
優先すべきか？
原因追究を
優先すべきか？

25. 障害対応
•短時間で回復可能
•同じ原因で障害が再発する可能性
回復を優先した場合
•原因追及に時間が必要
•許容される時間内で回復ができない可能性
原因追及を優先した場合

26. 障害対応(富豪的解決)

27. 運用自動化の障壁
障害対応
イベント対応
•イベント対応
•DoS/DDoS対応
脆弱性対応 「運用でカバー」

28. イベント対応
暴れるトラフィック
•1日でピークが1割以上上下
•ある程度の余裕を持ったリンクでの輻輳発生
•トラフィックの手動による迂回
•受信側(アイボール側)でとれる対処は限定的
•実は送信側(コンテンツ側)も対処に苦慮
http://www.jpix.ad.jp/jp/technical/traffic_metropolitan.html より

29. イベント対応
•水責め攻撃
•Mirai Botnet
DoS/DDoSの流行
•自分への攻撃
•他者への攻撃
•他者への攻撃による影響
DoS/DDoSの影響

30. 運用自動化の障壁
障害対応
イベント対応
•イベント対応
•DoS対応
脆弱性対応 「運用でカバー」

31. 脆弱性対応
Cisco等のルータ
•Ciscoは最近では平均で年2回程度
DNSとりわけBIND
•平均で年4～5回
•続けさまに出る月も
http://dnsops.jp/event/20160624/BIND%E3%81%8B%E3%82%89%E3%81%AE%E5%8D%92%E6%A5%AD_%E9%85%8D%E5%B8%83%E7%94%A8.pdf より

32. BINDの脆弱性
http://techlog.iij.ad.jp/archives/2135

33. BINDの脆弱性(続き)
• ．．．しかしみんな使っているから安心かというとそうで
もなく、BIND は外部からの攻撃でサービス停止に陥る
ような脆弱性が年に数件発見されています。とくに、な
ぜか毎年のように7月になると BIND の脆弱性が発見
されるので、DNS 関係者には夏の BIND 脆弱性祭を
存分に楽しむため、7月はスケジュールを空けて待ちか
まえる人も多いようです。今年の7月は影響範囲の極
めて小さいもので拍子抜けしたところに、9月末になっ
てヤバい脆弱性をブチこんでくるフェイントを決めてくる
など、いつも運用担当者を飽きさせることがありません
(だいぶ感覚が麻痺してる)。．．．

34. BINDの脆弱性(続き)
http://dnsops.jp/event/20160624/BIND%E3%81%8B%E3%82%89%E3%81%AE%E5%8D%92%E6%A5%AD_%E9%85%8D%E5%B8%83%E7%94%A8.pdf より

35. BINDの脆弱性(続き)
http://www.slideshare.net/ttkzw/bind-of-summer

36. BINDの脆弱性(続き)

37. BINDの脆弱性(続き)
アメリカモフモフうさぎ

38. BINDの脆弱性(続き)
American Fuzzy Rop

39. BINDの脆弱性(続き)
American Fuzzy Lop
•GAを使ってテストケースを変更し、
カバレッジを上げるファジングツール
•機械的に生成したテストデータでソフトウェア
の挙動を見るツール
• CVE-2015-5477: An error in handling TKEY queries can cause
named to exit with a REQUIRE assertion (2015/07/28)
• CVE-2015-5986: An incorrect boundary check can trigger a
REQUIRE assertion failure in openpgpkey_61.c (2015/09/03)
• CVE-2015-5722: Parsing malformed keys may cause BIND to
exit due to a failed assertion in buffer.c (2015/09/03)

40. 脆弱性対応
•その脆弱性に該当するのかどうか
•直ちに対応すべきなのか
•副作用が発生しないか
•正しく動くか
•機能不足／性能低下はないか
•デフォルト値の変更がされてないか
•対応のための工数がとれるか
•Workaroundで回避できないか
•顧客・社内の承認が得られるか
なぜ脆弱性対応に手間がとられるか

41. 運用自動化の障壁
障害対応
イベント対応
•イベント対応
•DoS対応
脆弱性対応 「運用でカバー」

42. 「運用でカバー」
•設計段階での考慮不足
•設計段階では想定外事象の発生
•顧客の要望によるもの
•設備・機器の想定外事象の発言
なぜ発生するか
•カバーしている領域の設計へのフィードバック
•過去の経緯のクリーンアップ
次回のシステム更新の際に排除できる可能性

43. 本日の内容
• イントロダクション
• 運用自動化の障壁
• 運用自動化の今後

44. 障害に強い構成
(自動化も視野に)
IX SW
Active
光スイッチ
TX RX TX RX
RX TX
10GbE
or
GbE
10GbE
or
GbE
10GbE
or
GbE
10GbE
or
GbE
10GbE
or
GbE
10GbE
or
GbE
IX SW
Standby
お客様側設備
（NW機器)
IX SWを、Active機器とStandby機器の完全二重構成
（冗長構成）。
メンテナンス時、障害時は、光スイッチによる切替に
て対応。
JPIXにおける
光スイッチの導入

45. 運用自動化に向けて
• API化するネットワーク構築・運用環境
http://www.equinix.co.jp/resources/data-sheets/equinix-cloud-exchange/

46. 運用自動化に向けて
http://qiita.com/advent-calendar/2016/netopscoding

47. 運用自動化に向けて
http://www.slideshare.net/taijitsuchiya5/jsnapypyez より

48. 運用自動化に向けて
http://www.slideshare.net/taijitsuchiya5/jsnapypyez より

49. 脆弱性の定量評価
https://www.first.org/cvss/calculator/3.0
https://www.ipa.go.jp/security/vuln/CVSS.html

50. 運用自動化に向けて
自動化の
方向性
アルゴリズムに
基づく
ルールに
基づく
機械学習に
基づく

51. 機械学習に基づく手法
ディープラーニングは万能ではない：AIとは何か、人工知能学会会長が語った常識と誤解 - ＠IT
http://www.atmarkit.co.jp/ait/articles/1611/11/news054.html
•経験の学習からの推論
•状態を監視することによる異常検出
機械学習で何ができるのか
どこまでできるのか

52. そもそも論：
運用の自動化は何を目指すのか？
Reliability Availability Serviceability
Integrity Security

53. 運用自動化
省力化・省人化が本来の自動化の目的
十分なリソース(人・金・時)があれば運
用自動化を進めることが可能
不十分なリソースの中での運用が行わ
れているのが実態
志のある若者が手の届く範囲から進め
ている現状

54. おまけ
究極の属人化
•Peering Coordinator
•海底ケーブル・コーディネータ

55. 本日の内容
• イントロダクション
• 運用自動化の障壁
• 運用自動化の今後
？