Stairlight の運用方法を考える - 2022年、夏

データリネージツール Stairlight の運用方法について、こうするとよいのでは？と検討したことを書きます。

運用にあたっての課題

いま見えている範囲では２つあります。

• 設定ファイルを更新するタイミング
• リネージ抽出結果だけではその鮮度がわからない

設定ファイルを更新するタイミング

クエリの変更にあわせて Stairlight の設定ファイルを更新していく仕様になっているので、 変更がなされたことに気づき、設定ファイルを継続的にメンテナンスしていける仕組みがあると嬉しいと考えました。

クエリを検出する対象は複数存在します。大別すると、下記の3種類です。

• ソースコード(クエリファイル含む)
• データベースレコード
• クエリ実行ログ(定期実行するものを想定)

リネージ抽出結果だけではその鮮度がわからない

手元にあるリネージ抽出結果が最新のデータパイプラインを反映しているかは、抽出結果だけ見てもわからないという課題です。 いつ、何をトリガーに抽出結果を更新したのかをトレースする仕組みがあると安心です。

提案手法

上記の課題2点を解決すべく、このような方法を考えてみました。

• 設定ファイルとリネージ抽出結果を履歴管理する
• 設定ファイルの更新作業をできるだけ自動化する

設定ファイルとリネージ抽出結果を履歴管理する

履歴管理することによって、下記のようなメリットが得られます。

• クエリの変更とリネージの変更を紐付けて管理
• 設定ファイルを履歴管理することで、差分を確認
• コミット履歴から、特定時点でのリネージを再現

設定ファイルの更新作業をできるだけ自動化する

クエリに変更が入るたびに人が設定ファイルを更新するのは大変ですし、おそらく更新作業そのものが忘れられてしまいます。 変更が入ったクエリを検出して、設定ファイルを変更する Pull Request を自動生成して通知すると便利なのでは？と考えました。

具体例

Git と GitHub Actions, Slack を使います。主な役割は以下のとおりです。

• Git: 履歴管理
• GitHub Actions: 設定ファイルを更新する Pull Request 作成
• Slack: Pull Request 作成通知

準備作業

リネージ情報を管理する専用のリポジトリを作成して、下記の作業を行います。

1. Pull Request を作成したときに Slack へ通知するように設定する
2. Stairlight 設定ファイルを作成して、push する
3. 下記の処理を行う GitHub Actions job をつくる(トリガーは定期実行)
   1. (異なるリポジトリにソースコードがある場合) 対象のソース一式を git clone する
   2. stairlight map コマンドを実行する
   3. 未定義設定が見つかった場合は、設定ファイルを更新する Pull Request を作成する(重複しないような工夫をしてもよいかも)
4. 下記の処理を行う GitHub Actions job をつくる(トリガーは Pull Request 作成)
   1. (異なるリポジトリにソースコードがある場合) 対象のソース一式を git clone する
   2. stairlight map コマンドを実行する
   3. 未定義設定が見つかった場合は、Pull Request にコメントする

更新作業

自動生成された Pull Request をマージして、最新の状態を保っていけばよいという算段です。

1. 作成された Pull Request で、未定義設定がなくなるまでファイルを更新する
2. main branch にマージする

具体例を挙げるにあたって考えたこと

具体例の紹介は以上ですが、例示にあたって考えたことをメモします。

• どうやって設定ファイルを管理するか
• どうやってリネージ履歴を管理するか
• 何をトリガーにしてリネージ履歴を更新するか

どうやって設定ファイルを管理するか

設定はファイルで管理する仕様なので、Git がよいと考えました。

どうやってリネージ履歴を管理するか

アウトプットである JSON ファイルはそこまで大きいサイズにならないはず、という前提で同じく Git を選びました。 オブジェクトストレージにも出力できるようにしていますが、これは最新の結果を配置するときに使うのがよいと考えます。

何をトリガーにしてリネージ履歴を更新するか

設定ファイルとリネージ履歴を Git で管理する場合、CI/CD に寄せたワークフローにするとよいと考えました。 GitHub Actions であれば、定期実行や Git 操作に起因する特定のイベントをトリガーにできます。

トリガー方法について検出対象ごとに考えてみましたが、下記のとおり、おおむね定期実行でよいのでは、という結論になりました。

ソースコード(クエリファイル含む)

ソースコードが更新されるタイミングは、main branch への merge と考えます。 それをトリガーにリネージ結果を更新すると、クエリの変更とリネージの変更を紐付けることができます。更新頻度が高くない場合は、定期実行でもよいと思います。

データベースレコード

特定のテーブルに対してレコードが挿入されたときに都度更新が理想ですが、そこまで厳密にする必要はなく更新にかかる負荷が高いので、定期実行が適当と考えます。

クエリ実行ログ

これは Google Cloud Logging, AWS CloudWatch Logs あたりを何らかの DWH にロードすることを想定しています。 書き込まれたタイミングで都度更新が理想ですが、データベースレコードと同じ理由で定期実行が適当と考えます。