スケジューラとの対話 — cronはなぜ生き残るのか
要点
- cronは1970年代から続く時刻起動の仕組みで、いまも多くのシステムの定期処理を担っている。
- 単純さが最大の長所だが、単一マシン前提という性質は分散環境では弱点になる。
- Googleの『SRE』は、信頼性の高い分散cronを作る難しさを具体的に論じている。
- 新しい道具が次々登場しても、cronが消えないのは「枯れていること」自体が価値だからである。
——いまだにcronって使われてるんですね。もっと新しいものに置き換わってると思っていました。
むしろ、いたるところで動いています。ログの掃除、証明書の更新確認、定期的なバックアップ。表に出ないが止まると困る処理の多くを、いまも素朴なcronが時刻どおりに起動している。1970年代にUnixで生まれた仕組みが、半世紀近く現役なんです。
単純であること
——なぜそんなに長持ちするんですか。
単純だからです。「毎日3時に、このコマンドを実行する」。それだけを、設定ファイルの一行で書ける。学ぶことが少なく、壊れる箇所も少ない。Paul Vixieが整理したいわゆるVixie cronの系譜は、この素朴さを保ったまま広く普及しました。新しい道具は機能が多い分、覚えることも、壊れ方も増える。cronの強みは、機能の少なさそのものにあります。
——でも、単純すぎて困ることはないんですか。
あります。cronは基本的に、一台のマシンの上で時刻を見て起動するだけ。そのマシンが落ちていれば、その時刻の処理は単に走らない。誰も走らせ直してくれない。手元で完結する潔さが、そのまま「面倒を見てくれなさ」になります。
分散になると難しくなる
——サーバーが何台もあると、どうなるんでしょう。
そこが厄介なところです。同じcron設定を複数のマシンに置くと、同じ処理が三重に走るかもしれない。かといって一台だけに置けば、その一台が落ちたとき処理が消える。Googleの『Site Reliability Engineering』には、まさにこの「信頼性の高い分散cron」をどう作るかを論じた章があります。要は、どのマシンが担当かを調整し、一度だけ確実に走らせる仕組みが要る。単純だったはずのcronが、分散になった途端、合意や冪等性といった重い問題を抱え込む。
——そんなに難しいなら、専用のワークフローエンジンに任せた方がいいのでは。
規模が大きく、処理が複雑に絡むなら、その判断はもっともです。ワークフローエンジンの比較で見たように、依存関係や再試行を丁寧に扱いたいなら専用の道具が向く。ただ、世の中の定期処理の多くは、そこまで複雑じゃない。一行で書けて確実に動く道具を、わざわざ重い仕組みに置き換える理由がない場面も多いんです。
枯れていることの価値
——つまり、適材適所だと。
そうです。そして、ここで大事なのが「枯れている」という評価です。新しい技術は魅力的に見えますが、長く運用する現場では、十分にこなれて挙動が読めることのほうが価値を持つ。cronは何十年も使われ、落とし穴も対処法も知れ渡っている。裏を返せば、未知の振る舞いがほとんどない。これは新しい道具にはまだ持てない財産です。
——枯れていることが、強みになるんですね。
派手さはありません。でも、背景で淡々と時刻を待ち、決まった時間に決まった処理を起こす——その地味な信頼性こそ、基盤に求められるものです。cronが生き残っているのは、置き換えられなかったからではない。置き換える必要が、多くの場面でなかったからです。新しさは更新され続けますが、枯れた信頼は時間をかけてしか積み上がらない。だから古い道具が、いちばん新しい問題の足元を支え続けている。
出典
- Google『Site Reliability Engineering』（分散cronの信頼性に関する章）
- Vixie cron に関する公開ドキュメント・Unix系システムの標準的な仕様