SharePoint Online ポータルのコンテンツ集約に関するガイダンス
ポータルの各設計には、ポータル ページに表示するコンテンツを動的に見つける、表示コンポーネントのスイートが含まれています。 これらのコントロールの操作に不可欠なのは、コンテンツ集約の概念です。この記事の目的上、ここではこの概念を、目的のコンテンツを実行時に動的に見つけるプロセスと定義します。 コンテンツ集約を実行するためにどの手法を選択するかによって、ポータルとそのページのパフォーマンスに大きな影響が及ぶことがあります。
注:
このガイダンスは主に SharePoint Online を対象にしていますが、大部分はオンプレミスの SharePoint 環境でホストされているポータルにも適用されます。
行うべきではないこと
適切なコンテンツ集約を実現するためにやってはいけない重要な事柄を以下に示します。
以下を行わないでください:
- 可能な限り、リアルタイム コンテンツ集約の手法を使用する
- 十数個またはそれ以上の、適切に設計されていないコンテンツ集約コントロールをボリュームの大きいポータル ページ (ホーム ページなど) に配置する
- グループ ポリシー オブジェクト (GPO) を使用して、すべてのブラウザーが問題のあるポータル ページを既定で読み込むように強制する
- コンテンツ集約の結果に行数の制限を適用しない
- コンテンツ集約の結果をキャッシュに入れない
- 従来のリスト (SOAP) Web サービスをターゲットにする 適切に設計されていない CAML クエリを渡すと、さらに問題が増えます
コンテンツ集約の定義
この記事のコンテキストにおいて、コンテンツ集約の明確な定義を確立することは重要です。
コンテンツ集約は、コンテンツがポータル内の現在のページとは異なる 1 か所以上の場所に存在する場合に、現在のページに表示するコンテンツを動的に見つけて取得する概念です。
コンテンツ集約には、現在のページ内で作成されたコンテンツは含まれません。
コンテンツ集約の主な目的は、ポータルのフロントエンド ユーザー ビューを提供することです (バックエンドの管理ビューとは対照的)。
コンテンツ集約を使用可能な場所の例:
- ポータル ホーム ページには、ポータル内で発行された最新の記事へのリンクのリストをレンダリングする、最新ニュース コントロールが含まれています。
- ポータル ページには、カスタム SharePoint リスト内で管理されるナビゲーション リンクをレンダリングするグローバル ナビゲーション コントロールが含まれています。
リアルタイム コンテンツ集約の要件
リアルタイム コンテンツ集約では、コンテンツ集約のソースに加えられた変更が、そのソースをターゲットとするコンテンツ集約コントロールに直ちに表示されます。
リアルタイム コンテンツ集約が期待される場所の例:
- コンテンツ作成者は、記事を発行したら、そのリンクがポータル ホーム ページの最新ニュース コントロールに直ちに表示されることを期待します。
- ポータル管理者は、グローバル ナビゲーション リストへのリンクを追加したら、それがグローバル ナビゲーション コントロールに直ちに表示されることを期待します。
緊急情報は無条件のリアルタイム配信が必須ですが、発行ポータルをこのような情報配信の第一選択にはしないでください。 他のシステム (携帯電話、ラジオ、衛星、テレビ、サイレン、警報、拡声器など) の方がこのタスクには向いています。 ポータルは、フォローアップ情報、コンテキスト、および詳細の配信の方が向いています。そのような配信はリアルタイムで発生する必要がないと思われるからです。
この状況を踏まえて、次のベスト プラクティスを考慮してください。リアルタイム コンテンツ集約のコストに見合うほど重要なポータル コンテンツは存在しません。
残念ながら、ほとんどのポータル コンテンツ管理チームは、最も平凡なコンテンツでさえも緊急であってリアルタイム コンテンツ集約に値するものとみなしたがる傾向があります。
ここに、ポータル設計者の課題があります。このようなプレッシャーとポータル パフォーマンスを低下させるリスクに屈しますか。それとも、別の方法でチームを説得し、高性能のポータルを実現しますか。 ぜひ、別の方法でチームを説得することをお勧めします。
無条件のリアルタイム コンテンツ集約はどんな発行システムにおいても技術的に不可能です。 発行ポータルの既定の動作に準拠したとしても、遅延やキャッシュはコンテンツ集約やレンダリングのパイプラインのさまざまなポイントで発生します。そうした遅延やキャッシュの中には、目に見えて構成可能なもの (クライアント側のカスタム キャッシュ、サーバー側の出力キャッシュ、サーバー側のオブジェクト キャッシュなど) と、目に見えず変更できないもの (データベースのクエリ プラン、内部アプリケーション キャッシュなど) があります。
コンテンツ集約の遅延に気づくのは通常、コンテンツ作成者だけです。 エンドユーザーは、コンテンツ発行プロセスを十分理解しているわけではないため、リアルタイム コンテンツ集約を期待していません。
リアルタイム コンテンツ集約は実現できないことに納得したら、あとは以下の交渉次第です。
- コンテンツが表示されるのに、どのくらいの時間までなら待てますか?
- コンテンツを少し早く表示するために、どのくらいのお金なら払えますか?
コンテンツ集約の遅延は、高性能のポータル ソリューションでも避けられません。 受け入れ可能な遅延に妥協すれば、ポータル ユーザーも納得するでしょう。
注:
コンテンツ集約はリアルタイムで実行できなくても、タイムアウトが 5 分のカスタム アラート機能やタイムアウトが 1 時間のニュース集約などは実現できる可能性があります。 これらは、リアルタイム コンテンツ集約ではありませんが、ほとんどのエンド ユーザーはほぼリアルタイムの集約と見なすでしょう。
コンテンツ集約の手法
次のセクションでは、SharePoint Online で使用可能な 2 つのコンテンツ集約の手法を説明します。
重要
CAML ベースのコンテンツ集約よりも、検索ベースのコンテンツ集約を優先することをお勧めします。
CAML ベースのコンテンツ集約
CAML ベースのコンテンツ集約の手法は、Collaborative Application Markup Language (CAML) クエリの使用に基づいています。
CAML クエリを作成し、それらを使用して SharePoint 内でコンテンツ集約操作を実行することができます。 クエリは、SharePoint のコンテンツ データベースに対して実行されます。 CAML クエリは、すぐに使えるクエリ結果 Web パーツなどのサーバー側コントロールの実装に組み込まれています。 CAML クエリは、カスタムのクライアント側 JavaScript コントロールで使用できるさまざまなコンテンツ検出 API に対して直接使用することもできます。
CAML の主な利点は、リアルタイム コンテンツ集約に限りなく近いものを実現できるということです。
CAML の主な欠点は、パフォーマンスの高い CAML クエリを設計するには知識とスキルが必要なことです。一見無害な変更によって、パフォーマンスの低い CAML クエリになってしまったり、キャッシュ ミスを無限に繰り返すことになってしまったりします。その場合の影響は、ポータルへの負荷が大きくなるまでは明らかになりません。
カスタム コードの展開を禁止することによって、SharePoint Online では、これまで SharePoint の唯一かつ最大のパフォーマンス低下要因のカテゴリとなってきた、設計が適切でない CAML クエリを利用するカスタムのサーバー側コントロールと Web パーツを排除してきました。 それでも、すぐに使えるクエリ結果 Web パーツを介して、または、カスタムのクライアント側 JavaScript コントロールを介して CAML の使い方を誤る可能性があります。
以下の点に注意してください。
クライアント側の各 CAML 要求は、直接のデータベース クエリになります。
- クライアント側の CAML 結果は、サーバーでキャッシュされません。
- クライアント側の CAML 要求は、実行のためにデータベース サーバーをヒットします (キャッシュ ミスが常に発生します)。
サーバー側の各 CAML 要求は、直接のデータベース クエリになる危険性があります。
- サーバー側の CAML 結果は、同様のユーザーのアクセス許可セットに基づいて、サーバーでキャッシュされます。
- 個人用設定フィールドを含むクエリがキャッシュされることはありません。
- サーバー側の CAML 要求は、キャッシュ ミスが発生したときに、実行のためにデータベース サーバーをヒットします。
- Web フロントエンドの数が多いファームでは、キャッシュ ミスがほぼ確実に発生します。
重要
可能な場合は、CAML ベースのコンテンツ集約は避けることをお勧めします。
CAML ベースのコンテンツ集約の使用に関するガイドライン
- ボリュームの大きいページでの使用は避けます。
- 特定のクラスのコンテンツ (アラートなど) への使用を制限します。
- できる限り最も単純で最も効率的な CAML クエリを定義し、そのパフォーマンスを検証します。
- ターゲット リストにインデックス付きの列を実装します。
- クエリに行数の制限を含めます。
- カスタムのクライアント側 JavaScript コントロールで、低ボリュームの全体表示ページへユーザーをリダイレクトする詳細リンクが提供されていることを確認します。
- カスタムのクライアント側 JavaScript コントロールで、クライアント側データ アクセス層フレームワークを利用して、コンテンツ応答がキャッシュに入れられていることを確認します。 結果なしは有効な応答であり、これもキャッシュに入れる必要があります。
- 5 分以上のクライアント側キャッシュの有効期限を適用します。
クライアント側データ アクセス層の詳細については、「SharePoint Online ポータル パフォーマンス ガイダンス」を参照してください。
検索ベースのコンテンツ集約
検索ベースのコンテンツ集約の手法は、SharePoint 検索キーワード クエリ言語 (KQL) クエリの使用に基づいています。
検索 KQL クエリを作成し、それらを使用して SharePoint 内でコンテンツ集約操作を実行することができます。 クエリは、SharePoint の検索インデックスに対して実行されます。 検索 KQL クエリは、すぐに使える検索によるコンテンツ Web パーツなどのサーバー側コントロールの実装に組み込まれています。 KQL クエリは、カスタムのクライアント側 JavaScript コントロールで使用できる検索 API に対して直接使用することもできます。
検索ベースのコンテンツ集約の主な利点は、負荷の高い大規模な環境で優れたパフォーマンスを提供するために構築された SharePoint Search Service を利用していることです。
検索ベースのコンテンツ集約の主な欠点は、検索インデックスに依存していることです。つまり、コンテンツの変更が検索インデックスに反映されるまでにわずかな遅延があります。
以下の点に注意してください。
ポータル コンテンツは、検索ベースのデータ集約で利用できるようにするために、クロールして検索インデックスに追加する必要があります
SharePoint は、最新の検索インデックスを提供するために、ポータル コンテンツを継続的にクロールします。 ただし、コンテンツの変更がインデックスに反映されるまでにわずかな遅延があります。
必要なコンテンツ プロパティが検索で検出されるように、検索スキーマを構成する必要があります。
重要
検索ベースのコンテンツ集約を使用することをお勧めします。
検索ベースのコンテンツ集約の使用に関するガイドライン
コンテンツを集約するには、その前にクロールする必要があるということをコンテンツ管理チームが理解していることを確認します。
- コンテンツ集約の遅延に関する期待値を設定します。
必要な検索スキーマを構成します。
- 適切なスコープ (テナント、サイト コレクション、または Web) を選択します。
- クロールして管理するプロパティの自動生成をトリガーします。
- 並べ替えや絞り込みが必要な場合は、すぐに使えるプレースホルダー管理対象プロパティ (RefinableInt01 など) を利用します。
適切な結果のソースとクエリを設計します。
- 必要に応じて、個別のリスト、Web、またはサイトをターゲットにします。
- 必要に応じて、個別のコンテンツ タイプをターゲットにします。
- 必要に応じて、特定の管理対象プロパティ (サイト列など) をターゲットにします。
適切な表示コントロールを選択します。
- すぐに使えるコントロール:
- 検索によるコンテンツ Web パーツを使用します。
- 必要に応じて、最小限の行と列を返します。
- 必要な表示テンプレートを作成します。
- 必要な場合は、非同期のクライアント側レンダリングを有効にします。
- カスタム コントロール:
- REST Search API を利用するカスタムのクライアント側 JavaScript 表示コントロールを使用します。
- 必要に応じて、最小限の行と列を返します。
- クライアント側データ アクセス層フレームワークを利用して、応答をキャッシュに入れます。
- すぐに使えるコントロール:
クライアント側データ アクセス層の詳細については、「SharePoint Online ポータル パフォーマンス ガイダンス」を参照してください。