Tweet
Tweet

Slide 1

Slide 1 text

[D40] ネットワーク 自動テストの実適用 現地に人がいないからネットワークの通信確認は利用者側で… なんてぬるい運用はもうやめようと 自動テストを入れてみた我々が見たものは…! 1 沖縄オープンラボラトリ TIS株式会社 萩原 学 July Tech Festa 2018 2018/07/29

Slide 2

Slide 2 text

経緯 2 Fy2016 Fy2017 JTF2017 2017/08/27 JTF2018 2018/07/29 ネットワークの検証やレビューに はもう正直疲弊したので全部プロ グラムで自動化できるようにして しまえばいいと思った https://speakerdeck.com/corestate55/jtf2017 実際に使ってみよう! ⚫ どんなものを作って、どう使ってみたのか ⚫ やってみて、実際どうだったのか 架空の利用者を想定した検証

Slide 3

Slide 3 text

もともと どんな話をしていたのか? 3

Slide 4

Slide 4 text

4 プロビジョニングを自動化して で環境が作れるシステムを作った 5分 半日かけて サービスが問題なく動くか 手作業でテストをする

Slide 5

Slide 5 text

サービス提供のボトルネック? サーバ/アプリ ネットワーク 設定 各種プロビジョナ普及 プロビジョナ発展中 テスト ⚫ テストコード/xSpec ⚫ 各種テストツール ⚫ CI/CDサービス ⚫ 出張 ⚫ 人海戦術 ⚫ 温かみのある手作業 5 NWテストの自動化によりボトルネック解消

Slide 6

Slide 6 text

NWのテスト? ◼NWのテストは大切 ◼「繋がること」の保証 ◼NWは自律分散システム → システム全体の挙動を予測す るのは難しい ◼しかし現実は… ◼物理作業をともなう人力作業 → スケールしない ◼系全体のテストが難しい → 単体のテストしかできない ◼提供するサービスレイヤと一致 しない 6 NW全体の動作を 自動テストする ユースケースによる 「受け入れテスト」 (ソフトウェア開発の知見をとりこむ)

Slide 7

Slide 7 text

どうやって? ◼電子工作のテスト ◼ネットワークのテスト 7 テスト対象 NW Test Scenario Electronic boards tests http://www.astrosurf.com/audine/English/cisup2.htm テストの操作手順を記述 指示を受けて 計測するシステム “Probe”を 動的に接続

Slide 8

Slide 8 text

NWテスト自動化のしくみ(TesterSet) 8 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS テスト用 ノード Test Scenario (Cucumber) NetTester テスト対象NW “Probe”相当

Slide 9

Slide 9 text

Sample (JTF2017) ◼中小企業ネットワークを想定した模擬環境 ◼SIerがネットワーク作って収めるシナリオ ◼ネットワークの通信試験・リンク障害試験を自動化 9 デモ動画あり https://youtu.be/C7z3aaWgsf4

Slide 10

Slide 10 text

PC テスト対象NW(論理) 10 内部LAN SSL VPN DNS 資産 管理 テスト 環境 PC PC 外部LAN Internet 内部LAN タジマックス通信工業社 ヨーヨーダイン社 DMZ PC PC PC NAT https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mon dai_kaitou_2013h25_2/2013h25a_nw_pm1_qs.pdf 平成25年度 ネットワークスペシャリスト試験の問題を もとに、架空の中小企業ネットワークとして設定 (「ヨーヨーダイン社」「タジマックス通信工業社」は架 空の企業名です)

Slide 11

Slide 11 text

ふるまい＝テストシナリオ例 11 Feature: リモート開発環境への安定したアクセス タジマックス通信工業社の社員として ヨーヨーダイン社内の開発環境に安定してアクセスしたい なぜならリモート作業を日常的に行うから Scenario: リンク障害発生でもリモート接続が切れない Given ヨーヨーダイン社のDMZ内部のVPNサーバ And タジマックス工業のPCをVPNクライアントに And ヨーヨーダイン社のサーバにVPN経由でリモートアクセスして作業 When “FW1” と “L2SW1” 間にリンク障害が発生 Then リモート接続が切れていない https://github.com/net-tester/examples/blob/feature/ood_demo/features/tcp_fw1_l2sw1_linkdown.feature

Slide 12

Slide 12 text

テストノード生成・物理構成操作 12 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS vpn_server tajimax_pc FW状態(Act/Pasv)変化 FW1-L2SW1間 リンクダウン/リンクアップ操作 "patch panel" 設定 (テスト用ノードの配置設定) OpenFlow Switchを Patch Panel として 制御する

Slide 13

Slide 13 text

実際の業務へ応用してみよう 本題 13

Slide 14

Slide 14 text

NTTCom様への実適用 ◼2016年度の内容に興味を持っていただきました ◼社内の検証用VPLS網の設定変更 ◼複数拠点、冗長化されたルータ(CE)で構成 ◼VLAN単位での拠点間L2接続サービス ◼運用が抱える問題点 ◼CEに投入する設定が手作業でレビューする余裕がない ◼ユーザからの指摘で設定ミスによる通信不可を発見 ◼運用管理者としては品質を安定したいが、テストが物理的に難しい 14 NWテスト自動化の導入

Slide 15

Slide 15 text

ねらい 15 Before After 繋げて! 設定うまくで きてる?? 終わったよ つながるか 確かめないと… ? どこが悪い のだろう… うまく つながらない んだけど!! 繋げて! 全パターン テストしたから 確実 終わったよ 安心して 使える 利用者 運用者 利用者 運用者

Slide 16

Slide 16 text

ねらい ◼最終的に「利用者がやりたいこと」を実現する ◼利用者が実際に流すであろうトラフィックを再現しよう ◼「利用者がやりたいこと」 ◼自分が申請したセグメント(L2)が出てくる ◼そのセグメントで、依頼した拠点間の通信ができる ◼「NW機器に必要な設定が入ること」は手段 ◼Configが正しくても問題が発生していることもある… ◼オペレーションをした上で、利用者が満足か? をチェックしよう 16

Slide 17

Slide 17 text

対象と観点 17 テスト 環境 本番 環境 障害試験など サービス影響リスクの高い オペレーションのテスト 作業後 ユーザサイドからの 「見え方」のテスト 再現/複製 Deploy

Slide 18

Slide 18 text

実適用 実際に入れてみたもの・仕組みの話 18 デモ動画あり https://youtu.be/DhKutgqYdSw

Slide 19

Slide 19 text

NetTester の改修 19 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C) “Controller” (Stateful) “Worker” (Stateless)

Slide 20

Slide 20 text

他システムとの連携 ◼NorthBoundとしてのテストシナリオ実行のサービス化 ◼テストシナリオを実行するAPI層を提供 ◼テスト自体を提供するサービスとして疎結合化 20 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) 他システム (設定自動化) REST API テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C)

Slide 21

Slide 21 text

テストシナリオ 実行サーバ 動作の全体像 21 21 NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (利用者セグメント) tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) TestNode起動 コマンド実行 パッチ実行 Trema起動 NetTester Server N …… TestNode起動 コマンド実行 拠点N テストコマンドによる TestNode間の トラフィック テストシナリオ実行 Test Scenario 他システム (設定自動化) REST API

Slide 22

Slide 22 text

テストシナリオ 実行サーバ 見え方 22 22 テスト対象 ネットワーク (利用者セグメント) Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) Test Nodes …… 拠点N Test Scenario 他システム (設定自動化) REST API Test Nodes

Slide 23

Slide 23 text

(補足) テスト設定 Target ⚫ VPLS網 ⚫ ユーザ視点で見ると(拠点をまたぐ)L2ネットワーク Test Parameters ⚫ ユーザに払い出すL2内に置くテスト用ノードのIP/MAC Parameter Policy ⚫ 今回はあえて固定 ⚫ IP: 利用者が使うアドレスと被らないIPを拠点ごとに確保 ⚫ MAC: 固定 ⚫ Teardown問題, 障害リスクの最小化 ⚫ 稼働中機器の状態変更をは最低限におさえる → テスタ側はテスト対象の状態をなるべく変えない 23

Slide 24

Slide 24 text

1. テストシナリオ実行要求 24 24 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) NetTester Server N …… 拠点N 拠点：1…N テスト内容：ping テストシナリオ実行

Slide 25

Slide 25 text

2. 各拠点を初期化 25 25 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) NetTester Server N …… 拠点N 各拠点初期化 NetTester等 コンポーネントの初期化 初期化 Trema起動

Slide 26

Slide 26 text

3. 各拠点にノード作成 26 26 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N ノード作成・ テスト対象NWへ接続 拠点1にAAを作成 拠点1にBBを作成 拠点NにXXを作成 拠点NにYYを作成 TestNode起動 TestNode起動 パッチ実行

Slide 27

Slide 27 text

4. 各拠点でコマンド実行 27 27 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N 拠点1のAAで 「ping XX」を実行 拠点1のBBで 「ping YY」を実行 各ノードでコマンド実行 コマンド実行 コマンド実行 テストコマンドによる TestNode間の トラフィック

Slide 28

Slide 28 text

5. 各拠点からコマンド実行結果を回収 28 28 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 実行結果回収 拠点N AAのログ回収 BBのログ回収 保存してあった 実行結果を送信

Slide 29

Slide 29 text

6. テスト成否を判断 29 29 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) テスト実行 結果 NetTester Server N …… 拠点N シナリオに設定された 要件表と比較 差分が無ければ テスト成功

Slide 30

Slide 30 text

7. 結果をもとに続行/中止を判断 30 30 Test Scenario NetTester Server 1 OFS (Pica8) テスト対象 ネットワーク (SOで作成した 利用者セグメント) テストシナリオ 実行サーバ tcp/3000 (REST API) テストシステム用 セグメント Operator (テスト実行者) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) OFS (OVS) Test Nodes (NetNS) NetTester Server N …… 拠点N テストが成功たから 設定は完了 or 失敗したから 設定見直そう

Slide 31

Slide 31 text

で、どうなの? 入れてみてどうだったのか 31

Slide 32

Slide 32 text

課題 ◼テスト実行時間 ◼いまの仕組み上、予想されていた問題 ◼オペレーションの精度とテスト効果のバランス ◼(自動)テストの必要性? ◼どうしたものやら 32

Slide 33

Slide 33 text

バランス ◼設定自動化 + テスト自動化の両方を導入 ◼テスト自動化問題なく動作・当初目的はそれなりに達成… ◼とはいえ「設定自動化だけでもよかったのでは?」ともとれる ◼設定自動化の精度が高いと、テスト自動化システムの効果が出 にくい ◼自動テストは安定して動いているが、オペミスがそもそも(少)ない ◼ 変化が現れない → テストの必要性は? …になりがち ◼Configできていれば動くことがほぼ間違いなく保証できる …という状況だと「利用者視点のテスト」の必要性がわかりにくい 33

Slide 34

Slide 34 text

テスト要る? 作業増えるだけでは? 34 利用者に渡して「仕事がはじめられる」までの 時間・品質・リスクをどう変えられるか? 繋げて! 設定! できたよ 俺が チェッ クする のね なんか通 信できな いぞ 繋げて! 拠点 A 設定! 拠点 B 拠点 C 拠点 D まだー? テスト! ← 表に出ない テストのコスト が発生 Too Fat (Cost) なテスト ← タイムラグ +オペレータ調査

Slide 35

Slide 35 text

「テストの効果」をどう考えるか ◼設定時「間違えずにコードを書く」手順はない ◼ 必要なのは、間違えたときにリーズナブルなコストでそれを見つけて修正すること ◼間違えやすい・判断しにくい操作を対象にするのが有効 35 変化や揺らぎがある ⚫ 人手作業 (ヒューマンエラー対策) ⚫ 自動化シナリオやコードの変更 (自動化システムの動作保証) ⚫ 成否判断に作業者の主観が入る わかりにくい (configと実際の動作 が直接結びつかない) ⚫ 実際に動かしてみないとわかりにくいもの ⚫ 例) Firewall Rule など → 可否を Code/Config から判断しにくい ⚫ 例) 経路制御設定など → 複数デバイスが連動するため系全体の動きが予想しにくい めんどうくさい ⚫ 確認のためのリソース確保・事前準備等、人手が必要・時間 がかかる ⚫ 確認手順が複雑 (確認のオペレーション自体にミスが入りこみやすい)

Slide 36

Slide 36 text

「テストの効果」をどう考えるか ◼定量的に評価するための指標があるか? ◼テストを入れたことで何が変化したのか? ◼利用者から見える効果…環境引き渡し後の問題発生減 → これ自体はOK ◼ それは「設定自動化」の効果? 「テスト自動化」の効果? ◼ 「ユーザ視点の end-to-end テスト」によって見つけられたものは? ◼どこからが「リーズナブル」なのか? ◼線引き ◼(自動)テストの効果を謳いにくい → 導入を押しにくい ◼ベストプラクティス蓄積が必要だけど導入を押しにくいのでプラク ティスが集まらないみたいな堂々巡り 36

Slide 37

Slide 37 text

で、どうなの? (-) ◼設定自動化がうまく回るとテスト自動化の効果が見えにくい ◼より複雑な (設定自動化したとしても全体の動きがわかりにくい) オペレーション向けの方がテストの効果が出やすいだろう ◼自動化の精度が高く「テストの効果が出にくい」は ”良くない” ? ◼設定自動化システムがあれば「テスト自動化は不要」なのか? ◼たとえば… ◼ 設定自動化が上手くいく前提でテスト自動化を考えなくてもよかった? ◼ 自動化システムを導入せず人力作業を続けていれば、 もっと「テストの効果があった」だろうけど、それは “良い” か? ◼バランスが取れているか? ◼どうやれば「適切なバランス」だと判断できるだろうか? 37

Slide 38

Slide 38 text

で、どうなの? (+) ◼重要なのは、判断・評価のベースラインを決めること ◼設定するのが [人/システム] どちらかを問わず、 NWが満たすべき機能を利用者視点で定義できた。 ◼ たとえば… 設定自動化システム自体の障害・更新等があったらどうする? 人力オペレーションに切り替えたときは? ◼サービスレベル要求や目標設定に沿って自動テストの要否を考える ◼ どのレベルで、どこまでフォローしたいか ◼実際 ◼人力オペのミス発見 ◼設定自動化システム導入時・設定シナリオのチェック 38

Slide 39

Slide 39 text

参照 39

Slide 40

Slide 40 text

参照 (OOL/Project) ◼ネットワーク自動テストシステム プロジェクト ◼https://www.okinawaopenlabs.org/single- post/networkautotestsystem ◼SDN技術を応用したネットワークテスト自動化システムの実用 検証を4社共同で実施 | 一般社団法人沖縄オープンラボラトリ ◼https://www.okinawaopenlabs.org/single-post/2018/03/01- press-release 40

Slide 41

Slide 41 text

参照 (NetTester) ◼NetTesterリポジトリ https://github.com/net-tester ◼net-tester : NetTester本体 ◼scenario-api : シナリオ実行APIサーバ ◼multisite-examples : 多拠点対応シナリオサンプル ◼デモ動画 https://youtu.be/C7z3aaWgsf4 https://youtu.be/DhKutgqYdSw 41