なぜネットワーク運用自動化が
進まないのか
Whitebox  Switch編
BIGLOBE  Inc.
Taiji  Tsuchiya
ホワイトボックススイッチユーザ会
第一回勉強会 1	
2015/5/13
Introduction
•  土屋 太二(Taiji  Tsuchiya)
– 28歳
– Twitter:@taijijiji
•  お仕事
– ネットワークエンジニア
– 2011年  :  DCネットワークの運用
– 2012年  :  自社SDNシステムの開発
– 2013年〜現在:  コアネットワークの運用  
2	
2015/5/13
ネットワーク運用のお仕事
•  ルータの設定
•  設定手順書の作成
•  トラフィック制御
•  ネットワーク資源や構成情報の管理
•  機器の増強、廃止、リプレイス
•  回線やDCラックの調達
3	
2015/5/13
ネットワークの自動化事情
•  サーバインフラと比べて
自動化が進んでない
•  Immutable  Infrastructureや
Infrastructure  as  codeとは別世界
 
•  今日は「どうしてこうなった?」話をします
4	
2015/5/13
課題その1 
操作対象OSが多い
5	
2015/5/13
Manufacturer	
 OS	
Cisco	
IOS	
  (IOS-­‐XE)	
IOS-­‐XR	
NX-­‐OS	
Juniper	
 JUNOS	
Brocade	
NetIron	
Network	
  OS	
Arista	
 EOS	
_人人人人人人人人人_	
> メーカー独自のCLI <	
 ̄Y^Y^Y^Y^Y^Y^Y^Y ̄	
6	
2015/5/13
課題その2 
標準的なAPIが
確立されていない
7	
2015/5/13
Manufacturer	
 OS	
 API	
Cisco	
IOS	
  (IOS-­‐XE)	
 •  OnePK(*)	
  
•  NETCONF	
IOS-­‐XR	
 •  OnePK(*)	
  
•  NETCONF	
NX-­‐OS	
•  OnePK(*)	
  
•  NX-­‐API(*)	
  
•  NETCONF	
Juniper	
 JUNOS	
•  JUNOS	
  XML	
  Protocol(*)	
  
•  REST	
  API	
  
•  NETCONF	
Brocade	
NetIron	
   •  NETCONF	
  
•  REST	
  API	
Network	
  OS	
Arista	
 EOS	
 •  eAPI(REST	
  API	
  )	
(*) メーカ独自API	
※1 最新OSの対応状況ですが、Versionによって大きく異なります。
※2 ネットワーク装置の場合「バグの枯れ」を重視するため
   最新OS versionを導入するケースはほとんどありません。
8	
2015/5/13
さくらインターネット 湯澤 民浩さん資料より引用
Internet Week 2014 ようこそ、ネットワーク運用自動化の世界へ!
https://www.nic.ad.jp/ja/materials/iw/2014/proceedings/s4/	
結果的に、装置ごとに異なる
制御モジュールが必要になる
9	
2015/5/13
課題その3 
作業失敗時の
影響が大きい
10	
2015/5/13
影響範囲
•  サーバ :   数サービス 通信断
•  DC系スイッチ : 数十サービス 通信断
•  コア系ルータ :    エリア 全断
_人人人人人人人人人人_	
> 失敗したら総務省 <	
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y ̄	
11	
2015/5/13
課題その4
エンジニアのスキルが
自動化から遠い
12	
2015/5/13
エンジニアの得意領域
ネットワーク屋
•  ルータCLIマスター
•  Cisco/Juniper
なんでも来い
•  パケットに強い
•  トラフィック制御が得意
サーバ屋
•  Linux/Unixマスター
•  Ubuntu/FreeBSD
なんでも来い
•  DBやWebサーバに強い
•  LL言語が得意
自動化開発に
必要なスキルはこちら	
13	
2015/5/13
課題その5
自動化のアイディアが
出づらい文化
14	
2015/5/13
ネットワークエンジニアの文化
•  染み付いたCLI文化
•  インフラの分業化によって、入社時から
Ciscoスペシャリストを目指しがち
•  技術革新がとても遅く、実装はメーカ次第
•  開発者  =  メーカの人
15	
2015/5/13
課題その6
手作業で
なんとかなる作業量
16	
2015/5/13
作業量
•  サーバ:
– 数千〜数万台
– 1台あたりの作業頻度:  週に1-2度    
•  ネットワーク機器:
– コア: 数十台
– データセンタ 数百〜数千台
– 1台あたりの作業頻度:  数ヶ月に1度
17	
2015/5/13
課題その7
開発に
時間が割けない
18	
2015/5/13
ネットワーク屋の働く環境
•  運用メンバーは必要最低限
•  開発にまとまった時間がさけない
•  1件の障害で1週間の予定が吹き飛ぶ
•  学習コストを乗り超えるのに決死の覚悟
19	
2015/5/13
↑ここまで自動化が進まない課題
-------------------------
↓ここから自動化を進めるための期待
20	
2015/5/13
自動化しやすい作業もある
•  ルータ操作以外の運用業務もたくさん
–  ルータを設定
–  設定を入れるための手順書を作成
–  トラフィック制御
–  ネットワーク資源や構成情報を管理
–  機器の増強、廃止、リプレイス
–  回線やDCラックの調達
•  ルータの自動操作は難しいが
状態取得はSNMPを使えば比較的容易
    
21	
2015/5/13
開発の敷居が下がってきた
•  Webフレームワーク
– Python  :  Django,  Flask
– Ruby  :  Rails
•  構成管理ツール
–  Chef
–  Ansible
–  Fabric
•  テストツール
–  Serverspec
–  Infrataster
22	
2015/5/13
ネットワーク業界の変化
•  NETCONF
•  Open  Daylight
•  Whitebox  Switch
23	
2015/5/13
NETCONF(Network  Configuration  Protocol)  
•  XMLを利用したルータ管理プロトコル
•  RFC6241で標準化
•  業界の標準的なAPIを作る目的
•  現時点ではメーカごとにXML記述が異なる
– YANGモデル対応が一つの鍵
24	
2015/5/13
Open  Daylight
•  Linux  FoundationのOSSプロジェクト
•  SDNコントローラプラットフォームを協業開発
•  主要なネットワーク機器メーカや
サーバメーカが参加
25	
2015/5/13
Whitebox  Switch
•  ODMベンダ製スイッチ
– ソフトウェアOSはユーザ自ら選ぶ
•  クラウドやコンテンツ屋のニーズから登場
•  実態は、ネットワーク機能のあるLinuxサーバ
•  サーバと同様の管理ツールを利用可能
26	
2015/5/13
Whitebox  Switchに期待していないこと
•  既存装置をすべてWhitebox  Switchに置き
換える、というアイディアは全く無い。
•  数台の購入だとそこまで安くない。
運用コスト、開発コストも考慮
•  今導入しても、制御モジュールが増えるので
そこまでうれしくない
27	
管理	
  
サーバ	
IOS	
 JUNOS	
IOS-­‐XR	
 Arista	
  EOS	
NetIron	
 Whitebox	
  
Switch	
IOS用	
  
SSH	
JUNOS用	
  
Netconf	
IOS-­‐XR用	
  
Netconf	
REST	
  API	
NetIron用	
  
Netconf	
Ansible	
  ?	
2015/5/13
•  Whitebox登場によるメーカの変革に期待
– ネットワーク装置の全機能を
外部サーバから制御できること
– メーカ間で差分のない制御方法があること
– 標準的なサーバ用ツールが流用できること
•  業界標準の制御方法が確立されれば
対応可否が、機器選定基準になり得る
28	
Whitebox  Switchに期待していること
2015/5/13
自動化開発のストーリー
29	
2015/5/13
想定シナリオ(架空)
•  運用チーム5名から、2名を開発に
•  運用チーム補強のため1名を助っ人増員
•  開発期間は1年間
•  開発が完了すれば運用工数が2/3に
•  開発終了後、保守が0.5人月が発生
•  1人月100万円で計算
30	
2015/5/13
開発コスト  vs  運用コスト
31	
0	
  
20	
  
40	
  
60	
  
80	
  
100	
  
120	
  
140	
  
160	
  
180	
  
200	
  
0	
   6	
   12	
   18	
   24	
   30	
   36	
  
運用5名体制の場合	
運用4名+開発2名体制の場合	
百万円	
ヶ月	
期間	
費用	
開発期間(12ヶ月)	
損益分岐点	
運用:3+1名	
  
開発:2名	
運用:3名	
  
保守:0.5名	
  
開発:1.5名	
  
•  工数削減	
  
•  納期改善	
  
•  オペミス削減	
  
2015/5/13
•  顧客ニーズにあったネットワーク機能を
開発する
•  新しいネットワーク機能やOSSツールを
積極的に試して導入していく
•  ネットワーク運用のかゆいところに
手の届くツールを自分たちで開発していく
32	
開発:1.5名	
   で新しいことを始める
2015/5/13
BIGLOBE  コアネットワークチームの取り組み
•  2014年からチーム内での
Python勉強会を週一で開催
•  全運用メンバがツール開発をマスター
•  外注ゼロの内製開発でノウハウを蓄積中
•  成果物の公開できる部分を切り出して
OSS化を検討中
33	
2015/5/13
まとめ
自動化が進まない課題
1.  操作対象OSが多い
2.  標準的な外部APIが確立されていない
3.  作業失敗時の影響が大きい
4.  エンジニアのスキルが自動化から遠い
5.  自動化のアイディアが出づらい文化
6.  手作業でなんとかなる作業量
7.  開発に時間がとれない
自動化を進めるための期待
1.  自動化しやすい作業もある
2.  開発の敷居が下がってきた
3.  ネットワーク業界の変化
NETCONF  /  Open  Daylight  /  ホワイトボックススイッチ
34	
自動化開発を通して変化に強いエンジニアが育つ
2015/5/13

なぜネットワーク運用自動化が進まないのか Whitebox switch編