Du betreibst sechs Instanzen eines Service und brauchst einen nächtlichen Job, der genau einmal läuft. Wie regelst du das?

Verlass dich nicht darauf, dass jede Instanz einen lokalen Cron fährt. Nutz ein Leader Lock, etwa eine Zeile oder einen Key, der mit Lease und Time-to-live erworben wird, sodass nur der Halter den Job fährt, oder gib das Scheduling an einen Cron auf Plattformebene ab, der einen Job für einen Worker einreiht. So oder so: mach den Job idempotent und beobachtbar, denn ein Lease kann mitten im Lauf ablaufen und eine Überlappung verursachen.

Die naive Variante läuft sechsmal, und die Variante mit einer eigens bestimmten Instanz hört an dem Tag auf zu funktionieren, an dem diese Instanz ungesund ist. Ich nutze also entweder ein Lock oder hole das Scheduling ganz aus der Anwendung raus. Beim Lock versucht jede Instanz zur geplanten Zeit ein Lease zu erwerben, typischerweise ein Insert oder ein bedingtes Update auf einer Jobs-Tabelle mit Ablaufzeit, und nur der Gewinner läuft und erneuert das Lease während der Arbeit. Der Haken ist, dass ein Lease bei einem langen Lauf ablaufen kann, dann startet eine zweite Instanz, der Job muss also trotzdem zweimal sicher laufen können. Ab einer gewissen Größe bevorzuge ich den zweiten Ansatz: Scheduling auf Plattformebene, das eine einzelne Message einreiht, und ganz normale Worker konsumieren sie. Das liefert Retries, Sichtbarkeit und Historie gratis, und der Anwendungscode wird zum Handler. Wie auch immer, ich erfasse Start- und Endzeiten und alarmiere, wenn ein Job nicht in seinem erwarteten Fenster fertig wurde, denn ein Job, der leise aufhört zu laufen, ist der Ausfall, den Leute Wochen später bemerken.