Studium przypadku: Dlaczego korzystam z infrastruktury chmury AWS dla moich produktów

Jako platforma do uruchamiania złożonego i wymagającego oprogramowania, AWS oferuje elastyczność dzięki wykorzystaniu zasobów w razie potrzeby, w wymaganej skali. Jest dostępny na żądanie i natychmiast, umożliwiając pełną kontrolę nad środowiskiem pracy. Proponując klientowi taką architekturę chmury, udostępniona infrastruktura i jej cena w dużej mierze zależą od wymagań, które należy ustawić z góry.

W tym artykule przedstawimy jedną z takich architektur infrastruktury chmury AWS, zaproponowaną i wdrożoną dla LEVELS, sieci społecznościowej ze zintegrowaną funkcją płatności za twarz, która znajduje i stosuje wszystkie korzyści, jakie użytkownicy mogą uzyskać za programy kartowe, w których się znajdują, rzeczy, które posiadają lub miejsca oni żyją w.

Wymagania

Klient miał dwa podstawowe wymagania, które musiało spełnić proponowane rozwiązanie:

1. Bezpieczeństwo
2. Skalowalność

Wymóg bezpieczeństwa polegał na ochronie danych użytkowników przed nieautoryzowanym dostępem z zewnątrz, ale także od wewnątrz. Wymóg skalowalności dotyczył zdolności infrastruktury do wspierania rozwoju produktu, automatycznego dostosowywania się do rosnącego ruchu i sporadycznych skoków, a także automatycznego przełączania awaryjnego i przywracania w przypadku awarii serwerów, minimalizując potencjalne przestoje.

Przegląd koncepcji bezpieczeństwa AWS

Jedną z głównych korzyści związanych z konfiguracją własnej infrastruktury AWS Cloud jest pełna izolacja sieci i pełna kontrola nad Twoją chmurą. Jest to główny powód, dla którego wybierasz trasę Infrastruktura jako usługa (IaaS), zamiast uruchamiać nieco prostsze środowiska Platforma jako usługa (PaaS), które oferują solidne domyślne zabezpieczenia, ale brakuje im pełnej, precyzyjnej kontroli, jaką uzyskujesz dzięki założenie własnej chmury z AWS.

Chociaż LEVELS był młodym produktem, kiedy zwrócili się do Toptal o usługi konsultingowe AWS, byli gotowi zaangażować się w AWS i wiedzieli, że chcą najnowocześniejszych zabezpieczeń w swojej infrastrukturze, ponieważ bardzo martwią się o dane użytkowników i prywatność. Ponadto planują w przyszłości wspierać przetwarzanie kart kredytowych, więc wiedzieli, że w pewnym momencie będą musieli zapewnić zgodność ze standardem PCI-DSS.

Wirtualna prywatna chmura (VPC)

Bezpieczeństwo w AWS zaczyna się od utworzenia Twojej własnej wirtualnej chmury prywatnej Amazon (VPC) – dedykowanej sieci wirtualnej, która obsługuje Twoje zasoby AWS i jest logicznie odizolowana od innych sieci wirtualnych w chmurze AWS. VPC otrzymuje własny zakres adresów IP, w pełni konfigurowalne podsieci, tabele routingu, listy kontroli dostępu do sieci i grupy bezpieczeństwa (w efekcie zaporę).

W przypadku LEVELS rozpoczęliśmy od odizolowania naszego środowiska produkcyjnego od środowisk programistycznych, testowych i QA. Pierwszym pomysłem było uruchomienie każdego z nich jako własnego, w pełni izolowanego VPC, z których każdy będzie uruchamiał wszystkie usługi wymagane przez aplikację. Po pewnym namyśle okazało się, że możemy pozwolić na współdzielenie zasobów w trzech środowiskach nieprodukcyjnych, co do pewnego stopnia obniżyło koszty.

Dlatego zdecydowaliśmy się na środowisko produkcyjne jako jeden VPC, a środowiska programistyczne, testowe i QA jako kolejny VPC.

Izolacja dostępu na poziomie VPC

Konfiguracja dwóch VPC izoluje środowisko produkcyjne od pozostałych trzech środowisk na poziomie sieci, zapewniając, że przypadkowa błędna konfiguracja aplikacji nie przekroczy tej granicy. Nawet jeśli konfiguracja środowiska nieprodukcyjnego błędnie wskazuje zasoby środowiska produkcyjnego, takie jak baza danych lub kolejki komunikatów, nie ma możliwości uzyskania do nich dostępu.

Ponieważ środowiska programistyczne, testowe i QA współdzielą ten sam VPC, dostęp transgraniczny jest możliwy w przypadku błędnej konfiguracji, ale ponieważ środowiska te wykorzystują dane testowe, nie ma realnych problemów związanych z bezpieczeństwem z powodu braku izolacji.

Model bezpieczeństwa magazynu aktywów

Zasoby są przechowywane w obiektowej pamięci masowej Amazon Simple Storage Service (S3) . Infrastruktura pamięci masowej S3 jest całkowicie niezależna od VPC, a jej model bezpieczeństwa jest inny. Pamięć masowa jest zorganizowana w osobnych zasobnikach S3 dla każdego środowiska i/lub klas zasobów, chroniąc każdy zasobnik odpowiednimi prawami dostępu.

Dzięki LEVELS zidentyfikowano kilka klas zasobów: przesłane przez użytkowników, treści wyprodukowane przez użytkowników (filmy promocyjne i podobne treści), zasoby aplikacji internetowych i interfejsu użytkownika (kod JS, ikony, czcionki), konfiguracja aplikacji i infrastruktury oraz pakiety wdrożeń po stronie serwera.

Każdy z nich otrzymuje osobne wiadro S3.

Zarządzanie tajemnicami aplikacji

Dzięki AWS istnieje zaszyfrowany magazyn parametrów AWS Systems Manager lub AWS Secrets Manager , które są zarządzanymi usługami opartymi na wartości klucza, zaprojektowanymi w celu zapewnienia bezpieczeństwa sekretów (więcej informacji można znaleźć w Linux Academy i 1Strategy).

AWS zarządza podstawowymi kluczami szyfrowania i obsługuje szyfrowanie/odszyfrowywanie. Same wpisy tajne mogą mieć zasady uprawnień do odczytu i zapisu stosowane na podstawie prefiksów kluczy, zarówno dla infrastruktury, jak i dla użytkowników (odpowiednio serwerów i programistów).

Dostęp do serwera SSH

Dostęp SSH do serwerów w w pełni zautomatyzowanym i niezmiennym środowisku nie powinien być w ogóle potrzebny. Logi można wyodrębniać i wysyłać do dedykowanych usług rejestrowania, monitorowanie jest również odciążane do dedykowanej usługi monitorowania. Mimo to może istnieć potrzeba sporadycznego dostępu SSH w celu sprawdzenia konfiguracji i debugowania.

Aby ograniczyć powierzchnię ataku serwerów, port SSH nie jest ujawniany w sieci publicznej. Serwery są osiągane przez bastion host, dedykowaną maszynę umożliwiającą zewnętrzny dostęp SSH, dodatkowo chronioną przez umieszczanie na zaporze tylko dozwolonych zakresów adresów IP. Dostęp jest kontrolowany przez umieszczenie publicznych kluczy SSH użytkowników w odpowiednich polach (logowanie za pomocą hasła jest wyłączone). Taka konfiguracja zapewnia dość odporną bramę, przez którą mogą przejść złośliwi atakujący.

Dostęp do bazy danych

Te same zasady opisane powyżej dotyczą serwerów baz danych. Może również zaistnieć okazjonalna potrzeba połączenia i manipulowania danymi bezpośrednio w bazie danych, choć zdecydowanie nie jest to zalecana praktyka, a dostęp taki musi być chroniony w taki sam sposób, jak chroniony jest dostęp SSH do serwerów.

Można zastosować podobne podejście, wykorzystując tę ​​samą infrastrukturę hosta bastionu z tunelowaniem SSH. Potrzebny jest podwójny tunel SSH, jeden do hosta bastionu, a przez ten drugi do serwera mającego dostęp do bazy danych (host bastionu nie ma dostępu do serwera bazy danych). Dzięki temu drugiemu tunelowi dostępne jest teraz połączenie z komputera klienckiego użytkownika do serwera bazy danych.

Omówienie koncepcji skalowalności AWS

Kiedy mówimy wyłącznie o serwerach, skalowalność jest dość łatwa do osiągnięcia dzięki platformom prostszym niż AWS. Główną wadą jest to, że niektóre wymagania mogą wymagać spełnienia przez zewnętrzne usługi platformy, co oznacza, że ​​dane przesyłane są przez sieć publiczną i przekraczają granice bezpieczeństwa. Pozostając przy AWS, wszystkie dane są prywatne, podczas gdy skalowalność musi być zaprojektowana tak, aby uzyskać skalowalną, odporną i odporną na awarie infrastrukturę.

Dzięki AWS najlepszym podejściem do skalowalności jest wykorzystanie zarządzanych usług AWS z monitorowaniem i automatyzacją przetestowaną w bitwach na tysiącach klientów korzystających z platformy. Dodaj do tego kopie zapasowe danych i mechanizmy odzyskiwania, a wiele obaw znajdziesz poza samą platformą.

Odciążenie tego wszystkiego pozwala na mniejszy zespół operacyjny, co nieco kompensuje wyższy koszt usług zarządzanych przez platformę. Zespół LEVELS z radością wybrał tę ścieżkę, gdy tylko było to możliwe.

Amazon Elastic Compute Cloud (EC2)

Poleganie na sprawdzonym środowisku z instancjami EC2 jest nadal dość rozsądnym podejściem w porównaniu z dodatkowym obciążeniem i złożonością uruchamiania kontenerów lub wciąż bardzo młodymi i szybko zmieniającymi się koncepcjami architektury bezserwerowej.

Udostępnianie instancji EC2 musi być w pełni zautomatyzowane. Automatyzację osiąga się poprzez niestandardowe AMI dla różnych klas serwerów oraz Grupy Auto Scaling dbające o uruchamianie dynamicznych flot serwerów poprzez utrzymywanie odpowiedniej liczby uruchomionych instancji serwerów we flocie zgodnie z aktualnym ruchem.

Dodatkowo funkcja autoskalowania umożliwia ustawienie dolnego i górnego limitu liczby uruchomionych instancji EC2. Dolna granica pomaga w tolerancji błędów, potencjalnie eliminując przestoje w przypadku awarii instancji. Górna granica utrzymuje koszty pod kontrolą, pozwalając na pewne ryzyko przestojów w przypadku nieoczekiwanych ekstremalnych warunków. Automatyczne skalowanie następnie dynamicznie skaluje liczbę wystąpień w ramach tych limitów.

Usługa relacyjnej bazy danych Amazon (RDS)

Zespół korzystał już z Amazon RDS dla MySQL , ale odpowiednia strategia tworzenia kopii zapasowych, odporności na awarie i bezpieczeństwa nie została jeszcze opracowana. W pierwszej iteracji instancja bazy danych została zaktualizowana do klastra dwuinstancyjnego w każdym VPC, skonfigurowanego jako master i replika do odczytu, obsługująca automatyczne przełączanie awaryjne.

W kolejnej iteracji, wraz z udostępnieniem silnika MySQL w wersji 5.7, infrastruktura została uaktualniona do usługi Amazon Aurora MySQL . Chociaż Aurora jest w pełni zarządzana, nie jest rozwiązaniem automatycznie skalowanym. Oferuje automatyczne skalowanie pamięci masowej, unikając problemu planowania pojemności. Jednak architekt rozwiązań nadal musi wybrać rozmiar instancji obliczeniowej.

Przestojów spowodowanych skalowaniem nie da się uniknąć, ale można je zredukować do minimum za pomocą funkcji automatycznego naprawiania. Dzięki lepszym możliwościom replikacji, Aurora oferuje bezproblemową funkcję przełączania awaryjnego. Skalowanie jest wykonywane przez utworzenie repliki do odczytu o żądanej mocy obliczeniowej, a następnie wykonanie przełączenia awaryjnego do tej instancji. Wszystkie inne repliki do odczytu są następnie również wyjmowane z klastra, zmieniane w rozmiarze i wprowadzane z powrotem do klastra. Wymaga trochę ręcznego żonglowania, ale jest więcej niż wykonalne.

Nowa oferta Aurora Serverless umożliwia również automatyczne skalowanie zasobów obliczeniowych, co zdecydowanie warto przyjrzeć się w przyszłości.

Zarządzane usługi AWS

Poza tymi dwoma komponentami, reszta systemu korzysta z mechanizmów autoskalowania w pełni zarządzanych usług AWS. Są to Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), obiektowa pamięć masowa Amazon S3, funkcje AWS Lambda i Amazon Simple Notification Service (SNS), w przypadku których architekt nie wymaga szczególnego wysiłku skalowania.

Zmienna a niezmienna infrastruktura

Rozpoznajemy dwa podejścia do obsługi infrastruktury serwerów — infrastrukturę zmienną , w której serwery są instalowane oraz stale aktualizowane i modyfikowane na miejscu; oraz niezmienną infrastrukturę, w której serwery nigdy nie są modyfikowane po udostępnieniu, a wszelkie modyfikacje konfiguracji lub aktualizacje serwera są obsługiwane przez udostępnianie nowych serwerów ze wspólnego obrazu lub skryptu instalacyjnego, zastępując stare.

W przypadku LEVELS wybór polega na uruchomieniu niezmiennej infrastruktury bez uaktualnień na miejscu, zmian konfiguracji lub działań związanych z zarządzaniem. Jedynym wyjątkiem są wdrożenia aplikacji, które mają miejsce na miejscu.

Więcej o infrastrukturze mutowalnej i niezmiennej można znaleźć na blogu HashiCorp.

Przegląd architektury

Technicznie rzecz biorąc, LEVELS to aplikacja mobilna i aplikacja internetowa z backendem REST API i niektórymi usługami w tle - dość typowa aplikacja w dzisiejszych czasach. W związku z tym zaproponowano i skonfigurowano następującą infrastrukturę:

Izolacja sieci wirtualnej — Amazon VPC

Diagram wizualizuje strukturę jednego środowiska w swoim VPC. Inne środowiska mają tę samą strukturę (posiadając klaster równoważenia obciążenia aplikacji (ALB) i klaster Amazon Aurora współdzielony między środowiskami nieprodukcyjnymi w ich VPC, ale konfiguracja sieci jest dokładnie taka sama).

VPC jest skonfigurowany w czterech strefach dostępności w regionie AWS, aby zapewnić odporność na błędy. Podsieci i grupy bezpieczeństwa z listami kontroli dostępu do sieci pozwalają spełnić wymagania dotyczące bezpieczeństwa i kontroli dostępu.

Rozszerzenie infrastruktury w wielu regionach AWS w celu uzyskania dodatkowej odporności na awarie byłoby zbyt skomplikowane i niepotrzebne na wczesnym etapie działalności i jej produktu, ale jest opcją w przyszłości.

Przetwarzanie danych

LEVELS uruchamia tradycyjny interfejs API REST z niektórymi pracownikami pracującymi w tle dla logiki aplikacji działającej w tle. Oba działają jako dynamiczne floty zwykłych instancji EC2, w pełni zautomatyzowane dzięki grupom automatycznego skalowania. Usługa zarządzana Amazon SQS służy do dystrybucji zadań w tle (zadań), co pozwala uniknąć konieczności uruchamiania, utrzymywania i skalowania własnego serwera MQ.

Istnieją również pewne zadania użytkowe, które nie mają logiki biznesowej współdzielonej z resztą aplikacji, takie jak przetwarzanie obrazu. Tego typu zadania działają bardzo dobrze na AWS Lambda , ponieważ Lambdy są skalowalne w nieskończoność w poziomie i oferują niezrównane przetwarzanie równoległe w porównaniu z pracownikami serwera.

Równoważenie obciążenia, automatyczne skalowanie i tolerancja błędów

Równoważenie obciążenia można osiągnąć ręcznie za pomocą Nginx lub HAProxy, ale wybranie Amazon Elastic Load Balancing (ELB) dodaje korzyści wynikające z tego, że infrastruktura równoważenia obciążenia jest wewnętrznie automatycznie skalowalna, wysoce dostępna i odporna na awarie.

Używany jest smak modułu równoważenia obciążenia aplikacji (ALB) ELB, przy użyciu routingu warstwy HTTP dostępnego w module równoważenia obciążenia. Nowe instancje dodawane do floty są automatycznie rejestrowane w ALB za pośrednictwem mechanizmów platformy AWS. ALB stale monitoruje również dostępność instancji. Może wyrejestrować i zakończyć niezdrowe instancje, uruchamiając automatyczne skalowanie w celu zastąpienia ich nowymi. Dzięki tej wzajemnej zależności między nimi osiągnięto automatyczne leczenie floty EC2.

Magazyn danych aplikacji

Magazyn danych aplikacji to klaster Amazon Aurora MySQL , składający się z instancji głównej oraz szeregu instancji do odczytu-replik. W przypadku awarii instancji głównej jedna z replik do odczytu jest automatycznie promowana do nowej instancji głównej. Skonfigurowany jako taki, spełnia wymagane wymagania dotyczące odporności na awarie.

Repliki do odczytu, jak wskazuje ich nazwa, mogą być również wykorzystywane do dystrybucji obciążenia klastra bazy danych na potrzeby operacji odczytu danych.

Pamięć masowa bazy danych jest automatycznie skalowana w przyrostach co 10 GB dzięki Aurora, a kopie zapasowe są również w pełni zarządzane przez AWS, oferując domyślnie przywracanie do określonego momentu. Wszystko to zmniejsza obciążenie administracyjne bazy danych praktycznie do zera, z wyjątkiem zwiększania mocy obliczeniowej bazy danych, gdy zajdzie taka potrzeba – usługa, za którą warto zapłacić, aby działać bezproblemowo.

Przechowywanie i udostępnianie zasobów

LEVELS akceptuje treści przesłane przez użytkowników, które muszą być przechowywane. Obiektowa pamięć masowa Amazon S3 jest, całkiem przewidywalnie, usługą, która zajmie się tym zadaniem. Istnieją również zasoby aplikacji (elementy interfejsu użytkownika - obrazy, ikony, czcionki), które należy udostępnić aplikacji klienckiej, aby zostały również zapisane w S3. Oferując automatyczne kopie zapasowe przesłanych danych poprzez ich wewnętrzną replikację pamięci masowej, S3 domyślnie zapewnia trwałość danych.

Obrazy przesyłane przez użytkowników mają różne rozmiary i wagę, często niepotrzebnie duże do bezpośredniego wyświetlania i przeciążają, obciążając połączenia komórkowe. Stworzenie kilku odmian w różnych rozmiarach umożliwi dostarczanie bardziej zoptymalizowanej zawartości dla każdego przypadku użycia. AWS Lambda jest wykorzystywana do tego zadania, a także do tworzenia kopii przesłanych oryginałów obrazów do osobnego zasobnika kopii zapasowych, na wszelki wypadek.

Wreszcie aplikacja internetowa działająca w przeglądarce to także zestaw zasobów statycznych — infrastruktura kompilacji ciągłej integracji kompiluje kod JavaScript i przechowuje każdą kompilację również w S3.

Gdy wszystkie te zasoby są bezpiecznie przechowywane w S3, można je obsługiwać bezpośrednio, ponieważ S3 zapewnia publiczny interfejs HTTP, lub za pośrednictwem Amazon CloudFront CDN. CloudFront sprawia, że ​​zasoby są rozproszone geograficznie, zmniejszając opóźnienia dla użytkowników końcowych, a także umożliwia obsługę HTTPS do obsługi zasobów statycznych.

Udostępnianie i zarządzanie infrastrukturą

Udostępnianie infrastruktury AWS to połączenie sieci, zasobów i usług zarządzanych przez AWS oraz samych zasobów obliczeniowych EC2. Zarządzane usługi AWS są, cóż, zarządzane. Nie ma z nimi wiele wspólnego poza zaopatrzeniem i zastosowaniem odpowiednich zabezpieczeń, natomiast przy zasobach obliczeniowych EC2 musimy sami zająć się konfiguracją i automatyzacją.

Obróbka

Internetowa konsola AWS sprawia, że ​​zarządzanie infrastrukturą AWS przypominającą klocki lego wcale nie jest trywialne i, jak każda praca ręczna, raczej podatne na błędy. Dlatego korzystanie z dedykowanego narzędzia do automatyzacji tej pracy jest bardzo pożądane.

Jednym z takich narzędzi jest AWS CloudFormation , opracowany i utrzymywany przez AWS. Kolejnym jest Terraform firmy HashiCorp — nieco bardziej elastyczny wybór, oferujący wielu dostawców platform, ale interesujący tutaj głównie ze względu na filozofię niezmiennej infrastruktury Terraform. W zgodzie ze sposobem, w jaki działa infrastruktura LEVELS, Terraform wraz z Packer do dostarczania podstawowych obrazów AMI okazał się doskonałym rozwiązaniem.

Dokumentacja infrastruktury

Dodatkową zaletą narzędzia do automatyzacji jest to, że nie wymaga ono szczegółowej dokumentacji infrastruktury, która prędzej czy później staje się nieaktualna. Paradygmat „Infrastruktura jako kod” (IaC) narzędzia do udostępniania jest kopiowany jako dokumentacja, dzięki czemu zawsze jest na bieżąco z rzeczywistą infrastrukturą. Wystarczy mieć ogólny przegląd, mniej podatny na zmiany i stosunkowo łatwy w utrzymaniu wraz z ewentualnymi zmianami, udokumentowany z boku.

Końcowe przemyślenia

Proponowana infrastruktura AWS Cloud jest skalowalnym rozwiązaniem, które jest w stanie dostosować się do przyszłego wzrostu produktu w większości automatycznie. Po prawie dwóch latach udaje mu się utrzymać koszty operacyjne na niskim poziomie, opierając się na automatyzacji w chmurze bez posiadania dedykowanego zespołu operacyjnego systemów dyżurującego 24 godziny na dobę, 7 dni w tygodniu.

Jeśli chodzi o bezpieczeństwo, AWS Cloud przechowuje wszystkie dane i wszystkie zasoby w sieci prywatnej w tej samej chmurze. Żadne poufne dane nie są nigdy wymagane, aby podróżować przez sieć publiczną. Dostęp zewnętrzny jest nadawany za pomocą szczegółowych uprawnień do zaufanych systemów wsparcia (CI/CD, zewnętrzny monitoring lub alarmowanie), ograniczając zakres dostępu tylko do zasobów wymaganych do ich roli w całym systemie.

Zaprojektowany i prawidłowo skonfigurowany, taki system jest elastyczny, odporny, bezpieczny i gotowy do spełnienia wszystkich przyszłych wymagań dotyczących skalowania w celu rozwoju produktu lub wdrażania zaawansowanych zabezpieczeń, takich jak zgodność z PCI-DSS.

Niekoniecznie jest tańszy niż oferty produktowe, takie jak Heroku lub podobne platformy, które działają dobrze, o ile pasujesz do typowych wzorców użytkowania objętych ich ofertami. Wybierając AWS zyskujesz większą kontrolę nad swoją infrastrukturą, dodatkowy poziom elastyczności z zakresem oferowanych usług AWS oraz dostosowaną konfigurację z możliwością dostrojenia całej infrastruktury.

Dalsza lektura na blogu Toptal Engineering:

• Odrób swoją pracę domową: 7 wskazówek egzaminacyjnych dla architektów rozwiązań z certyfikatem AWS
• Terraform vs. CloudFormation: ostateczny przewodnik
• Logowanie SSH i zarządzanie sesją za pomocą AWS SSM
• Praca z obsługą TypeScript i Jest: samouczek AWS SAM