Hur minskar jag kostnaden för mitt Flink-kluster utan att förstöra checkpointing?

Notan för ett Flink-kluster rör sig inte som notan för ett batch-jobb — du betalar för TaskManagers som är igång oavsett om det finns backpressure eller inte, och för checkpoints som utlöses av en timer oavsett hur mycket som faktiskt ändrats. Det gör det mindre till en fråga om ett enda dåligt jobb och mer till en fråga om inställningar som ingen sett över sedan lanseringen.

1. Checkpoint-intervallet är kostnadsspaken ingen ser över

Varje checkpoint innebär en fullständig genomgång av state-backend'en — för RocksDB betyder det disk-I/O plus, i en molndriftsättning, en batch med PUT-anrop till vilken objektlagring som helst som håller state.checkpoints.dir. Ett intervall som satts konservativt kort under den initiala utrullningen, när ingen ville riskera att förlora framsteg i ett oprövat jobb, fortsätter att kosta lika mycket i evighet även efter att jobbet varit stabilt i flera månader. Att bredda execution.checkpointing.interval sänker den återkommande kostnaden direkt — avvägningen är mer data att bearbeta om vid nästa fel, så det är värt att dimensionera efter den faktiska återställningstidstoleransen, inte bara efter hur kort siffran säkert kan vara.

2. Parallellism dimensionerad för den värsta dagen, betald varje dag

Antalet TaskManager-slots sätts oftast en gång, utifrån en uppskattning av toppbelastning, och rörs sedan aldrig — så trafik i stabilt tillstånd betalar för kapacitet den inte använder större delen av tiden. Reactive Mode eller en plattformsnivå-autoskalare kan täppa till det glappet automatiskt; även utan det räcker det att jämföra backpressure per subtask med tilldelade slots för att fånga det uppenbara fallet: parallellism dimensionerad för en topp som inträffar två gånger om året, men som körs till fullt pris varje dag däremellan.

3. Obegränsad tillväxt av state blåser upp checkpoints i det tysta

Keyed state som aldrig fått en TTL tillämpad växer så länge jobbet körs, och varje checkpoint måste serialisera allt av det — så checkpointens varaktighet och lagringsavtryck kryper uppåt över månader utan att en enda deploy orsakar det. Inget går sönder, vilket är precis varför det går obemärkt förbi. Att tillämpa en TTL som matchar hur mycket state affärslogiken faktiskt behöver är oftast en större vinst än det ser ut som, just för att det åtgärdar en långsam drift, inte ett enda felaktigt värde.

4. Inte varje TaskManager är en säker spot-kandidat

Om en TaskManager kan köras på spot-kapacitet beror på vad den håller: ett jobb som återställs rent från sin senaste checkpoint, med tillräcklig återställningstidstolerans för att absorbera en preemption, är en bra kandidat — samma återställningstidsbudget som i spak nummer ett. Ett jobb med stort keyed state som tar minuter att bygga upp från grunden är en sämre kandidat, eftersom en preemption där kostar mer än beräkningen den sparade.