Analysis Services によるクエリ処理のスケールアウト

  • [アーティクル]

SQL Server ベスト プラクティス アーティクル

このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

公開日: 2007年6月13日

著者: Denny Lee、Nicholas Dritsas

テクニカル レビューア: Lubor Kollar、Lindsey Allen

対象: SQL Server 2005 RTM

概要: このホワイト ペーパーでは、Microsoft SQL Server 2005 Analysis Services の負荷分散されたスケーラブルなクエリ処理環境を設定して、Analysis Services サーバーに対する大量の同時クエリを処理できるようにする方法について説明します。負荷分散されたクエリ処理によって、OLAP キューブを使用する場合に、1 日中いつでも最新の集計をクエリし、すべてのクエリの負荷を使用可能なサーバーに分散させることができます。このスケールアウト クエリ処理アーキテクチャによって、キューブの処理時間が最適化され、キューブの更新頻度が高くなり、より頻繁な処理と透過的なエラー処理が可能になるため処理の堅牢性が向上します。

トピック

はじめに
アーキテクチャの概要
処理の概要
まとめ

はじめに

このホワイト ペーパーでは、Microsoft® SQL Server™  2005 Analysis Services の負荷分散されたスケーラブルなクエリ処理環境の設定方法について詳しく説明します。負荷分散されたクエリ処理によって、OLAP キューブを使用する場合に、1 日中いつでも最新の集計をクエリし、すべてのクエリの負荷を使用可能なサーバーに分散させることができます。このアーキテクチャによって、次のような点が向上します。

  • キューブの処理時間の最適化。キューブ処理専用のサーバーによって、キューブの処理に固有のタスクや構成を最適化できます。

  • キューブの更新頻度の向上。クエリ実行と処理に別のサーバーを使用するので、必要に応じて、より頻繁にキューブを更新できます。

  • 処理メカニズムの堅牢性の向上。キューブ処理専用のサーバーによって、より頻繁な処理と透過的なエラー回復が可能になります。

ページのトップへ

アーキテクチャの概要

Cc966449.soqwas01(ja-jp,TechNet.10).gif

図 1   Analysis Services のスケールアウト クエリ処理アーキテクチャ

図 1 は、運用環境で長年にわたって動作している、複数の既存の顧客の実装に基づくテンプレートです。この図からわかるように、スケールアウト クエリ処理アーキテクチャでは、プレゼンテーション レイヤ、Analysis Services のクエリ レイヤ、および処理レイヤの 3 つのレイヤを作成する必要があります。"プレゼンテーション レイヤ" は、ユーザーにデータを表示し、4 台の Web サーバーによって構成されています。"Analysis Services クエリ レイヤ" は、プレゼンテーション レイヤにデータを提供するキューブを含み、2 台の Analysis Services サーバーで構成されています。"処理レイヤ" は、データを処理し、SQL Server を実行するサーバーと Analysis Services サーバーによって構成されています。実際のサーバーの数は環境によって異なりますが、ここではこれに基づいて説明を進めます。

テンプレート (図 1 を参照) のプレゼンテーション レイヤには 4 台の Web サーバーがあり、ユーザーに対して OLAP キューブ データを提供します。一般的な環境では、キューブ データにアクセスするには、SQL Server Reporting Services、カスタム Web UI、またはその他の Web アプリケーションを使用する必要があります。図 1 に示したテンプレートでは、Web アプリケーションまたは SQL Server Reporting Services を使用しています。4 台の各 Web サーバーは、IIS 6.0、32 ビット版 Microsoft Windows® 2003 Standard Edition、4 GB の RAM、2 CPU、および約 250 GB の記憶域という仕様です。このアーキテクチャの目標はスケールアウトなので、これが Analysis Services の多くの Web アプリケーションに適した標準的な Web レポート アプリケーションの設定です。

Analysis Services クエリ レイヤには 2 台の Analysis Services サーバーがあり、各サーバーには 64 ビット版の Windows 2003 Enterprise Edition で実行される Analysis Services の 2 つのインスタンスが含まれています。現在のハードウェアの多くは 32 ビットまたは 64 ビットのいずれかのモードで実行できるので、Analysis Services の 64 ビット コンテキストでメモリにアクセスできる機能を使用することには意味があります。Analysis Services を 64 ビット モードで正しく使用するには、最低でも 8 GB の RAM と 4 つの CPU (または 2 つのデュアル コア CPU) を搭載することをお勧めします。また、約 700 GB の記憶域も必要です。

処理レイヤには、1 台の Analysis Services 処理サーバーと、SQL Server を実行するサーバーが含まれています。Analysis Services 処理サーバーの仕様は Analysis Services クエリ サーバーの仕様とほぼ同じですが、このサーバーで必要な Analysis Services のインスタンスは 1 つだけである点が異なります。SQL Server を実行するサーバーは、キューブに提供するデータや、ROLAP ディメンションのソースになるデータをすべて処理できるようにさらに強力です。このサーバーは、SQL Server 2005 および 64 ビット版の Windows 2003 Enterprise Edition を実行しています。このサーバーはより強力であるため、16 GB の RAM と 8 つの CPU (または 4 つのデュアル コア CPU) を搭載することをお勧めします。SQL Server がデータを処理および格納し、インデックスを作成し、ログを記録できるようにするには、約 1 TB (テラバイト) の記憶域が必要です。

このドキュメントでは、この構成に基づいて詳細および利点を説明します。環境によっては、変更が必要になる場合があります。たとえば、OLAP キューブのサイズが大きく、個別のカウント計算の数が多い場合、Analysis Services サーバーのパフォーマンスを最適化するためにより多くのメモリや CPU が必要になる可能性があります。使用するカスタム UI アプリケーションが特に大量のメモリを必要とし、多くのデータをキャッシュする場合、Web サーバーのメモリおよび記憶域を増やす必要があります。レポート アプリケーションに固有の要件がある場合もあります。ただし、このホワイト ペーパーで示している詳細は、ハードウェアの要件を決定する際の出発点になります。

利点

このスケールアウト クエリ処理アーキテクチャの利点は、Analysis Services サーバーに対して同時にクエリを実行する多数のユーザーを処理できるようになることです。キューブが本来大きくない場合でも、多くのユーザーがこの情報に対してクエリを実行しようとする場合は、スケールアウト環境を実装して、複数のクエリによってレポート環境のリソースが消費されないようにすることにはメリットがあります。したがって、多数のユーザーが同時にキューブのデータにアクセスする場合は、このアーキテクチャを検討することが重要です。

図 1 からわかるように、このアーキテクチャはスケールアウト設計であり、処理サーバーと、処理の完了時に同期される独立したクエリ サーバーを使用しています。処理では、OLAP キューブの新しい状態をコミットする必要があるので、データベースを排他的にロックする必要があります。しかし、クエリの実行時間が長いと、この要求がブロックされ、クエリが完了するまで処理は待機状態なります。処理サーバーとクエリを実行する Analysis Services サーバーを別にすることによって、2 つの機能が互いに干渉しなくなります。これによって、処理サーバーはタスクを完了するための処理能力がさらに大きくなります。一方で、クエリ サーバーはクエリ タスク専用になるので、クエリをキャッシュする機能が向上します。処理サーバーからクエリ サーバーにデータを同期するときには、アイドル状態の Analysis Services インスタンスに対して転送が行われます。完了時には、新しく更新されたインスタンスがプライマリ クエリ インスタンスになります。これによって、ユーザーは応答の遅延を感じることなく、Analysis Services サーバー インスタンスに対してクエリを実行し続けることができます。

この処理は、SQL Server 2000 とネットワーク負荷分散を使用して処理する場合と同じくらい時間的な効率がよくなります。同様に、この特定の設計ではハードウェア負荷分散の使用は除外されないので、個々の Web または Analysis Services クエリ レイヤを最適化することができます。

サイズ決定のガイドライン

前述の構成 (図 1) で示したハードウェアの種類およびサーバーの台数の場合、Analysis Services サーバー 1 台あたり 30 人の同時接続ユーザーに対して、OLAP クエリ セルセットを数秒足らずで適切に配信することができます。これらのクエリは、個別のカウント メジャーが 1 つで、OLAP データベースの合計サイズが約 100 GB の場合に、主にカウントおよび合計の集計に対して実行されています。個別のカウント メジャーの数が増えると、Analysis Services サーバー 1 台あたりの同時接続ユーザー数が少なくなったり、適切なパフォーマンスを提供するためにより多くのメモリや CPU が必要になったりする可能性があることに注意が必要です。前述の構成で使用されている、この "標準的な" Analysis Services レポート環境では、およそ 60 人の同時接続ユーザーを処理できます。

実際に必要になるサーバーの数は、特定の作業負荷によって異なります。したがって、実際に必要なサーバーの数を決定するために、クエリおよび処理のパフォーマンス テストを実行する必要があります。一般的に、Web サーバーで負荷の一部を処理できるようにするには、Analysis Services クエリ サーバー 1 台あたり 2 台の Web サーバーを使用する必要があります。必要な Analysis Services クエリ サーバーの数を正確に特定するには、まず予想される同時接続ユーザーの数を特定します。前に説明したように、各 Analysis Services サーバーは約 30 人の同時接続ユーザーを処理できるので、前述の環境では 60 人の同時接続ユーザーを処理できます。同時接続ユーザーが 100 人と予想される場合は、Analysis Services クエリ サーバーの数を 2 倍にします。クエリの負荷をより均等に分散させるには、Web サーバーの数も 2 倍にする必要があります。

前述のアーキテクチャでは単一の Analysis Services 処理サーバーに依存していますが、このサーバーは 100 GB のサイズの OLAP データベースを容易に処理できます。実際の環境では、OLAP キューブの処理に必要なハードウェア リソースを判断する必要があります。たとえば、レポート環境のクエリ特性によって、Analysis Services 処理サーバーでより多くのメモリが必要になる場合は、Analysis Services クエリ サーバーのメモリも増設する必要があります。ハードウェアの要件を定義するには、最初に Analysis Services 処理サーバーのサイズを特定し、次に Analysis Services クエリ サーバーに対しても同じ要件を使用します。

制約

このアーキテクチャの主な制約は、Analysis Services クエリ サーバー インスタンスにアクセスしている UI の接続文字列を更新する必要があることです。これは、一般的に、顧客が Analysis Services クエリ サーバー インスタンスをハードコード化できるようにする (Microsoft Excel を使用して Analysis Services クエリ サーバー インスタンスに直接接続するなど) のではなく、Web サーバーからこれを制御することを意味しています。ただし、Analysis Services を操作するための多くのサーバー ベースの UI では、この接続文字列の変更を容易に実行できます。

ページのトップへ

処理の概要

図 2 に示されているように、このシステムの基本的なアーキテクチャは、4 台の IIS サーバー、2 台の Analysis Services レポート サーバー、1 台の Analysis Services 処理サーバー、およびリレーショナル データ ソースを格納する SQL Server を実行するサーバーで構成されています。

Cc966449.soqwas02(ja-jp,TechNet.10).gif

図 2   Analysis Services スケールアウト クエリ処理環境の概要

この図からわかるように、処理の概要は次のとおりです。

  1. OLAP キューブは専用の Analysis Services 処理サーバーで処理されます。このサーバーは、専用の SQL Server を実行するサーバーに対して処理を実行します。

  2. OLAP キューブが処理されると、データが Analysis Services 処理サーバーからアイドル状態の Analysis Services ステージング サーバー インスタンス (Analysis Services サーバー) に同期されます。

  3. 同期が完了し、Analysis Services ステージング サーバー インスタンスでクエリの結果を提供する準備ができると、UI (この場合、IIS サーバー) からの接続文字列が、それまでアイドル状態であった Analysis Services インスタンスを指すように更新されます。

  4. これらの接続文字列が変更されると、新しい Analysis Services クエリは新しく同期された Analysis Services インスタンスに送信されます。元の Analysis Services インスタンスも送信された元のクエリを完了するためにオンライン状態のままですが、完了するとアイドル状態になります。

メモ   このハードウェア構成では、SQL Server および Analysis Services サーバーはローカル ディスクを使用しています。この設計では、SAN (Storage Area Network) を使用することもできます。ここでは、低コストで堅牢なソリューションとしてこの構成を選択しました。Analysis Services データベースの複数のコピーが存在しているので、これらの Analysis Services サービスのいずれかに障害が発生した場合、サーバーが修復されるまで、クエリの負荷が他の Analysis Services クエリ サーバーに分散されるようになっていれば影響を緩和できます。処理サーバーに障害が発生した場合は、既存の Analysis Services クエリ サーバー インスタンス経由で OLAP データベースが即座に再作成され、この時点から処理を再開できます。

詳細

ここでは、処理から同期後までの各段階について詳しく説明します。前述のように、ここでは 4 台の Web サーバー、2 台の Analysis Services クエリ サーバー (それぞれ 2 つの Analysis Services インスタンスを含む)、1 台の Analysis Services 処理サーバー、および 1 台の SQL Server を実行するサーバーという割合でサーバーを使用しています。これは出発点としては適切ですが、サーバーの総数および割合は、特定の環境でクエリおよび処理のパフォーマンス テストを実行して決定する必要があります。

初期の状態

次の図に初期の状態を示します。

Cc966449.soqwas03(ja-jp,TechNet.10).gif

図 3   Analysis Services スケールアウト クエリ処理の初期状態

この段階では、4 台の Web サーバーがすべて、2 台の Analysis Services サーバーから生成された Analysis Services 結果セットを発行しています。これらのクエリはすべて、Analysis Services クエリ サーバーの 2 つのインスタンス (図 3 の AS1 と AS3) によってのみ配信されています。ROLAP クエリはこれらの 2 つのインスタンスを通って直接 SQL Server に送信されます。一方、他の 2 つのインスタンス (AS2 と AS4) はアイドル状態です。

1 日中いつでも、Analysis Services 処理サーバーは、SQL Server を実行するサーバーに対して OLAP データベースの処理タスクを実行できます。同時 ROLAP クエリおよび Analysis Services 処理クエリ (OLAP データベースの処理のために Analysis Services 処理サーバーから SQL Server を実行するサーバーに送信されるクエリ) を処理する SQL Server サーバーには、潜在的にリソースの制約がいくつか存在している場合があります。ただし、これらのクエリは基になるリレーショナル データ ソースをロックしません。このような競合の影響は最小限であり、あったとしても SQL クエリの応答が若干遅くなる可能性がある程度です。

同期

Analysis Services 処理サーバーで処理が完了した後、この OLAP データベースが、アイドル状態の Analysis Services サーバー インスタンス (AS2、AS4) 上の同じ OLAP データベースの既存の古いコピーに同期されるようにシステムを設定します。この構成の設定を図 4 に示します。

Cc966449.soqwas04(ja-jp,TechNet.10).gif

図 4   Analysis Services スケールアウト クエリ処理の同期状態

それまでアイドル状態であったインスタンスに対して同期が行われるので、現在のクエリはいずれも大きな影響を受けません。Analysis Services 処理サーバーから Analysis Services クエリ サーバー インスタンスへのデータの転送を許可するために、若干のリソースの競合が発生します。ただし、この影響はネットワーク上でファイルをコピーする場合と同様であり、このようなファイルのコピーは Analysis Services の同期機能の主要な (すべてではない) 機能です。一方、AS1 および AS3 で長時間実行されるクエリは、ほとんど影響を受けることなく実行し続けることができます。

Analysis Services サーバーの同期

同期の既定の選択肢は Analysis Services の同期機能を使用することであり、この機能は非常に堅牢で、大量のデータを処理できます。詳細については、SQL Server Books Online の「Analysis Services データベースの同期」を参照してください。また、この機能を自動化するには、SQL Server Integration Services (SSIS) または ascmd.exe サンプル ツールを使用し、Synchronize 要素を使用して XMLA スクリプトを実行します。ascmd.exe ツールは、Microsoft ダウンロード センターの SQL Server 2005 Samples and Sample Databases にある SQL Server 2005 のサンプルに含まれています。

カスタム マルチサーバーの並列サーバーの同期

この特定のアーキテクチャでは、複数のサーバーの同期タスクを並列して実行します。この設計は、堅牢ではないネットワークに頻繁に同期する場合にも適用できます。その考え方は、Robocopy などの高速コピー ツールを使用して、Analysis Services データ フォルダ内で変更または追加された (デルタ) ファイルをコピーするというものです。限定要因は、このデータ フォルダ内のすべてのファイルをコピーする必要があるということです。つまり、処理サーバー上のすべての OLAP データベースをコピーする必要があります。したがって、このアーキテクチャを使用する場合は、処理サーバー上の OLAP データベースの数を、クエリ サーバーに分散する必要があるものだけに制限することをお勧めします。  

この手順では、クエリ サーバー上の Analysis Services のアイドル状態のインスタンスをシャットダウンする SSIS パッケージを作成します。これによって、削除されたクエリ、完了していないクエリ、または長時間実行されているクエリは、この同期処理に影響しません。

メモ   Analysis Services インスタンスをシャットダウンまたは再起動する独自の .NET コードを作成するか、サービスをリモート制御する sc.exe や netsvc.exe などのコマンドライン ユーティリティを使用できます。詳細については、「SC.exe と Netsvc.exe を使用してリモートでサービスを操作する方法」を参照してください。

Cc966449.soqwas05(ja-jp,TechNet.10).gif

図 5   4 つのカスタム サーバーの並列同期の実行例

拡大表示する

アイドル状態のインスタンスをシャットダウンすると、SSIS パッケージは複数の Robocopy のスレッドを実行して Analysis Services のデータ フォルダ (既定では C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\Data) 全体を、Analysis Services 処理サーバーからクエリ サーバーのアイドル状態のインスタンスのデータ フォルダにコピーできます。Robocopy を使用するのは、既定では処理サーバーからクエリ サーバーに新しく追加されたファイルまたは更新されたファイルのみがコピーされるからです。Robocopy は Windows Vista™ および Windows Server 2003 Resource Kit Tools に含まれています。  この操作が完了すると、Analysis Services のアイドル状態のインスタンスを再起動することができ、インスタンスは最新の集計を使用して更新されます。

接続文字列の変更

データベースの同期が終了したら、Web サーバー (または UI) の接続文字列を、それまでアイドル状態であった Analysis Services インスタンス (AS2、AS4) を指すように更新します。

Cc966449.soqwas06(ja-jp,TechNet.10).gif

図 6   Analysis Services スケールアウト クエリ処理: 接続文字列の状態の変更

この処理は自動化されることが多いので、たとえば、SSIS パッケージを使用して、XMLA を実行してデータベースを同期した後に、接続文字列を変更することができます。一方で、以前のインスタンス (AS1、AS3) は、以前に要求されたクエリの実行を継続します。新しいクエリは新しいインスタンスに送信されます。

初期状態への復帰

接続文字列が変更されると、アクティブな Analysis Services クエリ サーバー インスタンスは AS2 と AS4 になります。以前のクエリが完了すると、AS1 および AS3 インスタンスはアイドル状態になり、次回の同期イベントまで待機します。つまり、AS1 と AS3 がアイドル インスタンスで、AS2 と AS4 がアクティブ インスタンスであることを除いて、以前の初期状態 (「初期状態」の図 3) に戻りました。

Cc966449.soqwas07(ja-jp,TechNet.10).gif

図 7: Analysis Services スケールアウト クエリ処理の初期状態への復帰 (AS1 と AS3 がアイドル状態)

1 台の Analysis Services クエリ サーバーに 2 つの Analysis Services インスタンスが存在しますが、クエリの大半はどの時間帯においても一方のインスタンスにのみ送信されます。したがって、2 つの Analysis Services インスタンスが互いに与える影響は最小限です。

まとめ

この負荷分散されたクエリ アーキテクチャでは、同時に実行されたクエリを複数のサーバーに分散させて、高速なクエリのパフォーマンスを維持することができます。Analysis Services のクエリ タスクと処理タスクを分離するので、相互の影響がなくなります。このアーキテクチャでは、タスクの競合を解消することに加えて、個々のサーバーを特定のタスク用に構成できます。したがって、キューブ処理はより堅牢になり、エンド ユーザーはキューブ処理を意識する必要がなくなります。クエリ サーバー上に複数の Analysis Services インスタンスがあるので、必要に応じて、より頻繁にキューブを更新できます。複数の Analysis Services クエリ サーバーがある場合は、クエリの負荷を Analysis Services サーバー間で分散させて、さらに高速に結果を提供することができます。