パート 2 - Tableau Server 導入の参照アーキテクチャ


次の画像は、関連する Tableau Server プロセスと、それらがリファレンス アーキテクチャーにどのように展開されているかを示しています。これは、企業環境での導入において求められる Tableau Server の最小構成です。

このトピックのプロセス図は、各ノードの特徴的で主要なプロセスを示すことを目的としています。ノードで実行されるサポートプロセスには、図に示されていないものも多くあります。すべてのプロセスの一覧については、このガイドの構成セクションパート 4 - Tableau Server のインストールと構成を参照してください。

Tableau Server プロセス

Tableau Server 参照アーキテクチャでは、PostgreSQL 上に外部リポジトリを備えた、4 つのノードからなる Tableau Server のクラスタを導入します。

  • Tableau Server 初期ノード (ノード 1): TSM 管理サービスとライセンス サービスを実行します。これらは必須のサービスであり、クラスター内の単一ノードでのみ実行できます。エンタープライズ環境では、Tableau Server 初期ノードはクラスター内のプライマリ ノードです。このノードは、ノード 2 を使用して冗長アプリケーション サービスも実行します。
  • Tableau Server アプリケーション ノード (ノード 1 およびノード 2): これらの 2 つのノードは、クライアント要求の処理、データ ソースへの接続とクエリ実行、データ ノードへの接続を行います。
  • Tableau Server データ ノード (ノード 3 およびノード 4): これらの 2 つのノードはデータ管理専用です。
  • 外部 PostgreSQL: このホストは Tableau Server リポジトリ プロセスを実行します。HA 構成では、アクティブ/パッシブ冗長性のために PostgreSQL ホストを追加で実行する必要があります。

    PostgreSQL は Amazon RDS でを実行することもできます。RDS と EC2 インスタンスでのリポジトリの実行の違いについては、「Tableau Server 外部リポジトリ」 (Linux(新しいウィンドウでリンクが開く)) を参照してください。

    外部リポジトリを使用して Tableau Server を展開するには、Tableau Advanced Management ライセンスが必要です。

    社内組織に DBA の専門知識がない場合は、オプションで、デフォルトの内部 PostgreSQL 構成を使用して Tableau Server リポジトリ プロセスを実行することもできます。デフォルトのシナリオでは、PostgreSQL が埋め込まれている Tableau ノードでリポジトリを実行します。その場合、リポジトリのフェイルオーバーに対応するために、専用の Tableau ノードでリポジトリを実行し、別の専用ノードでパッシブ リポジトリを実行することをお勧めします。リポジトリ フェイルオーバー (Linux(新しいウィンドウでリンクが開く)) を参照してください。

    たとえば、このガイドに記載されている AWS の実装では、EC2 インスタンスで実行されている PostgreSQL に外部リポジトリを展開する方法を説明しています。

  • オプション: 外部ストレージを使用している場合は、Tableau ファイル ストアを外部サービスとして導入できます。このガイドの主要な導入シナリオでは、外部ファイル ストアを扱っていません。「外部ファイル ストアを使用して Tableau Server をインストールする (Linux(新しいウィンドウでリンクが開く))」を参照してください。

    外部ファイル ストアを使用して Tableau Server を展開するには、Tableau Advanced Management ライセンスが必要です。

PostgresSQL リポジトリ

Tableau Server リポジトリは PostgresSQL データベースであり、サーバー データを格納します。このデータには、Tableau Server のユーザー、グループとグループ割り当て、パーミッション、プロジェクト、データ ソース、抽出のメタデータと更新などに関する情報が含まれています。

デフォルトの PostgresSQL の導入では、システム メモリ リソースのほぼ 50% を消費します。実稼働の導入の場合や、それが大規模である場合などの使用量に応じて、リソースの消費量が増える可能性があります。このため、リポジトリ プロセスを実行するコンピューターは、リソースを大量に消費する、VizQL、バックグラウンダー、データ エンジンなどのサーバー コンポーネントを実行していないコンピューターにすることをお勧めします。これらのコンポーネントのいずれかと一緒にリポジトリ プロセスを実行すると、IO の競合、リソースの制約などが発生し、導入の全体的なパフォーマンスが低下します。

ノード 1: 初期ノード

初期ノードは重要な少数のプロセスを実行し、アプリケーションの負荷をノード 2 と共有します。

Tableau を最初にインストールするコンピューターである「初期ノード」には、固有の特徴があります。初期ノード上で実行できるのは、ライセンス サービス (ライセンス マネージャー)、ライセンス認証サービス、TSM コントローラー (管理コントローラー) の 3 つのプロセスのみで、エラーが発生した場合を除き、これらのプロセスを他のノードに移動させることはできません。

ノード 1 のフェイルオーバーと自動復元

ライセンス、アクティブ化、および TSM コントローラー サービスは、Tableau Server を健全に展開するための重要なサービスです。参照アーキテクチャーが適切に構成されていれば、ノード 1 で障害が発生してもノード 2 に要求がルーティングされるため、ユーザーは引き続き Tableau Server 構成に接続できます。いっぽう、これらのコア サービスがなければ、Tableau Server 構成は障害が発生したままの重大な状態になります。「初期ノードの自動リカバリ」を参照してください。

ノード 1 およびノード 2: アプリケーション サーバー

Tableau アプリケーション ノードのプロセス

ノード 1 とノード 2 は Tableau Server プロセスを実行し、クライアント要求の処理、データ ソースへのクエリ、ビジュアライゼーションの生成、コンテンツと管理の処理、その他の Tableau ビジネス ロジックを実施します。アプリケーション サーバーではユーザー データは保存されません。

注: "アプリケーション サーバー" は、TSM にリストされている Tableau Sever プロセスを指すこともあります。"アプリケーション サーバー" の基盤となるプロセスは VizPortal です。

ノード 1 とノード 2 は、並行して実行すると拡張され、リバース プロキシ サーバーによる負荷分散ロジックからの要求を処理できます。冗長ノードとして、どれか 1 つのノードに障害が発生しても、クライアントの要求とサービスは残りのノードによって処理されます。

参照アーキテクチャは、補完的なアプリケーション プロセスが同一のコンピューターで実行されるように設計されています。つまり、このプロセスによって、コンピューティング リソースの競合が発生したり、誘発されたりすることはありません。

たとえば、アプリケーション サーバー上のコア処理サービスである VizQL は CPU とメモリに大きく依存しており、VizQL はコンピューターの CPU とメモリの約 60 ～ 70% を使用します。このため、リファレンス アーキテクチャは、他のメモリや CPU にバインドされたプロセスが VizQL と同じノード上に存在しないように設計されています。負荷の量やユーザー数が VizQL ノードのメモリや CPU の使用量に影響を与えないことはテストで確認済みです。たとえば、負荷テストで同時ユーザー数を減らしても、ダッシュボードやビジュアライゼーションの読み込みプロセスのパフォーマンスのみに効果があるものの、リソースの使用率は軽減されません。したがって、ピーク使用時に使用可能なメモリと CPU に基づいて、VizQL プロセスを追加することを検討できます。一般的なワークブックの開始方法として、まず VizQL プロセスごとに 4 つのコアを割り当てます。

アプリケーション サーバーの拡張

参照アーキテクチャは、使用量ベースのモデルに基づいて、拡張性を考慮して設計されています。最大 1000 人のユーザーをサポートするアプリケーション サーバーを少なくとも 2 台導入することを、一般的な出発点として推奨します。ユーザーの規模が拡大するのに合わせて、1000 ユーザーごとにアプリケーション サーバーを追加することを計画します。使用状況とパフォーマンスを監視して、自分の組織に適した、ホストあたりのユーザー規模を調整します。

ノード 3 およびノード 4: データ サーバー

Tableau Server データ ノードのプロセス

ファイル ストア、データ エンジン (ハイパー)、バックグラウンダーなどのプロセスは、次の理由からノード 3 やノード 4 に配置します。

  • 同一ノード上でバックグラウンダー、Hyper、およびファイル ストアを実行することで、パフォーマンスと信頼性が最適化されます。抽出プロセス中に、バックグラウンダーがターゲットのデータ ベースに対してクエリを実行し、Hyper ファイルを同じノードに作成してから、ファイル ストアにアップロードします。これらのプロセスを同じ場所に配置することにより、抽出作成ワークフローでは、ネットワークまたはノード間で大量のデータをコピーする必要がありません
  • リソースのバランシング: バックグラウンダーは主に CPU を集中的に使用します。データ エンジンはメモリを大量に消費するプロセスです。これらのプロセスを結合することによって、各ノードのリソース使用率を最大化できます。
  • データ プロセスの統合: これらの各プロセスはバックエンドのデータ プロセスであるため、安全なデータ層の中で実行することは理にかなっています。参照アーキテクチャの今後のバージョンでは、アプリケーション サーバーとデータ サーバーは別々の層で実行されます。ただし、Tableau アーキテクチャにはアプリケーションの依存関係があるため、この時点では、アプリケーション サーバーとデータ サーバーを同じ層で実行する必要があります。

データ サーバーの拡張

アプリケーション サーバーと同様に、Tableau データ サーバーに必要なリソースを計画するには、使用量ベースのモデルが必要です。一般に、各データ サーバーが 1 日あたり最大 2000 の抽出更新ジョブをサポートできると想定します。抽出ジョブの増加に伴い、ファイル ストア サービスを使用せずにデータ サーバーを追加します。一般的に、2 ノードのデータ サーバー展開は、ファイル ストア サービスにローカル ファイル システムを使用する展開に適しています。アプリケーション サーバーを追加しても、データ サーバーのパフォーマンスや拡張性に直線的に影響を与えることはありません。実際のところ、ユーザー クエリの追加によるオーバーヘッドを除くと、アプリケーション ホストとユーザーの追加による影響は最小限です。

一番上に戻る
フィードバックをお送りいただき、ありがとうございます。フィードバックは正常に送信されました。ありがとうございます!