Norweski portal nieruchomości

Portal, w którym sprzedający i kupujący widzą swoją nieruchomość: dokumenty, oferty kupna, statystyki ogłoszenia i rozmowę z pośrednikiem. Dane nie powstają tutaj - przychodzą z dwóch systemów źródłowych używanych w agencjach. Portal przechowuje ich kopię, synchronizowaną w tle, i dokłada własną warstwę, której w tamtych systemach nie ma.

Opisany stan obejmował 486 plików PHP i 122 migracje bazy danych. Kolejki działały na SQS, pliki na S3, a baza na RDS. Modernizację prowadziłem na systemie obsługującym użytkowników.

Celem było utrzymanie ciągłości pracy portalu i przygotowanie go do dalszego rozwoju.

Baza produkcyjna przeszła aktualizację z MySQL 8.0.44 na 8.4.9 metodą Blue/Green - ruch przełączany na gotową, zsynchronizowaną kopię. Bez przestoju. Zaraz po przełączeniu w logu wolnych zapytań pojawiły się dwa zapytania, których wcześniej tam nie było.

Analiza zapytań wskazała brak indeksów potrzebnych do efektywnego wyszukiwania danych. Był to problem istniejącej struktury bazy, który ujawnił się podczas kontroli po aktualizacji.

Pierwsze zapytanie: wyszukanie nieruchomości po identyfikatorze z systemu źródłowego, używane podczas synchronizacji danych. Kolumna była drugą kolumną istniejącego indeksu złożonego. Ten indeks nie zapewniał efektywnego wyszukiwania dla badanego zapytania. Baza miała 101 322 różne identyfikatory w 101 491 rekordach, a badany plan wykonania skanował około 23 500 wierszy.

Drugie: lista nieruchomości zalogowanego sprzedającego, uruchamiana za każdym razem, gdy ktoś otwiera swoją listę. Tabela osób sprzedających - 158 429 wierszy - miała wyłącznie klucz główny, żadnego indeksu na adresie e-mail ani na telefonie. Żeby znaleźć jednego zalogowanego użytkownika, baza przetwarzała wszystkie 158 429 wierszy. Sam ten skan to było 50 ms z 70 ms całego zapytania.

Dodanie indeksów na działającej bazie trwało 5,1 sekundy i 11,3 sekundy. Użyłem trybu pozwalającego na równoczesne zapisy; opisane zmiany nie wymagały okna serwisowego.

Pierwsze zapytanie służy synchronizacji danych, drugie - wyświetlaniu listy nieruchomości sprzedającego. Indeksy ograniczyły pracę bazy przy tych powtarzających się operacjach.

Zewnętrzny CRM zaczął masowo oznaczać nieruchomości jako zmienione i jednocześnie ograniczać ruch. W jeden dzień do kolejki trafiło 7 739 komunikatów zamiast zwykłych kilkuset, a odpowiedzi zaczęły wracać z kodem 429.

Portal pozostawał dostępny, ale część aktualizacji danych się nie powiodła. W tym jednym dniu system zapisał 558 nieudanych aktualizacji jako wykonane.

Kod pobierający nieruchomość przechwytywał błędy HTTP, ale nie przekazywał informacji o niepowodzeniu do procesu obsługi kolejki. W logu pojawiał się wpis „Successfully processed”, a komunikat znikał bez ponowienia. Dane mogły pozostać nieaktualne aż do kolejnej zmiany w CRM i udanego pobrania albo ręcznej naprawy. Portal nadal je wyświetlał, więc sam brak zgłoszenia awarii nie ujawniał problemu. Został zauważony przy zmianie danych kupującego, która nie dotarła do portalu.

Decyzja, która poprowadziła całą naprawę: przestać potwierdzać komunikaty, których nie udało się przetworzyć. Ponawianie nieudanych operacji zwiększa jednak liczbę żądań. Najpierw trzeba było ograniczyć zbędne wywołania, aby ponowienia mieściły się w limicie dostawcy.

Trzy rzeczy naraz:

• →Samo uwierzytelnianie odpowiadało za połowę ruchu do CRM. Token trafił do pamięci podręcznej.
• →Jedno pobranie nieruchomości to było około 45 wywołań API, a pojedyncza odpowiedź 429 przerywała cały ciąg. Doszła obsługa nagłówka Retry-After i ponawianie na poziomie klienta HTTP.
• →Odsiewanie duplikatów w kolejce nie działało od początku: parser daty odrzucał ułamki sekundy zwracane przez CRM, przez co te same aktualizacje trafiały do kolejki wielokrotnie.

Jeśli Twój system pobiera dane z zewnątrz - z ERP, CRM albo od dostawcy - zadaj jedno pytanie: skąd wiesz, że wczorajsza synchronizacja się udała? Odpowiedź „nie było zgłoszeń” znaczy dokładnie tyle, ile znaczyła w tym portalu przez lata.

Brak błędów w logach nie wystarcza do potwierdzenia poprawności danych. Warto porównać dane i statusy aktualizacji po obu stronach oraz sprawdzić reakcję systemu na nieudane pobranie. Taki zakres można uwzględnić w audycie oprogramowania.

Spadek z około 45 do 17 wywołań na nieruchomość nie oznaczał końca optymalizacji. Plan kolejnego etapu zakładał pobieranie tylko zmienionych sekcji i ograniczenie liczby wywołań do 3-6. Był to szacunek wymagający sprawdzenia po wdrożeniu.

Na koniec opisanego etapu portal nadal odpytował CRM cyklicznie. Przejście na powiadomienia o zmianach z systemu źródłowego pozostawało osobnym zadaniem integracyjnym.

Na koniec opisanego etapu brakowało automatycznych alarmów o przekraczaniu limitu dostawcy i rosnącej kolejce błędów. Kolejka zawierała 2 639 komunikatów wymagających przeglądu. Ta liczba nie określa liczby różnych nieruchomości ani aktualizacji, które nadal wymagały naprawy - trzeba było sprawdzić duplikaty i późniejsze udane pobrania.

System, którego dane pochodzą z zewnątrz, nie może zakładać, że źródło odpowie. Po opisanych zmianach nieudane pobrania były rejestrowane i ponawiane, a mniej wywołań API zmniejszało ryzyko przekroczenia limitu dostawcy. Czasy dwóch badanych zapytań spadły ze 130 ms do 0,04 ms oraz z 70 ms do 3,8 ms.

Wszystko na działającym systemie, bez okna serwisowego i bez przepisywania czegokolwiek od zera.