Exchange コンテンツ インデックスの再構築のベースラインを確立する – パート 3
原文の記事の投稿日: 2012 年 7 月 2 日 (月曜日)
このシリーズのパート 1 では、E2K7_IndexRebuildAnalyzer.ps1 スクリプト (英語) について説明しました。そしてパート 2 では、Anatoly Girko と私が開発した検索再構築フレームワークについて説明しました。このシリーズを締めくくる前に、フレームワークを導入してから観測された再構築の特性を示す一連のグラフと、"観測された平均値" の表をご覧いただきたいと思います。これによって概念化が容易になり、各自の再構築の速度を計算する際により正確な見積もりを出せるようになることを願っています。
マイクロソフト社内でこれまでに観測された平均値
Anatoly と私は、これをどのような方法で示すのが適切かについて議論しました。ご想像どおり、方法は無数にあります。我々は、多くの Exchange ストレージ アーキテクトが設計時に使用する、 メール アイテムあたり 150 KB というメッセージ サイズをグラフと表の範囲に設定することにしました。次に、 メールボックスの数 を対象に第 2 のフィルターを適用し、データ コレクション内で 100 個以上のアクティブ メールボックスがあるメールボックス データベースだけを計算に入れて下記の平均値を作成しました。それが終わると、パフォーマンスが最上位 10% と最下位 10% の範囲内にある再構築処理をコレクション内から削除して、グラフと表の作成に使用する平均値を導き出しました。
メモ : 以下に示すさまざまなグラフと表では、 メールボックスの平均サイズ の間隔がいくつかの範囲で途切れています。欠けているデータは、見落とされたわけでも意図的に省略されたわけでもありません。これらの範囲の統計データが欠けているのは、我々の履歴コレクションに有効なデータが存在しないためです。言い換えると、エンドユーザー メールボックスでメールボックスの平均サイズが次の範囲内にあったデータベースについては、コンテンツ インデックスの再構築処理も再構築後のメトリックの収集も行わなかったということです。
- 1700 ～ 1799 MB
- 1800 ～ 1899 MB
- 2000 ～ 2099 MB
- 2100 ～ 2199 MB
グラフ
ここでは、前述のようにフィルターを適用したコレクションに基づいて、これまでに観測されたスループットの特性を表す 4 つの Excel ピボットグラフ を示します。これらのピボットグラフは、メールボックス ストア内とその周囲で発生する各種のプロパティ (メールボックスの数、アイテムの数、EDB ファイル サイズなど) の間に存在する関係を示し、類似の特性を持つメールボックス ストアに対する フル クロール の実行にかかった履歴スループット時間とそれらを対比するように作られています。
グラフ 1
グラフ 1 に含まれるビューは、 データベースあたりのメールボックスの数 、メールボックス データベースの相対サイズ (GB)、およびこれが最終的にメールボックス ストアのコンテンツ インテックス再構築にかかる合計時間 (分) に与える影響について、それぞれの間の関係を明確に表しています。
このグラフは、Exchange メールボックス データベースにあるアクティブ メールボックスの合計数の増加に伴って、記憶域サブシステムにある EDB ファイル サイズの増加に関する並行関係が生じる傾向があることの明確な論拠になっています。さらに、この関係はコンテキスト インデックスの フル クロール の実行にかかる合計時間に影響を与えます。実際のところ、これはつまり、アクティブ メールボックスの数が増えると、通常はメール アイテムの数が増え、メール アイテムの数が増えると、ディスク上の EDB ファイル サイズが大きくなり、ディスク上の EDB ファイル サイズが大きくなるほど、コンテンツ インデックスの再構築にかかる時間が "普通は" 長くなる、という意味のことを格調高く言っているに過ぎません。この仮説が決して当てはまらない唯一の状況は、ファイル内に大量の空白文字があるメールボックス データベースを使用している場合です。このような場合、コンテンツ インデックスの再構築にかかる合計時間は予想より大幅に短くなります。この例外的な状況は、我々がサポートする環境内に存在していましたが、前述のフィルター処理の手法を利用して、それ以降の統計をコレクションから削除しました。
グラフ 2
グラフ 2 は、 メールボックスの平均サイズ (フィルター適用済みの同じサンプル セット内に含まれるデータベースに存在するメールボックス) と、その値がメールボックス データベース レベルでコンテンツ インデックスの再構築のスループット ( 秒/メールボックス ) に与える影響との間に存在する関係を表しています。
このグラフは実質的に、アクティブ メールボックス レベルとはいえ、 グラフ 1 で示した論拠を再確認しています。つまり、アクティブ メールボックスの平均サイズが増加するのに伴って、メールボックス内のメール アイテムの平均数も増加します。平均して、メールボックス内のメール アイテムの数が増えるほど、Search Indexer がメールボックスに対してクロールを実行する時間が長くなり、その結果、データベース内のすべてのメールボックスに対する フル クロール の実行にかかる時間に影響が及びます。
グラフ 3
グラフ 3 は、 メールボックスの平均サイズ (フィルター適用済みの同じサンプル セット内に含まれるデータベースに存在するメールボックス) と、その値がコンテンツ インデックスの再構築のスループット (MB/秒 ) に与える影響との間に存在する関係を表しています。
グラフ 3 は、 グラフ 2 でそれとなく触れた最初の仮説に基づいています。つまり、 メールボックス データベース 内の メールボックスの平均サイズ と アイテムの平均数 が増加すると、Search Indexer のスループットに関して負の関係が生じることを示しています。 グラフ 3 では、この関係を MB/秒単位で示しています。
グラフ 4
グラフ 4 は、 メールボックスの平均サイズ (フィルター適用済みの同じサンプル セット内に含まれるデータベースに存在するメールボックス) と、その値がコンテンツ インデックスの再構築の (メッセージの平均サイズを 150 KB とした場合の) スループット (1 秒あたりのアイテム数 ) に与える影響との間に存在する関係を表しています。
グラフ 3 の場合と同様に、 グラフ 4 もスループット ( アイテム/秒 ) に関してパフォーマンスに負の影響があることを示しています。
観測された平均値の表
この表を示すために、我々はフィルターを適用した同じセット (前に説明し、グラフで示したもの) を利用しましたが、メールボックスの平均サイズに基づいて的を絞った平均値を作成することにしました。これらの行は 99 MB 刻みの独立した行として示されています。各行のスループットの特性は、我々のコレクションで再構築処理が完了した同じようなサイズのすべてのデータベースの総平均を表しています。つまり、 メッセージの平均サイズ が 150 KB で、データベースにあるすべてのアクティブ メールボックスの メールボックスの平均サイズ が列 A に示された範囲内にありました。
この表の履歴平均値から、コンテンツ インデックスの再構築にかかる時間を見積もるための次の 3 つの方法が (少なくとも私には) 思い浮かびます。
- "履歴平均値"。Average Mailbox Size (メールボックスの平均サイズ) に基づいて実装できます。これらのメールボックス内にあるアイテムの Average Message Size (メッセージの平均サイズ) は 150 KB です。我々のコレクションには再構築の履歴データが大量にあるので、この平均値を活用することにします。"再構築前の" メトリックによってメールボックスの平均サイズの値を算出して見積もりを導き出し、これを履歴平均値と比較します。次に、Rebuild: Seconds per/Mailbox(再構築: 秒/メールボックス) の複合平均値を求め、その数字に、データベース上でクロールが必要なメールボックスの数を掛けて、実行に必要な合計時間を算出します。
- "組織の平均値"。組織全体のアイテムの数およびメールボックスの平均サイズにかかわらず、Average Message Size(メッセージの平均サイズ) に基づいて確立できます (組織の平均値は、上記の [Averages] 行に示されています)。
- 履歴平均値と組織の平均値の間の "複合平均値"。
たとえば、ユーザーの Average Mailbox Size (メールボックスの平均サイズ) の総計が 500 ～ 599 MB の範囲内にあるデータベースでコンテンツ インデックスを再構築する必要があり、Average Message Size (メッセージの平均サイズ) を 150 KB と仮定した場合に、そのデータベースのユーザーが 200 人いるとすると、次の 3 つのいずれかの方法で見積もりを導き出すことができます。
履歴平均値の表 :
200 個のメールボックス * 63 秒 = 合計 12,600 秒。したがって、 フル クロール にかかる時間は 210 分、つまりざっと 3.5 時間になります。
"組織の平均値":
200 個のメールボックス * 108 秒 = 合計 21,600 秒。したがって、 フル クロール にかかる時間は 360 分、つまりざっと 6.0 時間になります。
複合平均値 ("履歴" + "組織" の平均) :
3.5 + 6.0 = 9.5 時間
9.5 / 2 = 4.75 時間
まとめ
コンテンツ インデックスの再構築にかかる合計時間は常に変化します。メールの母集団とその中のアイテムも常に変化するからです。コンテンツ インデックスを再構築する場合に、最も正確で堅実な見積もりを得るには、常に履歴平均値を利用します。また、マイクロソフト社内でコンテンツ インデックスを再構築する決定を下すときは、"ユーザーへの影響が最も少ない" 時間帯にスケジュールを設定するように最善を尽くしていることも付け加えておきます。とはいえ、弊社の実装は全世界に及んでいるので、エンドユーザーへの影響を完全になくすことはほぼ不可能です。せいぜいセキュリティへの影響を最小限にするのが精一杯です。さらに、我々のデータ コレクション内では Search Indexer の調整遅延を考慮に入れていません。いかなる Search Indexer の再構築調整遅延も瞬時に処理および把握され、運用部門に提示されるときに個別チケット内に表示されます。この投稿全体で使用しているフィルター処理の手法を利用すると、好ましくない平均値 ("スループットが過度に高い" 再構築処理についても同様) から数字を隔離し、見積もり全体の精度を大幅に高めることができます。
あなたが平均値で賭けをしがちなタイプの性格ならば、この表を全面的に支援します。もっと精密な科学が必要な場合は、この一連の投稿内で説明しているようなフレームワークを実装することをお勧めします。
この一連の投稿が皆さんにとって有益で、できたら何か新しいことを学ぶきっかけになれば幸いです。
最後までお読みいただきありがとうございました。
Eric Norberg
サービス エンジニア
Office 365 専任
これはローカライズされたブログ投稿です。原文の記事は、「Establishing Exchange Content Index Rebuild Baselines – Part 3」をご覧ください。