チュートリアル：宣言型自動化バンドルを使用して、AI/BIダッシュボードの変更を安全かつ大規模にデプロイする方法

エラーだらけのダッシュボードで取締役会が始まることを想像するだけで、アナリティクスチームは夜も眠れなくなるはずです。採用計画、製品のローンチ、あるいは収益予測が誤ったメトリクスに基づいていたことを後から知ることも同様です。あるいは、ダッシュボードが顧客の購入履歴を誤って表示したために、サポートチームが過剰な払い戻しを行ってしまった場合も同様です。

こうした失敗が、分析の質の低さによって引き起こされることは滅多にありません。他の本番システムと同様に、データモデルや要件が進化する中でダッシュボードが手動で更新されることが原因であることがよくあります。バージョン管理や、信頼できるレビュープロセス、環境間で変更を反映するための再現可能な方法がないまま更新されてしまうためです。

このブログ記事では、シンプルな主張をしています。それは、ビジネスを推進する本番環境グレードのダッシュボードは、本番コードと同じ規律で管理されるべきであるということです。Databricks AI/BIは、データパイプラインやガバナンスレイヤーと同じData Intelligence Platform上で動作するため、チームはバージョン管理、環境固有の構成、制御されたデプロイといった本番環境でのプラクティスをダッシュボードにも同様に適用できます。

これを具体化するために、アナリストが日々のダッシュボード作成方法を変えることなく、本番環境グレードのDatabricks機能を使用する方法を紹介します。

具体的には、このフローによって以下のことがどのように可能になるかを示します。

• ダッシュボードへの各変更をレビューして承認する
• ダッシュボードの履歴を追跡し、コードの変更をビジネス要件に関連付ける
• ダッシュボードを以前のバージョンにロールバックする

前提条件

このワークフローには、ほとんどの組織がすでに導入している、1回限りのインフラストラクチャのセットアップが必要です。まだお持ちでない場合は、社内のDevOpsまたはITグループにセットアップの支援を依頼してください。

• ダッシュボードの作成、テスト、デプロイを行うための少なくとも2つのDatabricksワークスペース（開発用と本番用のワークスペースなど）
• ダッシュボード定義のバージョン管理に使用される、DatabricksのGit連携フォルダ（AWS | Azure | GCP）
• プロジェクト用に構成されたDeclarative Automation Bundles (DABs)（AWS | Azure | GCP）

はじめに：ダッシュボードの変更を安全にリリースするための構造化されたワークフロー

財務および営業のリーダーシップが毎週使用するSales Performanceダッシュボードを所有しているという、現実的なシナリオを見ていきましょう。これは、最初はインターンがワークスペースで直接作成したプロジェクトとして始まりましたが、時間の経過とともに進化し、現在ではいくつかのエグゼクティブレビューで使用されています。

取締役会による優先事項の変更に伴い、新たな要件が発生しました。財務部門は、単一の集計売上メトリクスに代わって、確定（committed）および未確定（uncommitted）の売上金額を追跡する必要があり、ダッシュボードは次回の予測レビューまでに新しい定義を反映する必要があります。

これらの値は、報酬やボーナスの計算など、実際のビジネス上の意思決定に直接影響するため、このダッシュボードを初めて規律あるデプロイパスに乗せてみましょう。

ステップ 1：ダッシュボードをDeclarative Automation Bundlesに追加する

プロセスを開始する前に、ITグループと協力して、いくつかの基本的なコードツール（空の「Declarative Automation Bundles」を含むGitリポジトリ、およびバンドルを自動的にデプロイするためのCI/CDスクリプト）をセットアップします。

Gitリポジトリはファイルの変更を追跡するためのツールです。開始するには、ダッシュボード構成の変更を追跡できるように、リポジトリをDatabricksに接続する必要があります。DatabricksワークスペースからGitフォルダを作成し、セットアップダイアログにリポジトリのURLを貼り付けます。これにより、Databricksがリポジトリを認識し、次のステップでダッシュボードを追加できるようになります。

Declarative Automation Bundlesは、コードファイル（この場合はダッシュボード）をグループ化する方法です。リポジトリにすでにバンドルが含まれている場合は、自動的に検出され、矢印アイコンを使用して開くことができます。そうでない場合は、Gitフォルダの作成（Create）メニューから新しいバンドルを作成できます。

アセットバンドルエディタ内では、現在空のバンドルに新規コンポーネントと既存コンポーネントの両方を追加できます。ダッシュボードを含めるには、追加（Add）メニューを開き、既存のダッシュボードを追加（Add existing dashboard）を選択します。追加が完了すると、ダッシュボードがバンドルの一部としてsrcフォルダ内に表示されます。

この時点から、ダッシュボードはデプロイ可能なアセットとして管理されるため、同じダッシュボードを開発、テスト、本番のワークスペース間で簡単に移行できます。

最後に、ダッシュボードをリポジトリにコミットします。これにより、ダッシュボードの現在の状態がベースラインとしてキャプチャされ、将来の変更を追跡およびレビューするための明確な開始点が確立されます。

ダッシュボードがリポジトリに追加され、いくつかの自動生成された構成ファイル（末尾が.yml）も一緒に追加されたことがわかります。これらのファイルは、ダッシュボードをさまざまな環境にどのようにデプロイするかを記述したもので、編集する必要はありません。

コミットメッセージ（commit message）フィールドに何を行ったかを説明する短いメモを追加し、コミットしてプッシュ（Commit & Push）を選択します。これにより、ダッシュボードのチェックポイント（後で戻ることができる既知の正常な状態）が作成され、将来の変更を比較、レビューし、安全にデプロイできるようになります。

ステップ 2：ダッシュボードを更新する

既存のダッシュボードがコミットされたので、すでに本番環境にあるものに影響を与えることなく変更を開始でき、Gitが具体的な変更内容を追跡します。

一般的なプラクティスは、Gitブランチ（他のブランチに影響を与えずに作業できるダッシュボードのバージョン）を作成することです。これは「ブランチの作成（Create Branch）」ボタンから行うことができ、自分の名前、機能名、または変更に関連するチケット番号などのわかりやすい名前を付けます。これは、アップデート用のプライベートバージョンと考えてください。ダッシュボードを自由に編集、テスト、調整し、変更内容をレビューしてデプロイする準備が整うタイミングを個別に決定できます。

これでダッシュボードを変更できるようになりました！今回は、左上の売上数値を変更して、未確定と確定の両方の売上カウンターを追加します（見やすさを考慮して、太字の青と赤を選択しています）。

作成エクスペリエンスは何も変わらないことに気づくでしょう。ダッシュボードのUIエディタを使用して、通常通りこれらの変更を行ってください。

開発環境でダッシュボードが正しく表示されたら、変更を本番環境に反映する準備は完了です。以前と同様に、上部にある同じ Git ボタンを使用して、短いコミットメッセージとともに関係する変更をチェックインします。

ステップ 3：変更のレビュー

次に、このワークフローのもう1つの重要なメリットが明らかになります。それは、変更が本番環境に反映される前に、他のメンバーが変更をレビューしてフィードバックを提供できる場所があることです。2人目のレビューを必要とすることは一般的なベストプラクティスですが、それと同じくらい重要なのは、レポートに影響を与える前に、アイデアを議論し、仮定を検証し、変更を洗練させるための、リスクの低いスペースが作成されることです。

レビューを開始するには、Gitプロバイダーで Pull Request (PR) を作成します。これは基本的にダッシュボード更新用のレビューページです。レビュアーは変更内容を正確に確認し、対応が必要なコメントを残し、すべて問題がなければ更新を承認できます。

レビュー中、本番環境のダッシュボードは変更されません。フィードバックに対応し、変更が承認されて初めて、プロセスが先に進みます。

ダッシュボードの変更はバックグラウンドで設定ファイルとして保存および追跡されますが、実際に何が変更されたかを理解するのは難しいことがよくあります。このため、多くのチームは、PRがオープンされるたびにレビュー用のダッシュボードの一時的なテストバージョンを自動的にデプロイする、ちょっとした自動化を使用しています。これにより、レビュアーは本番環境に反映される前に、提案されたメトリクス、計算、レイアウトをコンテキスト内で確認でき、データロジックやUIの問題をキャッチできます。開発者やレビュアーがテストダッシュボードのスクリーンショットやリンクをPRに直接含めることで、フィードバックも迅速になり、確実性が高まります。

レビュアーはコメントを追加して承認することができ、これらは記録されるため、後で変更内容を理解しやすくなります。

ステップ 4：バンドルを使用してダッシュボードを本番環境にデプロイする

変更が承認されたら、ダッシュボードを本番環境にデプロイする準備は完了です。

ダッシュボードは、開発環境とは異なる本番環境の設定が必要になることがよくあります。たとえば、開発用のデータセットではなく本番用のカタログやスキーマを指すようにしたり、別の SQL ウェアハウスを使用したりする場合などです。

嬉しいことに、これらの違いは想定内であり、デプロイプロセスの一部として処理されます。

ダッシュボードをアセットバンドルに追加すると、Databricks はこれらの環境固有の設定をキャプチャする小さな .yml 設定ファイルを生成しました。このファイルを使用すると、ダッシュボードのロジック自体を変更することなく、環境ごとに値をオーバーライドできます。今回のケースでは、カタログ名に ${variable} 値を使用することで、ダッシュボードが本番環境で使用するカタログがテスト環境とは異なるように指定しています。

最後に、databricks.yml ファイルがすべてのバンドルリソースを結び付け、各環境で使用されるカタログを定義するため、開発、テスト、本番のワークスペース全体で一貫したデプロイを簡単に管理できます。

プルリクエストが承認され、メインブランチにマージされると、デプロイ自動化が実行され、databricks.yml で定義された環境固有の値が使用されます。同じダッシュボードコードがワークスペース間で再利用され、カタログ、スキーマ、ウェアハウスなどの設定はターゲット環境に基づいて適用されます。これにより、ワークスペースごとに個別のダッシュボードのコピーを維持する必要がなくなり、どこでも変更が予測どおりに動作するようになります。

ほとんどの Git プロバイダーでは、プルリクエスト上でデプロイの自動化を確認できるため、デプロイを監視し、完了したとき（または問題が発生したとき）を確認できます。問題が発生した場合、既存の本番ダッシュボードに影響を与えることなくデプロイが停止し、トラブルシューティングを行うことができます。デプロイが正常に完了すると、更新されたダッシュボードが本番環境で稼働し、関係者が利用できるようになります。

おまけ 1：履歴を確認したい場合は？

ダッシュボードの更新が本番環境に反映された後、何が、いつ、なぜ変更されたかの履歴を把握する必要がある場合があります。このフローのメリットの1つは、変更が追跡可能になることです。ワークスペースで直接行われる単発の編集ではなく、保存されたバージョンのシーケンスとして表示されます。

各エントリは、作成者とタイムスタンプとともに、ダッシュボードの更新を表します。任意のエントリを開いて変更を確認し、必要に応じてロールバックできます。

おまけ 2：変更を元に戻す必要がある場合は？

慎重にレビューやテストを行っても、ダッシュボードの読み込みに失敗したり、メトリクスの定義が間違っていることが判明したりするなど、問題が発生することがあります。

ダッシュボードはこのワークフローを通じて管理されているため、更新のデプロイに使用したのと同じ制御されたプロセスを使用して、正常であることが確認されているバージョンにロールバックできます。

まず、リポジトリでダッシュボードの変更履歴を開き、元に戻したい更新を特定します。そこから、変更内容を確認して、正しい変更を元に戻そうとしていることを確認してから進めることができます。

変更の詳細から、リンクをたどってレビューページに戻ります。更新をロールバックするには、Revert を選択します。これにより、その特定の更新のみを元に戻す新しい「取り消し」変更が作成され、ダッシュボードの残りの履歴はそのまま維持しながら、ダッシュボードを以前のロジックに復元します。

変更がメインブランチにマージされると、ダッシュボードを本番環境にデプロイしたのと同じ自動化機能によってロールバックが行われます。これにより、既存のコントロールをバイパスすることなく、システム停止や影響の大きい計算上の問題に数分で対応できます。

ボーナス 3：データソースが更新された場合はどうなるか？

ほとんどのダッシュボードはデータソースと密接にリンクしているため、ダッシュボードの更新はパイプラインの更新と密接に関連していることがよくあります。幸いなことに、Asset Bundlesは、関連するコンポーネントを1つのパッケージにまとめるように設計されています。

これにより、上流のデータモデルの変更に不意を突かれることがなくなり、ビジュアライゼーションの変更にデータモデルの更新が必要な場合でも、両方の変更を1回のデプロイでリリースできます。

まとめ

AI/BIダッシュボードを本番グレードのデータ製品として扱うことは、信頼性の高いビジネス意思決定とリスク軽減のために不可欠です。このワークフローでは、いくつかの追加ステップを実行するだけで、日常のダッシュボード作成方法を変えることなく、ダッシュボードの変更を可視化し、レビュー可能にし、元に戻せるようにします。

GitとDeclarative Automation Bundlesを使用してダッシュボードを管理することで、チームは「変更、レビュー、テスト、デプロイ」という、定期的で予測可能な更新ワークフローを確立できます。このプロセスは、更新が小さな視覚的調整であっても、ビジネスロジックに対する重要な変更であっても同様に適用されます。

適切なデプロイ規律を導入することで、ダッシュボードの変更はリスクの要因ではなくなり、取締役会のような重要な局面でもビジネスとともに進化する、信頼できるインサイトの源泉となります。

詳細情報 + 次のステップ

このワークフローで使用されている要素についてさらに詳しく知りたい場合は、以下のリソースを参考にしてください。

• 「ブランチ戦略」（AWS | Azure | GCP）
  ベストプラクティスに従ったブランチモデルを使用して、変更をマージおよびデプロイする方法を説明します。
• Declarative Automation Bundles（AWS | Azure | GCP）
  Asset Bundlesを使用して、環境間で一貫してDatabricksリソースをパッケージ化およびデプロイする方法を説明します。
• Databricksでの自動デプロイのためのCI/CD（AWS | Azure | GCP）
  スターター用のGitHub Actionsスクリプト（AWS | Azure | GCP）を使用して、CI/CDを実装する方法を説明します。
• DatabricksワークスペースUIからのAsset Bundlesの使用（AWS | Azure | GCP）
  ワークスペースから直接バンドルを作成、編集、デプロイする方法を説明します。
• DatabricksでのGit連携フォルダー（AWS | Azure | GCP）
  DatabricksにおけるGit統合の仕組みと、バージョン管理が日常の分析ワークフローにどのように適合するかを説明します。

Databricks AI/BIで次のステップに進む準備ができている場合は、以下のいずれかのオプションを選択できます。

• 無料版と試用版：無料版または試用版に登録して、実際に体験してください。
• ドキュメント：詳細については、ドキュメントを参照してください。
• Webページ：詳細については、Webページをご覧ください。
• デモ：デモビデオの視聴、プロダクトツアーへの参加、ハンズオンチュートリアルを通じて、AI/BIの実際の動作を確認してください。
• トレーニング：Databricks Academyによる無料の製品トレーニングを開始しましょう。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事