#tc18 [レポート] Tableau Serverの導入時にチェックするポイント – Tableau Conference 2018 at New Orleans
目次
セッション概要
当セッションの概要は以下の通りです。
<レベル> Intermediate
<セッション概要> Join this session to learn key deployment best practices using a combination of real-world examples and our own internal testing (whether you’re deploying Tableau Server in the cloud, on VMs, or on physical hardware). We'll show you how Data Server, micro-services, and more will affect your deployments, and leave with tangible takeaways, applicable to your unique environments. (このセッションに参加して、事例と独自の内部テスト(クラウド、VM、または物理ハードウェアにTableau Serverを導入しているかどうか)を組み合わせたベストプラクティスを学びます。 Data Server、マイクロサービスなどが導入にどのように影響し、独自の環境に適用できる「重要なTips」をご紹介します。)
セッションレポート
Tableau Server導入事例(大手金融サービス企業)
概要
- 9ノード
- 数千人同時ユーザー
- キャッシュ重視
- バックグラウンダーを2つ用意したワーカーが2台
- 並列処理
このような大規模なTableau Serverの導入に成功した理由を見ていきましょう。
コンテンツの管理
彼らが最初に考えなければならなかったことは2つあります。1つ目はTableau Serverの構成でした。Tableau Serverはクラスタリングをサポートしていますが、1台でもインストールは可能です。これは非常に一般的なケースです。一方で、高可用性のために分散構成を選択する顧客もいます。この企業はクラスタ構成を選択しました。
2つ目はコンテンツの適切に管理してユーザーに表示する方法です。Tableau Serverにログインすると「デフォルトサイト」に遷移しますが、この「サイト」はいくつも用意することができます。サイトは「テナントのカプセル化」のように考えることもできます。
Tableau Serverにはプロジェクトという概念もあります。これはWindowsのフォルダのようなものです。ワークブックのデータソースはすべてプロジェクト内に保存されています。プロジェクトは、フォルダのように入れ子にすることも可能です。この企業は入れ子にしたプロジェクトを使用しています。
パーミッションとコンテンツの分離
次に考えたことは、パブリッシュしたコンテンツに対する権限です。この金融会社は、Tableauの本来の柔軟な権限を使用することを採用しました。
- 柔軟なパーミッション設定
- Active Directoryと統合されたユーザーとグループ
- 制限されたプロジェクトのプロジェクトレベルでのロック
- セルフサービスのサンドボックスはオープン権限
- 入れ子プロジェクトのアクセス許可
- 認定されたデータソースのアクセス許可
- サイト管理者、サーバー管理者、プロジェクトリーダー、所有者
データの接続性
次にこの会社が考えたのは、データへの接続性です。もし、分析するデータソースがOracleやRedshiftなどだった場合、Tableau Desktopからそれらに実際に接続できることを確認する必要があります。ファイアウォールが適切に設定されていることも合わせて確認します。そして、それはTableau Server自身も接続できる必要があります(前述したデータソースを使用したワークブックをTableau Serverにパブリッシュすると、今後そのワークブックの元となるデータはTableau Serverが問い合わせるから)。同じパブリッククラウド上にTableau Serverとデータソースが配置されている場合もあるかと思いますが、そういう場合でもセキュリティを考え、ファイアウォールを注意深く監視しましょう。
セルフサービスとガバナンス
次は「セルフサービスと統治」です。この企業はデータソースを管理して適切にユーザーに公開する方法について多くのことを考えました。
彼らはいくつかのフォルダと潜在的にいくつかのサイトを設定しました。そして、誰もが会社内で共有すべきデータに接続し、それを使って作業するように設計されています。例えば、書き込み可能なすべての個人ユーザー用のプロジェクトがあり、既定では誰もが共有できるように閲覧することができます。
また、サイトとプロジェクトの両方を使用して組織内のサブグループにアクセス権をロックし、適切なグループだけがそれらのデータソースを参照できるようにすることが非常に重要であることを数回述べました。それには、認証されたデータソースを使用します。データソースの統治として重要なことは、データをロックするだけではなく、多くの組織で適切なデータに接続することをユーザーに知らせることです。例えば、売上のデータソース一つとっても、実際には数百のデータソースが存在する可能性があります。正しいデータソースを「認証」することで、検索結果に最初に表示され、ユーザーが使用すべき唯一のものであることが非常に明確になります。
セキュリティ
金融企業にとってセキュリティは最も重要です。この企業はTableauが提供するあらゆるセキュリティオプションを考慮しました。シングルサインオンとしてKerberosを使用し、Vizに対する「行レベルのセキュリティ」まで実現しています。また、SSLも設定していますが、これはTableau社としても導入をオススメしています。
ハードウェア
このTableau Server環境のスケールについても考える必要がありました。結論からいうと、上記のようなマシン構成になっています。クラスターはVMwareの仮想環境に導入しています。
監視
Tableau Serverの監視として、監視レベルに応じて下記のような体制を組みました。
- システムレベルの監視:SRM、TabMon、その他サードパーティのツール
- サービスレベルの監視:JMX、ログ、
- プロセスレベルの監視:管理ビュー
- ユーザーレベルの監視:監査、ワークブックのパフォーマンス、管理ビュー
スケーラビリティについて
Tableau Serverには2つのスケール拡張方式があります。スケールアップとスケールアウトです。
スケールアップするのか、スケールアウトするのか、それらは2つの質問から判断できます。
- 何人のユーザーがTableau Server閲覧し、データを探索していますか?
- あなたのデータはどれくらいの頻度で更新する必要がありますか?
2つの質問に対する答えの組み合わせで、どれくらいスケールアップ or スケールアウトすればいいかがわかります。例えば「高速道路の交通状況のダッシュボード」は、常に最新状況が必要なため、データ更新頻度は「ライブ接続」ですが、それを使って分析するユーザーはそこまでいない…その場合はスケールアウトを優先する方針となります。
Tableau Server導入チェックリスト
今の事例で紹介した部分が、そのままチェックするべき項目となっています。Tableau Serverの導入時は、先に下記を考慮しておきましょう。
Tableau Serverのアーキテクチャ
Tableau Serverのアーキテクチャは上記のようになっています。各レベル毎にプロセスが別れているので、クラスタ構成時は、運用体系にあわせて増強することも考えましょう。
参考
Tableau Server 2018年の新機能
最後に今年リリースされたTableau Server新機能について紹介します。
(やはり、TSMは目玉らしく、がっつり紹介されていました。)
参考
- Tableau 2018.2 新機能紹介:TSM(Tableau Services ManagerまたはTableau Server Manager)登場の巻 #tableau | DevelopersIO
- Tableau 2018.2 新機能紹介:TSM CLI入門 #tableau | DevelopersIO
まとめ
Tableau Serverを導入する際にチェックする(気をつけておく)ポイントの話でした。どれも大事だとは思いますが、個人的にはやはりセキュリティを一番気をつけるべきかな、と思いました。認証方法はインストール後に変更できない部分ですし、何より「データ」を扱うプロダクトなので、見せてはいけない人には見られないようにする…という仕組みは、企業全体としても大事かなと考えています(コンテンツやパーミッションは後からいくらでも変えられるので)。