Amerykańska platforma subskrypcyjna

Proceduralny PHP pisany przez lata przez różne ręce. Baza obsługiwana przez funkcje usunięte z języka w PHP 7.0 - czyli kod, którego nie da się uruchomić na niczym współczesnym. Płatności przez skrypty CGI w Perlu, wciąż działające. Brak środowiska lokalnego: jedyną instancją, na której cokolwiek dało się sprawdzić, była produkcja.

System obsługiwał płacących klientów, dlatego modernizację trzeba było połączyć z bieżącą obsługą platformy.

Zaczęliśmy od audytu oprogramowania - żeby ustalić, które problemy wymagają naprawy, a które elementy mogą działać dalej. Pozwoliło to wybrać zakres modernizacji bez zakładania z góry, że całą aplikację trzeba przepisać.

Audyt wskazał trzy obszary do pilnej pracy: wersję PHP bez wsparcia bezpieczeństwa, luki w kontroli dostępu i koszty utrzymania infrastruktury.

Celem było przejście na PHP 8.4. Problem: 46 plików korzystało z funkcji obsługi bazy danych usuniętych z PHP w wersji 7.0. Trzeba było zapewnić ich działanie na nowej wersji języka.

Zamiast tego napisałem warstwę zgodności - osiem usuniętych funkcji zaimplementowanych od nowa na PDO, z typowanymi sygnaturami i tą samą semantyką, której oczekiwał stary kod. Aplikacja przeszła na PHP 8.4 bez zmiany w tych 46 plikach.

Do tego aktualizacja zależności do wersji wspieranych, statyczna analiza kodu i automatyczne formatowanie kodu, oraz środowisko lokalne w kontenerach - żeby przestać testować na produkcji.

To jest modernizacja aplikacji legacy: warstwa zgodności pozwoliła zaktualizować środowisko bez przepisywania wszystkich wywołań bazy danych.

W analizowanym okresie serwer obsługiwał około 90-95 tys. żądań na dobę. Logi pozwoliły wyodrębnić powtarzalny ruch jednego bota.

Największy pojedynczy sprawca odpowiadał za 24,4 tys. żądań dziennie, około 26% całego ruchu, i podszywał się pod ruch z wyszukiwarki Google, fałszując nagłówek Referer. Bot wysyłał w tym nagłówku wciąż ten sam ciąg z parametrami zapytania. Ta powtarzalna sygnatura pozwoliła przygotować filtr.

Filtr blokował żądania z tą sygnaturą. Przez dwa dni sprawdzałem, czy nie odcina prawdziwych użytkowników; w tym okresie nie stwierdziłem takich przypadków. Osobno odcięte zostały agresywne roboty komercyjne, które skanowały cały katalog. Przy okazji: tabela z logiem odwiedzin urosła do 2,1 GB i uległa uszkodzeniu - została odbudowana na silniku transakcyjnym.

Materiały wideo - 1 148 pozycji, 143 GB źródeł - przeniesione na wyspecjalizowany CDN, z odtwarzaniem i pobieraniem przez adresy podpisywane kryptograficznie. To naprawiło także lukę, przez którą pliki premium były dostępne bezpośrednio, z pominięciem kontroli abonamentu.

Szacowany koszt hostingu wideo na CDN wynosił 12-20 USD miesięcznie. Dotychczasowy serwer aplikacji i plików kosztował 400 USD miesięcznie. Na koniec opisanego etapu przejście na mniejszy serwer pozostawało w planie. Łączną oszczędność można potwierdzić dopiero po uwzględnieniu kosztu nowego serwera aplikacji i rzeczywistych opłat za CDN.

Na koniec opisanego etapu system działał na PHP 8.4 i miał środowisko lokalne, testy regresyjne oraz panel administracyjny. Filtr blokował bota odpowiadającego wcześniej za około 26% żądań. Wideo było już przeniesione na CDN, a obniżenie łącznych kosztów infrastruktury zależało od kolejnego kroku: zmniejszenia serwera aplikacji.

Żaden z tych efektów nie wymagał przepisania systemu od zera.