Kiedy Watchtower potrafi przeciążyć serwer?

•

Przypadkiem mocno obciążyłem jeden z serwerów Mikrusa, a zrobiłem to przez... Watchtower dla Dockera. Użyteczna aplikacja, ale przy odpowiedniej skali może nieźle namieszać. Na czym polegała wpadka? 🧵 ↓

Aby postawić aplikację N8N na VPS-ach od Mikrusa, można użyć jednego polecenia: n8n_install Możesz powiedzieć "ale n8n to tylko jeden kontener!". Tak, ale nasze skrypty ogarniają jeszcze backupy, auto-aktualizację, dodawanie własnej domeny, certyfikat SSL itp.

Skupmy się na tym temacie autoupdate. Tutaj nie wymyśliliśmy koła na nowo i korzystamy z watchtowera, a konkretniej mówiąc z jego forka, bo oryginalny soft nie jest już rozwijany. Aplikacja siedzi na serwerze użytkownika i co kilka dni sprawdza, czy da się podnieść wersję N8N.

Jeśli wydana została nowa wersja, to ściągany jest aktualny obraz, kontener jest na chwilę zatrzymywany i obraz podmienia się na nowy. Użytkownicy to uwielbiają, bo nie muszą myśleć o aktualizacji (zwłaszcza gdy pojawia się jakaś podatność), bo soft sam się aktualizuje.

Początkowo nasz instalator miał podane na sztywno co ile powinien sprawdzać aktualizacje - dokładnie co 259200 sekund, czyli co 3 dni. To w zupełności wystarczy, aby być na bieżąco i jednocześnie nie restartować usług bez potrzeby.

To ustawienie było teoretycznie bezpieczne, bo każdy użytkownik instaluje swoje N8N innego dnia i o innej godzinie, więc te 72h liczą się dla każdego osobno. No i tutaj dochodzimy do sedna problemu, bo tak to powinno działać w świecie idealnym, ale jednak tak to nie działa.

Raz na jakiś czas kilkadziesiąt VPS-ów na jednym dedyku aktualizuje się w tym samym momencie z dokładnością do 10-15 sekund. Jakim cudem?! Reboot - mówi to coś panu, panie czytelniku? ;)

W przypadku jednego z serwerów dedykowanych padł pojedynczy dysk. Niewielki to problem, bo serwery oczywiście mają RAID-a, ale mają też dyski SSD NVMe, które niestety hotswapa nie obsługują, więc serwer trzeba wyłączyć, wsadzić nowy dysk i włączyć ponownie.

Jest to szybka akcja wykonywana nocą i downtime jest niewielki, ale tutaj następuje wpadka, bo wszystkie kontenery Watchtowera synchronizują swoje liczniki. Za 3 dni odpalą się razem, inicjując update u wszystkich jednocześnie.

Tutaj aż się prosi o zastosowanie typowego 'RANDOM' przy opóźnieniu, ale zależało nam, aby aktualizacje rozrzucone były na przestrzeni 24h, a nie w obrębie np. 1-2h. Do tego, jak to bywa z liczbami losowymi, nietrudno o kolizję.

Opóźnienie jest wyliczane matematycznie na podstawie numeru ID kontenera. Niezależnie jak często restartowany będzie VPS (użytkownicy sami często robią reboot), to opóźnienie pozostaje bez zmian, a gdy następuje reboot całego dedyka, wszystkie updatery rozkładają się równomiernie.

Istnieje szansa, że nigdy nie trafisz na taki problem, ale jeśli projektujesz system, który obsługuje tysiące użytkowników, a pewna akcja wykonuje się co pewien czas, to zadbaj na poziomie architektury rozwiązania o to, aby przypadkiem te akcje nie nachodziły na siebie ;)