テストをステップアップさせる2つの仮想化

 「物理的に存在するものをソフトウェアでエミュレートして、あたかも存在するかのように利用する技術」
少々乱暴な定義かもしれませんが、仮想化という言葉はこのような状況を指すようになっています。
アプリケーションの品質を高めるというゴールを考えると、
  • 実際にサービスが動く環境で、
  • 実際の使われ方で利用し、
  • そこで発生する障害を解決していく
・・・というのが、一番手っ取り早くて間違いのないところではあります。が、もちろんそんなことをやったら非
難ごうごうの大問題となるのは火を見るより明らかです。
 事前に障害を発見・対策する上では、"本番に近い状況"をテストの段階でどこまで作れるかが、重要な要素になります。これまでのテストで考慮されてきた"本番に近い状況"を、仮想化という視点で捉え直してみると以下のように言い換えることができます。
  • テストの自動化
 HP UFTのような機能テストの自動化ツールでは、テストシナリオに従ってユーザによるGUI操作を記録(必要があればさらに編集して)自動化スクリプトを作成します。HP UFTのAPIテスト機能を考えると、ユーザというのが必ずしも人間であるとは限らず、他のシステムがテスト対象のAPIを利用するということになるので、"広義のユーザ"と捉えることが出来ます。つまり機能テストは、「広義のユーザを仮想化している」とみることが出来ます。
 一方この過程では、実データを使えることはまれなので、実際にありそうなデータとその結果を検証するためのデータを用意します。これは「データの仮想化」の簡単な例です。
  • 負荷テスト
負荷テストも前述の機能テストと同様に「広義のユーザ」と「データ」の2つの仮想化を行っていると捉えることが出来ます。
 しかし昨今のアプリケーションを考えると、"本番に近い状況"を作るためにはまだまだ足らないと弊社では考えています。それを埋める要素が「サービスの仮想化」「ネットワークの仮想化」です。
■さらに仮想化が求められる理由
図1は、昨今のアプリケーションが稼働する環境を模式的に表したものです。
スライド1.PNG
 今となっては懐かしい"クラサバの社内システム(←もう死語ですかね?)"の時代からすると、複雑さは格段に高まっています。
  • クライアントデバイスがPCからモバイル端末と多岐に渡ってきています。様々な機種・OS・アクセス手段を考慮しなければなりません。
  • アプリケーションの構成要素が複雑になっています。インフラ環境も、アプリケーションを構成する機能の一部ですら、自社ですべて提供せず、外部のクラウドやサードパーティーが提供するサービスとの併用を前提とすることが珍しくなくなっています。
  • もちろん、自社で構築するシステム自体も単独で稼働するものから相互に連携して、さらに高い価値を実現しようとしていますし、ERPを中心に据えて周辺のシステムを再編成するようなシナリオもあちらこちらで見ることが出来ます。
  • グローバル化やモバイル化が進展するにつれ、実際のアプリケーションの性能を左右する要素として、ネットワークの特性・品質を無視出来なくなっています。
 このような状況を踏まえて、HPでは従来のテストツール群に加えて、2つの仮想化製品「HP ServiceVirtualization」と「HP NetworkVirtualization」を提供しています(図2)
スライド2.PNG
HP ServiceVirtualizationは、「サービスの仮想化」を担います。次のようなユースケースが想像されます。
  • 「今テスト中のシステムAは、その処理でバックエンドのシステムBの機能を利用しているが、本番稼働中のシステムBをテストでは使えない。あるいは利用に制限がかかって、テスト遅延の原因になる。」
  • 「関連する2つのシステムAとB両方に手を入れる必要がある。Aをテストするために、Bの改修部分が必要だが、Bを改修するためにAの改修部分が必要。どうしよう?」
  • 「基幹系システムを段階的にクラウド化しようと思っている。並行して移行作業を進めようとしているが、テストで移行中の機能をお互い利用できない」
  • 「サードパーティーのWebサービスと組み合わせて、コンシューマ向けサービスを提供しているが、テスト利用でサードパーティーに支払う費用が無視出来ない」
等々・・・。
 サービス仮想化技術は、テスト対象のアプリケーション(Application Under Test:AUT)そのものではなく、AUTが利用する他のサービスを仮想化します。そのイメージを図に興したものが図3です。
スライド3.PNG
 テスト対象のアプリケーションが既存の社内外システムや他社のサービスと様々なプロトコルを介して連携する場合に、間にHP ServiceVirtualizationを入れると、テスト対象システムからのリクエストに対して、HP ServiceVirtualizationが所定の応答を返します。「あたかも存在するかのように応答を返す」というあたりが"仮想サービス"と呼ばれる由縁です。従来でいうところのスタブの類です。
 複数のシステムが連携し、特に並行して手を入れている場合には、お互いの開発進捗状況に影響され待ち時間が発生します。この間は、満足なテストもチューニングもできない単なる費用を浪費するだけになってしまいます。仮想サービスを介することで、関連するシステムの各々が独立してテストやチューニングが可能になり、結果として品質を高めることが出来ます。
2つめの仮想化は、HP NetworkVirtualizationによるネットワークの仮想化です(図4)。
スライド4.PNG
 日本のインターネットインフラの質の高さは世界的に評価されているところです。しかし、グローバル化がさらに進展すると、海外のキャリアが管理運営するネットワークを経由して通信することは避けられません。国内に限定して考えても、モバイル化が大きなテーマになっている現在で、すでに3G,LTE等の特性の異なるネットワークが混在している状況です。単なる帯域だけではなく、パケットのロスやレイテンシー等からなるトータルなネットワーク品質で、みなさんのアプリケーションの性能が左右されるようになっています。
 これまでの負荷テストは、社内インフラを使った開発環境という恵まれた環境の上で、同時ユーザ数の増減や利用シナリオに応じた応答特性をシミュレートしたものでした。しかし、そこには基盤となるネットワーク品質はほとんど加味されてきませんでした。
 HP NetworkVirtualizationは、ネットワークの品質特性データをネットワークから実際に収集して、シミュレートします。開発環境の社内インフラをよりリアルな検証環境に生まれ変わらせるのが、ネットワーク仮想化技術なのです。
 次のようなユースケースで、高い効果が期待できます。
  • アプリケーションや業務内容によらず、モバイルアプリケーションの利用シナリオ全般
  • データセンター移行時やクラウド移行時のSLA保障のための、事前検証
■2つの仮想化を組み合わせたテストサイクル
図5は、これら2つの仮想化技術を組み合わせたテストサイクルです。
スライド5.PNG
次のような流れになります。
①仮想サービスの作成(図6)
  テスト対象のアプリケーションが利用する、仮想化対象のサービスを、HP ServiceVirtualizationで作成します。この定義法は2つあります。
スライド6.PNG
  やり方1)WSDL等のサービスインターフェース定義ファイルを取り込み、応答(「XXがきたら、YYを返す」)を定義します。
  やり方2)実際に稼動している状態のサービス間応答をキャプチャしてインターフェースとデータのやり取りを記録します(※一部のプロトコルは未対応)。
  サービス間の応答は、表形式で定義できます(もちろん、もっと複雑なロジックが必要な場合には、プログラムを組むこともできます)。応答は、サービスの機能的な側面をあらわしますが、それに加えて「負荷がかかったときの応答の遅れ」も意識した応答特性もグラフィカルに定義することが出来ます。
 同時に、HP NetworkVirtualizaionを併用する場合には、ネットワークの特性情報を収集しておく必要があります。元になる特性情報は、3つの手段で入手することができます。
  ・専用のモバイルアプリでWifi情報を収集(モバイルアプリ向き)
  ・拠点でエージェントを起動させて情報を収集(社内拠点間の情報収集向き)
  ・HPが提供するグローバルライブラリの情報を利用。HPでは国内外のキャリア、通信手段ごとの特性データを収集・公開しています。
 これらの情報を元に、拠点間のシミュレーション用データ(ネットワークプロファイルと呼んでます)を定義します。
②HP ALMに登録編集
  HP ALMはライフサイクル管理の要となる製品です。テストの文脈では、テストケースやそれにひもづく(後述する)テストツール用スクリプトの管理、一括実行のコントロール等様々な機能を提供しますが、HP ServiceVirtualizationもHP ALMと連携します。。
③テスト実行を指示
 例の場合は、HP ALMがテスト実行をコントロールするシナリオを想定します。HP ALMが所定の一群のテスト実行を開始すると、対応するツール(UFTやLR)が起動されます。
④テスト実行
 ステップ③の起動指示を受けて、UFTやLRが起動します。
⑤テスト実行のタイミングで、仮想サービスのデプロイを指示
 このタイミングで①で定義した仮想サービスの起動が指示されます。
⑥登録情報から適切なデプロイ
 HP ALMの登録情報から適切な仮想サービスがデプロイされます。これでテスト対象アプリケーションをテストする環境が整いました。
 LRによる負荷テスト実行時に①で定義したネットワークプロファイルを指定することで、拠点間のネットワーク特性を加味したよりリアルな負荷テストが実施できるのです。
HP NetworkVirtualizationでは、図7にあるように、実際のHTTPのやりとりを解析して、パフォーマンス上の問題箇所をスコアリング、改善のガイドを提示してくれます。
スライド7.PNG
■まとめ
 品質向上というスローガンのもとで、これまで機能テストや負荷テストが有償無償含めリリースされており、その利用機会も増えています。しかし、これらのツールは、いわば「目の前のアプリケーションのテスト」をどう効率化するか?という直接的な効果を期待したものです。それに対して今回ご紹介した仮想化は、テストの周辺-他社製のサービスや他システムの代理だったり、ネットワーク環境そのものであったり-に、着目したものです。
 高品質なインフラ環境でいくらチューニングを行っても、サービスイン後に性能問題が発生してしまっては、そのビジネス上の負のインパクトは無視できないものです。
 モバイル化、クラウド化、グローバル化の流れの中で、テストの仮想化技術の重要度は増していく一方だと、HPでは考えています。
カテゴリ: