こんにちは。Arm Treasure Dataでサポートエンジニアとして働いています、佐藤です。今回は少しイメージとして掴みにくい、Treasure workflowのsession timeのコンセプトに関して少し説明して行こうかと思います。

そもそもTeasure Workflowとは？

Treasure workflowは、OSSのdigdagというツールをTreasure Dataがホストしたものになります。

https://www.digdag.io/

digdagはいわゆるワークフローツールと呼ばれるもので、外部ツールからのデータの取り込み、SQLによるデータ抽出、テーブルの作成、外部ツールへの書き出しなどを一連のフローとして設定出来るツールです。具体的な違いの詳細などの説明は今回の記事ではしませんが、基本的にはdigdagに利用方法とほぼ同じだと考えてもらえるとわかりやすいかと思います。

参考例その1

さて、それでは実際に参考例を取り上げていきたいと思います。まずはスケジュールを組んだワークフローを作成します。日時実行で11時に実行されるように設定しました。なお、このワークフローの作成は6/14に行われてます。

無事に11時に実行が終わりましたが、こちらのワークフローはまだ検証中なのでもう一度11:05に実行したいとします。スケジュールの設定を変更して保存をしたところ、Next Attemptが翌日(6/15)で表示されていることが分かります。これはどうしてでしょうか？

session_timeの考え方

上記の参考例で遭遇した事象に関して仕組みを理解するのに、session_timeという考え方が重要になってきます。先ほどの例でいうと、すでに実行された6/14分のsession_timeをコンソールから確認するとToday12:00 am( = 2020年06月14日 00:00)になっています。実際に実行された時間は6/14の11時なのにも関わらず、異なる時間が表示されているのは何故でしょう？

digdagのScheduled execution and session_timeの項目に詳しい記述があります。

http://docs.digdag.io/concepts.html#scheduled-execution-and-session-time

A session has a timestamp called session_time. This time means “for which time this workflow runs”. For example, if a workflow is scheduled every day, the time is usually 00:00:00 of a day such as 2017-01-01 00:00:00. Actual execution time may not be the same time.

まず、session_timeは実際の実行時間とは異なる場合があります。これは上記の日時実行の例でいうと、スケジュール上の重複実行を避けるためにsession_timeとして2020年06月14日 00:00(その日の00時)の時間が使用されるからです。この仕組みを用いて、その日に既にsessionが実行済みかどうかをチェックする事している訳ですね。

ちなみに、参考までに各スケジューリングの際にどのようにsession timeが採択されるかをまとめたものがこちらの表です。

スケジュール	最初のsession time	最初に予定される実際の実行時間
hourly>: “32:32”	2019-02-24 14:00:00 +0900	2019-02-24 14:32:32 +0900
daily>: “10:32:32”	2019-02-25 00:00:00 +0900	2019-02-25 10:32:32 +0900
weekly>: “Tue,10:32:32”	2019-02-26 00:00:00 +0900	2019-02-26 10:32:32 +0900
monthly>: “2,10:32:32”	2019-03-02 00:00:00 +0900	2019-03-02 10:32:32 +0900

今回の例もこれに当てはまり2020年06月14日 00:00のsession_timeが既に発行されているため、6/14分のスケジュール実行が完了しているとみなされます。これによってdailyのスケジュールを11:05に変更したとしても、当日分は既に終わっているとみなされるため翌日の6/15が実行予定として表示された、という事ですね。