パフォーマンス低下を招く前に
おっと! SharePointのキャパシティープランニングを忘れていた
Microsoftのオンラインコラボレーションツール「SharePoint」を利用する際、適切なキャパシティープランニングをしておかないと性能低下などのトラブルを招くことになる。
キャパシティープランニングはなぜ省略されるのか
SharePointのキャパシティープランニングに関して多くの企業が犯す最大の過ちは、プランニング作業そのものを怠ることだ。なぜそんなことが起きるのだろうか。理由はたくさんある。
第一に、SharePointは多階層型アプリケーションであるため、キャパシティープランニングが非常に複雑になることがある。Windowsファイルシステム、Active Directory(以下、AD)、.NET Framework、Internet Information Services、SQL Serverのさまざまなキャパシティー制限に関する知識も不可欠だ。これらの制限を知っていれば、パフォーマンス、ユーザーエクスペリエンス、SharePointの拡張の妨げになるようなボトルネックを防ぐことができる。
キャパシティープランニングを省略する理由としてよく挙げられるのが、「非現実的な期限のせいで十分な時間がない」「現在あるいは過去の利用率に関するデータが不足しているために、今後の拡張ペースを正確に予測できない」といったものだ。「SharePointでは情報がどのように保存・管理されているのかよく分からない」といった理由もあるだろう。
どういった理由であれ、キャパシティープランニング作業に役立つ指針が幾つかあるので、それらを以下に紹介する。
最初に考慮すべきSharePointのキャパシティー機能は、ADに関連したものだ。SharePointでは、ADのアカウントとグループを用いてユーザーの認証を行い、さらにSharePointのグループメンバーシップを用いてユーザーに権限を付与する。
SharePointに影響するADの制約というのは、個々のセキュリティ対象オブジェクトのセキュリティプリンシパルに適用されるキャパシティー制限だ。サイト、ライブラリ、リスト項目に関連付けることができるユーザーとグループの数には制限があり、これを超えると正しくインデックス化が行われない。この制限は約2000ユーザーとなっている。これは、ADのAccess Control List(ACL)のサイズが64Kバイトに制限されており、1ユーザーあるいは1グループのサイズが約32バイトであるからだ。
SharePointが項目をインデックス化するときに64Kバイトの制限に到達すれば、その項目とそれ以下のすべての項目のインデックス化が失敗する。つまりACLは64Kバイトを超えても構わないが、ACLのインデックス化が行われないということだ。
ADの1つのグループは1つのセキュリティプリンシパルとしてカウントされ、1つのADグループには10万ユーザーを含めることができる。つまり、1つのドキュメントに2000以上のユーザーを関連付けるには、ADグループメンバーシップを通じた間接的な方法でしか行えないということだ。また、1人のユーザーを1015以上のグループに含めることができないことにも注意が必要だ。
1つのWebサイトの最大ユーザー数は200万人だ。Microsoft Office SharePoint Server(以下、MOSS)では、サイトグループはすべてクロスサイトグループであるという点も忘れてはならない。すなわち、1つのサイトコレクション内のあらゆるグループを、ほかのグループの権限を承認するのに利用できるということだ。また、サイトコレクションは25万サイトまで拡張できるが、セキュリティプリンシパルの2000という制限に注意する必要がある。
リストとビューの制限とパフォーマンスの関係
MOSSのキャパシティープランニングでも、リストとビューの制限に関連して2000という数字が出現する。リストには500万項目を含めることができるが、そのデータのビューのパフォーマンスは200項目で低下し始め、2000項目で動作が停止する。これは、ベースとなるSQLクエリのページングやフィルタリングが行われなくなるからだ。
グループ化されたビューの場合、この点に特に注意する必要がある。カテゴリーを展開するまで一部のデータしか表示されなくても、すべてのデータがロードされるからだ。フォルダを利用すれば、多数の項目を小さな集合に分割できるが、ナビゲーションの問題やURLが長くなり過ぎる(最大で約260文字)という問題が生じる恐れがある。
リスト表示でのパフォーマンス問題を避けるために、サブサイトの数は2000以下に抑えるべきだ。また、カラムの数もライブラリでは2000以下、リストでは4000以下にしておくことも大切だ。サイトコレクションには25万サイトを含めることが可能だが、サイトをどのような構成にするかというのは重要な問題だ。例えば、それぞれ2000サブサイトが含まれる125のWebサイトでも問題はないかもしれないが、これらをさらに小さなグループに分割することでアーキテクチャの拡張性が高まる。ごみ箱もキャパシティーに影響するため、プランニングに際しては、その容量をあまり大きくしないことが重要だ。
適切なキャパシティープランニングを行うためには、Microsoftが公表しているキャパシティープランニングに関する情報を把握しておく必要がある。「そんな情報は見ていない」というのは言い訳にならない。
本稿筆者のスティーブン・カミンズ氏はwww.spsfaq.comの創業者で、SharePoint専門のコンサルタントを務める。この7年間にわたりSharePoint分野のMVP(Most Valuable Professional)を受賞した。妻、娘、2匹の犬、多数の金魚とともにアイルランドのキルデアで暮らしている。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
“攻撃者優位”なサイバーセキュリティ、全ての「穴」をふさぐ方法とは? -
製品資料
実際に悪用される脆弱性は4%前後 優先的に対処すべき脆弱性を把握するには? -
製品資料
HubSpotの機能を拡張する法人データ活用法 -
製品資料
面倒で非生産的な「名寄せ」作業 高精度&高効率に実施するには? -
製品資料
名刺管理には「その先」がある 成果のでない営業活動から脱却する秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
2
「VMware離れ」は本当か 3000社がVCF 9にかじを切った現実的な理由
-
3
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
4
「OSの選定・導入」に関するアンケート
-
5
マンガで解説:KSK2稼働で何が変わる? 税務調査の高度化に備えるデータ管理
-
6
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
-
7
「データストレージの活用方法」に関するアンケート
-
8
取手市がVDIと決別した理由 更改費用「4倍超」を約1.7倍に圧縮
-
9
脱VMwareに待った? AI基盤を掲げるBroadcomの思惑と情シスが直面する新コスト
-
10
なぜ人はいるのにDXが進まない? ライオンも直面した“老害”レガシーシステム
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
3
財務・会計はAI活用でどう変わる? 調査で見えた変革の道筋
-
4
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
「結局、一部の人しか使わない」 AI活用が業務に定着しない根本的な理由
-
7
コスト分析で見る「デバイス復旧」の代償 損失額から導きだされた投資戦略とは
-
8
Macの安全神話は崩壊? 最新の脅威動向から見えた攻撃のトレンドと有効な対策
-
9
ゼロトラストにおける「IDaaSの課題」と補完すべき重要機能とは?
-
10
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー