Wdrożenie aplikacji dla ponad 100 tys. użytkowników

Podobnie jak wielu z was, inżynierów, nauczyłem się tworzyć, projektować i wdrażać aplikacje internetowe poprzez kolekcję filmów na YouTube, artykułów na Medium i odpowiedzi Stack Overflow. Podczas gdy te cenne zasoby dostarczały niezbędnej wiedzy, często brakowało im praktycznego wglądu w tworzenie skalowalnych aplikacji i radzenia sobie z wyzwaniami infrastruktury.
W tym artykule chcę podzielić się z Wami moim doświadczeniem z tworzenia jednej z największych aplikacji w Holandii. Podzielę się cennymi lekcjami, które wyciągnąłem w ciągu ostatnich miesięcy, rzucając światło na praktyczne aspekty budowania skalowalnej aplikacji i odnosząc się do typowych zastrzeżeń, które pojawiają się podczas podejmowania decyzji dotyczących infrastruktury.
Skalowalność
Podczas gdy monolityczne architektury serwerów oferują korzyści, takie jak szybsze tempo rozwoju, mniejsza złożoność i lepsza wydajność w środowiskach o niskim natężeniu ruchu, skalowalność staje się poważnym wyzwaniem dla tych wdrożeń. W około 90% przypadków serwer monolityczny spełnia wymagania dotyczące wdrażania aplikacji. Problemy pojawiają się jednak, gdy obciążenie serwerów staje się bardzo nieprzewidywalne, charakteryzujące się wysokimi okresami szczytowymi i niskimi okresami poza szczytem.
Aby sprostać temu wyzwaniu, zdecydowaliśmy się na rozwiązanie bezserwerowe lub platformę organizowania kontenerów. W naszym przypadku wykorzystaliśmy EKS AWS do wdrożenia Kubernetes. Podczas gdy KOPS jest popularnym narzędziem ułatwiającym tworzenie klastrów, EKS oferuje kompleksowy zestaw wbudowanych funkcji, takich jak automatyczne skalowanie, solidna infrastruktura i uproszczone zarządzanie płaszczyzną sterowania. Możliwości te pozwoliły nam bez wysiłku skalować naszą infrastrukturę do dowolnego rozmiaru, skutecznie radząc sobie z różnymi obciążeniami.
Ale to nie wszystko! Samo skalowanie horyzontalne naszej infrastruktury nie wystarczyło. Aby poradzić sobie ze skalowalnością podów, zintegrowaliśmy nasze główne wdrożenie z HPA (Horizontal Pod Autoscaling). Umożliwiło to dynamiczne skalowanie poszczególnych podów, co pozwoliło nam spełnić kryteria infrastruktury klasy korporacyjnej.
Monitorowanie infrastruktury
Wraz ze złożoną architekturą opartą na mikro usługach pojawia się wyzwanie polegające na upewnieniu się, że wszystkie komponenty działają zgodnie z przeznaczeniem. Debugowanie błędu występującego w mikro usługach w chmurze może nie zawsze być łatwe. Jeszcze trudniejsze może być zidentyfikowanie słabego punktu występującego w stosie technologicznym.
Kilku pomocnych programistów poleciło nam skorzystanie z fantastycznego narzędzia o nazwie NewRelic. Niesamowite w tym narzędziu jest to, że pozwala ono płynnie połączyć całą infrastrukturę z jedną usługą monitorowania. Obejmuje to integrację z popularnymi językami, takimi jak Python, Javascript lub Go, a także platformami, takimi jak Kubernetes. NewRelic pozwala również monitorować wszystkie zasoby AWS z jednego intuicyjnego panelu.
Osłanianie
Potencjalnie największym błędem podczas pospiesznego procesu wdrażania jest brak jakiegokolwiek osłaniania WAF. Osłony WAF nie tylko zapobiegają atakom DDoS, ale także identyfikują wielu typowych złośliwych aktorów, którzy wykorzystują luki w zabezpieczeniach, takie jak XSS, CSRF lub wstrzyknięcia SQL. Gdy tacy aktorzy zostaną zidentyfikowani, osłona WAF natychmiast blokuje połączenia przychodzące i wychodzące.
Biorąc pod uwagę łatwość przeprowadzania ataków DDoS przy użyciu łatwo dostępnych narzędzi online, wdrożenie WAF ma kluczowe znaczenie dla zapobiegania odmowom usług spowodowanym przez amatorskie skrypty.
Dobrze znane przykłady rozwiązań WAF obejmują Cloudflare i osłonę WAF od AWS. Co prawda Cloudflare może posiadać więcej danych pozwalających określić legalność odwiedzających, ale AWS zapewnia płynną integrację z load balancerami w ramach swojego ekosystemu.
Tokeny dostępu
Chociaż w wielu przypadkach wbudowany menedżer JWT lub menedżer tokenów sesji z frameworka backendowego jest wystarczający, aplikacja na dużą skalę wymaga bardziej niezawodnego rozwiązania. Tradycyjne biblioteki OAuth są ogólnie uważane za bezpieczne, ale nadal mogą wprowadzać potencjalne błędy:
Po pierwsze, przechowywanie tokenów w lokalnej pamięci przeglądarki niekoniecznie jest bezpieczne. Atak XSS może umożliwić złośliwemu użytkownikowi dostęp do tokenów, z pominięciem zaimplementowanej biblioteki OAuth. Po drugie, tradycyjne biblioteki OAuth przechowują tokeny dostępu i odświeżania w bazie danych połączonej z ORM, co może być nieoptymalne w przypadku naruszenia bazy danych. I jako ostatnie, błędne konfiguracje w warstwie uwierzytelniania mogą powodować luki w zabezpieczeniach.
Na szczęście istnieje kilka rozwiązań, które można wdrożyć ręcznie. Jedną z cennych lekcji, których nauczyliśmy się podczas procesu rozwoju, jest powierzenie zaufanej stronie trzeciej obsługi zarządzania tokenami i IAM (Identity and Access Management). Takie podejście nie tylko upraszcza proces, ale także deleguje odpowiedzialność za zabezpieczenie tokenów i danych użytkowników do wyspecjalizowanej usługi. W naszym przypadku wykorzystaliśmy Auth0 do zarządzania wszystkimi tokenami i zarządzania dostępem.
Podsumowując, wdrożenie aplikacji na dużą skalę może być złożonym przedsięwzięciem, obejmującym wiele potencjalnych wyzwań. Z mojego doświadczenia wynika, że początkowe wdrożenie takiej aplikacji dostarczyło mi więcej cennych lekcji w ciągu pierwszych trzech dni, niż nauczyłem się przez cały poprzedni rok jako inżynier oprogramowania. Celem tego artykułu jest podzielenie się niektórymi z popełnionych przez nas błędów i rzucenie światła na przeszkody związane z wymagającym zadaniem tworzenia bezpiecznych, skalowalnych i wydajnych infrastruktur.
Oryginał tekstu w języku angielskim przeczytasz tutaj.