この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
さがらです。
Lookerでインスタンスを2つ用意して、開発環境・本番環境と2つの用途で分けて使用している場合、必ず「開発環境➟本番環境へのデプロイ」ということが必要になってきます。
「LookerはLookMLでコード管理しているからリポジトリ連携すれば終わりでしょ」と思われる方もいるかもしれませんが、そんなことはありません。
この理由と、どういったデプロイ方法がありそれぞれどんなメリット・デメリットがあるのか、をこのブログでまとめていきます。
開発➟本番へのデプロイが一筋縄でいかない理由
さて、改めてLookerでの開発環境➟本番環境へのデプロイが一筋縄ではいかない理由を考えてみます。
それは、Lookやダッシュボードなどの”コンテンツ”は、コードで定義されていないためです。具体的には下図のような状況に陥るかと思います。（わかりやすくするため諸々省略しています。）
LookMLで定義したModelやViewは、WebhookやDeployment Managerを介して本番環境へのデプロイも難なく行えるかと思います。
しかしLookやDashboardなどのコンテンツはどうでしょうか、コード化されていないためGithubを介すことも出来ませんし、ファイルのようにコピー&ペーストで別のインスタンスへ複製することも出来ません。
そのため、LookやDashboardをどうやって本番環境にデプロイするかが、ポイントになってきます。こちらについて方法が大きく２種類ありますので、次の章で説明します。
Dashboard等のコンテンツの開発➟本番へのデプロイ方法
その1.LookML Dashboardでコード化する
まず1つ目の方法が、LookML Dashboardに変換して、ダッシュボードもコード化してしまう方法です。
具体的には下図のように、開発環境のインスタンスにおいてダッシュボードをGUIで作成した後LookML Dashboardに変換してコード化し、WebhookやDeployment Managerを用いて本番環境へデプロイする、という流れになります。
この方法については、具体的な手順は下記のブログにまとめております。
その2.Looker Deployer等のOSSを使用する
2つ目の方法が、Looker Deployer等OSSのツールを使用して、特にコンテンツを変換することなく、そのまま本番環境にデプロイする方法です。
具体的には下図のように、デプロイのタイミングでOSSのツールでコマンドを実行し、本番環境にダッシュボード等のコンテンツをデプロイする、という流れになります。
この方法について、OSSのCLIツールの1つであるLooker Deployerを用いた実際の手順を下記のブログにまとめております。
それぞれのメリット・デメリット
続いて、これら2つの方法にどういったメリット・デメリットがあるのかをまとめます。
その1.LookML Dashboardでコード化する
メリット
- URLに記載されるダッシュボードIDが開発環境と本番環境で同じ値にすることが出来る
- Linkパラメータを用いたダッシュボード間のリンクをしたいときに便利。
- 全てGitでの管理ができるため、これまでの履歴の確認が出来る
- データモデルだけでなくダッシュボードも履歴管理できるようになるため、万が一ダッシュボードの削除等の問題があっても簡単に復元できる。
デメリット
- ダッシュボード修正時のプロセスが少し手間がかかる
- LookML Dashboardのままでの修正はとても難しいため、開発環境のダッシュボードを一度User-Defined Dashboardに直してから修正し、再度LookML Dashboardに変換し、本番環境にデプロイしないといけない場合が多い。
- 1つのフォルダに集約されてしまい、フォルダの階層構造も作れない
- LookML Dashboardは全て「All folders➟LookML Dashboards」というフォルダに格納されてしまう。Whitelabelを用いたOEMでの外部への提供などを考えた時、全てのダッシュボードが1つのフォルダにまとまっていると使いづらくなる可能性がある。
その2.Looker Deployer等のOSSを使用する
メリット
- LookML Dashboardよりも修正時の対応が簡単
- GUIで定義したUser-Defined Dashboardのままデプロイが出来るため、ダッシュボードに少し修正が必要となってもGUI上で直してすぐにデプロイが可能。
- 任意のタイミングでのデプロイが可能
- Webhookを使ったデプロイだとPushを通知したとき等にタイミングが限られてしまうが、OSSを用いた場合、コマンドを実行した時にデプロイが行われるので、デプロイ実行タイミングの自由度が高い。
デメリット
- ダッシュボードのIDが開発環境と本番環境と異なってしまうため、ダッシュボード間のLinkパラメータが機能しなくなってしまう
- ダッシュボード間のリンクを行いたい場合は、LookML Dashboardを使うしかない。
- トラブル発生時にLookerの公式サポートが使えない
- Looker DeployerなどのOSSツールはLookerの公式サポート対象外であり、上手く動かない等のトラブルがあったときはOSSのリポジトリにissue発行で対応してもらうしかない。
使い分け方
前章ではメリットとデメリットを記しましたが、「じゃあどっちを使えばよいのだろうか？」と疑問に感じている方もいるかと思います。
そこで、私が思う使い分け方をまとめてみたいと思います。一つの考え方として、参考になれば幸いです。
その1.LookML Dashboardでコード化する
- デプロイしたダッシュボード間でのLinkパラメータを設定している時
- URL上のIDを固定化出来るのはLookML Dashboardのみのため。
- Gitで全てを管理したい時
- 各プロジェクトごとに、データモデルもダッシュボードも全て1箇所にまとまっており、バージョン管理も出来るようになる。
その2.Looker Deployer等のOSSを使用する
- デプロイ先の本番環境でも開発環境と同じフォルダ構成でダッシュボードの管理をしたいとき
- 特にWhitelabelを用いたOEMでの外部への提供のときは、コンテンツを目的・役割ごとにフォルダで分けて、より探しやすくなるため良いと思います。
参考情報
複数インスタンスを持っているときのデプロイの考え方について、英語ですがより詳しくは下記のページにまとめられています。
こちらのページでは、Dev>QA>Prodという3つのインスタンスでの考え方など、本番環境にデプロイするまでに考えるべきことが幅広く記載されています。
なかなかに大作ですが、自分が知る限り複数インスタンスを用いたときの情報については、このページが一番詳しく記載されていると思います。是非こちらも御覧ください！
最後に
いかがでしたでしょうか！
Lookerでの開発環境➟本番環境のデプロイは大きく2つの方法があり、それぞれにメリット・デメリットがあるため、要件に応じて使い分ける必要があることを本ブログでまとめてみました。
こちらのブログが少しでも参考になれば幸いです！
3
