Bill Essary、Software Architect
Microsoft Corporation

November 2006
日本語版最終更新日 2007 年 7 月 27 日

適用対象 :
  Microsoft Visual Studio 2005 Team Foundation Server

概要: この記事では、Visual Studio 2005 Team Foundation Server のチーム プロジェクトの制限、および監視における推奨事項について説明します。

チーム プロジェクトの制限を算出するためのサンプル Microsoft Excel スプレッドシートのダウンロード (25 KB)

目次

概要
チーム プロジェクトの制限に影響を与える要因
MSF 作業項目タイプを使用するチーム プロジェクトの制限
カスタム作業項目タイプを使用するチーム プロジェクトの制限
チーム プロジェクトの制限に近くなった Team Foundation Server の管理
まとめ

概要:

Microsoft は Visual Studio Team Foundation Server チーム プロジェクトの制限のためのガイダンスを更新しました。この記事では、チーム プロジェクトの推奨される新しい制限、チーム プロジェクトの制限に影響を与える要因、プロジェクトの制限を見積もるための基準、およびチーム プロジェクトの制限と関連データの監視と管理の推奨事項について説明します。

この記事は、Team Foundation Server 環境を導入し保守するシステム管理者、およびシステム運用者を対象としています。

チーム プロジェクトの新しい制限

MSF for CMMI Process Improvement テンプレートに基づくチーム プロジェクトに推奨されるチーム プロジェクトの個数の新しい制限は 250 個です。MSF for Agile Software Development テンプレートに基づくチーム プロジェクトに推奨されるチーム プロジェクトの個数の新しい制限は 500 個です。カスタム作業項目タイプを使用するプロジェクトに推奨される個数の制限は、マイクロソフトのテスト データに基づきます。

具体的なガイダンスについては、MSF 作業項目タイプを使用するチーム プロジェクトの制限、およびカスタム作業項目タイプを使用するチーム プロジェクトの制限を参照してください。

新しい運用ガイダンス

この記事では、Team Foundation Server 導入環境のチーム プロジェクトの制限に影響を与える要因を説明し、Team Foundation Server 環境を監視する際に使用できる基準を提供します。

Team Foundation Server におけるチーム プロジェクトの制限は、作業項目追跡メタデータのキャッシュのサイズに対する制限であると言うことができます。メタデータのキャッシュのサイズとは、サーバーからのすべてのキャッシュ ファイルを保持する、クライアント コンピュータ上のサブディレクトリのサイズです。作業項目追跡メタデータのキャッシュ サイズは、同じ頃にサーバーに接続したすべてのクライアント コンピュータにおいて同じになります。メタデータのキャッシュ サイズを監視し、サーバーがチーム プロジェクトの制限に近くなっていることがわかっている場合は、クライアント コンピュータが、少数ずつオンラインになるように注意する必要があります。また、クライアント コンピュータの RAM の大きさを平均で 1 GB まで増やすことも考慮する必要があります。ほとんどのクライアントがサーバーに対してローカルである場合は、RAM を増やすことで、同時にオンラインにするクライアントの個数を増やすことができます。しかし、RAM を増やしても、チーム プロジェクトの制限そのものは変わりません。

チーム プロジェクトの制限に影響を与える要因

チーム プロジェクトの制限は、リソース使用に基づくソフト制限 (絶対ではありません) です。しかし、システム全体のパフォーマンスは、チーム プロジェクトの個数が多くなるにつれて低下します。このセクションでは、考慮する必要のある主な問題、および Team Foundation Server がチーム プロジェクトの制限に近づいたときに見られる現象を説明します。

チーム プロジェクトの個数が多い場合、パフォーマンスに影響する主なリソースは、クライアント コンピュータ上の使用可能なメモリの大きさと、クライアントとサーバー間のネットワーク速度です。リソースの消費が重要な考慮事項となるのは、サーバーが新たに接続したクライアント コンピュータと通信しているときのみです。長期間にわたって多数のチーム プロジェクトが作成されてきたサーバーでも、そのサーバーに定期的に接続しているクライアント コンピュータを更新する場合は、パフォーマンスが大きく低下することはありません。しかし、サーバーに初めて接続したクライアント コンピュータ、または多くのチーム プロジェクトが作成された後に接続したクライアント コンピュータは、サーバーから多くのデータをダウンロードし、多くのメモリを使用してそのデータを処理する必要があります。クライアント コンピュータ上の使用可能な RAM が少ない場合、またはサーバーへの接続が遅い場合は、一時的に処理が遅くなり、チーム エクスプローラでチーム プロジェクトのノードを展開するのに数分がかかるという場合もあります。また、サーバーがボトルネックとなる場合もあります。接続が開始されたばかりの時期は、サーバーで、大量の新しいクライアント コンピュータを同時に追加していく必要があります。

作業項目追跡メタデータのキャッシュのサイズは、大量のチーム プロジェクトを抱えるシステムのパフォーマンスに影響します。メタデータのキャッシュ サイズを増加させる最も大きな要因は、チーム プロジェクトで使用される作業項目タイプ定義の個数、およびその複雑性です。(システムの他の部分、たとえば、ユーザーやグループの合計数なども、メタデータのキャッシュ サイズの増加の要因となります。)

作業項目タイプの複雑性を測定するのは簡単ではありません。この複雑性は、1 つの作業項目の中のフィールドの個数、規則の個数と複雑性、許可される値のリストのサイズ、および定義内にある他のすべてのデータから測定します。チーム プロジェクトを作成するときに使用する作業項目タイプが常に同じである場合は、すべてのプロジェクトが同じプロセス テンプレートを使用するため、メタデータのキャッシュは、サーバー上のチーム プロジェクトの個数と同じ割合で増加します。しかし、サーバーのパフォーマンスは、この線形の増加に対して階段状に低下します。クライアント コンピュータがダウンロードするメタデータのキャッシュには、サーバー上で管理されるすべてのチーム プロジェクトの、すべての作業項目タイプのデータが含まれています。そのクライアントが実際に使用するチーム プロジェクトの個数は関係しません。クライアントは、初回の接続でキャッシュをダウンロードし、その後も、最新の状態を保つためにサーバーと定期的にメタデータを交換します。多数のチーム プロジェクトを抱えているサーバーに新しいクライアント コンピュータを追加した場合、サーバーのパフォーマンスにまず影響するのは、メタデータのキャッシュの初回のダウンロードです。

クライアントが最新に近いキャッシュを取得した後であれば、チーム プロジェクトの個数が多いことによる負荷は比較的小さく、ダウンロード時間にも、クライアントおよびサーバーのどちらのパフォーマンスにもあまり影響を与えません。たとえば、最新に近いキャッシュを既に保持しているクライアント コンピュータ (RAM は 512 MB) では、MSF for CMMI Process Improvement に基づく 1 つのチーム プロジェクトを管理するサーバーに接続した場合でも、MSF for CMMI Process Improvement に基づく 200 個のチーム プロジェクトを管理するサーバーに接続した場合でも、開始にかかる時間の差は、わずか 1 秒 (おおよそ) です。しかし、同じクライアントによる初回の接続では、MSF for CMMI Process Improvement に基づく 200 個のチーム プロジェクトを管理するサーバーからキャッシュをダウンロードする場合の方が、おおよそ 43 秒長くなります。サーバーへの接続が遅いリモート クライアントでは、データ転送時間がさらに長くなります。RAM が 1 GB 以上のクライアント コンピュータでは、初回の接続時間が大幅に短縮されます。43 秒違いの原因の大部分がページングであるためです。

多数の新規クライアント コンピュータが同時に 1 つのサーバーにメタデータを要求した場合は、サーバーが、Internet Information Services (IIS) の既定のメモリ制限に達するまでメモリを使用してしまう可能性があります。制限に達した場合、IIS は再始動してから、メタデータのキャッシュに対する要求の処理を再開します。しかし、多数のクライアント コンピュータでデータの要求を続ければ、サーバーの反応は大幅に遅くなります。このような状態は、多数のチーム プロジェクトがサーバー上に短期間のうちに作成されたために、クライアント コンピュータがメタデータを少しずつ収集するということが不可能な場合に発生します。また、作業項目タイプ定義のフィールドが本番稼働中のサーバーから削除された場合 (このようなことは通常行なわれません) にも発生します。多数の新規クライアント コンピュータがサーバーに接続を試みるという状態が発生するのは、一般的には、サーバーがバックアップ メディアから復元された後のみです。

MSF 作業項目タイプを使用するチーム プロジェクトの制限

Team Foundation Server に付属の MSF テンプレートの 1 つを使用する作業項目タイプを使用している場合は、チーム プロジェクトの制限を判断する際に以下の推奨事項を参考にしてください。

• MSF for CMMI Process Improvement テンプレートに基づくチーム プロジェクトの場合、推奨されるメタデータのキャッシュの制限は 250 個のチーム プロジェクトです。
• MSF for Agile Software Development テンプレートに基づくチーム プロジェクトの場合、推奨されるメタデータのキャッシュの制限は 500 個のチーム プロジェクトです。

Team Foundation Server データ層で、TFSWorkItemTracking.dbo.Rules のデータ スペースのサイズを監視することにより、おおよそのメタデータのキャッシュ サイズの制限、およびチーム プロジェクトの制限を判断することができます。Rules テーブルのデータ スペースのサイズは、メタデータのキャッシュのサイズに直接的に関係するわけではありませんが、多くのシステムにおいて簡単に監視することができます。推奨されるキャッシュの制限は、おおよそ、Rules テーブルのデータ スペース サイズが 30 MB の場合のサイズとなります。

Rules テーブルのサイズを確認するには、次のようにします。

1. SQL Server Management Studio を起動し、Team Foundation Server データ層のコンピュータに接続します。
2. [データベース] ノードを展開し、[TfsWorkItem] データベースを探します。
3. [TfsWorkItem] ノードの [テーブル] フォルダを展開します。
4. dbo.Rules テーブルを選択し、右クリックしてプロパティを表示します。
5. [General] プロパティ ページの [Data space] の数字を確認します。

カスタム作業項目タイプを使用するチーム プロジェクトの制限

カスタムな作業項目タイプを使用する場合は、以下の詳細な実験データを使用して、作業項目追跡のクライアント メタデータのキャッシュ サイズを見積もることができます。見積もったキャッシュ サイズから、現在のシステムのチーム プロジェクトの制限を判断することができます。

マイクロソフトは、500 個のチーム プロジェクトでのテストを使用して、同様のチーム プロジェクト プロファイルを持つシステムのメタデータのキャッシュ サイズを予測できるようにしています。図 1 は、システム内のチーム プロジェクトの制限を示しています。色でプロジェクトのレベルを示しています。安全 (緑色)、危険 (黄色)、過剰 (赤色) です。関連する主要因 (クライアントのメモリ、リモート接続の帯域幅、および負荷時のサーバーのメモリの状況) を考慮すると、作業項目追跡メタデータのキャッシュの安全なしきい値は、チーム プロジェクトが 500 個の場合で 65 MB です。

図 1. カスタム クライアント メタデータのキャッシュの制限

この実験データは、Microsoft Excel スプレッドシートとして入手可能です (この記事の最初のダウンロードを参照してください)。このスプレッドシートを使用することで、カスタム作業項目タイプを使用している場合も、そのサーバーのチーム プロジェクトの最大数を見積もることができます。スプレッドシートを使用するには、カスタム作業項目タイプ付きプロセス テンプレートを使用したチーム プロジェクトが存在しているサーバーからのデータで、紫色のセルを更新します。

Rules テーブルのサイズを確認するには、次のようにします。

1. SQL Server Management Studio を起動し、Team Foundation Server データ層のコンピュータに接続します。
2. [データベース] ノードを展開し、[TfsWorkItem] データベースを探します。
3. [TfsWorkItem] ノードの [テーブル] フォルダを展開します。
4. dbo.Rules テーブルを選択し、右クリックしてプロパティを表示します。
5. [General] プロパティ ページの [Data space] の数字を確認します。

サイズを判断するこのプロセスは、きれいなテスト システムで実行します。最も有効な見積もりを得るには、対象とするタイプを持つチーム プロジェクトを 1 つ作成した時点で Rules テーブルのサイズを計測し、その後、追加のチーム プロジェクトを作成した後に、再びサイズを測定します。図 1 の例では、9 個のチーム プロジェクトを追加してから、2 回目の計測を行なっています。このモデルは、数百個のプロジェクトに対する実際のサイズの実験において、作業項目追跡メタデータのキャッシュのサイズを正常に見積もることができました。きれいなシステムが使用可能でない場合は、1 個のチーム プロジェクトに対する Rules テーブルの見積もりサイズを 0 として、チーム プロジェクトの制限が低めに見積もられるようにします。

このモデルによって行なわれるサイズ計算は、単なる見積もりです。基準としてのみ使用することをお勧めします。予測の精度には、いくつかの点が影響しています。最も大きく影響するのは、システム上のすべてのチーム プロジェクトが同じプロセス テンプレートを使用すると想定している点です。この想定が当てはまらない場合は、有効な見積もりを生成できるように新たなモデルを作成する必要があります。(システムの他の点、たとえば、ユーザーやグループの個数なども、メタデータのキャッシュの増加に影響を与えます。) 最終的に、システム パフォーマンスの低下を表すために、このモデルは、メタデータのキャッシュ サイズというアナログな指標を使用して、階段状に増加していく数字の大きさを予測しています。

注意 システムで許容できるメタデータのキャッシュ サイズの制限を判断する場合は、システム内のリモート ユーザーの割合、およびそれらのユーザーとの接続の帯域幅も考慮する必要があります。

チーム プロジェクトの制限に近くなった Team Foundation Server の管理

Team Foundation Server を管理する場合は、チーム プロジェクトの制限を基準として、作業項目追跡メタデータのキャッシュのサイズを監視し、システムがチーム プロジェクトの制限に近くなった場合にその動作に影響を与える要因を考慮しておく必要があります。(メタデータのキャッシュのサイズが、推奨される安全なしきい値の 80% に達したときに、そのシステムはプロジェクトの制限に近くなったとみなします。)

作業項目追跡メタデータのキャッシュのサイズは、次のように測定します。

1. システム内のクライアント コンピュータ上で、Microsoft Windows エクスプローラを開始し、\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache フォルダを表示します。
2. 名前が Team Foundation Server GUID であるサブディレクトリを右クリックし、[プロパティ] を選択し、[プロパティ] ダイアログ ボックスに表示されるサイズを確認します。

クライアントが複数のサーバーに接続している場合は、サーバーの GUID とコンピュータ名との関連付けを知っておく必要があります。これを最も簡単に調べるには、このキャッシュ フォルダ内の ServerMap を開きます。

チーム プロジェクトの制限に近くなったシステムを管理する場合は、次のステップを行います。

• 新規クライアント コンピュータは少数ずつに分けてオンラインにする。

  クライアント コンピュータは、最初に接続したときに、メタデータのキャッシュをすべてダウンロードします。数百 (数千) のクライアント コンピュータが初めて接続するようなシステムの場合は、この初期接続にサーバーが対応できない可能性があります。メタデータのキャッシュ サイズが、推奨される安全なしきい値の 80% の場合、サーバーが作業項目追跡メタデータへの要求を約 20 以上同時に処理しようとすると、サーバーのメモリが圧迫することがあります。これにより、既定の IIS メモリのしきい値に達する場合もあります。この問題を避けるために、システムをバックアップから復元するなど、作業項目追跡メタデータのキャッシュを無効にするイベントの後は、必ず、クライアント コンピュータを 100 台以下のグループに分けて段階的にオンラインにするようにします。

• クライアント コンピュータの RAM を最低でも 1 GB にする。

  RAM の増加により、初回接続時のクライアント コンピュータのパフォーマンスは大幅に改善できます。これは、サーバーにも良い影響があります。サーバーが個々のクライアント コンピュータからの要求を処理する時間も短縮されるためです。前にも記述したとおり、クライアント コンピュータの初回のメタデータ要求の処理にかかる時間は、RAM が 1 GB の場合、512 MB の場合に比べて、43 秒短くなります。

まとめ

この記事では、Team Foundation Server のチーム プロジェクト、およびメタデータのキャッシュ サイズの制限を判断、および監視するときに考慮する必要のある事項を説明しました。以下の基準を考慮するようにします。

• MSF for CMMI Process Improvement テンプレートに基づくチーム プロジェクトの場合、推奨されるメタデータのキャッシュの制限は 250 個のチーム プロジェクトです。
• MSF for Agile Software Development テンプレートに基づくチーム プロジェクトの場合、推奨されるメタデータのキャッシュの制限は 500 個のチーム プロジェクトです。
• システムのパフォーマンスを向上させるには、クライアント コンピュータの RAM を 1 GB まで増やします。

メタデータのキャッシュ サイズを監視する場合は、次の基準に従います。

• Team Foundation Server のデータ層で、TFSWorkItemTracking.dbo.Rules のデータ スペースのサイズを監視します。この Rules テーブルのデータ スペースのサイズは、メタデータのキャッシュのサイズに直接的に関係するわけではありませんが、多くの場合、簡単に監視することができます。
  • TFS の場合、推奨されるチーム プロジェクトの制限は、Rules テーブルのデータ スペースのサイズが 30 MB のときの値です。
• Team Foundation Server の障害復旧計画に、制限に近い場合の対策を追加します。
  • チーム プロジェクトの制限の値がしきい値の 80% より小さい場合は、バックアップ メディアからシステムを復元するときの方法に変更の必要はありません。
  • チーム プロジェクトの制限の値がしきい値の 80% を超えている場合は、システムを復元する際、クライアント コンピュータを 100 台以下のグループに分けて段階的にオンラインにします。