Microsoft SharePoint Server 2010 ベースの部
門別ポータルのキャパシティプランニングとサイズ変更
このドキュメントは現状有姿で提供され、このドキュメント (URL などのインターネット Web サイトにある参照先を 含む) に記載されている情報および見解は、将来予告なしに変更することがあります。これを使用する責任はお客 様ご自身にあります。 このドキュメントに記載されている例の一部は、例示のみを目的としており、架空のものです。実在する事物とは一 切関係ありません。 このドキュメントは、あらゆるマイクロソフト製品に対する何らかの知的財産権をお客様に付与するものではありませ ん。このドキュメントは、内部的な参照目的にのみコピーおよび使用することができます。Microsoft SharePoint Server 2010 ベースの部
門別ポータルのキャパシティプランニングとサイズ変更
Gaurav Doshi、Raj Dhrolia、Wayne RoseberryMicrosoft Corporation 2010 年 2 月
適用 : Office SharePoint Server 2010
概要 : このホワイト ペーパーは、SharePoint Server 2010 ベースの部門別ポータルのパフォーマンスとキャパシティプランニングの ガイダンスを提供します。 ハードウェア、ファーム トポロジ、構成などのテスト環境の仕様 テスト ファームのデータ セット 類似した環境を展開するために必要なハードウェア、トポロジ、構成を決定する方法と、適切な処理能力とパフォーマンス 特性を得るために環境を最適化する方法に関するテスト データと推奨事項
目次
はじめに ... 4 シナリオ ... 4 仮定と前提条件 ... 4 テストのセットアップ ... 6 ハードウェア ... 6 ソフトウェア ... 6 トポロジと構成 ... 7 データ セットとディスク ジオメトリ ... 7 トランザクション ミックス ... 8 結果と分析 ... 10 テストの手法 ... 10 反復の結果 (1 X 1、1 X 1 X 1、2 X 1 X 1、3 X 1 X 1) ... 11 1 X 1 ファーム構成 ... 11 1 X 1 X 1 ファーム構成 ... 12 2 X 1 X 1 ファーム構成 ... 14 3 X 1 X 1 ファーム構成 ... 16 比較 ... 18 検索増分クロールを使用したテスト ... 20 結果と推奨事項のまとめ ... 21はじめに
シナリオ
このドキュメントは、典型的な部門別ポータルのキャパシティプランニングについて、そのガイダンスを提供するためのテスト の手法と結果の概要を示します。部門別ポータルは、主にチームで共同作業と何らかのコンテンツ公開を行う Microsoft® SharePoint® Server 2010 展開の 1 つの方法です。このドキュメントの “部門” とは、従業員が
1,000 ～ 10,000 人の会社内の 1 つの組織を仮定しています。 シナリオが変われば要件も異なるため、実際のハードウェアと環境で追加のテストを行って、このガイダンスを補完すること が重要です。 このドキュメントを読み終わると、次の方法を理解できます。 必要な規模のユーザー数、負荷、および有効にする機能をサポートするために必要なハードウェアの見積もり 最適な信頼性と効率性を備えた物理的論理的トポロジの設計。（高可用性/障害回復については、このド キュメントではカバーしていません。 ） 部門別ポータル展開の RPS に対する進行中の検索クロールの影響 このドキュメントを読む前に、次の内容 (英語) を読む必要があります。
『Capacity Planning and Sizing for Microsoft SharePoint 2010 Products and Technologies (Microsoft SharePoint 2010 製品とテクノロジの処理能力の計画とサイズ)』
『Office SharePoint Server 2010 Software Boundaries (Office SharePoint Server 2010 ソ フトウェアの制限)』
また、次も参照することをお勧めします。
「Performance and capacity technical case studies (パフォーマンスと処理能力の技術ケース スタ ディ)」ページ (http://technet.microsoft.com/en-us/library/cc261716(office.14).aspx、英 語) にある『Microsoft SharePoint Server 2010 Departmental Collaboration Environment (Microsoft SharePoint Server 2010 部門コラボレーション環境)』ドキュメント (英語)
仮定と前提条件
このテストでは、ディスク I/O を制限要素と見なしません。利用できるスピンドルの数は無限であることを前提と します。 テストは、典型的な部門別ポータルのピーク時の使用状況のみをモデリングしています。昼夜のサイクルで見ら れるようなトラフィックの周期的な変化は考慮していません。したがって、一般には夜に実行するようにスケジュー ルされるタイマー ジョブも、トランザクション ミックスには含まれていません。 この場合は、部門別ポータル展開で実行されるカスタム コードはありません。部門別ポータルにインストールされ るカスタム コードやサード パーティ ソリューションの動作は保証されません。 テストを目的としているため、すべてのサービス DB とコンテンツ DB は、Microsoft SQL Server® の同じイ ンスタンスに置かれています。また、使用 DB は、別の SQL Server インスタンスで管理されます。 テストを目的としているため、BLOB キャッシュは有効になっています。 認証モードは NTLM です。 このテストでは、検索クロールのトラフィックは考慮されていません。ただし、進行中の検索クロールの影響を織り 込むために、健全なファームの定義を変更しました。検索クロールの負荷を 10% と見なして、SQL Server のグリーン ゾーンを 40% と定義しました。同様に、最大 RPS の基準として、SQL Server CPU の 80% を使用しました。
テストのセットアップ
ハードウェア
次の表に、このテストで使用したコンピューターのハードウェア仕様を示します。テストを何回か反復する間にサーバー ファ ームに追加されるフロントエンド Web サーバーは、それぞれ同じ仕様に従います。フロントエンド Web
サーバー
アプリケーション
サーバー
データベース サーバー
サーバー モデル
PE 2950 PE 2950 Dell PE 6850プロセッサ
[email protected] [email protected] 4px4c@ 3.19GHzRAM
8 GB 8 GB 32 GBNIC の数
2 2 1NIC 速度
1 ギガビット 1 ギガビット 1 ギガビットロード バランサーの種類
F5 - ハードウェア ロー ド バランサー 該当なし 該当なしULS ログ レベル
ミディアム ミディアム 該当なし 表 1: サーバー コンピューターのハードウェア仕様ソフトウェア
次の表に、このテスト作業で使用したサーバーにインストールされて実行されたソフトウェアの仕様を示します。フロントエンド Web
サーバー
アプリケーション サーバー データベース サーバー
オペレーティング
システム
Windows Server® 2008 R2 x64 Windows Server 2008 R2 x64 Windows Server 2008 x64ソフトウェア
バージョン
Microsoft SharePoint 4733.1000、WAC 4733.1000 Microsoft SharePoint 4733.1000、WAC 4733.1000 SQL Server 2008 R2 CTP3ロード バランサー
の種類
F5 - ハードウェア ロード バランサー 該当なし 該当なしULS ログ レベル
ミディアム ミディアム 該当なしウイルス対策
設定
無効 無効 無効 表 2: サーバー コンピューターのソフトウェア仕様トポロジと構成
次のトポロジの図は、テストに使用したハードウェア設定を示します。テストを反復する間にフロントエンド Web サーバー の数を 1 から 2、3 へと変更しましたが、それ以外のトポロジは同じです。 図 1: ファームの構成 テスト環境に設定したサービスについては、上の図を参照してください。ユーザー プロファイル サービスや Web 解析など のその他のサービスは設定していません。データ セットとディスク ジオメトリ
テスト ファームには、約 1.62 テラバイトのコンテンツが、異なるサイズの 5 つのコンテンツ データベースに分散して配置さ れました。次の表に、データの分散方法を示します。 コンテンツ DB # 1 2 3 4 5 コンテンツ DB サイズ 36 GB 135 GB 175 GB 1.2 TB 75 GB サイトの数 44 74 9 9 222 Web の数 1544 2308 2242 2041 1178 RAID の構成 0 0 0 0 0MDF のスピンド ルの数 1 1 5 3 1 LDF のスピンドル の数 1 1 1 1 1 表 3: データ セットとディスク ジオメトリ
トランザクション ミックス
重要事項 この部門別ポータルでは、個人用サイトを設定していません。個人用サイトをサポートするユーザー プロファイル サービスもファームで実行されません。個人サイト ページ/Web サービスのヒットまたは Outlook Social Connector に関連するトラフィックは、トランザクション ミックスに含まれません。 ドキュメントの共同作成によって生成されるトラフィックは、テスト ミックスに含まれません。
検索クロールのトラフィックは、テスト ミックスに含まれません。ただし、検索クロール用に 10% の余裕を見て、 SQL Server CPU 使用率のグリーン ゾーンの定義を標準の 50% から 40% に変更したため、クロールは テストに織り込まれています。同様に、MAX RPS の基準として、SQL Server CPU の 80% を使用しまし た。 次の表に、トランザクション ミックスの概要を示します。 機能/サービス 操作 read/write ミックス内の 割合 ECM 静的ファイルの取得 R 8.93% ホーム ページの表示 R 1.52% Microsoft Infopath® アップサイズ リスト項目と新しいフォームの表示/編集 R 0.32% [名前を付けて保存] を使用したファイルのダウンロード R 1.39% Microsoft
OneNote® Office 12 OneNote ファイルを開く R 13.04%
検索
このサイト、このリスト（OSSSearch.aspx） または
Search Center からの検索 R 4.11%
ワークフロー 自動起動ワークフローの開始 W 0.35%
Microsoft
Visio® PNG/XAML での VISIO ファイルの表示 R 0.90%
Office Web App - PowerPoint
Microsoft PowerPoint® を表示、6 枚目のスライドにス
クロール R 0.05%
Office Web App - Word
PNG/Silverlight での Microsoft Word ドキュメントの
表示とスクロール R 0.24% Microsoft SharePoint Foundation リスト - 項目のチェックアウトおよびチェックイン W 0.83% リスト - リストの取得 R 0.83% リスト - Outlook 同期 R 1.66% リスト - リスト項目の変更の取得 R 2.49%
リスト - リスト項目の更新と新しい項目の追加 W 4.34% ビューの表示とビューの収集 R 0.22% Web ブラウザの表示 R 1.21% アクセス拒否ページの参照 R 0.07% リスト フィードの表示と参照 R 0.62% 一覧表示の参照 R 0.03%
default.aspx (Office 12 または Office 14 のホーム
ページ) の参照 R 1.70% ドキュメントを参照してドキュメント ライブラリにアップロード W 0.05% リスト/ライブラリの既定のビューの参照 R 7.16% DAV を使用したドキュメント ライブラリ内のドキュメントの削 除 W 0.83% DAV を使用したドキュメント ライブラリからのドキュメントの 取得 R 6.44% DAV を使用したドキュメント ライブラリ内のドキュメントのロッ クおよびアンロック W 3.32% DAV を使用したリストの Propfind R 4.16% DAV を使用したサイトの Propfind R 4.16% FPSE を使用したドキュメントの一覧 R 0.91% FPSE を使用したドキュメントのアップロード W 0.91% すべてのサイト コンテンツ ページの参照 R 0.03% リストまたは Wiki の RSS フィードの表示 R 2.03%
Excel Service 大小 Excel ファイルの表示 R 1.56%
ワークスペース WXP - Cobalt インターナル プロトコル R 23.00%
WXP を使用した全ファイルのアップロード W 0.57%
合計 100%
結果と分析
テストの手法
パフォーマンス テストの実行には、Visual Studio Team System for Test 2008 SP2 を使用しました。このテスト の目標は、各トポロジのグリーン ゾーン、MAX ゾーン、およびその間のさまざまなシステム段階におけるパフォーマンスの 特性を見つけ出すことです。“MAX ゾーン” と “グリーン ゾーン” の詳細な定義は、次に示すように、いくつかのパフォーマ ンス カウンターの値として与えられます。ただし、一般には、“MAX ゾーン” のブレークポイント付近で実行されているファ ーム構成はストレスがかかっていると考えられ、“グリーン ゾーン” のブレークポイント付近で実行されているファーム構成は 健全であると考えられます。 MAX RPS の基準 o スロットルがオン、503 エラーなし o 失敗率が 0.1% 未満 o 75 パーセンタイルの遅延時間が 1 秒未満 o 検索クロールを考慮して SQL Server CPU <= 75% o すべてのフロントエンド Web サーバー CPU <=75% “グリーン ゾーン” の基準 o 75 パーセンタイルの遅延時間が 0.5 秒未満 o フロントエンド Web サーバー CPU が 50% 未満 o SQL Server CPU が 40% 未満 (10% は検索クロールを考慮) o アプリケーション サーバー CPU が 50% 未満 o 失敗率が 0.01% 未満 メモ: 検索クロールの影響を織り込むために、検索クロールの負荷を 10% と見なして、SQL のグリーン ゾーンを 40% と定義しました。同様に、最大 RPS の基準として、SQL Server CPU の 75% を使用しました。 テストの手法として、最も基本的なファーム構成から始めて、一連のテストを行いました。最初のテストでは、徐々にシス テムの負荷を増やして、パフォーマンスの特性を監視しました。このテストから、さまざまなユーザー負荷でのスループットや 遅延を得ると共に、システムのボトルネックを特定しました。このデータを取得したところで、ファームがグリーン ゾーンと MAX ゾーンの特性を示すユーザー負荷を特定しました。事前に指定した一定のユーザー負荷で長時間のテストを何回 か個別に行いました。このテストで、このファーム構成がそれぞれのユーザー負荷で長期間持続してグリーン ゾーンと MAX ゾーンのパフォーマンスを提供できることを確認しました。 その後、次の構成のテストを行う際に、前の実行で特定したボトルネックがなくなるようにシステムをスケールアウトします。 SQL Server の CPU がボトルネックになるまでこの方法を繰り返します。 1 台のフロントエンド Web サーバー/アプリケーション サーバーと 1 台の SQL Server から成る最小ファーム構成から 開始しました。何回かの反復を経て、最終的に 3 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、 1 台の SQL Server のファーム構成で終了しました。ここで、SQL Server の CPU が上限を超えました。各反復で 構成のグリーン ゾーンと MAX ゾーンを確立するために実行したテストの要約とグラフを次に示します。その後、さまざまな 反復でグリーン ゾーンと MAX ゾーンを比較して、推奨事項を導き出します。
SharePoint Admin Toolkit チームは、LTK (Load Test Toolkit) というツールを作成しました。このツールは、ユ ーザーがダウンロードして使用できるように公開されています。
反復の結果 (1 X 1、1 X 1 X 1、2 X 1 X 1、3 X 1 X 1)
1 X 1 ファーム構成
結果の概要 - 1 台のフロントエンド Web サーバーと 1 台の SQL Server のファームでは、同じコンピューターがフロントエン ド Web サーバーの作業の他に、アプリケーション サーバーとしても動作します。明らかにこのコンピューター (引 き続きフロントエンド Web サーバーと記載) がボトルネックになりました。次のデータにあるように、このドキュメン トの前半で説明したトランザクション ミックスを使用してファームに 125 ユーザーの負荷が与えられると、フロント エンド Web サーバー CPU は約 86% の使用率に達しました。この時点で、ファームは 101.37 の MAX RPS を示しています。 - 小さなユーザー負荷でも、フロントエンド Web サーバーの使用率は常に非常に高く、このファームを健全なファ ームと見なすことはできませんでした。テストに使用した負荷とデータ セットに対して、この構成は実際の展開と しては推奨されません。 - “グリーン ゾーン” の定義に従うと、このファームには、実際には “グリーン ゾーン” はありません。負荷が小さい 場合でも、常にストレスにさらされています。“MAX ゾーン” については、ファームが “MAX ゾーン” になる最小 の負荷で、RPS 75 でした。 - フロントエンド Web サーバーがアプリケーション サーバーと二重の役割を持ってボトルネックになったため、次の 反復では、アプリケーション サーバーを専用のコンピューターに分離しました。 パフォーマンス カウンターとグラフ さまざまなユーザー負荷段階で 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示します。 ユーザー負荷 50 75 100 125 RPS 74.958 89.001 95.79 101.37 遅延 0.42 0.66 0.81 0.81 フロントエンド Web サーバ ー CPU 79.6 80.1 89.9 86 アプリケーション サーバー CPU 該当なし 該当なし 該当なし 該当なし SQL Server CPU 15.1 18.2 18.6 18.1 75 パーセンタイル [秒] 0.3 0.35 0.55 0.59 95 パーセンタイル [秒] 0.71 0.77 1.03 1 表 5: 1 X 1 ファーム構成のパフォーマンス カウンターグラフ 1: 1 X 1 構成の RPS と遅延 グラフ 2: 1 X 1 構成のパフォーマンス カウンター
1 X 1 X 1 ファーム構成
結果の概要 - 1 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、 フロントエンド Web サーバー がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説 明したトランザクション ミックスを使用してファームに 150 ユーザーの負荷が与えられると、フロントエンド Web サーバー CPU は約 85% の使用率に達しました。この時点で、ファームは 124.1 の MAX RPS を示してい ます。 - この構成では、RPS が 99、75 パーセンタイルの遅延が 0.23 秒、フロントエンド Web サーバーの CPU が 56% 程度の使用率の “グリーン ゾーン” が提供されました。このことは、このファームが健全に約 99 の RPSを提供できることを意味します。このファームで提供される “MAX ゾーン” の RPS は 123 で、遅延は 0.25 秒、フロントエンド Web サーバーの CPU は約 85% 程度の使用率になります。 - この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため、次の反復では、さらにフロントエン ド Web サーバーを追加しました。 - パフォーマンス カウンターとグラフ さまざまなユーザー負荷段階で 1 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示しま す。 ユーザー負荷 25 50 75 100 125 150 RPS 53.38 91.8 112.2 123.25 123.25 124.1 フロントエンド Web サーバー CPU 34.2 56 71.7 81.5 84.5 84.9 アプリケーション サー バー CPU 23.2 33.8 34.4 32 30.9 35.8 SQL Server CPU 12.9 19.7 24.1 25.2 23.8 40.9 75 パーセンタイル の遅延 [秒] 0.22 0.23 0.27 0.32 0.35 0.42 95 パーセンタイル の遅延 [秒] 0.54 0.52 0.68 0.71 0.74 0.88 表 6: 1 X 1 X 1 構成のパフォーマンス カウンター グラフ 3: 1 X 1 X 1 構成の RPS と遅延
グラフ 4: 1 X 1 X 1 構成のパフォーマンス カウンター
2 X 1 X 1 ファーム構成
結果の概要 - 2 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、 フロントエンド Web サーバー がボトルネックになりました。次のデータにあるように、このドキュメントの前半で説 明したトランザクション ミックスを使用してファームに 200 ユーザーの負荷が与えられると、フロントエンド Web サーバー CPU は約 76% の使用率に達しました。この時点で、ファームは 318 の最大 RPS を示していま す。 - この構成では、RPS が 191、75 パーセンタイルの遅延が 0.37 秒、フロントエンド Web サーバーの CPU が 47% 程度の使用率の “グリーン ゾーン” が提供されました。これは、このファームが健全に約 191 の RPS を提供できることを意味します。このファームで提供される “MAX ゾーン” の RPS は 291 で、遅延は 0.5 秒、フロントエンド Web サーバーの CPU は約 75% 程度の使用率になります。 - この反復ではフロントエンド Web サーバーの CPU がボトルネックだったため、次の反復では、さらにフロントエン ド Web サーバーを追加しました。 パフォーマンス カウンターとグラフ さまざまなユーザー負荷段階で 2 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示しま す。ユーザー負荷 40 80 115 150 175 200 RPS 109 190 251 287 304 318 遅延 0.32 0.37 0.42 0.49 0.54 0.59 フロントエンド Web サーバー CPU 27.5 47.3 61.5 66.9 73.8 76.2 アプリケーション サー バー CPU 17.6 29.7 34.7 38 45 45.9 SQL Server CPU 109 190 251 287 304 318 75 パーセンタイル [秒] 0.205 0.23 0.27 0.3 0.305 0.305 95 パーセンタイル [秒] 0.535 0.57 0.625 0.745 0.645 0.57 表 7: 2 X 1 X 1 構成のパフォーマンス カウンター グラフ 5: 2 X 1 X 1 構成の RPS と遅延
グラフ 6: 2 X 1 X 1 構成のパフォーマンス カウンター
3 X 1 X 1 ファーム構成
結果の概要 - 3 台のフロントエンド Web サーバー、1 台のアプリケーション サーバー、1 台の SQL Server のファームでは、 最終的に SQL Server の CPU がボトルネックになりました。次のデータにあるように、このドキュメントの前半 で説明したトランザクション ミックスを使用してファームに 226 ユーザーの負荷が与えられると、SQL Server CPU は約 76% の使用率に達しました。この時点で、ファームは 310 の最大 RPS を示しています。 - この構成では、RPS が 242、75 パーセンタイルの遅延が 0.41 秒、SQL Server の CPU が 44% 程度 の使用率の “グリーン ゾーン” が提供されました。このことは、このファームが健全に約 242 の RPS を提供で きることを意味します。このファームで提供される “MAX ゾーン” の RPS は 318 で、遅延は 0.5 秒、SQL Server の CPU は 75% 程度の使用率になります。 - これは、このシリーズの最後の構成です。パフォーマンス カウンターとグラフ さまざまなユーザー負荷段階で 3 X 1 X 1 ファームのテスト中にキャプチャされたパフォーマンス カウンターを次に示しま す。 ユーザー負荷 66 103 141 17 202 226 RPS 193.8 218.5 269.8 275.5 318.25 310 遅延 0.3 0.41 0.47 0.58 0.54 0.78 フロントエンド Web サーバー CPU 33 38.3 45.8 43.3 51 42.5 アプリケーション サー バー CPU 28 32.6 46.5 40 45.1 43.7 SQL Server CPU 41.6 44.2 52.6 48 61.8 75 75 パーセンタイル [秒] 0.22 0.24 0.30 0.65 0.78 0.87 95 パーセンタイル [秒] 0.49 0.57 0.72 1.49 0.51 1.43 表 8: 3 X 1 X 1 構成のパフォーマンス カウンター グラフ 7: 3 X 1 X 1 構成の RPS と遅延
グラフ 8: 3 X 1 X 1 構成のパフォーマンス カウンター
比較
実行した段階テストから、各構成が MAX ゾーンまたはグリーン ゾーンになるポイントがわかりました。このポイントを表に 示します。 次の表とグラフは、上に示したすべての結果の概要です。 トポロジ 1x1 1x1x1 2x1x1 3x1x1 最大 RPS 75 123 291 318 グリーン ゾーンの RPS 該当なし 99 191 242 最大遅延 0.29 0.25 0.5 0.5 グリーン ゾーンの遅延 0.23 0.23 0.37 0.41 表 10: さまざまな構成の結果の概要 グラフ 9: さまざまな構成の RPS の概要グラフ 10: さまざまな構成の遅延の概要 ディスク I/O に関するメモ このドキュメントに記載されている推奨事項では、ディスク I/O ベースのボトルネックは考慮されていませんが、傾向 を観察しておくことに意味はあります。次のような数値になりました。 構成 1x1 1x1x1 2x1x1 3x1x1 最大 RPS 75 154 291 318 読み込み数/秒 38 34 54 58 書き取り数/秒 135 115 230 270 表 11: さまざまな構成での 1 秒あたりの I/O テストを 1 時間実行し、固定のサイト/Web/ドキュメント ライブラリ セットのみを稼働したため、SQL Server はすべて のデータをキャッシュできました。そのため、テストで発生した読み取り IO は非常に少なくなりました。書き込み I/O 操 作の方が読み取りより多いことがわかります。これはテスト手法に基づく人為的な結果であり、実際の展開をよく表すもの ではないことに注意してください。典型的な部門別ポータルでは、書き込み操作の 3、4 倍の読み取り操作があることが 普通です。 グラフ 11: さまざまな RPS での 1 秒あたりの I/O
検索増分クロールを使用したテスト
前述のように、これまでのすべてのテストは検索クロールのトラフィックなしで実行されています。実行中の検索クロールがフ ァームのパフォーマンスに及ぼす影響についての情報を提供するために、トランザクション ミックスに検索クロールのトラフィッ クを入れて、最大エンド ユーザー RPS と、対応するエンド ユーザーの遅延を調査することにしました。検索クロールのタ ーゲット用として、1 台の専用フロントエンド Web サーバーを 3 X 1 X 1 ファームに追加しました。3 X 1 X 1 の場合 の元の RPS と比較して、RPS が 17% 低下しました。 同じファームの別のテストで、Resource Governor を使用して、検索クロールが利用できるリソースを 10% に制限し ました。検索が利用するリソースが減り、ファームの最大 RPS が 6% 増加しました。 このテスト結果は次のとおりです。 ベースライン 3 X 1 X 1 増分クロールのみ Resource Governor なし 10% Resource Governor RPS 318 該当なし 276 294.5 ベースラインとの差 (% RPS) 0% 該当なし 83% 88% SQL Server CPU [%] 83.40 8.00 86.60 87.3 SA SQL Server CPU [%] 3.16 2.13 3.88 4.2 フロントエンド Web サーバー CPU [%] 53.40 0.30 47.00 46.5 アプリケーション サーバー CPU [%] 22.10 28.60 48.00 41.3 クロールのフロントエンド Web サーバー CPU [%] 0.50 16.50 15.00 12.1 表 12: 増分検索クロールのテスト結果 グラフ 12: 増分検索クロールのテスト結果重要事項 ここでは、コンテンツの変更があまり多くないファームの増分クロールについてのみ議論しています。10% のリソース使用 量は、フル検索クロールに対しては非常に少ないことに注意してください。また、変更が非常に多い場合にも足りないこと があります。フル検索クロールを実行している場合や、一般にクロールとクロールの間のコンテンツの変化量が大きい場合 は、リソースの使用量を 10% に制限することは推奨されません。
結果と推奨事項のまとめ
テストしたすべての構成の結果をまとめると、次のようになります。 テストに選択した構成、データ セット、およびテスト負荷では、最大 3 台のフロントエンド サーバーに拡大したと ころで、SQL Server の CPU にボトルネックが発生しました。この時点で得られた絶対的な最大 RPS は、 約 318 でした。 フロントエンド Web サーバーの追加により、RPS はほぼ直線的に増加しました。SQL Server がボトルネック にならない限りは、フロントエンド Web サーバーを追加して RPS を増やすことができます。 SQL Server のボトルネックに近づくときに、遅延は大きな影響を受けません。 増分検索クロールは、構成から提供される RPS に直接影響を及ぼします。Resource Governor を使用 することで、この影響を最小限に抑えることができます。 この結果を参考にすると、部門別ポータルに必要な RPS が増えた場合にさらにスケールを拡大する方法として、次 の推奨事項が挙げられます。 1 X 1 ファームは、最大 75 RPS を提供しますが、ほぼ常にストレスがかかっています。運用中の部門別ポー タルの構成としては推奨されません。 コンテンツ データベースとサービス データベースを別々の SQL Server に分けます。テストで使用した負荷で は、SQL Server の CPU がボトルネックになったときに、サービス DB に送られていたトラフィックは 3% だけ でした。このため、この手順では、見た目よりわずかに良好なスケーリングが実現されています。ただし、一般には、 コンテンツ DB とサービス DB を分けることによるスケールの向上は、ファームのサービス DB へのトラフィックに完 全に比例します。 各コンテンツ DB を別々の SQL Server インスタンスに分けます。テストで使用したデータ セットでは、5 つの コンテンツ DB をすべて SQL Server の同じインスタンスに配置しました。これらを別のコンピューターに分ける ことで、CPU の利用が複数のコンピューターに分散されるため、RPS 数がきわめて大きくなります。 最後に、SQL Server サーバーの CPU がボトルネックになった場合は、SQL Server に CPU を追加すると、 ファームの RPS をほぼ直線的に増やすことができます。 この結果を実際の展開に活用する方法 ここまでは、RPS と遅延の点から結果を説明しましたが、現実にはどう適用すればよいでしょうか。ここで、マイクロソ フト社内の部門別ポータルから得られた経験に基づく計算方法があります。 マイクロソフト社内のある部門別ポータルでは、約 8000 人という大勢の従業員の共同作業をサポートしながら、 平均 110 の RPS が得られています。ユーザー/RPS 比は約 72 (=8000/110) です。この比率と前述の結果 を使用して、特定のファーム構成が健全にサポートできるユーザー数を推測できます。
ファームの構成 “グリーン ゾーン” の RPS サポートできるユーザーの概数 1 X 1 X 1 99 7128 2 X 1 X 1 191 13452 3 X 1 X 1 242 17424 表 13: 各構成のユーザー人口の概数 もちろん、これが直接当てはまるのは、トランザクション ミックスとハードウェアがテストで使用されたものと完全に同じ 場合に限ります。実際の部門別ポータルは利用パターンが異なり、この比率を直接当てはめることはできませんが、 近似的には適用可能と考えられます。
