Loading article…
ソフトウェア エンジニアリングにおいて、サービス仮想化とは、API駆動型アプリケーション、クラウドベース アプリケーション、サービス指向アーキテクチャなどの異種コンポーネント ベース アプリケーションにおける特定のコンポーネントの動作をエミュレートする方法です。これは、ソフトウェア開発チームとQA/テストチームに、テスト対象アプリケーション (AUT) を実行するために必要な依存システム コンポーネントへのアクセスを提供するために使用されますが、開発およびテストの目的では利用できないか、アクセスが困難です。依存コンポーネントの動作が「仮想化」されているため、実際の稼働中のコンポーネントにアクセスすることなく、テストと開発を進めることができます。サービス仮想化は、ベンダー、業界アナリスト、業界出版物によって、モックとは異なるものとして認識されています。[ 1 ] [ 2 ] API シミュレーション ツールの比較については、こちらを参照してください。
サービス仮想化は、ソフトウェアコンポーネントの動作をエミュレートすることで、開発チームとテストチームに対する依存関係の制約を取り除きます。このような制約は、テスト対象アプリケーションに接続されているコンポーネントが次のような場合、複雑で相互依存的な環境で発生します。
「サービス仮想化」という用語は、この技術が当初ウェブサービスの仮想化に重点を置いていたことを反映していますが、サービス仮想化は、サービス、データベース、メインフレーム、ESB、および共通のメッセージングプロトコルを使用して通信するその他のコンポーネントなど、複合アプリケーションのあらゆる側面に広がっています。 [ 3 ] [ 4 ] [ 5 ]他の同様のツールは、 APIシミュレータ、APIモックツール、オーバーザワイヤテストダブルと呼ばれます。
サービス仮想化は、開発者やテスターがエンドツーエンドのトランザクションを完了するために実行する必要のある特定の依存コンポーネントの動作のみをエミュレートします。システム全体を仮想化するのではなく、開発およびテストタスクの実行に不可欠な依存動作の特定の部分のみを仮想化します。これにより、開発者やテスターが実際のサービスが完了してすぐに使用できるようになるまで待つことなく必要なものを取得できるだけのアプリケーションロジックが提供されます。たとえば、データベース全体を仮想化して（関連するすべてのテストデータ管理を実行し、すべてのテストセッション用にデータベースを設定する）代わりに、アプリケーションがデータベースとどのようにやり取りするかを監視し、関連するデータベースの動作（データベースに渡されるSQLクエリ、返される対応する結果セットなど）をエミュレートします。[ 6 ] [ 7 ]
サービス仮想化とは、テスト対象アプリケーションの動作に必要な実際のコンポーネントの動作をシミュレートする「仮想資産」を作成し、展開することを指します。ただし、開発やテストの目的で実際のコンポーネントにアクセスすることは困難、あるいは不可能な場合に、この仮想資産の活用が重要となります。
仮想アセットは、要求をリッスンし、適切なパフォーマンスで適切な応答を返すことで、依存コンポーネントの代わりとなります。データベースの場合、これはSQLステートメントをリッスンし、データソースの行を返すことを含みます。Webサービスの場合、これはHTTP、JMS、またはMQ経由でXMLメッセージをリッスンし、別のXMLメッセージを返すことを含みます。仮想アセットの機能とパフォーマンスは、依存コンポーネントの実際の機能/パフォーマンスを反映する場合もあれば、極端な負荷やエラー状態などの例外的な状況をシミュレートして、テスト対象のアプリケーションがそのような状況下でどのように応答するかを判断する場合もあります。
仮想資産は通常、以下の方法で作成されます。
その後、特定のデータ、機能、応答時間を表現するようにさらに設定されます。
仮想アセットは、ローカルまたはクラウド（パブリックまたはプライベート）にデプロイされます。開発/テスト環境が依存コンポーネントの代わりに仮想アセットを使用するように構成されている場合、開発者またはテスターは、依存コンポーネントが完了またはすぐにアクセスできるようになるのを待つことなく、作業中のアプリケーションを実行できます。[ 3 ] [ 4 ] [ 7 ]
業界アナリストは、サービス仮想化は「依存ソフトウェア」のために統合テストを「スキップ」する経験が豊富で、十分に洗練されたテストハーネスを備えているIT部門に最適であると報告している。[ 8 ]
この記事の序論で概説したテスト環境のアクセス制約を回避するための別のアプローチとして、チームメンバーが依存リソースの代わりとなるメソッドスタブまたはモックオブジェクトを開発するという方法があります。このアプローチの欠点は、2000年代初頭にサービス指向アーキテクチャの台頭とともに明らかになりました。[ 9 ]多数の依存サービスに依存するコンポジットアプリケーションの増加と、2001年のアジャイルマニフェストの発表後のアジャイルソフトウェア開発の台頭により、開発者やテスターが、現代のエンタープライズアプリケーション開発の開発およびテストタスクを完了するために必要なスタブやモックの数、範囲、複雑さを手動で開発することがますます困難になりました。[ 10 ]
スタブ化からサービス仮想化への進化の第一歩は、2002 年以降 SOA テスト ツールにパッケージ化されたテクノロジーでした。[ 11 ] サービス仮想化の初期の実装は、複合アプリケーションをより効率的にテストできるように、単純なスタブのようなエミュレーションの開発プロセスを自動化するように設計されていました。[ 12 ]エンタープライズ システムがますます複雑化し、分散化するにつれて、ソフトウェア ツール ベンダーは、スタブ化から、より環境重視のサービス仮想化へと焦点を移しました。[ 2 ]スタブ化は、スタブの手動開発と管理によって今でも完了できますが、「サービス仮想化」として知られるようになったものは、市販の既製品 (COTS)サービス仮想化テクノロジーのいずれかをプラットフォームとして使用して、「サービス仮想化アセット」を開発および展開することによって完了します。[ 10 ]
アジャイルソフトウェア開発とDevOpsの人気が高まっていること[ 13 ]により、このような方法で作業するコミュニティにサービス仮想化を提供する新しいツールセットへの需要が生まれています[ 14 ] 。継続的デリバリーや、メインフレームやモノリス開発からより分散されたマイクロサービスベースのアーキテクチャへの移行といったプラクティスは、サービス仮想化の機能とよく適合します。アジャイルおよびDevOpsチームは、蓄積された肥大化が少なく、煩雑なライセンス制限のない軽量ツールを使用することを好みます[ 15 ] 。