機械制御/振動騒音
IR情報 会社情報

スケールの適切な測定 ステートフル被試験デバイス (DUT) の適性サイズ

SPIRENT 
Chris Chapman氏、2016年4月11日
セキュリティ
セキュリティパフォーマンステスト脆弱性スキャンセキュリティヒント脅威モデリングペネトレーションテストペンテストサイバーマンデーサイバーセキュリティ企業

ステートフル被試験デバイス (DUT) の適性サイズ
web_07-01.jpg 
ネットワークのアプリケーションやセキュリティデバイスをテストする場合、「デバイスまたはネットワークが実際に実稼働ネットワークでどのように機能するか」を調べることが重要です。
帯域幅オープン接続接続数/など、DUTのパフォーマンスを測定する従来の方法も必要ですが、これだけでは、有効なデータおよびメトリックを提供するには不十分です。
 

導入前のエンジニアリング規模のテストでは、TCPステートテーブル、アプリケーションテーブル、またはASICのパフォーマンス、フォワーディングエンジンなど、DUTのサブシステム単体を重点的にテストする傾向にあります。

 

また、これらのサブシステムを分離してテストするときに使用されるテストパターンは統合的なもので、テストにおいて特定の要素を分離するよう設計されています。
この方法論では、動的から静的変数へのプロトコルの有限状態機械 (FSM) 遷移やその他のDUTの要素を、静的な測定不能システム (そのプロセス状態では、全体的なシステムヒューリスティックスを考慮しないとエラーになり、システムテストで評価できないシステム) に変換することで、上位レイヤトラフィックの実在性が意図的に制限されます。
このレベルのテスター誘因エラーは、導入パフォーマンス測定の結果が楽観的になりすぎる傾向にあり、また、実行間での再現性に乏しい傾向にもあります。
現実的な効果を測定するには、たとえば帯域幅を100単位のパフォーマンスとしたときに、導入環境 (現実的な複雑性を備えている) においてどの程度のパフォーマンスが得られるか測定します。これで70~80単位程度のパフォーマンスが得られれば、許容誤差が20~30 %であることが分かります。したがって、この容認できない許容誤差を軽減するテストを設計する必要があります。

 

このような大きな許容誤差を軽減するには、テストを構築するにあたってRealism (現実性)、Reliability (信頼性) およびRepeatability (再現性) をできるだけ反映する必要があります。
まず現実性について話しましょう。

 

現実性とは、実際のトラフィックと遜色ないトラフィックをエミュレートすることです。トラフィックの複雑性に関しても、ユーザが体感するトラフィックの質 (すなわち、Quality of Experience、略してQoE) と同等のKPI (重要業績評価指標) が測定されるようにしま。

 

実際には、単一64バイトオブジェクトのHTTP GETは、現在のHTML5ベースのステートフルアプリケーションと同等の複雑性を持っていません。

 

次に、現実性の調整について考慮する必要があります。
基本単位のテストトラフィックを、DUTを横断するトラフィックに合わせると、そのDUT内のサブシステムのギャップが生じ、これらのシステムの相互関係はゼロに近付きます。現実性を調整すると、誤検出や否定的な結果の可能性が減るので、この結果は「非常に良い」とみなされます。
分析面からすると、現実性とは、適切なメトリックの測定を意味します。特に、ユーザによってトラフィックの品質と予測可能性が等しいと判断されるメトリックが、測定に適したルートメトリックと言えます。Webアプリケーションでは、エラーのないページ読み込み時間 (またはレンダー時間) がプライマリメトリックとなります。
ページが2秒以内で読み込まれれば (コードラインが数百から数千に及ぶことに注目してください)、ユーザはページを「良い」と判断します。ページ2~5秒で読み込まれる場合、認知されるQoEは一般的に「普通」~やや悪い」になります。そして、5秒以上かかると (「404 Object Not Found」などのエラーが発生した場合)、ユーザは「悪い」と判断します。
また、実際の評価が「良い」か「悪い」かに関係なく、異なる種類のパフォーマンス結果を感じると、ユーザはネガティビティバイアスを経験します。つまり、過去のパフォーマンス上の不具合は、皮肉にも非常に不均等な影響をユーザ認知に与えます。

 

たとえば、ユーザが99%のインスタンスのパフォーマンスを「良い」と判断しても、「悪い」インスタンスが1%あれば、この「悪い」という印象が非常に強くなります。このパフォーマンスメトリックの分布は現在、個々の読み込み時間と合わせて、KPIの1つとされています。また、KPI測定セットはアプリケーションごとに異なるので注意してください。
KPIテーブルで有意義なトラフィックを定義し、そのトラフィックを測定すれば、スケールを適切に測定できます。

 

実稼働のネットワークのスケールを測定するには、まず宣言から始めることもできます。この宣言とは、たとえば、「アクティブユーザのKPIパフォーマンス評価が最低許容限度を下回るまで、各ユーザが有意なトラフィックを生成し有意なKPIを測定するよう、ユーザをスケールアップできます」などです。次に、不具合が生じるまで、ユーザを同時に、または一定の割合で増やしていきます。

 

パフォーマンス (有意なトラフィックを伴うもの) を報告する際は、以下のような問題点をチェックしてみましょう。

 

「ありとあらゆるユーザ満足度を高く維持したまま、合計何人のユーザを、または1秒あたり何人のユーザをDUTで同時に処理できるか」
この数値が分かれば、実稼働ネットワークでDUTを非常に正確に、かつ高い信頼性で、プロビジョニングできます。

 

次に考慮すべきことは再現性です。
「このテストにより同じパターンが繰り返し生成されるか、またはテストの限界によりトラフィックを回帰させる能力が変わるか」を判断する必要があります。
再現性は重要です。これがないと結果の傾向分析や比較ができません。
DUTが時間にとともに変化するかどうかを常に確認してください。あるいは、自信を持って、DUT結果を別のDUT結果と比較してください。
Spirent AppSecテストソリューションは、現実性、再現性および信頼性を促進します。
これを達成するために、当社では、まず、スケジュールの基本単位をプロトコルではなくユーザに合わせて調整します。これにより、OSIスタック中間のレイヤをエミュレートすることで、「不明ユーザの問題の不明部分」ということがなくなります。そして、当社のLoad SpecアルゴリズムとTCPスタックは世界最高クラスです。TCPでは、ウィンドウィング、輻輳回避、バックオフなどにより、実際のホストのような現実的ワンアームスタックをエミュレートします。

 

つまり、DUTで不具合が検出された場合、単に接続を再開するのではなく、RFCの手続きに従い復旧します。言い換えると、TCPをUDPと同じようには扱いません。

 

SpirentのLoad Specは、信頼性および複数テスト間での再現性を向上させる、特許を取得したヒューリスティックエンジンです。テスターをテストする際は、同じテストを10回実行し、何が生成され、何が測定されるかを確認することをお勧めします。さらに、「これらが同等であるか、またはテスター誘因エラーがあるか」を確認するとよいでしょう。

 

最後に、当社では、時間的凝集の概念を必ずユーザレイヤに組み込んでいます。これにより、ユーザに関連付けられた特定のアクションを、そのユーザが長期にわたって実行するよう、プログラムすることができます (Webベースアプリケーションにおいて重要と言えます)。また、これはすべて、大規模な実行が可能です。

 

まとめ
適切なトラフィック複雑性、適切なKPI、高い信頼性と再現性に基づいてテストを行うことにより、関連性の高い有意義なテストを実現します。
妥協はしないでください。

 

企業ネットワークテストの大きな許容誤差を軽減する方法の詳細については、http://www.toyo.co.jp/ict/products/list/contents_type=1576をご覧ください。

PAGE TOP