この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
先日投稿したエントリに引き続きのTableau Server x AWSネタです。こちらはAWSの環境全体と言うよりもTableau ServerがインストールされるEC2環境にフォーカスしたもの。各種試験を重ねた結果を踏まえてのEC2インスタンスタイプの選定等について解説されたセッションとなりました。
ちなみにセッション紹介文は以下の内容となっています。
Tableau Server and AWS EC2: Like Chocolate and Peanut Butter
Thinking about running Tableau Server on AWS EC2? Wondering what sort of instances you should run and why? Want to avoid mistakes that first time Tableau-on-EC2 admins tend to make? Then this is the session for you! Russell and Alan are part of an informal team at Tableau that carried out exhaustive testing of Tableau Server on EC2 using TabJolt, the Tableau load testing tool. We experimented with different Tableau and EC2 configurations so you don’t have to. In this session we’ll reveal our test results and give you the "rules of thumb" you can use when making decisions about your EC2 environment.
当セッションのゴール＆扱わない範囲
- ゴール
- Tableau Serverが仮想環境下でどのようにスケールするのかを理解する
- 一番しっくり来る設定を決めるための異なるコアレイアウトの比較
- EC2における典型的な"障害"について
- EC2インスタンス選定のための基本的な条件の整理
- 扱わない範囲
- あらゆる設定を予測出来るような"魔法のEC2"を作成する事
- "完璧な"Tableau-EC2アーキテクチャの構築
- EC2とAzureの比較
EC2: 多種多様なタイプとサイズ
AWSサービスの学習に時間を投資
インスタンスタイプによって、仮想CPUのタイプと数は異なる
- EC2におけるvCPU:1は物理コア数に換算すると1/2コアとなる。このため、"実世界で"必要なコア数(すなわち物理コア数)を求める場合はvCPUの値を2倍する必要がある。
- 当エントリにおいて、以降は"実世界で必要となるコア数"で話を進める。
スループットを満たす"十分な"ディスク容量を確保しておく事
- マグネティックなディスクは非推奨
Tableauの要件を"パーフェクトに"満たすEC2インスタンスは存在しない。
当セッションで扱ったインスタンスタイプ
- テスト済：コンピューティング最適化(C3、C4)、メモリ最適化(R3)
- 未テスト：汎用目的(T3、M3、M4)、GPU、ストレージ最適化(I2、D2)
- その他、インスタンス環境に関する情報の解説など。
各種テストとその結果
様々なテストを実施
- 一定の割合で内容を混在させたワークロード
- 標準的なディスクの設定
- EBSプロビジョンドIOPS:1500
- Amazon EBS ボリュームの種類 - Amazon Elastic Compute Cloud
- OSはCドライブ、TableauはDドライブ
- デフォルト設定のインストール: カスタム設定は行わず
- 全てのベースラインテストにはC3インスタンスを使用
結果(ベースラインテスト)
- CPUが全て：多くの基本的な設定において、CPUが大抵の問題・課題を解決してくれる
- 8コアを分割しない：これをやるのは、お金をドブに捨てるようなものだ
結果(Heavy Metal:Heavy=負荷を掛けたテスト、の意か？)
- 4コアマシンは8コア&16コアのようにはスケールしない
- ベースライン設定では、4x8と2x16の構成(の性能差)は見分けが付きにくい
- ワークロードは需要
- NO 32-VCPU C4s(C4の32vCPUは使わない？)
- 8コアの場合の(スペック)増加に付いて行くのが困難になっていく為
- 共有セッションを多用しているか？まずはスケールアップし、その次にスケールアウトを。
- RAMの追加は大容量で複雑さの低いワークロードで役に立つと思われる
- EC2 CPU-to-RAMミックス
- C3とC4インスタンスではコア推奨値の8GB RAMに近い値を得ることは無い？
- R3やM3インスタンスであれば、CPUスペックを低くする犠牲を払う事で推奨値に近づける事は可能
- 最小コアマシン(4コア)のR3、M4辺りは興味深い
- RAMが非常に制限されたマシン上では、CPUはそれほど重要では無い
- まずRAMを増やし、次にCPUを増やす。
- Magnetic Disk. Bad Stuff happens磁気ディスクは良くない事が起こる(のでオススメしない)
Tinkering(手直し、修理、修繕)
- 磁気ディスクには安い理由がある
- 低TPS、レスポンスタイムもより掛かり、エラーレートも高くなる
- 高いI/Oの読み取り及び書き込みのニーズを満たす事が出来ない。
- あなたのワークロードでgp2をテストしてみてください
- 多くの場合、低価格で同じようなパフォーマンスを出すことが出来るでしょう
- 貧しいI/OはTPSを殺す
- I/Oはケチるとあまり良い結果とならないらしい...
プロセスの分離とその箇所
特定のプロセスはCPUとRAMを本当に消費する
- VizQLServer
- Backgrounder(Data Engine)
- Data Engine
十分なマシンがあるのならば、色々試してみて欲しい
- 1台の"モノリシック"なマシン上でのより少ない柔軟性
- 複数マシンを使ってのより多くの柔軟性(注:これは4コアマシンを10台起動させる、というのは意味していない)
- なぜ沢山の作業が？
- 適切なコンビネーションはワークロードによって異なる
- ワークロードの変化に応じて、リソースをシフトし、再度実験する必要がある
- 複数マシンに手を加え、結果が良くなった
- より多くのマシンを使うことで柔軟性が上がった
- 一般的に、リポジトリとデータエンジンを隔離させた
- 結果に関する数字は以下参照。
まとめ
- AWSを学ぶ: 知らないと損をします
- CPUを優先: インスタンスがRAMを少ししか備えていないという場合を除き、まずボトルネックにCPUが来ます
- 8コア(16 vCPU)インスタンスが良い結果を弾き出した: c4.4xlargeが柔軟かつパフォーマンスも良かった
- IOを軽視しない: 十分なIOPSを備えている事を確認する一方で費用は掛け過ぎない様に。
- テスト大事: TabJoltを使って各自の環境における確認を行なうこと - 我々の発表内容を鵜呑みにしないで
- デッキをダウンロード - 大きなおまけもあるので興味深い内容になってます
さいごに
以上、Tableau Server導入に際してのEC2インスタンス選定に関する調査まとめセッションでした。当セッション冒頭では『この結果を鵜呑みにしないように。それぞれの環境でしっかり検証して確かめてください』とコメントがありましたが、ざっくりな参考にはなるのかなと思います。実際利用される際の環境、人数、利用頻度などを考えて適切なインスタンスタイプを選んで行きたいですね。また、検証にはTabJoltを使用していたようです。こちらも機会があれば色々触ってその機能についてご紹介してみたいと思います。こちらからは以上です。
2
