こんにちは。Shuntaです。今回、2023/5/9〜5/11の期間で米国ラスベガスで開催されている
Tableau Conference 2023 （TC23）に参加してきました。
TC23では200を超えるセッションが開催されていますが、個人的に興味のあるTableau Serverから Tableau Cloud への移行について、Salesforce社のセッションを聞いてきましたので、個人の経験を踏まえた補足を入れつつ、内容をシェアしたいと思います。
当記事の内容について、正確性を保証するものではありません。最新および正確な情報については、記事内に適宜リンクしているオンラインヘルプを参照してください。
はじめに
セッションの案内文に気になる一言があります。
“manually” 、つまり”automatically” ではありません。本セッションでも移行の自動化についてはあまり語られず、もっぱら手動での移行について語られていました。
Cloud移行にあたり、現状では魔法の杖となるソリューションは存在せず、地道に移行していくしかありません。本セッション及びこのレポートでは、この「地道な移行」について説明していきます。
セッションの内容
マイグレーション計画を立てる
このパートは少し遅れて参加したのであまり聞けていなかったのですが、
-
不要なViz、データソースなどは削除して綺麗にしておく
不要コンテンツ削除により移行対象を減らすことができますが、それにはサイト管理者だけではなくユーザの強力も必要です。計画立案時には、ユーザを巻き込んだコンテンツクリーニングの予定を立てる必要がありますね。 -
データ戦略を立てる
「データ戦略」というとかなり広い範囲をカバーする用語になりますが、 移行にあたっては、「ライブ接続か抽出か」「インターネット経由でデータソースにアクセスするのか、Tableau Bridgeを使ってオンプレミス環境のデータソースを維持するか」といった観点での戦略立案が対象です。 -
認証について考慮する
（Serverでできていた）レガシーな、オンプレミス環境のAD認証はサポートしてないので注意、というニッチな情報がいきなり出てきました。SSPIとかkerberosとかですかね。
ServerではアイデンティティストアとしてADを指定することができましたがCloudでは当然できません。認証連携の手法もSAMLに限定されるからADユーザは注意ね、ということですかね。
また、多要素認証（MFA）はTableauCloudでは必須となっていますね。（正確には「必須化されるからね」とアナウンスがあってからいろいろ伸び伸びになってますが）
多要素認証を備えたSSOソリューションと連携する方法、Tableauが用意する多要素認証など複数のオプションはありますが、いずれにせよこれまでServerに「IDとパスワード」でログインしていた環境からの移行ではUXに影響を与えますね。
参考：オンラインヘルプ
Cloudのサイトを作成する
-
ライセンス数、レベル（Creatorなど）
これはCloudライセンス購入により決まるもので、Cloudでは管理者が設定するようなことではないですね。 -
アドオンプロダクトの購入
Data ManagementはServer環境で導入していたら引き続き導入しましょ、という話ですが、Advanced ManagementはCloud移行に伴い考慮すべきアドオンです。さらっと「Additional site capacity」と書いてますが、アドオンの有無でサイト全体のストレージ容量や、コンテンツ１つあたりの容量などが変わってくるので、中〜大規模にServerを運用している環境では導入を検討する必要があると思います。
詳細はオンラインヘルプを参照ください。 -
サイト管理の事前設定を行う
サイト管理者が実施するサイト設定には実に多様な項目があります。
最低限の設定をしておき、あとは必要になったら修正していきましょう、とのことでしたが、実際はServerでの設定項目を参考にしながらある程度標準的な設定を定めておくことになるかと思います。
データソース、ワークブックを移行する
プロジェクト作成やユーザ追加は特筆すべき内容はありませんでしたが、データソースに関しては、特にTableau Bridge経由でのアクセスを選択した場合は既存のデータソースはそのまま使えないので、接続の再設定を行う必要があります。
また、フローは作り直しと書いていますが、再パブリッシュが必要ということですね。
また、データソースやワークブックの移行については後述のCMTで一部半自動化できる可能性があります。
パーミッションを設定する
パーミッションは、Serverに設定されていたものと同じものを設定することが基本となりますが、古いバージョンのServerを使っている場合、Cloudへの移行により新たに追加されるパーミッション項目に注意する必要があります。
抽出更新、サブスクリプションやフロー実行のスケジュールを再設定する
Serverでは、サーバ管理者が定めたスケジュール枠から選択して抽出更新などを実行することが基本（管理者による設定で例外あり）でしたが、Cloudでは、実行スケジュールをコンテンツの所有者が好きに決められるので、スケジュールの定義を移行するのではなく、同じ（または別の好きな時間帯で）スケジュールし直すことになります。
さらっと書いてますが、データドリブンアラートや、AskDataのレンズも後述のCMTの対象外ですので、ユーザにそれぞれ手作業で再設定してもらう必要があります。
Contents Migration Tool (CMT)ってどうよ？
さて問題の章がきました（笑）
CMTはServerからCloud（または他のServer）に一括でコンテンツを移行するためのツールです。CMTでできること及びその限界についてはたくさん書きたいことはあるもののセッションレポートの範囲を超えるので自重します。
オンラインヘルプを参照ください。
スライドにも制限・制約について書かれていますが、セッションでも
- CMT知ってる人手挙げて〜 → 結構あがる
- CMT使ったことある人手挙げて〜 → それなりにあがる
- CMT好きな人手挙げて〜 → ぐっと減る
- ですよね〜
といった自虐ネタが繰り広げられていました。。。
ただCMTは今後も鋭意改良予定だということなので、期待したいです。
移行結果の確認・テスト
ここからは移行結果の確認についてです。移行されたコンテンツ（の数や構成など）についてざっと目検で確認し、ユーザを巻き込んで結果確認をしてもらう必要があります。
この辺は泥臭い工程ではありますが、必ず必要になりますね。
重要なことは”Include them (key representative users) in a coordinated validation plan”と書かれている通り、ユーザに検証してもらうことを予め見込んでおくことだとスピーカーの方も強調されていました。「移行は一人（＝IT部門のみ、CoE部門のみ）でやるものではない、みんなでやるんだ」と。
このあたりの感覚は伝統的な「システム移行プロジェクト」とは異なるので、ユーザを巻き込んでいくには十分な動機付け、説明など、パワーををかける必要があると感じます。
マイグレーションの手引き
まだ英語版しかないようですが、マイグレーションの手引きが公開されています。
これまたTableauらしいなと思ってしまったのですが、セッションでは「このガイドに従ってやったらうまくいくぜ！」というトーンではなく「このガイドに従ってやってもうまくいかなかったらフィードバックおくれ！みんなでこのガイドをよくしていこうぜ！」といったトーンだったのが良い意味でも悪い意味でも印象的でした笑
おわりに
セッションに参加する前に持っていたCloud移行のイメージは「まだまだ手作業が多く、移行にはパワーが必要」というものだったのですが、セッションに参加して、そのイメージが確信に変わりました笑
とはいえ、「移行は大変」ではあるが「移行は不可能」ということではなく、Cloudの利用によって受けられる恩恵も沢山あるので、大変であることを理解しつつ、それだけのパワーをかけても移行すべきか、を検討した上で、移行することを選択した場合は必要な対応としてユーザも巻き込み頑張る、といったところでしょう。