Web APIs e delivery Matando a fome de 1 milhão de pedidos mensais no Tiago Dolphine
Tiago Dolphine...
Online Delivery Restaurant receives the order Customer search for restaurants APIs Order food from App or Web Confirms the order and prepare Back office operators
4
5
Elasticidade para delivery Almoço Jantar
Elasticidade para delivery Almoço + Jantar Campanhas de Marketing : push app, comerciais, jogos de futebol...
Primeiras APIs Mobile App SOAP/WSDL
28k 14k 2011 2012 11
Web APIs e REST (WS CORE) Padronizar comunicação Centralizar regras de negócio Modelo de dados padronizado API Credential (permissões) SDK para uso das APIs Rapidez na inserção de features Deploy facilitado
API recepção de pedidos Foco bem específico Acesso por restaurantes Polling Confirmação de pedido Otimização e Caching Acesso ao DB
APIs públicas Integrações (3rd party) Restaurantes Cardápios Clientes Pedidos Controle de acesso Conquista de novos parceiros e negócios
Começam os problemas... Gargalos e load elevado Busca de endereços Processamento síncrono Jobs e processamentos em background Muito acesso ao DB Comprometimento do sistema no lançamento de novas features
Como solucionamos problema com demora na busca de endereços?
~4x mais rapido Alívio de queries ao DB WS Job para indexar Endereços e CEPs Base relacional própria com mapeamento de endereços
Como solucionamos o impacto de novas features em produção?
Feature Toggles Novas funcionalidades em produção Rapidez e segurança para publicação Validação controlada, no mundo real Comparação de cenários Chaveamento automático http://martinfowler.com/articles/feature-toggles.html
Como reduzimos excesso de processamento e tempo de resposta nas APIs?
Event-driven messaging Redução de processamento síncrono com menos orquestração e mais coreografia Alguns cenários: Envio de emails Notificações Cancelamentos Captura de pagamentos Analytics
Events-driven messaging
O que ganhamos? Alivio de processamento na aplicação Deploy independente Pontos de falha mais isolados Escala com a demanda
AWS
Aplicações A Afunilamento no banco de dados
Aplicações e serviços Cache Local A Afunilamento no banco de dados
Aplicações e serviços Cache Local A Afunilamento no banco de dados Read Only
Caching In-Memory => rápido Redução de queries Respostas mais rápidas das APIs Maior throughput por instância Planejamento de TTL com a regra de negócio
~800 k 450 k 108 k 14k 2011 28k 2013 201 201 29
800k 450k 108k 14k 2011 28k 2013 2014 2015 30
Mais problemas surgem com o crescimento... Número de acessos +++ Acúmulo de threads Tempo de resposta comprometido Alto consumo de memória + muito GC Muito load em momentos de pico Pontos de concorrência entre instâncias
Microservices daqui a pouco.
Lock Distribuído Permitir que apenas um processo/thread em um sistema distribuído acesse determinado recurso. Instance1 Instance5 Get/Set Lock Release Lock Lock TTL Instance2 Instance4 Instance3
Cache Distribuído Aumento do uso de cache Melhorias de estratégia de caching Alívio de memoria na aplicação Compartilhamento de refresh do cache Dependência total do cache Disponibilidade + Alta perfomance
Migrando para Aerospike Testes e validação Abstração de caching nas aplicações Criação de cluster Monitoramento Testes de failover Atualmente ~15k hits/s 3GB consumo
Migrando para Microservices Deploy segmentado Falhas isoladas Escalar pontos necessários Segmentar Database (DB per Service) Tecnologías específicas para cada problema Times menores
Times especializados Mais focados nos requisitos Conhecem profundamente o serviço Tecnologias específicas Melhor gerenciamento Responsabilidade pelos deploys
Estratégia inicial para microservices Encontrar os maiores problemas Delimitando escopos (bounded contexts) Padronização e stack Definir tecnologias especificas Mudança de paradigmas (chamadas remotas) Falha inevitável Preferir coreografia
Autenticação Centralizada Padrão de autenticação entre microservices Spring Security OAuth2 Authorization Server Applications: OAuth2 SDK Client: fácil uso respeitando fluxo OAuth2 Authorization: Bearer 8ba887c0-90d8-423f-99d3-ce878e48d3e7
BFF Backends for Frontends Restaurant Auxilia no processo de migração BFF Order Sem alteração no Frontend API se mantém constante Backend pode ser alterado conforme evolução dos Microservices Reduz chamadas remotas entre clientes externos/server http://samnewman.io/patterns/architectural/bff/ Account
Um pouco do que estamos usando... (Boot, MVC, Cache, Messaging, Data, Actuator, OAuth2...)
DevOps... Continuous Integration Continuous Deployment Orchestrated deploy process Quick Releases Service per host Chef AWS Auto scaling
CI / CD Process Get deploy artifact Deploy Artifact Get Instances Au tos Sync Repository g lin ca Orchestrated deploy Libs Applications
Monitoramento! Alertas Logs Centralizados
Monitoramento 48
Problemas encontrados e aprendizados: CI/CD necessário! Plano de rollback Time precisa estar envolvido em todo processo Log não centralizados Controle de versões entre serviços Desenvolvimento e testes com sistemas distribuídos Identificação de bugs em produção Pontos concorrência: necessário distributed lock! http://martinfowler.com/articles/microservice-trade-offs.html
Cuidado!
Monolith First http://martinfowler.com/bliki/monolithfirst.html
Hoje! 2016 1.4 milhões++ / mês
Orders Payments Restaurants Locations Menu Accounts Microservices
Tiago Dolphine tiagodolphine@gmail.com /tiagodolphine /tiagodolphine /tiagodolphine
Further Reading http://martinfowler.com/articles/feature-toggles.html http://samnewman.io/patterns/architectural/bff/ http://martinfowler.com/articles/dont-start-monolith.html https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html http://martinfowler.com/articles/microservice-trade-offs.html