たとえば、あなたがダイエットしようと思い立ったら、痩せるのに成功した人たちに、何をしたのかと訊ねるのではないでしょうか。するとおそらく、「 お酒をやめて、ケールを食べるようにして、8時に寝て、毎日5マイル歩かないと 」といった答えが返ってくるでしょう。健康的なライフスタイルに変えるには、たしかにすべて意味があることかもしれませんが、初日からいっぺんにやろうとすると、99％失敗するでしょう。そうではなく、ゆっくりと、段階的に健康的なライフサイクルに近づけていく必要があります。少しエクササイズを増やしてみたら、次はヘルシーな食べ物を選ぶようにしたり……プロのような生活ができるレベルまでゆっくりと自分自身を引き上げていきます。
サービスの仮想化もこれと同じです。私は何年にもわたって数多くの顧客と協力し、サービス仮想化の導入をサポートしてきたなかで、同じような問題に出会いました。ほとんどの組織は、ビッグバンアプローチを希望します。つまり、最初から複数のチームにまたがって完全に展開されたソリューションを導入し、継続的デリバリーパイプラインの一部として統合したいと考えています。もちろん、これらはすべて、サービス仮想化がもたらすROIを最大化するためには不可欠ですが、初日からすべてを実現しようとすると、サービス仮想化戦略は99％の確率で失敗するでしょう。では、どうすればよいのでしょうか？
ここで、あるストーリーを紹介したいと思います。1人の開発者の体験をたどって、1本の無料サービス仮想化ツールから継続的デリバリーパイプラインの一部として統合されたサービス仮想化の完全な展開に至るまでを見ていきましょう。以下は実際のストーリーに基づいています。
サリーの登場
まず、開発者のサリーを紹介しましょう。サリーはマイクロサービスの作成を任されました。個々のマイクロサービスの開発を開始してみると、彼女のアプリケーションは他のマイクロサービスと接続するため、ユニットテストを作成するのが難しいという問題がわかりました。
優秀で同僚よりもはるかに速く開発を進められたサリーは、できたパーツを統合してテストする必要がある段階まで来ました。当初、サリーはモックを使ってテスト対象を切り離してテストを始めましたが、スタブに置き換えようとするアプリケーションはかなり複雑だったため、システムに組み込む必要のあるロジックを開発するのに多くの時間がかかりました。
そこで、彼女はサービス仮想化に関して調査を始め、非常に複雑な仮想サービスを非常に短時間で作成できることを知りました。彼女は、Parasoft Virtualizeの無料版をダウンロードし、これを利用してサービス仮想化を実現しました。仮想化サービスの作成は非常にうまくいき、実際のサービスが変更されるのにしたがって簡単に仮想化サービスを修正することもできました。結果として、彼女は完全に隔離された環境ですべてのテストと開発を行うことができました。
サリーが同僚の何人かに、このようなVirtualizeの利点について話したところ、サリーが作成した仮想サービスは複数の開発者が利用する共通サービスのものだったので、同僚もそれを使いたいと希望しました。同僚が開発しているアプリケーションからサリーのマシンを参照するよう指定するだけで、仮想サービスを活用できました。同僚もParasoft Virtualizeの無料コミュニティ版をダウンロードして、新しいサービスの作成と調整を行い、無料のデスクトップからこれらのサービスを利用するという方法で、かなりの間、とてもうまくいっていました。これにより、環境に存在していた多くのボトルネックをなくすことができたため、チームの開発とテストは大いにはかどりました。チームはその開発の速さで有名になり、最優秀プロジェクトの座を総なめにしました。
サリーの上役たちが登場
ある日、サリーのチームに管理職クラスがコンタクトしてきました。サリーのチームがサービス仮想化ソリューションを利用し、アプリケーションをより迅速に構築したりテストするのに役立てていると聞いて興味を持ったのです。彼らは、より大きな範囲での仮想化ソリューションの実用性について議論したいと考えていました。それまで何度か、レガシーアプリケーションが原因で統合環境や運用環境に発生した障害をめぐって、大きな騒ぎがありました。アプリケーションは、複雑なESBおよびメインフレームだけでなく、いくつものOracleデータベースにも依存していました。これらのシステムは、以下のような理由からテストすることが難しかったのです。
- データベースのデータが適切でないことがほとんどでした。データをリフレッシュするためのETLジョブはありましたが、週に1回しか実行されていませんでした。そのため、緊急にデータベースのデータ更新を要求しなければらないケースが頻繁にありました。
- データベースのなかには、複製できるものもありましたが、ハードウェアを追加するためのライセンス費用は法外であり、実際に提案が通ることはありませんでした。
- ESBは、マイクロサービスへの転換の影響を受けて改修中であり、公開されたサービスの多くは利用できないか不安定でした。
- コストを節約するため、夜間はメインフレームがオフラインにされていました。そのため、オフショアテストは不可能でした。また、朝に自動ビルドが開始されると、開発チームの多くは、昨夜チェックインしたコードがメインフレームとの連携に失敗することを発見しました。こうして日々のサイクルのうち、まるまる12時間は失われていました。
管理職クラスは、サリーや彼女のチームのメンバーと話をして、彼女たちが開発およびテストサイクルの一環として使用しているサービス仮想化ソリューションが、これらのケースに役立つかどうかを確認したいと考えました。ESBの背後にあるサービスはベーシックなRESTサービスとSOAPサービス、そして独自のXMLを処理するJMSとMQであったため、サリーと彼女のチームはサービスを簡単にシミュレートできることを示すことができました。しかし、レガシーハードウェアに十分に対処するには、仮想化デスクトップツールをパワーアップする必要があったため、 Parasoft Virtualize の製品版を購入しました。
管理職が示したユースケースに存在するさまざまな課題に対して、容易に仮想化を適用できました。仮想サービスがさまざまなユースケースすべてを満たしていることを確認するのに数日かかりましたが、それらの環境で発生していたすべての課題を解消することができました。これは、サリーの組織におけるサービス仮想化の動きにとって重要な転換点の1つでした。なぜなら、サリーのチームが初歩的なサービス仮想化で得た知識を活用して、現実的なコストがからむ複雑な課題に対処できたからです。この取り組みに関する情報は経営上層部にも届き、類似の課題が発生したとき仮想サービスを構築できるよう、組織内にサービス仮想化チームを設けようという決断がなされました。
仮想化チームの発足
サリーはチームを率いるのに適任であり、こうして「チームバーチャルニンジャ」が設立されました。この時点で、チームがボトルネックにならないように受け入れ基準を作成することと同様に、個々の仮想化戦略を軌道に乗せるためのプロセスを確立することが重要になりました。ガバナンスは重要な議題の1つとなりました。チームは、仮想化プロジェクトを円滑に進めるため、役割と責任を設定しました。役割は5つありました。
- テスター:仮想サービスを作成する場合、必ず特定のコンポーネントを仮想化する理由があるはずです。チームは環境内の信頼性の低いアプリケーションをシミュレートしたいという要望を受けることがよくありました。そういった場合、最初に依頼者と会話するとき、「できないことは何ですか？」と訊ねることにしていました。仮想アセットがどのようになれば「完成」かという定義をはっきりさせるには、受け入れ基準を明確に定義しておく必要があるので、この質問は重要です。テスターは、どのテストケースが正常に実行される必要があるかを定義できるためこのプロセスで不可欠な存在です。仮想化チームは、テストの完了時に仮想アセットが完成したことを確認できます。
- 開発者: 仮想化対象のアプリケーションをほとんど、あるいはまったく理解していなくても、仮想アセットを作成することはできます。しかし最小限の労力で仮想サービスを作成するには、シミュレート対象のアプリケーションに関するドメイン知識が役に立ちます。そのため、開発者は仮想アセット作成プロセスに不可欠でした。開発者からサービスがどのように機能しているかを説明されていれば、サービスの振る舞いの理由を理解したうえで仮想サービスを作成できました。
- テストデータ管理: サービス仮想化の課題の多くは、本質的にはテストデータの課題であるともいえるため、仮想アセットを構築するにあたって、テストデータ管理チームが重要になります。ほとんどの仮想アセットは記録と再生によって作成されるため、必要なテストケースが特定され、その動作について合意が得られる時、記録を行う環境に適切なテストデータがあることが重要です。そのため、テストデータ管理チームが仮想化プロセス自体で果たす役割は最小限ですが、最初のサービスを作成する前に、仮想化プロセスにテストデータ管理チームを巻き込むことが重要でした。
- 運用: 仮想サービスは実際のサービスの動作を複製します。そのため仮想サービスが適切に作成されていれば、ユーザーは実際にはシミュレートされたサービスにアクセスしていることを意識しないでしょう。結果として、仮想サービスは実際のサービスがある環境に定義されたエンドポイントで利用できる必要があります。これは、仮想化プロセスの障害になることがあります。多くのユーザーは、アプリケーションが仮想サービスのエンドポイント指すように接続設定を変更する権限を持っていません。Parasoft Virtualize は、プロキシと呼ばれるメカニズムを使用しています。サービスは、サリーのチームによって制御されるプロキシを介して通信することができます。しかし、最初に接続を設定するのは運用チームの仕事でした。運用リソースを事前に特定し、仮想化戦略が実施される前に設定を定義しておくことは、実際にすべてのパイプを接続する時が来たとき、チームが準備を整え、現状を理解できるようにする最良の方法でした。
- リーダーシップ:サービス仮想化プロジェクトが成功するためには、経営層の肩入れが必要です。サリーの場合は、ゼロからスタートして大きな価値を証明したので、これは難しいことではありませんでしたが、チームが生産的に機能し続けるためには、引き続きリーダー層からの注目を維持することが重要でした。
デプロイメント
ガバナンスプロセスを確立した後は、デプロイメントについて考える必要がありました。バーチャルニンジャの各メンバーは、デスクトップ版の Parasoft Virtualize を持っていました。メンバーは仮想サービスをデスクトップ上に作成し、それをユーザーが利用できるようにします。チームメンバーの1人がマシンをシャットダウンしなければならない場合や、休暇を取る場合、仮想サービスにアクセスするユーザーに影響が出るため、チームの人気が高まるにつれて、現状では不十分になってきました。サリーは、デプロイメントアーキテクチャをもう一度アップグレードして、仮想化ステージングサーバーを調達するべき時だと決断しました。
これにより、チームのメンバーが協力し、仮想アセットを共有することが可能になりました。サーバーは「常時オン」で、仮想化成果物のライブラリとして機能しました。サーバーはソース管理システムに接続されており、新しいバージョンのサービスがサーバーにデプロイされると自動的にチェックインされました。これにより、チームはすべての仮想アセットについて一元化された真実のソースを持つことができ、最新のバージョンがどこにあるのか、迷うことなく誰にでもわかりました。
それから数ヶ月間、チームは嬉々として、組織にとって大きく有意義な課題の解決に邁進しました。チームは大きくなり、さらに何人かのメンバーが増えました。チームの存在感を向上させ、活動を知ってもらうため（また、より大きな予算を獲得するため）、サリーは「やったね」プログラムを開始しました。チームが何か定量化可能なROIを達成するたびに、利益を算出し、自分たちの成果と、どのチームが恩恵を受けたのかを説明する全社メールを送りました。これらの「やったね」の例は次のとおりです。
- 対向のSOAPサービスとメインOracleデータベースの拡張テーブルをシミュレートし、支払サービスの111個の組み合わせを自動化されたプロセスによってプロビジョニングしテストできるようにしました。これにより、テストスループットが向上し、テスト実行の自動化が促進され、プロジェクトの1サイクルで27,950ドルが節約されました。
- クラウドに移行する準備が整っていないサービスをシミュレートすることで、クラウド移行戦略を簡略化することができました。これにより、一部のサービスがない状態でも段階的に妥当性検査を行うことができ、スケジュールより2週間先行して移行できました。これにより、45,875ドル分のプロジェクト工数を節約しました。
- 社外のサービスの変更に対していちはやく対応できるよう、新しいサービスの代わりになる仮想サービスを作成し、変更より2〜6週間早く開発/テストチームにアクセスを提供しました。この変更対応により、社外サービスに関連する計画外のダウンタイムが削減され（約30％）、1プログラムにつき27,146ドルが節約されました。
- アカウントを呼び出す際にユニークなメンバーを返すメインフレーム上のメンバー検索サービスをシミュレートし、処理フローのテスト要件を大幅に簡略化しました。ユーザーは、メインフレームとデータベースのデータを制御し、必要なあらゆる動作を挿入できます。これは、15,000時間にのぼるミドルウェアによる予期しない停止時間を大幅に削減する見通しです。
- マスターキーエントリの回帰テストシナリオに必要な112のサービスのシミュレートに成功しました。これにより、チームはキー入力サービスの周辺に仮想サービスをデプロイすることができ、物理的なパフォーマンス環境の必要性を減らし、パフォーマンス環境を追加で調達するために予定されていた設備投資費用を123,654ドル節約しました。
これらの「やったね」メールによって、さらに多くのチームが仮想化を取り入れるようになったほか、テスト自動化プロセスにおけるサービス仮想化の重要性をビジネス部門に理解してもらうのにも役立ちました。
エラーのシミュレーションで評価される
その後、夏の終わりのある晩、セキュリティチームのメンバーが重要なアプリケーションの監査を行い、悪用される可能性のあるシステムへの攻撃経路を発見しました。悪用されれば、機密性の高い顧客データが漏洩するだけでなく、会社がコンプライアンスを逸脱するおそれがありました。迅速に是正されなければ、組織はコンプライアンス委員会のメンバーを入れ替え、罰則対応を開始することになるでしょう。
いっぽうで、セキュリティチームは、特定の時間枠内に欠陥を修正できれば、変更を運用環境にプッシュでき、すべてがうまく収まることに気付きました。課題は、問題を首尾よく再現するために、社外の支払システムの多くがさまざまなエラーを返す状態を作り、意図的に個人情報または顧客データを漏洩させなければならないということでした。セキュリティチームには、欠陥を再現し、これから行う修正を検証できるように、管轄外の支払システムを必要な状態にすることができませんでした。サリーは夜中に呼び出され、出社を求められました。サリーのチームは、これらの社外の支払システム用に作成した既存の仮想サービスを流用し、エラー動作を返すような状態をすばやく作り上げました。アプリケーションを再デプロイする必要はなかったため、開発者が変更を行っている間にシステムの振る舞いを変更し、悪用につながるすべての組み合わせを洗い出すことができました。言うまでもなく、チームは緊急パッチを運用環境に提供するのに成功し、数百万ドルの損害を未然に防ぎました。
仮想化のセンター・オブ・エクセレンス
この件は、チームに注目を集めるのに十分なできごとでした。彼らは「仮想化のセンター・オブ・エクセレンス（COE）」として有名になりました。すばらしい成果を聞いたおおぜいの開発者やテスターがチームに連絡を取り、Virtualizeを使わせてくれないか、自分たちでプロトタイプを作成し、正常系および異常系のシナリオを検証できないかと訊ねてきました。サリーにはそれが可能なツールがありましたが、一般のユーザーにはデスクトップのプロフェッショナル版という重いハンマーは必要なかったので、仮想化基盤を再びアップグレードし、誰でもアクセスできる集中型ダッシュボードであるContinuous Testing Platformを追加しました。これで、一般ユーザーはブラウザーから仮想化サービスとテストケースを作成できるようになりました。
このデプロイメントの進化は、「ハイブリッドモデル」を生み出しました。つまり、個々のチームメンバーはゆるやかに連携しながら自律的に行動できます――たとえば自分たちのニーズに応じた仮想サービスを作成し、それらにアクセスし、変更できます。その一方で、それらの仮想サービスをより大きなアーキテクチャに統合する際には、仮想化のセンター・オブ・エクセレンスと共同で取り組むことができる仕組みがありました。仮想化チームは必要な負荷を得るためにサーバーを追加したり、パフォーマンスチームが始動したらただちにパフォーマンスサーバーを用意することもできます。
この時点で、サリーのもとには包括的な仮想アセットのライブラリとそれに対応する自動化されたテストケースがありました。また、それらのテスト成果物の両方にデータを供給するテストデータのライブラリもありました。実際のサービス作成の大部分は個々のチームによって行われており、サリーのチームの役割は、これらのさまざまな仮想サービスを「環境」に統合することでした。環境とは、実際には仮想アセット、テストケース、テストデータのテンプレートであり、それらを組み合わせて特定の構成を作成することで、テストの要求を満たします。仮想化チームは多数の環境テンプレートを作成し、それらを組織内のさまざまなアプリケーションに合わせて調整しました。
アプリケーションをテストする必要があるが、実環境では不十分なケースがあれば、仮想化センター・オブ・エクセレンスがさまざまな仮想サービスからなる環境を派生させ、チームメンバーがテストを実施できるようにします。多くのチームは、テスト実行の一部としてますます仮想サービスを頼りにするようになり、それが自然と継続的デリバリーパイプラインへの移行につながりました。
最終的に、サリーの組織における仮想化の完成形は、次のようなデプロイメントになりました。
個々のチームメンバーは、ブラウザーで仮想サービスとテストケースを作成します。仮想サービスを更新する必要がある場合、またはロジックを追加する必要がある場合、仮想化COEはデスクトップのプロフェッショナル版でそれを処理します。仮想サービスとテストケースは、Continuous Testing Platformの内部で組み合わされ、その環境が必要になると、ビルドシステムがContinuous Testing Platformを呼び出してクラウドまたは専用サーバーに環境をデプロイします。自動化されたテストケースが開始され、その結果が集計されたダッシュボードに送信され、動的環境が破棄されます。
仮想化デプロイメントの完成形への移行
サービス仮想化によって実現される真の継続的テストは、一晩で出来上がるものではありません。ストーリーからわかるように、組織はさまざまなできごとによって必要性に迫られて、集中化された仮想化チームを作成し、継続的デリバリーパイプラインに統合する道をたどっていきました。
このストーリーは本物であり、ここで書かれていることはすべてサービス仮想化によって実現可能ですが、サリーのように（ちなみに今では重役会の一員です）組織を味方にし、着実に始める必要があります。この、ステップバイステップで、最も効果的な場所で利用するというやり方が、サービス仮想化を組織に根付かせる最善の方法です。人によって道筋は異なるでしょうが、行き着く先は同じであるはずです――つまり、テストの総コストを削減し、テスト自動化プロセスを真に制御する力を得ることです。
（この記事は、開発元Parasoft社 Blog 「Scaling service virtualization: one person’s journey」2018年4月6日の翻訳記事です。）
Parasoft SOAtest/Virtualizeについて
>
SOAtest/Virtualizeは、APIの開発者／利用者に向けてテストの自動化とテスト環境の仮想化の2つの側面から開発を効率化します。SOAtest/Virtualizeは、APIのテストドライバーを提供し、開発中のAPIのテストを自動化する機能と、APIを利用するアプリケーションが必要とするAPIをスタブとして仮想化する機能を同梱して提供します。