【ITニュース解説】Running Lightdash on Snowpark Container Services

このニュース記事は、データを分析し可視化することでビジネスの意思決定を支援するツールであるLightdashを、Snowflakeの最新サービスであるSnowpark Container Services（SPCS）上で動作させる方法を詳しく解説している。Lightdashには、サービスとして提供されるSaaS版と、ソースコードが公開されており自分で構築・運用が可能なオープンソースソフトウェア（OSS）版があるが、筆者は後者のOSS版をSnowflakeの環境で動かすことを選択した。これは、Lightdashの機能を活用する目的と同時に、Snowflakeが提供するマネージドPostgreSQLサービスであるSnowflake Postgresの利用方法を習得する機会でもあったようだ。

LightdashをSPCS上で実行するシステムは、いくつかの主要な要素から構成される。まず、「Compute Pool」は、Lightdashのアプリケーションコンテナが実際に動作するための仮想マシン群である。その上で稼働する「Lightdash Service」は、Lightdashのウェブユーザーインターフェースや、データ更新を管理するスケジューラといった機能を一つのコンテナ内で提供し、外部に公開されたエンドポイント（URL）を通じてアクセス可能となる。Lightdashが設定情報や内部データを保存するデータベースとしては「Snowflake Postgres」が使われ、これはSnowflakeプラットフォーム上で利用できるPostgreSQLデータベースのインスタンスである。「External Access Integration（EAI）」は、Lightdashのコンテナが、Snowflake Postgresや、データモデルのソースコードが格納されているAzure DevOpsといった外部サービスに安全に接続するための仕組みだ。Lightdashアプリケーションのプログラム本体である「Dockerイメージ」は、「Image Repository」というSnowflake内部の専用ストレージに保存される。また、「Azure DevOps」は、データ変換ツールであるdbtプロジェクトのソースコードを管理する場所として機能し、Lightdashはここからデータモデルの定義を取得する。

このシステムを構築するためには、いくつかの前提条件を満たす必要がある。具体的には、Snowflakeの契約エディションがEnterprise以上であること、Lightdashの運用に必要な権限を持つSnowflakeロールが準備されていること、ローカル環境でDockerコマンドラインツールが利用できること、Snowflake Postgres機能がアカウントで有効になっていること、そしてdbtプロジェクトを格納するAzure DevOpsリポジトリと、それにアクセスするための認証トークンが準備されていることが求められる。

実際の構築は、Snowflakeの環境設定から始まる。まず、Lightdashの運用を管理するための専用ロール「LIGHTDASH_ADMIN_ROLE」を作成し、データベース、ウェアハウス、コンピュートプール、外部連携、Postgresインスタンスの作成・管理など、Lightdashの稼働に必要な権限をこのロールに付与する。次に、Lightdashが使用するデータベースとスキーマ、そしてクエリ実行のための計算資源であるウェアハウスを準備する。Lightdashのコンテナが動作する基盤となるコンピュートプール、Dockerイメージを保存するImage Repository、そしてサービス設定ファイルなどを一時的に保管するステージもこの段階で設定される。

続いて、Lightdashのメタデータデータベースとして利用するSnowflake Postgresのインスタンスを作成する。これはSQLコマンドで直接PostgresデータベースをプロビジョニングできるSnowflakeの機能の一つだ。Postgresインスタンスへのネットワークアクセスを制御するためのルールとポリシーを設定した後、指定された計算資源とストレージサイズでPostgresインスタンスを起動する。インスタンスが作成されたら、Snowflakeの管理画面から管理者ユーザーのパスワードを再生成し、psqlなどのデータベースクライアントを用いてPostgresに接続し、Lightdashが使用するための専用データベースを作成する。

Lightdashの安全な運用のためには、機密情報の適切な管理が不可欠だ。Postgresデータベースへの接続パスワードや、Lightdashが内部データを暗号化する際に使用するキーなどの機密情報を、「Snowflake Secrets」という機能を利用して安全に保存する。これにより、これらの機密情報を設定ファイルに直接書き込むことなく、Lightdashアプリケーションからセキュアに参照できるようになる。

Lightdashコンテナが外部のサービスにアクセスできるように、「External Access Integration（EAI）」を設定する。SPCS上のコンテナはデフォルトで外部へのネットワーク通信が制限されているため、LightdashがSnowflake Postgresデータベースに接続するためのEAIと、dbtプロジェクトのソースコードが置かれたAzure DevOpsにアクセスするためのEAIの二つを作成する。これらのEAIには、許可する通信先（ホスト名とポート番号）や、認証に利用するシークレットを指定するネットワークルールが関連付けられる。

Lightdashアプリケーションのプログラム本体であるDockerイメージをSnowflakeの環境に登録する。Lightdashが公式に提供しているDockerイメージをローカル環境にダウンロードし、それをSnowflake内のImage Repositoryにプッシュする。これにより、LightdashアプリケーションがSnowflakeプラットフォーム内で利用可能となる。

SPCS上にLightdashサービスをデプロイするための設定ファイルとして、「サービス仕様YAML」を作成する。このYAMLファイルには、Lightdashコンテナが使用するDockerイメージのパス、Postgresデータベースへの接続情報（ホスト、ポート、ユーザー名）、Lightdashの動作に関する環境変数（ポート番号、ログレベルなど）、そしてSnowflake Secretsで管理されているパスワードや暗号化キーをコンテナの環境変数として渡す方法が記述される。特に、Snowflake Postgresが自己署名証明書を利用しているため、SSL接続時に証明書の検証をスキップする設定が必要となる。このYAMLファイルを、先に作成したステージにアップロードする。

全ての準備が整ったら、いよいよLightdashサービスをSPCS上に作成する。先に用意したコンピュートプール、アップロードしたサービス仕様YAMLファイル、そして設定済みのEAIを指定して、Lightdashサービスを起動する。サービスの起動にはしばらく時間がかかるが、そのステータスが「Ready」になると、サービスが正常に稼働していることを示す。サービスの公開エンドポイントURLを取得することで、ウェブブラウザからLightdashにアクセスできるようになる。

Lightdashが分析するデータモデルは、dbtプロジェクトで定義される。ここでは、Lightdashの公式サンプルプロジェクトである「jaffle_shop」を使って設定を進める。まず、Snowflake側に分析結果を格納するためのスキーマを作成する。次に、jaffle_shopのdbtプロジェクトのソースコードをAzure DevOpsのリポジトリに複製し、Snowflakeのdbtプロジェクト機能を利用して、サンプルデータをSnowflakeにロードし、dbtモデルを実行してデータを変換する。これにより、Lightdashが分析可能な形式のデータがSnowflake上に用意される。

最終ステップとして、公開されたLightdashのエンドポイントURLにウェブブラウザでアクセスし、ウェブUIでの初期設定を行う。初回アクセス時には、管理者アカウントの作成が求められる。その後、Lightdashの設定画面でSnowflakeの接続情報（ここではキーペア認証が選択された）と、先に準備したdbtプロジェクトのリポジトリ情報を設定する。これらの全てのステップを完了することで、Lightdashは正常に動作し始め、dbtプロジェクトで定義されたデータモデルに基づいて、チャートやグラフを作成してデータを視覚的に分析できるようになる。

この一連の構築を通じて、Snowpark Container ServicesとSnowflake Postgresを組み合わせることで、LightdashのようなカスタムアプリケーションをSnowflakeのプラットフォーム上で効率的かつセキュアにホスティングできることが実証された。このアプローチは、Lightdashの活用にとどまらず、企業が利用する様々なアプリケーションをSnowflakeの堅牢なデータプラットフォーム環境に統合するための有効な手段となる可能性を秘めている。