Share via

チーム グループ作業サイトに関するベスト プラクティス

  • [アーティクル]

この記事は、Microsoft Office SharePoint Server 2007 に関する一連のベスト プラクティス記事の 1 つです。この記事では、Office SharePoint Server 2007環境内でグループ作業サイトをホストする場合の代表的な特徴およびベスト プラクティスについて説明します。他のベスト プラクティス記事については、「ベスト プラクティス」を参照してください。Office SharePoint Server 2007 のベスト プラクティスに関するその他の情報とリソースについては、「Best Practices Resource Center for SharePoint Server 2007 (英語)」(https://go.microsoft.com/fwlink/?linkid=125981&clcid=0x411) を参照してください。

チーム グループ作業サイトには、一般的に、次のような特徴があります。

  • 書き込み操作が中心。他の種類のサイト (発行サイトなど) と比較して、グループ作業サイトでの SQL Server ストレージ層に対する書き込みの割合が高くなります。

  • コンテンツのキャッシュが非常に少ない。コンテンツは頻繁に更新され、機能的なグループ作業にとって情報の鮮度は非常に重要なことから、コンテンツのキャッシュはほとんど使用されません。

  • 大部分のコンテンツが構造化および定型化されていない。グループ作業サイトは一般的にセルフサービス形式なので、コンテンツは本質上、大部分が構造化および定型化されていません。高レベルなコンテンツの構造化の実装は、サーバー ベースのグループ作業をユーザーが採用することを躊躇させます。

  • 最小限のカスタム ソリューション。グループ作業環境では、カスタム Web パーツ、カスタム コード、サーバー コントロール、ワークフロー アクション、および InfoPath アクション フォームなどのソリューションやカスタム コードの展開が許可されることはほとんどありません。ただし、SharePoint Designer で、カスタム作成、ブランド設計、および簡単なワークフロー プロセスの設計などの操作を行うことが想定されています。

  • クライアント アプリケーションとの連携動作が非常に重要。他の種類のサイトと比較して、グループ作業サイトでは、2007 Microsoft Office system のクライアント アプリケーションとの連携動作の割合が高くなります。

1. ファーム全体に 64 ビット アーキテクチャを展開する

64 ビット アーキテクチャにより、 (すべてのサーバー ロールにおいて) Office SharePoint Server 2007 の最高のパフォーマンスが引き出されます。64 ビット アーキテクチャでは、32 ビットの場合に比べて大幅にアドレス領域が広くなります。アドレス領域が広がったことで、SharePoint アセンブリ、CLR/Native API、Network Stack、IIS/ASP.NET、およびそれぞれの層でホストされるその他のコンポーネントの領域も広く確保できます。

詳細については、「物理トポロジについての推奨事項 (Office SharePoint Server)」を参照してください。

2. データベース サーバーでグループ作業をサポートするように計画および割り当てを行う

グループ作業は、書き込み操作の割合が相対的に高いこと、およびコンテンツがキャッシュされないことから、SQL Server ストレージに大きな影響を与えるという特徴があります。このため、SQL Server の書込み操作を最適化し、ファームに専用のデータベース サーバーがあることを確認してください。次のホワイト ペーパーの推奨事項に従って、この種類のサイトのサポートに必要とされる SQL Server ストレージとパフォーマンスが確保されていることを確認してください。SharePoint 用 SQL Server 記憶域の計画と監視 : パフォーマンスの推奨事項とベスト プラクティス (ホワイト ペーパー)

SQL Server を実行する典型的なサーバー コンピュータ (8 コア、16 GB の RAM、1 IOPS/GB) では、約 5 TB (テラバイト) のコンテンツをサポートするように計画します。詳細については、「グループ作業サイトの論理アーキテクチャを設計する」を参照してください。

最適なパフォーマンスが得られるようにディスク ドライブを割り当てることも必要です。詳細については、「運用のベスト プラクティス」を参照してください。

3. サイトとコンテンツを監視して、クリーンアップを定期的に実行する

チーム サイトはセルフサービス方式であることが多く、グループ作業を容易にするために構造化のレベルは低く抑えられます。コンテンツのアーカイブと削除に対して、適切なサービス レベル契約 (SLA) を検討し締結します。チーム サイトは、サポートするプロジェクトによって運用期間が限定されることがよくあります。このことに留意して、ライフサイクル管理を実施して、アクティブでないサイトを定期的に削除およびアーカイブしてください。

4. サイトとコンテンツ サイズの制限を適用する

ビジネス ニーズに基づいて、サイト コレクション、サイト、リスト、およびドキュメントの管理に関する、以下のような推奨ガイドラインに従います。

  • コンテンツ データベースあたりのサイト コレクション数 : 50,000

  • サイト コレクションあたりの容量 : 500 MB (既定の最大クォータ値)

  • ファイル サイズ制限 : 50 MB (推奨値) ～ 2 GB (最大値)

  • リスト ビューあたりのアイテム数 : 2,000

大きなリスト、バージョン管理、およびワークフローは、ストレージ容量と環境のパフォーマンスの両方に影響する可能性があります。このため、「ワークフロー履歴の自動クリーンアップを無効にする」で説明されているように、ワークフロー履歴のクリーンアップ ジョブを無効にして、60 日間以上ワークフロー履歴を保存する組織もあります。

詳細については、以下のリソースを参照してください。

5. フロントエンド Web サーバーに対して、プラス 1 台の容量追加を計画する

環境で約 5,000 またはそれ以上のユーザーにサービスを提供している場合、フロントエンド Web サーバーについて、少なくとも 3 台、または適切な容量の提供に必要なフロントエンド Web サーバー数プラス 1 台の展開を検討してください。このようにすることで、あるフロントエンド Web サーバーが高負荷状態になった場合に、ロード バランサがトラフィックを他のサーバーにルーティングできます。残りのフロントエンド Web サーバーが 1 台のみの場合には、処理の連鎖が発生する可能性があります。この状況では、最初のフロントエンド Web サーバーに影響を与えた過負荷分のトラフィックが 2 番目のフロントエンド Web サーバーに転送され、この負荷により 2 番目のサーバーもダウンすることになります。1 台余分にフロントエンド Web サーバーを配置することで、ファーム内で負荷を平均して分配することができ、そうした状況においてパフォーマンスと安定性が高まります。このベスト プラクティスは、ユーザー トラフィックを処理するフロントエンド Web サーバーに適用します。この他に、クロールされる専用のフロントエンド Web サーバーやスタンバイ ファームに対するベスト プラクティスを使用します。これらのフロントエンド Web サーバーは仮想サーバーではなく物理サーバーであることが必要です。

詳細については、「冗長性を計画する (Office SharePoint Server)」を参照してください。

6. 可用性向上のためにアプリケーション プールのリサイクル設定を設定する

Office SharePoint Server 2007 では、アプリケーション プールが定期的にリサイクルされることが必要です。アプリケーション プールに対してプロセスのリサイクルが必要なときを含め、サイトを運用し続けるには、以下の推奨事項に従ってください

  • 異なる Web サーバー (64 ビットと 32 ビット) ごとに、異なる時間にアプリケーション プールをリサイクルします。ファーム内に複数の Web サーバーがある場合、アプリケーション プールが、異なる Web サーバーで異なる時間にリサイクルするように設定されていることを確認します。

  • アプリケーション プールを IIS Web サイトごとに異なる時間にリサイクルする (64 ビットおよび 32 ビット)。Web サーバーのピーク時間を避けるために、異なる時間に異なる IIS Web サイトをリサイクルします。特定の Web サーバーで複数のアプリケーション プールを同時にリサイクルする必要がある場合は、その Web サーバーをロード バランサから一時的に削除して、ユーザーの操作に支障が出ないようにします。

  • Consider memory usage for recycling (32 ビット)。アプリケーション プールのリサイクルを計画する際には、各アプリケーション プールで使用されるメモリ量を検討して、使用されるメモリ量に基づいて頻度を変更します。通常はメモリ リソースの使用量が少ないアプリケーション プールでは、メモリ使用量が多いアプリケーション プールよりもリサイクルの回数が少なくて済みます。以下の設定を推奨しますが、インストール内容および使用する機能によって数値は異なります。

    • 仮想メモリベースのリサイクルが 1,700 MB で行われるように構成します。

    • メモリ使用のリサイクルが 1,000 MB で行われるように構成します。

    • 大きなファイルのアップロードなど、長時間実行する必要のあるユーザー要求を完了できるように、シャットダウン時間制限を少なくとも 300 秒に設定します。

    • 1 日のある時間に大きな負荷が定期的に発生する環境では、時間ベースのリサイクルを使用します。スケジュールするリサイクルを、ピーク トラフィックが始まる約 30 分前に設定します。

詳細については、以下のリソースを参照してください。

7. セキュリティおよび権限を管理する

各サイト コレクションについて、限られた数の適用可能なセキュリティ プリンシパル (ユーザーとグループ) があります (Web サイトあたり 2,000 個)。アクセス権を付与するには、個別にユーザーを追加するのではなく、できるだけ、Active Directory セキュリティ グループと SharePoint グループを使用します。詳細については、「ソフトウェア境界を計画する (Office SharePoint Server)」を参照してください。

独自の権限や詳細に設定された権限は最小限に抑えます。詳細に設定された権限の適用が多くなるほど、アクセスできるユーザーとそのアクセス対象の追跡が複雑になります。さらに、詳細に設定された権限では、それらの権限が適用される各アイテムに対して実行するセキュリティ チェックの数が増えるため、パフォーマンスに影響が出る可能性があります。詳細については、「サイトのセキュリティを計画する (Office SharePoint Server)」およびブログ投稿「SharePoint Groups, Permissions, Site Security, and Depreciated Site Groups (英語)」(https://go.microsoft.com/fwlink/?linkid=123980&clcid=0x411) を参照してください。

サイト コレクション内の要素へのアクセスを監視します。サブサイト、リスト、ライブラリ、およびアイテムにアクセスできるユーザーを定期的に確認します。Office SharePoint Server 2007 内の要素に適用されている、詳細に設定された権限を検出することに役立つサードパーティのセキュリティ管理ツールがあります。この 1 つの例として、DeliverPoint (英語) (https://go.microsoft.com/fwlink/?linkid=126308&clcid=0x411) があります。

8. カスタム コードとカスタム設定をテストする

環境内で何らかのカスタム コードを展開する前に、環境のパフォーマンスの基準計画を作成して、カスタム要素がパフォーマンスに与える影響を確認できるようにします。テスト環境またはサンドボックス環境でカスタム コードを徹底的にテストして、環境への影響を確認します。カスタム コードは、展開前に必ずテストしてください。また、サードパーティや無償のリソースから取得したコードも、すべてテストしてください。無償で広く使用されているからというだけでは、環境内で予期しない影響、特にパフォーマンスに対して影響を与えることがないとは言えません。ソリューション展開を使用してすべてのカスタム コードを展開すると、環境を復元した後で、カスタム設定を容易に追跡および再展開できます。

詳細については、以下のリソースを参照してください。

9. ネットワーク遅延に対処する

ネットワーク遅延は、高パフォーマンスの環境においてさえ、ユーザー満足度を低下させることがあります。遅延の大きいネットワーク経由で大きなファイルに対してグループ作業を行おうとすると、ユーザーが不満を感じることになります。ドキュメントをわずかに変更しただけでも、サーバーにはドキュメント全体がアップロードされることに留意してください。

フロントエンド Web サーバーまたはアプリケーション サーバーとデータベース サーバー間の遅延が 1 ミリ秒を超えないようにすることが必要です。このため、実際問題としては、すべてのサーバーを同一データ センター内の 1 つのファームに配置する必要があります。ファーム内のすべてのサーバーが同じタイム ゾーンに属することが必要です。

多国籍のグローバルなエンタープライズの場合、組織内のチームは、一般的にはローカル地域を軸として展開し、エンドユーザーに密着した複数の小規模のチーム グループ作業ファームを展開します。これにより、ネットワーク遅延と WAN 帯域幅のコストが削減されます。遅延の問題に対処するために、Microsoft Office Groove 2007 などの製品による WAN アクセラレーションやバックグラウンド キャッシュの使用を検討してください。

詳細については、「帯域幅要件を計画する」および「WAN 環境用に Office SharePoint Server を最適化する」を参照してください。

10. エンドユーザーにツールの活用方法をトレーニングする

大部分のエンドユーザーは Web サイトの設計者ではなく、またそれを目指しているわけでもありません。たとえば、エンドユーザーがチーム グループ作業サイトの使用を開始する場合、SharePoint サイトの構成や組み込み機能の使用 (連絡先や予定表の Outlook へのリンクなど) について経験を持っていることはほとんどありません。

Microsoft では、Office Online (https://go.microsoft.com/fwlink/?linkid=89166&clcid=0x411) で、オンライン トレーニングと入門教材にアクセスいただけるようにしています。SharePoint 環境に展開できるエンドユーザー トレーニング キットに Gear up (英語) からアクセスすることもできます。組織内でこれらの教材の認知と利用を推進して、ユーザーが独力でトレーニングできる環境を構築してください。そうすることで、通常業務に関するヘルプ デスクへの問い合わせ件数を削減できます。

11. 運用上のベスト プラクティスに準拠し、ガバナンスのポリシーを保持する

「運用のベスト プラクティス」の記事では、環境を最適化できるように、環境のセットアップとメンテナンスに関するヒントを示しています。これらのベスト プラクティに従うことで、グループ作業サイトから最大のメリットを享受できます。

ガバナンスはグループ作業環境において重要です。グループ作業サイトの管理性を維持するには、一貫性のある情報アーキテクチャ、教育、分類法、およびナビゲーションについて、ガバナンスに関する推奨事項に従っていることを確認します。詳細については、「Governance Resource Center (英語)」(https://go.microsoft.com/fwlink/?linkid=92729&clcid=0x411) および「SharePoint ガバナンス チェックリスト ガイド」(https://go.microsoft.com/fwlink/?linkid=122806&clcid=0x411) を参照してください。

謝辞

Office SharePoint Server 2007 Content Publishing チームは、この記事に投稿していただいた以下の方々に感謝します。

  • Simon Skaria、Microsoft SharePoint Customer Advisory Team

  • Luca Bandinelli、Microsoft SharePoint Customer Advisory Team

  • Steve Peschka、Microsoft Consulting Services

  • Larry Kuhn、Microsoft Consulting Services

  • Ali Mazaheri、Microsoft Consulting Services

  • Todd Carter、Microsoft Premiere Field Engineering

  • Sam Crewdson、Microsoft Hosted SharePoint

  • Cory Burns、Microsoft Hosted SharePoint

  • Mike Watson、Microsoft SharePoint Support and Health