Tableau Server on Linux ヘルプ

Tableau Server 展開のトポロジ (ノード数、Tableau Server プロセス数) を決定する際には、利用環境、データのソース、セルフサービス データ アクセスを提供するための管理、作業負荷、および使用率などの変数について考慮する必要があります。しかし、Tableau Server を初めて展開する場合、これらの変数について十分な情報がないことがあります。このトピックでは、Tableau Server インストールの出発点として使用できる 3 つのベースライン アーキテクチャについて説明します。

サーバー展開計画の検証

組織に新しい Tableau Server 展開をインストールする前に、オプションを注意深く評価する必要があります。ほとんどの組織の場合、Tableau Cloud は、セルフホストしている Tableau Server よりも信頼性、パフォーマンス、コスト効率が高い分析ソリューションを提供します。組織に対する Tableau Cloud の有効性に関する詳細については、ブログ投稿「分析を Cloud に移行する必要がありますか (英語)(新しいウィンドウでリンクが開く)」を参照してください。

すでに Tableau Server を実行していて、Tableau Cloud への移行を検討している場合は、「Tableau Cloud 手動移行ガイド(新しいウィンドウでリンクが開く)」を参照してください。

Tableau Server をセルフホストする必要があると判断した場合は、「企業環境への Tableau Server 導入ガイド (EDG)(新しいウィンドウでリンクが開く)」で規定されている Tableau 展開に従うことをお勧めします。EDG は、階層型データ ネットワークに基づいた参照アーキテクチャを示しています。このアーキテクチャは完全にテストされていて、サポート対象であるほか、パフォーマンスが高く、スケーラブルかつ安全です。私たちは今後も EDG 参照アーキテクチャへの取り組みを続け、機能のロールアウトを簡単にし、アップグレード シナリオを改善していきます。

本番環境インストールに関するハードウェアの推奨事項

以下の本番環境の Tableau Server インストールに関するハードウェア推奨事項は、Tableau チームが Tableau Server のスケーラビリティのテストに使用するハードウェアに基づいています。これらの推奨事項を、本番環境展開の出発点として使用することをお勧めします。概念実証 (PoC) の展開では、Tableau Cloud を使用することをお勧めします。詳細については、「インストールの最小ハードウェア要件」を参照してください。

注: 仮想マシンを使用する展開の場合、専用 CPU アフィニティを適用することをお勧めします。仮想環境で Tableau Server を実行している場合は、VM ホスト上の物理 CPU コア数と関連して、vCPU 割り当てに対して VM ホストのベスト プラクティスを使用します。通常、Tableau Server の場合は 2 vCPU = 1 物理コアです。たとえば、AWS インストールでは、4 コアの最小推奨事項が 8 AWS vCPU に相当します。同様に、Tableau Server が適切な計算、メモリ、およびデータ リソースに確実にアクセスできるように、使用する仮想インフラストラクチャのプロバイダーから提供されるベスト プラクティスに従います。仮想環境またはクラウドベース展開で Tableau Server をインストールしている場合は、このトピックで後述する仮想マシンおよびパブリック クラウド展開のセクションを参照してください。

ディスク領域の推定

抽出をパブリッシュするかどうか、フロー、また Tableau Server にパブリッシュするワークブックの数が、ディスク領域要件に影響を及ぼす要因としてあげられます。詳細については、ディスク容量の要件を参照してください。

ベースライン構成

• 単一サーバー インストール

• 2 ノード インストール - 抽出負荷の高い環境用

• 2 ノード インストール - フロー環境用

• 高可用性インストール (HA)

単一サーバー インストール

推奨事項

初めての展開では、単一のマシンを使用して Tableau Server をインストールし、基幹業務以外で限定的に使用することをお勧めします。単一サーバー インストールは、作業負荷が増大したときに、複数ノード インストールに展開することもできます。

単一サーバー インストールが適さない可能性がある例を以下に示します。

• 使用するシステムが必要不可欠なシステムであり、高い可用性が必要とされている場合。高可用性とは、システム ダウンタイムを最小限に抑えることです。それには、単一障害点をなくし、信頼性の高いフェールオーバー メカニズムを備える必要があります。Tableau Server は、冗長性の提供と単一障害点の排除のために、少なくとも 3 ノードの構成が必要です。このことが、複数ノード構成に移行する主な理由の 1 つです。

• 多数のアクティブ ユーザーがいて、多数の抽出更新が発生する場合は、マシン上の同一リソースに対してこの 2 種類の負荷が競合する可能性があります。そのようなシナリオにおいては、異なる作業負荷を分離するために追加の専用ノードが必要になることがあるため、単一サーバー構成が適切な選択肢ではない可能性があります。

注: アクティブ ユーザーとは、Tableau Server に対して行われるインタラクティブな同時要求のことを表します。ノート パソコンやモバイル デバイスでのダッシュボードの使用、Web 作成、パブリッシュされたデータ ソースへの接続およびクエリなどが含まれます。

サーバー構成

• すべてのプロセスが 1 台のマシン上にインストールされたスタンドアロンの単一サーバー ノード。

• 以下は、8 コア マシン用のプロセス数です。

  • VizQL Server: 2 インスタンスに設定します (物理コア数を 4 で割る、最大 4)。

  • バックグラウンダー、キャッシュ サーバー、およびデータ サーバー: 2 インスタンスに設定します。

  • その他のすべてのプロセスは、ハードウェアに関係なく、プロセスのインスタンスを 1 つだけインストールします。

注: サーバー上で Data Management プロダクト キーがアクティブ化されている場合、Tableau Prep Conductor の 1 つのインスタンスが自動的に構成されます。ただし、Tableau Prep Conductor の専用ノードを設けることをお勧めします。Tableau Server にフローを設定する予定がある場合は、2 つ以上のノードを使用し、そのノードのうち 1 つをフローのみの実行専用にすることをお勧めします。単一ノード サーバーであるため、上記の構成例には Tableau Prep Conductor は含まれていません。

マルチノード インストール

複数のマシン上で Tableau Server を実行することを、マルチノード インストールまたはクラスターと言います。さまざまな理由でマルチノード インストールが必要になることがあります。たとえば、抽出負荷の高い環境では、一部のハードウェア リソースがバックグラウンダー プロセス専用に使用される可能性があります。高い可用性を必要とするシステムの場合、少なくとも 3 つのノードを備えたマルチノード環境を構築する必要があります。

2 ノード インストール - 抽出負荷の高い環境用

推奨事項

以下の条件が当てはまる場合は、2 ノード構成から開始してください。

• 抽出負荷の高い環境: データ ソースの大半を抽出が占めます。少数の極めて大きな抽出を持っているだけで、非常に多数の小さな抽出を持っているのと同じように、展開がこのカテゴリに該当する場合があります。

• 頻繁な抽出の更新: 抽出を更新するタスクは、CPU を大量に使用するタスクです。抽出が頻繁に更新される (1 日の営業時間内に数回など) 展開は、更新タスクを処理するバックグラウンド プロセスをさらに強化することで改善されることがよくあります。

重要: 2 ノード構成は、高可用性のための最小要件を満たしません。可用性の高いシステムが必要な場合は、高可用性インストール (HA)を参照してください。

サーバー構成

• 最初のノードで、バックグラウンダーを除くすべてのプロセスをインストールします。以下は、8 コア マシン用のプロセスのインスタンス数です。

  • VizQL Server: 2 インスタンスに設定します(既定の計算: 物理コア数を 4 で割る、最大 4)。

  • キャッシュ サーバーおよびデータ サーバー: 2 インスタンスに設定します。「データに聞く」 (Ask Data) の 1 つのインスタンスが、Data Server があるノードで自動的に構成されます。

  • Index and Search Server: indexandsearchserver.vmopts TSM 構成オプションを使用して、パフォーマンスが向上するように Index and Search Server のメモリを構成できます。詳細については、tsm configuration set のオプションを参照してください。

  • その他のすべてのプロセスは、ハードウェアに関係なく、プロセスのインスタンスを 1 つだけインストールします。インタラクティブなマイクロサービス コンテナーの 1 つのインスタンスがアプリケーション サーバーが有効になっているノードにインストールされ、インタラクティブでないマイクロサービス コンテナーの 1 つのインスタンスがバックグラウンダーが有効になっているノードにインストールされます。

• 追加ノードでバックグラウンダーを隔離します。このノードで実行するバックグラウンダー プロセスの最小数を計算するには、コンピューターの物理コアの合計数を 4 で除算します。最大数を計算する場合は、コンピューターの物理コアの合計数を 2 で除算します。上記の例では、どちらのノードも 8 物理コアを備えたマシン上にあります。バックグラウンダーをインストールするとき、Tableau Server によりデータ エンジンの 1 つのインスタンスが自動的にインストールされます。

注: この構成では、Tableau Server で Tableau Prep Conductor が有効になっていないことを前提としています。Tableau Prep Conductor を使用してフローのスケジュールと管理を行っており、抽出負荷の高い環境の場合、最低 3 つのノードがあり、このトピックで後述する 3 ノード構成を使用することをお勧めします。

パフォーマンスと利用状況に関するデータを監視および収集しながら、これらのプロセスのインスタンス数を微調整および構成できます。たとえば、バックグラウンダーを実行する専用のノードで、最初はバックグラウンダーの数を推奨最小値 (コアの合計数を 4 で割る) に設定しておき、後で次のような状況が発生したら、バックグラウンダー プロセスの数を増やします。

• 抽出の更新の完了に時間がかかっている

• サブスクリプションおよびアラートが時間どおりに完了していない

専用のバックグラウンダー ノードの場合、ワークロードとシステム リソースに応じて、バックグラウンダー インスタンスの数を上記の推奨最大値よりも増やすことができる場合があります。ノード上のバックグラウンダーのインスタンスを増やすと、ノードの機能にプラスとマイナスの影響を与えることがあります。ユーザーには、RAM や CPU リソースや Tableau Server のその他の側面を注意深く監視し、お使いの環境に最適な構成を決定する責任があります。

パフォーマンス調整の詳細については、パフォーマンスの調整トピックを参照してください。

2 ノード インストール - フロー環境用

Tableau Server でフローのパブリッシュ、スケジュール、管理を計画している場合、2 ノード構成から開始します。

重要: 2 ノード構成は、高可用性のための最小要件を満たしません。可用性の高いシステムが必要な場合は、高可用性インストール (HA)を参照してください。

サーバー構成

• 最初のノードで、すべてのプロセスをインストールします。以下は、8 コア マシン用のプロセスのインスタンス数です。

  • VizQL Server: 2 インスタンスに設定します(既定の計算: 物理コア数を 4 で割る、最大 4)。

  • キャッシュ サーバーおよびデータ サーバー: 2 インスタンスに設定します。「データに聞く」 (Ask Data) の 1 つのインスタンスが、Data Server があるノードで自動的に構成されます。

  • バックグラウンダー: 最小 2、最大 4。上の図は、8 コア ノード用の最大数が表示されています。Tableau Prep Conductor では、バックグラウンダーがインストールされているノードが自動的に 1 つ構成されます。最初のノードで tsm topology set-node-role の tsm 構成を使用し、フローを含むすべてのジョブ タイプを実行するようにバックグラウンダー ノードの役割を設定します。詳細については、tsm topology set-node-roleを参照してください。

  • Index and Search Server: indexandsearchserver.vmopts TSM 構成オプションを使用して、パフォーマンスが向上するように Index and Search Server のメモリを構成できます。詳細については、tsm configuration set のオプションを参照してください。

  • その他のすべてのプロセスは、ハードウェアに関係なく、プロセスのインスタンスを 1 つだけインストールします。インタラクティブなマイクロサービス コンテナーの 1 つのインスタンスがアプリケーション サーバーが有効になっているノードにインストールされ、インタラクティブでないマイクロサービス コンテナーの 1 つのインスタンスがバックグラウンダーが有効になっているノードにインストールされます。

• フローのみを実行する追加ノードでバックグラウンダーを分離しました。この設定を構成するには、tsm topology set-node-role の tsm 構成を使用します。詳細については、tsm topology set-node-roleを参照してください。

注: 抽出負荷の高い環境があり、サーバー上のフローのスケジュールと管理を行う場合は、以下の 3 のノード構成を使用することをお勧めします。

高可用性インストール (HA)

推奨事項

Tableau Server で可用性の高いインストールは、Tableau Server の可用性を最大化するように設計された分散インストールです。高可用性とは、基本的に、システムでダウンタイムを最小限に抑えながら利用可能な状態を保つことです。リポジトリ、ファイルの冗長性、フェールオーバーなど HA に関連するアイテムの冗長性を組み込むには、最低でも 3 つのノードが必要です。ダウンタイムに対する許容度は各組織によってさまざまであり、組織で確立されている SLA によって異なります。

高可用性を実現するには、単一障害点をなくし、障害を検出し、信頼性の高いフェールオーバー システムを構築する必要があります。Tableau Server の HA は、主に次の要素によって実現されます。

• 複数のファイル ストア/データ エンジン インスタンスによるファイルの冗長性。

• 2 つのノードにまたがるアクティブ/パッシブ リポジトリ。

• 3 つのノードすべてにまたがる Index and Search Server

• 外部ロード バランサーの追加。それにより、インストール環境がゲートウェイ障害に対して堅牢になります。また、機能しているゲートウェイ プロセスのみに要求が送られるようになります。

サーバー構成

3 ノード構成:

• 冗長性を組み込むには、リポジトリやファイル ストア/データ エンジン プロセスのホスト インスタンスに追加ノードを追加する必要があります。ノード上のプロセスの複数インスタンスを含め、その他のプロセスのインスタンスを追加することができます。

• バックグラウンド ジョブのタイプで冗長性を持たせるには、いずれかのノード (この例では最初のノード) ですべてのタイプのジョブを実行します。バックグラウンダーは既定ですべてのタイプのジョブを実行します。追加ノードのいずれかでフローのみを実行するようにバックグラウンダーを設定し、他の追加ノードではフロー以外のすべてのジョブを実行するように設定します。

• Tableau Server が正常に機能するかは、調整サービスが正常に機能しているかに依存します。3 ノード以上のサーバー インストールでは、新しい調整サービス アンサンブルを展開することによって、調整サービスの別のインスタンスを追加することをお勧めします。これにより、調整サービスのインスタンスの 1 つに問題が発生した場合に冗長性および向上された可用性が提供されます。詳細については、調整サービス アンサンブルの展開を参照してください。

• Index and Search Server のメモリは、冗長性確保のために 3 つのノードすべてに追加されているため、indexandsearchserver.vmopts TSM 構成オプションを使用して、パフォーマンスが向上するように構成することができます。詳細については、「indexandsearchserver.vmopts」を参照してください。

• システムの脆弱性を緩和するために、複数ゲートウェイおよび一部のサーバー プロセスの追加インスタンスを実行することができます。この構成を達成するには最低 3 台のコンピューターが必要です。

• リポジトリも最初のノードから追加ノードの 1 つに移動され、2 番目のパッシブ インスタンスが他の新しいノードに追加されました。

• インタラクティブなマイクロサービス コンテナーの 1 つのインスタンスがアプリケーション サーバーが有効になっているノードにインストールされ、インタラクティブでないマイクロサービス コンテナーの 1 つのインスタンスがバックグラウンダーが有効になっているノードにインストールされます。

注: 特定の状況で、最初のノードで実行するプロセスを制限したい場合があるかもしれません。たとえば、ノード上でプロセスするリクエストを制限するために、実行するプロセス数をできるだけ少なくしたい場合などです。また、コアベースのライセンスがあり、最初のノードのコアでコアの使用をカウントされたくない場合、ライセンスされた Tableau Server プロセスをノードから削除することがあるかもしれません。Tableau Server ライセンス プロセスの詳細については、ノードのTableau Server プロセスを参照してください。

仮想マシンおよびパブリック クラウド展開

一般的に、このトピックで説明されている考慮事項と推奨事項は、仮想環境およびクラウド展開に適用されます。

仮想環境で Tableau Server を実行している場合は、VM ホスト上の物理 CPU コア数と関連して、vCPU 割り当てに対して VM ホストのベスト プラクティスを使用します。通常、Tableau Server の場合は 2 vCPU = 1 物理コアです。たとえば、AWS インストールでは、4 コアの最小推奨事項が 8 AWS vCPU に相当します。

クラウドベース展開の詳細については、以下を参照してください。

• パブリック クラウド サービスで Tableau Server をセルフホストする

ベースライン以上の構成

ここで説明した制限を超える構成のシステムを計画している場合は、 Tableau プロフェッショナル サービス(新しいウィンドウでリンクが開く) にお問い合わせください。

高 VizQL のピーク使用に関する考慮事項

Tableau Server のパフォーマンスを最適化するには、展開内の専用ノードでリポジトリを分離することをお勧めします。Advanced Management ライセンスをお持ちの場合は、リポジトリを外部データベースとして実行することを検討してください。

組織のピーク負荷が 1 時間あたり 1000 VizQL セッションを超える場合は、Tableau Server on Linux を実行することもお勧めします。このシナリオでは、VizQL セッションは、Tableau Server からビジュアライゼーションを表示または生成するユーザー アクションのことを指します。

詳細については、「Tableau Server 外部リポジトリ(新しいウィンドウでリンクが開く)」を参照してください。

災害復旧の考慮事項

可用性の高い構成によってダウンタイムは減少しますが、それでも災害が起きたりハードウェアが故障したりした場合には、障害が発生する可能性があります。上記の考慮事項に加えて、組織において災害復旧の重要性を評価し、災害復旧の目標と目的を満たすことができる展開を計画する必要があります。

Tableau 環境で災害復旧 (DR) の計画を立てる場合、考慮すべき重要な要素が 2 つあります。

• 目標復旧時間 (RTO)。業務において完全復旧までの許容できるダウンタイム時間の指標。

  • バックアップの代替クラスターへの復元頻度とインフラへの投資額に影響します。

• 目標復旧時点 (RPO)。業務において許容できるデータ損失量の指標。

  • システムのバックアップの取得頻度に影響します。

  • Tableau Server の場合、RPO は、サーバーのフル バックアップを完了するのにかかる時間よりも短くすることはできません。

以下の図は、さまざまな RTO 要件に対応するための計画の立て方を示しています。

Tableau Server のスケーラビリティ

ニーズは変化したり増加したりするので、これらのベースライン構成では十分でない可能性があり、これらの構成以上に Tableau Server を拡張する必要が生じる場合があります。他のエンタープライズ プラットフォームと同様に、Tableau Server は、プロセッサー、メモリ、およびディスクを既存のノードに追加することでスケール アップできます。また、クラスターにノードをさらに追加することでスケール アウトすることもできます。ただし、スケーラビリティおよびパフォーマンスは、外部システムやユーザー アクティビティに大きく依存します。Tableau Server の構成は、以下のような要件や変数によって異なります。

Tableau Server のスケーラビリティおよびスケーラビリティに影響を及ぼす変数の詳細については、ホワイトペーパー「Tableau Server のスケーラビリティ」(英語) を参照してください。