SharePoint 2010: RBS で SharePoint 2010 のパフォーマンスを向上する
データベース外に BLOB を格納すると、SharePoint 2010 のパフォーマンスが向上します。
Iqbal Khan
SharePoint は、非常に人気の高いポータル プラットフォームになりました。SharePoint では、異なるグループ企業だけでなく異なる企業間での共同作業も可能にする、非常に多くのアプリケーションが提供されます。プロセス管理、ドキュメント管理、およびその他の主要なアプリケーションはすべて、数多くある SharePoint の機能の一部です。
ですが、SharePoint の評判の裏には否定的な側面も隠れています。SharePoint では、あらゆるものに対して SQL Server データベースを多用するので、使用するユーザーが増えるほどパフォーマンスとスケーラビリティが低下します。たとえば、Microsoft Word、Excel、PowerPoint、Adobe Acrobat の構造化されたデータや構造化されたドキュメントは、すべてデータベースから取得します。
パフォーマンスの問題
SharePoint 2010 における潜在的な問題は 2 つあります。1 つ目は、バイナリ ラージ オブジェクト (BLOB) データが原因で、データベースのサイズが桁外れに大きくなる場合があることです。2 つ目は、SQL Server は BLOB を格納するのに最適な場所ではないため、BLOB と他のリレーショナル データの読み取りと書き込みを行うと、SQL Server のパフォーマンスが低下することです。
リレーショナル データベースは、構造化されたリレーショナル データを処理するように設計されており、アーキテクチャはそれを対象としています。マイクロソフトは、SQL Server のデータベースに BLOB を格納するサポートを追加しましたが、データベースは BLOB を格納するのに最適な場所ではありません。これに対して、ファイル ストレージは、基本的に一連のデータ (BLOB) ファイルを格納するように設計されています。
SharePoint 2010 は、Word、Excel、PDF、または PowerPoint ファイルのドキュメント中心に設計されています。サイズの大きいドキュメントが数多く使用されると、急速にデータベースが大きくなり、実用性が失われます。その結果、SharePoint のパフォーマンスが影響を受けます。図 1 に、SQL Server データベースと BLOB に関するパフォーマンスの問題を示します。
.png)
図 1 肥大化した SQL Server データベースにより SharePoint 2010 の動作が遅くなる
SharePoint にユーザーとドキュメントを追加すればするほど、この問題は深刻になります。データベースに何万件ものドキュメントを格納していると、データベースの負荷が高くなり、SharePoint Web ファームと SQL Server のデータベース間で多くのドキュメントをやり取りしなくてはなりません。
データベースのサイズが異常に大きくなることは、データベースの処理速度が低下する大きな要因となります。この SharePoint データが、構造化されたリレーショナル データであれば、インデックスが自動的に作成され、SQL Server によって適切に処理されます。
BLOB データの合計サイズは急速に膨らみ、データベースに格納されているドキュメントのメタデータや構造化されたデータの合計サイズよりも大きくなることがあります。このような状況に対処するには、SQL Server データベースから別のストレージに BLOB を移動します。というのも、BLOB データは、多くのファイル領域を消費し、データベースのアクセス パターン用に最適化されているサーバー リソースを使用するためです。
データベース外に BLOB を移動する
Microsoft Office SharePoint Server (MOSS) 2007 には、外部 BLOB ストレージ (EBS) というメカニズムが導入されました。EBS のプラグイン アーキテクチャによって、サードパーティのベンダーが、EBS モジュールをインストールし、SharePoint データベースのトラフィックを傍受して、あらゆる BLOB トラフィックを別の BLOB ストレージにリダイレクトするようになりました。EBS は、問題なく機能し、SharePoint のパフォーマンスが低下するという問題にかなり効率的に対処します。
EBS を使用すると、BLOB をデータベース外に移行して、記憶域ネットワーク (SAN) またはネットワーク接続ストレージ (NAS) のファイル ストレージ システムに格納できます。BLOB は、一般的に社内で作成されたり、ユーザー間で共有されたりするドキュメント (Excel、Word、PDF など) なので、これらのストレージ システムは BLOB を格納するのに適しています。
ですが、MOSS 2007 に EBS プロバイダーは付属していないので、直接 EBS を使用することはできません。また、EBS のアーキテクチャは、完全な .NET ベースではなく、従来の COM インターフェイス ベースになっているという欠点もあります。このため、サードパーティの EBS プロバイダーを利用する必要があります。サードパーティのモジュールがないと、IT プロフェッショナルが EBS を使用することはできません。サードパーティのモジュールでは、BLOB の削除などの問題にも対処する必要があります。と言うのも、BLOB が削除されるとき、SharePoint では BLOB を削除するようモジュールに指定するのではなく、ただ参照するのを中止するからです。
EBS モジュール ベンダーは、SharePoint で参照されないすべての BLOB を定期的に検索する、BLOB のガベージ コレクション機能または BLOB の削除機能を用意する必要があります。このように参照されていないドキュメントは、ユーザーが削除しているものなので、この機能では、そのような BLOB を削除します。
同様に、ユーザーがドキュメントを更新しても、SharePoint で既存の BLOB が更新されることはありません。既存の BLOB が削除されないように、新しい BLOB が必ず作成されます。EBS モジュールのガベージ コレクション機能では、このような BLOB を削除する必要があります。EBS では、BLOB をデータベース外に移動することで、SharePoint のパフォーマンスを大幅に向上します。
SQL Server 2008 と RBS を使用する
Microsoft SQL Server 2008 には、リモート BLOB ストレージ (RBS) 機能が組み込まれています。RBS を使用すると、SQL Server のユーザーがすべての BLOB をデータベース外に格納できます。RBS には、一般的なファイル システムに対応した FILESTREAM プロバイダーが同梱されています。また、この特殊なストレージのプロバイダーを開発できるように、サードパーティにインターフェイスと仕様が公開されています。このため、日立や EMC などの企業だけでなく、Windows Azure や Amazon クラウド ストレージなどのクラウド ストレージでも、固有のストレージ システムへの RBS の実装、またはその実装の提供が可能になりました。
SQL Server 2008 のユーザーは、これらの機能をすべて使用できます。SharePoint では、この機能を活用するので、SQL Server 2008 をコンテンツ データベースとして使用するように SharePoint 2010 を構成できます。SharePoint 2010 は SQL Server 2005 とも連動していますが、SQL Server 2005 には RBS 機能がないため、SharePoint 2010 で RBS 機能を使用するには SQL Server 2008 を使用する必要があります。
SharePoint の観点では、RBS は EBS とまったく同じように機能します。RBS はデータベース外に BLOB を格納するメカニズムです。唯一の違いは、EBS の場合はサードパーティのベンダーが EBS モジュールを提供する必要がある点です。RBS には、FILESTREAM プロバイダーが用意されています。
SharePoint で RBS を使用する場合は、サードパーティ製品を使用するのが最も便利です。サードパーティ製品を使用すると、プロセス全体がきわめて使用しやすく包括的になり、GUI ツールで、すべてを管理できます。サードパーティ製品を使用しない場合は、SQL Server 2008 と SharePoint 2010 で、BLOB ストレージ用に RBS を構成できます。
SQL Server 2008 の RBS には、RBS Maintainer というガベージ コレクションのプロセスが組み込まれていますが、これは EBS にはない機能です。RBS Maintainer は独立したプロセスで、すべての参照されていない BLOB を削除します。EBS の場合は、この機能をサードパーティ ベンダーが独自に実装する必要があります。
ですが、ユーザーの観点では、RBS と EBS のどちらも、サードパーティ ベンダーが機能を実装すれば、その価値は変わりません。ユーザーがサードパーティ ベンダーを使用したくない場合、RBS しか選択肢はありません。エンド ユーザーが、データベース外に BLOB を移動するのにサードパーティのソリューションを使用してもかまわないのであれば、RBS と EBS のどちらも使用できます。
EBS と RBS のどちらを使用しても、SharePoint のパフォーマンスは等しく向上します。異なるのは、EBS が従来の COM インターフェイスを使用するのに対し、RBS は完全な .NET ベースのソリューションである点です。テクノロジの観点では、RBS は .NET に問題なく適合しますが、EBS は従来のインターフェイスに依存しています。
SQL Server 2008 に組み込まれている FILESTREAM RBS プロバイダーを使用するように SharePoint 2010 を構成することもできます。これは、現在 SQL Server 2008 に組み込まれている唯一のプロバイダーです。今後、サードパーティによって他の RBS プロバイダーが提供されることが予想されます。このようなプロバイダーを使用すると、BLOB をこの外部のストレージに移動できます (図 2 参照)。
.png)
図 2 RBS によって SQL Server 2008 の外に移動された BLOB
データベース外に BLOB を移動することは、SharePoint のパフォーマンスを向上して、データベースを管理しやすくするうえで重要な要素です。ですが、SharePoint のパフォーマンスをさらに向上する場合は、他にもやるべきことがあるのを知っておく必要があります。
BLOB とリストのキャッシュを活用してパフォーマンスを向上する
BLOB をデータベース外に移動したら、BLOB データをキャッシュすることで、SharePoint のアプリケーションのパフォーマンスが大幅に向上します。これは、Web フロントエンド (WFE) サーバーのメモリで、頻繁に使用される BLOB に分散キャッシュを使用する場合に特に当てはまります。キャッシュにより、BLOB ストレージへのアクセスを最小限に抑えられます。この方法だと、データベース外に格納されている BLOB をすばやく読み込んで、SharePoint アプリケーションの応答時間を短縮することが可能になります。
また、他の種類のデータをキャッシュすることもできます。たとえば SharePoint では、キャッシュ可能なリスト データを多用します。リスト データのキャッシュは、メモリ内のキャッシュがもたらすもう 1 つの利点です。リストには、事実上、SharePoint 2010 のすべてのものが表示されています。SharePoint では、リストを読み込むたびにデータベースにアクセスする必要がありますが、このリストを WFE サーバーのメモリにキャッシュすることで、データベースへのアクセスを大幅に削減して、パフォーマンスを向上できます。BLOB とリスト データのキャッシュにより、パフォーマンス レベルを劇的に向上できます (図 3 参照)。
メモリ内のキャッシュは、.NET と Java の領域において大きな影響力を持つようになっています。キャッシュは、WFE サーバーで行う必要があります。サーバーが 32 ビットであるか 64 ビットであるかによって割り当てられるサイズは異なりますが、500 MB から 5 GB または 10 GB まで (使用できるメモリがどのくらいあるかにもよりますが) のメモリを割り当てられます。
このキャッシュは、WFE が BLOB ストレージまたは SQL Server から読み取っている唯一のデータで、どちらから読み取るかは透過的に判断されます。フェッチされたデータはすべて自動的にキャッシュに格納されます。次に SharePoint で同じデータが必要となった場合、そのデータが BLOB とリストのどちらであっても、分散キャッシュからデータが検出されます。つまり、キャッシュは実際には複数の WFE サーバーに分散していることになります。
より規模の大きな環境では、キャッシュを専用のキャッシュ層に移行することもできます。分散キャッシュにすることで、複数のサーバー間でキャッシュを同期できます。したがって、ある Web サーバーでドキュメントが更新されると、他の Web サーバーでもそれが認識されます。メモリ内のキャッシュはきわめて高速なため、キャッシュによってパフォーマンスのレベルを向上できます。
.png)
図 3 SharePoint のパフォーマンスをさらに向上するデータ キャッシュ
各 WFE で単一のワーカー プロセスを使用するように SharePoint を構成すると、ワーカー プロセス内にキャッシュを保持できます。ただし、32 ビットのプラットフォームではワーカー プロセスのメモリ サイズが制限されることを考慮する必要があります。単一のワーカー プロセスでは、1 GB 以上のメモリは使用できません。この場合は、キャッシュを別々のプロセスに保持します。
BLOB をデータベース外に移動し、キャッシュを実装すると、コストの高いネットワークへのアクセスが行われないので、パフォーマンスを何倍も向上できます。リスト データを取得するのに BLOB ストレージにもアクセスしなければ SQL Server にもアクセスしません。すべてのデータは WFE サーバーのメモリに存在します。
プロセス内のキャッシュのパフォーマンス ベンチマークによると、パフォーマンスは少なくとも 3 ～ 4 倍向上することが明らかになりました。これは、データが固有のプロセス メモリに格納されているためです。キャッシュがプロセス外にあっても、同じコンピューターで実行されているプロセス間通信は、ネットワーク間で通信するよりもずっと高速です。
開発者にプログラミングをしてもらい独自のキャッシュ機能を実装することも確かに可能ですが、時間を節約して、エラーの発生しやすいインストールを回避するためには、サードパーティの分散キャッシュ ソリューションを使用することをお勧めします。
SQL Server 2008 の RBS を使用して、BLOB をデータベース外に移動し、SharePoint 2010 のパフォーマンスを向上してください。SQL Server 2008 への移行の準備が整っておらず、それでも BLOB をデータベース外に移動する場合は、ご自身でその処理を行うか、サードパーティが提供するモジュールを使用して EBS 経由でデータベース外に BLOB を移動してください。
Iqbal Khan は、Alachisoft (http://www.alachisoft.com、英語) の社長およびテクノロジ エバンジェリストです。Alachisoft は、NCachePoint と NCache を提供しています。NCachePoint は、SharePoint のパフォーマンスとスケーラビリティを向上する業界の主力製品で、NCache は人気のある .NET ベースの分散キャッシュ製品です。連絡先は iqbal@alachisoft.com (英語のみ) です。