Baixado 59 vezes
Carregado porAmazon Web Services LATAM
Deep dive com Microserviços e Docker
O documento apresenta uma profundidade na arquitetura de microserviços e uso de Docker na nuvem da Amazon, com foco em práticas como alocação de tarefas e escalabilidade usando o Amazon ECS. São discutidos conceitos essenciais, como modularidade, separação de preocupações e a abordagem do twelve-factor app, além de um estudo de caso do Nubank. O conteúdo também cobre gestão de infraestrutura, implantação contínua e práticas de operação automatizada.
Mais conteúdo relacionado
Semelhante a Deep dive com Microserviços e Docker
![[DTC21] Thiago Lima - Do Zero ao 100 no Mundo de Microservices](https://cdn.slidesharecdn.com/ss_thumbnails/0a100microservies-210317154040-thumbnail.jpg?width=640&height=640&fit=bounds)
Deep dive com Microserviços e Docker
- 1. © 2016, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Luiz Coutinho, Professional Services Max Miorim, Nubank Junho 2017 Deep Dive em Microserviços e Docker
- 2. What to Expectfrom the Session • Arquitetura de microserviços • Alocação de tarefas • Amazon ECS • Aplicação do Twelve-Factor App com Amazon ECS • Case Nubank --- Max Miorim O que esperar da Sessão:
- 3.
- 4. O que sãomicroserviços? “Um estilo de arquitetura de software onde aplicações complexas são divididadas em partes pequenas e independentes, comunicando-se entre si usando APIs de linguagem agnóstica. Esses serviços são pequenos, altamente desacoplados e focados em executar tarefas pequenas, facilitando uma aproximação modular na construção do sistema.” – Martin Fowler
- 5. O que sãomicroserviços – Aproximação prática Separação das preocupações Modularidade, encapsulamento Escalabilidade Escalabilidade horizontal Separação de tipos de tarefas Virtualização e Elasticidade Operação automatizada Provisionamento on-demand
- 6. Propriedades da Arquiteturade Microserviços Faz uma coisa bem Independente Descentralizada Caixa preta Poliglota Você fez, você cuida
- 7. Monolítico vs. Microserviços webserver .package Interface Ordem ServiçoOrdem Serviço Inventário Serviço Entrega Interface Ordem Serviço Inventário Serviço Ordem Serviço Entrega
- 8. Comunicação entre serviços •Latência de rede • Congestionamento ou falha em algum serviço • Erro na lógica ou processo de escalabilidade Erro em cascata
- 9. Diagrama Arquitetura demicroserviços
- 10.
- 11. • Media EncodingExperimentation • Digital Watermarking Netflix
- 12.
- 13. Porquê Amazon ECS •Serviço elástico totalmente gerenciado – Você não precisa executar nada e sua arquitetura escala conforme seus microserviços aumentam • Estado compartilhado e distribuição otimista • Integração com o CloudWatch para monitoramento e log • Integração com os serviços Code* para integração e entrega contínua (CI/CD)
- 14. Distribuição de tarefasno ECS – Escolha do Agendador Execução em lotes (tarefas) ECS task scheduler Executa tarefas uma vez Tarefas em lote RunTask (random) StartTask (placed) Aplicações persistentes (serviços) ECS service scheduler Health check Scale-up e scale-down Distribuição por AZ Agrupamento de containers
- 15. Amazon ECS: Underthe Hood ALB ALB AZ 1 AZ 2 user / scheduler
- 16. Exemplo de distribuiçãode tarefas
- 17. g2.2xlarge t2.small t2.microt2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Distribuição: Espalhamento nas AZs
- 18. g2.2xlarge t2.small g2.2xlargeg2.2xlarge Distribuição: Por tipo de instância
- 19. g2.2xlarge t2.small t2.microt2.medium t2.medium t2.small g2.2xlarge t2.small t2.small t2.medium us-east-1aus-east-1d Distribuição: Tipo e AZ das instâncias base
- 20. Definição de gruposde afinidade
- 21. g2.2xlarge t2.small t2.microt2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Distribuição: Afinidade e anti-afinidade
- 22. t2.medium t2.small t2.small us-east-1aus-east-1d t2.mediumt2.micro t2.small us-east-1c Distribuição: Multiplos serviços em um Cluster
- 23. t2.medium g2.2xlarge t2.microt2.small t2.small t2.small g2.2xlarge t2.small t2.small t2.small g2.2xlarge t2.small Distribuição: Serviços – Instâncias Distintas
- 24. Aplicação do Twelve-FactorApp com Amazon ECS Arquiteturas de Referência
- 25. The Twelve-Factor App 1.Base de código 2. Dependências 3. Configuração 4. Serviços de Backup 5. Build, Release, Run 6. Processos 7. Mapeamento de Portas 8. Concorrência 9. Descartabilidade 10. Paridade Dev/Prod 11. Logs 12. Processos admin https://12factor.net/
- 26.
- 27. Exemplo: Arquitetura deMicroserviços com ECS Amazon ECR Amazon RDS Application Load Balancer ECS Cluster ECS Cluster IAM Amazon API Gateway* Amazon Route 53 Amazon CloudWatch
- 28. Escalabilidade Automática Publish metrics AutoScaling ECS service Availability Zone A Availability Zone B TASK A Add/Remove ECS tasks TASK C TASK BScaling Policies Amazon CloudWatch Amazon ECS Application Load Balancer
- 29. IAM Roles paraTarefas ECS Cluster EC2 Instance EC2 Instance TASK A TASK B TASK B Amazon DynamoDB Amazon S3
- 30. Deployment Contínuo AWS CodeCommit AWS CodePipeline AWS CodeBuild Amazon ECR Amazon ECS instance Spot Instance AWS CloudFormation 1.Commit Code 2. Trigger Pipeline 3.Build Artifact 5.Update Stack 6. Update Service 4. Push Image
- 31. Blue-Green Deployments TaskTask Route 53 recordset with weighted routing policy 0% 100%
- 32. Gerenciamento de chavesprivadas •prod.app1.db-pass •general.license-code •prod.app2.user-name ECS Cluster EC2 Instance EC2 Instance TASK A TASK B TASK B EC2 System Manager – Parameter Store
- 33. Service Discovery comRoute 53 e Application Load Balancers (ALB) Application Load Balancer i-aaa i-bbb i-ccc i-aaa i-bbb i-ccc oAuth Target Group 8080 8081 Portal Target Group Weather Target Group 8000 8001 8002 8080 Amazon Route 53 ECS Cluster mydomain.com mydomain.com mydomain.com/weather mydomain.com/auth
- 34. Consumindo eventos paraService Discovery app1-tst 10.1.0.11 db1-tst 10.1.0.14 app2 10.1.0.16 db2 10.1.0.18 my-app 10.1.0.20 websrv1 10.1.0.1 websrv2 10.1.0.2 websrv3 10.1.0.4 app-dev1 10.1.0.9 app-dev2 10.1.0.5 app-dev3 10.1.0.8 db-dev 10.1.0.19
- 35. Governança: AWS ServiceCatalog Organizations Developers Control Standardization Governance Agility Self-service Time to market
- 36. Creates portfolio Adds constraintsand grant access 1 4 5 Administrator Portfolio Users Browse Products 6Launch Products Creates product3Authors template2 Product X Product Y Product Z 7 Deploys stacks Notifications Notifications 8 8 Governança: AWS Service Catalog
- 37.
- 38.
- 39. Max Miorim Microserviços e Dockerno Nubank
- 40.
- 41. Infraestrutura dos serviços 45 Infraestruturados serviços: visão geral • Arquitetura típica de serviços na AWS: •ELBs, ASGs, SGs, IAM Roles, etc • Usamos o CloudFormation sempre que possível
- 42. Infraestrutura dos serviços 46 Infraestruturados serviços: containers • Todos os serviços rodam em containers • Apenas um container de um serviço por instância • Todas instâncias rodam CoreOS Stable
- 43. Infraestrutura dos serviços 47 InfraestruturaImutável • Toda a nossa infraestrutura é imutável • Detalhes em https://sou.nu/infraestrutura-imutavel
- 44.
- 45. Build e deploy 49 NossoCI faz todo o trabalho • Usamos o GoCD, detalhes em https://gocd.io • Cada serviço tem uma pipeline, que faz o build, testa, coloca tags e manda para o quay.io • Assim que publicadas no registry, as imagens são enviadas para um ambiente de teste end-to-end (e2e)
- 46. Build e deploy 50 Blue-greendeployments • Infraestrutura idêntica para blue e green • Ambas versões rodam em paralelo • Se a versão nova está OK, desliga a anterior • Senão, desliga a versão nova e falha a pipeline
- 47.
- 48. Configuração 52 Variável de ambiente •Usamosapenas uma variável, valor é JSON •É a principal fonte de configurações •Geramos no CloudFormation (UserData)
- 49. Configuração 53 Configuração dinâmica •Alguns serviçosprecisam de configuração dinâmica •Chave/valor no DynamoDB ou arquivo no S3 •Carregados pelo próprio serviço periodicamente ou na inicialização
- 50. Configuração 54 Senhas, chaves edados sensíveis •São obtidos pela instância quando o serviço inicia •Um serviço não pode acessar secrets de outro •Valores são persistidos em memória apenas
- 51.
- 52. Debugging e operações 56 Logs •Logsde aplicação são enviados para o Splunk •Logs de inicialização de um serviço são enviados para o STDOUT (motivos históricos) •Usamos o journalctl para ler, quando necessário •Também mandamos exceções para o sentry.io
- 53. Debugging e operações 57 SSH •Em horários de pico (de dias normais), temos cerca de 1000 instâncias rodando •Ferramentas internas facilitam coisas como ssh •Nomes/endereços são previsíveis; automação fácil
- 54. Ah, estamos contratando!https://sou.nu/vagasnu Obrigado!
- 55. Ainda não temo App oficial do AWS Summit São Paulo? http://amzn.to/2rOcsVy Não deixe de avaliar as sessões no app!