AWS 上の Tableau Server のパフォーマンスを最適化する

これはアーカイブされたコンテンツです

パブリック クラウドへの展開は引き続きサポートされますが、サードパーティーのパブリック クラウドへの展開に関するコンテンツは更新されなくなります。

Tableau Server の展開の最新コンテンツについては、「Tableau Server 導入ガイド(新しいウィンドウでリンクが開く)」および Tableau Server ヘルプの「」「展開(新しいウィンドウでリンクが開く)」セクションを参照してください。

アクセスが可能な場合は、Tableau Cloud を使用することをお勧めします。詳細については、以下を参照してください。

概要

AWS Cloud 内の Amazon EC2 インスタンス上にインストールする Tableau Server のパフォーマンスを最適化することで、Tableau Server 製品をより細かくカスタマイズできるようになります。このセクションは、クラウド用に Tableau Server を調整する方法を取り扱います。一般的なパフォーマンス調整の情報については、「Tableau Server パフォーマンスの概要」を参照してください。パフォーマンスの最適化に役立つ各種ツールの情報については、「パフォーマンス関連リソース」を参照してください。

作業負荷はユーザー毎に異なるため、AWS に Tableau Server を展開する方法は一人ひとり異なるという点をしっかり理解しておいてください。従業員は一人ひとり異なっています。活用するデータや抱く疑問はそれぞれ異なり、ビジネス ニーズも企業毎に違います。そのため、本番環境に移る前に、Tableau Server の作業負荷を様々な種類の Amazon EC2 インスタンスでテストすることが推奨されます。この作業負荷に関する要件は、次のような要素に影響されることが多くあります。

  • Tableau データ抽出の使用量の程度

  • 視覚化およびダッシュボードを閲覧するだけのユーザーと、操作するユーザーの割合

  • 業務時間中あるいは業務時間後に行われる Tableau データ抽出の更新

  • 任意の時点における同時アクセス ユーザー数

  • ビューおよびダッシュボードの複雑さ

  • Tableau Web 作成を利用するユーザーの規模

インスタンスの種類を正しく選択しやすくする上で、役立つガイドラインがいくつかあります。Tableau が開発した無料のスケーラビリティ診断ツール「TabJolt」を使えば、Amazon EC2 インスタンスに対して負荷テストを実行し、次のメトリクスに基づいてパフォーマンスやスケーラビリティを検証することができます。

  • 実行中の仮想ユーザーの数

  • 秒あたりの平均トランザクション数

  • 処理成功時の平均応答時間

  • エラーが発生する割合の平均値 (このテストでは、60 秒以内に描画できなかった viz がすべてエラーだとみなされます)

パフォーマンスのベスト プラクティス

Tableau を AWS 上に展開する際、次のパフォーマンスに関するベスト プラクティスが役立つでしょう。

  • Amazon EC2 インスタンス 1 つにつき 8 コア以上を常に実行する

    ユーザー数が比較的少ない場合でも、EC2 インスタンスの vCPU が 16 (8 コアに相当) 未満の場合、安定したパフォーマンスは得られません。たとえば、vCPU が 8 つの r4.2xlarge インスタンス 2 つよりも、vCPU が 16 個の r4.4xlarge インスタンス単体の方がより多くのユーザーに対応でき、応答時間も短くエラーも少なくなります。この性質はスケールアップしても変わらず、16vCPU のインスタンス 4 つや 32vCPU インスタンス 2 つの方が、8vCPU インスタンス 8 つの場合よりもパフォーマンスがずっと優れています。

  • 作業負荷が結果に大きく影響

    各種の EC2 インスタンスにおけるパフォーマンスは、作業負荷のロバストネスに大きく影響されます。たとえば、ダッシュボードの組み合わせを変えるだけで、同じ仮想マシン インスタンス上でもパフォーマンスに目立った差が生じることがわかるでしょう。自分の環境のものとは異なる作業負荷を使ってパフォーマンスを比較しようと試みるのは、あまり有効ではありません。

  • CPU は多い程良い

    Tableau Server のパフォーマンスを低下させる一番のボトルネックになりやすいのが、CPU です。一般的に、Tableau でより多くの作業を行いたい場合、CPU の性能を上げたり、数を増やしたりすることが推奨されます。

  • Amazon EC2 インスタンスが十分な RAM を備えていることを確認する

    CPU が少ないながらも RAM が多いインスタンスに同じ作業負荷をかけると、秒あたりのトランザクション数 (TPS) が増え、応答時間が短くなり、エラーが発生しにくくなります。EC2 インスタンスの RAM が少なすぎる場合、ハイエンドの CPU のメリットがなくなってしまいます。本番環境の場合、最低でも 30 GB の RAM を実行しつつも、1 コアあたり 8 GB を目指してください。CPU が多いインスタンスを選択するのが重要である一方で、CPU がいくら豊富にあっても、RAM が少ないインスタンス上で Tableau Server を実行すると、パフォーマンスの低下につながります。

  • SSD ベースのストレージは役立つが、Provisioned IOPS は必要でない場合がある

    Tableau Server は、システムのメタデータを保存する非常に高機能なデータベース (PostgreSQL) を含めて、数々のプロセスやコンポーネントを隠蔽します。Tableau Server が優れたパフォーマンス発揮するためには適切なレベルのディスク スループットが求められるため、Amazon Elastic Block Store (EBS) の SSD ベースのストレージを使用することをお勧めします。磁気ディスクには、データベースのリクエストを効果的に処理できるだけのスループットがありません。弊社は、大抵のテストで EBS ディスクを 2 つ使用しつつ、汎用 SSD (gp2) および EBS プロビジョンド IOPS ボリュームの両方を実行してテストを行っています。その際、大抵の EBS ボリュームのプロビジョンド IOPS は 1500 でした。汎用 SSD でテストを行ったところ、中程度の作業負荷がかかる場合とほぼ同じ結果が得られました。プロビジョンド IOPS によって AWS 上の Tableau Server の作業量に関するパフォーマンスに目立った差が出る場合も確かにありますが、初期状態で必ずプロビジョンド IOPS が必要だと仮定する必要はありません。もちろん、判断を下す最適な方法は、ご自身の Tableau Server の作業負荷を自らテストしてみることです。

  • TabJolt を使って自らテストを実施

    作業負荷や Amazon EC2 インスタンスの設定によって、Tableau Server のパフォーマンスが大きく左右される場合があります。EC2 は柔軟性に優れているため、それぞれのニーズに最適な設定の組み合わせやインスタンスの種類を判断しやすくなっています。たとえば、RAM と CPU を大きく消費するプロセスをクラスタ内の全部のマシンで実行するのではなく、一部のマシンに隔離することで、秒あたりのトランザクション数 (TPS) に劇的な違いが生じます。異なる環境の作業負荷でパフォーマンス特性を比較したいと思う気持ちは抑えてください。そうするのが便利なのは確かですが、あまり有効な行為ではありません。その代わりに、同じ作業負荷を使ってご自身のハードウェアおよびソフトウェアの構成を吟味することで、最適な結果が得られます。AWS ではこの作業を非常に簡単に行えます。