Cloud Schedulerへの期待とマネージドジョブ実行基盤の今後

注意

この記事は2019年4月26日に更新されたもので、内容が古い可能性がありますのでご注意ください。

葉桜が陽気を連れてくる初夏、いかがお過ごしでしょうか。クラウドエースSREチームの亀梨です。アルルとウィンは自引き出来ました。(RISING RAMPAGE BOX)

元オンプレの運用屋としては、「すっごいcron」を名乗っているCloud Schedulerが気になります。

昨年11月に出た、「フルマネージドなcron」です。まだBetaですが。

そのお題目はというと。

Cloud Scheduler は、エンタープライズクラスのフルマネージド cron ジョブスケジューラです。バッチ処理、ビッグデータジョブ、クラウドインフラストラクチャオペレーションなど、実質的にほぼすべてのジョブをスケジューリングできます。
Cloud Scheduler | Google Cloud

「実質的にほぼすべてのジョブをスケジューリングできます。」🤔ほぼ。ほぼとは。

実行はどこで、誰がどうやってするのか？
結果の判定と再試行は、どうなっているのか？
ジョブの実行状況と結果をどうモニターするのか？

既にApp Engine SEをお使いの方々には今更かと思いますが、App Engine cronをまだ使っていない人の視点で考察してみました。

Cloud Schedulerのご紹介です。

順に見ていきましょう。

従来のジョブ管理の課題
Cloud Schedulerは、何をしてくれるのか？
どのくらいマネージドなのか？
Cloud Schedulerの制約
- 動作させるプロジェクトにApp Engineアプリの存在が必要
- 処理は羃等(べきとう)性の担保が必要
おわりに

従来のジョブ管理の課題

コンピューター(というかUNIX)の黎明期から、cronには以下のような問題がありました。(VM・IaaSは装置・ラック・DCなりに読み替えてください)

cron「ジョブ実行するで (するだけ)」
systemd「cronをちゃんと1分に1回動作させるために起動させとくで(するだけ)」
VM「カーネルの指示にそれなりに忠実に動くで」
IaaS「人間さんがちゃんと面倒見てくれな困りますわ」

つまり、

「ジョブ自体は機械が実行してくれるが、ジョブの前提になる全てのお世話を人間がしなければならない」
「ジョブを実行しない間、ジョブを実行するために用意したリソースが、まるっきり無駄になる」

ということです。

しかも、

「異常が発生していた場合、気付くために必要な処理を、各ジョブの中全てに作り込まなければならない」
「スケジュールを司るマシンに異常が起きると、ジョブが実行されない」

のです。

具体的に例えば、「一日に一回、PD(Persistent Disks)のsnapshotをひとつ取るだけのAPIをcallするcronジョブ」というものがあったとします。(※scheduled snapshotが実装されたので、今後はこれをする必要はなくなりましたが ^^;)

凡そ、これを動かすために、「cronが動くためだけのVM」をひとつ追加で立て、それを運用するという雑用が発生すると思います。

使うツールがcronでなく、Jenkinsでも、Apache Airflowでも、JP1でも、Systemwalkerでも結局は同じことです。

集中管理サーバを操作するAPI、独自のお作法を覚えて
管理サーバを対象サイトごとに構築して
管理サーバが壊れたら直して
管理サーバのお作法にツールの方を合わせて
管理サーバの提供する操作ツールを使ってバッチを実行する

ことに代わりはありません。

ただ「cronが動いてくれるだけのマネージドサービス」、ずっと欲しかったと思います。私は欲しかったです。

Cloud Schedulerは、何をしてくれるのか？

と、ここまで語っておいて、実は、Cloud SchedulerはUNIX cron相当をそのまんま動かしてくれるサービスではありません。

旧来のUNIX cronというミクロ視点から離れて、マクロ視点で他サービスのAPIを呼び出す機能を、フルマネージドで提供します。

これは、cron互換の実行周期指定ができ、フルマネージドで、

Pub/Sub
App Engine HTTP
汎用HTTP/S

の3種類のターゲットに対して、リクエストを発行させるサービスなのです。

なので、これらのAPIを持たないジョブは、実行できません。

(Cloud Functions、App Engine等でwrapperを書けばできますが)

「APIのトリガーを引く部分だけ」をマネージドにしてくれるサービスだ、といえるでしょう。

分離できる部分は極力分離してmicroservice化する、GCPらしいサービスです。

どのくらいマネージドなのか？

ログはちゃんと出るのか？

もう、shellscriptとloggerコマンドを駆使して賽の河原の石積みをする必要はありません。(ホントか？)

というか、「ジョブのトリガー」と「ジョブの実行」を分離することで管理をシンプルにしています。

schedulerのログは、stackdriver loggingに出力されます。

schedulerの呼び出すジョブのログは、そのジョブをホストするサービスのログとして出力されるわけです。

サービス間の疎結合の恩恵ですね。

失敗判定と再試行について

gcloud beta scheduler jobs createコマンドの --max-backoff オプション、 --max-retry-attempts オプション等を指定することで、App Engine cron.yamlと同様に再試行(リトライ)の挙動を制御できます。
失敗判定については、App Engine cron側の資料によると、HTTPについては

2XX番台以外のステータスコードが返る
timeout

いずれかの状況の場合、リトライ動作となるようです。(※Cloud Schedulerについては明言しているドキュメントが見付かりませんでした)

Cloud Console(Web)からの設定については、現時点ではできないように見えます。

異常の検知については、呼び出される側の、例えばGKE、App Engine等のログをstackdriver loggingのログベース指標であらかじめ定義しておき、Stackdriver MonitoringのAlerting機能でslack通知、Email通知といった手段で実装できるでしょう。

実行状況のモニター

Cloud Consoleから、直近のジョブの成否の確認、ならびにstackdriver loggingの「そのジョブに関連するエントリーを抽出した画面」へ遷移することができます。

おいくら？

プロジェクトに関係なく、課金アカウントごとに、合計で月に3ジョブまで無料。

それ以降は $0.10 USD/ジョブずつ加算されます。(2019/04時点)

Cloud Schedulerの制約

動作させるプロジェクトにApp Engineアプリの存在が必要

App Engine cronの仕組みを流用しているのか、「App Engineアプリがプロジェクト内に含まれている」ことを要求します。

動作するコードが無い、空の「アプリ設定」だけでよいのですが、以下をよく読んでください。

Cloud Scheduler を使用するには、サポートされているリージョンのいずれかに配置されている App Engine アプリがプロジェクトに含まれている必要があります。プロジェクトに App Engine アプリが含まれていない場合は、App Engine アプリを作成する必要があります。
概要

App Engine固有の制約として、 「一度App Engineアプリケーションを作成すると、そのプロジェクトでアプリを配置するリージョンは変更できなくなる」 点があるため、プロジェクト自体の運用設計時に考慮する必要があります。