Od 20 do 1800 serwerów: ewolucja DevOps w airSlate

Jak zaczęliśmy

W 2015 roku airSlate miał jeden produkt – pdfFiller. W tym czasie cała infrastruktura była utrzymywana na 20 serwerach. Ze względu na nieoptymalny rozkład obciążenia, wydajność produktu spadała w godzinach szczytu, co negatywnie wpływało na sprzedaż i powodowało niezadowolenie klientów. Infrastrukturę utrzymywał jeden inżynier i dyrektor techniczny DevOps, więc zdecydowano się na stworzenie sukcesywnie rozwijającego się działu DevOps.

Infrastruktura firmy została zbudowana na platformie AWS (Amazon Web Services). Ze wszystkich alternatyw dla dostawców chmury ta platforma była najbardziej zaawansowana i opłacalna. Chociaż utrzymanie własnego centrum danych było tańsze, AWS umożliwił szybką rozbudowę infrastruktury wraz z rozwojem firmy – infrastruktura rosła o 100% rocznie – i tym samym generowanie nowych przychodów. To zrekompensowało koszty utrzymania infrastruktury w AWS.

Do 2016 roku serwery nadal były zarządzane ręcznie, a ich liczba wzrosła do 200. Jednak wraz z rozwojem infrastruktury utrzymanie jej stawało się coraz trudniejsze. Następnie zespół przystąpił do pełnej automatyzacji infrastruktury i wdrożenia CI/CD (Continuous Integration/Continuous Delivery).

Zaczęliśmy od oceny aktualnego stanu systemu i usprawnienia monitoringu. W tym celu wprowadzono system monitoringu Zabbix oraz scentralizowanie, procesowanie i analizę logów w modelu ELK. Platforma TeamCity CI/CD została wprowadzona w celu przyspieszenia dostarczania nowych wersji oprogramowania.

Od 2016 roku podejście IaC (Infrastructure as Code) jest wdrażane z wykorzystaniem takich narzędzi jak Terraform, ECS i Docker. Pełne wdrożenie tych technologii zajęło firmie dwa lata. Czas pokazał, że była to strategicznie słuszna decyzja – rozwój infrastruktury okazał się wyjątkowo dynamiczny: z 200 do 1500 serwerów w ciągu dwóch lat.

Zakup i adaptacja nowych produktów

W ciągu 4 lat szybkiego wzrostu airSlate nabyło dwie firmy: signNow w 2017 r. i US Legal w 2019 r.

Obie firmy miały uruchomione usługi na platformie AWS, jednak pojawiły się też utrudnienia: w signNow w momencie zakupu infrastruktura była zarządzana ręcznie, do konfiguracji użyto SaltStack, a wszystko działało na serwerach EC2 bez kontenerów. Nie było prawie żadnej dokumentacji. W rezultacie dostosowanie infrastruktury signNow do standardów airSlate zajęło około roku. Deweloperzy przepisali większość kodu i dostosowali usługi do użytku z kontenerami Dockera.

 Tworzenie nowego produktu

W 2018 roku firma rozpoczęła budowę tytułowego produktu airSlate. Dzięki doświadczeniu i wystarczającym zasobom infrastruktura dla airSlate została natychmiast wykonana na podstawie IaC. Od pierwszych dni zdecydowano się na wykorzystanie architektury mikroserwisowej. A dziś produkt składa się z ponad 200 mikroserwisów. Początkowo wszystkie mikroserwisy były uruchamiane z wykorzystaniem AWS ECS (Elastic Container Services). Obecnie wiele usług jest zarządzanych z wykorzystaniem Kubernetesa, ponieważ stał się de facto standardem branżowym dla systemów orkiestracji kontenerów.

Wraz z uruchomieniem airSlate w 2018 roku firma rozpoczęła wdrażanie Jaeger, rozproszonego systemu śledzenia. Było to konieczne do monitorowania interakcji mikroserwisów. Firma nie miała wcześniejszego doświadczenia z OpenTracing, więc system był wielokrotnie zmieniany, dopóki nie spełnił standardów airSlate.

W tym czasie zarządzanie wszystkimi zasobami zostało całkowicie przeniesione do modelu IaC, można powiedzieć, że odtworzono infrastrukturę od podstaw. Zwiększyło to sterowalność, bezpieczeństwo i szybkość rozwoju. Przez cały ten czas infrastruktura firmy rosła o 100% rocznie.

W 2019 roku komponenty każdego produktu zostały przeniesione do oddzielnych izolowanych środowisk chmurowych i skonfigurowane do komunikacji równorzędnej. Zespół DevOps, który liczył już 20 osób, podzielił się na dwa zespoły infrastruktury:

• Marketing obsługuje systemy płatności, systemy marketingowe i zawartość stron oraz odpowiada za zarządzanie kampaniami Google AdWords. Średnio około 50 milionów słów jest używanych do prowadzenia kampanii Google AdWords, co jest poziomem największych kampanii AdWords.
• Common monitoruje infrastrukturę dla testerów, system testów A/B oraz konwertuje dokumenty, czyli komponenty, których potrzebują wszystkie produkty i zespoły.

Nasza metodologia

W zespole DevOps staramy się kierować prostymi i skutecznymi metodologiami, takimi jak:

• Immutable Infrastructure – cała infrastruktura jest wdrażana ze wstępnie przygotowanych obrazów;
• Self-healing – w przypadku awarii serwera sama infrastruktura powróci do stanu pracy;
• IaC – infrastruktura jako kod, która ułatwia tworzenie infrastruktury poprzez szybkie ponowne wykorzystanie kodu i zmniejsza ryzyko w najlepszej cenie. Możemy szybko odbudować dowolną część infrastruktury – pomaga to w razie potrzeby wdrożyć produkt w nowym regionie.

Wybierając technologie w firmie kierujemy się jasnym procesem:

• Opisujemy wymagania;
• Badamy i wybieramy technologie do porównania;
• Przeprowadzamy analizę porównawczą technologii;
• Przeprowadzamy testy;
• Po potwierdzeniu przez architektów i dyrektora technicznego technologie są testowane w praktyce w środowiskach testowych, a następnie udostępniane użytkownikom.

Technologie wprowadzane są do eksploatacji stopniowo, poprzez testy A/B. Najpierw dopuszczamy ograniczony przepływ użytkowników, a następnie zwiększamy ich odsetek i monitorujemy, jak wprowadzenie nowej technologii wpływa na rejestrację, sprzedaż i inne wskaźniki.

Wybierając technologię lub usługę zwracamy uwagę na to, czy w AWS są jakieś eliminujące konieczność serwisowania usługi. Jeśli ani AWS, ani inni dostawcy na rynku nie mogą nam zaoferować niczego optymalnego do rozwiązania naszych problemów, tworzymy własne rozwiązania.

Na przykład, gdy zaczęliśmy używać usługi AWS S3 do przechowywania danych, okazało się, że znacznie spowalnia ona pobieranie plików. Z tego powodu traciliśmy sprzedaż. Inna natywna usługa Amazon EFS (Elastic File System) nie rozwiązała tego problemu. Dlatego napisaliśmy rozproszony system plików do buforowania, przez który przechodzą pliki przed dostaniem się do AWS S3, co znacznie przyspiesza pobieranie plików.

Opracowaliśmy również własny system przetwarzania dokumentów, ponieważ nie byliśmy zadowoleni ze stabilności, szybkości i ograniczeń funkcjonalnych istniejących systemów.

Czego nauczyliśmy się pracując z infrastrukturą

Konieczne jest zrozumienie jak infrastruktura i programy wpływają na działalność firmy:

• Jak zmiany wydajności systemu wpływają na zyski?
• Ile kosztuje minuta przestoju produktu?
• Ile średnio kosztuje przechowywanie danych na użytkownika?
• Jakie metryki są krytyczne dla konkretnego systemu?

Konieczne są również:

– Dobrze znaj rozwiązania chmurowe, w których zbudowana jest infrastruktura. Istnieje wiele niuansów dotyczących każdej platformy, które można opisać w dokumentacji. Musisz dokładnie monitorować działanie systemów i przeprowadzać testy warunków skrajnych.

– W pełni zautomatyzuj infrastrukturę zgodnie z zasadami IaC i zaimplementuj te zasady w pracy zespołów, aby osiągnąć wysoką efektywność w zarządzaniu infrastrukturą.

– Wypróbuj dostępne technologie, ale jeśli nie pasują, nie bój się budować własnych. Czasami napisane narzędzie jest bardziej przydatne niż gotowe rozwiązanie.

– Prawidłowo oceń ryzyko związane z blokadą dostawcy. W naszym przypadku koszty i ryzyko związane z blokowaniem dostawcy AWS były niższe niż ryzyko korzystania ze złożonych rozwiązań infrastrukturalnych. Na rynku można znaleźć odpowiednie rozwiązania, aby zaoszczędzić dużo czasu, wysiłku i pieniędzy.

– Kupując nowe produkty, zbuduj jasny plan ich adaptacji, uwzględniając wymagania, ograniczenia i koszt zasobów.

– Przeznacz tyle czasu, ile potrzeba na techniczną adaptację produktów.

– Zrozum, że czynnik ludzki może odgrywać ważniejszą rolę niż czynnik techniczny. Na przykład przy zakupie firmy bardzo ważne są dobre relacje z zespołami firmy, którą kupujesz, podobnie jak wsparcie najwyższego kierownictwa obu firm.

Do czego dążymy i nad czym pracujemy

• Monitoring as a service – to rodzaj kontraktu pomiędzy zespołem ds. infrastruktury a zespołem programistów, w ramach którego zespół ds. infrastruktury utrzymuje system monitorowania w dobrym stanie, a sami programiści monitorują swoje usługi. Pozwala to osiągnąć dobrą skalowalność w poziomie.
• GitOps (argoCD) to metodologia, która przekłada najlepsze praktyki w tworzeniu oprogramowania na projekty infrastrukturalne. Za jego pomocą repozytoria Git stają się jedynym źródłem prawdy o stanie systemu: kodzie konfiguracyjnym aplikacji i infrastrukturze. A proces jej wdrażania jest zautomatyzowany przy użyciu zwykłych narzędzi CI/CD, co zwiększa szybkość tworzenia, niezawodność i powtarzalność rozwiązań.
• DevSecOps – ten model rozwoju zapewnia bezpieczeństwo na wszystkich etapach tworzenia oprogramowania poprzez procesy DevOps, takie jak SAST, DAST, skanowanie Open source, skanowanie obrazów kontenerów i inne.
• Budowanie centrów danych w nowych regionach geograficznych na platformie Amazon.
• Service mesh – pełne wykorzystanie systemów service mesh dla mikroserwisów.
• Enterprise security systems – wdrażanie systemów bezpieczeństwa dla dużych organizacji takich jak Okta, Snyk czy Ermetic.

Nasze statystyki na dziś:

• 100 000 000 zarejestrowanych użytkowników
• Około 25 000 000 wizyt miesięcznie
• Ponad 2 000 000 rejestracji miesięcznie
• Zaangażowanych jest 1700-1800 serwerów, w zależności od obciążenia infrastruktury