ネットワーク自動テストの実適用 / JTF2018

July Tech Festa 2018 https://2018.techfesta.jp/speakers#D40

Transcript

1. [D40] ネットワーク 自動テストの実適用 現地に人がいないからネットワークの通信確認は利用者側で… なんてぬるい運用はもうやめようと 自動テストを入れてみた我々が見たものは…! 1 沖縄オープンラボラトリ TIS株式会社 萩原 学 July Tech Festa 2018 2018/07/29
2. 経緯 2 Fy2016 Fy2017 JTF2017 2017/08/27 JTF2018 2018/07/29 ネットワークの検証やレビューに はもう正直疲弊したので全部プロ グラムで自動化できるようにして しまえばいいと思った https://speakerdeck.com/corestate55/jtf2017 実際に使ってみよう! ⚫ どんなものを作って、どう使ってみたのか ⚫ やってみて、実際どうだったのか 架空の利用者を想定した検証
3. もともと どんな話をしていたのか? 3
4. 4 プロビジョニングを自動化して で環境が作れるシステムを作った 5分 半日かけて サービスが問題なく動くか 手作業でテストをする
5. サービス提供のボトルネック? サーバ/アプリ ネットワーク 設定 各種プロビジョナ普及 プロビジョナ発展中 テスト ⚫ テストコード/xSpec ⚫ 各種テストツール ⚫ CI/CDサービス ⚫ 出張 ⚫ 人海戦術 ⚫ 温かみのある手作業 5 NWテストの自動化によりボトルネック解消
6. NWのテスト? ◼NWのテストは大切 ◼「繋がること」の保証 ◼NWは自律分散システム → システム全体の挙動を予測す るのは難しい ◼しかし現実は… ◼物理作業をともなう人力作業 → スケールしない ◼系全体のテストが難しい → 単体のテストしかできない ◼提供するサービスレイヤと一致 しない 6 NW全体の動作を 自動テストする ユースケースによる 「受け入れテスト」 (ソフトウェア開発の知見をとりこむ)
7. どうやって? ◼電子工作のテスト ◼ネットワークのテスト 7 テスト対象 NW Test Scenario Electronic boards tests http://www.astrosurf.com/audine/English/cisup2.htm テストの操作手順を記述 指示を受けて 計測するシステム “Probe”を 動的に接続
8. NWテスト自動化のしくみ(TesterSet) 8 L3SW FW1 (Act) FW2 (Pasv) L2SW1 L2SW2 OFS1 OVS テスト用 ノード Test Scenario (Cucumber) NetTester テスト対象NW “Probe”相当
9. Sample (JTF2017) ◼中小企業ネットワークを想定した模擬環境 ◼SIerがネットワーク作って収めるシナリオ ◼ネットワークの通信試験・リンク障害試験を自動化 9 デモ動画あり https://youtu.be/C7z3aaWgsf4
10. 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年度 ネットワークスペシャリスト試験の問題を もとに、架空の中小企業ネットワークとして設定 (「ヨーヨーダイン社」「タジマックス通信工業社」は架 空の企業名です)
11. ふるまい＝テストシナリオ例 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
12. テストノード生成・物理構成操作 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 として 制御する
13. 実際の業務へ応用してみよう 本題 13
14. NTTCom様への実適用 ◼2016年度の内容に興味を持っていただきました ◼社内の検証用VPLS網の設定変更 ◼複数拠点、冗長化されたルータ(CE)で構成 ◼VLAN単位での拠点間L2接続サービス ◼運用が抱える問題点 ◼CEに投入する設定が手作業でレビューする余裕がない ◼ユーザからの指摘で設定ミスによる通信不可を発見 ◼運用管理者としては品質を安定したいが、テストが物理的に難しい 14 NWテスト自動化の導入
15. ねらい 15 Before After 繋げて! 設定うまくで きてる?? 終わったよ つながるか 確かめないと… ? どこが悪い のだろう… うまく つながらない んだけど!! 繋げて! 全パターン テストしたから 確実 終わったよ 安心して 使える 利用者 運用者 利用者 運用者
16. ねらい ◼最終的に「利用者がやりたいこと」を実現する ◼利用者が実際に流すであろうトラフィックを再現しよう ◼「利用者がやりたいこと」 ◼自分が申請したセグメント(L2)が出てくる ◼そのセグメントで、依頼した拠点間の通信ができる ◼「NW機器に必要な設定が入ること」は手段 ◼Configが正しくても問題が発生していることもある… ◼オペレーションをした上で、利用者が満足か? をチェックしよう 16
17. 対象と観点 17 テスト 環境 本番 環境 障害試験など サービス影響リスクの高い オペレーションのテスト 作業後 ユーザサイドからの 「見え方」のテスト 再現/複製 Deploy
18. 実適用 実際に入れてみたもの・仕組みの話 18 デモ動画あり https://youtu.be/DhKutgqYdSw
19. NetTester の改修 19 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C) “Controller” (Stateful) “Worker” (Stateless)
20. 他システムとの連携 ◼NorthBoundとしてのテストシナリオ実行のサービス化 ◼テストシナリオを実行するAPI層を提供 ◼テスト自体を提供するサービスとして疎結合化 20 Test Scenario (Cucumber) テスト対象NW tcp/3000 (REST API) 他システム (設定自動化) REST API テストシナリオ 実行API テストシナリオ 実行サーバ NetTester (拠点B) NetTester (拠点A) NetTester (拠点D) NetTester (拠点C)
21. テストシナリオ 実行サーバ 動作の全体像 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
22. テストシナリオ 実行サーバ 見え方 22 22 テスト対象 ネットワーク (利用者セグメント) Operator (テスト実行者) ssh (CLI) 拠点1 各拠点 操作シナリオ 記述 (RubyCucumber) Test Nodes …… 拠点N Test Scenario 他システム (設定自動化) REST API Test Nodes
23. (補足) テスト設定 Target ⚫ VPLS網 ⚫ ユーザ視点で見ると(拠点をまたぐ)L2ネットワーク Test Parameters ⚫ ユーザに払い出すL2内に置くテスト用ノードのIP/MAC Parameter Policy ⚫ 今回はあえて固定 ⚫ IP: 利用者が使うアドレスと被らないIPを拠点ごとに確保 ⚫ MAC: 固定 ⚫ Teardown問題, 障害リスクの最小化 ⚫ 稼働中機器の状態変更をは最低限におさえる → テスタ側はテスト対象の状態をなるべく変えない 23
24. 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 テストシナリオ実行
25. 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起動
26. 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起動 パッチ実行
27. 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間の トラフィック
28. 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のログ回収 保存してあった 実行結果を送信
29. 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 シナリオに設定された 要件表と比較 差分が無ければ テスト成功
30. 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 失敗したから 設定見直そう
31. で、どうなの? 入れてみてどうだったのか 31
32. 課題 ◼テスト実行時間 ◼いまの仕組み上、予想されていた問題 ◼オペレーションの精度とテスト効果のバランス ◼(自動)テストの必要性? ◼どうしたものやら 32
33. バランス ◼設定自動化 + テスト自動化の両方を導入 ◼テスト自動化問題なく動作・当初目的はそれなりに達成… ◼とはいえ「設定自動化だけでもよかったのでは?」ともとれる ◼設定自動化の精度が高いと、テスト自動化システムの効果が出 にくい ◼自動テストは安定して動いているが、オペミスがそもそも(少)ない ◼ 変化が現れない → テストの必要性は? …になりがち ◼Configできていれば動くことがほぼ間違いなく保証できる …という状況だと「利用者視点のテスト」の必要性がわかりにくい 33
34. テスト要る? 作業増えるだけでは? 34 利用者に渡して「仕事がはじめられる」までの 時間・品質・リスクをどう変えられるか? 繋げて! 設定! できたよ 俺が チェッ クする のね なんか通 信できな いぞ 繋げて! 拠点 A 設定! 拠点 B 拠点 C 拠点 D まだー? テスト! ← 表に出ない テストのコスト が発生 Too Fat (Cost) なテスト ← タイムラグ +オペレータ調査
35. 「テストの効果」をどう考えるか ◼設定時「間違えずにコードを書く」手順はない ◼ 必要なのは、間違えたときにリーズナブルなコストでそれを見つけて修正すること ◼間違えやすい・判断しにくい操作を対象にするのが有効 35 変化や揺らぎがある ⚫ 人手作業 (ヒューマンエラー対策) ⚫ 自動化シナリオやコードの変更 (自動化システムの動作保証) ⚫ 成否判断に作業者の主観が入る わかりにくい (configと実際の動作 が直接結びつかない) ⚫ 実際に動かしてみないとわかりにくいもの ⚫ 例) Firewall Rule など → 可否を Code/Config から判断しにくい ⚫ 例) 経路制御設定など → 複数デバイスが連動するため系全体の動きが予想しにくい めんどうくさい ⚫ 確認のためのリソース確保・事前準備等、人手が必要・時間 がかかる ⚫ 確認手順が複雑 (確認のオペレーション自体にミスが入りこみやすい)
36. 「テストの効果」をどう考えるか ◼定量的に評価するための指標があるか? ◼テストを入れたことで何が変化したのか? ◼利用者から見える効果…環境引き渡し後の問題発生減 → これ自体はOK ◼ それは「設定自動化」の効果? 「テスト自動化」の効果? ◼ 「ユーザ視点の end-to-end テスト」によって見つけられたものは? ◼どこからが「リーズナブル」なのか? ◼線引き ◼(自動)テストの効果を謳いにくい → 導入を押しにくい ◼ベストプラクティス蓄積が必要だけど導入を押しにくいのでプラク ティスが集まらないみたいな堂々巡り 36
37. で、どうなの? (-) ◼設定自動化がうまく回るとテスト自動化の効果が見えにくい ◼より複雑な (設定自動化したとしても全体の動きがわかりにくい) オペレーション向けの方がテストの効果が出やすいだろう ◼自動化の精度が高く「テストの効果が出にくい」は ”良くない” ? ◼設定自動化システムがあれば「テスト自動化は不要」なのか? ◼たとえば… ◼ 設定自動化が上手くいく前提でテスト自動化を考えなくてもよかった? ◼ 自動化システムを導入せず人力作業を続けていれば、 もっと「テストの効果があった」だろうけど、それは “良い” か? ◼バランスが取れているか? ◼どうやれば「適切なバランス」だと判断できるだろうか? 37
38. で、どうなの? (+) ◼重要なのは、判断・評価のベースラインを決めること ◼設定するのが [人/システム] どちらかを問わず、 NWが満たすべき機能を利用者視点で定義できた。 ◼ たとえば… 設定自動化システム自体の障害・更新等があったらどうする? 人力オペレーションに切り替えたときは? ◼サービスレベル要求や目標設定に沿って自動テストの要否を考える ◼ どのレベルで、どこまでフォローしたいか ◼実際 ◼人力オペのミス発見 ◼設定自動化システム導入時・設定シナリオのチェック 38
39. 参照 39
40. 参照 (OOL/Project) ◼ネットワーク自動テストシステム プロジェクト ◼https://www.okinawaopenlabs.org/single- post/networkautotestsystem ◼SDN技術を応用したネットワークテスト自動化システムの実用 検証を4社共同で実施 | 一般社団法人沖縄オープンラボラトリ ◼https://www.okinawaopenlabs.org/single-post/2018/03/01- press-release 40
41. 参照 (NetTester) ◼NetTesterリポジトリ https://github.com/net-tester ◼net-tester : NetTester本体 ◼scenario-api : シナリオ実行APIサーバ ◼multisite-examples : 多拠点対応シナリオサンプル ◼デモ動画 https://youtu.be/C7z3aaWgsf4 https://youtu.be/DhKutgqYdSw 41