O mnieBlogGitHub

ITCorner Tech Meetup #1 Skalowanie

19 January, 2020 - 4 min read

Kilka dni temu wziąłem udział w spotkaniu ITCorner Tech Meetup, którego tematem przewodnim było skalowanie. Poniżej garść notatek.

Temat

W zasadzie tylko 50% spotkania było o skalowaniu - reszta była o refaktorze legacy. Temat ciekawy jeden i drugi, ale tytuł spotkania jednak mylący.

Skalowanie

Jarosław Jedliński w swojej prezentacji opowiedział, jak jego zespół dba o to, żeby strona popularnego sklepu Euro RTV AGD nie wysypywała się w czasie czarnego piątku. Według zamieszczony statystyk - ruch na stornie w ten dzień jest kilka razy większy, dając kilka tysięcy requestów na sekundę. Ten zespół rozwija portal [https://www.euro.com.pl/] już od kilkunastu lat, co pozwoliło w fajny sposób pokazać ewolucję architektury i używanych rozwiązań. Kroki mniej więcej były takie:

  1. Odseparować aplikacje "analityczne" od tej głównej, sklepowej.
  2. Zduplikować bazę, żeby aplikacje "analityczne" nie zamulały dostępu do bazy dla sklepu.
  3. Dać więcej instancji aplikacji sklepowych i jakiś load balancer.
  4. Dodać cache w aplikacjach sklepowych - żeby zredukować round-tripy do bazy.
  5. Wprowadzić centralny cache, żeby oszczędzić pamięć i nie trzymać powtórek w kilku cache'ach.
  6. Wprowadzić cache dla całych requestów (Varnish) - umożliwia chwilowy offline sklepu (np. podczas wdrożenia w ciągu dnia).
  7. Dodać drugą serwerownię ze zdkuplikowaną infrastrukturą, na wypadek awarii tej pierwszej.

Co ciekawe, cały rozwiązanie jest trzymane we własnych serwerowniach. Wydawało mi się, że to śmiga w chmurze, a jednak. Inna ciekawostka: nad rozwojem i utrzymaniem sklepu pracuje ponad 20-osobowy zespół programistów, testerów i administratorów.

Piotr Gołofit z Accesto opowiadał bardziej o mądrym przepisywaniu legacy (o tym niżej), ale w działce skalowania zwrócił uwagę na ciekawy aspekt. Bardziej mówił o skalowaniu biznesowy niż technicznym, tzn. o skalowaniu produktu (aplikacji) na większy rynek (międzynarodowy). W takich wypadkach trzeba pomyśleć m.in. o:

  • i18n = czyli obsłudze wielu języków: zarówno o przetłumaczonym interfejsie, jak i potencjalnym multi-języczną obsługą danych,
  • różnych strefach czasowych: wyświetlanie wg strefy czasowej użytkownika plus odpowiednie "tłumaczenie" dat i godzin wprowadzanych,
  • obsługa różnych walut - przede wszystkim jeśli chodzi o płatności. Co ciekawe, w przypadku tego projektu, o którym opowiadał Piotr, były to bliskie geograficznie rynki - wyjście z Irlandii na całe Wyspy Brytyjskie - to poza ww. sprawami dochodziły różnice kulturowe (wpływające de facto na sposób prezentowania danych) i polityczne (potencjalny brexit).

Przepisywanie legacy

Piotr Gołofit i Łukasz Urbański w swoich prezentacjach poruszali podobny temat: dostajemy do utrzymania (i rozwijania) starą aplikację, co robimy?

  1. Ciągniemy to tak, jak jest - babrzemy się w legacy, conieco refaktorując.
  2. Nowe rzeczy idą po nowemu, stare powoli próbujemy przepisywać na nowo.
  3. Wywalamy wszystko i startujemy z carte blanche.

Żadna z opcji nie jest idealna, obaj prelegenci udowadniali, że opcja druga - nazwana strangler pattern (termin wprowadził Martin Fowler) - jest sensownym rozwiązaniem. Jeżeli jesteśmy w stanie na poziomie routingu rozdzilić ruch do starej i nowej aplikacji, to możemy sobie stworzyć takie poletko z nową aplikacją w nowej technologii. Nowe moduły trafiają do nowej aplikacji, stare są po kolei przepisywane na nowo. Ale cały czas mamy jedno i drugie aktywne - na produkcji. Co więcej, analizując użycie poszczególnych funkcji, możemy wybierać do przepisana te części, które są najczęściej używane przez użytkowników. Finalnie - w świecie idealnym - na koniec w starej aplikacji nie zostaje nic, można więc w całości przepiąć się na nową wersję. Oczywiście to nie jest takie hop-siup: przykład projektu, o którym opowiadał Piotr Gołofit, to były 3 lata stopniowego naprawiania sytuacji. To wymaga metodycznego podejścia, tym bardziej, im bardziej bagniste jest legacy, do którego siadamy. Trzeba najpierw zadbać o elementarne sprawy, jak kontrola wersji, CI/CD, podstawowe testy, załatanie najważniejszych luk bezpieczeństwa - żeby móc iść do przodu. W pewnym sensie podziwiam konsekwencję, bo wiele osób widząc bagniste legacy, do którego nikt nie chce się dotykać, szybko by uciekło, byleby nie babarać się w jakichś technologiach sprzed 10 lat i byleby nie sprzątać bajzlu po kimś innym.

© 2020, Built with Gatsby