Problemem nie był jeden worker. Problemem był brak jednego modelu własności procesu.
W systemie działało kilka niezależnych mechanizmów wykonawczych. Część workerów posiadała własny cykl pracy, inne zadania uruchamiał cron, watchdog reagował na stan usług, supervisor utrzymywał procesy, a orchestrator uruchamiał kolejne elementy systemu.
Każdy mechanizm był uzasadniony osobno. Dopiero widok całego środowiska pokazał, że podobna funkcja mogła zostać uruchomiona więcej niż jeden raz. Gdy poprzednia instancja nie kończyła pracy przed kolejnym wywołaniem, powstawała następna; procesy potomne dodatkowo zwiększały liczbę PID-ów.
Sam PID nie wystarcza
Numer procesu potwierdza istnienie wpisu w tablicy procesów, ale nie opisuje roli, zdrowia ani własności lifecycle. Przed decyzją o restarcie trzeba potwierdzić tożsamość procesu, jego stan, drzewo potomków oraz mechanizm, który ma prawo nim zarządzać.
Decyzja architektoniczna: 1 rola = 1 właściciel procesu = 1 sposób uruchamiania
Przed dołożeniem nowego workera sprawdzamy, czy funkcja już istnieje. Jeśli istnieje, aktualizujemy bieżący mechanizm albo zastępujemy go nowym. Nie uruchamiamy nowej wersji obok starej na podstawie założenia, że poprzednia prawdopodobnie już nie działa.
Kolejka albo jawna równoległość
Jeśli dwa zadania nie powinny wykonywać się równolegle, trafiają do wspólnej kolejki. Jeżeli równoległość jest potrzebna, staje się elementem architektury: każda domena otrzymuje własnego workera, odpowiedzialność i jasno określony budżet procesów.
Worker zamiast crona dla częstych cykli
Dla często wykonywanych zadań lepszym modelem może być jeden długotrwały worker z wewnętrznym cyklem: wykonanie → oczekiwanie → kolejne wykonanie → healthcheck. Cron pozostaje dla zadań faktycznie okresowych: backupu, housekeeping, raportu dziennego lub audytu.
Watchdog diagnozuje przed restartem
Brak oczekiwanego sygnału nie musi oznaczać, że proces nie istnieje. Kontrola przed restartem obejmuje proces główny, dzieci, healthcheck, właściciela usługi i możliwość równoległego nadzoru przez inny mechanizm.
Rezultat: mniej procesów było skutkiem, przewidywalność była celem
Po uporządkowaniu workerów, mechanizmów startowych i nadzoru liczba aktywnych procesów spadła z około 100 do 48. Jednocześnie ograniczyliśmy warunki, które wcześniej pozwalały środowisku eskalować do setek PID-ów. Sama redukcja nie jest uniwersalnym benchmarkiem — dotyczy konkretnego środowiska i incydentu.
Blast radius na hostingu współdzielonym
Gdy kilka projektów korzysta ze wspólnego budżetu zasobów, wzrost liczby procesów lub pamięci w jednej aplikacji może ograniczyć inne usługi. Dlatego monitoring powinien obejmować całe konto: liczbę PID-ów użytkownika, RAM, drzewa procesów, aktywne harmonogramy i mechanizmy nadzoru.
Sześć reguł projektu
- Najpierw sprawdź, czy rola już istnieje.
- Jeden worker — jeden właściciel lifecycle.
- Równoległość projektuj jawnie.
- Cron nie jest supervisorem.
- Watchdog diagnozuje przed restartem.
- Monitoruj środowisko, nie tylko pojedynczą usługę.
FAQ
Czy sam plik PID wystarcza do ochrony przed duplikacją workera?
Nie. PID potwierdza jedynie istnienie procesu o danym numerze. Nadzór powinien potwierdzić rolę procesu, właściciela lifecycle, stan healthcheck oraz brak równoległej instancji tej samej roli.
Czy cron jest dobrym sposobem na uruchamianie stale działającego workera?
Zwykle nie. Długotrwały worker powinien mieć jeden mechanizm uruchamiania i nadzoru, a cron pozostać narzędziem do rzeczywiście okresowych zadań.
Dlaczego watchdog może zwiększyć liczbę procesów?
Jeżeli reaguje na brak sygnału bez sprawdzenia procesu i jego potomków, może uruchomić kolejną instancję tej samej roli.
Czy zawsze trzeba ograniczać system do jednej instancji workera?
Nie. Równoległość jest poprawna, jeśli jest jawnie zaprojektowana: liczba instancji, odpowiedzialność, kolejki i budżet zasobów są kontrolowane.