トップ > 仕事紹介 > 古くて大きなTableau ServerをモダンなTableau Serverに統合した話


古くて大きなTableau ServerをモダンなTableau Serverに統合した話

仕事紹介 技術的な取り組み

Loading...

Integrated Data Service部 の @Matsushiman です。

普段はIDS部のデータエンジニアとしてニコニコ動画の数値解析ツールの開発やKADOKAWAグループ向けデータウェアハウスの開発、Tableau Serverのオンプレミスでのホスティングやライセンス管理などを行っています。仕事以外の面では、KADOKAWA Connected（以下KDX）の2022年度の従業員代表も務めています。

engineering.kdx.co.jp

手前味噌ですがKDX入社時のインタビュー記事がありますのでこちらも是非ご覧ください。

Yuki Matsushima｜KADOKAWA Connected Inc.

本記事は、一緒にプロジェクトを遂行したTableau Serverのホスティングサービスのメンバーである中島さんにも協力いただきながら執筆しております。

そんな我々が2022年の年初から取り組んでいたTableau Server統合プロジェクトが完了したので、今日はその話を書きます。この記事では、Tableau Serverに関する技術的な知見はさることながら、KDX流サービス型チームで中〜大規模プロジェクトを進行する際の様子についても記載するようにしました。KDXのデータエンジニアとして働くイメージを少しでも伝えることができれば嬉しく思います。

この記事を3行でまとめてみる

  • KADOKAWAグループ内にTableau Serverが2つ存在することによるデメリットを解消すべく、統合プロジェクトを実施した。
  • 想定外の課題が発生したものの、アドホックな対応ができる体制を整えて進めることで期限内にプロジェクトを完了することができた。
  • Tableau Serverの統合が完了したことで、KADOKAWAグループ一丸となってデータ分析を行なっていくための環境整備が一歩進んだ。

背景

Tableau Server とは？

みなさんは、Tableau というBIプラットフォームをご存知でしょうか？

BI（Business Intelligence）とは、データの可視化や分析を通して意思決定の支援を行うことであり、現在多くの企業でBIツールが導入されています。

Tableauは メジャーなBIツールのうちの1つで、KADOKAWAグループでもこのTableauを利用しています。例えばKDXのIDS部内では、CDO(Chief Data Officer)が障害について定量的に評価し、部署内への情報共有に使われています。

engineering.kdx.co.jp

この事例のように、ダッシュボードを共有するために利用するプラットフォームが Tableau Server です。Tableau Serverはダッシュボード(Taleauの世界ではワークブックと呼びます)・データソースの閲覧・ダウンロードなどの権限管理や、機能のユーザー別の制限が容易であることが特徴で、大規模ながらも信頼性を保ちつつTableauを用いたデータ利活用を推進できるプラットフォームだと理解していただけるといいかなと思います。

KADOKAWAグループに Tableau Server が2つあった

KADOKAWAグループには歴史的経緯により、Tableau Server が2つ存在していました。元々、ドワンゴとKADOKAWAで別々のデータプラットフォームが存在した背景などがあり、別々の管理者がTableau Serverを導入、管理していたのです。2つのTableau Serverの統合前におけるスペックは以下のようになっていました。

項目 Tableau Server (2021.3サーバー) Tableau Server (10.5サーバー)
ライセンス種別 ユーザーライセンス コアライセンス
ユーザー数 約200人 約2500人
ワークブック数 約400 約2500
Tableau Server バージョン 2021.3 10.5
ユーザー認証方法 Active Directory 認証 ローカル認証
構成ノード数 3 1
サーバー種別 Linux Windows

この他にもサーバーが立っているネットワークが異なる、保守運用者が異なるなど、あらゆる項目が異なる状況でした。

統合前におけるリスクとデメリット

統合前におけるTableau Server の状況や運用方法には、以下のようなリスク・デメリットがありました。

  • Tableau Server 10.5サーバーのバージョンが古く、セキュリティ上のリスクが存在した。

    • この点が最も大きな問題だったと思います。バージョン10.5はサポートが2020年7月に既に終了しており、新たに発見された脆弱性に対する処置がなされていない状況にありました。

    • 早急なアップデートが必要にも関わらず、10.5からアップデートは一筋縄でいかない（後述）こともあり、なかなか手を付けられない状況にありました。

  • Tableau Server 10.5が利用者人数に比べて構成ノード数が小さく、スペックに不足があった。
    • 当時のユーザー数やワークブック数から考えると、構成ノード数1は十分だったとは決して言えません。
    • また、そもそもノード数が1であることは、そのノードで障害が起こった際のバックアップがない状況であり、心許ない状況と言えました。
    • 加えて、Tableau Server 10.5はコアライセンス契約であるため、ノード数を増やすと追加で費用がかかってしまうこともあり、費用面からもノード数を増やしづらい状況でした。
  • 2つのTableau Serverで保守運用者が異なり、コストが二重にかかっていた。
    • ユーザやサイトの追加など同様の運用を行っている場合、運用者を統一した方がコストを抑えることができるのは言わずもがなかと思います。
    • また、保守運用者が異なることにより、運用方法も異なっていました。一例をあげると、2021.3サーバーではサイトを分けることで権限管理をしていたのに対し、10.5サーバーでは1サイトにおいてグループ単位で権限管理をしていたことにより、2つのTableau Serverの使い分けが煩雑になっていました。
  • 2つのサーバを使う必要があるユーザが増え始め、使い分けによる非効率が発生していた。
    • 元々は会社ごとにTableau Serverが存在していたわけですが、グループを横断したデータ分析事例も増えてきたことで、両方のTableau Serverを使うユーザーも増えてきていました。
    • 2つのTableau Serverでバージョンが異なっていたので、ダッシュボードをパブリッシュする人にとっては複数バージョンを使い分けて作業をする必要があり、煩わしい作業となっていました。
    • この状況では、1人のユーザに対してライセンスが2つ必要であり、コストが二重にかかっていました。

いざ、統合

この記事を読み進めたみなさんは「こんなにデメリットあるんやったら、さっさと統合してまえばええやん」と思われたかもしれません。しかし、そうは問屋が卸してくれないのです。
統合プロジェクトを発足するまでに、既に多くのワークブックを保持しているTableau Serverを統合することが技術的に可能かだけでなく、統合によるユーザー影響や統合後の保守運用方法など、実に多くの点を決める必要がありました。また、各Tableau Serverの保守運用者がそれぞれの他のプロジェクトで忙しくてなかなか腰を据えて話し合う機会を取れなかったことや、セキュリティ上のリスクがありつつも利用できてしまっていたことも、なかなか手をつけられなかった一因かもしれません。

ただ、KADOKAWAグループの成長にむけてDXを推進することは不可欠であり、グループ全体でのデータ利活用の機運が高まったことも相まって、ようやく統合プロジェクト発足に至りました。

統合のプロジェクト体制

さて、これから統合プロジェクトの進行についてお話するのですが、最初に本プロジェクトのメンバーやそのロールなどの体制を紹介しましょう。 本プロジェクトでは、

  • KDXのTableau Server運用・開発メンバー 4名
    • プロジェクトリーダー
    • 運用サービスオーナー(@Matsushiman)
    • 運用・開発エンジニア(中島さん含む2名)
    • 業務委託 2名
    • KDXのPMO部より派遣されたスクラムマスター 1名

の計6名でスクラムを組んで進めました。

KDX PMOについて

engineering.kdx.co.jp

1スプリントは1週とし、RoB(Rythm of Bissiness)として1日に1回の朝会、週に1回バックログ棚卸し、タスク確認会、2週に1回のKPTを開催していました。 作業中に他の人の力を借りたい、誰かと話しながら作業したい、というときに柔軟に対応できるように、「雑談部屋」というものも運用していました。

雑談部屋とは

KDXでは、ミーティングツールとして主にGoogle Meetsを使用しているのですが、その特徴として、一度部屋を作成したら作成者のアカウントがなくならない限りは部屋が残り続ける、というものがあります。 この特性を使って、Slackの関連ページにリンクを置いておき、急な相談からお勧めのお菓子の話まで、予定を別途組むほどではないけれど口頭で話したい時に使うようにしていました。

今回のプロジェクトに限らず、IDS部内の至る所で非公式ながらも導入されています。 もしかしたら名前は違えど同じような運用をしているチームは各所にあるかもしれないですね。

プロジェクトの開発チャンネルの関連ページ部分。他にもいろいろ載せてました

統合の方針の決定

統合後のTableau Serverは誰が使うのか？どう使うのか？に焦点を当てると、以下について明らかにする必要が出てきました。

  • 利用者数と必要なライセンス
  • 統合によって10.5サーバーから移行されるデータソース・ワークブック等のデータサイズ・負荷の増加
ライセンスについて

コアライセンスとユーザーライセンスで必要となる金額が変わるため、それぞれだといくらになるか試算しました。

コアライセンス

コアライセンスの場合、Creatorライセンスと、ServerのCPUコア数にかかるコアライセンス数で金額が決まります。 統合に際して、SalesforceのTableau営業ご担当者様に試算していただいた結果、24コアが必要ということがわかりました。

したがって、必要なライセンス数は以下のようになります。

  • Creatorライセンス 60
  • コアライセンス 24コア

また、運用について考えると、Creator以外のユーザーは自由に増やせるため、利用者の増加に伴った新規ライセンスの購入は不要になり、運用上は比較的楽になります。

ユーザーライセンス

一方で、ユーザーライセンスの場合、Creator、Exolorer、Viewerライセンスが必要となります( Tableau の価格 (チーム & 組織向け) )。 こちらは、1ユーザー1ライセンスとなるため、コアライセンスと比べるとユーザー数がスケールしにくいという点があります。

利用者数と必要なライセンス

利用者数に関しては、Tableau Serverリポジトリ( Tableau Server リポジトリでデータを収集する - Tableau )を使って、直近1年でアクティブになったユーザー数を出しました。

アクティブになっていないユーザーのアカウントを棚卸対象として、移行対象のユーザーとするかどうかの選定を行いました。

前述のように、10.5サーバーはコアライセンスで運用されていたため、ユーザーライセンスで運用されている2021.3サーバーに利用者を統合するためには、利用者のユースケースについて調査する必要がありました。

主にヒアリングによって調査を行った結果、以下のようなユースケースが存在することがわかりました。

  1. Tableau Desktopを利用してワークブックやデータソースをパブリッシュし、分析やその共有を行う
  2. Tableau Server上にあるワークブックを見る
  3. Tableau Server上にあるワークブックからクロス集計データをダウンロードし、手元でExcel等を用いてさらに分析を行う
  4. Tableau Server上にあるワークブックを、編集モードで操作し、細かいデータの変化を確認する(保存はしない)

Tableauの各ライセンスタイプの想定ユースケース( Tableau のライセンスタイプ - Tableau )と見比べると、1はCreator, 2はViewer, 3,4は少し特殊ですがExplorerが適当だとわかります。 調査・棚卸しの結果、それぞれのライセンスが以下の数だけ必要なことがわかりました。

  • Creatorライセンス: 60
  • Explorerライセンス: 50
  • Viewerライセンス: 900

上記の結果を踏まえ、SalesforceのTableau営業ご担当者様に協力していただいた調査の結果、ライセンス金額はユーザーライセンスのほうがコアライセンスよりもかなり安く運用できることがわかりました。

スペックについて

前述の通り、2021.3サーバーと10.5サーバーではノード数にも差があり、スペックとしては以下のようになっています。

  • 2021.3サーバー

    • OS: CentOS 7
    • primary 16CPU/64GB
    • worker1 8CPU/64GB
    • worker2 8CPU/64GB

  • 10.5サーバー

    • OS: Windows Server 2012RC
    • primary 8CPU/128GB

2021.3サーバーでは、構築にはansibleを用いていたりと流用できる資産が多くあります。さらに、複数ノードで構成されていて冗長性のある2021.3サーバーに寄せた方が、今後のメンテナンスやスケールの手間が少なくなるという利点もあります。

したがって、スペックや構成も2021.3サーバーに寄せていく方針にしました。

統合によって10.5サーバーから移行されるデータソース・ワークブック等のデータサイズ・負荷の増加

10.5サーバーにはおよそ2500のワークブックがあったのですが、愚直に移行しても使われなければストレージの無駄遣いになります。

そのため、ユーザーヒアリングを通して何が必要で何が不要かの棚卸しを行いました。

棚卸しの後、移行対象のファイルサイズがおよそ120GBあったため、10.5サーバーと同規模のサイズが移行されることが予想されました。

10.5サーバーのプライマリサーバーのストレージサイズは512GBで運用していましたが、バックアップを作成したりすることを想定すると少し心許ないサイズであることがわかります。 また、利用者の増加に伴ってServerの処理の負荷がどれくらい大きくなるかを考える必要があります。

これに関しては、上記で出したアクティブユーザー数と、定期的に行われるデータソースの更新の数をもとに、SalesforceのTableau営業ご担当者様に相談しながら推定しました。

おおよそですが、こちらも10.5サーバーで行われる処理と同等か、それより小さめの負荷があることがわかりました(利用者数に比べてかなり少ないのは驚きでした)。

以上のことから、プライマリノードに256GBのストレージ追加をすることで移行されるものを迎えることにしました。

移行作業

いよいよ統合の一番大切なところである統合作業に移ります。

「統合」とはいったものの、基本的には2021.3サーバーから10.5サーバーへの移行となるため、10.5サーバーのデータ等の資材をいかに2021.3サーバーに確実に持っていくかが大事になってきます。

プロジェクト当初より、以下のスケジュールで移行する予定を立てていました。

  1. 10.5サーバーでエクスポートファイルの作成
  2. 2021.3サーバーで10.5サーバーから移行するユーザー・グループ・スケジュール作成
  3. 10.5サーバーから2021.3サーバーへのエクスポートファイル転送
  4. 10.5サーバーでエクスポートファイルのインポート

しかし、そう簡単に物事は進みませんでした。

ユーザー・グループの移行問題

Tableau Serverのユーザー作成方法は「ローカルユーザー作成」と「ActiveDirectoryユーザーインポート 」の2通りあります( Tableau Server へのユーザーの追加 - Tableau )。

1つのサーバーに対しては基本的にどちらかしか使用できないため、片方の方法で作成されたユーザーをもう一方で作成されたTableau Serverにそのまま移行することはできません。

10.5サーバーはローカルユーザー、2021.3サーバーはADユーザーで作成するようになっていたため、ユーザー及びユーザーに紐づくグループ情報は、新しく作り直す形で移行する必要がありました。

流石にTableau Serverのweb UIから手作業で追加できる数ではなかったため、Tableau Server REST APIでガッとやってしまうことにしました。

  1. 10.5サーバーの利用者一覧と、KADOKAWAグループ内のActiveDirectoryのユーザー名を突合
  2. 利用者のADユーザー名一覧を作成し、Tableauの提示する手順 に従ってユーザーインポート用のcsvを作成
  3. 10.5サーバーのユーザーとグループの対応をREST APIを用いて作成し、KDX Tableau Serverへの適用

Tableau Server 10.5→2021.3移行不可能問題

なんと、移行のための事前検証の段階で、Tableau Serverのバージョンが10.5のものから2021.3へのデータ移行( サイトのエクスポートまたはインポート - Tableau )が直接行えないことが判明しました。

また、10.5サーバーもユーザーが利用している状態のため、移行も切り戻しもできなくなる可能性も考慮に入れ10.5サーバーの直接のアップデートを行わず、以下の手順で実施することになりました。

  1. 10.5サーバーのバックアップ作成
  2. KDXで2020.4のTableau Serverを別途構築（以降、リストア用のサーバーとする）し、1のバックアップをリストア
  3. 2020.4のTableau Serverを2021.3サーバーと同じ2021.3にアップデート
  4. 3でアップデートしたTableau ServerをExportし、2021.3サーバーにImport

移行用ファイル移動の問題

いよいよ本番のServer統合作業に移ります。

ここで、KADOKAWAおよびKDXのネットワークについてお話しします。

実は、前述のリストア用のサーバーはTableau Server2021.3サーバーの本番運用している環境とは疎通が取れない環境に立っていました。

なので、移行のためのバックアップファイルやExportファイルの移行は、ローカルPC経由で移行することになります。

今回のプロジェクトはフルリモートで行われたため、数十〜百数GBのファイルを、VPN経由で転送する必要があり、転送だけでおよそ5時間程度かかっていました。

また、転送の際の作業者の自宅ネットワークの瞬断等によってファイルが壊れたりしたため想定よりも多くの転送作業が発生しました......
リモートワークならではの困りごとは往々にしてコミュニケーション部分に生じるという話が多いですが、こういう部分にも影響が出るようです。
ファイルが壊れたことによるエラーの原因が発覚当初は分からなかったため、雑談部屋で何人かが集まって作業することになりました。
3人集まればなんとやらで、エラーの原因はファイルの破損であることが発覚しました。
ダウンロード中に作業者のPCがスリープしてしまうために起こる破損であったため、スリープ設定の解除や、転送作業を朝から始めて、定期的に転送の進捗を確認共有をする、といった対応をすることになりました。
このようなアドホックな対応のための雑談部屋利用はかなり良かったかと思います。
この問題によって、あわやプロジェクト期限破りか、というところでしたが、スクラムマスターに主導してもらいながら予定の立て直しによって難を逃れることができました。

アクセスが制限されたデータソースの移行問題

また、データの移行に関しても問題が発生しました。
KADOKAWAのネットワーク内でしかアクセスできないところに立っているOracleサーバーからデータソースを作成しているものがあり、Oracleサーバーがglobal IPを取得していなかったため、社内のネットワークチームに依頼して疏通を開けてもらうという最終手段も時期的に取れないものでした。
この問題に対する解決方法として、バッチ処理によるデータソース・ワークブックのダウンロード・パブリッシュを行うシステムを作成することになりました。
統合終了ギリギリで発覚したため、急ごしらえで用意することになりましたが、なんとか稼働しています。
ユーザー追加や、2021.3サーバーの通常の運用でTableau Server REST APIによる開発の知見が溜まっていたのでかなりスピーディに対応できました。

移行後

さて、すったもんだあった移行作業は完了し、プロジェクトも完遂しました。 しかし、我々はサービスとしてTableau Serverを提供しているので、継続的に価値を提供する必要があるわけです。

旧運用方法の移管

10.5サーバーの運用方法を踏襲して利用者のサポートを行い、ユーザー体験を極力損なわないようにしなければなりません。

具体的には10.5サーバーの運用方法の「ユーザー追加と権限管理」を踏襲する必要がありました。

ユーザー追加・権限管理は、「Aさんから新規利用したいという申請があったため、Bさんと同じ権限を付与する」という形で行われていました。

10.5サーバーでは、APIをキックしてこれらを付与するバッチ処理が行われていたのですが、統合先である2021.3サーバーではTableau Serverのグループ機能をほとんど使用していなかったため、そのようなシステムはありませんでした。

そのため、手作業でこれらを行う必要があります。

当然、自動化すれば良いのですが、統合プロジェクトでためていたサービスメンバーの他のタスクの合間を縫って開発するには時間が少なく、残念ながら今現在も自動化までは至っていません。

しかし、愚直に行うにしてもそれなりの労力がかかるため、ユーザー - グループの対応表や、ユーザーの権限(ライセンス)の一覧化プロセスの整備という形で対応するようになりました。

問い合わせ対応

統合に伴って環境が変わったため、利用者からの問い合わせが複数来るようになりました。

統合直後は、1日で十数件の問い合わせが来る、といったこともあり、サービスのメンバーだけでなく、契約期限ギリギリまではプロジェクトのメンバーにも手伝ってもらう形で対応をしました。 その多くは「ワークブックが見られない」「ログインできない」といったものでした。

「ワークブックが見られない」という問い合わせは、ほとんどが前述の権限管理の段階であるべき形にグループ権限が付与されていないことが原因でした。

「ログインできない」という問い合わせの原因は、ローカル認証からADユーザー認証に変わったことによるID・パスワードの変更によるものでした。

可能な限り大々的(KADOKAWAグループのほとんどの社員が所属するSlackチャンネルでの周知やメールの送信)に周知したつもりではいたのですが、なかなか伝わりきらずこのようになってしまいました。

これは、今後、停止メンテナンスなどのユーザーへの全体周知を行う際のコミュニケーション方法を見直すきっかけになりました。

まとめとこれからの展望

できたこと

統合前・統合作業・統合後といったところでそれぞれ課題が生まれながらもプロジェクトは進行していきましたが、プロジェクト立ち上げ時点で決めていた期限までに統合が完了したのは、細かい頻度のRoB・課題管理や、アドホックな相談ができる雑談部屋が効いたのだと思います。

また、統合によって(形式的には)データを根拠とした知見が一箇所に集まることになったため、これからグループが一丸となってデータ分析を行なっていくための第一歩となりました。 今回参画したKDXのTableau Serverを提供するサービスのメンバーはあくまでも使い方までのサポートを行うチームですが、KDXのIDS部にはBIツールを使ったデータ分析のプロフェッショナルが集うチームもあります。また、Tableauを用いたデータ分析のレクチャーを行うチームもあるため、これからグループ全体にデータ分析の波が広がっていくことに期待しています。(なんと今回共同執筆していただいた中島さんは、そのメンバーの一人でもあります！)

PMO部より派遣されたスクラムマスターによって、課題の発見→対策のイテレーションをかなり早く回せたのも良かったです。 統合作業の終盤の怒涛の勢いのスケジュールの組み直しや役割分担のおかげで、プロジェクトのゴールまで到達できました。

余談ですが、雑談部屋はIDS部以外のメンバーからの評判がかなり良かったです。
IDS部内では浸透しつつある非公式なシステムですが、導入によって成功した事例もまた機会があれば共有できたらと思います！

できなかったこと

前述の通り、ユーザー管理、アクセスできない場所にあるデータソースの扱いの点ではまだまだスマートでない部分があります。

特に、「統合後の利用者数と必要ライセンス数、サーバースペック検討の必要性」で挙げた特殊なExplorerの利用方法に関しては、使われ方としては「編集結果が残らない」という点でイケてないと感じています。

より良いBIツールとしての立ち位置を確立するためにも、前述のBIツールプロフェッショナルやトレーニングチームと協業して整えていきたいです。

これから

とりあえずの形で統合は完了し、大きな問題もなく運用はされていますが、それでも泥臭い作業が残っていたり、グループで統合したことによるデータ活用の面での価値をフルに生み出せていません。

特に、グループ全体でのデータ分析文化の醸成という点においては、Tableau Serverや分析基盤の統合を起点として始められる状態になったので、この点の難しさと楽しさを享受しながらサービスを運営していく所存です。

P.S.

色々と書きましたが、一番大変だったのは10.5→2019.4→2021.3と段階を踏んだデータの移行でした。 オンプレミスでTableau Serverを管理されている方々はサーバーのバージョンは定期的にアップデートすることを強く強くお勧めします。

©KADOKAWA Connected Inc.