ハードウェアプラットフォーム
このコンテンツは、Tableau Blueprint の一部です。Tableau Blueprint は、組織がデータの活用方法を拡大および改善して、影響力を強化できるよう支援する成熟したフレームワークです。使用を開始する前に、まず評価(新しいウィンドウでリンクが開く)を受けてください。
注: このトピックは、Tableau Server にのみ適用されます。
Tableau Server は、オンプレミスの物理マシンや仮想マシンにもクラウドにもインストールでき、オペレーティングシステムは Windows と Linux をサポートしています。ハードウェアプラットフォームとサイジングを決定する場合は、要素として、環境、セルフサービスのデータアクセスを行えるようにするためのデータソースと管理、全ユーザーの見込みワークロード、実際の使用状況データを考慮に入れてください。また、Tableau Server を初めて導入するのであれば、環境の標準値とデータソースに目を向ける必要があります。既存の導入環境では、Tableau Server データを分析し、環境とデータソースに加えてワークロードや使用状況を評価しましょう。
ハードウェア要件
Tableau Server をどこに導入するかにかかわらず、欠かせないのは適切にサイジングしたハードウェアです。計画は変化し続けるビジネスニーズに従って策定する必要があり、それにはサーバー使用状況とユーザーエンゲージメントの評価、拡張、トポロジの変更を、他のソフトウェアアプリケーションより頻繁に行います。以下の中から、社内標準に合ったハードウェアプラットフォームのリンクをご覧ください。
- 推奨されるベースライン構成 (Windows | Linux)
- VMware vSphere 上の Tableau Server
- AWS インスタンスの種別とサイズ (Windows | Linux)
Tableau Server をクラウドで導入する場合、専用ハードウェアを使用して RAM を静的に割り当てると、リソース競合によるパフォーマンスの変動を抑えることができます。コストを考慮しなければならない場合は、仮想ハードウェアも使用可能です。ニーズに最適な構成を見出すために、使用しているインフラストラクチャをテストすることをお勧めします。テストの実施方法例については、EC2 の速度での Tableau 稼働に関するホワイトペーパーをご覧ください(この実験は AWS で行われましたが、テストの方法論はどのクラウドプロバイダーにも適用できます)。
当初のサイジング
担当の Tableau アカウントチームも、要件の評価やサイジングのサポートでお手伝いします。Tableau を初めて導入する場合は、アクティブユーザー (ノート PC やモバイルデバイスでのダッシュボード利用、Web 作成、パブリッシュされたデータソースへの接続とクエリなどの、Tableau Server に対するインタラクティブな同時要求) が 10% とすれば、8 コアのノードごとに 600 ～ 800 の Explorer と見積もってください。これは単なる出発点であり、初期導入以降でも変わらないサイジングの基準ではありません。メモリは、本番サーバーで 1 コア当たり 8 GB 以上の RAM が必要です。40 コア以下のクラスターでは 8 コアのノードを、40 コア以上のクラスターでは 16 コアのノードを使用してください。また、各ライセンスタイプの相対的なワークロードは、ハードウェアのサイジングに織り込む必要があります。Explorer を 1 ユーザーとして数えるとすると、Creator の相対的なワークロードは 2.4 ユーザー分、Viewer の相対的なワークロードは 0.75 ユーザー分になります。このワークロード係数を使うと、クラスターのキャパシティを見積もることができます。下の表では、相当するワークロードの例が各行に示されています。
| Creator | Explorer | Viewer |
|---|---|---|---|
ワークロード 1 | 25 | 300 | 586 |
ワークロード 2 | 50 | 333 | 462 |
ワークロード 3 | 75 | 234 | 514 |
ワークロード 4 | 100 | 171 | 518 |
Creator、Explorer、Viewer の実際のワークロードは、データへの接続と Web 作成の頻度、コンテンツの表示と操作などの Tableau Server 機能の使用状況によって異なることがあります。ユーザーがオンボーディングされ、コンテンツの作成と利用を開始したら、ハードウェア監視ツールと Tableau Server のリポジトリからのデータを使用して、ハードウェアとコンテンツの使用状況を監視し、情報に基づいてサーバーのサイジングを決定する必要があります。詳しくは、「Tableau の監視」と「Tableau のユーザーエンゲージメントとユーザー利用の評価」をご覧ください。
スケーラビリティ
新規導入のシナリオでも既存の導入環境のシナリオでも、目標は先を見越して十分な可用性、キャパシティ、余裕を維持し、リソースの競合を最小限に抑えることにあります。Tableau Server は他のエンタープライズプラットフォームと同様に、プロセッサやメモリ、ディスクを追加してスケールアップを、あるいはクラスターにノードを追加してスケールアウトを行うことができます。Tableau Server は、それぞれの組織に特有の環境やデータ、ワークロード、使用状況の組み合わせに応じて、追加したハードウェアリソースにほぼ比例してスケーリングします。「Tableau のメンテナンス」に従って、定期的に負荷テストとキャパシティプランニングを行ってください。
スケーラビリティとパフォーマンスは、データ取得元、データ量、ネットワーク速度、ユーザーのワークロード、ワークブックのデザインなどの外部システムに大きく左右され、導入が進むに従って短期間で変わることもあります。たとえば、当初の導入では適切にサイジングされたハードウェア構成があるとしましょう。その場合でも、無計画なユーザーオンボーディング、使用状況の監視の欠如、非効率的なワークブック、最適とは言えない抽出の構造、利用のピーク時に設定された更新スケジュールにより、サーバーのパフォーマンスやユーザーエクスペリエンスに大きな影響が出て、複数のインシデントによる結果が積み重なりパフォーマンスが低下することがあります。詳しくは、Tableau Server スケーラビリティのホワイトペーパーをご覧ください。
Tableau Server をクラウドで導入する場合、トポロジのホット変更など、Tableau プラットフォームがすでに持っているあらゆるスケーリング機能の利用が可能です。また、パブリック IP アドレスが変更されていない限り、サーバーを再起動するだけで、プラットフォームの基盤となるマシンを変更できます。
単一ノードの導入環境では、ダウンタイム中に Tableau Server のマシンをオフにして、マシンコストを抑えることもできます。複数ノードのクラスターで同じことを行うと、Tableau は縮退状態になります。しかし、トポロジのホット変更により Tableau Server プロセスの割り当てを状況に応じて変えられるため、マシンコストとキャパシティニーズのバランスを調整することが可能です。なお、需要に応じてマシンの終了やインスタンス作成を行う自動スケーリング機能はサポートされていません。
サーバー環境
本番環境に加えて、アップグレードやサーバートポロジの変更を検証するためのテスト環境を 1 つ用意しておくことをお勧めします。本番環境は、コンテンツの検証、利用拡大、認証のプロセスを持った、本番とサンドボックスのプロジェクトを使ってモダン分析をサポートし、このすべてに 1 つの環境で対応します。こうしたコンテンツ管理プロセスについて詳しくは、「Tableau のガバナンス」をご覧ください。本番環境とテスト環境は、ハードウェア仕様、サーバートポロジ、構成を同一にします。これにより、管理者は本番コンテンツを復元したテスト環境で、アップグレードのテストやベータプログラムへの参加を行えるようになります。
組織の中には、コンテンツの作成、テスト、利用のユースケースを異なる Tableau Server 導入環境に分離するために、IT ポリシーで 3 つの環境 (開発、品質保証、本番) を要件とするところもあります。組織にこの要件がある場合は、Tableau のエンドユーザーライセンス契約で規定されているように 3 つの本番環境と見なされるため、3 つの環境それぞれで別個にライセンスが必要になります。また、本番環境と品質保証環境も、仕様、サーバートポロジ、構成を同一にします。3 つの異なる環境を稼働する必要がある場合は、モダン分析プラットフォームで従来のウォーターフォール型開発サイクルを再現することは避けるようにしてください。さらにユーザーは、厳格なポリシーや、コンテンツが本番環境で使えるようになるまで待つことを避けるために、品質保証環境の方を好んで使う可能性があります。そのため、Tableau Advanced Management の Content Migration Tool や、Tableau の REST API を使ったカスタムワークフローのスクリプトで、本番サーバーへのコンテンツ移行を自動化して、ちょうど良いバランスを確保するようにしましょう。なお、開発環境は、アップグレードのテストやベータプログラムへの参加で使われていない限り、本番や品質保証の環境と同一のハードウェア仕様にする必要はありません。
高可用性
Tableau は可用性の要件に基づいてインストール、構成し、キャパシティや高可用性のための追加ノードを加えてください (Windows | Linux)。ミッションクリティカルなユースケースに対応する場合は、外部ロードバランサーを使った高可用性 (HA) クラスター構成を導入する必要があります (Windows | Linux)。
Tableau Server の HA 導入環境は、3 つ以上のノードに加えて、異なるノードで実行する主なプロセス (リポジトリ、ファイルストア/データエンジン、コーディネーションサービス) の複数の冗長インスタンスを持ちます。その目的は、単一障害点を排除し、そして可能であれば障害を検出しフェールオーバーを行えるようにして、システムのダウンタイムを最小限に抑えることです。詳しくは、ホワイトペーパー「Tableau Server の高可用性」をご覧ください。
HA クラスターの構築は、以下の手順に従ってください。
- 最初のノードをインストールし、アーキテクチャを認識するスマートなインストーラーにプロセスを構成させます (Windows | Linux)。アクティブリポジトリはノード 1 にあります。
- プロセスの構成を他の VizQL ノードにレプリケートして、冗長性を確保します (Windows | Linux)。パッシブリポジトリはノード 2 にあります。ノード 3 のプロセスはノード 1 と 2 をミラーリングしますが、リポジトリプロセスはありません。
- コーディネーションサービスアンサンブルとクライアントファイルサービスを追加します (Windows | Linux)。
- 外部ロードバランサーを追加します (Windows | Linux)
3 ノードの Tableau Server HA デプロイメント (注: 調整サービスとクライアント ファイル サービスは明示的に示されていません)
専用ノードの必要性は時とともに変わっていきます。抽出が多く頻繁な抽出更新のワークロードは、インタラクティブなビジュアライゼーションのレンダリングのワークロードから分離する必要があります。抽出が多い環境では、データソースの大半が抽出です。非常に大きな抽出がいくつかある場合も、小さな抽出が数多くある場合と同じ扱いが必要になる可能性があります。抽出を頻繁に更新する導入環境 (業務時間中で 1 日に数回など) は、専用のバックグラウンダーノードに分離してください。バックグラウンダープロセスのワークロードを分離するには、下のノード 4 と 5 に示されているように、専用のバックグラウンダーノードを追加して冗長性を確保します。ノード ロールを使用すると、Tableau Server インストールで特定のタイプのワークロードが処理される場所を構成できます。ノード ロール機能を使用すると、リソースを特定のワークロード専用にしたり、ワークロードに合わせて拡張したりできます。バックグラウンダーとファイルストアに対してノードロールを構成する方法について詳しくは、「ノードロールによるワークロード管理」をご覧ください。
5 ノードの Tableau Server HA デプロイメント (注: 調整サービスとクライアント ファイル サービスは明示的に示されていません)
2019.3 より、Amazon Relational Database Service (RDS) に Tableau Server リポジトリを展開することができます。Tableau Server リポジトリは、すべてのユーザー インタラクション、抽出の更新などに関するデータを格納する PostgreSQL データベースです。Amazon RDS では、PostgreSQL 向けにスケーラビリティ、信頼性、高可用性、およびセキュリティが組み込まれています。Tableau Server 外部リポジトリの構成のために AWS と統合することにより、クラウドを展開するこれらの別のメリットを活用することができます。詳細については、「Tableau Server 外部リポジトリ」を参照してください。
Tableau Server をパブリッククラウドで導入する場合、ダウンタイムのリスクをさらに軽減するためのオプションがいくつかあります。たとえば Tableau Server の各ノードは、それ自身の仮想ネットワークにも、異なるアベイラビリティゾーン/ゾーンにも導入することができます。しかし、環境を分割すると、システム全体で待ち時間が増大するというデメリットが生じることもあります。環境を完成させる前に、データコミュニティに対して適切なバランスを取れることを確認するために、パフォーマンスと可用性の両方のテストを検討してください。なお Tableau Server では、異なるリージョンへの複数ノードクラスター導入はサポートされていません。
災害復旧
Tableau 環境で災害復旧 (DR) 計画を立てる場合、考慮すべき重要な要素が 2 つあります。目標復旧時間 (RTO) と目標復旧時点 (RPO) です。RTO とは、社内で許容できる、完全な復旧までのダウンタイムの長さを示す指標であり、バックアップを代替クラスターに復旧する頻度やインフラストラクチャへの投資額に影響を及ぼします。また RPO とは、社内で許容できるデータ損失の量を示す指標であり、システムをバックアップしなければならない頻度に影響を及ぼします。Tableau Server の場合、RPO は、サーバーのフル バックアップを完了するのにかかる時間よりも短くすることはできません。下の表に、RTO 要件の程度に応じて計画を立てる方法を示します。
長い RTO | 中程度の RTO | 短い RTO |
|---|---|---|
停止に備えて新規ハードウェア/仮想マシンを取得 | マシンはプロビジョニング済みだが稼働していない | 本番と同一の構成およびトポロジで常時稼働している専用ハードウェア |
Tableau Server のインストール | Tableau Server はインストール済み | バックアップを定期的にディザスタリカバリ環境に復元 |
新しい環境にバックアップを復元 | 最新のバックアップをコールドスタンバイ環境に復元 | ディザスタリカバリ環境に切り替えるように変更が可能な外部ロードバランサー/DNS ルーティング |
数時間～数日 | 2 ～ 3 時間 | 数分以内
|
Tableau Server をホスティングしているのがオンプレミスであってもクラウドであっても、バックアップ方法は同じです。Tableau サービスマネージャーの backup コマンドを使って、Tableau Server のバックアップ作成や、新しいマシンへのバックアップ復元を行ってください。なお、Tableau Server マシンのスナップショット作成と新しいマシンでの復元はサポートされていません。詳しくは「ミッションクリティカルな信頼性」で、高可用性とディザスタリカバリの概念や、ホワイトペーパーをご覧ください。