【ITニュース解説】What Is Service Virtualization: Definition, Types & Tools

ソフトウェア開発において、アプリケーションの規模が大きくなるにつれてテストは複雑になる。特に、自分の開発しているアプリケーション（テスト対象のアプリケーション）が、他の様々なサービスに依存している場合、その依存関係がテストの大きな障害となることがある。例えば、外部の決済APIは呼び出すたびに費用がかかったり、社内の別のチームがまだ開発中のマイクロサービスは利用できなかったり、古いシステムは週にたった30分しかアクセスできなかったりといった問題だ。複数のチームが同時にテスト環境を使うことで、テストが壊れるという状況も頻繁に発生する。このような依存関係のせいでテストが滞り、不具合の発見が遅れ、結果としてリリースのサイクルが長くなってしまう。

このような課題を解決するために「サービス仮想化」という技術が役立つ。サービス仮想化とは、テスト対象のアプリケーションが依存している実際のサービス（API、データベース、メッセージキューなど）の仮想的なレプリカ（複製）を作成し、それを使ってテストを進めるソフトウェアテストの手法だ。この仮想サービスは、実際のサービスの代わりに配置され、テスト対象アプリケーションからの呼び出しを傍受し、本物そっくりの応答を返す。単に利用できないサービスを置き換えるだけでなく、その応答を細かく制御できる点が重要だ。例えば、エラーを返したり、特定の状況をシミュレートしたり、呼び出しごとに費用がかからないようにしたりと、思い通りのテスト環境を作り出せるのが大きな価値だ。

サービス仮想化は、アプリケーションが依存サービスに対して行う呼び出しを途中で捕らえ、実際のサービスにリクエストを渡す代わりに、あらかじめ設定または記録された応答を返すことで機能する。この応答の準備には主に2つのアプローチがある。一つは「設定ベース」のアプローチで、エンジニアが手動で仮想サービスの振る舞いを定義する。例えば、「このリクエストが来たら、この応答を返す」といったルールをJSONファイルなどで記述する方法だ。もう一つは「トラフィックキャプチャベース」のアプローチで、ツールがアプリケーションと依存サービス間の実際のやり取りを記録し、その記録された応答をテスト中に再生する。この方法では手動での設定は不要で、実際のサービスが返した振る舞いを正確に再現できる。

具体的な例を挙げよう。ある品質保証チームがEコマースの決済フローを検証しているとする。このフローは、取引承認のために外部の決済ゲートウェイを呼び出す。しかし、このゲートウェイのテスト環境がまだ準備できていなかったり、テスト環境が利用可能でも、CI（継続的インテグレーション）の実行ごとに呼び出すと料金が発生したり、レート制限に引っかかったりする問題があった。また、カード拒否やネットワークタイムアウトといったエラーシナリオを実際のゲートウェイで再現するのは非常に難しいか、不可能だったりする。サービス仮想化を使わない場合、決済ロジックは単体でテストできるものの、外部との連携を含むエンドツーエンドのフローは検証できない。エラーハンドリングのテストも本番環境に近いテストまで持ち越され、不具合の発見が遅れる。

サービス仮想化を導入すると、チームは同じAPIパスを公開する仮想決済サービスを作成できる。この仮想サービスは、承認された取引には正常な応答を、カード拒否にはエラー応答を、ネットワーク遅延をシミュレートするタイムアウト応答などを返すように設定できる。これにより、外部システムの利用状況や費用を気にせず、すべてのコミットに対して決済フロー全体をテストできる。エラーハンドリング、再試行ロジック、代替処理なども完全に網羅され、不具合は早期に発見される。

サービス仮想化の真価は、単に利用できないサービスを置き換えるだけでなく、実際のサービスでは困難な状況を自在にシミュレートできる点にある。例えば、実際の決済ゲートウェイはテスト中にタイムアウトをめったに返さないが、仮想サービスなら必要なテストケースに対していつでもタイムアウトを返すことができる。また、下流サービスが遅い場合のアプリケーションの挙動を確認するために、仮想サービスに3秒の遅延を意図的に追加することも可能だ。さらに、価格APIが本来は値があるべきフィールドに「null」を返すなど、予期せぬ、あるいは不正な応答を返すエッジケースもシミュレートできる。一部の依存サービスは、セッションを通じて状態が変化する（例：注文が「保留中」から「確定済み」に、そして「発送済み」へと変化する）。サービス仮想化プラットフォームは、このようなステートフルな振る舞いもシミュレートできる。このような制御の範囲の広さが、サービス仮想化が単なる「スタブ」（常に同じ応答を返すシンプルなもの）と異なる点である。

サービス仮想化には多くのメリットがある。依存サービスが準備できていなくてもテストを開始できるため、「テストを早期に開始」できる。実際のシステムでは安全でない、あるいは実行不可能なシナリオ（高負荷時の決済ゲートウェイ、メンテナンス中の基幹システム、特定のタイミングでのエラー応答など）も仮想サービスでは簡単に再現できるため、「より完全にテスト」できる。呼び出しごとに課金されるAPIを使う必要がなくなるため、「コストを削減」できる。共有のテスト環境で発生する、他のチームのテストが自分のテストに影響を与えるといった「環境のボトルネックを解消」し、仮想サービスはテスト環境ごとに独立して動作する。また、外部サービスの可用性、レート制限、環境の不整合によって発生する断続的な失敗がなくなり、仮想サービスは常に予測可能な応答を返すため、「CI（継続的インテグレーション）をより確定的」にできる。

サービス仮想化は万能ではないが、特定の制約がある場合に特に有効だ。例えば、アプリケーションが呼び出す予定のサービスがまだ存在しない場合、決済プロセッサやSMSゲートウェイのように呼び出しごとに費用がかかる場合、サードパーティAPIのようにレート制限があったり、複数のチームで共有されることで競合が発生したりする共有環境の場合、レガシーシステムのようにテスト用の設定が難しい場合、そして実際のシステムでは再現が困難な「カード拒否」「サービス停止」「不正な応答」といったシナリオをテストする必要がある場合に、その価値を最大限に発揮する。

サービス仮想化とよく混同される概念に「モック」や「スタブ」があるが、これらは異なる。スタブは、単一のテストのために依存関係をハードコードされた応答に置き換えるもので、通常はテストコード内で作成され、特定の関数やクラスの分離されたテスト（ユニットテスト）に適している。モックも似ているが、応答が正しいだけでなく、依存関係が特定の方法で呼び出されたかを検証する機能が加わる。これらがアプリケーションのコードレベルで動作するのに対し、サービス仮想化はアプリケーションのコード外、ネットワークレベルで動作する。HTTP、gRPC、JDBCなどのプロトコルを介したアプリケーションの呼び出しを傍受し、あたかも本物のサービスと通信しているかのように振る舞う。スタブやモックは主にユニットテストでコードの単体分離に用いられ、サービス仮想化は統合テストやシステムテスト、CI/CDパイプラインにおいて、実際の依存サービスの振る舞いが重要な場合に利用される。

サービス仮想化ツールは、そのアプローチによって分類できる。トラフィックキャプチャツールは、実際のサービスが返す応答を記録し、それを仮想サービスとして再生する。Keployはその代表例で、eBPFという技術を使ってカーネルレベルでHTTPリクエスト、データベースクエリ、gRPC呼び出しなどを捕捉し、仮想サービスとして再生する。オープンソースのスタブサーバーとしてはWireMockが有名で、JSONやDSLでリクエストパターンと応答を定義し、HTTPサービスを仮想化する。MountebankはHTTPだけでなくHTTPS、SMTP、TCPなど複数のプロトコルに対応している。MockoonはGUIで仮想サービスを設定できる。Parasoft Virtualizeのようなエンタープライズ向けのプラットフォームは、HTTP以外のSOAP、MQ、JDBCなどのプロトコルにも対応し、大規模な組織での利用を想定している。

APIサービス仮想化は、REST、gRPC、GraphQLといった現代のAPIエンドポイントに特化したサービス仮想化だ。これは従来のエンタープライズ向けツールがSOAPやメインフレームプロトコルなどを対象としていたのに対し、マイクロサービス開発に必要なHTTPやgRPCの依存関係のシミュレーションに焦点を当てている。設定はよりシンプルで、開発者が読みやすい形式であり、モダンなCIパイプラインとの統合が重視されている。

サービス仮想化は2000年代初頭にエンタープライズ向けのテスト技術として登場し、メインフレームへのアクセス制約を解決するために使われた。当時のツールは強力だが、導入に時間と費用がかかった。その後、WireMockのような軽量なスタブサーバーが登場し、HTTP依存関係の仮想化が開発者にも身近になった。そして現在の進化は「スマートサービス仮想化」と呼ばれ、手動設定ではなく、実際のトラフィックから仮想サービスを自動生成するアプローチが主流となっている。この自動生成された仮想サービスは、手動で設定されたスタブよりも実際のサービスの状態を反映し続けるため、メンテナンスコストが低いという利点がある。

しかし、サービス仮想化にも限界がある。仮想サービスは作成時点では正確だが、実際のサービスが変更されると、仮想サービスがその変更に追従できず、乖離（ドリフト）する可能性がある。トラフィックキャプチャベースのアプローチでは、キャプチャするべき実際のトラフィックがまだ存在しない新しいサービスには適用できない。また、実際のトラフィックの記録や仮想サービスの設定には初期コストがかかり、ごくシンプルな単発のテストであれば手書きのスタブの方が効率が良い場合もある。ツールによってサポートされるプロトコルが異なるため、複数のプロトコルを仮想化する場合、複数のツールを組み合わせる必要が生じることもある。そして最も重要なのは、サービス仮想化は本番環境でのテストを完全に代替するものではないという点だ。仮想サービスは期待される振る舞いを検証するが、実際のデータ、実際の負荷、実際のネットワーク条件が組み合わさって初めて現れる予期せぬ問題をカバーすることはできない。サービス仮想化はテスト範囲を向上させるが、本番環境の監視やオブザーバビリティを置き換えるものではない。

Keployは、eBPFを利用してカーネルレベルでトラフィックをキャプチャすることでサービス仮想化を実現している。Keployが記録モードで動作している間、アプリケーションが行うすべての外部呼び出し（外部APIへのHTTPリクエスト、データベースへのSQLクエリ、gRPC呼び出し、キュー操作など）を傍受し、リクエスト、応答、タイミングメタデータを含む完全なやり取りを記録する。この記録されたやり取りが、CI/CDのための仮想サービス層となる。その後のテスト実行時には、Keployが同じ外部呼び出しを傍受し、実際の依存サービスに到達させる代わりに、記録された応答を再生する。これにより、アプリケーションは実際のサービスが応答したかのように振る舞い、ライブの依存サービスなしでテストを実行できる。これはHTTPのみを扱うツールを超え、API呼び出しの背後にある完全な依存チェーン（データベース、ダウンストリームサービス、キューなど）を一つの記録セッションで捕捉し、CIで再生できることを意味する。

サービス仮想化は、アプリケーションが依存するサービスが増えるほど、テストが環境起因で不安定になるという避けられない問題を解決する。仮想サービスは、このテストの制御を再び開発チームの手に取り戻すことを可能にする。どのようなアプローチを選ぶかは、依存サービスの特性や、投入できる初期投資によって異なる。WireMockのような設定ベースのツールは、HTTPのやり取りに対して正確な制御を提供し、小規模な環境でうまく機能する。エンタープライズプラットフォームは、複雑な環境向けにステートフルなシミュレーションと多様なプロトコルをサポートする。トラフィックキャプチャツールは、実際の振る舞いから仮想サービスを自動生成することで、設定の手間を省く。これらすべてのアプローチに共通するのは、外部システムの準備を待つことなくテストが進められ、CIパイプラインが実行ごとに同じ結果を出すようになる点である。