Tweet
Tweet

Slide 1

Slide 1 text

拠点間ネットワークでの "利用者視点の“ ネットワークテストシステム 適用 1 TIS株式会社 萩原 学 ENOG50 2018/05/18

Slide 2

Slide 2 text

おさらい 2 Fy2016 Fy2017 ENOG45 2017/06/23 ENOG50 2018/05/18 物理構成操作を含めた ネットワーク受け入れテスト 自動化の試み ENOG45 Meeting を開催しました http://enog.jp/archives/1671 実際に使ってみよう! ローカル環境での検証

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

NWのテストは自動化が進まない ◼物理機器の各種作業が必要 ◼設置場所が遠隔地 ◼物理配線の変更 ◼複数機器にまたがる操作手順 ◼テスト対象の組み合わせ爆発 7 ユースケースによる 「受け入れテスト」 (ソフトウェア開発の知見を拝借) NWは繋がるもの 届きさえすれば中の設定は画一的 テストも１つに着目、ツールも色々 NWは繋げるもの 色々な機器の整合性を取る必要がある… テスト? 現地の人手作業…

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

NWテスト自動化のしくみ(TesterSet) 9 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS テスト用 ノード Test Scenario (Cucumber) NetTester テスト対象NW “Probe” “回線切断”を OpenFlowで実装

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

PoC状況設定 11 発注者 要件定義 NW基本設計 NW詳細設計 構築 構築指示 納品 受入テスト 実施 受入テスト 作成 構築担当者 ヨーヨーダイン社 要件定義で合意したとおりに、 発注者の業務が行えるような NWが構築されているか? (「ヨーヨーダイン社」「タジマックス通信工業社」は架空の企業名です) タジマックス通信工業社

Slide 12

Slide 12 text

PC テスト対象NW(論理) 12 内部LAN SSL VPN DNS 資産 管理 テスト 環境 PC PC 10.10.10.0/24 外部LAN 203.0.1.113.0/29 Internet 198.51.100.94 内部LAN 192.168.1.0/24 タジマックス通信工業社 ヨーヨーダイン社 タジマックス社はVPNで 接続して共同開発を行う DMZ 10.10.0.0/24 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 13

Slide 13 text

ふるまい＝テストシナリオ例 13 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 14

Slide 14 text

テスト用ノード生成と配置 14 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS vpn_server 10.10.0.11/24 port 9 port 2 OpenFlow Switchを Patch Panel として制御する "patch panel" 設定 (テスト用ノードの配置設定)

Slide 15

Slide 15 text

テスト対象NWの物理構成操作 15 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS port 15 port 14 vpn_server tajimax_pc FW状態(Act/Pasv)変化 FW1-L2SW1間 リンクダウン/リンクアップ操作 PoCでは単純なup/downのみ。 OpenFlowルールで設定入れ ることも原理的には可能

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

2016年度の課題 ◼テストできない構成があった ◼OFS1台を超えるポート数を使ったテスト ◼物理的に離れた地点間のテスト ◼根本原因 ◼使用コンポーネント間の密結合 ◼ 同一筐体内での協調動作が前提 ✓ テストツール(Cucumber) ✓ NetTester ✓ OFコントローラ(Trema) ✓ OVS ✓ テストノード(Netns) 21 NetTester Server OFS OFS Test Nodes (NetNS) 各拠点 操作シナリオ 記述 (Ruby/Cucumber)

Slide 22

Slide 22 text

コンポーネント疎結合化と役割分担 22 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C) “Controller” (Stateful) “Worker” (Stateless)

Slide 23

Slide 23 text

実適用 NTTCom共同検証・多拠点接続WAN通信試験 23 デモ動画あり https://youtu.be/DhKutgqYdSw

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

テストシナリオ 実行サーバ 動作の全体像 25 25 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 26

Slide 26 text

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

Slide 27

Slide 27 text

テスト設定 ◼Target → VPLS網 ◼ユーザ視点で見るとL2 ◼テストに必要なパラメータ ◼ユーザに払い出すL2内でのテスト用ノードのIP/MAC ◼パラメータポリシ ◼今回はあえて固定 ◼ IP: 利用者が使うアドレスと被らないIPを拠点ごとに確保 ◼ MAC: 固定 ◼Teardown問題, 障害リスクの最小化 ◼ 稼働中機器の状態変更をは最低限におさえる → テスタ側はテスト対象の状態をなるべく変えない 27

Slide 28

Slide 28 text

1. テストシナリオ実行要求 28 28 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 29

Slide 29 text

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

Slide 30

Slide 30 text

3. 各拠点にノード作成 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 ノード作成・ テスト対象NWへ接続 拠点1にAAを作成 拠点1にBBを作成 拠点NにXXを作成 拠点NにYYを作成 TestNode起動 TestNode起動 パッチ実行

Slide 31

Slide 31 text

4. 各拠点でコマンド実行 31 31 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 32

Slide 32 text

5. 各拠点からコマンド実行結果を回収 32 32 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 33

Slide 33 text

6. テスト成否を判断 33 33 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 34

Slide 34 text

7. 結果をもとに続行/中止を判断 34 34 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 35

Slide 35 text

テストにかかるコスト? 35 繋げて! 設定しよう 終わらない… ◼テストをしなかった場合 ◼ 暗黙的にユーザが負担 ◼ 問題発生時に信頼度の低下 ・利用開始までのリードタイム悪化 ◼ 作業時のミス対策などのコスト増加 ◼人海戦術のテストをした場合 ◼ カバレッジとテスト時間のバランス ◼ 現地作業員のアサイン・出張 ◼ テスト失敗したときの再実施コスト大 テスト NWテスト自動化で解消 テスト要るの? 作業コスト増えるだけじゃない?

Slide 36

Slide 36 text

実適用の効果まとめ ◼テストにより設定ミスを発見できた ◼手作業で設定変更した後のミスの発見 ◼他システム(設定自動化)連携 ◼作業者のレベルによらない品質保証を実現 ◼実環境(本番作業)の機能テストへの応用 ◼変更内容が機械的にチェックされる安心感UP ◼利用者同等の通信テスト → 機器の不調や網のトラブルなど config 以外の問題発見も可 (事例としてはまだだけど) ◼設定→テストのサイクルを自動化,ワークフロー見直しへ 36

Slide 37

Slide 37 text

まとめ 37

Slide 38

Slide 38 text

まとめ ◼テストシステムの改善 → 実適用可能な構成を実現 ◼コンポーネント間の密結合を解消 ◼分散配置による多拠点間の通信試験 ◼実適用の効果 ◼テストにより設定ミスを発見できた ◼作業者のレベルによらない品質保証を実現 ◼変更内容が機械的にチェックされる安心感UP ◼各フェーズが自動化できワークフローの見直しへ 38

Slide 39

Slide 39 text

発展 ◼テストシナリオ(ふるまい)の定義 ◼リファクタリング (ふるまいを変えずにネットワークを変更する) ◼系切替後の通信経路確認など作業・確認が面倒な操作の自動化 ◼人手ではできないテスト ◼パターン網羅 ◼回帰テスト ◼ランダム性の導入 ◼将来的には、ネットワーク(やシステム基盤全体)の開発プロセ ス・CI/CDへの応用を 39

Slide 40

Slide 40 text

参照 40

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

テスト自動化とこれまでの取り組み 43 テスト対象 NW(トポロジ)の操作 テスト対象 NW機器の設定 テスト対象サーバ (サービス)の設定 テスト用ノードの 作成・テスト実行 テスト用ノードを 対象NWへ接続 テストのための多様なトラフィック生成、 トラフィックの送受信 テストの結果判定 複数ノードの同時制御(client/server etc) 物理・論理構成に対するテストパターンの網羅 必要なテストトラフィックを 必要なポイントで入出力させるための仕組み 物理トポロジのソフトウェアによる操作 障害模擬・物理経路の系切替試験実行 NW機器インタフェース(CLI/REST/NETCONF…) による機器コンフィグレーション、機器状態取得 テスト対象の物理・論理リソース、 サービスの設定・セットアップ ユースケースから各種作業へ分解 テスト全体のオーケストレータ Test Scenario (Cucumber) 済 済 済 済 実際の業務へ適用できる段階 PJ外 PJ外

Slide 44

Slide 44 text

インフラ構築・運用プロセスの展望 44 変更 自動テスト リリース 本番 環境 検証 環境 運用者 機械的に解釈 できる 構成管理 要 件 テストパス後 設定反映 自動構成 自動テスト ソフトウェアによるインフラの継続的なテスト、サービスデリバリ OFS NetTester 変更後の テスト シナリオ