QCon 2016 - Como migramos uma solução de 4 milhões de usuários para o Azure
Transferir como PPTX, PDF0 gostou605 visualizações
O documento aborda a migração da Secretaria Escolar Digital (SED), que possui 4 milhões de usuários, para a nuvem com Azure e .NET, enfatizando soluções de PaaS e IaaS. Ele detalha o cenário de missão crítica, tecnologias utilizadas, desafios enfrentados, e o processo de migração, que incluiu reescrita de queries e otimização de performance. Além disso, discute a implementação de arquitetura no Azure com escalabilidade e balanceamento de carga.
QCon 2016 - Como migramos uma solução de 4 milhões de usuários para o Azure
- 1. Levando uma aplicação com 4 milhões de usuários para a nuvem com Azure e .NET Fabrício Sanchez (@sanchezfabricio) Senior Technical Evangelist – Microsoft
- 2. It’s all about apps to the cloud
- 3. Transforming the Application Landscape Loosely Coupled Services Many Small Servers ~2000 Today Monolithic Big Servers Slow changing Rapidly updated
- 4. The New Challenge of Distributed Apps 4 Virtual machines Server Public Cloud Disaster Recovery Developer Laptop Server Cluster Data Center Static Website Web Front EndBackground Workers User DB Analytics DB Queue API Endpoint Development Test & QA Production Scale Out
- 5. Cenários-base de migrações Desenvolvimento de novas soluções (born to the cloud) Planejamento de novas soluções para a nuvem. Migração de soluções para PaaS Migração de soluções para os serviços de plataforma do Azure. Migração de soluções para IaaS Soluções que precisam ser migradas para IaaS apenas. Migração de soluções híbridas/mistas Migração de soluções para um modelo híbrido – public and private (IaaS com PaaS).
- 6. PaaS, IaaS, misto ou híbrido? DEPENDEPerguntas que podem ajudar 1. É uma solução nova ou já existente? 2. Qual é a tecnologia base da solução? .NET? PHP? Java? Pyton? 3. Roda atualmente em Linux ou Windows? 4. Possui muitas customizações de ambiente? 5. O banco de dados, roda em servidor dedicado ou compartilhado? Possui customizações de ambiente? 6. Banco de dados: SQL? Oracle? MySQL? 7. Existe a necessidade de IP fixo na solução? 8. Serviços. Soap? REST? Precisam ser escaláveis? 9. IOPS de disco. Qual a importância para a natureza da aplicação? 10. Banco de dados: são múltiplos ou apenas 1? 11. Armanzenamento de arquivos: como é feito? Precisa ser SSD? 12. Deployment. Como será feito? 13. Usa recursos adicionais como: SOLR, NGINX, etc? 14. Necessita de segmentações de rede? 15. Qual o esforço de engenharia disponível para o projeto? 16. Usa SMS, Email, etc.? Precisa de domínio personalizado?
- 7. Secretaria Escolar Digital (SED) A Secretaria Escolar Digital (SED) é uma plataforma on- line criada para centralizar, agilizar e facilitar todas as operações que envolvem a gestão diária da administração escolar. • 4 milhões de usuários • Utilizado diariamente por mais de 5k escolas • Rotinas para professores, alunos e responsáveis https://sed.educação.sp.gov.br Típico cenário de missão crítica
- 8. Tecnologias base utilizadas no host original • Web • ASP.NET MVC 4 • Web API • WCF • Frameworks web (jQuery, Bootstrap, etc) • Database • Oracle RAC • Host • IIS 7 • Windows Server 2008 R2
- 9. Informações adicionais do host original Oracle RAC • 3 instâncias clusterizadas Cluster de aplicação • 16 instâncias • 8 cores • 16 GB RAM • 250 GB disco
- 10. Principais características técnicas • Operações de banco de dados ad-hock • Database de 4 TB • +5k queries escritas para Oracle RAC • Algumas cargas de dados automatizadas efetuadas por um main frame • Diversas customizações de ambientes • Ampla utlilização de sessions • Gravação de arquivos diretamente no file system • Sem utlilização de cache • Sem scale-up e sem scale-out • Tempo era um limitador: tinhamos apenas 3 meses
- 11. Qual o melhor caminho de migração? Conclusões sobre a aplicação • Boa arquitetura mas muitos ajustes de queries • Com algum esforço de engenharia blobs seriam viáveis • Com algum esforço de engenharia cache seria viável • Aplicação usa recursos customizados do IIS e do SO Conclusões sobre o banco de dados • Migração para SQL Server era premissa • Muitas rotinas de integração com main-frame • Cada schema deveria ser tratado como novo banco • Controle do ambiente necessário PaaS + IaaS IaaS Modelo Misto
- 12. O processo de migração • Oracle RAC -> SQL Server • 2x D14 com AlwaysOn • Reescrita de todas as queries para SQL Server • Query tunning para otimização de performance • Implementação de Redis Cache para persistir sessions e alguns outros ítens • Ajustes da aplicação para gravação em blobs • Implementação de web farm (com VM’s) para host da aplicação web • 8x Standard A4 • API’s publicadas em Web Role com ajustes via Startup Task • Implementação de autoscaling e load balancer (BD e Web Farm) • Implantação do processo de CD/CI para este novo ambiente via VSTS
- 13. Arquitetura no Azure Availability Set (SED-APP) SED01 SED02 SED03 SED04 SED05 SED06 SED07 SED08 SEE-SQL1 (Reader) SEE-SQL2 (Writer) Always On Availability Set (SED-BD) … … … n Cloud Service (SED) Virtual Network Blobs Cache n Microsoft Azure API’s … n
- 14. Visões de ambientes. Antes e depois... Uso de CPU (host original) Banco de dados Uso de CPU Microsoft Azure Fácil crescer horizontalmente e verticalmente...Difícil crescer horizontalmente e verticalmente...
- 15. Visões de ambientes. Antes e depois... Servidores de Aplicação Uso de CPU (host original) Uso de CPU Microsoft Azure Máquinas são ligadas apenas por demanda... Todas as máquinas ligadas 100% do tempo...
- 16. André Costa CIO | Secretaria de Educação do Estado de São Paulo (Seduc)
- 17. Q&A