Tableau Conference 2016 at Austin [レポート]TableauサーバをAWS EC2に展開する：上級特別クラス #data16

「カスタマーストーリー」を支えるツール特集

#ビジネス・アナリティクス

#イベントレポート

#Amazon EC2

#Tableau

#レポート

川崎照夫

2016.11.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Tableau Conference 2016@Austinのセッション参加レポート：5本目は「Deploying Tableau Server on AWS EC2: The Master Class」の紹介をしていきます。

title

セッションの紹介文は下記の通りです。

Thinking about running Tableau Server on AWS EC2? Want to learn from others' mistakes? Then, this session is for you. We've spent hundreds of hours load testing and developing real-world experience in order to give you the most complete information possible. We'll reveal our test results and give you the "rules of thumb" you can use when making decisions about your EC2 environment.We'll address questions like:

- Should I spread my cores across multiple EC2 instances, or build out bigger machines?

- How important is disk throughput, and how many IOPS do I need?

- How to implement disk and network encryption to protect PII and move towards HIPAA compliance?

会場風景

アジェンダ

ゴールと、対象外の範囲
EC2とは何か
TabJoltについて
テスト結果
スケーラビリティを求めていじくり回す

agenda

セッションビデオ・スライド

本セッションの録画版、およびPDF版のスライドは、下記のサイトで公開されています。（※登録必要ですが無料で利用・アクセス可能）

http://tclive.tableau.com/Library/Video?vCode=BRK53637

このセッションのゴール

EC2上のTableauの展開オプションについて説明する
Tableau Serverが仮想環境下でどのようにスケールするのかを理解する
一番しっくり来る設定を決めるための異なるコアレイアウトの比較
EC2における典型的な"障害"について
EC2インスタンス選定のための基本的な条件の整理

EC2:多数の種類とサイズ

AWSのサービスを学習する時間をかけよう
それぞれのインスタンスタイプは、仮想CPUの種類や数が異なる
- 仮想CPUは、物理コアの1/2に相当する
- 仮想CPUは、「実世界」のコア数の2倍の数が必要
- デモの中で「実世界」のコアについて説明する
十分なディスクのスループットが必要
- 磁気ディスクは性能が悪い、非常に悪い
Tableauにとって完璧なEC2インスタンスタイプは存在しない

インスタンス・タイプ

テスト済み	未テスト
コンピューティング最適化 C3(2015)	汎用目的 T3
コンピューティング最適化 C4(2015 & 2016)	汎用目的 M3
メモリ最適化 R3(2015 & 2016)	GPU G2
汎用目的 M4(2016)	ストレージ最適化 I2
	ストレージ最適化 D2
	スケールするGPU P2

インスタンスタイプ2_2

ストレージ

多数のテストを実施

TabJolt
- 簡単操作のロードテスト・ツール
- オープンソース
一定のワークロード・ミックス
- 60% 5秒の思考時間を設定したView（参照）
- 40% 10秒の思考時間を設定したInteract（操作）

2015年版のテスト

スタンダードなディスク設定
- 1500EBSプロビジョンド
  - CドライブにOS
  - DドライブにTableau
デフォルト・インストレーション
- Tableau 9.03
- プロセスの配置や数を最適化しない
基準となるテストでは、C3インスタンスを使用
- コア数を4の倍数で設定

2016年版のテスト

スタンダードなディスク設定
- EBS SSD gp2 disks(ほとんど)
- CドライブにOS
- DドライブにTableau
デフォルト・インストレーションに加えて基本のプロセス配置
- Tableau 9.3 beta 4 vs. Tableau 10
- レポ、データエンジン、バックグラウンダー、VizPotal
- 単一のボックス
- 1VizQL 2 or 4 VizQL
基準となるテストでは、M4インスタンスを使用

物理マシンのテスト結果

ワークロードが重要
飽和点をどのように定義するか
- 自分で決める
- 我々の定義：仮想ユーザ数を増やしても、TPSがもはや増加しない点、一定のエラー率を超えた点
- 飽和点は、一般的にCPUの80〜90%付近

仮想マシンのテスト結果

仮想マシンにはパフォーマンス上のペナルティがある
- ペナルティは、ハードウェアやワークロードの内容で変化するが、確かに存在する
CPUは重要、でも決定的ではない
- 十分なメモリとディスクが必要。そうでないとCPUを使い切れない
- すべてが同等の場合、CPUはすべての病をいやす
  - 低いエラー率、より高いTPS、大きなユーザ数

より大きな構成の場合

v10はv9.3より、スケールする
- 両者の差は、スケールアウトしてみるとよりわかりやすい
4コアマシンは大丈夫か？
- ぱっと見た分には、4コアは大丈夫に見える
- 性能が低いままになる危険性がある
EC2 CPU-メモリのミックス
- C4インスタンスでは、推奨値のコアあたり8GBのメモリが実現できない
- R3とM4は、それが実現できる。（少しだけロースペックのCPUを使う犠牲をはらうことで）
8コアはよくスケールする
- ただし、それはワークロード次第
32-vCPU C4/M4は使わない
- コア数の増加についていけない

GP2のバーストを使い切った時

3000IOPSで30分間バーストする
回復の割合は、容量のGBあたり、毎秒3IOPS
バーストを使い切った場合、性能はベースラインに戻る（GBあたり3IOPS、100GBの場合300IOPS = 12.8MiB/s）
1TBのGP2ストレージは、常に3000IOPSを使い続けることができる

暗号化ディスク

EBS(Elastic Block Store)が面倒をみてくれる
- Tableauサーバからは透過的である
- 「保管データの暗号化」の要件を満たす

IPSec

IPSecのセットアップについてはここでは触れない
デフォルトのIPSec設定
- 鍵交換
  - ハッシュアルゴリズム:SHA-1
  - 暗号化:AES-CBC-128
  - 交換:Diffie-Hellmanグループ2
- データ保護
  - プロトコル:ESP
  - 暗号化:AES-CBC-128
  - ハッシュアルゴリズム:SHA-1
  - 鍵有効期限:60分
セキュリティレベルが高いケース
- 鍵交換
  - ハッシュアルゴリズム:SHA-384
  - 暗号化:AES-CBC-256
  - 交換:Diffie-Hellman P-384
- データ保護
  - プロトコル:ESP
  - 暗号化:AES-GMAC-256
  - ハッシュアルゴリズム:AES-GMAC-256
  - 鍵有効期限:60分

ストレージや暗号化について

HDDが安いのは理由がある
- 低いTPS、長いレスポンスタイム、高いエラー率
- 高い読み書きのIOのニーズにマッチしない
gp2を自身のワークロードでテストするべき
- 多くのケースで、同等の性能を低価格で提供する
- 負荷が高い期間は、PIOPSに移行する。より高いがより安全になる
貧弱なIO性能がTPSを殺す
- gp2のブーストが空になると、CPUも性能の制限を受ける
- HDD使うのは止めよう
暗号化はよい
- 躊躇せずに暗号化を行う。TPSに対するインパクトは無いと考えてよい。
- ネットワーク通信の暗号化は、インパクトはほぼ無いか、低い

まとめ

あなた自身のワークロードでテストしてください
- 自分自身のシナリオに当てはめなければ、数字は無意味である
v10.01以降に移行しよう
- v9よりスケールする
- メモリ使用が改善
- より多くのCPUを使うようになった
- ※上の２つは、このセッションの中では提示しないが、事実である
CPUは重要であるが
- メモリとディスクの良いミックスが必要
暗号化はよい。
- TPSに対するインパクトは無いと考えてよい。
- ネットワーク通信の暗号化は、インパクトはほぼ無いか、低い
R3はよい
- バックグラウンダーが多数動作している場合は試してみる。
C4
- コア当たりのメモリが少ないのが苦しい
M4
- m4.4xlarge は優れたビルディングブロックになる
HDD使わない
- gp2を使おう
- ブーストの枯渇に注意。1TBなら枯渇しないので、それを使う
- PIOPSを必要に応じて使う
インスタンスごとに4 vs. 8 vs. 16コア
- われわれのワークロードでは、8がベストだった
繰り返しになるが、テストをしよう！