【経営戦略】「Tableauサーバーの適切な台数を算出し、観測せよ」_算出編
概要
詳しい説明が不要の方は、以下をご覧ください！
前提
ミッション
結論
全体を通して
より詳しくは、以下是非ご覧ください。
検討ポイント①
検討ポイント②
検討ポイント③
前提はパスでも大丈夫です。
背景
金融機関で勤務します、yuと申します。
大量のデータを集約させ、見たいデータを即座に取り出し分析ができる環境を創ることをミッションに日々動いています。
今後の利用者増加を見越し、以下のミッションが与えられした。
ミッション
①適切な台数のTableauサーバーを用意せよ
②利用状況とリソース状況をリアルタイムモニタリングせよ
※本記事は①について記載します。
前提
データレイク：AWS S3
データウェアハウス：Redshift
BIツール： Tableau
Tableau Server：AWS EC2
16core
メモリ128GB
Tableauサーバーの構成
2022/9 ：
AWS EC2 1台構成
〜現在 :
AWS EC2 3台構成(内1台フロー専用機)
AWS EC2 5台待機(ライセンス購入未済)
※インフラ構築のリードタイムを短縮する為。
ディスクは最小にし、従量課金はミニマムに。
※プロセス構成を調整することで一定の冗長化。
結論
先に結論を述べると以下のシナリオ想定で台数を提示しました。
その結果現状の構成。
シナリオ①：
以下を考慮した場合
・楽観的な利用者増加
・スポット的な利用増によるリソース逼迫
→5台構成
シナリオ②：
以下を考慮した場合
・利用者数の増加想定を0.5倍
・スポット的な利用増の時間帯が想定より分散
→3台構成
検討ポイント①：同時接続数
a.同時接続数の考え方
アクティブユーザーが10%の場合、以下の通り処理可。
600〜800explore / 物理8core
b.ライセンスごとの負荷
creator/人 の負荷 = 2.40 × explore
viewer/人 の負荷 = 0.75 × explore
c.将来のライセンス配布計画
d.30分単位のセッション数
上記a.b.c,dをもとに、以下の関係式から
explore換算の推定利用率を算出。
d ÷ b = ●%
30分単位のセッション数予想値を算出。
c × ●% = ☆
物理16coreの1台が処理できる"負荷"=160
☆ ÷ 160
上記より、同時接続数という観点での推奨台数を算出。
検討ポイント②：CPU利用率
a.CPU/メモリは"5分平均"でのピーク値を観測。
b.CPU利用率は80%以下キープが推奨
c.将来のライセンス配布計画
d.現状のCPU利用率と配布ライセンス数
上記を前提に情報を整理。
dの本部と営業店利用者を分け、1exploreあたりのCPU利用率をそれぞれ算出。
営業 = ●%
本部 = ★%
cの将来配布計画値に基づき、予測CPU利用率を算出。
営業 = ○%
本部 = ☆%
将来の予測利用率から、何台必要か算出。
ただしライセンス配布(c)はするも、利用率は緩やかとなる可能性が高い為、ストレス計数(0.1〜0.9)をかけたシナリオも用意して算出。
またaのシナリオについても複数用意。
5分平均のピーク値をさらに30分、60分、90分に分散させたケースも用意。
以上より、CPUの利用率という観点での台数算出。
検討ポイント③：現状分析
CPUとメモリと同時接続の相関関係
→相関関係があり、検討ポイント①,②は妥当性があるかを確認メモリ使用率と閲覧ワークブックの相関関係
→抽出 or ライブ はそう程度通りか。Tabmonによるプロセス利用率の観測
→閲覧ワークブックが限定的で、キャッシュが効いているか。利用者の利用傾向分析
→曜日に傾向があるか。
→月初/月中/月末に利用傾向があるか
→月ごとに傾向があるか
現状分析により、検討ポイントの妥当性を固めにいきました。
全体を通して
あらゆるパラメータの中で
・何を観測し、
・どのように分析し、
・制約や条件、考慮不要観点は何で
・台数を算出するロジックを立て
・上記の仮説を検証し
・提案
上記の一連をほんの一部抽出したのが本記事になります。
リソース状況のモニタリングはまた別途記事に記載しますが、この思考の流れや結果を役立てる場面があれば思い出して頂けると幸いです。
続きは→