ダウンロード - Tableau

Neelesh Kamkolkar、プロダクトマネージャー
Tableau Server 9.0 の
スケーラビリティ: 規模に応じて
セルフサービス分析を提供
2
目次
動機.........................................................................................................................................................4
背景.........................................................................................................................................................4
エグゼクティブサマリー...................................................................................................................5
Tableau Public をサポートする Tableau Server....................................................................6
クラウドスケールでの試験運用...................................................................................................7
新しいアーキテクチャの変更点...................................................................................................8
ハードウェアの新しい最小要件...................................................................................................9
パフォーマンスの向上.....................................................................................................................9
並行クエリ......................................................................................................................................9
クエリ統合................................................................................................................................... 10
キャッシュサーバー – 外部クエリキャッシュ................................................................. 10
データエンジンの水平スケール............................................................................................... 12
その他の改善点............................................................................................................................. 12
スケーラビリティテストの目標................................................................................................... 12
テストの手順と方法....................................................................................................................... 13
仮想マシン......................................................................................................................................... 14
物理マシン......................................................................................................................................... 14
システムの飽和と思考時間....................................................................................................... 15
リトルの法則............................................................................................................................... 17
思考時間..................................................................................................................................... 17
ワークロードミックスの変更........................................................................................................ 18
新しい方法.................................................................................................................................. 19
テストワークブックの例.......................................................................................................... 20
3
抽出の特徴.......................................................................................................................................21
標準化した隔離環境.....................................................................................................................22
導入トポロジ.....................................................................................................................................22
測定とレポート作成.......................................................................................................................23
トランザクション...............................................................................................................................24
スループット......................................................................................................................................24
飽和スループット............................................................................................................................24
応答時間............................................................................................................................................24
同時にアクセスするユーザー数...............................................................................................24
結果......................................................................................................................................................25
Tableau Server 8.3 と 9.0 のスケーラビリティ比較...........................................................25
直線的なスケーリングのスループット....................................................................................26
全体的なハードウェアの所見....................................................................................................26
メモリ..............................................................................................................................................27
ディスクスループット................................................................................................................28
ネットワーク使用率..................................................................................................................28
8 コアシングルマシンの比較...............................................................................................29
メモリ要件の増加.....................................................................................................................31
高可用性の影響.............................................................................................................................32
結果の適用.......................................................................................................................................33
バックグラウンダーの注意点.....................................................................................................33
ベストプラクティス - 自分で行うスケールテスト................................................................34
TabJolt - スケーラビリティテストのツール....................................................................34
最適化のベストプラクティス実例.............................................................................................35
まとめ...................................................................................................................................................36
4
動機
多くのお客様が、規模に応じたセルフサービス分析を行うために、戦略的な選択をして
います。IT 部門でも営業部門でも、Tableau Server をスケールして、世界中にいる自
社のユーザー全員をサポートする仕組みを知りたいと思うのは当然です。またお客様
は、Tableau の導入数の増加に合わせて、キャパシティやハードウェア予算の分配を前
もって計画したいと考えています。
私たちは、Tableau 9.0 リリースプロセスの一環として、Tableau Server 9.0 のスケーラビ
リティの特徴を Tableau Server 8.3 と比較し、その違いを理解するという目標を立てまし
た。また、Tableau Server 9.0 が直線的にスケールしたかどうかや、負荷が増えることで
可用性にどのような影響があったかも把握したいと考えました。
背景
従来の BI に慣れている方や Tableau を初めて使う方は、Tableau と他のソリューション
の主要な違いを知っておくと便利です。
要件を限定して設計開発された従来の BI レポートとは異なり、Tableau のビジュアライ
ゼーションは対話的な操作を実現するように設計されています。ユーザーは自分のデー
タについていくつでも質問をすることができ、新しいビジュアライゼーションを作成するた
めに、従来のソフトウェア開発のライフサイクルを繰り返す必要はありません。
分析環境の規模拡大を行うために、またユーザーの分析作業のフローを止めない環境
を提供するために、Tableau Server 9.0 はこれまで開発されてきた革新的なテクノロジー
に基づいて構築されました。
Tableau は、昔ながらの「最初にクエリ、次にビジュアライゼーション」という考え方を完全
に変えました。VizQL™ などの特許技術を使用して、クエリとビジュアライゼーションを 1 つ
のプロセスにシームレスに統合しました。
ユーザーは、ビジネスの問題を解決することと、データに関する質問をすることに集中で
きます。Tableau では、データを選択して、あらかじめ用意されているグラフの種類から
選ぶような従来のやり方に代わり、ディメンションのドラッグ & ドロップ、データセットのブ
レンド、さまざまなメジャーの計算を繰り返し実行します。このプロセスの最中、Tableau
はわかりやすいビジュアライゼーションを作成すると同時に、必要なクエリをシームレス
に実行します。これは、Tableau Server のスケーラビリティを理解するうえで考慮する必
要がある、今までとは異なるパラダイムです。
従来の BI を使っている方は、特定のサービスレベル契約 (SLA) を満たす負荷テストの
静的レポートに慣れているでしょう。静的レポートには、固定スコープ、固定クエリセット
があり、多くの場合開発者が何週間もかけて 1 つずつ最適化しています。
5
一方、Tableau のビジュアライゼーションでは、ユーザーがさらにデータを調べるための
アクションを実行すると、新しいクエリが再生成されるか送信されます。データをすばやく
取得できるように最適化することにより、ユーザーは分析のフローに留まることができ、
クエリの結果を待つことはありません。Tableau 9.0 では、ユーザーの分析のフローを止
めないように、パフォーマンスをはじめ多くの領域に大きな力を注ぎました。
このホワイトペーパーでは、Tableau Server 9.0 のしくみ、ユーザー負荷の増加に合わせ
てさまざまな構成でスケールする方法、Tableau Server 8.3 と比較したスケーラビリティを
説明します。
エグゼクティブサマリー
Tableau 9.0 は、私たちにとって史上最大のリリースです。2014 年 11 月、9.0 のリリース
サイクルの非常に早い時期に、まだ開発中でしたが、新機能のパフォーマンスのテストお
よびスケーラビリティのテストを開始しました。テストでは、Tableau Server 9.0 のパフォー
マンステストおよび負荷テストに新機能の設計フィードバックを何度も反映しました。
ワークブックのデザイン、サーバー構成、インフラストラクチャの調整、ネットワークなど、
パフォーマンスやスケーラビリティに影響を及ぼす可能性のある要素は多数あります。
テストの目的と方法に基づき、以下の点が確認できました。
1. Tableau Server 9.0 は、テストしたすべてのシナリオでほぼ直線的にスケールできる。
2. Tableau Server 9.0 では、8.3 と比較して、スループットが 200% 以上増加し、応答時間
も大幅に短縮された。
3. Tableau Server 9.0 では、8.3 と比較して、メモリとネットワークの使用率が増加した。
Tableau Server 9.0 には新しいアーキテクチャの変更点が多くあるため、新しいサーバー
設計とお客様の一般的なシナリオでの反復テストに基づいて、クラスタトポロジを選択し
ました。次の表 (図 1) で、各行は、1 ノード - 16 コア、2 ノード - 32 コア、3 ノード - 48 コ
アの Tableau Server 9.0 のクラスタ構成を表しています。
Tableau Server 9.0 は、さまざまな構成で、システムが飽和状態のときに、次のユーザー
数をサポートできることがわかりました。以下の表に示されている同時アクセスユーザー
数は、リトルの法則を使用してサーバーが飽和状態のときに、ビジュアライゼーションに
同時にアクセスし、操作もできるエンドユーザーの人数を表します。
6
このテストシナリオでは、組織または部門の総エンドユーザーの約 10% が同時にビジュ
アライゼーションにアクセスし、操作すると仮定しました。
テストとワークロードに基づき、Tableau Server 9.0 は、16 コアシングルマシン導入の場合で
最大 927 人のユーザーをサポートできることがわかりました。また、表に示すとおり、48 コ
ア、3 ノードのクラスタ設定では、最大 2809 人のユーザーにまでスケールします。
ᑟධᵓᡂ
㻝㻌䝜䞊䝗㻌㻝㻢㻌䝁䜰
㻞㻌䝜䞊䝗㻌㻟㻞㻌䝁䜰
㻟㻌䝜䞊䝗㻌㻠㻤㻌䝁䜰
㼀㼍㼎㼘㼑㼍㼡㻌㻿㼑㼞㼢㼑㼞㻌㻥㻚㻜㻌
ྠ᫬䝴䞊䝄䞊ᩘ
㼀㼍㼎㼘㼑㼍㼡㻌㻿㼑㼞㼢㼑㼞㻌㻥㻚㻜
ྜィ䝴䞊䝄䞊ᩘ
㻥㻞㻚㻣㻡
㻝㻟㻤㻚㻜㻠
㻞㻤㻜㻚㻥㻟
㻥㻞㻣
㻝㻟㻤㻜
㻞㻤㻜㻥
図 1: Tableau Server 9.0 のスケーラビリティのまとめ
また、クラスタにノードを追加することで、Tableau Server 9.0 がほぼ直線的にスケール
することを確認しました。
上の表では 10% の同時ユーザーアクセス (つまり、組織の総ユーザー数の 10% が同時
にビジュアライゼーションを表示または操作する状態) を想定しましたが、同時ユーザー
アクセスのレベルは組織によって異なります。同時アクセスが 1% という低い値の場合も
ありました。
このホワイトペーパーでは、まず Tableau Server のスケーラビリティについて実例を紹
介します。Tableau Server 9.0 のアーキテクチャにおける新しい変更点を説明するほか、
テストの方法と手順を説明して、Tableau Server 9.0 のスケーラビリティを詳しく紹介しま
す。最後に、経験から学んだ知識をお客様の環境に適用していただく際に参考となる点
をお伝えします。
Tableau Public をサポートする Tableau Server
多くの組織において、Tableau Server はクラウドスケール、エンタープライズスケールで導
入が進められています。その中には、Tableau Software での導入もいくつかあります。
Tableau Public は、誰でもインタラクティブデータを Web サイトでパブリッシュできるよう
になる無料の高品質クラウドサービスです。Tableau Public は膨大な数のワークブック、
作成者、リアルタイムビューをサポートします。先日、Tableau Public 各ユーザー向けの
データ抽出サイズを 100 万行から 1,000 万行に、ストレージ容量合計を 10GB まで増や
しました。
7
10 万人を上回る作成者、4 億 5,000 万回を超える閲覧回数、50 万のビジュアライゼー
ションを伴う Tableau Public は、Tableau にとって「自社製品の使用」を可能にする重要
な役割を担っています。
クラウドスケールでの試験運用
自社製品を使用して毎日の業務を行うことは、Tableau の企業文化の基本理念です。
Tableau Public を使うことによって、Tableau Server の新バージョンをテストするためのク
ラウドスケールのテスト環境を作ることができました。製品のリリースプロセスの一環とし
て、Tableau Server のプレリリースソフトウェアを Tableau Public に導入しました。これに
よって、ミッションクリティカルな本番環境において大規模に自社製品を導入できるように
なっただけでなく、スケーラビリティに関する問題を理解し、発見し、解決できるようになっ
たのです。
Tableau Server 9.0 は、9.0 のベータサイクルで Tableau Public に導入しました。このた
め、新しいアーキテクチャが実際の本番環境でどのようにスケールするかを知るだけでな
く、法人のお客様向け製品を発売する前に問題を発見して解決できるようになりました。
図 2: Tableau Public 使用量のポイントインタイムビュー
これまでに、Tableau Public は 4 億 5,000 万回を超える閲覧回数を記録し、先月だけで
も 2,700 万回を超えています。また、10 万人を超える作成者による 50 万個を超えるビ
ジュアライゼーションを作成して Tableau Public にパブリッシュしています。
8
いくつかの例外を除き、Tableau Public の構成は Tableau Server の企業導入と似ていま
す。すべての Tableau Public ユーザーは、データの抽出サイズが最大 1,000 万行に制限
されています。Tableau Public はオープンな無料のプラットフォームであるため、ユーザー
は、公開されているデータにアクセスするときに企業と同等レベルのセキュリティを期待し
ていません。また、Tableau Public はアプリケーションサーバー (VizPortal) プロセスの代
わりに、Author Profile というカスタムのフロントエンドを使用してワークブックを管理してい
ます。
ただし、Tableau Public は毎日何万ものクエリを実行しています。それぞれのデータサイ
ズは比較的小さくとも、相当な多様性があります。
Tableau Server 9.0 を搭載する Tableau Public は、Tableau Server 9.0 の更新されたアー
キテクチャをテストするのに最適な場所となってきました。
新しいアーキテクチャの変更点
Tableau Server 9.0 における新機能の多くは、これまでの Tableau Server のエンタープ
ライズアーキテクチャを拡張、向上させる強固なアーキテクチャを基盤としています。そ
の新機能をサポートするために、Tableau Server では新しいサーバープロセスをいくつ
か追加しました。
Tableau Server 9.0 でスケーラビリティを管理する方法を理解するには、これらのコンポー
ネントを知って役割を把握することが重要です。簡単に示すため、図 3 では、複数のサー
バープロセスを、より上位レベルのサービスレイヤーグループに分けた論理アーキテク
チャにまとめました。
䝀䞊䝖䜴䜵䜲㻌㻔䝸䝞䞊䝇䝥䝻䜻䝅㻕
䝴䞊䝄䞊ᒙ
䝇䝖䝺䞊䝆ᒙ
⟶⌮ᒙ
䝁䞁䝔䞁䝒
⟶⌮
䝃䞊䝡䝇㻖
䝡䝆䝳䜰䝷䜲
䝊䞊䝅䝵䞁
䝃䞊䝡䝇
䝕䞊䝍
䝥䝻䝞䜲䝎䞊
䝃䞊䝡䝇
䝸䝫䝆䝖䝸㻌㻔㻼㼛㼟㼠㼓㼞㼑㼟㻕
䝣䜯䜲䝹㻌䝇䝖䜰㻖
䜽䝷䝇䝍䝁䞁䝖䝻䞊䝷㻖
䝁䞊䝕䜱䝛䞊䝅䝵䞁䝃䞊䝡䝇㻖
䝞䝑䜽䜾䝷䜴䞁䝎䞊
図 3: 単一サーバーノードの論理アーキテクチャ
㻭㻼㻵
䝃䞊䝡䝇
9
複数のサーバープロセスが連携して、さまざまな階層でサービスを実行します。ゲート
ウェイは、データの流れをすべてのサーバーノードに導くコンポーネントです。サーバークラ
スタ (図 3 には示していません) の前に外付けのロードバランサーを配置し、あらゆるノー
ドにゲートウェイを持たせると、可用性がさらに高まります。
ユーザー層は、コンテンツ管理、ビジュアライゼーション、データプロバイダーサービス、
API サービスで構成されます。
ストレージ層は、コンテンツリポジトリと新しいファイルストアプロセスで構成されます。メ
タデータ、パーミッション情報、Tableau ワークブックなどの構造化されたリレーショナル
データは、リポジトリにあります。ファイルストアプロセスは、ユーザーのデータ (Tableau
データ抽出) 用であり、クラスタ全体でデータ抽出ファイルを冗長化できるようにします。
管理層では、サーバー管理者がクラスタを効率的に管理し、高可用性を確保するための一
連のサービスが提供されます。
個別のサーバープロセスの詳細については、管理者ガイドをご覧ください。
新しいハードウェア最小要件
サーバーで新機能をサポートするための新しいサービスが導入されたことによって、64 ビッ
トのサーバーインストーラーの最小要件が 4 コア、8 GB RAM に増加しました。インストール
に必要な最小値は 4 コアですが、4 コアのマシンを使用して単一ノードサーバーの負荷テ
ストやスケールテストを行うことはお勧めしません。単一の 4 コアサーバーは通常、小規模
なトライアルやプロトタイピング用です。企業への大規模な導入では、すべてのノードで 16
コアサーバーの使用を検討してください。
パフォーマンスの向上
パフォーマンスが向上すると、エンドユーザーへの応答時間の短縮につながり、会社全
体での Tableau の使用が促進されます。パフォーマンスの向上は、分析フロー全体で実
現しています。ただし、パフォーマンスに影響する要因が多数あるため、実際の結果は
状況によって異なる場合があります。パフォーマンスとスケールの両方に関して、導入を
進める際に役立つ重要な改善点を以下にいくつか取り上げます。
並行クエリ
並行クエリは Tableau がバックエンドのデータベースをさらに効率よく利用することを可
能にし、ユーザーとビジュアライゼーションとのやり取りをスピードアップします。現在、私
たちは Tableau Server 9.0 でバックエンドのデータベースに送信するビジュアライゼーショ
ンのクエリに注目しており、適切な場合には重複を排除して、複数のクエリを同時に送
信します。
10
つまり、Tableau Server はバックエンドデータベースに複数の接続を確立し、可能であれ
ばより多くのデータベースリソースを活用できます。これによって、互換性のあるデータ
ベースが、連続ではなく並行してクエリを実行できるようになるため、クエリ結果が出力さ
れるまでの時間が大幅に短縮されます。この機能が利点となるかどうかは、お使いの
バックエンドデータベースが並行処理にどう対応するかによって決まります。
クエリ統合
名前からもわかるように、ダッシュボードから複数の別々のクエリを取り出し、可能な場
合はそれらを統合し、バックエンドデータベースに送信するクエリの数を減らします。これ
はライブ接続に特に便利です。ただし、組み合わせ可能なクエリをダッシュボードで生成
していない場合は、この最適化は役に立ちません。
」ᩘ䛾䜽䜶䝸
ྠ䛨䜽䜶䝸䜢
≉ᐃ䛧䛶
㏉䛥䜜䜛ิ䜢᤼㝖
㻌㻌
⤫ྜ䛥䜜䛯䜽䜶䝸
ฟຊ䛾㝿䛻䛿
㞟ィ㻛ィ⟬䛷
ิ䜢༊ู
㻌
ᚲせ䛺
䛩䜉䛶䛾ิ䛷
༢୍䛺
䜽䜶䝸䛻⤫ྜ
図 4: Tableau Server 9.0 でのクエリ統合
キャッシュサーバー – 外部クエリキャッシュ
ワークブックをロードしてすべてのクエリを初めて実行したとき、ワークブックを閉じて開
き直しても、バックエンドではデータが変更されていないことがよくあります。
11
これがデータの新しさや使用シナリオの特徴である場合、エンドユーザーがこれらのワー
クブックを 2 回目にロードしたときにはかなり速くなります。今後ユーザーが迅速にアクセ
スできるように、外部クエリキャッシュを使用して、以前のクエリ結果を保存します。
キャッシュサーバープロセスには Redis が搭載されています。Redis は、多くのインター
ネットスケールのプロバイダーで使用されている拡張性の高いキーバリュー型のキャッ
シュです。
䈄
䈄
䜰䝥䝸䜿䞊䝅䝵䞁
䝃䞊䝞䞊
㻭㻼㻵㻌䝃䞊䝞䞊
䈄
㻰㼍㼠㼍
㻿㼑㼞㼢㼑㼞
䈄
䝞䝑䜽䜾䝷
䜴䞁䝎䞊
䈄
㼂㼕㼦㼝㼘
㻿㼑㼞㼢㼑㼞
䜻䝱䝑䝅䝳䝃䞊䝞䞊
䈄㻌ᢳ㇟䜽䜶䝸䜻䝱䝑䝅䝳
䝕䞊䝍䝧䞊䝇
䝕䞊䝍䝧䞊䝇
図 5: キャッシュの仕組みを簡略化した図
この図は、キャッシュサーバー上でのプロセス間のやり取りを簡略化して示しています。簡
単にするために、キャッシュサーバーとやり取りをしない他のプロセスは示していません。
各プロセスには、クエリキャッシュと呼ばれるインメモリのキャッシュがあります。最初に、
サーバープロセスは必要なものをクエリキャッシュで探します。インメモリキャッシュで見つ
からない場合は、必要なものをキャッシュサーバーで見つけようとします。キャッシュサー
バーに結果があれば、インメモリキャッシュにコピーされ、返されます。いずれの場所にも
ない場合は、データベースでクエリが実行され、キャッシュサーバーとそれを必要とするプ
ロセスのインメモリキャッシュに結果が書き込まれます。各キャッシュサーバーのキャッシュ
は、クラスタ全体のすべてのプロセスとノードがアクセスできます。
12
データエンジンの水平スケール
新しい Tableau Server 9.0 のデータエンジンは、メモリおよびクエリへの抽出データのロー
ドを担うコンポーネントであり、クラスタ内で N ノードまで水平拡張できるようになりました。
以前は 2 つのノードまでに制限されていました。これにより、Tableau の抽出を使用してい
るときに、拡張性の高いクラスタを構築することも可能になります。
その他の機能の向上
さらに、並行クエリ (上記) やベクトル化のサポートを追加することで、レンダリングの向
上、より高速な抽出の作成、データサーバーにおける一時テーブルの対応など、データ
エンジン全体で多くの改善が行われました。
Tableau 9.0 製品ライン全体で、多数の新機能や性能が追加されています。上のセクショ
ンでは、主な新しいサーバーコンポーネントとその役割だけを確認しました。
スケーラビリティテストの目的
2014 年 11 月初旬、私たちは Tableau Server 8.3 と比較した Tableau Server 9.0
のスケーラビリティの特徴を、負荷を増やすことによって理解しようと試みました。また、
Tableau Server 9.0 が直線的にスケールされたかどうか、負荷が増えた場合に 3 秒以
内の平均対応時間を維持しながら、そのスケーラビリティが鈍化したり、停止したりする
かどうかも把握しようとしました。
このホワイトペーパーの前半で繰り返し行ったテストの方法、ワークロード、ワークロード
の組み合わせを一貫して保持することが目的ではありませんでした。新リリースに計画
された設計とアーキテクチャの変更に基づいて、これらのすべてを繰り返し更新して、お
知らせする必要がありました。たとえば、Tableau Server 9.0 の新機能を使うワークロー
ドに重点を置いて、お客様の視点から現実的に考えました。
本書の後半で紹介するワークロードからの脱却や方法の変化を考えると、このホワイト
ペーパーで公開された Tableau Server のスケーラビリティの結果を以前のホワイトペー
パーで公開されたスケーラビリティの結果と比較することはできません。テストのバリ
エーションはかなり大きいため、直接比較ができないからです。
本書の目的のため、および以前のリリースとスケーラビリティを比較するために、同じハー
ドウェアを使用して Tableau Server 9.0 と Tableau Server 8.3 に対して同じテストを明示的
に実行しました。両方のテストで同じ方法に従いました。
13
テストの手順と方法
このペーパーで使用した方法の多くは、一般的に使用されるベストプラクティスにだけで
なく、Tableau Server 9.0 での設計変更に基づいています。たとえば、お客様向けのワー
クブックを使用することに加えて、テストの組み合わせに加えた追加のワークブックを吟
味して選びました。これは、導入されている新しい機能を明示的に使用するユーザーの
操作を表すワークブックを必要としていたためです。
全体的に、Tableau Server で実行できるさまざまなワークロードには、エンドユーザーの
ビジュアライゼーションのロードから、自動サブスクリプション、更新ジョブの抽出など多
数あります。方法の一環として、私たちはエンドユーザーのワークロードに焦点を当てま
した。これは、飽和状態でどれくらいのエンドユーザーをシステムでサポートできるかを
把握することが目的の 1 つだったためです。
全体的な能力を計画するときは、同時ユーザーの負荷に加えて、バックグラウンダーを実
行するために必要な能力を計画し、考慮する必要があります。通常は、「N」がマシンのコ
ア数である場合、マシンに N/2 から N/4 の間の数のバックグラウンダーを導入します。
バックグラウンダーに関する詳細なガイドと検討事項は、すでにサーバー管理者ガイド
に記載されています。
ユーザーから見たときに、最も重要になる Tableau Server のプロセスは、VizQL Server
と、新しく改良されたアプリケーションサーバーです。API クライアントからの要求にのみ
対応する API サーバーのような他のプロセスもありますが、エンドユーザーのワークロー
ドに焦点を当てるために、これはテスト方法から除外しています。
VizQL Server プロセスは、意図的に CPU バウンドであり、適切なパフォーマンスとスケー
ラビリティを確保するため十分なリソースを割り当てる必要があります。
14
仮想マシン
多くのお客様が、仮想マシンで Tableau Server を導入し、スケーラブルな実装に成功し
ています。このホワイトペーパーの目的は、物理インフラストラクチャと仮想のインフラス
トラクチャ環境の違いや、利用可能なさまざまな仮想プラットフォーム間の違いを徹底的
に明らかにすることではありません。仮想プラットフォームで得られるパフォーマンスやス
ケーラビリティのレベルも、プラットフォームごとの仮想パラメーターの設定および調整に
よって異なります。たとえば、VMware ESX™ に対しオーバーロードしている CPU を使用
することは Tableau Server には推奨できません。これは、ワークロードが大きいと、他の
アプリケーションが必要なリソースを Tableau Server と取り合う可能性があるためです。
代わりに、専用の CPU アフィニティが設定された VM で Tableau Server を実行すること
を推奨します。お使いの仮想プラットフォームのベストプラクティスについては、仮想プラッ
トフォームのベンダーについてのホワイトペーパーを確認してください。参考までに、いく
つかの VMWare の例を以下に挙げます。
Performance Best Practices for vSphere 5.5 guide (vSphere 5.5 向けパフォーマンスの
ベストプラクティスガイド)
Deploying Extremely Latency-Sensitive Applications in vSphere 5.5 (vSphere 5.5 にお
ける遅延を許容しないアプリケーションの導入)
Tableau Server 9.0 は、任意の仮想化プラットフォームでサーバークラスのアプリケーショ
ンとして実行されます。十分なコンピュートリソースが必要とされるため、導入の際には
注意してください。導入の際は、お使いの仮想プラットフォームのベンダーに、サーバー
導入の調整サポートを依頼することを推奨します。
物理マシン
各物理マシンの導入は、多くの要因によって異なります。これらの実験の目的のために、
私たちは、仮想化プラットフォームおよびそれらのプラットフォーム特有の設定のばらつき
を最小限に抑えようとしました。そこで私たちは、ネットワークが隔離されたラボに、同一
のハードウェア構成の物理マシンを設置し、Tableau Server 9.0 クラスタを実装しました。
各テストにおいて、さまざまなクラスタトポロジでの 16、32、48 コアに対し、あらかじめ定
義したワークロードと負荷の組み合わせを実行しました。テストを繰り返しながら、主要な
パフォーマンス指標だけでなく、JMX を使ってシステム指標とアプリケーションサーバー
指標も記録しました。各テストにおいて、得られたデータを相関させ、ユーザーによる負荷
が増加していくとシステムがどのように動作するかを分析しました。一連のテストを繰り返
すごとにアーキテクチャを変更し、Tableau のアーキテクチャチームとともに結果を確認し
て、次に行うテスト内容や方法について検討を行いました。また、アジャイル開発プロセス
の一環として、スケーラビリティのバグの検出と修正も行いました。
15
多くの実験を行うことにより、最終テストの導入トポロジが確定しました。これらの実験で
は、サーバーのスケーラビリティがさまざまなサーバーコンポーネントの動作にどのよう
な影響を与えるかについても調査しました。これらの結果は、このホワイトペーパーで紹
介します。
全部で、1 トポロジにわたり 1000 回以上のテストを繰り返し、1 回のテストが完了するま
でにおよそ 2 時間かかりました。多くのワーカーをクラスタに追加することによって負荷
が増加するのに対しシステムがどのようにスケールするかを理解するため、負荷テスト
中にさまざまなシステム指標とアプリケーション指標を測定、収集しました。
システムの飽和と思考時間
多くの場合、インフラストラクチャチームは、さまざまなサーバープロセスとマシンの CPU
を測定し、監視したいと考えています。一般的に、インフラストラクチャチームは、バース
ト負荷に備えて、十分に余裕のある CPU 容量を必要とします。
たとえば、インフラストラクチャの視点から見ると、80% の CPU 使用率は、飽和を示す優
れた指標となる可能性があります。しかし、Tableau Server 9.0 は多大な作業負荷に対
応するため、作業を行うのに十分な計算能力が必要です。サーバークラスタ内のプロセ
スの一部が CPU サイクルの 100% を占めていることがよくあります。これは意図的に行
われており、インフラストラクチャチームが監視計画の一環として考慮すべきことです。
私たちは、ピークスループットの飽和を再現した負荷テスト中に、システムの飽和ポイン
トを明確に測定しました。その際、平均応答時間が 3 秒を超えないという上限を設定し
ました。報告された数値を冷静に把握するため、平均待ち時間が 3 秒を超えた場合は、
クライアントのスループットがさらに増加するのを無視しました。
この実験でわかったのは、新しいユーザーがシステムに追加されると遅延は増えるもの
の、システムに対して増加するユーザー負荷に Tableau Server が耐えうるということで
す。また、飽和を測定するポイントを選ぶため、1% 未満の誤差率 (ソケット、HTTP など)
の目標を設定しました。
16
以下は Tableau 8.3 と Tableau 9.0 を比較し、システムの飽和状態で行った測定の概要
図です。この図は、TPS、平均応答時間、同時ユーザー (リトルの法則を使用)、エラー率
などの KPI を示しています。
図 6: システムの飽和点を示す 1 つのテストシナリオ
飽和状態でのスループットと応答時間を決定した後、リトルの法則を使ってシステムの
同時ユーザー数を推定しました。
17
リトルの法則
これらのテストの目標は、システムが容量の限界に達するポイント (そのポイントにおけ
る合計ユーザー数を含む) を判断することにありました。リトルの法則は、このポイントを
非常に適切に示すのに役立ちます。
バリスタが 1 人で一度に 1 人の客の応対しかできない小さなカフェがあるとします。客
が入ってきて、コーヒーを買って、出ていきます。普通のコーヒー 1 杯ならすぐに出せま
すが、複雑なドリンクになると、時間がかかります。さらに、バリスタがドリンクを準備する
のに手順書を確認する時間が加われば、その客にサービスを提供する合計時間は、手
順書を見直す時間と、ドリンクを作るために必要な時間の合計時間になります。
このエンドツーエンドのサービス時間により、接客して送り出すまでの速度が決まります。
ただし、来店する客の数が退出する客の数を上回ると、店内はいっぱいになり、誰も入
れなくなります。カフェの収容能力は最大限度に達します。任意の時点で店内にいる客
の最大数を決める変数は、客が店に滞在する時間の長さ、客が注文するドリンクの複雑
さ、接客する店員数です。
コーヒーショップのたとえ話を Tableau Server に当てはめるために、各バリスタが
VizQL Server のプロセスと考えてみます。コーヒーは、ビジュアライゼーションをロードし
たり、エンドユーザーがダッシュボードを操作したりするのに似ています。次に、ビジュア
ライゼーションを同時にロードしたり操作したりするエンドユーザーの数は、平均応答時
間と飽和スループットの積となります。
同時ユーザー数 = 平均応答時間 x 飽和スループット
このたとえ話で、CPU は何を表すでしょうか。ここでは、バリスタが実際に作業するエ
スプレッソマシン、ジューサー、ミキサー、コーヒーディスペンサーなどのハードウェアを
CPU に例えることができます。一度に 4 杯ではなく、1 杯のエスプレッソを作ることがで
きるエスプレッソマシンを使用している場合、バリスタが顧客に効率的にサービスを提供
する方法に決定的な違いが生じます。
思考時間
多くの場合、負荷とパフォーマンスのテストチームは、応答時間または負荷テストのシナ
リオに「思考時間」と呼ばれるものを含めます。これは現実的な概念ではありますが、分
析の場合、「思考時間」を予測することは困難です。
18
たとえば、ビジュアライゼーションを見ればすぐに、必要なものをすぐに見つけ出します。
これは非常に短い思考時間です。ただし、場合によっては、何度も繰り返しデータを見て
長い時間検証しなければならないこともあります。このようにデータを検証する時間はす
べて、エンドユーザーの「思考時間」と見なされます。
従来のアプローチでは、これをエンドユーザーによる「遅延」として考えていましたが、私
たちのアプローチでは、この思考時間による遅延を無視し、並行性を追及するためにテ
ストを行うことにしました。実際に、私たちの思考時間はゼロでした。
考えられるユーザーの増加モデルにはさまざまなものがあります。テストでは、前述の定義
した飽和状態に達するまで、アクション間の思考時間がゼロであるユーザーを 1 秒に 1 人
ずつ増やしていきました。
ワークロードミックスの変更
私たちはリリースサイクルの非常に早い段階で、パフォーマンスとスケーラビリティのテ
ストを始めました。その途中、私たちのアプローチを決めるいくつかの重要な決定をしま
した。テストではサーバーの新機能を必ず使用し、実際の顧客のワークブックなど現実
的な使用状況のシナリオを反映するワークロードミックスを使用することを希望していま
した。
以前のホワイトペーパーでも同じトピックを取り上げ、単純、複雑、普通の 3 つにワーク
ロードを定義または分類するのは難しいことを証明しました。多くの場合、用語の解釈は
主観的なものになりました。
たとえば、ワークブックは視覚的にシンプルに見えても、それに必要なデータは複雑であ
る可能性があります。データが複雑であれば、多くの計算処理が必要なワークブックに
なります。Tableau Server 9.0 での性能向上による多大なメリットを得ることができるのは
このようなワークブックを使うユーザーです。
簡略化して新機能をテストするため、(a) 実際に利用されるような多種多様なワークブッ
ク (顧客が実際に利用しているものも含む) 、(b) ワークブックの表示・操作を行う多様な
ユーザー、の組み合わせを網羅し、テストとして信頼できるワークロードを作成しました。
19
次の図では、テストのためにワークロードの組み合わせをどのように行ったかを示してい
ます。
㼂㼕㼦㻽㻸㻌㻿㼑㼞㼢㼑㼞
㈇Ⲵ䛾ቑຍ㻦
㻝㻌䝴䞊䝄䞊㻛⛊
㻢㻡㻑㻌䝡䝳䞊
㻢㻜㻑㻌䝤䝷䜴䝄
䝺䞁䝎䝸䞁䜾
㻟㻡㻑㻌᧯స
㻠㻜㻑㻌䝃䞊䝞䞊
䝺䞁䝎䝸䞁䜾
䝽䞊䜽䝻䞊䝗䛾⤌䜏ྜ䜟䛫
」ᩘ䛾䝽䞊䜽䝤䝑䜽
図 7: Tableau Server 9.0 に対する複数のワークロードミックス
新しい方法
ワークロードミックスは、以前のホワイトペーパーで使用した簡単、普通、複雑というワー
クブックの概念から始まります。いずれかのタイプ (簡単、複雑、普通) のワークブックで
飽和するまでサーバーを実行して、ビューアーとインタラクターのユーザーミックスを使
用するようなテストではなく、より現実的なテストを実施するため、
複雑さが異なるワークブックのプールを導入しました。このプールには、Tableau Server
の最新機能を使ったワークブックのほかに顧客のワークブックが含まれていました。
ワークブックの設計に応じて、ブラウザレンダリングやサーバーレンダリングを使用する
こともできます。ブラウザレンダリングは、Tableau Server の前のバージョンにあった機
能です。最近のブラウザを使えば、ワークブックのレンダリングの一部を実行でき、サー
バーの負荷を軽減できます。
ワークブックが非常に複雑な場合、パフォーマンス上の理由から、Tableau クライアント
は負荷の高いレンダリング作業をサーバーにプッシュします。これに応じて、サーバーは
その負荷を処理して、ビジュアライゼーションを作るタイルを返します。これは、サーバー
レンダリングと呼ばれます。
20
したがって、Tableau のビジュアライゼーションでは、状況に応じて最近のブラウザ機能
を使ったり、負荷の高い処理をサーバーにプッシュしたりできます。これは、ワークブック
の複雑さによって決まりますが、ユーザーにもわかるように示されます。
以前に 8.1 で出された結果と本書の 9.0 の結果を比較できない主な理由の一部は、ワー
クロードミックスが更新され、ワークブックのプールから選択するという新しい方法が加
わったためです。
テストワークブックの例
顧客のワークブックが含まれているため、私たちが使用したサンプルワークブックを公開す
ることはできませんが、ここでは使用したタイプのダッシュボードの例をいくつか紹介します。
ユーザー操作のワークロードには、Tableau ストーリーポイント、さまざまなレイヤーを持
My Himalayan Story
8000 overview.
Everest and Cho Oyu
are the most Climbed
mountain
切り替え、フィルターアクションなどのナビゲーションがあります。次の図は、テストに使
Everest is climbed in
Cho Oyu is climbed in
Expeditions are on the
Cho Oyu and Everest
What are the main
Poeple die on Everest
Yet they are the safest
of the 8000ers
the Spring
the Fall
rise in the last 30
receive most of the
visits
years
用したストーリーポイントのワークブックの例です。
Season Name
Autumn
Spring
Summer
causes?
because of 2 main
causes
Member to death ratio (X member for 1 death)
Winter
0.0
3.8
# of climbers and # of Expeditions growth over time
Annapurna I
600
An A
na n.
p.. .
Cho Oyu
Dhaulagiri I
Everest
Kangchenjunga
K
K a.
a.. .
Lhotse
Shar
Lhotse
Makalu
Yalun
g Kan
g
Manaslu
100
400
60
40
165
20
Summit to Death ratio
Everest
Dhaulagiri I
50
Cho Oyu
Lhotse
0
3.71 15
1.11
0
Death trends over time
40
20
2000s
Max. HEIGHT in Meters
Peak Name
Annapurna I
Annapurna I - Mid..
Dhaulagiri I
Kangchenjunga
Kangchenjunga So..
Lhotse Middle
Makalu
Annapurna I - East..
Cho Oyu
Everest
Kangchenjunga C..
Lhotse
Lhotse Shar
Manaslu
図 8: ヒマラヤの登山と事故の傾向を示すストーリーポイントのワークブック
Yalung Kang
8,000 to 8,850
2010s
1990s
1970s
1980s
3,000
1950s
1,000
1,500
2,000
2,500
# MEMBERS ON SUMMIT
1960s
500
1940s
0
0
1920s
Kangchenjunga
100
40
1930s
Annapurna I
2.89
1900s
-> Click on a peak to find
more about it
More Red means higher % of
Death per 100 summitter
Darker Green means safer
150
36
1974
1985
1.17
1910s
8000ers map
3.49 11
1.00
1954
1973
1979
1985
1991
1997
2003
35
1.86 9
11
1.17
1.00
21
Number Of Member Deaths
10.35
3.38
2001
1965
1983
1989
2007
1961
1974
1981
1987
1993
1999
2005
40
1925
1951
1980
1986
1992
1998
2004
1969
1979
1985
1991
1997
2004
0
2009
2004
1958
1980
1986
1992
1998
2004
2.25 5
1.137
1.17
1955
1970
1978
1984
1990
1996
2002
2008
1933
1950
1960
1967
1973
1979
1985
1991
1997
2003
13.01
32
1989
1989
1973
1979
1985
1991
1998
2004
156
Number Of Member Deaths
200
# EXPEDITION
80
# MEMBERS
Welcome to the
fourteen
ちマーク数が増加する色塗りマップ、選択、インデックスによるカテゴリーフィルター、タブ
A lot less
Cho Oyu
to Everes
21
図 9: タクシー乗車数のワークブックとサンプルの操作
上に示した別のテストワークブックの見た目は単純に見えますが、以前のリリースではロー
ドするのに時間がかかりました。これは、同じクエリが 4 つのビューで個別に再実行される
ためでした。このワークブックは、タクシー乗車のデータセットに基づいており、私たちが実
行した操作は、インデックス別にカテゴリーフィルターを選択、タブの切り替え、カレンダー
で 11 月を選択、17 日を選択、現金をフィルター、タブの切り替え、でした。
他のテストワークブックは、さまざまなトレンド分析を示す 1,000,000 個のマークが付いた
高い負荷のある状況でパフォーマンスをテストする目的で作られました。
これらのワークブックはすべて、抽出を使用して作成されました。
抽出の特徴
私たちは、抽出を使ったワークブックでテストすることにしました。こうすることで、ライブ
のバックエンドデータソースの影響で発生するばらつきをテストから排除できます。
データベースがどのように使用され、他にどのような負荷がデータベースにかかっている
かによって、実際のライブ接続シナリオは大きく異なります。使用した抽出の行数はデー
タの 3000 行から 93 万行の範囲でした (抽出サイズは最大 3.5 ギガバイト)。
22
ワークロードに加えて、システムのパフォーマンスとスケーラビリティに影響を与える可
能性のある変数が多数あります。このばらつきを管理して、実行するテスト間で一貫性を
保つために、テストの標準化を複数の側面で行いました。
標準化した隔離環境
はじめに、ハードウェアを標準化しました。私たちは、自社のパフォーマンスラボで、次の
ような仕様の物理マシンを使ってこれらのスケーラビリティテストを実行しました。
䝃䞊䝞䞊䝍䜲䝥
㻰㼑㼘㼘㻌㻼㼛㼣㼑㼞㻱㼐㼓㼑㻌㻾㻢㻞㻜
䜸䝨䝺䞊䝔䜱䞁䜾䝅䝇䝔䝮
㻹㼕㼏㼞㼛㼟㼛㼒㼠㻌㼃㼕㼚㼐㼛㼣㼟㻌㻿㼑㼞㼢㼑㼞㻌㻞㻜㻝㻞
㻾㻞㻌㻿㼠㼍㼚㼐㼍㼞㼐㻌㻢㻠㻌䝡䝑䝖
㻯㻼㼁
㻞㻚㻢㻌㻳㻴㼦㻌㻞㼤㻤㻌䝁䜰㻌㻔ྜィ㻌㻝㻢㻌䝁䜰㻕
䝝䜲䝟䞊䝇䝺䝑䝕䜱䞁䜾䜢᭷ຠ໬
䝯䝰䝸
㻢㻠㻌㻳㻮
図 10: ベンチマーク環境のハードウェア仕様
導入トポロジ
プライマリノードを除く各クラスタノード (ワーカー) 全体で、次のようにサーバープロセス
の構成を維持しました。
図 11: スケーラビリティテストのサーバー導入トポロジ
23
前述のワークロードミックスを行うロードジェネレータを使用して、ワークロードをスケー
ルしました。テストの実行中、JMX を使ってシステムの指標、パフォーマンスの指標、ア
プリケーションの指標を収集し、その結果をリレーショナルデータストアに保存しました。
次に、Tableau Desktop を使って結果を分析しました。次の図では、テストの実行を論理
的かつ簡略化して示しています。マシンで実行しているサーバープロセスの一部が省略
されて各クラスタノードに示されていますが、それ以外は省略されていません。
㼀㼍㼎㻌㻶㼛㼘㼠㻌㻝
䝀䞊䝖䜴䜵䜲
䝃䞊䝞䞊㻌䜽䝷䝇䝍
㼀㼍㼎㻶㼛㼘㼠㻌䝻䞊䝗
䝆䜵䝛䝺䞊䝍
㼂㼕㼦㻽㻵㻌㼤㻌㻞
㻭㼜㼜㻌䝃䞊䝞䞊㻌㼤㻌㻝
䝕䞊䝍䜶䞁䝆䞁㻌㼤㻌㻝
㼀㼍㼎㼘㼑㼍㼡㻌
㻰㼑㼟㼗㼠㼛㼜㻌
ศᯒ
䝀䞊䝖䜴䜵䜲
䝔䝇䝖⤖ᯝ
䝀䞊䝖䜴䜵䜲
㼀㼍㼎㻌㻶㼛㼘㼠㻌㻟
䝀䞊䝖䜴䜵䜲
㼀㼍㼎㻌㻶㼛㼘㼠㻌㻞
㼂㼕㼦㻽㻵㻌㼤㻌㻞
㻭㼜㼜㻌䝃䞊䝞䞊㻌㼤㻌㻝
䝕䞊䝍䜶䞁䝆䞁㻌㼤㻌㻜
㼂㼕㼦㻽㻵㻌㼤㻌㻞
㻭㼜㼜㻌䝃䞊䝞䞊㻌㼤㻌㻝
䝕䞊䝍䜶䞁䝆䞁㻌㼤㻌㻜
㼂㼕㼦㻽㻵㻌㼤㻌㻞
㻭㼜㼜㻌䝃䞊䝞䞊㻌㼤㻌㻝
䝕䞊䝍䜶䞁䝆䞁㻌㼤㻌㻜
図 12: テスト環境の簡略論理図
テストを繰り返すたびに大量のデータが収集されましたが、結果を紹介する前に、いくつ
かの指標と定義を説明します。
測定とレポート作成
私たちは、システムパフォーマンスとスケーラビリティを理解するため、CPU、メモリ、ディ
スクなどのシステム指標、応答時間、スループット、実行時間などのスケーラビリティ指
標を測定しました。このホワイトペーパーで説明するデータを理解するために、いくつか
の定義を簡単に見てみましょう。
24
トランザクション
トランザクションとは、Tableau のビジュアライゼーションのロードやビューの操作など、エ
ンドユーザーが行う操作のことです。たとえば、ビジュアライゼーションをロードする場合
は、ビジュアライゼーションをロードするリクエストのセット全体 (HTTP) が 1 つのトラン
ザクションとなります。応答時間は、クライアントのパースペクティブ (ロードが実行された
場所) で行われた 1 つのトランザクションに対して測定され、レポートされます。
スループット
スループットとは、1 秒当たりのトランザクション数 (transactions per second=TPS) のこ
とです。例: 5TPS = 432,000 トランザクション/24 時間。Tableau Public を例にあげると、
1 日最大 1,300 万ページビューまでをサポートします。
飽和スループット
飽和スループットとは、システムが飽和状態のときに、システムにアクセスするすべての
クライアントにわたる 1 秒当たりのトランザクション数のことです。飽和のポイントを決定
する方法は、前述したとおりです。
応答時間
応答時間は、サーバーがエンドユーザーのリクエストに応答するために要する時間とし
て測定されます。
同時ユーザー数
Tableau Server において同時アクセスを把握するには、同時アクセスと見なされないも
のを定義することから始めます。パフォーマンスチームと話してみると、多くの場合、ユー
ザーの同時アクセス数は Tableau Server にログインしているユーザー数として定義され
るものだと考えているようです。論理上の測定ではそのようになりますが、このホワイト
ペーパーで述べる同時アクセスは異なります。
ログインユーザー数は、アプリケーションサーバーのプロセスのスケーラビリティのみを
測定するために使用されます。ユーザーログインではシステムの狭いパスを使用し、そ
のパスはビジュアライゼーションのロードや操作といった負荷の高い作業の計算処理が
集中する重要なパスではありません。
Tableau Server での同時アクセスとは、ビジュアライゼーションのロードや操作を、指定
された応答時間とスループットで行っているエンドユーザー数として定義されます。これ
は、テスト中の任意のシステムが飽和状態でサポートできるユーザー数を示す中心的な
指標となります。私たちは、リトルの法則を使用して、実験やテストの実行全体における
平均応答時間と飽和スループットに基づいて同時ユーザー数を割り出しています。
25
Tableau Server のスケーラビリティは、ビジュアライゼーションのロードと操作を行うため
のエンドユーザーのリクエストを VizQL Server のプロセスがどのように処理し、それを満
たすことができるかによって決まると考え、それを測定する数多くのテストを実施してい
ます。
テストの実行方法、使用した導入、および指標を確認したところで、次は結果を見てみま
しょう。
結果
Tableau Server 9.0 の新機能とアーキテクチャの更新のすべてで実験を数回実施し、
次のシナリオについての情報を提供しました。この実験では、Tableau Server 9.0 と
Tableau Server 8.3 の両方で、同じラボで同じトポロジとハードウェアで同じ方法を用い
て同じワークロードを実行しました。
Tableau Server 9.0 と 8.3 のスケーラビリティ比較
Tableau Server 9.0 では、Tableau Server 8.3 と比較して、16 コア以上のマシンでパフォー
マンスとスケーラビリティの向上が見られました。具体的には、Tableau Server 9.0 では、
目標の 3 秒よりはるかに短い平均応答時間で、単一ノード 16 コアマシンでの総ユーザー
数 927 人から、3 ノード 48 コアのサーバークラスタでは総ユーザー数 2809 人までにス
ケールし、エラー率も 1% を下回りました。
Tableau Server 9.0 の飽和スループットについては、一般的なワークロードで、単一ノー
ド 16 コアマシンでの 209 TPS から、3 ノード 48 コアマシンでは 475 TPS にまで増加し
たという結果が確認されました。TPS が 1 秒以内にロードおよび操作されたビジュアライ
ゼーションの数に相当することを考えると、ほぼ直線的にスケールするシステムであると
確認できます。また、より多くのワーカーノードをクラスタに追加することでスケールアウ
トできることがわかります。
飽和
スループット TPS
応答時間 (秒)
同時ユーザー数
合計ユーザー数
エラー率
1 ノード 16 コア
209.7
0.44
92.75
927
0.78%
2 ノード 32 コア
303.4
0.46
138.04
1380
0.58%
3 ノード 48 コア
475.5
0.59
280.93
2809
0.16%
トポロジ
図 13: Tableau Server 9.0 のスケーラビリティのまとめ
26
Tableau Server 8.3 を使って、同じハードウェアで同じ方法を用いて、同じテストを再度実
施しました。下の表にその結果をまとめました。
飽和
スループット TPS
応答時間 (秒)
同時ユーザー数
合計ユーザー数
エラー率
1 ノード 16 コア
61.0
1.47
89.88
899
0.46%
2 ノード 32 コア
144.6
0.69
99.82
998
0.06%
3 ノード 48 コア
152.6
1.36
206.76
2068
0.12%
トポロジ
図 14: Tableau Server 8.3 のスケーラビリティのまとめ
Tableau Server 8.3 では単一ノード16 コアマシンで総ユーザー数 899 人を記録しまし
た。これに対して Tableau Server 9.0 では、同じ構成で 927 人に達しました。さらに、
Tableau Server 8.3 は 3 ノード 48 コアクラスタにおいて総ユーザー数 2068 人で飽
和状態となったのに対し、Tableau Server 9.0 では総ユーザー数 2809 人でした。しか
し、Tableau 8.3 は 16 コアマシンで比較的すぐに 61 TPS で飽和状態に達したのに対
し、Tableau Server 9.0 が飽和状態になったのは 209 TPS でした。さらに大きいスケー
ルテストでは、3 ノード 48 コアクラスタにおいて Tableau Server 8.3 は 152 TPS で飽和
状態になったのに対し、Tableau Server 9.0 は 475 TPS を記録しました。
直線的なスケーリングのスループット
同じワークロード、方法、インフラストラクチャを使用した場合、すべてのテストにわたっ
て、Tableau Server 9.0 のスループットはほぼ直線的にスケールし、Tableau Server 8.3
と比較してもより一貫していることが証明されました。
単一ノード 8 コアマシンで Tableau Server を実行しようと考えているお客様のために、こ
ののシナリオを知らせるための特定の異なるテストも実行しています。この文書で後述
する「8 コアシングルマシンの比較」の項をご覧ください。
全体的なハードウェアの所見
先に確認した具体的なスケーラビリティの所見、およびコアと水平方向のスケーリングに
よって影響を受けるサーバーの処理力の測定に加えて、インフラストラクチャの測定と所
見を記録しました。次のセクションでは、16 コア、32 コア、48 コアのマシンでの上記の各
コアトポロジに与えるメモリ、ディスク、ネットワークの影響について見ていきます。
27
メモリ
Tableau Server 8.3 と比較して、Tableau Server 9.0 は、単一ノード 16 コアマシンで 40% 以
上のメモリ、3 ノード 48 コアクラスタで 70% 以上の RAM を必要とすることがわかりました。
図 15: 16 コア、32 コア、48 コアのマシンでの RAM の使用状況
RAM の増加は、このホワイトペーパーで前述した多くの変更によるものであり、8.x から 9.0
システムへのアップグレードでは、RAM の追加を検討する必要があります。
28
ディスクスループット
この実験で使用したディスクにおいて、Tableau Server 9.0 では、分散したクラスタにわ
たってディスクスループットの減少が見られました。単一マシン 16 コアマシンのシナリ
オでは、8.3 と 9.0 で消費されたディスクスループットに 14% の増加が見られました。一
方、3 ノード 48 コアクラスタでは、負荷テスト中サーバーバージョン間のディスクスルー
プットに 30% の減少が見られました。Tableau Server 9.0 では、ディスクに対するクラスタ
の状況を一定にし、Tableau Server 9.0 の新しい各コンポーネントはディスクにログを記
録します。
図 16: ディスク使用状況の比較
ネットワーク使用率
Tableau Server 9.0 には、新しい分散クエリのキャッシュと連動するいくつかのコンポー
ネントがあります。さらに、クラスタ全体の状況を管理するコーディネーションサービスも
あります。8.3 との比較では、ネットワークのチャタリングに比較的大幅な増加が見られ
ます。しかし、ネットワークのチャタリングによるスケーラビリティやパフォーマンスへの大
きな影響は見られませんでした。
29
図 17: ネットワーク使用状況の比較
つまり、ネットワークトラフィックの増加があるにもかかわらず、Tableau Server 9.0 は十
分にスケールし、適切に機能します。実際の導入について学んだことは、可能であれば
10 GB のネットワークに Tableau Server の導入を考慮するということです。
8 コアシングルマシンの比較
8 コアマシンで Tableau Server を実行するお客様のために、8.3 からのアップグレード後
に、Tableau Server 9.0 の動作にどのような違いがあるのかを説明します。9.0 と 8.3 で
の結果を比較するために、同じ方法でバッテリーテストを実施しました。
30
下の表にあるように、8 コアマシンのシナリオでは、Tableau Server 9.0 は 8.3 と比較し
て、飽和スループット、応答時間が大幅に優れていることがわかりました。
Tableau Server 8.3
1 ノード 8 コア
Tableau Server 9.0
1 ノード 8 コア
飽和スループット (TPS)
34.2
129.9
応答時間 (秒)
1.80
0.46
同時ユーザー数
61.56
59.45
エラー率
1.71%
0.78%
キーインジケーター
図 18: 8 コアマシンでの Server 8.3 と Server 9.0 の比較
Tableau Server 9.0 では、130 TPS という極めて高い飽和スループット、0.46 秒という短
い平均応答時間、および 1% を下回る低いエラー率が測定されました。
Tableau Server 8.3 では、スループットは 34 TPS と大幅に低く、平均応答時間は 1.8 秒
でした。Tableau Server 9.0 では目標となる 1% より低いエラー率を維持できていますが、
8 コアシングルマシン上の Tableau Server 8.3 ではエラーの発生率が目標より高く、
これには多くの場合、ロードが増加すると応答時間が増加し始めるため、クライアントの
タイムアウトが関連しています。
31
メモリ要件の増加
単一 8 コアマシンと 16 コアマシンを比較すると、Tableau Server 9.0 は、16 コアのテスト
では 38%、8 コアのテストでは 68% 多く RAM を使用しました。
図 19: 単一ノードマシンでの導入における 8.3 と 9.0 の RAM 使用状況の比較
さらに、複数マシンクラスタの導入では、Tableau Server 9.0 は、Tableau Server 8.3 と
比較して、最大使用時で約 60% ～ 80% 多くメモリを使用します。Tableau Server 9.0 で
は、9.0 の新機能をサポートするその他のサーバープロセスに対応できるようにハードウェ
ア要件を 8 GB に引き上げました。
たとえば、起動時の各キャッシュサーバープロセスでは、500 MB の RAM を消費しま
す。効率的になる一方で、マシンでのキャッシュサーバープロセスが多くなると、使われ
る RAM が多くなります。それに加え、ファイルストアのような新しいプロセスは、さらに
RAM を消費します。これらは、旧バージョンの Tableau Server にはなかったものです。
32
つまり、このホワイトペーパーで紹介している特定のテストで示されているように、シング
ルマシン 8 コアで Tableau Server 8.3 のインスタンスがある場合は、9.0 にインプレース
アップグレードを実施することによって、エンドユーザーはパフォーマンスの向上を実感
できます。ただし、リソースの競合により、スケーリングがわずかに低下する場合があり
ます。単一マシンで 8.3 と比較すると、9.0 ではエラーが少なくなります。特定のパフォー
マンスの向上は、数多くの要素によって変わる場合があります。お客様が 8.x から 9.0
へのアップグレードを検討する際の処理能力の計画に、この情報が役立つことを願って
います。
Tableau Server 9.0 では、高可用性 (HA) についても多くの改善が行われました。ファイル
ストア、クラスタコントローラ、コーディネーションサービスなどの新しいサーバープロセスに
加え、データエンジンを持つクラスタで抽出をすべてのノードに移行する作業を行っていま
す。アップグレードによる HA への影響がある場合、どのような影響がスケーラビリティに
及ぶのかをテストしたいと考えました。次のセクションでは、その結果について説明します。
高可用性の効果
高可用性と非高可用性について考える際に覚えておくべき重要なことは、テストでは HA
のための新しいアーキテクチャをサポートする新しいコンポーネントをいくつかサーバー
に追加したということです。HA をテストするために、新しいアプリケーションサーバーの
ワークロードが含まれるように確認しました。これまでと同じハードウェアで新しいワーク
ロードを実行しました。Tableau Server 9.0 では、HA 構成を実行するには 3 台以上のマ
シンが必要となります。詳細については、サーバー管理ガイドをお読みください。
1 つのテストでは、フェールオーバーのパッシブリポジトリと、ファイルストアおよびデータ
エンジンのプロセスをクラスタの各ノードに追加して、HA を有効にしました。
非高可用性の導入と比較すると、高可用性が有効になっている場合、スループットと応
答時間への影響が非常に小さいことがわかりました。この影響が小さく、予測されていた
結果となったのは、Postgres のリポジトリと抽出を同期させるためにさらなる作業を行っ
ていたためです。しかし、HA 構成を実行しているとき、すべてのワーカーにわたってメモ
リの使用量に約 10% の増加が見られました。
メモリ使用量の増加は、TPS に大きな影響を与えることはありませんでした。HA が有効
になっている場合、TPS に見られた減少は 1% 未満でした。エラー率 (ほとんどがソケッ
ト読み取りのタイムアウト) は、エラー率のしきい値である 1% 未満を下回るものの、0.1%
から 0.3% に増えました。
さらに HA モードで実行している場合、サーバーに対するそれぞれのパブリッシュアクシ
ョンで (抽出を使用する場合)、クラスタのすべてのノードに新しい抽出を同期させるファ
イルストアプロセスが必要となります。前のバージョンでは、クラスタの最大 2 つのノー
ドでデータエンジンプロセスを実行することしかできませんでした。Tableau Server 9.0 で
は、任意のノード数でデータエンジンプロセスを実行できます。
33
データエンジンプロセスを実行する各マシンでは、ファイルストアプロセスも必要になりま
す。この構成の可能性を考えると、抽出の冗長性のために設定するノード数を増やすほ
ど、ノード間で抽出を同期させるために生じるコストが増えるということを意識してくださ
い。このコストは主にネットワーク使用率に反映され、低速リンクにサーバーワーカーを
導入する判断の材料となります。
結果の適用
この時点では、これが自分のケースにどのように当てはまるか、また、実装に必要な容
量をどのように決めればよいのか、判断できないこともあります。このホワイトペーパー
では、Tableau Server が同時アクセスユーザー数に対し直線的にスケールすることを説
明しました。実際に取ることができるアプローチの 1 つは、本書のアドバイスに従って必
要な容量を見極め、その容量を基準として使用することです。ユーザーの環境では、こ
のホワイトペーパーで使用されているシステムと同じものが使用されているわけではな
いため、実際の結果は異なる場合があります。
バックグラウンダーの考慮事項
これまで説明した内容のほとんどは、ユーザーが直面する負荷に関するものでした。こ
れらの中で最も重要なものは、ビューのロードと操作およびポータルの操作です。バック
グラウンダーサーバープロセスは、抽出の更新、サブスクリプション、スケジュールが設
定されているその他のバックグラウンドジョブに関連する作業の多くを実行します。これ
らのジョブをピーク時以外に実行するようにスケジュールを設定すれば、容量で競合す
ることはありません。これが難しい場合は、バックグラウンダーおよびユーザーに直接関
係のないワークロードを、ユーザーに直接関係のあるプロセスと同時に実行するために
必要な容量を追加することを計画してください。
バックグラウンダーはできるだけ早く作業を終了するように設計されているため、コアの
すべての容量を消費します。複数のバックグラウンダーを実行するときは、バックグラウン
ドサーバープロセスが、同じマシンで実行されている他のサービスに影響を与える可能
性があるということを考慮してください。この場合の適切なベストプラクティスは、マシンの
Tableau Server で利用できる N コアの場合、N/4 と N/2 の間のバックグラウンダーを必
ずそのマシンで実行することです。
必須ではありませんが、必要に応じてバックグラウンドサーバープロセスを専用のハード
ウェアに分離して、エンドユーザーのワークロードへの影響を切り離すこともできます。
自分の環境とワークロードで Tableau Server がどのようにスケールするかを確認する負
荷テストを行う場合、次のようなベストプラクティスが役立ちます。
34
ベストプラクティス - 自分で行うスケールテスト
自社の環境とワークロードで Tableau Server がどのようにスケールするかを確かめるた
め、拡張性と負荷テストを独自に実施する必要が発生することがよくあります。
このテストを自社で行う場合に最も考慮すべき点が 4 つあります。
1. Tableau Server をブラックボックスとして扱わない。Tableau はスケールアップおよ
びスケールアウトするようにできています。ただし、Tableau をブラックボックスとし
て扱うと、予期しない結果となる可能性があります。これは、Tableau Server のス
ケーリングが、テスト負荷にあるワークロード、構成、システム環境、およびシステ
ム全体のさまざまな要素に依存するためです。
2. テストに適切なツールを選ぶ。Tableau Server は多機能であり、複雑かつリソース
集約的な作業を行います。Tableau Server に負荷をかけるためのツールも数多く
あります。Tableau は直接これらのツールをサポートしていませんが、最も使いや
すく、本番環境に最も近いものを選択してください。もう 1 つの考慮すべき事項は、
テストする人がツールの使い方と Tableau Server に対する専門知識を持っている
ことです。
3. 適切なワークブックを選ぶ。多くの場合、パフォーマンスやスケールに関して不満
が生じるのは、ベストプラクティスを念頭に置いて作られていないワークブックを使
用しているためです。ワークブックで、非常に遅いシングルユーザーテストの応答
時間が示されている場合、負荷テストプロジェクトを始める前にワークブックを最適
化してください。
4. ライブ接続を使ってワークブックをテストするとき、Tableau Server 9.0 に並列処理
が導入されたことによって、以前のバージョンの Tableau Server で導入したほど多
くの VizQL Server が必要なくなる場合があります。新しい既定の構成で始めて、
プロセスを徐々にスケールアップしていくことができます。
TabJolt - スケーラビリティテストのツール
最近 Tableau は TabJolt をリリースしました。これは、Tableau Server で簡単に動作する
ように設計された、指定して実行するだけで負荷とパフォーマンスをテストできるツール
です。このツールを使えば、スクリプトを開発して管理する必要がなくなり、より高速な反
復テストが可能になります。このツールは現状のまま無料で github から入手できます。
詳細については、リリースに関するブログをご覧ください。
35
最適化のベストプラクティス実例
最適に設計されたシステムに加えて、パフォーマンスを大幅に向上させ、平均応答時間
を削減することができるベストプラクティスがあります。
Tableau データ抽出の使用 – データベースクエリが遅い場合、抽出を使用して、クエリのパ
フォーマンスを向上させることを検討してください。抽出ではデータをサーバーのメモリに
ローカルで格納するため、ユーザーはデータベースにリクエストを送信することなく、データ
にアクセスできます。行レベルでの詳細が不要な場合は、データを簡単にフィルタリングお
よび集計でき、応答時間が大幅に改善します。
オフピーク時間中の更新のスケジュール – データソースがリアルタイムに更新される一
方で、ユーザーは日単位または週単位でしかデータを必要としないことがよくあります。
オフピーク時間に抽出のスケジュールを設定すれば、データベースと Tableau Server の
両方に対するピーク時の負荷を軽減できます。さらに、十分なコア容量がある場合は、
既存のマシンにバックグラウンダーを追加したり、専用のハードウェアを使ったりすること
ができます。抽出をより早く終える場合は、この方法を検討してください。
ピーク時間中の「コストの高い」操作の回避 – 特に大きなファイルをパブリッシュすること
は、非常にリソースを消費する作業です。さらに、この作業がパブリッシュの動作に影響
を与えることもよくあります。ユーザーには、月曜の朝などの繁忙時間を避けて、オフピー
ク時間にパブリッシュするように依頼してください。サーバーが最も使用されているタイミン
グを知るには、[管理者] ビューに移動して、実際の使用状況に基づいてポリシーを作成
します。Tableau Server 9.0 をどのように構成したかに応じて、可用性を高めるために、パ
ブリッシュ時に抽出のコピーが各クラスタノードに作られることもあります。ピーク時以外
にこれを行うことにより、ネットワークの帯域幅を最大限に活用できます。
ビューのキャッシュ – 複数のユーザーが Tableau Server へのアクセスを開始すると、最
初は共有リソースの競合により応答時間が長くなります。キャッシングをオンにすると、シ
ステムへの各リクエストからのビューがキャッシュされ、同じダッシュボードの次のユー
ザーが同じビューをレンダリングするときに表示時間が短縮されます。Tableau Server 9.0
の新しい機能であるキャッシュサーバープロセスは、抽出の更新が終わってから一般的
なビューをリクエストするメールのスケジュールを設定することによってウォームアップで
きます。このようにしてビューを見る人は、以前のリクエストからキャッシュされたデータを
使用しています。他の方法を使ってキャッシュをウォームアップすることもできます。自動
化ツールを使って、通常はトラフィックが大きい主なビジュアライゼーションをロードする方
法です。ユーザーは外部のクエリキャッシュを手動で無効にできます。このクエリキャッシュ
はキャッシュサーバープロセスが管理するものであり、いつでもデータソースからデータ
を更新し、キャッシュの再生成を実行します。このようにして、データのコピーのバージョン
がキャッシュにあるかどうかにかかわらず、ユーザーは常に最新のデータのコピーを取得
できます。
36
より少なく効果的に - 以前のリリースでは、1 台のマシン上で複数の VizQL Server プロセス
を実行して、負荷を処理する必要がありました。しかし、プロトコルグループと呼ばれるコアテ
クノロジーが導入されたことで、並列クエリを実行できるようになり、VizQL Server はバック
エンドデータベースへの複数の接続を使用できるようになりました。Tableau Server 9.0 では、
実際に VizQL プロセスを 4 つ未満に減らすことにより、さらに効率的にスケールできるよう
になっています。現在のベストプラクティスは、マシンあたり 2 つの VizQL Server プロセス
を実行する新しい既定の構成です。
まとめ
このホワイトペーパーでは、私たちのアプローチの詳細と具体的な例、方法における
適切な変更、Tableau Server 9.0 サーバーのスケーラビリティの最終結果を説明しまし
た。Tableau Server 9.0 は直線的にスケールし、Tableau Server 8.3 に比べてパフォー
マンスが向上していることを示しました。
ユーザーの 10% がアクティブにビジュアライゼーションをロードおよび操作している環境
で、Tableau Server 9.0 は 1 台の 16 コアマシンで最大 927 の合計ユーザーをサポート
し、3 ノード、48 コアクラスタのセットアップで最大 2809 の合計ユーザーまでスケールで
きることを確認しました。
このホワイトペーパーは、Tableau Server 9.0 を実装するときにガイドとして役に立つ情
報を提供するために作成されました。ワークロードと実装はそれぞれの環境で異なるた
め、結果も異なる場合があることをご了承ください。
37
Tableau について
Tableau Software のミッションは、お客様がデータを見て理解できるように支援することです。Tableau を
利用すれば、簡単に情報を分析してビジュアル化し、共有することができます。すでに世界で 29,000 社を
超えるお客様が Tableau を導入し、オフィスや外出先で簡単にデータ分析を行っています。また、無料の
データビジュアル化ツールである Tableau Public を利用して、数万人のお客様がデータをインタラクティブ
な Viz (ビジュアライゼーション) としてブログや Web サイトで共有しています。ぜひ無料トライアル版を
お試しください。www.tableau.com/ja-jp/products/trial からダウンロードしていただけます。
その他のリソース
無料トライアル版をダウンロード
関連ホワイトペーパー
高可用性：Tableau Serverを使ったミッションクリティカルな超高速処理 BI
Tableau の安全なソフトウェア導入
すべてのホワイトペーパーを見る
その他のリソースを見る
· 製品デモ
· トレーニングとチュートリアル
· コミュニティとサポート
· カスタマーストーリー
· ソリューション
Tableau および Tableau Software は、Tableau Software, Inc. の商標です。その他の社名および製品名は各社
の商標です。

Download Report