Sieć Mira niedawno aplikowała i została zaakceptowana do programu akceleracyjnego OVHcloud Web3 oraz poznała konsulting DevOps Dysnix w ramach tego programu. Dysnix zaprojektował, zaplanował i przeprowadził tranzycję do OVHcloud, wykorzystując usługi chmurowe o wysokiej wydajności oraz zarządzane usługi Kubernetes. Strategia skupiała się na "optymalizacji rozmiaru", "automatyzacji jako priorytecie" oraz zasadach widoczności.
Zespół Dysnix zaprojektował mapę migracji i wdrożenia, mającą na celu przeprowadzenie tranzytu w ciągu 17-25 dni, pozostawiając wystarczająco dużo czasu na rozwiązywanie problemów. Zespół Dysnix przeprojektował infrastrukturę od podstaw, upewniając się, że od pierwszego dnia obecne były oprogramowanie do monitorowania, alarmowania i rejestrowania, a także skalowalność zaplanowana na przyszłe wdrożenia.
Poprzednie rozwiązanie o dużej skali obsługiwało provisioning za pomocą systemów ręcznych, które zespół Dysnix przełączył na Terraform i Terragrunt, uruchamiając infrastrukturę jako kod. Orkiestracja zmieniła się z niezarządzanej lub ręcznej Kubernetes na zarządzaną usługę Kubernetes OVHcloud, a nadmierna baza danych RDS została przeniesiona do zoptymalizowanej, zarządzanej bazy danych PostgreSQL. Nowe rozwiązanie używało przewidywalnego / poziomego autoskalowania podów, aby zapewnić skalowalność, oraz monitorowania VictoriaMetrics, Grafana i Loki; żaden z tych systemów nie był wcześniej wdrożony.
Główne warstwy backendu i danych zostały przeniesione do uproszczonej, dwu-strefowej konfiguracji wysokiej dostępności w regionie OVHcloud Niemcy (Limburg), a instancje zostały wybrane na podstawie starannie profilowanych potrzeb ruchowych. Zespół Dysnix również wprowadził load balancery, aby zapewnić optymalizację ruchu.
„Podjęliśmy kilka kroków, aby upewnić się, że system działał dobrze,” powiedział Daniel Yavorovych, CTO w Dysnix. „W backendzie skonfigurowaliśmy kontrole zdrowia, aby automatycznie wykrywać i restartować niezdrowe pody, a także aktualizacje w trybie rolling, aby upewnić się, że ruch zawsze płynął podczas wdrożeń – co również pozwoliło nam na uruchomienie automatycznych wycofań, jeśli wskaźniki błędów wzrosły po nowym wdrożeniu. Włożono wiele pracy w zaprojektowanie każdego aspektu systemu, ponieważ wiedzieliśmy, że Mira Network szybko rośnie – a to oznaczało, że musieliśmy utrzymywać rzeczy w ruchu.”
Aktywa frontendowe zostały przeniesione od dostawcy o dużej skali do obiektowego magazynu OVHcloud i CDN, ściśle współpracując z zespołem sukcesu klienta OVHcloud, co ostatecznie zmniejszyło opóźnienia dla użytkowników końcowych na całym świecie. Pipelines CI/CD zostały skonfigurowane dla frontendu, zapewniając, że nowe wersje mogą być bezproblemowo wdrażane do S3. Poprzednia konfiguracja opierała się na ręcznych wdrożeniach i doraźnych skryptach. Dysnix wdrożył pipeline CI/CD oparty na GitHubie, używając standardowych narzędzi branżowych, które zautomatyzowały każdy krok od zatwierdzenia kodu do wydania produkcyjnego. Ten zjednoczony model wdrożeń wyeliminował operacyjne tarcia związane z zarządzaniem oddzielnymi cyklami wydania frontendowego i backendowego.
Zespół Dysnix również wprowadził wielowarstwowy stos monitorowania, aby uczynić system samouczącym się i samonaprawiającym. Obejmuje to korzystanie z Prometheusa do zbierania metryk z każdego węzła Kubernetes, poda i punktu końcowego aplikacji co 15 sekund. To rejestruje CPU, pamięć, dysk I/O, przepustowość sieci oraz niestandardowe metryki aplikacji, takie jak opóźnienie zapytań i czasy potwierdzenia transakcji blockchain.
Stosy Grafana (Loki, Alloy, Grafana) dostarczały wizualizację zdrowia systemu w czasie rzeczywistym, a także wprowadzono zestaw zautomatyzowanych reguł alertów.
