Treasure Data - Support Engineering Team blog

トレジャーデータのサポートエンジニアリングチームのブログです。

Treasure Workflowのsession timeとスケジューリングについて

こんにちは。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に行われてます。

f:id:td-kohki:20200614104718p:plain
ワークフロー作成とスケジュールを設定

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

f:id:td-kohki:20200614110301p:plain

session_timeの考え方

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

f:id:td-kohki:20200614110812p:plain

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が実行予定として表示された、という事ですね。

では、どうすれば同日に実行が出来るのか。

どうして同じ日にスケジュールできないかの仕組みが分かったものの、結局その日に再度スケジュールするのにはどのようにすれば良いのでしょうか?

1つはスケジュールをcronに置き換えてしまう方法で達成が出来ます。 これはcronを利用した場合はsession_timeとして実際の実行時刻が使用されるため、既存のsession_timeと重複せずに当日の予定を組めるためです。

f:id:td-kohki:20200614113405p:plain

もしくは他のスケジューリング(minutes_intervalやhourly)でsession_timeが実行しないように調整することも可能です。

他には、一時的にスケジュール実行をoffにして手動で実行する、という手もあります。

まとめ

いかがでしたでしょうか? session_timeがスケジュール実行の制御のために上手く使用されている事が分かりましたね。 細かく説明しきれなかった部分も多々あるかと思いますが、もし使ってみて疑問がありましたらTreasure Dataのサポートまでお気軽にお問い合わせください!