Digdag v0.9.40 で理解する Digdag UI

これは Arm Treasure Data Advent Calendar 2019 25日目の記事です。

※ こちらの記事に書かれている情報は v0.9.40 をベースにしており、将来的に変更される可能性があります。

はじめに

みなさんこんにちは。
先日 (2019-12-11) に、digdag v0.9.40がリリースされました。
リリースノートはこちら: Release 0.9.40 — Digdag 0.9.40 documentation

久しぶりのリリースになった関係でたくさんの変更が含まれる形になりましたが、実はUIも大きく変わっております。

今回ではそんなデザインの変更に触れつつ、今までDigdag UIを利用したことがないなというユーザーの皆さんにも「こんな感じなのか」とイメージをつけていただけるように、ページの一覧や機能を少し詳しく書いてみたいと思います。慣れればそういうことか！となるものが多いのですが、そうなるまでに少し時間がかかる気がしています。

ちなみに今まで使われているユーザーの皆さんからすると、既に知っている情報だというところはあると思いますが、機能を振り返りつつ、サラッと眺めていただければと思います :)

UI関連で何を変更したのか

具体的には Bootstrapのメジャーバージョンアップ (3 -> 4) を行いました。デザインに微調整を入れたところがあります。新たにページの追加などはしていませんが、見た目の印象でいうと割と変わったのかなと思っています。

ページ一覧

現在は下記の通りページが存在しています。
（分類は便宜上、個人的感覚で分けたものになります）

一覧ページ

• Workflows (=Topページ)
• Projects

詳細ページ

• Project
• Workflow
• Session
• Attempt

編集ページ

• Project作成
• Workflow編集

Digdag UIはSPAになっており、一覧ページ/詳細ページのそれぞれ見た目としては似たような作りになっていますが、出てくる情報としては細かいところで違いがあります。

事前準備

それぞれの役割をみていく前に事前準備をしていきます。

筆者の環境情報

• macOS Mojave
• Java version: 1.8.0_202
• Digdag version: v0.9.40

Digdagサーバを起動

下記のコマンドでdigdag serverをインメモリモード (-m) で起動します。

digdag server -m --task-log task-log

--task-log オプションではタスクログのアウトプット先を指定することができます。コマンドを実行したディレクトリを起点とし、オプションとして渡したディレクトリ名 (今回の場合task-log) がない場合は新規で作成され、そこにタスクログのファイルが追加されていきます。
UI上ではタスクログが見る機能が存在しますが、このオプションを指定しないと何も出てきませんので注意しましょう。
ちなみにオプションを指定することで、S3などにもタスクログを保存することができますが、これに関しては割愛します。

プロジェクト作成 & 登録

今回は、予めプロジェクトを登録しておきたいと思います。

### 作業用ディレクトリへ移動
$ cd path/to/work

### プロジェクトを新規作成
$ digdag init hello-world

### プロジェクトを登録
$ digdag push hello-world

## sampleプロジェクトも同様に作成 & 登録
$ digdag init sample
$ digdag push sample

初期状態ではプロジェクト名と同様のワークフローが1つ作成されますが、例として紹介するにはさみしい感じになってしまうので、私の方でいくつかのワークフローを追加 + 実行しておいた状態になっています。

それでは、それぞれのページに関して詳しくみていきましょう。

ページ紹介

一覧ページ

Workflows

UIにアクセスしたときのトップページになります。

わかること

• ワークフローの一覧(Name/Revision/Project)¹
• 全セッション実行履歴確認²

できること

• 新規プロジェクト作成 (New project)

ワークフロー名のリンクでWorkflowページへ移動できます。
ワークフローが存在しているプロジェクトもここでわかります。

Projects

わかること

• プロジェクトの一覧
• 全セッション実行履歴確認²

できること

• 特にありません

現在登録されているプロジェクトの一覧を見る時に使います。
プロジェクト名のリンクでProjectページへ移動できます。

詳細ページ

Project

わかること

• プロジェクト詳細 (ID/Name/Revision/Created/Updated)
• プロジェクト内にあるワークフローの一覧¹
• 対象プロジェクトのセッション実行履歴確認

できること

• 特にありません

またプロジェクト内に存在するワークフローのセッション一覧がわかります。
一覧ページと違うのは、プロジェクト内のみのセッションの実行履歴がわかるという点です。
プロジェクトが多い場合、絞り込んでそのプロジェクト内を俯瞰してみるには便利だと思います。

Workflow

わかること

• ワークフロー詳細 (ID/Name/Project/Revision)
• スケジュール (※ スケジュール登録されている場合のみ表示)
• ワークフローの定義
• 対象ワークフローのセッション実行履歴確認
• ファイル(※ ワークフローで利用されているShellやSQLなどある場合のみ表示)

できること

• ワークフローを実行
• ワークフローを編集
• スケジュールの一時停止/再開 (※ スケジュール登録されている場合のみ)

スケジュールありのWorkflow:

ファイルありのWorkflow:

対象ワークフローのセッションの一覧はこちらで確認できるため、アクセスする機会がかなり多いのではないかと思います。

注意すべき点がいくつかありますので、ご紹介しておきます。

1: WorkflowのRUNに関しての制限事項

• 実行時にユーザーが任意で実行するパラメータを指定することはできません
• 実行時のSessionTimeの指定もできません -> 実行した時刻になります

これは、SessionTimeに依存する処理をしている場合には注意が必要です。単体で実行しても大丈夫なものは気にする必要はありません。現状は、CLIを利用することで任意のパラメータ指定や、SessionTime (daily, hourly, etc.) を指定することができます。

2: Digdag UIからのPAUSE/RESUME

UIからもPAUSE/RESUME機能が利用できますが、この仕様には注意が必要です。
下記に詳しくまとまっていたので、ぜひそちら参照いただければと思います。

参考: Digdag UIのPAUSE/RESUME機能 & Digdag CLIでのenable/disable機能の注意点 - Qiita

3: ワークフローのRevisionに注目

もうひとつ注意しなければいけないのは、このワークフローの詳細画面はクリックした対象のRevisonを対象としたワークフローの詳細が表示されるということです。

例えば、下記のIDが12/13のSessionのタスクを例に見てみると… (Workflowのリンクをクリックしたと仮定)

表示されているワークフローがきちんと対象Revisionになっていて、上記の例では Definition が failed / failed2 と異なっているのがわかります。

ワークフローの一覧ページからは基本的に最新のReivisonの情報でリンクされているため、違和感を感じることはありません。先程の例にあるようなSessionsの実行履歴からリンクからたどってきた際には、Revisionが異なっていた場合でもきちんと対象Revisionのワークフローが表示されるようになっているため一瞬アレッとなるケースがあるもしれません。また、過去のRevisionが表示されている状態でRUNを押すとそのReivisonを利用してワークフローが実行がされます。これは親切な設計だと思いますが、理解していない状態だと混乱しやすいポイントかなとも思っています

WorklfowページにはRevisionの情報が表示されるので確認すれば問題ありません。
運用する視点からは、ProjectをPushする際にはわかりやすいRevision名をつけておくことをおすすめします。

わかりやすいRevisionの例: ${ブランチ名}-${GitコミットのHash}

$ echo $(git symbolic-ref --short HEAD)-$(git rev-parse --short HEAD)
master-41cc6076b9

Session

わかること

(Attemptの情報は最新のものに基づくもの)

• 対象のSession情報
• Task のタイムライン³
• Task の詳細情報⁴
• 各Task のログ
• 対象Sessionで実行されたAttemptsの一覧

できること

• ワークフローのRETRY
• ワークフローのRETRY FAILED（ワークフローが途中で失敗した場合のみ）

成功したとき:

失敗したとき:

Workflowのリトライが必要になった時にはこのページから行うことができます。

Sessionページでは最新のAttemptに基づいた情報が表示されます。それより過去のAttemptの情報に関してはAttemptページで確認する必要があります。

注意点としては、前述のWorkflow詳細のページでは表示された対象のReivisonでのRUNができましたが、このページからRETRYをした場合は 常に最新のReivisonを利用してのRETRY が行われます。
これは何らかの原因でワークフローが失敗して修正済みが終わりそれがpushされたら、このボタンを押すだけで最新のRevisionで実行されるので楽という側面はあります。一方で、それが不都合なケースもあるでしょう。その場合はCLIを利用してRETRYする必要があります。
これは、オプションで過去のRevisionでも実行できるようにしてあげても良いのかなと思っています。

Attempt

わかること

• 対象のAttempt情報
• Task のタイムライン³
• Task の詳細情報⁴
• 各Task のログ

できること

• Attemptをkill (実行中のみ)

成功:

失敗:

実行中:

Sessionページでは、最新のAttemptの情報を元にした情報が出ていましたが、Attemptページでは過去のAttemptに関するログ/タスク等の詳細情報を確認することができます。

現状、実行中のワークフローのkillはこのページからしかできませんので注意が必要です。

なお、killに関しての仕様はこちらの記事にまとまっているのでよければ参照してくてみてください。
参考: digdag kill が実行されてから Attempt が停止するまでの挙動

編集ページ

Project作成

わかること

• 特にありません

できること

• 新規にプロジェクトを作成できる

ちなみにサブディレクトリにファイルを作りたい時は↑のサンプルのようにするとちゃんと作ってくれます。
本番環境等で積極的に使うシーンはないと思いますが、ローカルからサッと作ったりするのには重宝します。

Workflow編集

Workflowページからこの編集ページを利用することができます。

わかること

• 現在のリビジョンのプロジェクト内に含まれるファイル等

できること

• 対象ワークフローが含まれるプロジェクトの編集

注意点としては、便宜上ワークフローと呼んでいると思うのですが実際にはプロジェクトの編集になっています。特定のワークフローのみの編集は対応していないため対象のワークフローが存在するプロジェクトを編集することになります。

そしてこの編集ページでは、プロジェクト内で含まれるファイルやサブディレクトリにあるワークフローのファイルなども見れるので簡易的にみたいという時は便利かもしれないです。

運用している側からすると、実際にはここでは編集されたくないケースも多いはずです。僕自身はあまり使ったことがありません。
ここで編集して保存した場合には、新しいrevisionのワークフローが登録されます。本当に急いで何かを直したい時などには便利かもしれないですが差分が生まれることになるので、Gitなどで管理されている場合はなるべく早く元と合わせるようにした方が良いと思います。
現状では、ワークフローの定義などがUIからダウンロードできないのでAPI経由で対象のプロジェクトをダウンロードして、ローカルでdiff等を利用して、差分を確認し反映する作業が必要になってしまいます。

DigdagのUI機能をザッと眺めてみました。以上になります。
v0.9.39をお使いの皆さまも、ぜひ最新版へとアップデートして使ってみてはいかがでしょうか?

(UI周りで) 改善した方が良いと感じているところ

せっかくなので、改善できそうなところした方が良さそうなところを、個人的な視点で書いてみることにします。

タスクのログが長くなった際にページの読み込みに時間がかかることがある

対象ページ: Attempt/Session

これはそもそものタスクのログ/タスクの量に依存するものです。
もしもリトライ等が原因でログが長くなっている場合は、Retry Intervalをもう少し伸ばしてみる、もしくはexponentialなリトライをした方が良いと思います。
根本的な案としては、Lazy Loadingなどを導入しても良いかもしれないと考えています。

タスクのログが長くなった際にAttemptsへ辿り着くのに時間がかかる

対象ページ: Session

これはログの下にAttemptsが表示されるのに起因していますが、タスクログが長かったりするとAttemptsへたどり着くのに時間がかかってしまうことがあります。
Cmd + 下矢印キーで一番下まで下がることはできますが、上記の問題に起因して不便を感じるときがあります。
解決策としては、SessionページでのAttempts一覧を上の方に持ってきても良いのかなと思っています。

100件より前のattempts/sessionsがたどれない

現時点でのワークアラウンドとして、max_attempts_page_size/api.max_sessions_page_sizeのサイズを増やす（100より大きくにする）という方法があります。
これは一日一回しか実行する必要のないセッションではあまり問題にならないと思いますが、高頻度で実行するワークフローの場合は不便を感じることがあります。根本的な改善としては今も進んでいるところだと思いますが、ページネーションで解決されていく問題という認識です。
ちなみにattemptsに関しては増えることはないですし、100個以上前のもの見れなくてもそ不便を感じたことはそこまで多くないです。

Reactコンポーネントの見通し問題

目に見えない部分の細かい話ではありますが、、今現在はReactコンポーネントなどがひとつにまとまっています。最初の構成としてはシンプルでやりやすく良いと思っていましたが、今後のことを考えると分けたほうが良いかなと思っています。その際の構成などは慎重に考える必要はありそうです。（実は途中までトライしている状態なんですけど、いま止まってしまっています）

その他、issueで指摘されている件

UI周りに関してissueもいくつかご意見をいただいているものがあり、この記事内で書いたものも既にissueとしてあがっているものがあります。私も同意見で改善した方が良いと思うものが多くあります。

現状の不便に感じるところはあるとはいえ、DigdagのCLIなどを組み合わせると解決できる問題が多いなという印象があります。ただしそれで満足するのではなく、必要な機能は追加をしていったり機能の差を埋めていくところからスタートしても良いのかなと考えています。

最後に

OSSのユーザーにとって、本体の機能的な面ももちろんですが、UI/UXというのはダイレクトに関わるところなので少しずつでも良いので改善を重ねていき、より便利にしていけると良いのかなと感じています。
現段階では、OSSとプロダクト開発のリソース配分の難しさを感じているところがあるのが正直なところではありますが、コツコツとできるところから関わっていければな、と思っています。