Kubernetes z kampaniami Sendy/Mautic

Uruchomienie Sendy lub Mautic na Kubernetes pozwala skalować moc wysyłkową kampanii wraz z rosnącym wolumenem.

Kubernetes jako warstwa uruchomieniowa dla Sendy i Mautic

Kubernetes może służyć do uruchamiania aplikacji Sendy oraz Mautic w postaci zarządzanych obciążeń aplikacyjnych. W typowym układzie komponent odpowiedzialny za obsługę żądań HTTP działa jako Deployment, a dostęp do niego zapewnia obiekt Service. Ruch z zewnątrz może być kierowany przez Ingress lub inny kontroler wejściowy, który przekazuje żądania do właściwego serwisu aplikacyjnego. Taki podział pozwala oddzielić adres dostępny dla użytkownika od konkretnych instancji procesu obsługujących stronę WWW.

Samo zwiększenie liczby replik nie rozwiązuje jednak wszystkich problemów związanych z kampaniami. Sendy i Mautic korzystają z trwałych danych przechowywanych w bazie oraz z ustawień aplikacji, dlatego konfiguracja musi być wspólna dla instancji albo dostępna z trwałego magazynu. Każda replika powinna mieć spójne parametry połączenia z bazą, adres aplikacji, ustawienia wysyłki i informacje potrzebne do obsługi zadań cyklicznych. W przeciwnym razie poszczególne procesy mogą działać według różnych konfiguracji, a wynik kampanii będzie trudny do przewidzenia.

Różnice między obsługą HTTP a wysyłką kampanii

W Sendy panel administracyjny i endpointy aplikacji są obsługiwane przez PHP oraz serwer WWW, natomiast wysyłka wiadomości jest związana z kolejką kampanii i komunikacją z Amazon Simple Email Service. Kubernetes może zwiększyć liczbę replik obsługujących panel, ale nie oznacza to automatycznie proporcjonalnego przyspieszenia wysyłki. Ograniczeniem może być przepustowość Amazon SES, liczba zadań wykonywanych przez proces wysyłkowy, czas odpowiedzi bazy danych albo konfiguracja samej aplikacji.

Mautic również rozdziela obsługę interfejsu WWW od zadań wykonywanych cyklicznie. Do prawidłowej pracy wykorzystuje zadania cron, między innymi do przetwarzania kampanii, aktualizacji segmentów, obsługi punktów oraz wysyłania wiadomości. W Kubernetes zadania te można uruchamiać przez obiekty CronJob, ale trzeba kontrolować równoległość i czas trwania kolejnych uruchomień. Jeżeli kilka replik wykona to samo zadanie bez mechanizmu blokady lub odpowiedniego harmonogramu, może dojść do wielokrotnego przetworzenia tego samego etapu kampanii.

Skalowanie, kolejki i trwałość danych

Automatyczne skalowanie poziome, czyli HPA, podejmuje decyzje na podstawie obserwowanych metryk, takich jak wykorzystanie procesora lub pamięci. Dla Sendy i Mautic takie wskaźniki nie zawsze dobrze opisują rzeczywiste zaległości w wysyłce. Proces może zużywać niewiele procesora, mimo że kolejka zawiera wiele wiadomości oczekujących na przetworzenie. Przydatniejsze mogą być dodatkowe metryki aplikacyjne, liczba zadań w kolejce, czas oczekiwania albo liczba błędów transportu, o ile środowisko potrafi je wiarygodnie udostępnić.

Baza danych powinna być traktowana jako osobny element architektury. Deployment aplikacji nie zapewnia automatycznie wysokiej dostępności ani poprawnych kopii danych bazy. Należy uwzględnić trwały wolumen, procedurę odtwarzania, zgodność wersji silnika bazy z wymaganiami aplikacji oraz limit połączeń. Zbyt duża liczba replik PHP może otworzyć więcej połączeń, niż baza jest w stanie obsłużyć. Objawem będzie wtedy wzrost czasu odpowiedzi, błędy zapisu kampanii, opóźnienia w panelu albo niepełne przetwarzanie zadań.

Ważne są także probe’y Kubernetes. Readiness probe powinna dopuszczać ruch dopiero wtedy, gdy instancja może obsługiwać żądania, natomiast liveness probe powinna wykrywać zawieszenie procesu, a nie chwilową niedostępność bazy lub zewnętrznego transportu. Zbyt agresywne ustawienia mogą powodować ciągłe restarty podczas większej kampanii. Zbyt łagodne ustawienia pozostawią w ruchu instancje, które zwracają błędy lub nie przetwarzają zadań.

Diagnostyka wdrożenia i skutków kampanii

Analizę problemu należy rozpocząć od rozdzielenia kilku warstw: dostępności panelu, pracy zadań cron, działania procesu wysyłkowego, połączeń z bazą oraz odpowiedzi Amazon SES. Pojedynczy komunikat o błędzie HTTP nie musi oznaczać problemu z Kubernetes, tak jak poprawny status poda nie potwierdza prawidłowego wysyłania wiadomości. Należy porównać logi aplikacji z informacjami o restartach podów, zdarzeniami klastra, limitami zasobów i stanem zależności.

Przydatne jest sprawdzenie, czy zadania Mautic wykonują się w przewidywanych odstępach, czy nie pozostają aktywne dłużej niż następne uruchomienie oraz czy liczba procesów wysyłkowych odpowiada założonemu modelowi pracy. W Sendy warto zweryfikować status kolejki, błędy zwracane przez Amazon SES, opóźnienia zapisu oraz zgodność konfiguracji wszystkich replik. Diagnostyka powinna obejmować również DNS, certyfikat TLS, reguły Ingress i limity czasu połączeń, ponieważ awaria jednej z tych warstw może wyglądać jak niedziałająca aplikacja.

Przy problemach z laptopem lub komputerem PC, na którym otwierany jest panel Sendy albo Mautic, można sprawdzić przeglądarkę, połączenie sieciowe, rozwiązywanie nazw DNS, certyfikaty oraz błędy lokalnego oprogramowania. Nie zastępuje to analizy klastra, bazy ani procesów wysyłkowych, ale pozwala oddzielić problem po stronie urządzenia użytkownika od problemu występującego w środowisku aplikacyjnym.