Stress Testing como Servio Um conto de Natal

Stress Testing como Serviço Um conto de Natal no Twitter @ herval

Twitter? ”O microfone das massas" �� Tráfego sempre crescente �� Picos imprevisíveis

Castle in the Sky, 2011 8 k Tweets/segundo A palavra mágica ”balse” é utilizada para destruir o castelo inimigo. https: //www. wired. com/2014/09/how-twitter-handles-traffic-from-the-japanese-who-tweet-like-no-one-else/

© Alex Norris http: //webcomicname. com/

Ano Novo no Japão, 2012 16 k Tweets/segundo Tweetar "happy new year!" exatamente à meia noite é um ritual de boa sorte https: //www. wired. com/2014/09/how-twitter-handles-traffic-from-the-japanese-who-tweet-like-no-one-else/

Brasil x Alemanha, 2014 35 m tweets durante a partida 30 k Tweets/segundo durante cada um dos 7 gols https: //www. theguardian. com/technology/2014/jul/15/twitter-world-cup-tweets-germany-brazil

Goooooolllll

Sobre mim @herval Insights & Reliability • 2 anos no Twitter • Fundador de startups (3 x), Sound. Cloud, Pivotal Labs • Um cachorro, uma esposa, uma dezena de teclados mecânicos Desenvolvendo ferramenta para reduzir os momentos de ”oh no”

"Embracing Failure 24/7" (2016) Quebre seu sistema, ou alguém o quebrará por você • Como descobrir os elos fracos? • Como convencer outros times a testá-los? • Como automatizar tudo isso https: //www. wired. com/brandlab/2017/10/juniper-mazdak-hashemi/

Boas notícias! Alguns picos são previsíveis • • Copa do Mundo Super Bowl Oscars Ano Novo Outros são imprevisíveis, mais planejáveis Ø Padrão de tráfego em Redes Sociais: breaking news e/ou memes Descubra seus padrões!

Tráfego de "Breaking News" Instantâneo, imediato e breve Ø Difícil de reagir, mesmo com auto-scaling (escalar instâncias de AWS suficentes é mais demorado que o pico!) Ø Falhas súbitas Ø Prealocar infra para estes cenários o tempo todo é caro e ineficiente

The "meme" traffic Menor amplitude, maior duração Ø Cenário ideal para autoscaling Ø Leva a implosões em câmera lenta (serviço A fica sem memória aos poucos, serviço B acumula logs em disco, etc)

O que testar

Antes de mais nada. . .

S. R. E. Práticas de Resiliência são prerequisito para stress testing https: //landing. google. com/sre/book/chapters/part 3. html Ø Ø Logs centralizados Monitoria Resposta a incidentes Postmortems

A pirâmide de testes de resiliência Omni Testing Full service Stress Testing Redline Testing E 2 E

Bikeshedding ���� �� Stress testing Ø Conjunto pequeno de API, cargas e duração predeterminados �� Redline testing Ø Teste de serviços individuais até o ponto de quebra (e medição de resultados) �� Omni testing Ø Simulação de carga completa por uma duração predeterminada

Construindo uma base de testes Um cenário histórico que provavelmente se repetirá ü ü ü "Tweets com imagens" Retweet storms ”FELIZ ANO NOVO!!!!!ONZE!1111!!!” cat (logs) → grep (APIs a serem testadas) → sed (ids de usuários) → �� (não tão simples com 1 PB de logs)

Construindo uma base de testes Gere um histograma de chamadas de API, escolha as top 10 • • • Recalcule frequentemente, à medida que padrões de tráfego mude Não sobre-teste serviços menores/secundários Sanitize parâmetros (substitua ids de usuário, produtos, etc, por dados falsos) Construa uma base de usuários representativa • Construa um ”grafo social” • De longe a parte mais difícil (maioria das bases de teste são montadas à mão/não representativas )

Construindo uma base de testes Automação ü ü Um job constantemente computando as 10 APIs mais utilizadas em um dataset Hadoop Um job constantemente mantendo uma base de milhões de ”fake users” (e seus relacionamentos)

Construindo uma base de testes Typed. Pipe. from(Most. Recent. Http. Log(date. Range)). filter { log => log. method == "GET" && !exclusion. List. contains(log. path) }. map { log => log. path }. group. size. sort. to. Typed. Pipe. write(Typed. Tsv(s"top_apis_${date. Range}")

Sobre "fake users". . . Tenha muito cuidado para não afetar seus usuários reais Introduza o conceito de usuários de teste em sua infraestrutura • • Interações isoladas (usuários reais nunca vêem usuários de teste) Usuários de teste não afetam métricas de negócio, não processam pagamentos, etc Solução simples: HTTP Header para”ativar” usuários de teste Muito difícil de implementar em uma selva de microserviços Ø Comece com APIs de leitura APIs destrutivas somente após ter segurança no framework) (inclua

Sobre "fake users". . . Tenha muito cuidado para não afetar seus usuários reais

Execução

Staging x produção Ambientes de teste não são necessariamente uma boa ideia • Twitter, Google, Netflix, etc infra muito grande e fragmentada • Stress testing em ambiente de testes não detecta bottlenecks de produção

Gerando carga Executando um conjunto de testes ü Deploy dos geradores de carga em um DC/zona externo ao teste ü Carga dos cenários de teste ü Coleta de métricas e resultados Replay the traffic logs you generated Ø Centenas de RPS: Uma instância lendo requests de um CSV protótipo Ø Milhares de RPS: múltiplas instâncias, eventos em uma fila V 1 Ø Milhões de RPS: múltiplas instâncias, múltiplas zonas, múltiplas filas V 2

Load Generators Execution Coordinator Target Systems Target APIs Stats collector Test Loads Load Generation DCs/Zones Service Metrics Queue DC/Zone under test

Gerando carga // Make 1000 HTTP requests at a roughly constant rate of 10/sec val client = Client. Builder(). codec(http()). hosts("twitter. com: 80"). build() val transport = new Finagle. Transport(Finagle. Service(client)) val consumer = new Request. Consumer(() => new Poission. Process(10) // add 1000 requests to the queue for (i <- (1 to 1000)) { consumer. offer(new Parrot. Request(uri= Uri("/jack/status/20", Nil)) } // start sending transport. start() consumer. start() // wait for the consumer to exhaust the queue while(consumer. size > 0) { Thread. sleep(100) } // shutdown consumer. shutdown() transport. close() https: //github. com/twitter/iago (Scala) https: //github. com/tsenart/vegeta (Golang) https: //jmeter. apache. org/ (Java)

Monitorando

COLETE TODAS AS METRICAS!!!! Métricas em tempo real: circuit break e finalização Armazenamento de métricas em longo prazo: postmortems & planejamento

Ferramentas de monitoramento & métricas

Ferramentas de monitoramento & métricas

IMPORTANTE: abortando testes Mantenha um botão de emergência (não necessariamente um botão de verdade) Abortando tráfego rapidamente �� V 1: de-scheduling jobs Mesos ~1 -5 minutos → downtime �� V 2: controle em nível de DNS (Zookeeper) → freio de emergência em milisegundos https: //github. com/herval/groundcontrol

IMPORTANTE: abortando testes https: //zookeeper. apache. org/

IMPORTANTE: abortando testes import com. twitter. zookeeper. Zoo. Keeper. Client import org. apache. zookeeper. Create. Mode val zk = new Zoo. Keeper. Client("zookeeper. local: 2181") zk. create("/test_deadbeef_circuit_break", "ok". get. Bytes, Create. Mode. PERSISTENT) zk. watch. Node("/test_deadbeef_circuit_break", { (data : Option[Array[Byte]]) => data match { case Some(d) => if new String(d) == "abort" { test. Service. abort() } case None => println("Test is done") } }) https: //zookeeper. apache. org/

Planejamento

O plano de teste Stress Testing adequado é disruptivo Comunicação é a chave �� • • Evite confusão entre times Previna intervenção humana durante testes Timing é fundamental � • • • Teste muito próximo a grandes eventos = surpresas (sem tempo para correções) Teste muito distante = surpresas (muitas mudanças/regressões) Testes menores e regulares + agenda de eventos = WIN

O plano de teste Ø Obtenha autorização dos operadores de serviços e estabeleça alvos Ø Mantenha um calendário único (V 1: um Google Doc!) Construa confiança antes de construir software

O plano de teste Ø Comunique testes à medida que eles ocorrerem (e seus resultados) Ø Auxilie os times impactados a detectar e corrigir gargalos Construa confiança antes de construir software

yeah!

Aprendizados de arquitetura Sistemas degradáveis absorvem picos (feature degradation, feature toggles, circuit breaks) Sistema auto-corretivos previnem degradação lenta (auto-scaling, self-monitoring)

Resultados Ano Novo Japonês (2015): sem incidentes Ano Novo Japonês (2016): sem incidentes Ano Novo Japonês (2017): sem incidentes Copa do Mundo (2018): ������

Agradecimentos especiais aos membros (atuais e passados) do time de Continouous Reliability Testing (CRT) - Ali Alzabarah Esteban Kuber Kyle Laplante Mazdak Hashemi Niranjan Baiju Pascal Borghino Ramya Krishnan Steve Salevan E a todos os heróis de SRE que salvam o dia – todos os dias.

Obrigado! �� ♂� @herval