当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

当社では業務系システムを開発する機会が多く、定期的に実行する処理が多くあります。慣れ親しんだCron式でジョブの実行定義ができる Cloud Scheduler は利用機会も多く、優先的に仕様を調査することにしました。

G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のフルマネージドの cron ジョブスケジューラである Cloud Scheduler を解説します。

Cloud Scheduler とは
ユースケース
cron ジョブのターゲット
cron ジョブスケジュールの設定
ターゲットの認証
ジョブ失敗時の対処
- ジョブ失敗の通知
- 失敗したジョブの再実行
使用上の注意点
- サマータイムによる影響
- べき等性を考慮する
料金

Cloud Scheduler とは

Cloud Scheduler はサーバーレスなジョブスケジューラサービスです。
Google Cloud コンソールや gcloud コマンドを使用してジョブのスケジュールとターゲットを指定するだけで cron ジョブを簡単に作成することができ、一括で管理することができます。
ジョブ実行のためのインフラストラクチャのプロビジョニングや運用管理をする必要はありません。

ユースケース

Cloud Scheduler は、cron ジョブを使用して Cloud Functions や Cloud Run などのコンピューティングプロダクトや、Pub/Sub のようなメッセージングのプロダクトにリクエストを送信することができます。

一般的なユースケースとしては、cron ジョブを起点とした Cloud Functions によるバッチ処理 があります。
たとえば、Cloud Functions から他の Google Cloud プロダクトの API を使用することで、以下のような処理を定期実行タスクとして実装することができます。

Cloud SQL や Cloud Storage にあるデータを読み込んで変換し、BigQuery に書き込む ( ETL 処理 )
Compute Engine インスタンスのマシンイメージを取得する ( バックアップ )
Web サイトから収集したデータを Cloud Storage や BigQuery に出力する ( Web スクレイピング )

すべてのコンポーネントにサーバーレスのプロダクトを使用するため、インフラストラクチャの運用管理をすることなく定期バッチ処理を実装することができます。

cron ジョブのターゲット

cron ジョブのターゲットには、以下のタイプが指定できます。

一般公開されている HTTP/S エンドポイント
Cloud Pub/Sub トピック
Google App Engine の HTTP/S アプリケーション

Cloud Pub/Sub トピックを cron ジョブのターゲットとして利用することで、Pub/Sub サブスクライバーとなる Cloud Functions や Cloud Run にリクエストを送信することができ、定期実行タスクの柔軟性がかなり高まります。

なお、Cloud Functions や Cloud Run では HTTPS エンドポイントが提供されるため、Pub/Sub を間に挟むことなく使用することもできます。
しかし、Pub/Sub を使用することで、cron ジョブと実際の処理部分を疎結合にすることができ、同じ cron ジョブから複数のサブスクライバーにリクエストを送信するなど、処理の柔軟性が向上します。

また、Pub/Sub ターゲットを使用する場合のみ、ジョブを VPC Service Controls の境界に含めることができます。

cron ジョブスケジュールの設定

Cloud Scheduler では、cron ジョブを unix-cron 形式で指定します。

日時フィールド

cron 形式は、空白で区切られた 5 つの日時フィールドで構成されます。

フィールド	有効な値
分	0~59
時間	0~23
日	1~31
月	1~12 ( JAN ~ DEC でも可 )
曜日	0~6 ( SUN ~ SAT でも可。また日曜日は 7 でも可 )

特殊文字

日時フィールドには先述した有効な値のほか、特殊文字を使用することができます。

特殊文字	説明
* (アスタリスク)	日時フィールドに設定できるすべての値を表します。たとえば、曜日フィールドに `*` を設定した場合、`日曜日~土曜日までの全ての曜日` を意味します。
- (ハイフン)	範囲を指定することができます。たとえば、月フィールドに `4-8` を設定した場合、`4 月から 8 月までの毎月 ( 8 月も含む )` を意味します。
/{数値}	範囲の指定とともに使用することで、指定した範囲内での実行間隔 (ステップ) を指定することができます。たとえば、時間フィールドに `0-23/2` を設定した場合、ジョブは `0,2,4,6,8,10,12,14,16,18,20,22 時` に実行されます。
, (カンマ)	値のリストを使用することができます。たとえば、日フィールドに `7,17,27` を設定した場合、`7 日、17 日、27 日` にジョブが実行されます。

設定例

設定したいスケジュール	値
毎週月曜日の午前 9 時	`0 9 * * 1`
毎平日の午前 0 時 30 分	`30 0 * * 1-5`
毎月 5, 15, 25 日の午後 6 時	`0 18 5,15,25, * *`
毎年 8 月 5 日の午後 9 時	`0 21 5 8 *`

ターゲットの認証

ターゲットに HTTP/S エンドポイントを使用し、認証が必要なターゲットを Cloud Scheduler から呼び出す場合、ジョブに対してサービスアカウントを設定します。
たとえば、認証が必要な Cloud Functions の HTTPS エンドポイントをターゲットとする場合、Cloud Functions 起動元 ロール ( roles/cloudfunctions.invoker ) を紐付けたサービスアカウントをジョブに設定します。

Pub/Sub をターゲットとして使用する場合、Cloud Scheduler ジョブに対しては追加の権限を設定する必要はありません。
Pub/Sub 経由で Cloud Functions や Cloud Run などを使用する場合は、サブスクリプションに対してサービスアカウントを設定します。

ジョブ失敗時の対処

ジョブ失敗の通知

Cloud Scheduler ジョブの実行は、デフォルトで Cloud Logging に記録されます。
Cloud Logging に記録されたジョブのエラーログをログベースの指標として Cloud Monitoring で取得し、アラートポリシー を設定することで、メールや Slack による通知や、Pub/Sub を使用した後続処理などを行うことができます。

失敗したジョブの再実行

Cloud Scheduler のジョブ実行が失敗した場合、デフォルトでは再実行されません。 ジョブの再実行が必要な場合、最大実行回数 (1~5) や最大実行時間 (1s ~ 実質無制限)、再実行間隔などを指定し、指数バックオフ による再実行を設定することができます (参考)。

また、ジョブはコンソールや gcloud コマンドから手動で実行することも可能です。

使用上の注意点

サマータイムによる影響

ジョブの実行時間を設定する際、基準となるタイムゾーンを選択することができますが、一部のタイムゾーンにおいて、夏時間の影響でジョブが予期せず実行される、もしくはジョブが実行されない可能性があります。

したがって、基本的には夏時間のないタイムゾーンを選択します。
ドキュメントでは UTC を選択することが推奨されていますが、JST もサマータイムの影響を受けないため、いずれかのタイムゾーンを選択するとよいでしょう。

べき等性を考慮する

Cloud Scheduler では最低 1 回の実行 ( At-least Once ) を保証しており、そのため同じ cron ジョブが複数回実行されることが稀にあります。
したがって、cron ジョブを起点とする処理全体を べき等 に実装する必要があります。

ジョブの作成時に ヘッダー を設定し、ジョブ名や cron で設定した実行時刻をターゲットへのリクエストに含めることで、リクエストの重複削除に役立てることができます (参考)。

料金

Cloud Scheduler の料金は、ジョブの実行回数ではなく、ジョブの個数で決定されます。
1 日あたり $0.003 課金され、たとえばジョブを作成して 10 日後に削除した場合は $0.03 の課金となります。
無料枠はプロジェクト単位ではなく、請求先アカウント単位で集計される点に注意しましょう。