このセクションでは、Parasoft Virtualize、Parasoft Data Repository、および Parasoft Continuous Testing Platform (CTP) を運用レベルでデプロイする上で、Parasoft が推奨する事項について説明します。このセクションの内容:

前提条件

デプロイメントには以下が含まれると仮定します。

  • Virtualize サーバー (war ファイルでデプロイされることが望ましい)
  • Parasoft Data Repository サーバー
  • Parasoft CTP およびサポートされるデータベース ( 詳細については「Selecting a CTP Database」を参照)

デプロイメントの方法

デプロイメントには 2 種類の方法があります。動的インフラストラクチャ (Docker イメージまたはAzure VM) または物理的な静的インフラストラクチャです。

動的インフラストラクチャは、動的な使い捨てのテスト環境を実現することを目的とします。つまり、基準となるテンプレートからただちにテスト環境をセットアップし、環境を使用して変更した後、環境を破棄することができます。複数のチームやテスト フェーズでテスト環境やリソースを共有する必要はありません。いつでも必要なときに、まさに必要な環境をただちにセットアップし、使い終わったら破棄します。動的なインフラストラクチャは、高い水準の自動化を可能にする高度な柔軟性を提供します。さらに、規模を拡大する必要がある場合 (たとえばパフォーマンス テストなど) も、必要に応じて実現できます。 

物理的な静的インフラストラクチャでは、恒久的な (専用の) サーバーがあります。この方法は、長期間のスケーリングが予想され、多用される前にハードウェアが指定される場合に役立ちます。この方法は、高い可用性とフォールト トレランスの要求に対応するために選択されます。このような要件があり、ロード バランサーの背後に Parasoft Virtualize サーバーのクラスターを構成する計画である場合、「ロード バランサーの背後での Virtualize サーバー クラスタのセットアップ」も確認してください。

動的インフラストラクチャの推奨事項

動的インフラストラクチャは、Docker イメージまたは Microsoft Azure VM を使用します。
Dockerでは、以下を推奨します。

  • イメージごとに、1 つの Tomcat と CTP、Virtualize サービス (war ファイルのデプロイ)、および Data Repository サーバーが必要です。
  • 最小のマシンスペックは 4 コアの 16 GB RAM ですが、推奨するスペックは 8 コアの 32 GB RAM です。
  • 同じホスト OS 上で 2-4 以上のイメージを使用することは推奨しません。なぜなら、イメージがリソースを ( 特にネットワーク リソースを) 奪い合うからです。同一ホスト マシンに4 以上のイメージを置くと、問題があった場合に原因を突き止めるのが難しくなります。

Azure の場合、以下を推奨します。

  • DS2_V2 以上のサイズの仮想マシン
  • Parasoft Service Virtualization 用の Azure 仮想マシン (オンデマンドまたは BYOL)

AWS では、以下を推奨します。

  • t2.medium 以上のサイズの仮想マシン

物理的な静的インフラストラクチャの推奨事項

以下の図は、3 個の Virtualize サーバーと CTP のデプロイメントのために推奨するアーキテクチャを示します。なお、右下の "Server n" アイコンは、ユーザー環境に適した、任意の数の追加サーバーを表します。 
 

デスクトップ ユーザーは、ローカルのデスクトップ サーバーを使用してアセットを開発し、Virtualize Staging Server に接続してサーバー環境でアセットをテストする必要があります。ステージング サーバー上のイベントを監視してアセットをデバッグできます。仮想アセットの準備ができたら、ソース管理 (SCM) システムに変更をチェックインできます。

本番サーバーまたはパフォーマンスサーバー上のアセットは、SCM を通じて更新する必要があります。これにより、これらのサーバー上で実行されているアセットの動作とパフォーマンスが仮想アセットの開発によって影響を受けないようにし、本番サーバーとパフォーマンス サーバを安定した状態に保つことができます。パフォーマンス サーバーは、「Virtualize サーバーのパフォーマンス チューニング」で概説されている原則に基づいて構成する必要があります。SCM からのアセットの更新は、現在のニーズに最適なものに基づいて、スケジュールまたはオンデマンドで実行できます。 たとえば、Kubernetes でのデプロイでは initContainer を使用して SCM からプルする一方、物理サーバーを使用するデプロイではオートメーション サーバーからオンデマンドで実行されるジョブがあるかもしれません。

ステージングと本番の両方に 1 つのサーバーを使用することには、固有のリスクが伴います。可能ではありますが、いくつかの理由から推奨できません。たとえば、テストがサーバーを使用している間にデスクトップ ユーザーがアセットを再デプロイして障害を引き起こしたり、負荷テスト中にアセットを監視してスループットの低下を引き起こしたりすることがあります。ステージング環境と本番環境を分離しないと、デスクトップ ユーザーによるアセットの開発が自動テストや負荷テストに悪影響を及ぼす可能性があります。

Virtualize サーバーと Data Repository サーバー間のネットワーク待ち時間を、可能な限り最小限に抑えることを推奨します。 プロセス間のネットワーク遅延は、負荷時の Virtualize サーバーのパフォーマンスに悪影響を与えます。ユーザーがこれを達成する最も一般的な方法は、同じマシン、または可能な限り同じ場所 (同じデータセンター領域など) に配置された 2 台のマシンにインストールすることです。Data Repository サーバーは大量のメモリを消費するので、Virtualize サーバーと同じマシンにインストールする場合は、32 GB 以上の RAM を搭載したマシンを推奨します。

Virtualize、Data Repository、および CTP サーバーマシンについて、以下のハードウェアを推奨します。

Virtualize

  • CPU: 8 コア
  • RAM: 32 GB 以上
  • 必要なディスク容量: 300 GB 以上

Data Repository

  • CPU: 4 コア
  • RAM: 32 GB 以上
  • 必要なディスク容量: 300 GB 以上

CTP

  • CPU: 4 コア
  • RAM: 8 GB
  • 必要なディスク容量: 150 GB

注意

  • CTP 用のデータベースは複数のチームの成果物をバイナリとしてホストする場合があるため、かなり規模が大きくなります。
  • Virtualize サーバーでは、通常、ワークスペースが最もストレージの割り当てを占有します。すべての成果物およびデータ (データのスナップショットを含む) は、ソース管理システムにチェックインされる前に、ここに格納されます。
  • Virtualize サーバーでは、最適なパフォーマンスを実現するために、強力な馬力が必要です。
  • Virtualize サーバーおよび Data Repository サーバーマシンでは、RAM の量を増やすと、特に Data Repository のメモリ マッピングのパフォーマンスが向上します。
  • Data Repository サーバーのストレージ要件を満たすことが重要です。同じサービスの複数バージョンのデータやデータベース データを格納し、複数のチーム、複数の環境から使用できます。

オペレーティング システム

以下の理由により、Parasoft のデプロイメントには、Windows よりも Linux を推奨します。

  • 管理タスク (起動、再起動、ログ記録、デバッグなど) が容易。「バックグラウンドで」サービスとしてアプリケーションを実行する場合、Linux では nohup/ init.d/cron を使用できる。Windows には同等に容易なソリューションがありません。
  • パーミッションの管理が容易。管理グループだけがファイル (起動スクリプト、server.xml など) を参照/ 変更できるよう、サービス アカウントを作成できます。
  • パフォーマンスが優れている。Windows では、コア OS がパフォーマンスのかなりの部分を消費します。Linux では、マシンを骨組みだけにして Virtualize を専用のスペースで実行することができます。
  • ssh や scp などのツールのおかげで、自動化作業が容易。Parasoft は Linux でこれらのタスクを実行するためのパッケージやスクリプトを提供しています。

CTP データベースの選択 

CTP は Oracle、HyperSQL、MySQL をサポートしていますが、MySQL ではなく Oracle または HyperSQL を使用することを強く推奨します。推奨する順序は次のとおりです。 

Oracle >= HyperSQL > MySQL

Oracle および HSQLDB は同等ですが、MySQL ではトラブルシューティングが困難です。CTP データベースをクラスタリングする予定がなく、十分なスペースがある場合は、HyperSQL を推奨します。 

クラウドベースの動的インフラストラクチャのデプロイメントを開始する

Microsoft Azure や Amazon AWS などのクラウド サービス プロバイダーの提供するクラウド上に VM をデプロイする場合、VM をシャットダウンし、再起動するたびにマシン ID が変わる可能性があります。Prasoft 製品を起動するとき、次のフラグを使用すると、クラウド プラットフォームで VM を再起動したときもマシン ID が変わらないようにできます。

-Dparasoft.cloudvm=true
  • No labels

Need assistance? Visit our support page