背景

私たちは、社内向けのTableau Serverを運用しています。このサーバーでは、様々なデータソースからデータを抽出し、分析やレポーティングを行っています。しかし、社外のパートナーやクライアントにもレポートを共有したい場合があります。そこで、社外向けにもTableau Serverを作成しました。社外向けのサーバーでは、データの抽出は行わず、レポートの閲覧のみを目的としています。

このように、環境を分けることには、以下のような理由があります。

データガバナンスを強化するため
社外向けのサーバーでは、必要なデータのみを公開し、アクセス権限を制御することができます。
サーバーリソースの管理をシンプルに
抽出用のサーバーと閲覧用のサーバーを分けることによりサーバーのリソースをより柔軟に管理できるようになります。

しかし、環境を分けることには、以下のような課題もあります。

クラウドDWHの費用が倍に
私たちは、クラウドDWHをデータソースとして利用しています。クラウドDWHでは、クエリーの実行回数やデータ量に応じて料金が発生します。2台のTableau Serverに同じデータを抽出すると、クラウドDWHの料金が2倍になってしまいます。
ダッシュボードの同期を手動で行う必要がある
社内向けのサーバーでダッシュボードを作成・更新したら、社外向けのサーバーにも同じダッシュボードをパブリッシュする必要があります。これは、手間がかかるだけでなく、ヒューマンエラーの可能性もあります。

そこで、私たちは、Tableau Server間のダッシュボード同期を自動化するツールを作成してみました。

ツールの仕組み

私たちが作成したツールの仕組みは、以下のようになっています。

Tableau Webhook APIを利用して、社内向けのサーバーでダッシュボードが作成・更新されたときに、AWS Lambdaをキックするように設定する。
AWS Lambdaでは、Tableau Rest APIを利用して、社内向けのサーバーからワークブックをダウンロードして、社外向けのサーバーへパブリッシュする。

このようにすることで、社内向けのサーバーでダッシュボードを作成・更新するだけで、社外向けのサーバーにも同じダッシュボードが自動的に反映されるようになります。

注意点

このツールを作成するにあたって、いくつかの注意点がありました。ここでは、その中から主なものを紹介します。

Tableau ServerからはREST APIでシートの表示・非表示情報を取得できない
何故かTableau Server上ではワークブックのパブリッシュの際に指定したシートの表示・非表示情報をREST APIで取得することができません。（ワークブック編集中に指定するシートの表示・非表示とは別で、パブリッシュする際に指定するシート選択の機能による表示非表示情報についてです。）
検索してみるといくつか同様に困っている方を見かけました

RestAPIで取得できないためダウンロードしたワークブックをLambda上でUnzipしてXMLを解析することで表示/非表示情報を取得し、パブリッシュする際に表示/非表示情報をXMLにて指定して解決しました。（ただ、実装したあとにTableau SupportからTableau メタデータ APIを利用したら取得出来るかもとの回答を頂きました。何事もまずは聞いてみるのが重要ですね。）

エラーが発生するとWebhookが無効になる
Webhookを設定するときに、4回エラーが発生した場合に登録したwebhookが無効になります。
レスポンスコードで200を返さないと4回目に無効になるためエラー処理を入念にして200以外で返らないようにする必要があります。
Webhook実行トリガー
Webhookを設定するときに、トリガーとなるイベントを選択することができます。私たちは、ワークブックとデータソースの両方を同期するために、以下のイベントを選択しました。
- ワークブックが作成されたとき
- ワークブックが更新されたとき
- データソースが作成されたとき
- データソースが更新されたとき
  また、Lambdaでは、ワークブックとデータソースのダウンロード・アップロード処理を別々に行う必要がありました。これは、ワークブックとデータソースのファイル形式やAPIのパラメータが異なるためです。

本システムのメリット

このツールを作成することで、以下のようなメリットが得られました。

抽出用のサーバーと閲覧用のサーバーを切り分けることでリソースの管理が容易に
社内向けのサーバーでは、データの抽出や更新を頻繁に行うことができます。社外向けのサーバーでは、データの閲覧のみを行うことができます。これにより、サーバーの負荷やパフォーマンスを最適化することができます。
コストが半額に
2台のTableau Serverにパブリッシュした場合両方に抽出がかかるとクラウドDWHでは料金が2台分の料金がかかるところ、1台で抽出した結果をそのままもう一台のサーバーに送るので1台分の料金で済むようになりました。クラウドDWHの料金は、クエリーの実行回数やデータ量に応じて発生します。2台のTableau Serverに同じデータを抽出すると、クラウドDWHの料金が2倍になってしまいます。しかし、このツールを使うと、1台のTableau Serverで抽出した結果をそのままもう一台のサーバーに送ることができます。これにより、クラウドDWHの料金を半分にすることができます。
データ更新速度が速く
要件にもよるがクエリーを2回実行するより1回実行してその結果をもう一台に転送したほうが時間も短縮できます。データの抽出には、データソースの種類やサイズ、クエリーの複雑さなどによって時間がかかります。2台のTableau Serverに同じクエリーを実行すると、その分だけ時間がかかってしまいます。しかし、このツールを使うと、1台のTableau Serverでクエリーを実行した結果をそのままもう一台のサーバーに転送することができます。これにより、クエリーの実行時間を半分にすることができます。

本システムの開発に役立った情報・ツール

Tableau Webhooks Docs
英語しかありませんがWebhookを設定するのであれば必ず一通り読んでおいた方が理解しやすいです

Tableau REST API Help
ドキュメントは大分量がありますが、分かりやすかったです

Postman
Rest APIやWebhook APIをテストするに当たって非常に便利でした

GitHub Copilot＋ChatGPT4
今回AWS LambdaにてPythonを書きましたが、生成AIに非常に助けられました。
TableauのAPIの情報はChatGPT4で学習されており、実際に自分がやりたい事を伝えるだけでコードのテンプレートを大方作ってくれます。また、修正や機能追加などGitHub Copilotが非常に役立ちました。ちょっと怖いくらいに予測して書いてくれます。

まとめ

以上が、Tableau Webhook APIを利用してTableau Server間のダッシュボード同期を実現する方法についての紹介でした。
生成AIを使って作成した記事なのでやや見づらい点があるかもしれませんがこれだけの情報を手軽に共有出来るのも凄いですね。
需要があればコードも共有するかも？