クラウドでのテスト自動化を助長するグリッドおよび P2P

グリッドとピア・ツー・ピアの概念によって、クラウドでのテストの自動化に弾みがつきます

クラウド・コンピューティングの最近の傾向として、モバイル機器からクラウドにアクセスする例が急増するなか、爆発的に数が増加する新しいアプリケーションをテストすることが、迅速な開発の妨げとなる可能性があります。この障害を乗り越えるための答えは、クラウドでのテストを自動化することです。この記事では著者が、グリッド・コンピューティングおよびピア・ツー・ピア・コラボレーション機能を追加して、クラウドでの自動化テストを効率化する方法を説明します。また、実際のシステムとシナリオの例も紹介します。

Randy Hayes, Founder and CTO, Grid Robotics

Randy は 1979年、Altair 8080 用の診断テストの作成で経験を積み、1983年に AutoTester という PC 用の初の自動テスト・ツールを作成しました。当時、彼はエンタープライズ・アプリケーションのアプリケーション・ライフサイクル管理ソリューションのベンダー、Worksoft の共同設立者でした。Grid Robotics (旧称 Capacity Calibration) が設立されたのは 2008年 11月のことです。現在この会社は、パブリック・クラウドおよびプライベート・クラウドの PaaS (Platform as a Service) ソリューションの主要なサプライヤーとなっています。



2011年 10月 21日

クラウド・ベースのアプリケーションの機能、セキュリティー、スケーラビリティー、そして信頼性を保証するための大前提として、アプリケーションをデプロイする前にテストを行うことは不可欠です。その一方、あらゆるタイプのアプリケーションがモバイル機器用に改造される傾向にあることも手伝って、デプロイする必要のあるアプリケーションの数は増え続けています。そのため、こうしたアプリケーションに対して有効なテストを行うことが、デプロイメントを遅らせることにつながる可能性があります。そこで出番となるのが、自動クラウド・アプリケーション・テストです。

この記事では、クラウドでの自動テストにグリッド・コンピューティングおよびピア・ツー・ピア・コラボレーションを統合することによってもたらされる効果を紹介します。また、グリッド・コンピューティングとピア・ツー・ピア・コラボレーションのそれぞれについて、クラウド・コンピューティングに適用する際に重要となる概念、そしてクラウドでの自動テストに統合する上での考慮事項を説明し、最後に実際のシナリオとソフトウェアの例を紹介します。

本題に入る前に、まずはグリッド・コンピューティングおよびピア・ツー・ピア機能についての基本的な背景を説明しておきます。

グリッド・コンピューティングの定義

「グリッド・コンピューティング」の概念が初めて評判になった頃のことは、誰もが覚えているでしょう。それは、2000年になってまだ何年もたたない頃のことで、SETI@home やヒトゲノム計画などのプロジェクトが複雑な問題に取り組むために、数千台のコンピューターの力を駆使していました。グリッド・コンピューティングとは、複数の管理ドメインのリソースを結集して共通のゴールを達成することを意味します。つまりグリッドは、それぞれのワークロードが相互作用することなく、多数のファイルが関与する分散システムであると考えられます。

クラスターと比べ、グリッドはより緩やかに結合された異種混合環境であり、物理的に分散される傾向があります。グリッドは LAN 上に構成することもできます。事実、プライベート・クラウドは実際には一種の仮想プライベート・グリッドです。


コラボレーティブ・ピア・ツー・ピアの定義

グリッド・コンピューティングと時を同じくして、ピア・ツー・ピア (P2P、Peer-to-Peer) というもう 1 つの概念も登場しました。P2P は短命に終わった Napster プロジェクトによって不朽の名声を与えられ、のちに Skype がそのコラボレーティブ P2P モデルによって再び大きな成功をもたらしました。P2P とは、ピア間でタスクまたはワークロードを分割する分散アプリケーション・アーキテクチャーのことです (アプリケーションに参加するピアには、それぞれ平等に特権が与えられます)。

ピアの集合が形作るのは、ノードで構成された P2P ネットワークです。ピアはそのリソース (処理能力、ディスク・ストレージ、ネットワーク帯域幅など) の一部を他のネットワーク参加者が直接使用できるようにするので、サーバーや特定のホストが中心となって調整する必要がありせん。ピアはリソースを提供する側になることも、利用する側になることもあります (クライアント・サーバー・モデルでは、サーバーだけがリソースを提供し、クライアントはそれを利用するだけです)。

P2P システムは多くの場合、アプリケーション層に構築された概念上のオーバーレイ・ネットワークとしてネイティブ・ネットワークまたは物理ネットワークの上に実装されます。これらのオーバーレイをピアの検出や索引付けに使用することによって、P2P システムをネットワーク・トポロジーから独立したものにすることができます。P2P オーバーレイ・ネットワークでは、参加するすべてのピアがネットワーク・ノードとしてその構成要素となります。

P2P ネットワークでは、ノードのリソースおよび需要がシステム全体で共有されるため、参加するノードが多くなればなるほど、システム全体での需要への対応能力が大きくなります。さらに、P2P ネットワークは分散型であることから、単一障害点がありません。したがって、より堅牢なネットワークとなります。


クラウド・テスト環境への 2 つの概念の統合

グリッド・コンピューティングの概念とコラボレーティブ P2P の概念を併せてクラウド・テスト環境に統合するとしたら、どうなるでしょうか。

  • グリッドの機能を追加することで、クラウド上で自動テスト実行グリッドを起動できるようになります。クラウド上の自動テスト実行グリッドは、ある 1 つのテストを短時間で実行できるとしたら、そのテストのインスタンスが複数になっても同じ時間内で実行することができます。ヒトゲノム・プロジェクトのような大規模な問題が多数のコンピューターの間で分割して実行されるのと同じように、どのようなデータ駆動型機能テストでも並行して実行することができます。それは、どの機能テスト・ツールを使用しているかには依存しません。
  • P2P の機能を追加した場合には、リンクを渡すだけで、いくらでも必要なだけの協力ノードがブラウザー・セッションを介してテスト実行グリッドを共有することができます。したがって、組み込みチャット・ウィンドウですべてのオンライン参加者を詳述することが可能になると同時に、適切なアクセス権を持つ参加者がそれぞれ独自のテストを実行できるようになります (ここで話題にしているのは、手動によるテストではなく、自動テスト実行システムなので、参加者が実行中インスタンスとの直接リモート・デスクトップ・プロトコル (RDP) セッションを確立しなければならないことはめったにありません)。

ここからは、この 2 つの機能とクラウド環境との統合に話題を移し、それぞれの機能を統合する上で考慮しなければならない詳細について説明します。その後、この統合への取り組みによって実現した実際のソフトウェアを紹介します。

グリッドの機能を統合する

グリッド・コンピューティングを比類のないものにしている特徴は、1 つの大きなタスクを、並行して実行可能な多数の小さなタスクに分割できることです。典型的な例として、SETI@home プロジェクトでこの 1 つの大きなタスクに相当するのは、深宇宙からの無線信号を分析して、地球外文明の存在を示すパターンを識別することでした。有名なグリッド・コンピューティングの例には、ヒトゲノムの配列の決定や、100 万桁の円周率の計算などもあります。

グリッド・コンピューティング・アーキテクチャーに必要なコンポーネントには、グリッド自体の他、タスクを配布して結果を収集するための中央サーバーまたはサーバー・クラスターがあります。サーバー・コンポーネントの設計とアーキテクチャーは、実行するタスクによって異なり、ノード・コンピューターとの間でデータを送受信するだけのサーバーや、複雑な制御および同期化アクティビティーを行うサーバー、あるいは単純なタスクと複雑なタスクの両方に対処するサーバーもあります。したがって、グリッド自体のサイズ、そしてタスクの複雑さはいずれも、主にコマンドと制御サーバーによって決まります。

約 10 年前、私は Capacity Calibration というグリッド・コンピューティング・プロジェクトを開発しました。このプロジェクトでは、世界中の人々がエージェント・プログラムをダウンロードして、各人のコンピューターを Web サイトの容量とパフォーマンスのテストに使用することができます。注目に値する 1 つの例は、スペース・シャトル打ち上げの動画を配信するための NASA の Web サイトのテストです。NASA がこのサイトを実用に移す前に、世界中の 1,500 を超えるエージェントが 1 秒あたり何千件ものアクセスをシミュレートしてサービス・レベルを検証しました。

Capacity Calibration (CapCal) は、グリッド自体をオンデマンドで起動および停止できるように、クラウドにマイグレーションされています。このプロジェクトで必要とされる制御や同期化は相当な量であり、しかも大量のデータが転送されることから、クラウドへマイグレーションすることで大きな違いがもたらされます。特に、Web 上のランダム・エージェントのネットワーク接続性および可用性が変化することは、大規模な負荷テストの調整および制御を余計に困難にしますが、IBM Smart Cloud Enterprise では、これと同じことを、綿密かつ正確なメトリクスを使用した、可用性 99.99 パーセントの複数のデータ・センターで行うことができます。

私が現在取り組んでいるプロジェクト、Cloud Lab Grid Automation (この記事で追って説明します) でも、上述のプロジェクトと同じような問題を抱え、その問題に対処するために同じような対処方法を採っています。つまり、多数の仮想マシンの力を利用して、その力を共通のタスク (このプロジェクトの場合は機能テストの自動化) に適用するために、Cloud Lab サーバーが必要に応じて新しいインスタンスを即時に起動して仮想ラボに追加し、必要がなくなった時点でそれらのインスタンスを停止できるようにする必要がありました。

これらのインスタンスのそれぞれが本格的なデスクトップ Windows 環境であれば、当然、あらゆる類の興味深い可能性が浮上してきます。例えば、Java Swing または .NET で作成されたシック・クライアントを使用したレガシー・クライアント・サーバー・アプリケーションのパフォーマンスをテストする場合を考えてみてください。1 台のマシンで複数のクライアントをシミュレーションする方法はないため、周知のとおり、このようなアプリケーションのパフォーマンスをテストするのは困難です。しかし、IBM SmartCloud Enterprise を利用すれば簡単で、単純に複数のマシンを起動するだけでこの問題に対処することができます。

P2P の機能を統合する

今から 10 年近く前の、まだグリッド・コンピューティングと P2P が登場して間もない頃は、この 2 つの言葉が同じ文のなかで使われていたことが多かったため、混乱を招く結果となりました。初の代表的な P2P コンピューター、Napster を例に挙げると、その決定的な差別化の要因となったのは、Napster ではグリッド内のノード (ユーザー) 同士が直接データ (音楽) を交換できるという点です。このパラダイムは暫くの間は大成功を収めたものの、著作権侵害の問題が持ち上がってきたことから長続きしませんでした。合法かつ非常に広く使用されている P2P アプリケーションの最近の例は、Skype です。

Cloud Lab Grid Automation システムでは、グリッド内の各仮想マシンを特定のユーザーに割り当てたり、ユーザーのグループで共有したりできるようにする必要がありました。この機能を管理者が制御するには、ブラウザー・コンソール自体にリンクを送信するという方法や、RDP を介して個別のマシンだけにリンクを送信する方法など、さまざまな方法で制御できる必要がありました。最近ではテストおよび開発チームが地理的に分散していることが通例なので、人手を介さない自動テストでも、手動テストでも、このようにコンピューティング・リソースを共有できることが非常に有益です。

例えば、管理者は 1 人ないし 2 人のユーザーにテスト・リーダーの役割を割り当てることによって、これらのユーザーにグリッドのブラウザー・コンソールへのリンクを渡します。このレベルのアクセス権を持つユーザーは、すべてのマシンを表示し、マシンの間でファイルをコピーしたり、テストを開始、停止したりすることができます。仮想マシンは、物理的なテスト・ラボにある通常のコンピューターとまったく同じように、個人が勤務時間中に使用することも、勤務時間外に夜通し行われるリグレッション・テストに割り当てることもできます。

私のチームでは、ブラウザー・コンソールにチャット・ウィンドウを組み込むことにしました。チーム・メンバーは、個々のマシンを制御する場合も、マシンの集合を使用して以下に説明するようなタスクを行う場合もあります。そこで、この組み込みチャット・ウィンドウを使用して、管理者とこれらのチーム・メンバーとの間の基本的なコラボレーションをサポートするというわけです。ユーザーは電話会議ブリッジまたは Skype チャットを追加するだけで、物理的なテスト・ラボそのものを除けば、テスト・ラボで使用するようなリソースをすべて使用できるようになります。


典型的なシナリオ

テスト自動化ツールがとりわけ役に立つのは、テストのため、あるいはシステム間でデータを変換するために、データベースにデータを取り込む場合です。クエリーを作成してデータを取り込む代わりに、テスト自動化ツールを使用してデータを取り込む利点は、UI を介してビジネス・ルールが適用されるため、データの保全性が確実になるところにあります。数百件または数千件にものぼるレコードを入力するのは、いずれにしても相当な時間がかかります。これがまさに、グリッド・コンピューターによって大幅に時間を短縮できるシナリオです。

この記事で、次に例として引用する実際のシステムでは、.NET Pet Shop アプリケーション (「参考文献」を参照) を使用しています。例えば、ASCII カンマ区切り形式のテキスト・ファイルから 10,000 人の新規ユーザーをデータベースに取り込み、各行にユーザー ID、E メール・アドレス、苗字と名前、電話番号、メーリング・アドレスを含めるとします。単一のワークステーションがリストをすべて取り込むには約 3 時間 20 分かかりますが、たった 12 のクラウド・インスタンスからなるグリッドを使えば、所要時間を 15 分にまで短縮することができます。


Cloud Lab Grid Automation の紹介

Grid Robotics の Cloud Lab Grid Automation

クラウド・コンピューティングは、実質的に無制限のリソースをオンデマンドで集めることができる環境を実現しています。こうした環境を実現することは、テストの自動化には不可欠です。このクラウドが持つ力のすべてを駆使して自動テストを処理するのが、Cloud Lab Grid Automation です。Cloud Lab Grid Automation サーバーは稼動する場所を選びません。パブリック・クラウド内でも、プライベート・クラウド内でも稼動します。あるいは単にラボやデータ・センター内のサーバーとして機能することもあります。そして、その場所から任意の数のクライアント・コンピューターまたはエージェント・コンピューターを管理し、これらのコンピューターが AWS、IBM、または Rackspace などのパブリック・クラウド、あるいは VMware や Citrix などのプライベート・クラウドで自動的に起動できるようにします。どのように構成されているかに関わらず、Cloud Lab サーバーは分散コンピューティングの本領を発揮します。このサーバーにとって、物理マシン、仮想マシン、そしてクラウド・マシンの区別はまったくありません。

この記事で紹介する実際のソフトウェアの例は、Grid Robotics の Cloud Lab Grid Automation ソリューションです。このシステムでは、グリッド・コンピューティングの概念とコラボレーティブ P2P の概念の両方がクラウドに生かされています。

Cloud Lab の概要

クラウドで稼動する Cloud Lab サーバーは、任意の数の Cloud Lab Appliance をサポートすることができます。Cloud Lab Appliance とは、パブリック・クラウド、プライベート・クラウド、仮想マシン、あるいは物理マシンで稼動する、Windows または Linux 仮想マシン・インスタンスのことです。Cloud Lab Appliance は、既存のマシンに Cloud Lab エージェントをインストールするか、あるいはパブリック・クラウドの標準 Cloud Lab エージェント・マシン・インスタンスを構成することによって作成することができます。

パブリック・クラウドとプライベート・クラウドの出現により、実質的に無制限のリソースをオンデマンドで集めることができる環境が実現されています。テスト自動化にとって、クラウド以上に重要な意味を持つ環境はありません。特に、サポートされる環境および構成をベースに、最も一般的であると考えられるブラウザーとそのさまざまなバージョンを使用して行われるリグレッション・テストでは、なおさらクラウドが重要です。

Cloud Lab Grid Automation サーバーは稼動する場所を選びません。パブリック・クラウド内でも、プライベート・クラウド内でも稼動します。あるいは単にラボやデータ・センター内のサーバーとして機能することもあります。そして、その場所から任意の数のクライアント・コンピューターまたはエージェント・コンピューターを管理し、これらのコンピューターが AWS、IBM、または Rackspace などのパブリック・クラウド、あるいは VMware や Citrix などのプライベート・クラウドで自動的に起動できるようにします。どのように構成されているかに関わらず、Cloud Lab サーバーは分散コンピューティングの本領を発揮します。このサーバーにとって、物理マシン、仮想マシン、そしてクラウド・マシンの区別はまったくありません。

標準 Cloud Lab エージェントには、5 つの主要なブラウザー (Internet Explorer、Firefox、Chrome、Safari、および Opera) と併せて優れたオープンソースの Web テスト・ソリューションである Selenium (「参考文献」を参照) がすでにインストールされています。つまり、「そのままの状態」ですぐに、Selenium テストをこの 5 つの主要なブラウザーに対して並行して実行できるので、通常のリグレッション・テスト・サイクルにかかる時間を (数日分とは言わないまでも) 何時間も節約することができます。その一方、Selenium 以外の機能テスト・ツールのライセンスを持っている場合には、Cloud Lab エージェントにそのツールをインストールして (または自分のマシンにCloud Lab エージェント・ソフトウェアをインストールして)、同じようにテストすることもできます。

複数の環境で同じリグレッション・テストを実行する場合でも、あるいは同じ環境で異なるデータを使用してテストする場合でも、Cloud Lab Grid Automation はテストを「スーパーチャージ」して、グリッド・コンピューティングとクラウドの統合によってもたらされるメリットを実現し、最大の生産性を達成する手段となります。Cloud Lab Grid Automation は、IBM および Amazon のクラウドで使用することができます。

Cloud Lab Grid Automation の基本操作手順

クラウドでの自動テストを容易にするために、Cloud Lab Grid Automation ではグリッドとコラボレーティブ P2P の機能および操作を簡単に使用できるようになっています (このプロセスのデモ・ビデオが用意されています)。

ステップ 1: クラウドでグリッドを起動する

  1. www.cloudlabsetup.com の Cloud Lab セットアップ・ページにアクセスします。Cloud Lab を初めて使用する場合には、14 日の試用期間に登録する必要があります。
    図 1. Cloud Lab の試用を登録する
    Cloud Lab の試用を登録する

    このデモでは、デフォルトの Cloud Lab Agent にプリインストールされているオープンソースの Selenium Web テスト・ソリューションを使用します (デフォルトのエージェントに任意の機能テスト・ツールをインストールして、カスタマイズするのでも構いません)。

  2. 例として、12 のデフォルト・エージェントを指定して、グリッドが起動中になったことを通知する E メールが到着するのを待ちます。
    図 2. グリッドが起動するまで待機する
    グリッドが起動するまで待機する

    起動するまでに数分かかることもあるので、コーヒーのお代わりを入れに行くには今がチャンスです。

  3. E メールが到着したら、リンクをクリックします。すると、コマンドの入力を待機している状態の Cloud Lab テスト実行グリッドが表示されます。
    図 3. 作動可能状態のテスト実行グリッド
    作動可能状態のテスト実行グリッド
    図 4. テスト実行グリッドの拡大図
    テスト実行グリッドの拡大図

コラボレーションが関係してくるため、事前に共同作業する同僚を手配しておいてください。環境を共有するには、参加する他のユーザーを招待します。これが、「コラボレーティブ P2P」の側面です。チームの誰もが参加できるようにするには、組み込みチャット・ウィンドウや電話会議ブリッジを使用します。

ステップ 2: テストをアップロードして実行する

テストを開始するために必要な作業は、以下の 3 つだけです。

  1. Upload Local File コマンドを使用して、テスト自体をすべてのインスタンスにアップロードします。複数のファイルやフォルダーをアップロードする場合は、あらかじめ zip で圧縮しておく必要があります。残りの処理は、Cloud Lab が自動的に行ってくれます。
  2. Dispense File コマンドを使用して、テスト・データ・ファイルをインスタンスに均等に配布します。
  3. Execute OS コマンドを使用してテストを開始します。

これだけの作業で、テストを開始することができます。

ステップ 3: 結果をダウンロードする

15 分ほど経つと、10,000 件の新規レコードがすべてデータベースに追加されているはずです。今度はグリッドのシャットダウンを行いますが、ログにエラーが記録されたインスタンスが 1 つでもある場合には、グリッドをシャットダウンする前にテスト結果をダウンロードすることが重要です。そうしないと、テスト結果が失われてしまいます。

図 5. 結果をダウンロードする
結果をダウンロードする

テスト結果をダウンロードするには、Download Agent Files コマンドを使用します。テスト結果が保存されているフォルダーの名前を入力すると、Cloud Lab サーバーがテスト結果を 1 つの ZIP ファイルにまとめて、そのファイルのダウンロード・リンクを記載した E メールを送信します。


まとめ

クラウド・コンピューティングは、多くの点でソフトウェア・テストの自動化に大変革をもたらします。事前に構成された任意の数のテスト・マシンをどこからともなく起動し、そのそれぞれを単独で、あるいは並行して使用できれば、テストに関するあらゆる問題の処理にグリッド・コンピューティングの威力を活かすことができます。また、チームのメンバーが世界のどこにいようと、どのメンバーとも共同で作業できるということは、従来のテスト・ラボの利点をもたらしながらも、テスト・ラボ環境の物理マシンの制限を取り除くことになります。

この記事では、グリッド・コンピューティングとコラボレーティブ P2P の機能を統合することで、クラウド・ベースのテストを容易に自動化できる仕組みを説明しました。自動クラウド・テストについては、皆さんが独自に探ってみてください。

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmartCloud Enterprise に用意された製品イメージを調べてください。
  • PetShop .NET Sample Application は、.NET Web アプリケーションを構築するためのエンタープライズ・アーキテクチャーの実例を示し、エンタープライズ・アプリケーションの構造をそのアーキテクチャー、プログラミング・モデル、生産性、パフォーマンス、拡張性、および信頼性を検討することによって明らかにします。
  • Amazon EC2 クラウドで使用できる IBM 製品イメージを調べてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=765661
ArticleTitle=クラウドでのテスト自動化を助長するグリッドおよび P2P
publish-date=10212011