パフォーマンス低下を招く前に
おっと! 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
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
2
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
3
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
4
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
5
「身代金を支払う」以外のランサムウェア対策は本当にあるのか?
-
6
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
7
肥大化した「SFA」の沼 4カ月でBigQuery×AppSheetの新システムを構築した方法
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
ネットワールド、ICカード認証対応のシンクライアント構築アプライアンスを販売
-
10
次世代RPA「ハイパーオートメーション」が急成長か Gartnerが予測
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
4
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
5
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
6
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
“あのファイル転送”で暗躍するノーウェアランサム
-
10
「オンプレミス回帰」せざるを得ない“合理的な理由”
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー