#tableau #data17 [レポート] Tableau Server のチューニング: パフォーマンス SWAT チームによるヒント – Tableau Conference On Tour 2017 Tokyo

先日2017/04/18(火)〜2017/04/19(水)の2日間に渡り、ウェスティンホテル東京@恵比寿にて行われたカンファレンスイベント
Tableau Conference 2017 On Tour Tokyo』。

screenshot 2017-04-24 2.31.34

当エントリでは、イベント1日目(2017/04/18)のテクニカルセッション『Tableau Server のチューニング: パフォーマンス SWAT チームによるヒント』についてその内容をご紹介したいと思います。

目次

 

セッション情報:概要

事前に公開されていたセッションの概要情報は以下となります。

企業の Tableau Server 環境をチューニングしてパフォーマンスを最大限に引き出すための方法やヒントを、Tableau のパフォーマンス SWAT チームから学びましょう。
内容は次のとおりです。
- 用途に基づいたトポロジの調整
- 大きなインパクトをもたらすワークブックでの小さな工夫
- Tableau Server のパフォーマンスのさまざまな側面を監視する方法
- Tableau のリソース利用の仕組み
- データベースの微調整によるクエリ回数の削減

Speaker: 野口 健二
レベル: Jedi
タイプ: ブレイクアウトセッション
場所: スタールーム A

 

セッション内容レポート

 

パフォーマンス問題をどのように知るか

だいたい以下のようなタイミング、状況で問題が顕在化する事が多い。

data17-tableau-server-tuning-swat-tips_01

 

特定するためのツール群

Tableau Serverに於いては、以下観点でそれぞれパフォーマンスの情報を知る事が出来る。

目的 ツール おおよそ掛かるであろう期間
Windowsシステムのパフォーマンスを確認 タスクマネージャー Windowsユーザーなら
すぐに動かせる
ある指標でWindowsシステムの
パフォーマンスを記録
パフォーマンスモニター Windowsユーザーなら
おおよそ半日学べば動かせる
分散構成のTableau Serverの
パフォーマンスを一元的に記録
TabMon 前提はパフォーマンスモニターの
スキルとTableau Serverのスキル。
その上で2〜3日学べば動かせる
特定のワークブックの
パフォーマンスを評価
パフォーマンスレコーダー Tableauユーザーなら
おおよそ半日学べば動かせる
Tableau Serverの
関連イベントを全て分析
ログ分析(Logshark) 前提はTableau Server管理者スキルと
動作環境。その上で
3〜5日あれば動かせる

 

タスクマネージャー

[プロセス]ビューを使用して最もリソースを使用しているプロセスを確認。

 

パフォーマンスモニター

 

TabMon

 

パフォーマンスレコーダー

 

ログ分析(Logshark)

 

回避するための検討事項

 

ワークブックの設計

  • ビュー内のフィルターの数を減らす
  • 機能として使用出来るマークの数を検討する
  • クロス集計を大量に使用しないようにする
  • 各ダッシュボード内のビューの数を検討する
  • 以下ホワイトペーパーは必読!(※ログイン必要)

 

データベースの設計

  • 列は少ないほうが良い
  • トラフィックが多いワークブックではマテリアライズド・ビューの作成も検討
  • DBの主要なディメンションにインデックスを付与
  • ワークブックにデータソースフィルターを適用
  • 良く利用されるデータソースの抽出をパブリッシュして一元管理
  • 抽出を最適化して関連のある列と行のみを含める事で、Vizの読み込み中にフィルタリングや処理が必要なデータの量を減らす事が出来る
  • クエリアナライザー
    • 殆どの商用データベースではクエリ分析ツールを利用可能
    • 分析結果を取得してDB管理者と会話

 

Tableauトポロジ

Tableau Serverのプロセス数に関するTipsは以下。

  • Tableau Server プロセス
  • ユーザーからのトラフィックのピーク時にアクティブなバックグラウンダーがある場合、分散構成に拡張する事を検討、バックグラウンダーを別のノードで動かす。
  • プロセッサとVizQLプロセスの比率は1:4以内にする
  • パフォーマンスを低下させない範囲で、少ないプロセス数でキャッシュサーバを実行する事でシステムのオーバーヘッドを削減可能
  • 分散構成の場合、クラスター全体でZookeeperの数は最大3または5に維持

 

VMリソースの割り当て

  • VMを割り当てる場合、Tableauが『計算に大きな負荷が掛かるアプリケーションである』事を念頭に置いておく
  • ユーザーに快適なパフォーマンスを提供し続けるにはCPUとメモリのリソースを確保する事が強く推奨される
  • VMWareから公開されたホワイトペーパーでは『メモリとCPUを100%を確保』しておく事が推奨されている。これはTableauがリソースに対する優先権を持つように設定し、負荷が急上昇した場合に待つ必要が無いようにするという事

 

ウィルス対策(ソフトウェアへの対策)

  • Tableauはレイテンシーの影響を受け易く、ウイルス対策(ソフトウェア)によってはユーザーが速度低下を体感するレベルにまで影響が出る事も。
  • セキュリティソフトウェアの中にはフィルタドライバーとして動作するものも
  • 会社のポリシーによってウイルス対策が必要な場合、ITチームと協力してTableauのディレクトリを除外リストに追加するのが最善
  • アクティブスキャンを実行する必要がある場合、サーバーの使用率が低い時間帯にスケジュールを設定

 

エフェメラルポート

『エフェメラルポート』=特定の用途(プロトコルでの使用が推奨されておらず、一時的な通信のために自由に利用できるポート。「ephemeral」は「短命な」の意。(※参考: エフェメラルポートとは - IT用語辞典)

  • TableauプロセスではTCP/IPを使用してお互いに通信するため、利用可能になっているポートの数がパフォーマンスに影響。
  • Windowsサーバのデフォルトでは、49152〜65535のポートが解放されている
  • 利用可能なポート数を増やし、Tableauプロセス間のスループットを向上可能
  • 関連記事(これで合ってるかな?)
  • この設定変更によってシステムのスループットを大幅に向上出来た例も

 

処理能力の強化

  • リソースを融通しあう事で処理能力が制限される場合がある
  • メモリの消耗によってパフォーマンスが低下している場合、メモリを追加する事で簡単に解決出来る場合もある
  • パフォーマンスの問題が特定の時間でピークになり発生している場合、ピーク時の使用量をベースにリソースを追加するか、一時的なパフォーマンス低下を受け入れる

 

まとめ

という訳で、Tableau SWATチームによるTableau Serverのパフォーマンスチューニングに関するセッション内容のご紹介でした。こうしてみると色々な観点・ポイントで改善出来る要素がある事が分かりますね。情報を整理し、今後の展開に向けて活用していきたいところです。

参考情報