Analysis Services の高可用性とスケーラビリティ

[アーティクル]
05/08/2023

適用対象: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

この記事では、Analysis Services データベースを高可用性およびスケーラブルにするための最も一般的に使用される手法について説明します。それぞれの目的に個別に対処できますが、実際のところ、この 2 つはほとんどのケースで連携しています。つまり、大規模なクエリまたは処理ワークロードをスケーラブルな方法で配置すると、通常は、高可用性を期待できます。

ただし、その逆については必ずしも正しいとは限りません。ミッションクリティカルで中程度のクエリワークロードに対して厳格なサービスレベル契約が存在する場合は、スケーラビリティが伴わない高可用性が唯一の目的になることがあります。

Analysis Services で高可用性とスケーラビリティを確保する手法は、すべてのサーバーモード (多次元、表形式、および SharePoint 統合モード) で同じになる傾向があります。特に明記しない限り、この記事の情報はすべてのモードに適用されます。

重要なポイント

可用性とスケーラビリティの手法はリレーショナルデータベースエンジンの手法とは異なるため、Analysis Services で使用される手法の導入部として、重要なポイントを簡単に説明しておきます。

Analysis Services では、Windows のサーバープラットフォームに組み込まれている高可用性とスケーラビリティメカニズムであるネットワーク負荷分散 (NLB) または Windows Server フェールオーバークラスタリング (WSFC)、あるいはその両方が使用されます。

注意

リレーショナルデータベースエンジンの Always On 機能は、Analysis Services には拡張されません。また、Analysis Services インスタンスを、Always On 可用性グループで実行されるように構成することはできません。

Analysis Services は、Always On 可用性グループで実行されませんが、Always On リレーショナルデータベースからデータを取得して、処理することはできます。高可用性リレーショナルデータベースを、Analysis Services で使用できるように構成する方法の手順については、「 Analysis Services と Always On 可用性グループ」をご覧ください。
フェールオーバークラスターでサーバーの冗長性が確保されている場合は、唯一の目的として高可用性を実現できます。代替ノードのハードウェアおよびソフトウェアの構成は、アクティブノードと同じと見なされます。 WSFC はそれ自体で高可用性を提供しますが、スケーラビリティは確保されません。
可用性の有無にかかわらず、スケーラビリティは、読み取り専用データベースよりも NLB によって実現されます。スケーラビリティが心配になるのは、通常、クエリ量が多く、急激なスパイクの影響を受けやすい場合です。

負荷分散と複数の読み取り専用データベースを組み合わせると、スケーラビリティと高可用性の両方を実現できます。すべてのノードがアクティブになり、1 台のサーバーで障害が発生しても、残りのノードに要求が自動的に再分散されるためです。スケーラビリティと可用性の両方が必要な場合、NLB クラスターを選択するのが適切です。

処理については、操作のタイミングとスコープを制御できるため、高可用性とスケーラビリティはそれほど心配する必要はありません。モデルは部分処理と増分処理の両方が可能ですが、ある時点で、単一サーバーでモデル全体を処理して、すべてのインデックスと集計でデータの整合性を確保する必要があります。堅牢でスケーラブルなアーキテクチャは、どのような負荷のパターンも完全に処理できるハードウェアに依存します。大規模なソリューションでは、この作業は、独自のハードウェアリソースを備えた独立した操作として構成されます。

単一サーバーとマルチサーバーの構成

通常の単一サーバーデプロイでは、両方のアクティビティにシステムリソースで十分であると仮定して、処理ワークロードとクエリワークロードが同時に実行されます。 Analysis Services の既存のデータ構造はそのままでクエリをサポートし、更新バージョンの処理はバックグラウンドで実行されます。一時的なデータ構造を処理するための十分なメモリとディスク領域を確保するというハードウェア要件はすべてのサーバーモードに共通して存在しますが、システムリソースに対する要求や NUMA 対応レベルは、モードによってそれぞれ異なります。

単一サーバーとスケーラビリティ

単一のハイエンド、マルチコアサーバーは、それ自体で十分なスケーラビリティが用意されていることがあります。多数のコア、RAM、およびディスク領域を備えたハイエンドシステムでは、単一システム内でスケールアップできる可能性があります。

多次元データベースの場合は、サーバー構成プロパティを調整して、プロセスとプロセッサの間にアフィニティを作成できます。詳細については、「スレッドプールプロパティ」をご覧ください。

マルチサーバーの配置

運用上の要件で複数のサーバーを使用するように指定されることがあります。たとえば、定義上、フェールオーバークラスターはマルチサーバーであり、同じハードウェアおよびソフトウェア構成で各ノードが実行されています。

同様に、クエリのワークロードの高可用性が重要な要件となっている場合も、通常、複数のサーバーが必要です。このシナリオでは、Analysis Services の推奨構成として、Analysis Services の個別のインスタンスで実行される読み取り専用データベースと読み取り/書き込みデータベースを専用ハードウェア上で組み合わせて使用することをお勧めします。読み取り専用データベースはクエリ要求を処理します。一方、読み取り/書き込みデータベースは、処理実行に使用されます。よく使用されるこの手法の詳細については、次のセクションで説明します。

仮想マシンと高可用性

高可用性の要件に満たすためのもう 1 つの戦略として、仮想マシンを使用することもできます。代替サーバーを数時間 (数分ではありません) で起動して可用性に対応できる場合は、要求時に開始可能な仮想マシンが使用できる可能性があります。この仮想マシンには、一元化された場所から取得された最新のデータベースを読み込むことができます。

読み取り専用データベースと読み取り/書き込みデータベースを使用したスケーラビリティ

ネットワーク負荷分散は、クエリと処理のワークロードが多い場合、またはこれをエスカレートする場合にお勧めします。 NLB ソリューションの Analysis Services のデータベースは、クエリ間の一貫性を確保するために、読み取り専用のデータベースとして定義されます。

「 Scale-out querying for Analysis Services using read-only databases 」(読み取り専用データベースを使用して Analysis Services クエリをスケールアウトする)(2008 年公開) のガイダンスはかなり前のものですが、基本的にはまだ利用できます。サーバーのオペレーティングシステムやコンピューターハードウェアは進化しているため、プラットフォーム、CPU 制限に関する説明の中には古いものもありますが、読み取り専用データベースと読み取り/書き込みデータベースで大量のクエリを処理する方法は基本的には変わっていません。

このアプローチをまとめると次のようになります。

専用のハードウェアと Analysis Services のインスタンスを使用して、データベースを処理します。処理完了後、データベースを読み取り専用に設定します。手順については、「 Analysis Services データベースの ReadOnly モードと ReadWrite モードの切り替え」をご覧ください。
複数の同じクエリサーバーを使用して、同じ読み取り専用 Analysis Services データベースのコピーを実行します。サーバーは NLB クラスターに展開され、クラスターへの単一のエントリポイントとして機能する 1 つの仮想サーバー名を介してアクセスされます。
robocopy を使用して、データディレクトリ全体を、処理サーバーから各クエリサーバーにコピーし、同じデータベースを読み取り専用モードですべてのクエリサーバーにアタッチします。 SAN スナップショット、同期、または実稼働データベースの移動に使う他のツールまたは方法を使用することもできます。

表形式および多次元ワークロードに対するリソース要求

次の表では、Analysis Services がクエリと処理でシステムリソースをどのように使用しているかを、サーバーモードとストレージモードに分けて大まかに説明します。これは、分散ワークロードを処理するマルチサーバー配置での重要事項を把握するうえで役立ちます。

サーバーとストレージモード	システムリソースへの影響
表形式インメモリ (既定)。インメモリデータ構造のテーブルスキャンとしてクエリが実行されます。	高速クロック速度で RAM と CPU が強調されます。
DirectQuery モードの表形式。バックエンドのリレーショナルデータベースサーバーにクエリがオフロードされ、処理はモデル内でのメタデータ構築に制限されます。	リレーショナルデータベースのパフォーマンスに焦点が置かれ、ネットワーク待機時間の短縮、スループットの最大化が実現します。 CPU の高速化により、Analysis Services クエリプロセッサのパフォーマンスを高めることもできます。
MOLAP ストレージを使用した多次元モデル	データをすばやく読み込むためのディスク IO と、キャッシュデータ用の十分な RAM を確保できるバランスの取れた構成を選択します。
ROLAP ストレージを使用した多次元モデル。	ディスク I/O を最大化し、ネットワーク待機時間を最小限に抑えます。

WSFC による高可用性と冗長性

Analysis Services は、最短時間でサービスを復元する高可用性を実現するために、既存の Windows Server フェールオーバークラスター (WSFC) サービスにインストールできます。

フェールオーバークラスターは、データベースへのフルアクセス (読み取りと書き戻し) を 1 ノードずつ提供します。最初のノードがダウンした場合、セカンダリデータベースは、クラスター内の追加ノードで代替サーバーとして実行されます。

フェールオーバークラスタリングの主なメリットは、サービスの障害から迅速に回復できることです。この利点には、制限がいくつか伴います。その 1 つとして、フェールオーバーが不要な場合は、クラスター内の専用リソースがアイドル状態になります。また、フェールオーバーが発生すると、すべての接続と、その接続に対応するコミットされていない作業が失われます。ほとんどの場合、この状況はクライアントアプリケーションで処理することができます。通常、アプリケーションで更新ボタンを押すことによって、再び結果が表示されます。

WSFC を検討する場合は、次の点に留意してください。

アクティブ/アクティブは現在サポートされていません。 Analysis Services でサポートされている WSFC 構成は、アクティブ/パッシブ (フェールオーバー) のみです。
Analysis Services をクラスター化するときは、クラスターに参加するすべてのノードが同じハードウェアまたは非常によく似たハードウェアで実行され、各ノードの操作コンテキストがオペレーティングシステムのバージョンとサービスパック、Analysis Services のバージョンとサービスパック (または累積更新プログラム)、およびサーバーモードに関して同じであることを確認してください。
パッシブノードを別のワークロードのアクティブノードとして再利用しないでください。ノードが両方のワークロードを処理できないと、実際のフェールオーバー状況が発生した場合に、コンピューター使用率の短期的な効果が失われます。

フェールオーバークラスターで Analysis Services を配置するための詳細な手順と背景情報については、ホワイトペーパー「 SQL Server Analysis Services をクラスター化する方法」をご覧ください。このガイダンスは SQL Server 2012 を対象にしていますが、最新バージョンの Analysis Services にも引き続き適用されます。

参照

Analysis Services データベースの同期
 Forcing NUMA Node affinity for Analysis Services Tabular Databases (Analysis Services 表形式データベースに対する NUMA ノードアフィニティの強制)
An Analysis Services Case Study: Using Tabular Models in a Large-scale Commercial Solution (Analysis Services のケーススタディ: 大規模な商用ソリューションにおける表形式モデルの使用)