SharePoint Server 2010 のパフォーマンス テスト

  • [アーティクル]

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

この記事では、Microsoft SharePoint Server 2010 のパフォーマンスをテストする方法について説明します。テストと最適化の段階は、効果的な容量管理の重要な要素です。新しいアーキテクチャは、運用環境に展開する前にテストする必要があります。また、受け入れテストを、以下の監視のベスト プラクティスと共に実施し、設計したアーキテクチャがパフォーマンスと容量の目標を達成することを確認する必要があります。これにより、実際の展開でユーザーが潜在的なボトルネックの影響を受ける前に、そのボトルネックを特定して最適化できます。Microsoft Office SharePoint Server 2007 環境からアップグレードするときにアーキテクチャの変更を計画している場合や、SharePoint Server 2010 の新しい機能のユーザー負荷を見積もる場合、新しい SharePoint Server 2010 ベースの環境がパフォーマンスと容量の目標を満たすことを確認するためのテストが特に重要です。

環境のテストが完了すると、テスト結果を分析し、「SharePoint Server 2010 の容量計画」の「手順 1. モデル作成」で確立したパフォーマンスと容量の目標を達成するために加える必要のある変更を確認できます。

以下の手順は、運用前に実行する必要のある推奨補助手順です。

  • 「手順 2. 設計」で設計した初期のアーキテクチャを模倣するテスト環境を作成します。

  • 「手順 1. モデル作成」で特定したデータセットまたはデータセットの一部をストレージに格納します。

  • 「手順 1. モデル作成」で特定した負荷を表す人工的負荷をシステムにかけます。

  • テストを実行し、結果を分析して、アーキテクチャを最適化します。

  • 最適化したアーキテクチャをデータ センターで展開し、小さいユーザー セットを使用してパイロットをロールアウトします。

  • パイロットの結果を分析し、潜在的なボトルネックを特定して、アーキテクチャを最適化します。必要に応じて、再テストを実行します。

  • 運用環境に展開します。

この記事を読む前に、「SharePoint Server 2010 での容量管理と規模設定の概要」を読む必要があります。

この記事の内容

  • テスト計画を作成する

  • テスト環境を作成する

  • テストとツールを作成する

テスト計画を作成する

計画に次の項目が入っていることを確認します。

  • 想定した運用時のパフォーマンスの目標値で動作するように設計されたハードウェア。テスト システムのパフォーマンスは常に控えめに測定します。

  • カスタム コードまたはカスタム コンポーネントがある場合は、最初にそのコンポーネントを隔離した状態でそのパフォーマンスをテストし、パフォーマンスと安定性を検証することが重要です。コンポーネントが安定した後で、そのコンポーネントをインストールしたシステムをテストし、インストールしていない状態のファームとパフォーマンスを比較する必要があります。運用システムで発生するパフォーマンスと信頼性の問題の主な原因の多くは、カスタム コンポーネントです。

  • テストの目標を理解します。ファーム用に開発された新しいカスタム コンポーネントのパフォーマンスを検証する、コンテンツのクロールとインデックスの作成にかかる時間を確認する、ファームでサポートできる 1 秒あたりの要求数を確認するなど、事前にテストの目標を理解します。テスト中には多数の異なる目標を設定する可能性があるので、優れたテスト計画を作成するためには、最初に目標を決定します。

  • テストの目標を測定する方法を理解します。たとえば、ファームのスループットを測定する場合は、RPS とページ待機時間を測定します。検索パフォーマンスを測定する場合は、クロール時間とドキュメントのインデックス作成速度を測定します。テストの目標をよく理解すると、テストを完了するために検証する必要がある主要業績評価目標を明確に定義しやすくなります。

テスト環境を作成する

テストの目標を決定し、測定方法を定義し、(このプロセスの手順 1. と 2. から) ファームの容量要件を特定した後で、テスト環境を設計し、作成します。テスト環境を作成する作業は、軽視されることが多くあります。テスト環境では、運用環境をできるだけ正確に再現する必要があります。テスト環境を設計するときに考慮する必要がある機能の一部を次に示します。

  • 認証 – ファームで使用する認証 (Active Directory ドメイン サービス (AD DS)、フォーム ベース認証 (および使用するディレクトリ)、クレーム ベース認証など) を決定します。使用しているディレクトリに関係なく、テスト環境に必要なユーザーの数、作成する予定のユーザーの数、必要なグループまたはロールの数、およびそれらを作成し事前設定する方法を確認します。また、認証サービスがテスト中にボトルネックにならないように十分なリソースがそのサービスに割り当てられていることを確認する必要があります。

  • DNS – テスト時に必要な名前空間を確認します。要求に応答するサーバーを特定し、各サーバーが使用する IP アドレスおよび作成する必要がある DNS エントリが計画に追加されていることを確認します。

  • 負荷分散 – 複数のサーバーを使用していると想定すると (これは普通の構成です。複数のサーバーがない場合は、負荷テストを保証できるだけの負荷を得ることができません)、何らかのロード バランサー ソリューションが必要になります。これに該当するのは、ハードウェアの負荷分散デバイスか、Windows NLB のようなソフトウェアによる負荷分散です。使用するソリューションを決定し、すばやく効率的にセットアップするために必要なすべての構成情報を書き留めます。また、負荷テストのエージェントは、通常、30 秒に 1 回だけアドレスを URL に解決しようとする点に注意してください。つまり、テスト エージェントは、使用できるすべてのサーバーに対して分散するのではなく、すべての要求で同じサーバーに到達する可能性があるので、ローカル ホスト ファイルまたはラウンド ロビン DNS を負荷分散に使用しないでください。

  • テスト サーバー – テスト環境を計画するときは、SharePoint Server 2010 ファームのサーバーについて計画を立てるだけでなく、テストを実行するのに必要なコンピューターについても計画を立てる必要があります。通常、少なくとも 3 台のサーバーが必要です。これ以上必要な場合もあります。Visual Studio Team System (Team Test Load Agent) を使用してテストを実行する場合は、1 台のコンピューターを負荷テストのコントローラーとして使用します。一般的に、2 台以上のコンピューターを負荷テストのエージェントとして使用します。エージェントとは、テスト内容に関する指示をテスト コントローラーから受け取り、要求を SharePoint Server 2010 ファームに発行するコンピューターのことです。テスト結果は、SQL Server ベースのコンピューターに保存されます。SharePoint Server 2010 ファームの使用可能な SQL Server リソースはテスト データの書き込みによる影響を受け、通常の状態ではなくなるので、SharePoint Server 2010 ファームに使用する SQL Server ベースのコンピューターと同じコンピューターを使用しないでください。また、テストの実行中は、SharePoint Server 2010 ファームのサーバー、ドメイン コントローラーなどを監視するときと同じ方法でテスト サーバーを監視して、テスト結果がセットアップしているファームを確実に表すようにする必要があります。負荷エージェントまたはコントローラー自体がボトルネックとなることがあります。このような場合、テストで確認したスループットは、通常、ファームでサポートできる最大のスループットではありません。

  • SQL Server – テスト環境では、記事「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」のセクション「SQL Server を構成する」と「ストレージと SQL Server のパフォーマンスを検証し監視する」に記載されているガイダンスに従って操作を行います。

  • データセットの検証 – 既存の運用システムからのデータを使用することが最高条件のシナリオであることを念頭に置いて、テスト対象のコンテンツを決定します。たとえば、運用ファームからコンテンツ データベースをバックアップしてそのデータベースをテスト環境で復元し、データベースをアタッチしてコンテンツをファームに展開できます。架空のデータまたはサンプル データに対してテストを実行するときは常に、コンテンツ コーパスの相違が原因で、結果が偏る可能性があります。

サンプル データを作成する必要がある場合は、次の点に注意してコンテンツを構築します。

  • すべてのページは発行する必要があります。ページはチェックアウトしないでください。

  • ナビゲーションは実際の環境に即したものにする必要があります。運用において使用することが予想されるナビゲーション以上のものを構築しないでください。

  • 運用サイトで使用される予定のカスタマイズを予測する必要があります。たとえば、マスター ページ、スタイル シート、JavaScript など、該当するすべてのものをできるだけ運用環境に近い形でテスト環境に実装する必要があります。

  • 必要な SharePoint グループまたはアクセス許可レベルの数、およびユーザーに関連付ける方法を決定します。

  • プロファイルをインポートする必要があるかどうか、インポートにかかる時間を確認します。

  • 対象ユーザーが必要かどうかを判断し、対象ユーザーを作成および事前設定する方法を決定します。

  • 追加の検索コンテンツ ソースが必要かどうかを判断し、その検索コンテンツ ソースを作成するのに必要な材料を確認します。作成する必要がない場合は、検索コンテンツ ソースをクロールできるネットワーク アクセスがあるかどうかを確認します。

  • ドキュメント、リスト、リスト アイテムなど、十分な量のサンプル データがあるかどうかを確認します。ない場合、このコンテンツを作成する方法について計画します。

  • 検索を適切にテストできるようにさまざまなコンテンツを用意することを計画します。よくある間違いは、同じドキュメントを、何百回、何千回と異なるドキュメント ライブラリに毎回別の名前でアップロードすることです。この場合、運用環境の実際のコンテンツでは行う必要がない重複データの検出にクエリ プロセッサが大量の時間を費やすので、検索パフォーマンスに影響する可能性があります。

テストとツールを作成する

テスト環境を動作可能な状態にした後で、ファームのパフォーマンスと容量の測定に使用するテストを作成し、調整します。ここでは、何度か Visual Studio Team System (Team Test Load Agent) について触れていますが、概念の多くは、どの負荷テスト ツールを使用している場合でも当てはまります。Visual Studio Team System の詳細については、MSDN の「Visual Studio Team System (英語)」(https://msdn.microsoft.com/ja-jp/library/fda2bad5.aspx) (英語) を参照してください。

SharePoint Load Test Kit (LTK) と VSTS を組み合わせて SharePoint 2010 ファームの負荷テストを実行することもできます。Load Test Kit は、Windows SharePoint Services 3.0 と Microsoft Office SharePoint Server 2007 IIS のログに基づいて Visual Studio Team System 2008 負荷テストを生成します。VSTS 負荷テストを使用すると、容量計画作業またはアップグレード前のストレス テストの一部として SharePoint Foundation 2010 あるいは SharePoint Server 2010 に対する人工的な負荷を生成できます。

Load Test Kit は、Microsoft ダウンロード センター (英語) (https://www.microsoft.com/downloads/details.aspx?FamilyId=718447d8-0814-427a-81c3-c9c3d84c456e\&displaylang=en) (英語) からダウンロードできる Microsoft SharePoint 2010 Administration Toolkit v1.0 に収録されています。

テストを成功させるための主な条件は、ユーザーが SharePoint Server 2010 運用ファームで広範囲のコンテンツにアクセスするのと同様に、広範囲のテスト サイトのデータに対して要求を生成することで、現実に即した負荷を効果的にシミュレートできることです。これを実現するには、通常、データ ドリブン テストになるようにテストを構築する必要があります。ハードコードされた個別のテストを何百個も作成して特定のページにアクセスするのではなく、アイテムの URL を含んでいるデータ ソースを使用する少数のテストを使用して、その一連のページに動的にアクセスする必要があります。

Visual Studio Team System (Team Test Load Agent) では、さまざまな形式のデータ ソースを処理できますが、ほとんどの場合、最も簡単に管理でき、開発環境とテスト環境の間を移動できるのは CSV ファイル形式です。コンテンツを含んだ CSV ファイルを作成すると、場合によっては、SharePoint Server 2010 ベースの環境を列挙し、使用されているさまざまな URL を記録するためのカスタム ツールを作成する必要があります。

ツールを使用する必要があるのは、次のような作業です。

  • Active Directory で、またはフォーム ベース認証を使用している場合はその他の認証ストアでユーザーとグループを作成する。

  • サイト、リストとライブラリ、リスト アイテム、ドキュメントの URL を列挙し、負荷テスト用の CSV ファイルにその URL を入力する。

  • さまざまなドキュメント ライブラリとサイトにサンプル ドキュメントをアップロードする。

  • サイト コレクション、Web、リスト、ライブラリ、フォルダー、およびリスト アイテムを作成する。

  • 個人用サイトを作成する。

  • テスト ユーザーのユーザー名とパスワードを含んだ CSV ファイルを作成する。これは、負荷テストの実行者となるユーザー アカウントです。複数のファイルを作成する必要があります。たとえば、あるファイルには管理者ユーザーだけを入れ、別のファイルには、昇格された特権が付与されたその他のユーザー (作成者、共同作成者、階層管理者など) を入れ、その他のファイルには閲覧者だけを入れます。

  • 検索キーワードと語句のサンプルのリストを作成する。

  • ユーザーと Active Directory グループ (または、フォーム ベース認証を使用している場合はロール) を使用して SharePoint グループとアクセス許可レベルを設定する。

Web テストを作成するときには、次に示すその他のベスト プラクティスに注意し、実装することをお勧めします。

  • 出発点として簡単な Web テストを記録します。このテストでは、URL、ID などのパラメーターに対して値がハードコードされます。このハードコードされた値を CSV ファイルからのリンクに置き換えます。Visual Studio Team System (Team Test Load Agent) では、このような値のデータ バインドを簡単に実行できます。

  • テストには必ず検証ルールを設けます。たとえば、ページを要求しているときにエラーが発生した場合、応答として error.aspx ページが表示されます。負荷テストの結果には HTTP 状態コード 200 (成功) が返されるので、Web テストの観点では、もう 1 つの肯定応答のように見えます。エラーが発生しているのは明らかなので、別の方法で追跡する必要があります。1 つ以上の検証ルールを作成すると、特定のテキストが応答として送信されたことを認識できるので、検証が失敗し、その要求をエラーとしてマークできます。たとえば、Visual Studio Team System (Team Test Load Agent) の簡単な検証ルールは、ResponseUrl 検証です。この検証ルールでは、リダイレクト後に表示されるページが、テストに記録された応答ページと同じでない場合にエラーを記録します。また、応答で "アクセスが拒否されました" などの言葉を検出した場合にエラーを記録する FindText ルールを追加することもできます。

  • テストでは、異なるロールが割り当てられた複数のユーザーを使用します。出力キャッシュのような動作は、現在のユーザーの権限に応じて変化します。たとえば、サイト コレクションの管理者、または承認権限あるいは作成権限が付与された認証されたユーザーには、キャッシュされた結果は表示されません。このようなユーザーには必ず最新バージョンのコンテンツが表示されます。ただし、匿名ユーザーにはキャッシュされたコンテンツが表示されます。テスト ユーザーのこれらのロールの混合率が運用環境の混合率とほぼ一致するようにする必要があります。たとえば、運用環境にサイト コレクションの管理者が 2、3 人しかいない場合は、テスト コンテンツに対してサイト コレクションの管理者であるユーザー アカウントがページ要求全体の 10% を占めるテストを作成しないでください。

  • 依存する要求の解析は、Visual Studio Team System (Team Test Load Agent) の属性の 1 つで、テスト エージェントがページだけを取得するのか、ページに加えて、画像、スタイル シート、スクリプトなど、ページに組み込まれているすべての関連する要求を取得するのかを指定します。負荷テストでは、一般的に次の理由からこれらのアイテムを無視します。

    • ユーザーが初めてサイトにヒットした後、多くの場合これらのアイテムは、ローカル ブラウザーによってキャッシュされます。

    • これらのアイテムは、通常、SharePoint Server 2010 ベースの環境に展開された SQL Server から提供されません。BLOB キャッシュを有効にしている場合、これらのアイテムは、Web サーバーによって提供されるので、SQL Server に負荷はかかりません。

初めてサイトを表示するユーザーの割合が定期的に高い場合、ブラウザー キャッシュを無効にしている場合、または何らかの理由で意図的に BLOB キャッシュを使用しない場合は、テストで依存する要求の解析を有効にする意味があります。ただし、これは非常に例外的な処理です。ほとんどの実装では一般的ではありません。この属性を有効にすると、テスト コントローラーによって報告される RPS 数が大幅に増加する可能性があります。これらの要求はすぐに満たされるので、ファームの実際の容量よりも多い容量がファームにあると勘違いする可能性があります。

  • クライアント アプリケーションのアクティビティのモデルも必ず作成します。Microsoft Word、PowerPoint、Excel、Outlook などのクライアント アプリケーションは、同様に SharePoint Server 2010 ファームに対して要求を生成します。クライアント アプリケーションは、RSS フィードの取得、パーソナリティ情報の取得、サイトとリスト構造に関する詳細の要求、データの同期など、サーバー要求を送信することで環境に負荷をかけます。実装でこのようなクライアントを使用する場合は、これらの要求を追加してモデルを作成する必要があります。

  • ほとんどの場合、1 つの Web テストには 1 つの要求だけを追加する必要があります。テストで指定されている要求が 1 つだけの場合、テスト装置と各要求の調整およびトラブルシューティングを簡単に実行できます。Web テストでは、通常、シミュレートする操作が複数の要求で構成される場合は、複数の要求を入れる必要があります。たとえば、一連の動作をテストするには、ドキュメントのチェックアウト、ドキュメントの編集、ドキュメントのチェックイン、およびドキュメントの発行という複数の手順で構成されたテストが必要です。また、同じユーザー アカウントを使用してチェックアウト、編集、再チェックインを実行するというように手順間の状態を維持する必要もあります。各手順間で状態を維持する必要があり、複数手順で構成される操作は、1 つの Web テストで複数の要求を実行することで最適な結果を得ることができます。

  • 各 Web テストを個別にテストします。各テストは、大規模な負荷テストで実行する前に正常に完了できることを確認します。Web アプリケーションのすべての名前が解決でき、テストで使用するユーザー アカウントにテストを実行できるだけの十分な権限があることを確認します。

Web テストは、各ページ、ドキュメントのアップロード、リスト アイテムの表示などに対する要求で構成されます。これらすべての要求は負荷テストにまとめられます。負荷テストでは、実行する予定のすべての Web テストを組み合わせます。各 Web テストに対して、実行する時間の割合を指定できます。たとえば、運用ファームで行われる要求の 10% が検索クエリであることがわかっている場合、負荷テストで、クエリ Web テストを全体の 10% の時間、実行するように構成します。Visual Studio Team System (Team Test Load Agent) の負荷テストでは、ブラウザー ミックス、ネットワーク ミックス、負荷パターン、実行設定などを構成できます。

負荷テストでは、次のその他のベスト プラクティスに注意し、実装することをお勧めします。

  • テストで適切な読み取り/書き込みの比率を使用します。テストで書き込みの数を増やしすぎると、テストの全体のスループットに大きく影響する可能性があります。グループ作業ファームでも、書き込みよりも読み取りの比率が高い傾向にあります。詳細については、「パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)」を参照してください。

  • その他の大量のリソースを使用する操作の影響を考慮し、その操作を負荷テスト中に実行するかどうかを判断します。たとえば、バックアップと復元のような操作は、通常は、負荷テスト中に実行しません。検索フル クロールを負荷テスト中に実行することはあまりありませんが、増分クロールを実行することは普通であると考えられます。運用においてこのようなタスクがどのようにスケジュールされるのか、つまり、負荷のピーク時に実行されるのかを考察する必要があります。負荷のピーク時に実行されない場合でも、トラフィックのピーク時にサポートできる定常状態の負荷の最大値を確認しようとする場合は、負荷テスト中にこれらのタスクを実行することが望ましいと考えられます。

  • 待ち時間は使用しません。待ち時間は、Visual Studio Team System (Team Test Load Agent) の機能の 1 つで、ユーザーがページでクリックしてから次にクリックするまでの時間をシミュレートできます。たとえば、標準的なユーザーは、ページを読み込んだ後に、3 分間ページを読んでからページのリンクをクリックして別のサイトに移動します。この動作のモデルをテスト環境で正確に構築することはほとんど不可能で、実質上、テスト結果の価値を高めることはありません。ほとんどの組織では、さまざまなユーザーを監視したり、そのユーザーがさまざまな種類の SharePoint サイト (発行、検索、グループ作業など) で次にクリックするまでの時間を監視したりすることはできないので、モデルを作成するのは大変です。また、ユーザーはページ要求の間隔をあけることがあっても、SharePoint Server 2010 ベースのサーバーは間隔をあけないので、実際にはこれによる付加価値はありません。サーバーは、時間によって増減することはありますが、絶え間なく続く要求を受け取るだけで、各ユーザーがページのリンクをクリックするまで操作を中断しているときにサーバーは何もしないで待っているわけではありません。

  • ユーザーと要求の違いを理解します。Visual Studio Team System (Team Test Load Agent) には、負荷パターンという機能があり、そこではシミュレートするユーザーの数を入力する必要があります。これは、アプリケーション ユーザーとはまったく関係がありません。これは、要求を生成するために負荷テストで使用する予定のスレッドの数にすぎません。よくある間違いは、たとえば、展開でユーザーが 5,000 人いる場合、5,000 という数値を Visual Studio Team System (Team Test Load Agent) で使用する必要があると考えることです。実際にはそうではありません。これは、容量計画要件を予測するときに使用量の要件は、ユーザーの数ではなく、1 秒あたりの要求の数に基づいて決定する必要がある理由の 1 つです。Visual Studio Team System (Team Test Load Agent) の負荷テストでは、50 ～ 75 人程度の負荷テストの "ユーザー" を使用して 1 秒あたり数百個の要求を生成できることがわかります。

  • 最も確実で再現可能なテスト結果を得るためには、一定の負荷パターンを使用します。Visual Studio Team System (Team Test Load Agent) では、一定数のユーザー (前の項目で説明したとおり、スレッド) に基づいて負荷を決めるのか、ユーザーを段階的に増加する負荷パターンを使用するのか、それとも目標に基づく使用量テストを実行するのかを選択できます。段階的な負荷パターンでは、少数のユーザーから始めて、数分おきにユーザーを追加するように "設定" します。目標に基づく使用量テストでは、CPU 使用率のような特定の診断カウンターに対してしきい値を設定し、テストでは、定義したしきい値の最小値と最大値の間でカウンターが維持されるように負荷を操作します。ただし、SharePoint Server 2010 ファームで負荷のピーク時に維持できる最大スループットを確認する場合は、一定の負荷パターンを選択する方が効果的で正確です。この負荷パターンを使用すると、正常なファームで維持する必要があるしきい値を繰り返し超過し始める前にシステムが耐えられる負荷の量をより簡単に特定できます。

負荷テストを実行するたびに、データベースのデータは変化します。テストで実行する操作 (ドキュメントのアップロード、リスト アイテムの編集、利用状況データベースでのアクティビティの記録など) に関係なく、SQL Server にはデータが書き込まれます。各負荷テストから得られるテスト結果の一貫性と適正さを確保するには、最初の負荷テストを実行する前にバックアップを使用できる状態にする必要があります。各負荷テストが完了した後に、バックアップを使用して、テストを開始する前の状態にコンテンツを戻す必要があります。

See Also

Concepts

SharePoint Server 2010 での容量管理と規模設定の概要
SharePoint Server 2010 の容量計画
SharePoint Server 2010 の監視と保守
正常性の監視 (SharePoint Server 2010)
ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)