抽出クエリの負荷が大きい環境用に最適化
このトピックでは、抽出クエリの負荷が大きい環境でパフォーマンスを最適化および改善するために、Tableau Server のトポロジと構成を具体的に設定するためのガイドを提供します。
抽出クエリの負荷が大きい環境とはワークブック、ビュー、ダッシュボードの読み込み中には、抽出とフェデレーション データ ソースに対してクエリが実行されるため、多くのクエリ ワークロードが作成されます。そのため、抽出とフェデレーション データ ソースが多くある場合は、「抽出クエリの負荷が大きい環境」であると言えます。
上記で定義したように、抽出クエリの負荷が大きい環境である場合、次の 2 つのセクションを参考にして、この構成が適切かどうかを判断することができます。
この構成を使用するタイミング
この構成の背後にある重要な理由: Hyperは、高速データ取り込みと分析処理に適した Tableau のメモリ最適化データ エンジン テクノロジーであり、クエリの負荷が大きいワークロードを最適化することの重要性を裏付けています。抽出の使用の拡大に伴い、Tableau Server クラスタの専用ノードでデータ エンジンを構成することをお勧めします。この構成により、Tableau Server はインフラストラクチャをスケールアウトして、抽出をクエリするときのパフォーマンスを最適化できます。
抽出とフェデレーション データ ソースを使用してコンテンツを表示する場合、Tableau Server のパフォーマンスに影響を与えるいくつかの要因があります。ここでの目標は、サーバーでコンテンツを表示するときに、一貫性のある信頼性の高いクエリ パフォーマンスを実現することです。この構成は、以下のいずれかの条件がお使いの環境に該当する場合に使用します。
ワークブックの読み込み時間には大きなばらつきがあり、ワークブックでは抽出またはフェデレーション データ ソースが使用されている。
Tableau Server の展開で、Creator、Explorer、Viewer の数、および抽出ベースのコンテンツの数が増加しているため、効率的にスケール アウトする必要がある。
- ファイル ストアがマシンに存在するときに、データ エンジンと VizQL Server 間でリソースの競合がある。
大量のデータを分析する。この構成は、データの取り込みと分析の両方で、ビッグ データ シナリオのパフォーマンスを最適化するのに役立ちます。Tableau とビッグ データの詳細については、「Tableau を使用したハイパーチャージ ビッグ データ分析」を参照してください。
注: クエリの実行時間を確認するには、サーバー側のパフォーマンスの記録を使用します。Tableau のリソース利用状況を確認するには、Windows インストールではパフォーマンス モニター、Linux インストールでは sysstat または vmstat ツールを使用します。
この構成を使用する利点
データ エンジンの専用ノードを構成する主な利点は次のとおりです。
専用のデータ エンジン ノードにより、抽出クエリと、リソースを大量に消費する他のワークロード (VizQL Server によって処理されるワークロードなど) との間のリソースの競合が減少します。
- 抽出クエリは、専用ノードで動的に負荷分散されます。その際、過剰に活用されているノードや、十分に活用されていないノードがないように、システムの現在の状態がチェックされます。
抽出に依存するワークブックを読み込む際に、ユーザー エクスペリエンスのさらに一貫したパフォーマンスが得られます。ここで焦点を当てるのは、個々のクエリを改善することではなく、一貫性のある信頼できるパフォーマンスを確立することです。
より多くのリソースを必要とする Tableau Server プロセスのスケール アウトをより詳細に制御できます。VizQL Server、データ エンジン、およびバックグラウンダーがすべて同じノードで実行されており、抽出クエリが遅いことが問題である場合、3 つのすべてのプロセスで 2 つ目のノードを追加しても、パフォーマンスを向上させることは困難です。この構成を使用すると、抽出クエリのワークロードを具体的に改善するノードを追加できます。
可用性とアップタイムを改善するのに役立ちます。障害が発生し、専用のデータ エンジン ノードの 1 つが使用できない場合、VizQL Server は、問題のあるノードで保留中の要求を他の専用のデータ エンジン ノードにルーティングしようとします。
データ エンジンはマシンで利用可能な数のコアを活用します。これにより、専用のデータ エンジン ノードにリソースをさらに追加して、クエリ応答時間や高価な抽出クエリのばらつきを低減したり、専用のデータ エンジン ノードを追加して、サーバーでの抽出クエリのスループットを向上させたりするなど、柔軟に対応できます。
データ エンジンは、CPU 利用率を 1 時間あたり平均 75% に抑えるようにデフォルトで設定されています。これは、他の Tableau Server プロセスとの競合を回避することを目的としています。データ エンジンを専用ノードで実行している場合は、この平均を 95% まで増やすことができます。これを行うための詳細については、「hyper.srm_cpu_limit_percentage」を参照してください。
この構成を使用しないタイミング
抽出ベースのクエリの読み込みで問題が発生していない場合は、ハードウェア リソースを Tableau Server の他の部分に割り当てる方が適切な場合があります。
ファイル ストア、データ エンジン、および VizQL Server が共存するノードでは、データ エンジンと VizQL Server との間でリソースの競合は発生しません。
この構成を実装する前に、VizQL Server の CPU 使用率、およびファイル ストアと共にインストールされたデータ エンジンが存在するノードの CPU 使用率を評価することが強く推奨されています。
設定
この構成の主な目標は、1 つ以上の専用ノードにデータ エンジンを配置することです。
つまり、ファイル ストアがローカルにインストールされている展開では、1 つ以上の専用ノードでファイル ストアを構成するということです。データ エンジンは、ファイル ストアと同じノードに自動的にインストールされます。
外部ファイル ストアを構成している展開では、引き続き Tableau Server の専用ノードでデータ エンジンを構成できます。
つまり、VizQL Server とファイル ストアのプロセスを分けることで、抽出クエリの負荷と、ビューの読み込みまたは操作にかかる負荷との間の均衡が取れ、管理を向上させることができます。この構成は、抽出をクエリする際に一貫したパフォーマンスを得ることを目標としています。
以下は、データ エンジン/ファイル ストア プロセスにノード 5 と 6 の 2 つの専用ノードがある構成を視覚的に表したものです。これは、ファイル ストアがローカルに構成されている例であり、データ エンジンとファイル ストアのプロセスが同じ場所に配置されています。
外部ファイル ストアを使用した展開で同じ構成を使用しても機能しますが、その場合、ノード 5 と 6 にはデータ エンジンのみが構成されます。
さらに、ノード 1 にはリポジトリ プロセスとファイル ストア プロセスがあり、バックアップの実行に必要なすべてのデータがノード 1 に存在するため、バックアップのパフォーマンスを向上させることができます。
ハードウェアのガイダンス
この構成を最大限に活用するには、さまざまなハードウェア サイズと構成を試して、ピーク負荷のパフォーマンス目標に最適なものを確認する必要があります。Hyper は高性能データベース テクノロジーであり、パフォーマンスに影響を与える主要なリソースは、メモリ、コア、およびストレージ I/O です。Hyper がリソースを使用してクエリを処理する方法を理解すると、さまざまな構成の中からハードウェアを選択でき、その理由を理解できるようになります。
メモリ: 抽出ベースのクエリがユーザーまたはバックグラウンド プロセスに対して処理されると、Tableau Server は専用のデータ エンジン ノードを選択し、クエリを処理します。その専用のデータ エンジン ノードは、抽出をローカル ストレージ (多くの場合、サーバーのハードディスク) からメモリにコピーします。使用可能なシステム メモリが増えると、オペレーティング システムは Tableau のメモリ使用率をより適切に管理できるようになります。専用のデータ エンジン ノードは、システム メモリを使用して、実行されたクエリの結果セットを保存します。結果セットがまだ有効で、オペレーティング システムがそれをメモリからクリアしていない場合は、メモリ内の結果セットを再利用できます。
Tableau Server の推奨される最小ハードウェア要件は 32 GB のメモリですが、抽出ベースのワークブックが大量に読み込まれることが予想される場合は、64 GB または 128 GB を検討する必要があります。コアなどのメモリに加えて、他のリソースの制限値に達した場合は、128 Gbのメモリにスケール アップする代わりに、64 GB の専用データ エンジン ノードにスケール アウトする方がよい場合があります。
抽出をローカル ストレージからメモリにコピーするプロセスには時間がかかるため、ディスク パフォーマンスの最適化が必要になる場合があります。ディスク パフォーマンスの最適化については、[ストレージ I/O] セクションで説明しています。
コア: 抽出ベースのクエリを処理する場合、コアの数はパフォーマンスとスケーラビリティに影響を与える可能性のある重要なハードウェア リソースです。CPU コアはクエリの実行を担い、使用可能なコアが多いほど実行時間が短縮されます。一般的に、コアの数を 2 倍にすると、クエリの実行時間は半分になります。たとえば、現在 4 物理コアまたは 8 vCPU を使用しているクエリの実行時間は 10 秒ですが、8 物理コアまたは 16 vCPU にアップグレードすると、実行時間が 5 秒になります。
現在の Tableau Server で推奨される最小ハードウェア要件は 8 コアですが、展開で抽出を使用する場合は、16 または 32 コアのマシンを検討してください。ここで注意すべき重要な点は、メモリと I/O がボトルネックである場合、使用可能なコアを増やしてもクエリのパフォーマンスは向上しません。
- ストレージ I/O: Hyper は、抽出ストレージ デバイスの利用可能なパフォーマンスを活用して、クエリ処理を高速化するように設計されています。読み取り/書き込み速度が速いソリッド ステート ドライブ (SSD) などの高速ディスク ストレージを選択することをお勧めします。現在利用可能な最速のディスク ストレージは、NVMe ストレージ プロトコルを使用する SSD です。
注: 専用のデータ エンジン ノードのリソースのサイズ設定は、抽出クエリのパフォーマンスにのみ影響します。ワークブックを読み込む際には、VizQL の読み込み要求の合計時間を構成する他の多くのプロセスが伴います。たとえば、VizQL Server プロセスは、データ エンジンからデータを取得し、視覚化をレンダリングする役割を担います。
その他のパフォーマンスの調整と最適化:
上記の基本構成の他に、パフォーマンスを最適化するために使用できる追加機能があります。以下で説明する最適化は、ローカル ファイル ストアと外部ファイル ストアの両方の展開に適用できます。
抽出クエリのロード バランシング: データ エンジンは、抽出クエリをルーティングする場所を決定するために、サーバー ヘルス メトリクスを使用します。これは、データ エンジンが消費しているリソースの量と、同じノードで実行されている可能性のある他の Tableau プロセスからの負荷です。システム リソースの評価に加えて、抽出がノードのメモリに既に存在するかどうかも考慮され、クエリを処理するための可用性が最も高いリソースを持つノードに抽出クエリが送信されるようにします。これにより、メモリとディスクの使用効率が向上し、抽出がノード全体のメモリに複製されなくなります。詳細については、抽出クエリのロード バランシングのヘルプ記事を参照してください。
抽出クエリのロード バランシング機能は、Tableau Server バージョン 2020.2 以降では既定で有効になっています。
ノード ロールを使用したワークロードの最適化: バックグラウンダーおよびファイル ストア ノード ロールを使用すると、サーバー管理者は、抽出クエリと抽出更新を実行する専用のノードをより柔軟に制御できます。上記のトポロジ図で説明したように、特定のデータ エンジ ンノードは抽出クエリを処理する専用のノードであるため、ファイル ストア プロセスとデータ エンジン プロセスのみを実行します。ノード ロールは Advanced Management で使用できます。詳細については、ノード ロールによるワークロード管理を参照してください。
次の図は、上記の基本構成と同じトポロジを使用していますが、ノード ロールが設定されています。
抽出更新バックグラウンダーのノード ロール: ノード 3 を抽出更新バックグラウンダーのノード ロールに設定すると、増分更新、完全更新、暗号化/復号化ジョブのみがこのノードで実行されます。ノード 4 を抽出更新なしのバックグラウンダーのノード ロールに設定すると、抽出更新以外のすべてのバックグラウンド ジョブがこのノードで実行されます。データ サーバーとゲートウェイは、フェデレーション抽出とシャドウ抽出を使用するときに、抽出更新ジョブを支援します。バックグラウンダーのノード ロールの詳細については、ファイル ストア ノード ロールを参照してください。
さらに、ノード 1 にはリポジトリ プロセスとファイル ストア プロセスがあり、バックアップの実行に必要なすべてのデータがノード 1 に存在するため、バックアップのパフォーマンスを向上させることができます。
バックグラウンダーのノード ロールは、Tableau Server バージョン 2019.3 以降の Advanced Management で使用できます。
- 抽出クエリのファイル ストアのノード ロール: 専用データ エンジン ノードであるノード 5 とノード 6 には、抽出クエリのファイル ストアのノード ロールがあり、viz のロード、サブスクリプション、データ駆動型アラートのクエリのみを処理します。
抽出クエリのインタラクティブなファイル ストアのノード ロール: 抽出クエリのファイル ストアのノード ロールが割り当てられた専用データ エンジン ノードの場合、サーバー管理者は、インタラクティブなワークロードとスケジュールされたワークロードを分離して、特定の専用データ エンジン ノードで実行することができます。これは、大量のサブスクリプションが発生しているときに、多くのユーザーがワークブックを操作したり、読み込んだりしている場合に役立ちます。たとえば、月曜日の午前 8 時に 1000 のサブスクリプションがスケジュールされているとします。同時に、1 日の始めに多くのユーザーがダッシュボードを読み込んでいます。サブスクリプションにユーザー クエリの量が加わるため、ワークブックの読み込みが遅くなり、読み込み時間が変動しやすくなる可能性があります。抽出クエリのインタラクティブなファイル ストアのノード ロールを使用すると、専用データ エンジン ノードを指定して、インタラクティブ ユーザー (画面を見て待機しているユーザー) のクエリのみを受け入れることができます。インタラクティブなワークロードに対して優先されるこれらの専用データ エンジン ノードは、競合する大量のサブスクリプション ジョブから保護され、クエリ時間の一貫性が向上します。さらに、サーバー管理者はこのノード ロールを使用して、インタラクティブなワークロードとスケジュールされたワークロードにそれぞれ専用のデータ エンジン ノードを追加できるため、増加に備えた優れたプランニングを行うことができます。詳細については、ファイル ストア ノード ロールを参照してください。
ファイル ストアのノード ロールは、Tableau Server バージョン 2020.4 以降の Advanced Management で使用できます。
外部ファイル ストアを使用した最適化: この機能を使用すると、Tableau Server ノードでローカル ディスクを使用する代わりに、ファイル ストアのストレージとしてネットワーク共有を使用できます。一元化された場所にストレージを配置することで、ファイル ストア ノード間でデータを複製するために費やされるネットワーク トラフィックの量を大幅に削減できます。たとえば、ファイル ストアがローカル ディスクを使用している場合、ローカル ファイル ストアを使用して 1 GB の抽出が更新されると、1 GB のデータがネットワークを介してファイル ストア プロセスを実行しているすべてのノードに複製されます。Tableau Server が外部ファイル ストアで構成されている場合、1 GB の抽出をネットワーク共有にコピーする必要があるのは 1 回のみで、すべてのファイル ストア ノードがその単一のコピーにアクセスできます。ストレージを一元化することで、ファイル ストア ノードで必要なローカル ストレージの総量も削減されます。
さらに、Tableau Server バックアップでは、スナップショット テクノロジーを活用して、バックアップを完了する時間を大幅に短縮します。
外部ファイル ストアの利点を享受するために専用のデータ エンジン ノードを構成する必要はありません。ファイル ストア ノード ロールと抽出クエリのインタラクティブ ノード ロールを備えた追加のワークロード管理機能を併用できます。詳細については、Tableau Server 外部ファイル ストアトピックを参照してください。
外部ファイル ストアは、Tableau Server バージョン 2020.1 以降の Advanced Management で使用できます。