Całkowity remont infrastruktury jest jedną z najtrudniejszych inicjatyw, jakie podejmuje każdy zespół techniczny. Wiele razy zespół stojący za określonym stosem mógł go opuścić, co prowadziło do wielu nieprzewidzianych okoliczności. Jednak w mPharma tak nie było, przez lata mieliśmy odpowiedni transfer wiedzy między krytycznymi częściami systemu. W tym artykule chciałbym podzielić się tym, jak udało nam się przeprowadzić migrację naszej podstawowej infrastruktury z Marathon/Mesos do Kubernetes.

Przez lata aktywnie budowaliśmy szereg produktów w oparciu o stale rosnące potrzeby pacjenta w Afryce. Aby wymienić kilka;

1. Z powodzeniem przeskalowaliśmy Bloom , naszą autorską aplikację do zarządzania nowoczesną apteką na 9 krajów (w chwili pisania tego artykułu liczba ta wzrosła do 10).
2. Uruchomiliśmy również myMutti , platformę handlu elektronicznego umożliwiającą kupowanie leków dostępnych bez recepty przez Internet i dostarczanie ich do domu.
3. Zbudowaliśmy i uruchomiliśmy aplikację magazynowo-logistyczną, aby lepiej śledzić ruch produktów z naszego magazynu do partnerskich aptek i szpitali o nazwie Marketplace.
4. Uruchomiliśmy aplikację do dostarczania ostatniej mili, aby dalej cyfryzować sposób, w jaki transportujemy narkotyki.
5. Zaczęliśmy również gromadzić dane diagnostyczne w Bloom, aby rozszerzyć nasz program Mutti Doctor .

Zespół inżynierów przez lata rozważał możliwość migracji naszej podstawowej infrastruktury. Jednak nasz gwałtowny rozwój jako firmy skłonił nas do nadania priorytetu produktom budowlanym zamiast wymyślania na nowo naszej podstawowej infrastruktury. W styczniu 2021 roku zdaliśmy sobie sprawę, że musimy na nowo opracować naszą infrastrukturę, w przeciwnym razie nie będziemy w stanie wspierać wzrostu, jakiego doświadczamy jako firma i zespół.

Podstawowa infrastruktura w mPharma przechodziła przez lata różne fazy, jednak była to nasza pierwsza próba całkowitej przebudowy, a także zapewnienia, że ​​nasza infrastruktura odpowiada rozwojowi firmy i zespołu jako całości.

Nasze rozmowy rozpoczęły się od skupienia się na problemie, który chcieliśmy rozwiązać. Dzięki temu zredukowaliśmy wszelkie elementy stronniczości przy wyborze konkretnego narzędzia i skupiliśmy się na najlepszym rozwiązaniu. Kluczowym pytaniem, które sobie zadaliśmy, było „jaki stos pomoże nam się rozwijać”. Zaczęliśmy od skupienia się na pięciu kluczowych obszarach;
1. Skalowalność
2. Doświadczenie programisty
3. Wsparcie społeczności
4. Bezpieczeństwo
5. Koszt

W oparciu o powyższe i kilka gorących debat zdecydowaliśmy się na Kubernetes.

Co to jest Kubernetes?

Według Kubernetes.io Kubernetes, znany również jako K8s, to system typu open source do automatyzacji wdrażania, skalowania i zarządzania kontenerowymi aplikacjami. Grupuje kontenery, które składają się na aplikację, w logiczne jednostki w celu łatwego zarządzania i wykrywania. Kubernetes opiera się na 15-letnim doświadczeniu w obsłudze obciążeń produkcyjnych w Google, w połączeniu z najlepszymi pomysłami i praktykami społeczności.

Proces migracji

Każda migracja na taką skalę zwykle prowadzi do przestojów w działaniu usług, naszym celem było albo całkowite wyeliminowanie tego zjawiska, albo zminimalizowanie jego występowania. Nasz pierwszy krok polegał na utworzeniu zespołu projektowego kierowanego przez kierownika projektu. Kierownik projektu był odpowiedzialny za kompleksowe zarządzanie migracją i zapewnienie wszystkim zainteresowanym stronom aktualnych informacji o postępach różnych inicjatyw. Niektóre z nich obejmują;
1. Jaki będzie dodatkowy koszt uruchomienia dodatkowych serwerów?
2. Jaki jest najlepszy sposób na łatwe wdrażanie aplikacji na Kubernetes bez powodowania przerw w przepływie prac programistycznych?
3. Jak będziemy mierzyć sukces wdrożenia?
4. Jak sprawnie przeniesiemy ruch ze starych serwerów na nowe po migracji?

Jaki będzie dodatkowy koszt uruchomienia dodatkowych serwerów?

Jako zespół jednym z naszych głównych celów jest redukcja kosztów, ponieważ te oszczędności przekładają się na to, że mPharma jako firma jest w stanie oferować pacjentom niższe koszty leków. Postanowiliśmy porozmawiać z naszym dostawcą usług w chmurze, aby sprawdzić, czy mają program do sprawdzania poprawności projektów (POC). Udało nam się nakłonić naszego dostawcę usług chmurowych do pokrycia kosztów naszej migracji do momentu, gdy uzyskaliśmy stabilną pozycję. Z tego powodu wydaliśmy 0 USD na kilka pierwszych tygodni naszej migracji.

Jaki jest najlepszy sposób na łatwe wdrażanie aplikacji na Kubernetes bez powodowania przerw w przepływie pracy programistycznej?

Chcieliśmy znaleźć sposób na przeprowadzenie tej migracji bez zakłócania cyklu rozwoju oprogramowania przez inżynierów. Kluczową rzeczą, na którą należy zwrócić uwagę, jest to, że podczas migracji nadal tworzyliśmy produkty dla pacjentów, a biznes nadal rozwijał się w zastraszającym tempie. Przed tą migracją wszystkie nasze usługi miały plik .yaml, który zawierał instrukcje wdrażania. Nie chcieliśmy przeciążać inżynierów pisaniem nowego zestawu instrukcji wdrożeniowych. To sprawiło, że zdecydowaliśmy się na scentralizowanie naszego skryptu wdrożeniowego w GitLab. W tym skrypcie mieliśmy sekcje, które wdrażały kod zarówno w Marathon/Mesos, jak i Kubernetes. Zapewniło to, że praca inżynierów nie została naruszona podczas tego okresu migracji.

Jak sprawnie przeniesiemy ruch ze starych serwerów na nowe po migracji?

To był najtrudniejszy i najtrudniejszy etap naszej strategii migracyjnej. Skupiliśmy się na tym, jaka ścieżka nie spowoduje zakłóceń w jakości usług. Przełączanie ruchu na nowe serwery było dla nas trudne, ponieważ podczas tej migracji zmieniliśmy sposób uwierzytelniania i autoryzacji. Uniemożliwiło nam to stopniową migrację. Musieliśmy przeprowadzić migrację wszystkich usług jednocześnie. Po kilku dyskusjach skłanialiśmy się ku wykorzystaniu danych o ruchu do podjęcia tej decyzji. Przyjrzeliśmy się ruchowi w naszych aplikacjach, aby wybrać najlepszy czas na zmianę ruchu. Po przejrzeniu danych z naszej bramy API ustaliliśmy, że sobotni wieczór. Było to spowodowane mniejszym ruchem w naszej sieci w niedziele, stąd wszelkie zakłócenia będą miały bardzo mały promień wybuchu. Zdecydowaliśmy się również na pracę w biurze, aby zmniejszyć problemy komunikacyjne. Zamówiliśmy dużo pizzy, bo wiedzieliśmy, że zadanie nie będzie łatwe. O 23:00 GMT przystąpiliśmy do zmiany ruchu.

Jak będziemy mierzyć sukces wdrożenia?

Jednym z zespołów, o których mało się słyszy, jest nasz zespół ds. zapewniania jakości i SRE. Te dwa zespoły dbają o to, aby tworzone przez nas produkty spełniały najwyższe standardy. Jednak, jak mówi Isaac, kierownik kontroli jakości, zawsze mówi: „Jakość produktów to nie tylko obowiązek zespołu ds. kontroli jakości”. Postanowiliśmy złączyć się wszyscy, aby przetestować różne części aplikacji po migracji, aby upewnić się, że wszystko działa płynnie. Innym kluczowym obszarem, którego nie udało mi się podkreślić, była migracja naszych środowisk testowych i etapowych do Kubernetes przed wdrożeniem do produkcji. To dało nam pewność, że wszystko zostało odpowiednio przetestowane i działa zgodnie z oczekiwaniami.

Zdobyta wiedza

1. Nie zwracanie uwagi na wskaźniki użytkowania

Wkrótce po wdrożeniu do Kubernetes zauważyliśmy szereg problemów zgłaszanych przez naszych użytkowników dotyczących przestojów aplikacji. Podczas migracji naszych aplikacji skupiliśmy się na środkach obniżających koszty, ograniczyliśmy ilość pamięci i procesora, które można przydzielić do konkretnego kontenera. Prowadziło to do tego, że kontenery umierały lub uruchamiały się ponownie za każdym razem, gdy osiągnęły limit pamięci lub procesora. Kluczową lekcją dla nas było nie zwracanie uwagi na wskaźniki wykorzystania kontenerów z naszej starej infrastruktury i wykorzystywanie ich do decydowania o tym, jak przydzielamy zasoby do każdej usługi.

2. Błędna konfiguracja usług przez właścicieli usług

Kolejnym błędem, który zauważyliśmy, były błędne konfiguracje przez właścicieli usług. Konfigurowanie zmiennych środowiskowych dla usług wymagało dużo ręcznej pracy, co prowadziło do popełniania błędów przez inżynierów. Jest to coś, nad czym aktywnie pracujemy i ustalamy najlepszy sposób zarządzania zmiennymi, aby ograniczyć liczbę błędów.

3. Brak testów jednostkowych i kompleksowych

Ze względu na to, jak radziliśmy sobie z uwierzytelnianiem w naszej starej infrastrukturze i potrzebą jak najszybszej migracji, pominęliśmy testy jednostkowe i testy kompleksowe w naszym potoku CI/CD. Doprowadziło to do kilku błędów, które zostałyby złapane. W przypadku, gdy będziemy przeprowadzać kolejną migrację, zawsze zadbamy o to, aby ten etap był uwzględniony w procesie CI/CD.

4. Przełączanie ruchu:

Przełączanie ruchu między naszą starą a nową infrastrukturą mogło być obsługiwane inaczej. Zamiast przełączać 100% ruchu, mogliśmy skupić się na robieniu tego stopniowo, aby zmniejszyć promień wybuchu.

Napisanie tego artykułu zajęło około 6 miesięcy, ponieważ zespół skupił się na upewnieniu się, że migracja nie doprowadziła do pogorszenia jakości usług, a także skupił się na tworzeniu/udoskonalaniu produktów, z którymi współpracują nasi klienci. Na podstawie interakcji z różnymi kluczowymi interesariuszami w firmie i poza nią powiem, że migracja zakończyła się sukcesem. Nieustannie ulepszamy nasze usługi, aby lepiej służyć naszym klientom i zapewnić, że ułatwimy pacjentom korzystanie z ogromnych inwestycji infrastrukturalnych, jakie mPharma dokonuje w opiece zdrowotnej.