機械制御/振動騒音
IR情報 会社情報

Polarionのパフォーマンスと拡張可能性について

Polarion のパフォーマンスとスケーラビリティについて -- 2013著者: Nick Entin

この記事では、Polarion プラットフォームのパフォーマンスに重大な影響を与える要素、スケーラビリティの限界および潜在的な危険性、運用環境における適切な能力計画を立案するための推奨事項について、Polarion Software社のインストール・ベースの代表的なシナリオに基づき解説を行います。

システム構成の全体像

Polarion はWebベースのアプリケーションです。クライアント・インターフェースをサポート対象のブラウザ上で操作するため、結果的にPolarion へのアクセスは、LAN、WAN(例: 社内ネットワークなど)、インターネットまたは VPN を経由して行われます。

Polarion の基本的なシステム・アーキテクチャの図 Polarion の基本的なシステム・アーキテクチャ

アプリケーション・アーキテクチャ

Polarion は、多くのオープンソース・フレームワークとAPI を利用して構築されています。これらすべてのコンポーネントは、それぞれに固有のパフォーマンスとスケーラビリティを有しますが、その中でもPolarion のパフォーマンスとスケーラビリティに影響を与えるのは、Polarion のプラットフォームにおいて特定の使われ方をしている少数のコンポーネントのみになります(Polarionで利用されているコンポーネントの中には、大規模な環境、または、過度のストレスが存在する環境でなければ利用されないものさえ存在します)。

Polarion のアプリケーション・アーキテクチャの図 Polarion のアプリケーション・アーキテクチャ

主要なレイヤ

主要なレイヤの図 主要なレイヤ

プラットフォーム・コンポーネント

Apache HTTP Server

Apache は、Windows プラットフォーム上で稼働するIIS に対抗できる事実上唯一の Web サーバ・ソリューションであり、その堅牢さ故に、インターネット上で最大規模の複数のWeb サイトで採用されています。

パフォーマンスとスケーラビリティ

Polarion のパフォーマンスに影響を及ぼす Apache の既知の問題は存在しません。

推奨事項

Polarion のインストール手順を実行することで、Apache のインストールおよび構成も自動的に行われます。不必要なパフォーマンスの低下、あるいは、システムのダウンタイムを避けるために、特別な理由が存在する場合以外は Apache の構成を変更しないでください。また、特別な理由が存在する場合でも、Polarion のサポート・チームによるコンサルティングを受けてから構成を変更するようにしてください。

Polarion は、特定のユーザがドキュメントまたはワークアイテムに対する読み取りおよび書き込みアクセスを保持しているかどうかを判断するために、Subversion のフォルダ権限を読み込みます。また、access ファイルが複雑になるほど、Polarion がaccess ファイルを処理するために要する時間とメモリは増加します。そのため、ソース・コードに対する権限を処理する際に、access ファイルが非常に複雑な場合(ルールが数千個に及ぶような場合)かつ、Polarionとの関連性が薄い場合に、Polarion による access ファイルの解析を無効化することもできます。

Subversion (SVN)

2004年の登場以来、Subversion は瞬く間に、トップ・シェアを誇るバージョン管理ソリューションへと成長しました。現在では、世界中の様々な規模の組織において、Subversion が使用されています。Polarion もその例外ではなく、ほぼすべての構成とデータを Subversion を使って管理しています(ただし、トレンドおよびレポートに関するデータとログ・ファイルの管理には、Subversion を使用していません)。

パフォーマンスとスケーラビリティ

Subversion の強みの1つは、同時に、Subversion のパフォーマンスにおけるボトルネックでもあります(Subversion は、規模の大きい変更セットをリポジトリへアップロードすることができますが、それによりネットワーク・トラフィックが大量に消費され、リクエストが多い場合には、データが待ち行列に登録されます)。

しかしながら、Polarion の変更セットがキロバイトの範囲を超えることはほとんどなく、Polarion の変更セットの大きさが、 Subversion のアップロード性能に影響を及ぼすことはありません。

Subversion は、遅延を伴わずにネットワークを運用できるリポジトリ・サイズの上限に関して、具体的な証拠を示していません。なお、Apacheソフトウェア財団は、運営しているすべてのプロジェクト(Subversion および Apache Web サーバ プロジェクトを含む)の管理に単一のリポジトリを使用していますが、そのリビジョンのサイズは優に1300K を超えています(2012年6月現在 http://svn.apache.org/repos/asf/ を参照のこと)。

Subversion v1.7.x

Apache は、2011年10月に、Subversion 1.7 をリリースしました。このバージョンでは、ワーキング・コピーの形式変更および、よりシンプルなHTTP プロトコル(一部では、HTTPv2 として言及されています)の採用により、パフォーマンスが大幅に向上しています。

Polarion ではワーキング・コピーを使用していません。また、SVNとの間の接続も常時確立されているため、Subversionに実装された上述の改善点の影響はそれほど大きくありません(テストで確認されたパフォーマンスの改善は、1-5%に留まりました)。しかしながら、Polarion のSVN リポジトリをソース・コードをホストするために使用しており、かつ、開発者がそのリポジトリへ頻繁にアクセスするような場合は、SVN 1.7.x を使用するとよいでしょう。なお、現在では、SVN 1.7.x が Polarion に同梱されています。

外部リポジトリ - SVN と Git

Polarion 2012 では、単一の Polarion プロジェクトに対して、複数のソース・コード・リポジトリを作成できます(サポート対象のシステムでは、Subversion または Git の使用が推奨されています)。これらのリポジトリでは、新しいリビジョン(トレーサビリティを担保するために、関連するワークアイテムとリンクされるべきリビジョン)が検索され、リンクの存在が認識された場合には、対応するコミットを外部の SVN または Git ブラウザを利用して表示することができます。Polarion とこれらのリポジトリとの間の接続状況は、必ずしも良好である必要はなく、通信速度が遅い、または接続の信頼性が劣る場合でも、これらのリポジトリおよび関連する機能を利用することができます(接続状況が良好でない場合には、リンク済みリビジョンが Polarion の UI に表示されるまで、接続状況が良好な場合に比べて比較的長い時間を要しますが、データが失われることはありません)。

推奨事項

SVNのパフォーマンスを最適化するために重要なのは、様々なコミットフック(主に操作時のパフォーマンス向上を目的として、 Subversion リポジトリに設定されます)で行われる処理の総数を制限することです。実行可能な場合はいつでも、コミットフックをコミットのプロセス外で実行するために、すべての重要な自動化を実装するとよいでしょう。

Subversion は、ファイル・システムへアクセスする際に、超高速アクセスを要求します。そのため、物理的に接続されるストレージ以外は絶対に使用しないでください。(具体的に言えば、Polarion と同じサーバ、あるいはそれと同等の超高速アクセスを提供する NAS ソリューション上にSVN リポジトリが構築された場合のみ、Subversionのパフォーマンスが最適化されます)。

Polarion と SVN は、容量が小さいファイルを数多く使用するため、ディスク・サブシステムのパフォーマンスが重要な意味を持ちます。また、オペレーティング・システムはファイル・システムのキャッシュを利用するため、ファイルの操作に関するOS のキャッシュを保存するために、RAM上に十分な空き領域を確保する必要があります。サーバ上に 8GB以上の RAM を確保でき、かつ、規模の大きいプロジェクトを運用する場合の目安としては、サーバ RAM の半分を Polarion 用に、残りの半分をOS のキャッシュの保存先として割り当てるとよいでしょう。

Apache Lucene

Polarion は、すべての XML データ と構成を Subversionに保存します。そのため、データベースのバックエンドが存在しない場合と、検索条件を実行したうえで、結果の取得およびフィルタリングを即座に実行できる場合のギャップを埋める必要があります。Apache Lucene は、インデックスを作成するための強力なフレームワークです。Polarion は、 Apache Lucene を利用することで、我々が“インデックス”と呼んでいる機能 - Polarion プラットフォームが読み込み操作を行う際に必ず使用する機能 - を実装しています。

パフォーマンスとスケーラビリティ

Lucene は、アクセス速度が早いインメモリストレージとオンディスク・オーバーフローのバランスを取ることで、大きなデータ・セットによるメモリの占有領域を制限しています。上記の制限以外に、Lucene が扱うデータに関する上限は存在しません。なお、メモリの占有領域は、同時要求の数が増加するに従い、ほぼ完全な直線を描いて増加します。

Lucene のパフォーマンスは、返却される結果の数に大きく影響を受けます。Polarion はこの影響を緩和するために、可能な場合には必ず遅延読み込みを行います。

推奨事項

検索条件との関連性が高く、かつ、より絞り込まれた検索結果を抽出するために、検索条件のスコープをより狭く設定することが推奨されます。

SQL レイヤ

Polarion 2012 では、インデックスを作成するためのメカニズムが一新され、連結検索条件や履歴検索を含む、より洗練された検索を行えるようになりました。このメカニズムは、元々 Lucene に実装されていたものであり、単純な検索条件を Lucene に対して実行する一方で、より複雑な検索条件を SQL データベースに対して実行できるというものでした。

パフォーマンスとスケーラビリティ

Polarion が採用しているSQL ストレージ(埋め込み H2 データベース)は、開発元のオープン・ソース・コミュニティによって、その優れたアクセス速度や信頼性の高さが証明されています。H2 データベースを採用した場合、メモリの占有領域は小さくなりますが、必要なストレージの容量は非常に大きくなります(Lucene が必要とする容量の5倍から10倍の容量が必要になります)。

Polarion 2012 へアップデートした後、最初に行われるリポジトリの再インデックス化では、 データベースへのデータの格納に膨大な時間がかかります(リポジトリのサイズと、リポジトリに含まれているドキュメントおよびワークアイテムのリビジョン数にもよりますが、全体で1-2日かかることもあります)。なお、このプロセスは安全に中断することができ、中断した場合は、サーバの再起動後に自動で再開されます。また、履歴インデックスが完全に格納されるまでは、ベースラインと履歴検索へのアクセスが制限される場合があります。

推奨事項

Polarion 2011以前のバージョンを対象とした、トレーサビリティ・メトリックスおよびレポートをご確認ください。SQL レイヤ は、マクロ・クエリで新たにサポートされた SQL を、Lucene クエリの代わりにワークアイテムに対して適用することで、 パフォーマンスが向上する場合があります。

LiveDoc™ ドキュメント

バージョン 2011 に導入されてから、中間成果物の管理を可能にした LiveDoc オンライン・ドキュメント(“LiveDoc ドキュメント”)は、要件管理、品質保証およびテストの分野において、大きな注目を集めています。LiveDoc ドキュメントは、粒度の細かい中間成果物(要件やテストケースなどの“ワークアイテム”。自動化されたプロセス・ワークフローにより、追跡および管理することができる)をドキュメントに含めるメカニズムと、広く使用されている Office ドキュメントの簡単な操作性を統合した機能です。

パフォーマンスとスケーラビリティ

プロジェクトにおいて、LiveDoc ドキュメントに含まれているワークアイテムは、その他のワークアイテムとは別の場所に保存されます。また、LiveDoc ドキュメントに含まれているワークアイテムにのみ課される制約ゆえに、ワークアイテムとしての扱いもその他のワークアイテムとは異なります。その結果として、5,000個未満のワークアイテムを含むLiveDoc ドキュメントは問題なくサポートされますが、LiveDoc ドキュメントに含まれているワークアイテムが5,000個以上の場合には、大幅なパフォーマンスの低下が生じる恐れがあります。

Polarion 2012 SR1 では、いくつかの既知の問題が改善されました。具体的には、サーバとクライアントのパフォーマンスが最適化されたことにより、大幅なパフォーマンスの低下を伴うことなく、1つのドキュメント対して最大で1,000個のコメントを追加できるようになりました。また、同一のドキュメントに対して、複数のユーザが同時に加えた変更をマージできるようになりました。この改善により、同一のドキュメントの複数のセクションにおいて、構造的な変更が複数のユーザにより同時に加えられた場合でも、変更箇所を上書きすることなくマージできるようになりました。

推奨事項

LiveDoc ドキュメントに含めるワークアイテムの数を、5,000個未満に限定することをお奨めします。

総合的なパフォーマンスとスケーラビリティ

このトピックに関しては、互いに関連を持ちながらも異なる2つの視点 - CPUの負荷とデータ量 - から考察する必要があります。

CPUの負荷

Polarion の総合的なパフォーマンス検証した以下のグラフからは、デュアルコア CPUを採用した Polarion システムの場合、保存操作に要する時間は、同時に操作を行うユーザ数の増加に比例して、ほぼ直線的な伸びを示していることが分かります。一方で、8コア CPUを採用した Polarion システムの場合、保存操作に要する時間は、同時に操作を行うユーザ数の増加にかかわらず、ほぼ一定の値を示しています。

CPUの負荷のグラフ

上のグラフからは、単一の Intel i7 CPU プラットフォームにおいて、100人の同時ユーザがPolarionで作業を行い、かつ、それぞれのユーザが任意のタイミングで保存操作を行った場合、実行された保存操作の80%が、4秒以内で完了していることが分かります。*ワークアイテムを5分ごとに変更する同時ユーザが100人いた場合、5人以下のユーザが同時に保存操作を実行する割合は、統計上80%であることが証明されています。

データ量

Polarion のデータ量が、本稿で既に示した設定値の範囲内に収まっている場合、データ量のスケーラビリティはメモリ(RAM)消費量によって限定され、単一のリポジトリに保存されているプロジェクト数の増加と Polarion 全体のメモリ占有領域の増加との関係を示した下図において、ほぼ直線的な伸びを示します。

データ量のグラフ

並列処理の図 並列処理

推奨事項

リポジトリに保存されているワークアイテムの総量が Polarion のパフォーマンスに与える影響は小さく、また、すべてのワークアイテムに対する検索条件が頻繁に実行されない限り、スケーラビリティに影響が及ぶこともありません。

稼働しているプロジェクトの数はメモリ消費量に大きく影響しますが、プロジェクト構成、権限、ロールおよびその他の情報は、パフォーマンスの向上を目的としてメモリに保存されます。以下に、推奨事項を列挙します。

  • 単一のインスタンス上で、500個以上のプロジェクトを稼働させない
  • リソースを解放するために、稼働していない、または、既に終了しているプロジェクトを閉じる
  • 500個以上のプロジェクトを稼働させる場合には、マルチ・インスタンス・インストレーションの実行を検討する(マルチ・インスタンス・インストレーションを実行した場合、プロジェクトを複数のインスタンスに分散して保存できます)。単一のサーバ上に複数のインスタンスをホストする手法も有効だが、単一のインスタンスがホストされた物理マシンを複数台用意する手法の方が望ましい

登録ユーザ数による影響:単一のインスタンス上に1000人を超える登録ユーザが存在する場合、ページの表示が遅くなるなど、ユーザ管理画面の操作性に影響が出る場合があります。

アクティブユーザ数による影響:処理は複数のCPUにおいて並行して行われますが、スレッドの数が利用可能なCPU の数を超えた場合には待ち行列が作成され、それに伴い応答時間も長くなります。

Polarion Software によるホスティング・サービス

Polarion 製品をご購入いただいたお客様には、Polarion Software が提供するホスティング・サービスをご利用いただけます。このサービスを利用した場合、Amazon Cloud 上において、ライセンスが自動的にインストールされます。また、ユーザのニーズに合わせてサーバの最適化が行われるほか、アップデートのインストールおよびサーバ管理に関する技術的な問題についても、Polarion が責任を持って解決します。

インストレーションの例

以下に、我々の顧客ベースから抽出したインストレーションの例を示します。Polarion のスケーラビリティを計画する際に、参考としてご参照ください。

顧客 “A”

  • ワークアイテム: 1万5千個
  • プロジェクト: 12個
  • ユーザ: 60人

顧客 “B”

  • ワークアイテム: 30万個
  • プロジェクト: 145個
  • ユーザ: 1,030人

顧客 “C”

  • ワークアイテム: 15万個
  • プロジェクト: 600個
  • ユーザ: 140人

外的要因と推奨事項

クライアント

Polarion は、他のリッチ Web ベース・アプリケーションと同様に、ブラウザに表示された動的コンテンツのキャッシュを保存します。その結果、ブラウザの処理に伴い生じるメモリの消費量が、時間とともに増加していきます。この問題を防ぐために、Polarion を使用した後にはブラウザを閉じるとよいでしょう。この問題は、より適切なメモリ管理を行っている Firefox や Chrome よりも、Internet Explorer において発生しやすい問題だと言えます。

要求の処理の図 要求の処理

ファイル・システム

Polarion の処理は、ディスク操作に依存する傾向があります(特に、ファイル・システムに対してシリアル化されるインデックスの増加をサーバが計量化する場合に、その傾向は顕著になります)。

どのようなオペレーティング・システムでも、インデックスを行う際のパフォーマンスは、ディスクの断片化による影響を敏感に受けます。ほとんどの Linux ディストリビューションでは、断片化を完全に防止する機能を持つ ext3 ファイル・システムを使用するためのオプションが提供されますが、その他のケースでは、定期的な最適化の実行が強く推奨されます。

Subversion を使用する場合、ローカル・ファイル・システム(または、それと同等のリポジトリへのアクセス速度を持つファイル・システム)が必要になります。そのため、内蔵ドライブまたは接続ストレージ(光ファイバー接続されるもの)の使用が強く推奨されます。ネットワーク接続ストレージ(NAS)を使用しなければならない場合は、サーバとストレージ間におけるネットワーク・パスの長さ、速度および安定性が極めて重要になります。

ソリッドステートドライブ(SSD)を使用する場合は、使用するドライブの種類について、十分に検討を行ってください。比較的安価なデバイスでは、時間の経過と共に、保存操作を行う際のパフォーマンスが低下する傾向にあります。Polarion と Subversion は、ディスクへの細かい書き込みを頻繁に行うため、性能が証明されている SSD のみを使用してください。

ウイルス・スキャン

リアルタイムで実行されるウイルス・スキャンは、ファイル・システムのパフォーマンスを著しく低下させる場合があります。Subversion リポジトリのファイル・ストラクチャとディスク上のすべての Polarion に関するデータ (c:\polarion\data or /opt/polarion/data in default install) をリアルタイムで実行されるウイルス・スキャンの対象から除外し、必要なウイルス・スキャンを夜間または作業時間外に実行してください。

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

Windows は、ほぼすべての機能において、 Linux よりも動作速度が遅くなります(例えば、ファイル・システムにおける操作に関しては、最大で5%動作が遅くなります)。また、インストールの容易さ以外に、Linuxに勝る特有の機能は存在しません。

32ビット版ではなく64ビット版のオペレーティング・システムを選択することで、より多くのメモリをサーバ・プロセスに割り当てることができます。サーバ・プロセスに割り当てられるメモリ量が現時点で顕在化した問題ではない場合でも、オペレーティング・システムを32ビット版から64ビット版に変更することで、メモリにかかる負荷を低減し、スケーラビリティを向上することができます。(ただし評価目的の場合は、32ビット版のオペレーティング・システムを使用することができます)。

運用環境においては、64ビット版のLinuxと、最低でも 8GB の RAM を使用することが推奨されます。

OS の保持しているファイル・ハンドルが、Polarion を使用するために必要十分であることを確認してください。Windows の場合は、必要なファイル・ハンドルをデフォルトで備えているので、この問題はLinux に特有の問題だと言えます。なお、Polarion のプロセスが十分なパフォーマンスを発揮するためには、32K ファイル・ハンドルへのアクセスを必要とします。

ネットワーク

Polarion のクライアント・インターフェースは、サーバとの迅速かつ集中的な通信を行います。そのため、ネットワーク待ち時間は、クライアントのパフォーマンスを低下させる主要な要因となります。理想的には、クライアントとサーバ間におけるネットワーク・ラウンドトリップ時間(ping)が、150ミリ秒を下回っているとよいでしょう。

仮想化

仮想環境では、ソフトウェアによって、メモリ、ネットワーク、 グラフィックスおよびストレージを含むハードウェア・コンポーネントがエミュレートされるため、パフォーマンス・コストに影響を与えます。その結果、仮想マシン(VM)と専用の物理ハードウェアにおいて、同じ仕様に基づき、同じアプリケーションを実行した場合、仮想マシン上で実行されたアプリケーションのパフォーマンスは、専用の物理ハードウェア上で実行されたアプリケーションのパフォーマンスを下回ります。

物理サーバ環境における推奨ハードウェア構成は、複数の仮想マシンを同時に実行できる物理ホスト・サーバ・マシンに限らず、Polarion が実行される仮想マシンに対しても適用することができます。

Polarion Software社は、Linux の仮想マシン上でのみ Polarion を実行することを推奨しています。なぜならば、Windows は Linux に比べて動作が遅い上に、より大きなメモリ占有領域を必要とし、仮想化によってそれらの問題が増幅してしまうオペレーティング・システムだからです。

ハードウェア構成の例

  S M L XL XXL
オペレーティング・システム 32 / 64-bit 64-bit 64-bit 64-bit 64-bit
CPU コア 4 8 8 16 32
GB RAM (Polarion専用) 8 (4) 16 (8) 32 (16) 64 (32) 128 (64)
Polarion 用のストレージ 250GB+ 500GB+ 1TB+ (SCSi / similar) 1TB+ (RAID 10, NAS, SAN) 1TB+ (RAID 10, NAS, SAN)
プロジェクト数 < 100 > 100 > 300 500 500
ユーザ数 < 50 < 150 > 150 > 300 > 500

ファイルをキャッシュするために、十分な RAM をOSに割り当ててください。SVN が別のマシンにホストされている場合には、より多くのメモリがPolarion のプロセスに必要になる場合があります。


著者について:

Nick Entin 氏は、Polarion Software社の研究開発担当副社長であり、認定を受けたスクラム・マスターとしても活動を行っています。

PAGE TOP