André Nobre
Mar 14 · 10 min read

Por André Nobre e Fernando Silva


Para qualquer área de tecnologia em varejo, a black friday é sempre cercada de grandes emoções. O evento concentra grande parte da meta da companhia para o ano e todo alicerce para este sucesso vem da TI.

Eu falei sobre o evento neste podcast.

O ano de 2018 para nós foi movimentado em números de implantações realizadas. Por todas as evoluções publicadas e as estratégias comercial e de marketing agressivas tínhamos a expectativa de aumento de tráfego significativo para o evento em relação a 2017.

Por estes motivos, decidimos em setembro realizar o transbordo do e-commerce para alguma nuvem pública, garantindo assim sua maior disponibilidade através de escalabilidade infinita, quando necessário, à medida do aumento do tráfego.

Praticamente toda estrutura até aquele momento era executada on-premises.

Sim, decidir isso em setembro foi loucura. Daquelas boas, que a gente gosta de realizar.

Você pode estar se perguntando: “transbordo? Quanto de antipattern tem aí?”

É importante destacar que a decisão do transbordo faz parte de um programa de migração para cloud maior. Uma outra fase deste programa é a modernização das aplicações, em um plano de cloud migration extremamente estratégico para a companhia.

Para conseguir concretizar este plano, acionamos nosso principal fornecedor de cloud, a Microsoft, para que fizéssemos juntos um plano de configuração e transbordo para a Azure.

Para entrar no detalhe, preciso passar pra vocês o nosso cenário histórico: temos um conjunto de aplicações que vem desde 2009 / 2010 conosco; um legado monólito de difícil migração, alto custo, que exige grande recurso computacional independente de sazonalidade.

A arquitetura macro as-is pode ser exemplificada como abaixo:

Arquitetura macro as-is

Em nossas reuniões estratégicas para definição do transbordo, entramos em discussões de abordagem. As opções eram:

  1. Realizar o transbordo completo do e-commerce
  2. Realizar o transbordo priorizando os maiores locais de tráfego
  3. Modernizar a aplicação para realizar o transbordo

O ponto mais crítico para decisão era o tempo versus valor gerado pelo transbordo. Apesar de mais desejado, não havia tempo hábil para modernização das aplicações. Normalmente realizamos o freezing para a black friday em meados de outubro para novembro. Ao todo eram no máximo 8 semanas de trabalho para qualquer geração de valor.

Realizar o transbordo completo do e-commerce poderia ser impossível por conta do tempo e por conta da arquitetura do e-commerce, devido ao alto acoplamento com o back-office.

Já sob a ótica de volume de tráfego, o que chamamos de “vitrine” concentra 85% do volume. Este era nosso maior foco: se realizarmos o transbordo da vitrine, além de “aliviar” a estrutura on-premises em caso de “surpresa”, garantimos uma melhor experiência ao nosso cliente.

Optamos então pela segunda abordagem: transbordo dos locais com maior concentração de tráfego durante o evento.

Traçamos portanto a meta:

Realizar o transbordo da vitrine do e-commerce para a cloud, com pelo menos 20% do tráfego sempre ativo, possibilitando um aumento para 100% caso necessário.

Arquitetura to-be

Com o levantamento detalhado do as-is e conhecido por todos no time, partimos para a discussão do to-be.

Nossa estratégia técnica estava clara neste momento: rehost das aplicações no Azure com as devidas alterações em configuração para contemplar o novo ambiente.

Primeiro desafio: devemos direcionar o tráfego ora para um data center ora para outro, dependendo dos critérios de qualidade de entrega de cada um, podendo ser pilotado por nós a qualquer momento.

A distribuição do trafego era realizada pela Akamai, configurado pelo GTM (Global Traffic Manager) deles.

GTM — Balanceador de carga de alta disponibilidade com capacidade de respostas as solicitações dos usuário online, tolerante a falhas, toma decisões de roteamento baseado na saúde do data center em tempo real.

Arquitetura macro to-be

Segundo desafio: sendo transbordo, como manter estruturas consideravelmente grandes nos dois locais?

Como visto na arquitetura as-is, temos grandes deployments de MongoDB, Apache Solr e Microsoft SQL Server. Dado que estes recursos continuarão on-premises e passarão a ter instâncias na nuvem, como realizar o sincronismo entre os nós?

É importante ressaltar que em 2017, portanto um ano antes do transbordo, contratamos o ExpressRoute. Um desafio a menos na conectividade da Azure com nosso data center.

  1. MongoDB

Nossa estratégia para o MongoDB se resumiu a manter a escrita no nó primário on-premises e estender os nós secundários (que usamos para leitura preferencialmente) também na cloud:

Replicação MongoDB on-prem e cloud

Porém, as consultas dos dados no MongoDB em alguns momentos eram atendidas por nodes on-premises e em outros pelos nodes da Azure. Isso se dava ao fato que sua configuração de readPreference estava como secondaryPreferred, ficando difícil direcionar as consultar nesses ambientes.

Então em algumas situações requests recebidos pela aplicação on-premises estavam indo para o MongoDB no Azure (e vice-versa).

Nos testes iniciais identificamos um trafego de dados muito grande passando neste link, quase 50% de toda sua capacidade, e ainda não estávamos com o mesmo volume da Black Friday.

Para reduzir o tráfego e melhorar a performance das aplicações, tagueamos os nodes do MongoDB com a informação do data center. Desta maneira as aplicações realizariam consultas em seu próprio ambiente, on-premises ou cloud. Requests recebidos por um data center consumiriam recursos exclusivos deste data center, evitando assim o consumo desnecessário do ExpressRoute.

Mongodb tagueado nos ambientes cloud e on-premises

2. Solr

Para o Solr tínhamos 15 nodes na cloud e 15 on-premises, e a sincronização entre os ambientes era realizado através dos nós master. O master da cloud ficava como responsável por sincronizar os dados entre os slaves de seu ambiente, com isso evitaríamos dados redundantes passando pelo ExpressRoute.

Replicação Solr entre os ambientes cloud e on-premises

3. SQL Server

Para o SQL Server tínhamos um listener fazendo o load entre as réplicas de escrita e leitura, já no azure uma réplica de leitura com conexão direta.

Replicação Sql Server para os ambientes cloud e on-premise

Todo deploy foi realizado pelo Microsoft Release Management, ferramenta que já usamos em nossas aplicações, porém criamos dois step de deploy, um para o código, já que era o mesmo em ambos ambientes e um para os configs, já que cada um tinha sua particularidade.

Todo a criação do ambiente cloud foi realizado com automação e para isso usamos Ansible e Arm template, assim se no evento precisássemos subir algumas maquinas adicionais, poderíamos fazer isso em pouco segundos.

Terceiro desafio: como balancear o tráfego com a mesma performance que o F5 BigIP interno?

Nossa primeira tentativa foi partir para application gateway, um balanceador de camada 7 (L7) do Azure, onde poderíamos aproveitar algumas regras aplicadas no BigIP (on-premises) e manter a compatibilidade completa dos ambientes.

Ao implantarmos, realizamos os primeiros testes de performance. No nosso caso, o application gateway adicionou um overhead de alguns milissegundos a mais aos requests, em comparação com nosso on-premises. Este cenário poderia impactar nossa performance geral no dia do evento.

Revisamos as regras aplicadas ao BigIP on-premises e ao application gateway, optando por ir com load balancers de camada 4 (L4) na nuvem. Conseguimos então atingir a performance esperada.

Figrua 6— Load Balancer

Tivemos duas camadas de Load Balance, um com IP externo para a Akamai, fazendo Health Probe para as aplicações de site, como por exemplo a Vitrine, e um balance interno fazendo uso das Apis que os sites chamam.

Sem o Application Gateway perdemos alguma recursos como Terminação SSL, Firewall, afinidade de sessão baseada em cookie e o modo de balance Round Robin, porém alguns desses recursos relacionados principalmente a segurança já usufruímos com a utilização do Akamai.

Quarto desafio: como monitorar os recursos na Azure da mesma maneira e com os mesmos procedimentos já estabelecidos na companhia?

Nossa principal ferramenta de APM para as aplicações locais é o Dynatrace Appmon. Obviamente para o ambiente Cloud seria um grande acelerador também utilizar a mesma estrutura ao invés do Application Insights, que nessa altura já tínhamos pouco tempo para a curva de aprendizado.

Uma outra opção adicional ao Dynatrace Appmon é a versão Managed.

Dynatrace Managed tem algumas particularidades como o formato de licença, monitoramento dos principais componentes do Azure (virtual machines, virtual machine scale-sets, app services, azure SQL, redis cache, API management service, load balance, storage e service bus. Como usaríamos alguns desses componentes, optamos por ele.

No decorrer dos testes, vimos que as métricas coletadas não estavam compatíveis com a nossa estratégia de teste. Afim de não termos surpresa para o grande evento, resolvemos utilizar o que já sabemos de melhor, Dynatrace Appmon versão 7.1 instalando os agentes nas VMs do Azure. Com isso teríamos a mesma monitoria, em todos os níveis, que temos hoje on-premises.

Ah! nossas aplicações são em .NET para o e-commerce.

Dynatrace Appmon

Para o MongoDB utilizamos a mesma ferramenta que já usamos on-premise, assim teríamos métricas de leituras, escritas, volume de replicação, oplog, etc.

Monitoria do MongoDB

Para o ExpressRoute utilizamos métricas disponíveis pelo Azure, assim monitoramos em tempo real BitsIn e BitsOut.

Figura 9— Métricas ExpressRoute

Com ajuda do time da Microsoft criamos algumas métricas adicionais das nossas principais aplicações, como request por segundo, filas de request e informações de compute (processamento e mémoria):

Métricas Vitrine e Api de Preço

Após configurar todo o ambiente do Azure, precisaríamos fazer alguns testes funcionais durante todo o dia e a algumas noites.

E não há melhor maneira de testar algo que não em produção, certo? :) (Alias, este é um belo assunto para um próximo post)

Direcionamos pequenos tráfegos para a cloud através do GTM da Akamai, geralmente algo até 5%. Obviamente toda a equipe estava a postos, com comunicados internos avisando sobre o novo direcionamento de tráfego. Outro motivo para esta abordagem era “testar” os procedimentos de administração do GTM, entender o tempo de resposta da mudança de tráfego, etc.

Após testes funcionais realizados com sucesso, tínhamos que ter certeza se estávamos preparados para o grande evento. Não podemos deixar de mencionar as várias noites de testes, várias noites sem dormir, além do mais o único horário disponível onde poderíamos estressar todos nossos sites, apps, APIs e banco de dados era de madrugada. O empenho do time foi fundamental, tínhamos toda esquipe dedicada trabalhando durante o dia e noite.

Para os testes de performance usamos BlazeMeter com scripts em jmeter, obtendo métricas em tempo real:

Testes BlazeMeter

Nosso resultado final da arquitetura macro to-be ficou assim:

Figura 11- Visão macro to-be híbrida

Afinal, como foi durante a Black Friday?

Como de costume nos últimos 5 anos, iniciamos o evento na quinta-feira. Normalmente chegamos cedo e acompanhamos a evolução dos acessos durante o dia.

No caso do nosso transbordo, começamos com os 20% de carga:

Figura 12— Visão de uma configuração de GTM para algumas properties das Casas Bahia

No monitoramento dos recursos na nuvem, tudo tranquilo.

Por volta das 20h o fluxo começou a aumentar consideravelmente e tivemos alguns imprevistos na nossa estrutura on-premises.

Resultado: jogamos 90% do tráfego das vitrines das três bandeiras para o Azure.

Obviamente ficamos apreensivos com esta situação. Criamos toda a estrutura, testamos e colocamos pra rodar esperando uma execução mais “conservadora”. De repente todo o tráfego do maior pico do evento seria enviado para o Azure.

Fomos assim praticamente o resto do evento, até domingo, indo para 100% muitas vezes.

Transbordo realizado com sucesso!

Lições aprendidas

Sobre a condução da iniciativa e envolvimento de stakeholders

Estruturamos um time dedicado para realizar todos os esforços de migração e configuração. E que time!

Enfrentamos desafios em garantir que outras iniciativas rodando em paralelo estavam aderentes ao que este time definia como padrão ou diretriz. Talvez hoje faríamos diferente: toda migração para cloud deve ser suportada pela empresa toda — ou minimamente pela TI toda.

https://azure.microsoft.com/en-us/migration/get-started/

Nosso time multidisciplinar foi composto por:

  1. Engenheiros de Software
  2. Agile Coach
  3. Especialista em monitoramento
  4. Arquitetos de Infraestrutura
  5. Arquitetos Cloud Microsoft
  6. Arquiteto de Dados
  7. Especialista em testes de carga

Sobre a participação da Microsoft

A Microsoft esteve conosco em todos os momentos, dedicando arquitetos full-time para todas as atividades, inclusive em algumas madrugadas de testes.

Auxiliaram também na questão orçamentária e investimentos próprios para entregarmos o resultado final de sucesso.

Capacitação das equipes envolvidas

A migração foi extremamente importante para incluirmos o assunto cloud oficialmente no radar da empresa. Por mais que este assunto já permeava algumas equipes, temos centenas de profissionais envolvidos no desenvolvimento e operação.

Toda estratégia de cloud, independente do tipo, deve exigir capacitação desde o início. Treinamentos formais, informais, hackatons e programas de certificação devem estar no roadmap da iniciativa.

Custo

Sabíamos desde o início que o custo seria relativamente alto. Toda migração de aplicações que não estão preparadas para cloud normalmente carregam junto anti-padrões que oneram no orçamento final.

De qualquer maneira, o resultado final obtido de performance e entrega de valor justificou o investimento.

Conclusão

Criamos nossa estratégia de migração para cloud e acreditamos que este passo foi fundamental para a disseminação da cultura internamente.

Não é fácil migrar uma empresa com um legado de décadas. O processo deve ser conduzido cuidadosamente para que tenha sucesso pensado no longo prazo.

Comprovamos mais uma vez que contar com os talentos internos e com parceria sólida com nossos fornecedores geram resultados incríveis.

Agora é continuar com a modernização para escrever mais um post pós-black friday 2019 de sucesso!

Abraços!

Fotos:

Via Varejo: Tecnologia

Compartilhando um pouco do dia-a-dia da área de tecnologia de uma das maiores varejistas do Brasil.

Thanks to Fernando Silva

André Nobre

Written by

Head of architecture @ Via Varejo

Via Varejo: Tecnologia

Compartilhando um pouco do dia-a-dia da área de tecnologia de uma das maiores varejistas do Brasil.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade