Esta postagem no blog é sobre como aposentou suas últimas peças de infraestrutura na DigitalOcean, marcando sua migração para a AWS como concluída. ChartMogul A jornada não foi sua migração regular da AWS, pois envolveu a mudança de nossa infraestrutura de VMs clássicas para contêineres orquestrados pelo Kubernetes. Em uma série de artigos, compartilharemos nossas experiências sobre: Nossa jornada para o AWS EKS (serviço gerenciado do Kubernetes). Alguns dos obstáculos mais críticos que encontramos. Nossa pilha e ferramentas atuais. Nossos planos de infraestrutura daqui para frente, esperando que possam ser úteis para toda a comunidade. A vida com o DigitalOcean Desde a nossa criação em 2014 e até meados de 2021, toda a nossa infraestrutura foi executada em droplets da DigitalOcean (máquinas virtuais em nuvem autogerenciadas). Precisávamos de um provedor de nuvem para nos tirar do papel de forma rápida, confiável e econômica. A DigitalOcean fez muito sentido e foi uma ótima escolha. Estamos onde estamos por causa deles. Essa escolha nos deu a liberdade de focar na construção do produto sem nos preocuparmos com escalabilidade e complexidade da infraestrutura – aspectos que normalmente entram em ação em um estágio posterior. Cada aspecto de nossa infraestrutura foi provisionado, configurado e gerenciado internamente. Usamos ferramentas de gerenciamento de configuração e infraestrutura como código (Saltstack e Terraform) para gerenciar as coisas. Continuamos crescendo ao longo dos anos e, em 2019, nos deparamos com uma frota de cerca de 50 máquinas em constante necessidade de gerenciamento, atualizações de software, patches de segurança e assim por diante. E com novos projetos em nosso pipeline, esperávamos que nossas necessidades de poder computacional dobrassem até o final de 2020. Por que mudar e por que agora? Por mais que a DigitalOcean tenha sido uma ótima escolha, nosso crescimento orgânico foi ultrapassando os limites de nossa configuração ao longo dos anos. Enfrentamos desafios em várias áreas, algumas corrigíveis e evitáveis, outras não. Várias Falhas Janelas de manutenção ad-hoc não anunciadas que interromperam repentinamente a produção. Falhas de hardware em várias ocasiões, afetando nossa configuração primária de banco de dados de réplica (por exemplo, droplets entrando em um "estado de migração ao vivo para outras máquinas de hardware" sem aviso prévio, significando 1-2 horas de inatividade para esse droplet). Problemas inexplicáveis de rede com latência entre nossas máquinas que a equipe de suporte da DigitalOcean nunca eliminou (isso foi crítico para nosso atraso de réplicas de leitura do Postgres, instâncias Redis e HA em geral). Reprovação da região AMS2 Nossa região DigitalOcean (AMS2) foi anunciada como “em breve será aposentada”, o que significa suporte limitado. Não podíamos garantir recursos adicionais sob demanda, e a execução de tarefas simples geralmente significava planejamento demorado e desperdício de recursos. Coisas simples, como atualizar uma versão do Postgres e provisionar uma nova máquina para executar uma tarefa, estavam se tornando impossíveis de fazer. Opções limitadas de hardware Estar no espaço de análise de assinatura significa operações com uso intensivo de dados, grandes volumes e a capacidade de dimensionar de acordo com frequência. Máquinas modernas com recursos de hardware mais extensos só estavam disponíveis em outras regiões. A degradação do desempenho da rede era uma ocorrência frequente e logo percebemos que migrar para uma região diferente era nossa melhor aposta. Falta de recursos modernos de nuvem e serviços gerenciados O volume de trabalho operacional para manter nossa infraestrutura para acompanhar a taxa de crescimento (e lidar com a dívida de tecnologia simultaneamente) aumentou. Tivemos que dar uma boa olhada em nossa configuração e entender se mudar para uma região diferente da DigitalOcean ou um novo provedor de nuvem era a melhor escolha. Devemos ficar ou devemos ir? Começamos a analisar os benefícios de permanecer na DigitalOcean e simplesmente mudar para uma nova região – uma opção mais tranquila, rápida, barata e menos dolorosa. Mas, ao mesmo tempo, tratamos essa mudança como uma oportunidade de modernizar partes de nossa pilha a serviço do crescimento esperado de usuários e uma maior taxa de progresso. Ao final de nossa avaliação, percebemos que requisitos obrigatórios específicos seriam difíceis de alcançar permanecendo e simplesmente mudando de região. Os mais importantes foram: Flexibilidade em recursos de computação de dimensionamento automático. Bancos de dados gerenciados. Provisão de recursos com base no uso temporário. Baixa (mais) latência. Interoperabilidade de serviços. Infraestrutura baseada em contêiner com orquestração do Kubernetes. Essa lista de requisitos, juntamente com os desafios listados na seção anterior, fez pender a balança a favor da troca de provedores. Por que AWS? Escolher um novo provedor de nuvem para alimentar a infraestrutura ChartMogul foi uma longa jornada. Pesquisamos o mercado e descobrimos muitas compensações e vantagens que um novo provedor poderia trazer para a mesa. Nossas opções eram Amazon Web Services (AWS), Google Cloud (GCP) e Azure. Por fim, decidimos usar a AWS. Listamos alguns dos principais motivos abaixo. Experiência da equipe Já estávamos usando alguns serviços da AWS em produção (por exemplo, S3 para armazenar backups incrementais do Postgres). Mais importante, alguns de nossos engenheiros tiveram experiência profissional anterior usando vários serviços da AWS extensivamente em sistemas de produção. Escalabilidade Podemos aumentar ou diminuir as instâncias da AWS com o apertar de um botão. Podemos provisionar instantaneamente recursos como bancos de dados RDS e computar recursos temporariamente. Podemos iterar através de experimentos e provas de conceitos rapidamente. A flexibilidade e a escalabilidade dos pools de nós do Kubernetes com backup do dimensionamento automático do EC2 são difíceis de superar. Segurança de Dados e Conformidade A segurança dos dados sempre esteve em primeiro lugar. Ao longo dos anos, os recursos de segurança da AWS cresceram substancialmente. O número de novos serviços que a AWS desenvolveu em torno da segurança de dados cobre a maior parte de nossas necessidades no espaço de contêineres/Kubernetes. Eles funcionam bem com serviços bem estabelecidos, como isolamento privado de VPC, controle refinado de políticas e funções de IAM. Em termos de conformidade, planejamos obter a certificação SOC II o mais rápido possível e descobrimos que da AWS são uma vantagem que pode ajudar a acelerar essa jornada. os programas de conformidade Serviços gerenciados O Postgres está no centro do que fazemos na ChartMogul, e normalmente passamos muito tempo gerenciando ativamente nossa frota de máquinas de banco de dados para dar suporte ao nosso crescimento. A alta disponibilidade e confiabilidade dos bancos de dados estavam se tornando preocupações crescentes, então decidimos avaliar várias ofertas dos principais provedores de nuvem com PostgreSQL gerenciado. AWS RDS foi o vencedor claro. O Kubernetes gerenciado foi outro fator importante a ser considerado, e isso ocorreu de igual para igual com o Google Cloud (GCP). O Kubernetes (GKE) gerenciado do Google parecia melhor do que o que a AWS tinha na época, mas comparar o RDS ao CloudSQL não era tão próximo em termos de recursos. Atualmente, parece que a AWS está alcançando o EKS; Nós nos beneficiamos de excelentes recursos de RDS, como flexibilidade de snapshots, durabilidade de backup (com SLA), réplicas de leitura para Postgres, atualizações simples, IOPS dedicado, métricas Cloudwatch, Performance Insights e a lista continua. O número insano de serviços da AWS No momento da redação deste artigo, a AWS oferece mais de 200 serviços. A maioria deles oferece a capacidade de obter acesso instantâneo a serviços gerenciados de várias áreas, como computação, bancos de dados, análise de dados, armazenamento de dados, sem servidor e armazenamento. Nossas equipes de engenharia agora podem aproveitar integrações de alto nível para resolver problemas centrais rapidamente e priorizar a compra versus a construção onde faz sentido. Recuperação de desastres A nuvem AWS é uma parte essencial do nosso plano de recuperação de desastres. Isso ocorre porque as instâncias são fáceis de criar, podemos promover réplicas de leitura RDS a primárias com o clique de um botão, instantâneos são fáceis, podemos hospedar em várias regiões e temos uma integração de alto nível com nossa ferramenta IaC de escolha. Créditos da AWS Garantimos US$ 100 mil em créditos por meio do programa AWS Startup. Conseguimos planejar, testar e concluir nossa migração sem despesas consideráveis. Migração para AWS Nossa migração da DigitalOcean para a AWS foi uma jornada de dez meses. Todo o esforço foi apoiado por voluntários de todas as nossas equipes de engenharia e conduzido por um engenheiro de DevOps, um engenheiro de back-end e nosso chefe de engenharia. Algumas coisas envolviam tentativa e erro. Tentamos várias maneiras de: Movendo dados de Postgres para RDS com tempo de inatividade quase zero. Movendo nosso aplicativo e serviços da arquitetura baseada em VM para os conteinerizados no Kubernetes. Mudando fundamentalmente a maneira como implantamos. Um plano perfeito estava em vigor e tudo parecia bom para sair no papel, mas aprendemos da maneira mais difícil que as coisas nem sempre saem conforme o planejado. Às vezes, nossa meta de migração de tempo de inatividade quase zero corria sério risco e voltávamos à prancheta. Perseverança, motivação e um fantástico esforço de equipe nos ajudaram a superar os desafios que enfrentamos. O planejamento cuidadoso também fez maravilhas; Dada a nossa capacidade, estabelecemos desde o início que a divisão da migração real em três estágios (ou dias) funcionaria melhor. Semana anterior ao Dia D Inicie a replicação do Postgres da DigitalOcean para as instâncias do RDS. Revise nossa futura infraestrutura de produção da AWS. Configuração de segredos (AWS Parameter Store). Garanta que os pipelines de CI/CD estejam prontos para implantação em nossos novos clusters Kubernetes. Um dia antes do dia D Prepare nossa infraestrutura temporária de gravador de webhook da AWS (perder eventos durante nossa migração não era uma opção). Mova alguns dados com antecedência (por exemplo, DigitalOcean Spaces para S3). Atualize todos os segredos do Parameter Store para valores de produção. Preparar alterações de DNS. Defina todas as implantações do Kubernetes como zero pods para impedir que os serviços acessem dados de produção durante a migração. Dia D: apertando o botão Redirecione todos os webhooks para o gravador temporário da AWS. Pare todos os serviços na DigitalOcean. Aguarde a replicação do Postgres para atualizar as atualizações mais recentes. Compare os dados da DigitalOcean e RDS Postgres (para garantir a integridade e recuperação da replicação). Elimine a assinatura do RDS para o Postgres em execução na DigitalOcean. Crie réplicas de leitura do RDS. Atualize nossos segredos do Parameter Store com novos endpoints e segredos RDS. Implante no Kubernetes e reinicie o PgBouncer para carregar novas configurações. Alterne os registros DNS de para AWS. app.chartmogul.com Nesse ponto, estávamos executando nossa carga de trabalho de produção na infraestrutura novinha em folha! Terminamos tudo em 10 horas (inicialmente estimamos 8 horas – nada mal). Desafios com a AWS A maior dificuldade foi com o serviço DMS (serviço gerenciado da AWS para mover bancos de dados para RDS). Não foi tão fácil de usar como anunciado. No nosso caso com o Postgres, não foi útil. Por fim, desenvolvemos uma maneira personalizada de mover dados para a AWS. Também percebemos que mover bancos de dados com tempo de inatividade zero para a AWS com suporte a webhook é complicado. Desenvolvemos uma abordagem personalizada para dar suporte a essa configuração. Mais sobre essas abordagens personalizadas em artigos futuros. Futuros artigos da série Fique atento aos artigos futuros que documentam nossa jornada de migração da DigitalOcean para a AWS. Abordaremos temas como: Por que escolhemos o Kubernetes para capacitar o ChartMogul. Como migramos PostgreSQL para RDS. Como migramos nosso aplicativo Rails para Kubernetes. Como configuramos um túnel IPSEC para AWS VPC.
