葉桜が陽気を連れてくる初夏、いかがお過ごしでしょうか。クラウドエース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のご紹介です。
順に見ていきましょう。
目次
従来のジョブ管理の課題
コンピューター(というか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アプリケーションを作成すると、そのプロジェクトでアプリを配置するリージョンは変更できなくなる」 点があるため、プロジェクト自体の運用設計時に考慮する必要があります。
処理は羃等(べきとう)性の担保が必要
「at-least-one」(少なくとも1回の実行)を保証するため、一度の処理で複数回発動する可能性があります。
日次バッチなら24時間ごとに実行済フラグをクリア、等すればよさそうですが、短いスパンでの実行は要検討です。
おわりに
これまでのインフラ運用、つまりサーバー以上のレイヤーの運用に於ては、「個々のサーバー(インスタンス)」に状態を持たせ、その状態を保持するように「サーバー単位で管理する」という考え方でした。
今後、コンテナ運用、コンテナオーケストレーション(Kubernetes等)運用、そしてハイブリッドクラウドと進化していくアプリケーション基盤としてのインフラ運用の最適化。
これらの取り組みを進めるにつれ、これまでのミクロな視点を極力排し、サービス同士をAPIで疎に結合し、マクロな粒度で運用していく、という思想が見えてきます。
Cloud Schedulerは、単純なUNIX cronの置換にはなりませんが、Cloud Schedulerを前提としたバッチ実行・運用を考えることで、木よりも森を見る設計のヒントになるのではないでしょうか。
クラウドエースでは、コンテナオーケストレーションやインフラの抽象化、IaC、immutable infrastructure、CI/CDを前提としたSIを一緒に進めていく仲間を募集しております。
↓ ↓ ↓ ↓ ↓ ↓ ご応募はこちらからどうぞ！ ↓ ↓ ↓ ↓ ↓ ↓
👉 https://www.cloud-ace.jp/recruit/ 👈
↑ ↑ ↑ ↑ ↑ ↑
