共同作業環境のパフォーマンスと容量の要件を見積もる (SharePoint Server 2013)

適用対象:yes-img-13 2013no-img-162016 no-img-192019 no-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

この記事には、SharePoint Server 2013 に基づく部門別 コラボレーション ソリューションのパフォーマンスと容量の計画に関するガイダンスが記載されています。 この記事の内容は次のとおりです。

  • テスト ラボ環境の仕様。ハードウェア、ファーム トポロジと構成など

  • テスト負荷を生成したテスト ファームのワークロードとデータセット

  • 特定の規模の負荷条件におけるスループット、待機時間、およびハードウェアの要件の傾向を実証および説明するテスト結果と分析。

この記事を読むと、通常の負荷およびピーク時の負荷のシナリオの特性や、ファーム サーバーをスケールアウトした場合のパフォーマンス傾向の変化を理解できます。また、計画したアーキテクチャの適切な開始点を見積り、ファームがピーク時の負荷で許容できるレベルのパフォーマンスを維持する計画を立てる際に考慮することを理解する場合にも役立ちます。

概要

この記事では、SharePoint Server 2013 の部門別コラボレーション ソリューションにおいてサーバーをスケールアウトする方法の概要を示します。 部門別コラボレーション ソリューションは、共同アクティビティにおいてエンタープライズ コラボレーション ソリューションよりも使用するコンピューターが少ない SharePoint Server 2013 展開です。 この記事では、部門は、従業員 1,000 ~ 10,000 人の企業内の組織を想定しています。

シナリオによって要件は異なります。 したがって、ご使用のハードウェアおよび環境でさらにテストを行うことでこのガイダンスの内容を補足してください。 計画した設計およびワークロードがこの記事で説明する環境に似ている場合には、ご使用の環境をスケールアップおよびスケールアウトした際のパフォーマンスを推断できます。

重要

この記事に記載されているテスト結果は、高度に制御された条件下で運用環境をシミュレートしたワークロード、データセット、およびアーキテクチャを使用したテスト ラボの結果です。 このテストは慎重に設計されていますが、テスト ラボのパフォーマンス特性は運用環境の動作と同じにはなりません。 このテスト結果は運用ファームのパフォーマンスと容量の特性を表すものではありません。 それよりも、テスト結果は、スループット、待機時間、およびハードウェアの要件の観測傾向を示しています。 実際のファーム容量の計画および管理に役立つ観測データの分析を使用してください。

この記事を読むと次のことを理解できます。

  • 仕様 (ハードウェア、トポロジ、および構成など)

  • ワークロード (ファーム、ユーザー数、使用の特性に関する要件の分析など)

  • データセット (データベースのサイズとコンテンツの種類など)

  • Web サーバーのスケールアウトのためのテスト結果と分析

この記事を読む前に、次の記事を読んで、 SharePoint 2013 SharePoint Server 2013 のソフトウェアの境界と制限の容量管理の背後にある重要な概念を理解していることを確認してください。

用語集

この記事で使用される重要な用語の定義は次のとおりです。

  • RPS: 1 秒あたりの要求数。 RPS はファームまたはサーバーが 1 秒あたりに受信した要求の数です。 これはサーバー負荷とファーム負荷の一般的な計測方法です。

    注:

    要求はページ読み込みとは異なります。 ページにはいくつかのコンポーネントが含まれ、ブラウザーがページを読み込むときに、各コンポーネントは 1 つ以上の要求を生成します。 1 回のページ読み込みで複数の要求が作成されます。 通常、認証チェックと、重要ではないリソースを使用するイベントは、RPS 計測ではカウントされません。

  • グリーン ゾーン: グリーン ゾーンは、予想される日ごとのピーク負荷の範囲内の、通常の運用条件の下で動作している、一連の定義済み負荷特性を表します。 この範囲内で動作するファームは、応答時間と待機時間を許容できるパラメーター内に維持できていると考えることができます。

    以下は、サーバーが次の一連の条件を維持できる状態です。

    • 要求の 75% 以上について、サーバー側の待機時間が 1 秒未満。

    • すべてのファーム サーバーが 60% 未満の平均 CPU 使用率を維持している。

      注:

      ラボ環境でアクティブな検索クロールが実行されませんでした。 そのため、データベース サーバーの CPU 使用率を 50% 以下に抑え、検索クロールの負荷を 10% 確保しました。 ここでは、検索クロールの負荷を 10% CPU に制限するため、運用環境で SQL Server リソース ガバナーが使用されているものとします。

    • 障害発生率が 0.01% 未満。

  • レッド ゾーン (最大): レッド ゾーンは、ピーク時の運用条件の下での一連の定義済み負荷特性を表します。 レッド ゾーンでは、ファームのリソース要件の変動が激しく、障害や、他のパフォーマンスおよび信頼性の問題が発生するまでの限られた期間のみ維持できます。

    これは、サーバーが限られた期間に次の一連の条件を維持できる状態です。

    • HTTP 要求の調整機能は有効だが、503 エラー (サーバー ビジー) が返されない。

    • エラー率が 0 未満です。 1%.

    • 要求の 75% 以上について、サーバー側の待機時間が 3 秒未満。

    • (データベース サーバーを除く) すべてのファーム サーバーが約 90% 未満の平均 CPU 使用率を維持している。

    • データベース サーバーの平均 CPU 使用率が約 50% 未満。これは、検索クロールの負荷を十分に確保できるオーバーヘッドです。

  • AxBxC (グラフの注釈): ファーム内の Web サーバー数、アプリケーション サーバー数、およびデータベース サーバー数をそれぞれ表します。 たとえば、10x1x1 は、環境内に Web サーバーが 10、アプリケーション サーバーが 1、データベース サーバーが 1 あることを示します。

  • MDF と LDF: SQL Server 物理ファイル。 詳細については、「 ファイルとファイル グループのアーキテクチャ」を参照してください。

概要

ここでは、スケーリングのアプローチとテスト手法の概要について説明します。

スケーリングのアプローチ

ここではラボ環境を拡大縮小する際のアプローチについて説明します。 このアプローチを利用すると、実際のワークロードに最適な構成を見つけることができます。

  • 4 つの Web サーバーが使用中になるまで、Web サーバーをスケール アウトしました。 各サーバーは Distributed Cache Service を実行しています。

  • Distributed Cache Service を実行する専用サーバーを追加しました。

  • Web サーバーの Distributed Cache Service を無効にしました。

  • テスト範囲の最大数まで追加の Web サーバーをスケールアウトしました。

手法とテストのメモ

この記事ではテスト ラボ環境の結果を記載しているため、特定の要素を制御して、このワークロードに関するパフォーマンスの特定の側面を示すことができました。 さらに、次の一覧に示されているように、運用環境の一部の要素は、テストのオーバーヘッドを簡略化するために、ラボ環境から除外されています。

注:

運用環境では、これらの要素を含めることをお勧めします。

  • 1 回のテストを実行するたびに、1 つの変数のみを変更し、それぞれのテスト結果を簡単に比較できるようにしました。

  • このテストの目的には、冗長性が不要だったため、データベース サーバーはクラスターに属していませんでした。

  • テスト中は、検索クロールは実行されていませんでした。 当然ながら、運用環境では実行される可能性があります。 この点を考慮に入れるために、「グリーン ゾーン」と「レッド ゾーン」の定義の SQL Server CPU 使用率を下げて、テスト中に検索クロールが通常使用するリソースに合わせました。

仕様

ここでは、テスト ラボ環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。

ハードウェア

ここでは、テスト ラボ環境で使用したハードウェアについて説明します。

重要

Hyper-V ホストを使用してテスト ラボのすべての Web サーバーおよびアプリケーション サーバーを仮想化しています。 データベース サーバーは仮想化されていません。 このセクションでは、物理ホストのハードウェアと仮想マシンの仮想ハードウェアを別々に説明します。

Hyper-V ホスト

まったく同じ構成の 6 台の Hyper-V ホストがテストに使用されています。 各ホストは 1 ~ 2 台の仮想マシンを実行します。

ホスト ハードウェア
プロセッサ
2 クアッドコア 2.49 GHz プロセッサ
RAM
32 GB
オペレーティング システム
Windows Server 2008 R2 SP1
ネットワーク アダプター数
2
ネットワーク アダプターの速度
1 ギガビット

仮想 Web サーバーとアプリケーション サーバー

テスト ファームでは 8 台の仮想 Web サーバーを使用します。 また、Distributed Cache Service を実行する専用仮想サーバーも使用します。

注:

通常、運用環境では、Distributed Cache Service を高可用構成で実行する専用サーバーが展開されます。 テスト ラボ環境では、高可用性は重要な要因ではないため、Distributed Cache 専用として 1 台のサーバーを使用します。

VM ハードウェア WFE1-8 と DC1
プロセッサ
4 つの仮想プロセッサ
RAM
12 GB
オペレーティング システム
Windows Server 2008 R2 SP1
SharePoint ドライブのサイズ
100 GB
ネットワーク アダプター数
2
ネットワーク アダプターの速度
10 ギガビット (ホスト ネットワーク アダプター速度までに制限されたホスト間トラフィック)
認証
Windows NTLM
ロード バランサーの種類
F5 Big IP
ローカルで実行されているサービス
WFE 1-8: Basic Federated Services。 これには、SharePoint Timer Service、Trace Service、Word Automation Services、Excel Services、および Microsoft SharePoint Foundation Sandboxed Code Service が含まれます。
DC1: Distributed Cache Service。

データベース サーバー

テストでは、1 台の物理データベース サーバーを使用し、SharePoint データベースを格納する既定の SQL Server インスタンスを実行しています。 この記事では、ログ データベースは追跡しません。

注:

使用状況レポートを有効にする場合、別の論理ユニット番号 (LUN) にログ データベースを格納することをお勧めします。 大規模な展開および一部の中規模な展開では、ボリュームの大きいログ イベントが発生するプロセッサでの要求に応えるため、専用のログ データベース サーバーが必要となる場合があります。

ラボ環境では、ログ出力は制限され、ログ データベースは別の SQL Server インスタンスに格納されています。

データベース サーバー - 既定のインスタンス SQL Server
プロセッサ
4 クアッドコア 2.4 GHz プロセッサ
RAM
32 GB
オペレーティング システム
Windows Server 2008 R2 SP1
ストレージとジオメトリ
直接接続ストレージ (DAS)
1 x システム ボリューム (RAID0、1 スピンドル、300 GB)
2 x コンテンツ データ ボリューム (RAID0、4 スピンドル、各 450 GB)
2 x コンテンツ ログ ボリューム (RAID0、2 スピンドル、各 450 GB)
1 x 一時データ ボリューム (RAID0、2 スピンドル、各 300 GB)
1 x 一時ログ ボリューム (RAID0、2 スピンドル、各 300 GB)
ネットワーク アダプター数
1
ネットワーク アダプターの速度
1 ギガビット
認証
Windows NTLM
ソフトウェアのバージョン
SQL Server 2008 R2

トポロジ

次の図は、テスト ラボ環境のトポロジを示しています。

テスト ラボ のトポロジは Hyper-V VM を4個もち、それぞれが 2 つの Web サーバーともう 1 つの VM をドメイン コントローラーとしてホストします。物理 DB サーバーは SQL サーバー 2008 R2 SP1 を実行します (1 システム ボリューム、2 コンテンツ データ ボリューム、2 コンテンツ ログ ボリューム、1 temp データ ボリューム、1 temp ログ ボリューム)

構成

次の表は、ラボ環境でデータベース サーバーに対して行った大幅な構成変更を示しています。 これらの構成変更により、最適なテスト パフォーマンスおよびテスト パラメータと結果との間のクリアな関係が得られます。 MAXDOP 設定は、SharePoint Server 2013 で必要になります。 他の設定変更はテスト ラボ環境に対してのみ適用され、ご使用の運用環境には影響されません。

設定 メモ
サイト コレクション
179 (total in environment)
テスト環境のサイト コレクションは、既定の設定と Windows クレーム認証を使用しています。
BLOB キャッシュ
オン
既定ではオフです。 BLOB キャッシュを有効にする場合、ブラウザに頻繁に要求される可能性のある静的なページ リソースについて、データベース サーバーへの呼び出しを減らすことで、サーバーの効率を改善します。
並列処理の最大限度 (MAXDOP)
1
このパラメーターは、SHAREPoint Server 2013 コンテンツ データベースを含む SQL Server インスタンスまたはインスタンスに設定されます。 既定値は 0 です。これにより、SQL Server は並列処理の最大レベルを決定できます。 SharePoint Server 2013 では、SharePoint Server 2013 データベースを含む SQL Server インスタンスの場合、MAXDOP を 1 に設定する必要があります。
SQL Server 2008 R2 の MAXDOP 設定を構成する方法の詳細については、「max degree of parallelism サーバー構成オプションの構成」を参照してください。
SQL Server 2012 の MAXDOP 設定を構成する方法については、「max degree of parallelism サーバー構成オプションの構成」を参照してください。

Workload

ここでは、SharePoint Server 2013 に対して実行したラボ テストについて説明します。 テストの詳細は、部門別コラボレーション環境の一般的なものです。

ラボ テストは SharePoint Server 2013 に対して部門別コラボレーションを実施します。テストの詳細はサーバーに作られた要求を 9 つのシナリオで示します。

データセット

テスト ラボ環境のデータセットは、一般的な部門別コラボレーション環境を示しています。 このデータセットには、多様なサイト コレクション、サイト、リスト、ライブラリ、ファイルの種類、およびファイルのサイズが含まれます。

データセットの特性
データベースのサイズ (合計)
174 GB
MDF のサイズ
154 GB
LDF のサイズ
20 GB
BLOB のサイズ
152 GB
コンテンツ データベース数
2
サイト コレクション数
179
Web アプリケーション数
1
サイト数
1,471

結果と分析

次の結果は、「概要」で説明されているスケーリング アプローチに基づいて並べられています。

Web サーバーのスケールアウト

つぎのセクションでは、テスト ラボ環境の Web サーバー数をスケールアウトしたときに取得したテスト結果について説明します。

テスト手法

  • 同じハードウェア仕様を使用する Web サーバーを追加し、ファームまたはテストのパラメーターを変更せずにテストを再実行します。

  • テスト ファームの各サーバーで RPS、待機時間、およびリソースの使用率を計測します。

分析

テストでは、次の点がわかりました。

  • 環境は 1 つのデータベース サーバーあたり 10 台の Web サーバーまで拡張しました。 スループットは、比較的線形に増加しました。

  • 最大 10 台の Web サーバーのテスト スケールに達したときに、データベース サーバーを追加してもスループットは増えませんでした。 これでボトルネックは、一般的には Web サーバー リソースに限定されました。

  • グリーン ゾーンの平均待機時間は、テスト全体を通してほぼ一定でした。 Web サーバー数とスループットは、グリーン ゾーンの待機時間に影響を与えませんでした。 レッド ゾーンの待機時間データは、予測される傾向線を示します。 1 台の Web サーバーの場合の待機時間は非常に長くなります。 Web サーバーを 2 ~ 8 台にすると、曲線はレッド ゾーンの条件内に十分収まります。

    注:

    Distributed Cache Service をファームの Web サーバーから Distributed Cache 専用のサーバーに移行すると、待機時間の影響をわずかに受ける可能性があります。 これは、各 Web サーバー間でやり取りされていた Distributed Cache トラフィックが、ネットワーク経由になるためです。 実際の環境でスケールアウトのパフォーマンスをテストし、この影響が重大なものかどうかを判断してください。 テスト環境では、Distributed Cache Service を専用サーバーに移行すると、待機時間はわずかに増えました。 名目上の待機時間の増加は、Web サーバーの処理負荷およびメモリ負荷と相殺されるため、Web サーバーが追加されるたびに待機時間は減ります。 > 分散キャッシュの容量計画の詳細については、「 フィードの計画」と「SharePoint Server での分散キャッシュ サービス」を参照してください。

  • SharePoint Server 2013 のキャッシュとデータベースの使用特性が改善されたため、データベース サーバー層の平均負荷が低くなります。 テスト中にデータベース サーバーをスケールアウトする必要がないことがわかりました。

  • ホスト ハードウェア リソース、および同じホストで実行されている他の仮想コンピューターのリソースの使用率に部分的に依存する仮想 Web サーバーを追加すると、パフォーマンスが改善されます。 仮想サーバーには、仮想化に固有の計画および管理戦略を追加する必要があります。

    Hyper-V のパフォーマンスと容量の計画の詳細については、「 SharePoint 2013 の Hyper-V 仮想化要件 」および「 SharePoint 2013 仮想マシンと Hyper-V 環境のベスト プラクティス構成を使用する」を参照してください。

注:

このセクションでの結論は、環境を構成しているハードウェアに固有のものです。 この環境がより多数の低機能 Hyper-V ホスト サーバーを使用する、またはより少ない数の高機能 Hyper-V ホスト サーバーを使用する場合、同じスループットを達成できた可能性があります。 データベース サーバーのハードウェア リソースを増やしても、結果に大きな影響はありません。

結果、グラフ、および図表

次のグラフの X 軸は、ファーム内の Web サーバー数の変化を示しています。 目盛りは 1 つの仮想 Web サーバーと 1 つの物理データベース サーバー (1x1) から始まります。 最大で、8 台の仮想 Web サーバー、1 台の専用仮想 Distributed Cache サーバー (Web サーバーが 4 台になると追加される)、1 台の物理データベース サーバー (18x1x1) です。

注:

このセクションのグラフは、テスト期間中の各データ ポイントの平均値を示しています。 すべてのグラフには、グリーン ゾーンとレッド ゾーン両方の RPS 基準が含まれており、RPS と要因 (待機時間、サーバー リソースの使用率、SQL Server ディスクの使用状況など) の関係を示しています。

1. RPS

次のグラフは、スケールアウトが RPS 基準に与える影響を示しています。

図のイラストは、フロントエンド Web サーバーとドメイン コントローラーがスケール アウトするにつれ、1 秒ごとのリクエストが増加することを表します

2. 待機時間

次のグラフは、スケールアウトが待機時間に与える影響を示しています。 グリーン ゾーンの待機時間は、ほぼ平坦なままですが、レッド ゾーンの待機時間は許容可能な制限内で増えています。

フロントエンド Web サーバーとドメイン コントローラーのスケール アウトは待機時間に影響を及ぼします。グリーン ゾーンはフラットのままですが、レッド ゾーンは変動を示します。

3. Web サーバー プロセッサとメモリの使用率

次のグラフは、スケールアウトが Web サーバーのプロセッサとメモリの平均使用率に与える影響を示しています。 グリーン ゾーンのプロセッサ使用率および平均メモリ使用率は RPS が増加しても比較的平坦なままです。

レッド ゾーンのプロセッサ使用率は下降傾向です。 これは、サーバー数が増えるにつれて、最大負荷の Web サーバーのプロセッサにかかる平均負荷が徐々に減るためです。

図は、スケール アウトのフロントエンド Web サーバー が プロセッサおよびメモリ使用量に影響を与えるかを示します。グリーン ゾーンでは、1秒ごとのリクエストがコンスタントに続き、メモリ使用量は増加します。レッド ゾーンは減少を示し、サーバーが追加されたときにサーバー プロセッサへの要求が減少します。

4. SQL Server の IOPS (1 秒あたりの I/O 操作数) とプロセッサ使用率

次のグラフは、Web サーバー数のスケール アウトに従って、平均ディスク IOPS (合計と読み取り/書き込みの両方) およびプロセッサ使用率の値がどのように変化するかを示しています。IOPS の値を測定するために、次のパフォーマンス カウンターを使用しています。

  • PhysicalDisk: 1 秒あたりのディスクの読み取り

  • PhysicalDisk: 1 秒あたりのディスクの書き込み

テスト期間中の各カウンターの値は平均化され、その合計により、IOPS 合計が算出されます。

注:

SQL Server のメモリ使用率のデータをテストの際に入手できなかったため、このデータはグラフに含まれていません。

重要

テスト環境のデータセットは運用ファームのデータセットよりもかなり小規模なので、これらの IOPS テスト結果は運用環境の結果とは異なります。 そのため、運用環境よりも、Web サーバーでキャッシュされるデータの割合が多くなる可能性があります。 Web サーバーに大部分のデータをキャッシュしたため、このセクションの IOPS の結果は、使用できるテスト データに基づいて算出された平均値です。 ここでの IOPS の結果は、一般的に、運用環境の IOPS よりも低いと予想されます。 パイロット環境で実際のファームの詳細なテストを実行すると、別の結果になる可能性があります。

このセクションのグラフでは、6 台のフロントエンド Web サーバーで IOPS とデータベース サーバー プロセッサの使用率が低下しますが、RPS は増加し続けます。 以前のグラフで示したように、この変化は Web サーバー プロセッサの使用率にも反映されます。

これは、ファームのスケールが、基準の負荷とデータセットを使用して達成されたファーム サーバー リソースの最高レベルの負荷に達したことを示します。 ファームの負荷に対応するには、サーバー リソースの平均使用率を低くする必要があります。

この傾向から、次のように結論を下すことができます。

  • 6 台の Web サーバーの規模でテストの負荷を増やすと、RPS は達成されるが、サーバー リソースの使用率の曲線は平坦なままである。

  • Web サーバー数をさらにスケールアウトし、同じテスト負荷を維持した場合、RPS は増え続け、サーバー リソースへの負荷は引き続き下降傾向になる。

  1. SQL Server の合計 IOPS

    次のグラフは、スケールアウトが合計 IOP に与える影響を示しています。

    図はグリーン および レッド ゾーンへの SQL サーバーの合計 IOP を表します。両ゾーンは最大 4 フロントエンド Web サーバーまで増加し、水平になった後、8 web サーバーで次第に減少します。

  2. 読み取り操作と書き込み操作に分類された SQL Server の IOPS

    次のグラフは、スケールアウトが IOPS に与える影響を、1 秒あたりの読み取りと 1 秒あたりの書き込みについて示しています。

    図は、スケール アウトのフロントエンド Web サーバー が 1 秒ごとの読み取りおよび書き込みで、どのように IOP に影響を及ぼすかを示します。1 秒ごとの読み込みおよび書き込みの傾向 は 4 フロントエンド Web サーバーまで増加し、その後 1 秒ごとの読み取りは次第に減少する一方、1秒ごとの書き込みは増加し続けます。

  3. SQL Server のプロセッサ使用率

    次のグラフは、スケールアウトが SQL Server のプロセッサ使用率に与える影響を示しています。

    図のイラストは SQL プロセッサを表し、より多くのサーバーが追加されるにつれて 1 秒ごとの読み取りの傾向が上昇することを示します

関連項目

概念

SharePoint Server 2013 の計画、パフォーマンスを計画します。

パフォーマンスと容量テストの結果および推奨事項 (SharePoint Server 2013)

エンタープライズ イントラネット コラボレーション環境のパフォーマンスと容量の要件を見積もる (SharePoint Server 2013)