A Sancor Seguros migrou seu Sistema SAP para a AWS em 8 semanas

Por Mauro Auer, Líder de Infraestructura y Redes en Grupo Sancor Seguros e
Alexis Winer, Sr. Advisory Consultant para el Sector Público en AWS e
Leandro Santi, Arquitecto de Soluciones para el Sector Público en AWS

O Grupo Sancor Seguros é um grupo de empresas localizadas na cidade de Sunchales (província de Santa Fé – Argentina) dedicada ao mercado de seguros. Atualmente, lidera o mercado de seguros argentino e fornece proteção a mais de sete milhões de segurados por meio de suas subsidiárias na Argentina, Uruguai, Paraguai e Brasil. Fundada em 1945, a Sancor Seguros é uma entidade jurídica cooperativa independente que se expandiu para o setor de seguros, bem como para a indústria de medicamentos pré-pagos com o estabelecimento da empresa “Prevención Salud” e o setor financeiro com o “Banco del Sol”.

Em 2020, quando a pandemia de COVID-19 nos obrigou a trabalhar de casa, a equipe de TI do Grupo Sancor Seguros teve que resolver o desafio de evoluir seus ambientes SAP, buscando aumentar sua disponibilidade, governança, e custos da plataforma. Para isso, a empresa realizou um processo de seleção de tecnologia e, como resultado, foi decidido migrar todos os ambientes SAP para a AWS.

Desafios

Durante a concepção do ambiente de migração do projeto SAP, identificamos alguns desafios:

Projetos simultâneos. A migração de ambientes teve que ser feita em paralelo com outros projetos de alta visibilidade dentro do grupo: a segunda etapa do projeto de implementação SAP que incluiu os recursos de cobranças, além da implantação de support packages da SAP para manter os componentes de software atualizados. O objetivo também era minimizar a janela de indisponibilidade dos ambientes SAP.

Janela de tempo limitada e multiplicidade de ambientes. Devido às janelas de implementação dos projetos simultâneos mencionados acima e às restrições contratuais adicionais do fornecedor anterior, a migração teve que ser feita dentro de um período de tempo limitado, dentro de um período máximo de 3 meses, para 7 ambientes com mais de 25 servidores diretamente envolvidos no processo de migração.

Diversidade de ambientes. Os ambientes originais rodavam em infraestrutura baseada em diferentes versões e variantes do Linux (Red Hat Enterprise Linux RHEL/SUSE). Para unificar e simplificar o gerenciamento de TI, a nova plataforma precisava implantar uma versão do RHEL em todos os ambientes.

Agilidade nas interações. Estávamos procurando um provedor que nos permitisse adotar mecanismos de interação ágeis e, assim, reduzir o tempo na tomada de decisões e na implementação de mudanças. Por exemplo, ter a capacidade de integrar recursos especializados da equipe de serviços profissionais da AWS e de nosso parceiro especializado em SAP, adicionar equipes aos ambientes ou modificar os recursos alocados a alguns deles.

Contrato de nível de serviço. Encontramos na proposta da AWS a capacidade de implantar todos os ambientes SAP com base em serviços em nuvem com níveis de SLA bem definidos, como Amazon EC2, Amazon S3, Amazon Site-to-Site VPN e muito mais.

Desempenho da interconexão de data center e nuvem. Tivemos uma experiência anterior em que o desempenho da interconexão com a infraestrutura de nuvem (em termos de latência e largura de banda em relação à região) não permitia que esse cenário fosse adotado. Embora todos os ambientes SAP já estivessem em uma nuvem, precisávamos validar que a interconexão com a nuvem da AWS não criaria um problema.

Recuperação de desastres. A plataforma de origem não tinha um esquema definido para recuperação de desastres, devido, entre outras coisas, aos altos custos associados à duplicação da infraestrutura de servidores na plataforma que prestava o serviço. Encontramos na proposta da AWS uma alternativa inovadora e, no final do dia, permitia implementar um esquema de recuperação de desastres com um bom equilíbrio entre baixo custo e desempenho (Recovery Point Objective – RPO tendendo a zero com um baixo Recovery Time Objective – RTO) graças a uma arquitetura de “pilot light”.

Mãos a obra

Durante a fase de avaliação do projeto, trabalhamos com a equipe da AWS conduzindo testes de conectividade entre nossos data centers e a nuvem usando a infraestrutura de borda da AWS na Argentina. Ao ativar o AWS Global Accelerator, conseguimos rotear o tráfego de VPN para o ponto de presença mais próximo de nossos data centers: dessa forma, conseguimos otimizar o caminho de rede da conexão, permitindo que nosso tráfego VPN entre na AWS com menos saltos, usando tráfego doméstico em vez de tráfego internacional.

Fig. 1: número total de saltos da conexão VPN normal versus VPN acelerada.

Como pode ser visto na Figura 1, habilitar a aceleração de VPN em relação ao nosso data center reduziu o número de saltos entre as duas extremidades da terminação do túnel, otimizando o roteamento dos datagramas graças ao fato de que eles entram na rede da AWS com menos saltos, roteando para a região através de um caminho livre de congestionamento para alcançar um melhor desempenho para nossos aplicativos. Também foi descoberto que as velocidades de transferência para a nuvem aumentaram 2,5 vezes, combinando otimizações no acesso à nuvem (redução no número de saltos) com o uso do tráfego doméstico em vez do tráfego internacional.

Obs: Para obter mais informações sobre o impacto do AWS Global Accelerator no desempenho de interconexão, você pode visitar a postagem do blog “Achieve up to 60% better performance for internet traffic with AWS Global Accelerator” e “Measuring AWS Global Accelerator performance and analyzing results“.

Início da migração
O projeto de implementação começou nos últimos dias de dezembro de 2020. A equipe de Serviços Profissionais da AWS (ProServe) foi responsável por liderar o projeto incorporando os parceiros AWS Seidor e Moebius que têm a especialidade SAP. A equipe de AWS ProServe implantou inicialmente o AWS Control Tower para criar uma estrutura de governança de várias contas, integrando-a aos datacenters do grupo por meio de Site-to-Site VPN utilizando Global Accelerator para executar um túnel com a infraestrutura de borda que a AWS tem no território da Argentina.

A arquitetura do esquema de recuperação de desastres foi proposta pela equipe de especialistas SAP de ProServe com base em um esquema de replicação híbrida, levando em consideração as necessidades apresentadas pelos negócios:

Replicação nativa síncrona para SAP HANA-DB sem carga na memória (pré-carga) de dados na instância secundária, adotando um esquema “pilot light” para otimização de custos que permite que a instância que executa a replicação HANA seja menor em tamanho e custo do que sua contraparte de produção (no nosso caso, ¼ do tamanho), permitindo que os dados sejam replicados continuamente sem duplicar os custos de infraestrutura para o banco de dados.
Replicação do restante dos computadores no cenário usando a ferramenta CloudEndure Disaster Recovery , que implementa um esquema de replicação contínua para dados em discos de servidor, permitindo que as alterações sejam replicadas no nível do bloco em segundos e (quando necessário) implantar toda a infraestrutura para recuperação de desastres em alguns minutos, sem o custo de manter as instâncias do EC2 ativadas durante a operação normal. Para a solução CloudEndure, somente instâncias econômicas (1 instância do tipo t2 por 10 volumes replicados) e discos de armazenamento de baixo custo são usados.

Fig. 2: arquitetura de recuperação de desastres para o ambiente SAP PROD (pilot-light):

replicação de armazenamento usando CloudEndure, replicação nativa HANA-DB.

No diagrama de arquitetura da Figura 2, podemos ver que o local de recuperação de desastres foi implantado em uma zona de disponibilidade dedicada na mesma região, buscando, por um lado, minimizar os custos de replicação e transferência de dados e, por outro lado, ter baixa latência entre os sites primário e o secundário (normalmente na ordem de 1 a 2 milisegundos), permitindo o uso de um esquema de replicação síncrona para o mecanismo de banco de dados.

Dessa forma, a arquitetura permite um equilíbrio entre tempos de recuperação de desastres (RPO tendendo a zero, RTO baixo) e custos, graças ao fato de que apenas 1 servidor do tipo t2 precisava ser implantado no site secundário de recuperação de desastres com os volumes de armazenamento das instâncias do aplicativo (sem implantar o plano de computação, que é apenas ativado em contingência) e uma instância para o banco de dados HANA de ¼ do tamanho do original de produção (e, portanto, ¼ do custo desse componente).

Os ambientes foram migrados seguindo um esquema concorrente detalhado na figura 3:

Fig. 3: plano de alto nível. Aqui podemos ver o trabalho paralelo das diferentes trilhas de migração, buscando concluir a implementação do ambiente produtivo antes do prazo contratual.

Como podemos ver neste diagrama, o trabalho de implementação começou com um ambiente PILOTO, que tem características semelhantes ao ambiente de produção (PROD). Nele, todas as configurações iniciais, testes, treinamentos foram realizados, culminando com dois testes finais de ponta a ponta para aplicar os mecanismos de contingência frente a desastres (por meio de atividades de simulação ou gamedays). Nelas, as transações eram executadas nas instâncias de contingência e, após o retorno para o site principal, também foi validado que as alterações feitas na contingência foram replicadas corretamente. Ao longo desse processo, pudemos fazer os ajustes necessários nos procedimentos (playbooks), documentando os tempos de referência obtidos nesses processos e disponibilizando-os para a empresa no caso de uma possível solicitação de auditoria. O processo de validação também ajudou a identificar as equipes que deveriam ser envolvidas durante uma contingência e a identificar as ações exigidas por cada uma.

Além disso, e embora não esteja incluído neste plano, pois era um projeto paralelo, enquanto os ambientes subsequentes (DEV, QA, PREPROD) estavam sendo implantados, pudemos usar esse ambiente PILOTO para o projeto de atualização de Support Packages, que foi executado paralelamente ao projeto de migração. Esse segundo projeto, que não teve problemas, nos permitiu chegar na AWS com o SAP atualizado.

Esse processo de implementação — que começou nos últimos dias de dezembro de 2020 — foi concluído na segunda semana de fevereiro de 2021, ou seja, uma semana antes do previsto. Isso significava que a empresa não precisava renovar o contrato de manutenção da infraestrutura SAP original, substituindo-a por um esquema mais favorável aos negócios.

Resultados

A migração bem-sucedida dos ambientes SAP do grupo resultou em uma redução de 60% nos custos totais de manutenção em um período de 3 anos, graças à combinação de um esquema de contratação flexível combinado com os programas que a AWS tem para migrar cargas de trabalho baseadas em SAP. Além disso, o esquema de continuidade de negócios foi aprimorado com a adoção de uma arquitetura “pilot light”, alcançando um bom equilíbrio entre custos e benefícios (RPO tendendo a zero, RTO baixo), controle total e visibilidade para a equipe da Sancor sobre nossa plataforma SAP. Por fim, durante os projetos de migração e atualização de pacotes de suporte, pudemos experimentar a agilidade do provisionamento de novos ambientes, que passou de quase um mês na plataforma anterior para horas no novo esquema.

Próximos passos

A implementação dessa arquitetura híbrida combinada com recursos de governança permitirá que a próxima etapa de implementação de novas funcionalidades para o projeto de evolução SAP (estágio 3 do projeto) seja abordada com maior agilidade e previsibilidade para os negócios da empresa.