SharePoint Server 2013 のパフォーマンス テスト
適用対象:
2016 2019 Subscription Edition SharePoint in Microsoft 365
この記事では、SharePoint Server 2013 のパフォーマンスをテストする方法について説明します。 テストと最適化の段階は、効果的な容量管理の重要なコンポーネントです。 新しいアーキテクチャを運用環境にデプロイする前にテストする必要があります。また、設計するアーキテクチャがパフォーマンスと容量の目標を確実に達成できるように、次の監視のベスト プラクティスを使用して受け入れテストを実施する必要があります。 これにより、ライブ デプロイのユーザーに影響を与える前に、潜在的なボトルネックを特定して最適化できます。 Office SharePoint Server 2007 環境からアップグレードし、アーキテクチャの変更を計画している場合、または新しい SharePoint Server 2013 機能のユーザー負荷を見積もる場合は、新しい SharePoint Server 2013 ベースの環境がパフォーマンスと容量の目標を満たしていることを確認するために特に重要なテストを行います。
環境のテストが完了すると、テスト結果を分析し、「SharePoint Server 2013 の容量計画」の「ステップ 1: モデル化」で確立したパフォーマンスと容量の目標を達成するために加える必要のある変更を確認できます。
以下の手順は、運用前に実行する必要のある推奨補助手順です。
「ステップ 2: 設計」で設計した初期のアーキテクチャを模倣するテスト環境を作成します。
ステップ 1: モデル化で特定したデータセットまたはデータセットの一部でストレージを構成します。
ステップ 1: モデル化で特定したワークロードに相当する合成負荷をシステムに加えます。
テストを実施して、結果を分析し、アーキテクチャを最適化します。
最適化したアーキテクチャをデータ センターで展開し、小さいユーザー セットを使用してパイロットをロールアウトします。
パイロットの結果を分析し、潜在的なボトルネックを特定して、アーキテクチャを最適化します。 必要に応じて、再テストを実行します。
運用環境に展開します。
この記事を読む前に、「Capacity management and sizing overview for SharePoint Server 2013」を読む必要があります。
テスト計画を作成する
計画に次の項目が入っていることを確認します。
想定した運用時のパフォーマンスの目標値で動作するように設計されたハードウェア。 テスト システムのパフォーマンスは常に控えめに測定します。
カスタム コードまたはカスタム コンポーネントがある場合は、最初にそのコンポーネントを隔離した状態でそのパフォーマンスをテストし、パフォーマンスと安定性を検証することが重要です。 コンポーネントが安定した後で、そのコンポーネントをインストールしたシステムをテストし、インストールしていない状態のファームとパフォーマンスを比較する必要があります。 運用システムで発生するパフォーマンスと信頼性の問題の主な原因の多くは、カスタム コンポーネントです。
テストの目標を把握します。 テストの目的が何であるかを事前に理解します。 ファーム用に開発された新しいカスタム コンポーネントのパフォーマンスを検証する目的ですか? コンテンツのセットのクロールとインデックス作成にかかる時間を確認するには、 ファームでサポートできる要求の数を 1 秒あたりに決定するかどうか。 テスト中にはさまざまな目的が存在する可能性があり、適切なテスト 計画を開発する最初の手順は、目的を決定することです。
テストの目標を測定する方法を理解します。 たとえば、ファームのスループット容量の測定に関心がある場合は、RPS とページ待機時間を測定します。 検索パフォーマンスを測定する場合は、クロール時間とドキュメントのインデックス作成率を測定する必要があります。 テストの目標をよく理解すると、テストを完了するために検証する必要がある主要業績評価目標を明確に定義しやすくなります。
テスト環境を作成する
テスト目標が決定されると、測定値が定義され、ファームの容量要件 (このプロセスの手順 1 と 2 から) が決定されたら、次の目的はテスト環境を設計して作成することです。 テスト環境を作成する作業は、多くの場合、過小評価されます。 運用環境は可能な限り密接に複製する必要があります。 テスト環境の設計時に考慮する必要がある機能には、次のようなものがあります。
認証: ファームで使用する認証 (Active Directory ドメイン サービス (AD DS)、フォーム ベース認証 (および使用するディレクトリ)、クレーム ベース認証など) を決定します。 使用しているディレクトリに関係なく、テスト環境に必要なユーザーの数、作成する予定のユーザーの数、必要なグループまたはロールの数、およびそれらを作成し事前設定する方法を確認します。 また、認証サービスがテスト中にボトルネックにならないように十分なリソースがそのサービスに割り当てられていることを確認する必要があります。
DNS: テスト時に必要な名前空間を確認します。 要求に応答するサーバーを特定し、各サーバーが使用する IP アドレスおよび作成する必要がある DNS エントリが計画に追加されていることを確認します。
負荷分散: 複数のサーバー (通常はロード テストを保証するのに十分な負荷がない可能性がある) を使用していると仮定すると、何らかのロード バランサー ソリューションが必要になります。 これは、ハードウェア負荷分散デバイスである場合や、Windows NLB などのソフトウェア負荷分散を使用することもできます。 使用する内容を把握し、迅速かつ効率的に設定するために必要なすべての構成情報を書き留めておきます。 もう 1 つの注意点は、ロード テスト エージェントは通常、アドレスを 30 分に 1 回だけ URL に解決しようとすることです。 つまり、ロード バランシングにはローカル ホスト ファイルまたはラウンド ロビン DNS を使用しないでください。テスト エージェントは、使用可能なすべてのサーバーのバランスを取るのではなく、1 つの要求ごとに同じサーバーに移動する可能性があるためです。
テスト サーバー: テスト環境を計画するときは、SharePoint Server 2013 ファームのサーバーを計画する必要があるだけでなく、テストの実行に必要なマシンの計画も必要です。 通常、少なくとも 3 つのサーバーが含まれます。より多くのが必要な場合があります。 Visual Studio Team System (Team Test Load Agent) を使用してテストを実行している場合、ロード テスト コントローラーとして 1 台のマシンが使用されます。 一般に、ロード テスト エージェントとして使用されるマシンは 2 つ以上あります。 エージェントは、テスト対象についてテスト コントローラーから指示を受け取り、SharePoint Server 2013 ファームに要求を発行するマシンです。 テスト結果自体は、SQL Server ベースのコンピューターに格納されます。 テスト データを記述すると、SharePoint Server 2013 ファームで使用可能なSQL Server リソースが傾斜するため、SharePoint Server 2016 ファームで使用されるのと同じSQL Server ベースのコンピューターを使用しないでください。 また、SharePoint Server 2013 ファーム内のサーバーやドメイン コントローラーなどを監視するのと同じ方法で、テストを実行するときにテスト サーバーを監視する必要もあります。テスト結果が、設定しているファームの代表であることを確認します。 場合によっては、ロード エージェントまたはコントローラー自体がボトルネックになることがあります。 その場合、スループットは、通常、ファームでサポートできる最大ではありません。
SQL Server: テスト環境では、記事「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)」のセクション「SQL Server を構成する」と「ストレージと SQL Server のパフォーマンスを検証し監視する」に記載されているガイダンスに従って操作を実行します。
データセットの検証: 既存の運用システムからのデータを使用することが最高条件のシナリオであることを念頭に置いて、テスト対象のコンテンツを決定します。 たとえば、運用ファームからコンテンツ データベースをバックアップしてそれをテスト環境で復元し、データベースをアタッチしてコンテンツをファームに展開できます。 架空のデータまたはサンプル データに対してテストを実行するときは常に、コンテンツ コーパスの相違が原因で、結果が偏る可能性があります。
サンプル データを作成する必要がある場合は、次の点に注意してコンテンツを構築します。
すべてのページは発行する必要があります。ページはチェックアウトしないでください。
ナビゲーションは実際の環境に即したものにする必要があります。運用において使用することが予想されるナビゲーション以上のものを構築しないでください。
運用サイトで使用される予定のカスタマイズを予測する必要があります。 たとえば、マスター ページ、スタイル シート、JavaScript など、該当するすべてのものをできるだけ運用環境に近い形でテスト環境に実装する必要があります。
必要な SharePoint グループまたはアクセス許可レベルの数、およびユーザーに関連付ける方法を決定します。
プロファイルをインポートする必要があるかどうか、インポートにかかる時間を確認します。
対象ユーザーが必要かどうか、また対象ユーザーをどのように作成して設定するかを決定します。
追加の検索コンテンツ ソースが必要かどうかを判断し、その検索コンテンツ ソースを作成するのに必要な材料を確認します。 作成する必要がない場合は、検索コンテンツ ソースをクロールできるネットワーク アクセスがあるかどうかを確認します。
ドキュメント、リスト、リスト アイテムなど、十分な量のサンプル データがあるかどうかを確認します。ない場合、このコンテンツを作成する方法について計画します。
検索を適切にテストできるようにさまざまなコンテンツを用意することを計画します。 よくある間違いは、同じドキュメントを、何百回、何千回と異なるドキュメント ライブラリに毎回別の名前でアップロードすることです。 この場合、運用環境の実際のコンテンツでは行う必要がない重複データの検出にクエリ プロセッサが大量の時間を費やすので、検索パフォーマンスに影響する可能性があります。
テストとツールを作成する
テスト環境を動作可能な状態にした後で、ファームのパフォーマンスと容量の測定に使用するテストを作成し、調整します。 ここでは、何度か Visual Studio Team System (Team Test Load Agent) について触れていますが、概念の多くは、どの負荷テスト ツールを使用している場合でも当てはまります。 Azure DevOps (旧称 VSTS) で使用できるテスト ツールの詳細については、「 Azure DevOps の DevOps ツールの概要」を参照してください。
SharePoint 2010 ファームのロード テストには、VSTS で SharePoint ロード テスト キット (LTK) を使用することもできます。 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 に対する人工的な負荷を生成できます。
ロード テスト キットは、Microsoft ダウンロード センターから入手できる Microsoft SharePoint 2010 管理ツールキット v2.0 に含まれています。
テストを成功させるための主な条件は、ユーザーが SharePoint Server 2013 運用ファームで広範囲のコンテンツにアクセスするのと同様に、広範囲のテスト サイトのデータに対して要求を生成することで、現実に即した負荷を効果的にシミュレートできることです。 これを実現するには、通常、データ ドリブン テストになるようにテストを構築する必要があります。 ハードコードされた個別のテストを何百個も作成して特定のページにアクセスするのではなく、アイテムの URL を含んでいるデータ ソースを使用する少数のテストを使用して、その一連のページに動的にアクセスする必要があります。
Visual Studio Team System (Team Test Load Agent) では、さまざまな形式のデータ ソースを処理できますが、ほとんどの場合、最も簡単に管理でき、開発環境とテスト環境の間を移動できるのは CSV ファイル形式です。 コンテンツを含んだ CSV ファイルを作成すると、場合によっては、SharePoint Server 2013 ベースの環境を列挙し、使用されているさまざまな URL を記録するためのカスタム ツールを作成する必要があります。
ツールを使用する必要があるのは、次のような作業です。
Active Directory で、またはフォーム ベース認証を使用している場合はその他の認証ストアでユーザーとグループを作成する。
サイト、リストとライブラリ、リスト アイテム、ドキュメントの URL を列挙し、負荷テスト用の CSV ファイルにその URL を入力する。
さまざまなドキュメント ライブラリとサイトにサンプル ドキュメントをアップロードする。
サイト コレクション、Web、リスト、ライブラリ、フォルダー、およびリスト アイテムを作成する。
個人用サイトを作成する。
テスト ユーザーのユーザー名とパスワードを使用して CSV ファイルを作成する。これらは、ロード テストで実行されるユーザー アカウントです。 たとえば、管理者ユーザーのみを含むファイルもあれば、管理者特権を持つ他のユーザー (作成者/共同作成者、階層マネージャーなど) が含まれているファイルもあれば、リーダーのみのファイルもあります。
検索キーワードと語句のサンプルのリストを作成する。
ユーザーと Active Directory グループ (または、フォーム ベース認証を使用している場合はロール) を使用して SharePoint グループとアクセス許可レベルを設定する。
Web テストを作成するときは、他にも、観察して実装する必要があるベスト プラクティスがあります。 これには、次のものが含まれます。
単純な Web テストを出発点として記録します。 これらのテストには、URL、ID などのパラメーターのハードコーディングされた値が含まれます。これらのハードコーディングされた値を CSV ファイルからのリンクに置き換えます。 Visual Studio Team System (チーム テスト ロード エージェント) でこれらの値をバインドするデータは非常に簡単です。
テストの検証規則は常に持っています。 たとえば、ページを要求するときに、エラーが発生した場合、多くの場合、応答として error.aspx ページが表示されます。 Web テストの観点からは、ロード テストの結果で 200 (成功) の HTTP 状態コードを取得するため、もう 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 2013 ベースの環境に展開された SQL Server から提供されません。 BLOB キャッシュを有効にしている場合、これらのアイテムは、Web サーバーによって提供されるので、SQL Server に負荷はかかりません。
サイトへの初めてのユーザーの割合が頻繁に高い場合、またはブラウザーのキャッシュを無効にしている場合、または何らかの理由で BLOB キャッシュを使用しない場合は、テストで依存する要求の解析を有効にすることが理にかなっている可能性があります。 しかし、これは実際には例外であり、ほとんどの実装の経験則ではありません。 これをオンにすると、テスト コントローラーによって報告される RPS 番号が大幅に膨らむ可能性があることに注意してください。 これらの要求は迅速に提供されるため、実際よりもファームで利用できる容量が多いと誤解される可能性があります。
クライアント アプリケーション アクティビティもモデル化してください。 Microsoft Word、PowerPoint、Excel、Outlook などのクライアント アプリケーションでは、SharePoint Server 2013 ファームへの要求も生成されます。 RSS フィードの取得、ソーシャル情報の取得、サイトとリストの構造の詳細の要求、データの同期などのサーバー要求を送信することで、環境に負荷を追加します。実装にこれらのクライアントがある場合は、これらの種類の要求を含め、モデル化する必要があります。
ほとんどの場合、1 つの Web テストには 1 つの要求だけを追加する必要があります。 テストで指定されている要求が 1 つだけの場合、テスト装置と各要求の調整およびトラブルシューティングを簡単に実行できます。 Web テストでは、通常、シミュレートする操作が複数の要求で構成される場合は、複数の要求を入れる必要があります。 たとえば、一連の動作をテストするには、ドキュメントのチェックアウト、ドキュメントの編集、ドキュメントのチェックイン、およびドキュメントの発行という複数の手順で構成されたテストが必要です。 また、同じユーザー アカウントを使用してチェックアウト、編集、再チェックインを実行するというように手順間の状態を維持する必要もあります。 各手順間で状態を維持する必要があり、複数手順で構成される操作は、1 つの Web テストで複数の要求を実行することで最適な結果を得ることができます。
各 Web テストを個別にテストします。 各テストは、大規模な負荷テストで実行する前に正常に完了できることを確認します。 Web アプリケーションのすべての名前が解決でき、テストで使用するユーザー アカウントにテストを実行できるだけの十分な権限があることを確認します。
Web テストは、個々のページの要求、ドキュメントのアップロード、リスト アイテムの表示などを構成します。これらはすべてロード テストでまとめます。 ロード テストとは、実行されるさまざまな Web テストをすべてプラグインする場所です。 各 Web テストには、実行される時間の割合を指定できます。たとえば、運用ファームの要求の 10% が検索クエリである場合、ロード テストでは、10% の時間を実行するようにクエリ Web テストを構成します。 Visual Studio Team System (Team Test Load Agent) では、ロード テストは、ブラウザー ミックス、ネットワーク ミックス、読み込みパターン、実行設定などを構成する方法でもあります。
負荷テストでは、次のその他のベスト プラクティスに注意し、実装することをお勧めします。
テスト内で適切な読み取り/書き込み比率を使用します。 テスト内で書き込み数の負荷が大きすぎると、テストの全体のスループットに大きな影響を与える場合があります。 コラボレーション ファームでも、読み取り/書き込み比率では書き込みより読み取りの方が多い傾向にあります。
その他の大量のリソースを使用する操作の影響を考慮し、その操作を負荷テスト中に実行するかどうかを判断します。 たとえば、バックアップと復元のような操作は、通常は、負荷テスト中に実行しません。 検索フル クロールを負荷テスト中に実行することはあまりありませんが、増分クロールを実行することは普通であると考えられます。 運用においてこのようなタスクがどのようにスケジュールされるのか、つまり、負荷のピーク時に実行されるのかを考察する必要があります。 負荷のピーク時に実行されない場合でも、トラフィックのピーク時にサポートできる定常状態の負荷の最大値を確認しようとする場合は、負荷テスト中にこれらのタスクを実行することが望ましいと考えられます。
待ち時間は使用しません。 待ち時間は、Visual Studio Team System (Team Test Load Agent) の機能の 1 つで、ユーザーがページでクリックしてから次にクリックするまでの時間をシミュレートできます。 たとえば、標準的なユーザーは、ページを読み込んだ後に、3 分間ページを読んでからページのリンクをクリックして別のサイトに移動します。 この動作のモデルをテスト環境で正確に構築することはほとんど不可能で、実質上、テスト結果の価値を高めることはありません。 ほとんどの組織では、さまざまなユーザーを監視したり、そのユーザーがさまざまな種類の SharePoint サイト (発行、検索、グループ作業など) で次にクリックするまでの時間を監視したりすることはできないので、モデルを作成するのは大変です。 また、ユーザーはページ要求の間隔をあけることがあっても、SharePoint Server 2013 ベースのサーバーは間隔をあけないので、実際にはこれによる付加価値はありません。 サーバーは、時間によって増減することはありますが、絶え間なく続く要求を受け取るだけで、各ユーザーがページのリンクをクリックするまで操作を中断しているときにサーバーは何もしないで待っているわけではありません。
ユーザーと要求の違いを理解します。 Visual Studio Team System (Team Test Load Agent) には、シミュレートするユーザーの数を入力するように求める読み込みパターンがあります。 これはアプリケーション ユーザーとは関係ありません。実際には、ロード テスト エージェントで要求を生成するために使用されるスレッドの数だけです。 一般的な間違いは、たとえば、デプロイに 5,000 人のユーザーがいる場合、5,000 人が Visual Studio Team System (チーム テスト ロード エージェント) で使用する必要がある数値であると考えていることです。 これは、容量計画の要件を見積もるときに、使用要件がユーザー数ではなく、1 秒あたりの要求数に基づいている必要がある多くの理由の 1 つです。 Visual Studio Team System (Team Test Load Agent) ロード テストでは、多くの場合、50 から 75 のロード テスト "ユーザー" のみを使用して、1 秒あたり何百もの要求を生成できます。
最も確実で再現可能なテスト結果を得るためには、一定の負荷パターンを使用します。 Visual Studio Team System (Team Test Load Agent) では、一定の数のユーザー (前のポイントで説明したようにスレッド)、ユーザーのステップアップ ロード パターン、または目標ベースの使用状況テストに負荷を基にすることもできます。 段階的な負荷パターンでは、少数のユーザーから始めて、数分おきにユーザーを追加するように "設定" します。 目標に基づく使用量テストでは、CPU 使用率のような特定の診断カウンターに対してしきい値を設定し、テストでは、定義したしきい値の最小値と最大値の間でカウンターが維持されるように負荷を操作します。 ただし、SharePoint Server 2013 ファームで負荷のピーク時に維持できる最大スループットを確認する場合は、一定の負荷パターンを選択する方が効果的で正確です。 この負荷パターンを使用すると、正常なファームで維持する必要があるしきい値を繰り返し超過し始める前にシステムが耐えられる負荷の量をより簡単に特定できます。
負荷テストを実行するたびに、データベースのデータは変化します。 テストで実行する操作 (ドキュメントのアップロード、リスト アイテムの編集、利用状況データベースでのアクティビティの記録など) に関係なく、SQL Server にはデータが書き込まれます。 各負荷テストから得られるテスト結果の一貫性と適正さを確保するには、最初の負荷テストを実行する前にバックアップを使用できる状態にする必要があります。 各ロード テストが完了したら、バックアップを使用してコンテンツを元の状態に戻す必要があります。これはテストが開始される前でした。
関連項目
概念
SharePoint Server 2013 の監視とメンテナンス
ソフトウェアの境界と制限 (SharePoint Server 2016)
その他のリソース
Capacity management and sizing overview for SharePoint Server 2013