A Mira Network havia recentemente solicitado e sido aceita no programa de acelerador OVHcloud Web3 e conheceu a consultoria DevOps Dysnix através do esquema. A Dysnix projetou, planejou e conduziu uma transição para a OVHcloud, aproveitando serviços de nuvem de alto desempenho e Kubernetes gerenciado. A estratégia focou em "dimensionamento adequado", "automação primeiro" e princípios de visibilidade.
A equipe da Dysnix projetou um roadmap de migração e implementação que visava resolver a transição dentro de 17-25 dias, deixando tempo suficiente para resolução de problemas. A equipe da Dysnix re-arquitetou a infraestrutura do zero, garantindo que houvesse monitoramento, alerta e software de registro desde o primeiro dia, assim como escalabilidade por design, planejada para a implementação futura.
A solução hyperscale anterior lidava com provisionamento via sistemas manuais, que a equipe da Dysnix converteu para Terraform e Terragrunt, rodando infraestrutura como código. A orquestração mudou de Kubernetes não gerenciado ou manual para o serviço de Kubernetes gerenciado da OVHcloud, e o banco de dados RDS superdimensionado foi movido para um banco de dados PostgreSQL otimizado e gerenciado. A nova solução utilizou escalonamento automático preditivo / horizontal de pods para garantir escalabilidade, e monitoramento com VictoriaMetrics, Grafana e Loki; nenhum desses sistemas estava em vigor anteriormente.
As camadas principais de backend e dados foram movidas para uma configuração otimizada de alta disponibilidade em duas zonas na região da OVHcloud na Alemanha (Limburgo), e instâncias foram escolhidas com base nas necessidades de tráfego cuidadosamente perfiladas. A equipe da Dysnix também implementou balanceadores de carga para garantir a otimização do tráfego.
“Tomamos várias medidas para garantir que o sistema funcionasse bem,” disse Daniel Yavorovych, CTO da Dysnix. “No backend, configuramos verificações de saúde para detectar e reiniciar pods não saudáveis automaticamente, além de atualizações contínuas para garantir que o tráfego sempre estivesse fluindo durante os deployments – o que também nos permitiu acionar rollback automático se as taxas de erro disparassem após um novo deployment. Houve muito trabalho envolvido no design de cada aspecto do sistema, porque sabíamos que a Mira Network estava crescendo rápido – e isso significava manter as coisas em movimento.”
Os ativos de frontend foram migrados do provedor hyperscale para o armazenamento de objetos e CDN da OVHcloud, trabalhando em estreita colaboração com a equipe de sucesso do cliente da OVHcloud, reduzindo, assim, a latência para usuários finais globalmente. Pipelines de CI/CD foram configurados para o frontend, garantindo que novas versões pudessem ser implantadas de forma contínua no S3. A configuração anterior dependia de implantações manuais e scripts ad-hoc. A Dysnix implementou uma pipeline de CI/CD baseada no GitHub usando ferramentas padrão da indústria que automatizaram cada etapa, desde o commit de código até o lançamento em produção. Este modelo de implantação unificado eliminou a fricção operacional de gerenciar ciclos de lançamento separados para frontend e backend.
A equipe da Dysnix também implementou uma pilha de monitoramento em múltiplas camadas para tornar o sistema auto-consciente e auto-reparável. Isso incluiu o uso do Prometheus para coletar métricas de cada nó, pod e ponto de extremidade de aplicação do Kubernetes a cada 15 segundos. Isso captura CPU, memória, disco I/O, throughput de rede e métricas personalizadas de aplicação, como latência de consulta e tempos de confirmação de transações em blockchain.
Os dashboards do stack Grafana (Loki, Alloy, Grafana) forneceram visualização em tempo real da saúde do sistema, e um conjunto de regras de alerta automatizadas também foi implementado.
