GopherConBR 2019: Busca de alta performance com GraphQL e Elasticsearch

13 vezes mais rápido, 50% menos servidores e 30 vezes mais carga. Parece utopia mas não é. Saiba o porquê Go e GraphQL formam uma ótima combinação e como suas características se complementam para uma performance incrível. Entenda como Go ajudou a atingir esse resultado, como é a integração entre Go e Elasticsearch e como estruturar uma API GraphQL utilizando Go. Vamos entrar a fundo nos conceitos do GraphQL, conhecer as alternativas de bibliotecas existentes para GraphQL em Go, entender os seus desafios, limitações e mostrar como contornamos as dificuldades para extrair o melhor dessa combinação.

Transcript

1. Busca de alta performance Busca de alta performance com GraphQL e Elasticsearch com GraphQL e Elasticsearch Guilherme Baptista GopherConBR 2019 1
2. Agenda Agenda O que é performance? Qual problema queremos resolver? Como escolhemos Go? Como trabalhamos com Elasticsearch? Onde entra GraphQL na história? Resultados Re exões 2
3. O que é performance? O que é performance? 3
4. O que é performance? O que é performance? Estrangeirismo predileto na área de T.I. 4
5. Performance Performance em português: Desempenho Desempenho 5
6. Desempenho Desempenho associado com: Velocidade Velocidade 6
7. Velocidade? Velocidade? 7
8. Tempo de resposta: 1 milissegundo 1 milissegundo Servidores: 150 mil dólares por mês; Taxa de erros: 97% das requisições. 8
9. Serviço de alta Serviço de alta performance: performance: Alta velocidade; Baixa taxa de erros; Mínimo custo nanceiro; ... 9
10. Simplificando, Simplificando, vamos associar performance performance com: 10
11. Tempo de resposta Tempo de resposta "Essa página demora quantos segundos para abrir?" Throughput suportado (rpm) Throughput suportado (rpm) "Quantos acessos por minuto esse site aguenta? 11
12. Tempo de resposta Tempo de resposta Por que isso importa? 12
13. O óbvio: O óbvio: Ninguém gosta de site lento. 13
14. Sites que demoram mais que 3 segundos 3 segundos v 80% nunca voltam; 57% desistem do acesso; 50% falam mal para outras pessoas. 14
15. Para cada 100 milissegundos 100 milissegundos a mais no tempo de resposta a Amazon perde -1% de suas vendas. -1% de suas vendas. 15
16. Para cada 1 segundo 1 segundo a menos no tempo de resposta o Walmart ganha +2% de aumento em suas +2% de aumento em suas vendas. vendas. 16
17. Com uma melhoria de 40% 40% no tempo de carregamento de suas páginas o Pinterest conseguiu um aumento de +15% no cadastro de usuários. +15% no cadastro de usuários. 17
18. Para cada 1 segundo 1 segundo a mais no tempo de resposta a BBC perde -10% de seus usuários. -10% de seus usuários. 18
19. Throughput suportado Throughput suportado Por que isso importa? 19
20. Um estudo identi cou que quando sites cam fora do ar fora do ar v Queda de 100% nos acessos; Queda de 100% nas vendas; Aumento de 300% nos batimentos cardíacos de quem cuida do site. 20
21. Por onde começar então? Por onde começar então? 1968 1968 George A. Miller 21
22. Ciência cognitiva Ciência cognitiva George A. Miller Mnemônica; Lei de Miller: 7 coisas de cada vez; Palácio da memória (Sherlock Holmes); Programação neurolinguística (PNL); Psicologia e informação. 22
23. 1968 1968 A interação entre seres humanos e sistemas de informação. Quais os limites para manter a atenção de seres humanos ao interagirem com sistemas de informações? 23
25. Até 100 milissegundos Até 100 milissegundos Ter a sensação de instantâneo. Até 1 segundo Até 1 segundo Ter a sensação de continuidade. 25
26. Entre 1 e 10 segundos Entre 1 e 10 segundos Manter a atenção enquanto aguarda. Acima de 10 segundos Acima de 10 segundos Atenção perdida. 26
27. 1968 1968 2019? 2019? 27
28. FPS ( FPS (quadros por segundo quadros por segundo) ) Olho humano: 12 FPS 12 FPS Tela de um celular moderno: 60 FPS 60 FPS 28
29. Olho humano (12 FPS): 83 milissegundos 83 milissegundos Tela de um celular moderno (60 FPS): 16 milissegundos 16 milissegundos 29
30. Até 16 milissegundos Até 16 milissegundos Não existe diferença real para renderização. Mais que 100 milissegundos 100 milissegundos Seres humanos perdem a percepção de instantâneo. 30
31. Renderização progressiva Renderização progressiva https://developers.google.com 31
32. Diretrizes para tempo Diretrizes para tempo de resposta de resposta 32
33. API's: Idealmente, mantenha tudo abaixo de 100 milissegundos 100 milissegundos Nunca ultrapasse os 200 milissegundos 200 milissegundos 33
34. Interfaces: Idealmente, renderize tudo em até 100 milissegundos 100 milissegundos Utilize técnicas de renderização progressiva e nunca ultrapasse 1 segundo 1 segundo 34
35. Qual problema Qual problema queremos resolver? queremos resolver? 35
36. enjoei.com.br enjoei.com.br Marketplace de moda com milhões de produtos que precisa: Fazer buscas em todos esses milhões de produtos; Aguentar picos de acessos por conta de programas na TV. 36
37. O cenário O cenário Altos custos com infraestrutura; Tempo de resposta acima dos 200 milissegundos; Grande di culdade em aguentar picos de acessos instantâneos. 37
38. Características Características API's em Ruby on Rails; Muito código legado; Elasticsearch com problemas de performance. 38
39. Como escolhemos Go? Como escolhemos Go? 39
40. "Não dá mais." "Não dá mais." 40
41. O custo de reescrever tudo O custo de reescrever tudo "Se for pra mudar, tem que valer a pena." "Será que precisa mesmo?" https://roda.jeremyevans.net/ 41
43. https://www.techempower.com/benchmarks/ 43
44. E o roda? 44
45. E o roda? ... 45
46. E o roda? 46
47. "Se for pra mudar, tem que valer a pena." "Se for pra mudar, tem que valer a pena." 47
48. Ruby, até mais, e obrigado pelos peixes! ♥ 48
49. Should I Rust, or Should I Go? https://codeburst.io 49
50. Muitos testes, estudos e benchmarks depois: Let's Go! Let's Go! Sempre no top 3 de qualquer benchmark; Mais opções de bibliotecas; Curva de aprendizado menor; Maior produtividade no dia a dia. 50
51. package main import "fmt" func main() { fmt.Println("hello world") } 51
52. E agora? E agora? 52
53. Como servir dados via HTTP? Como servir dados via HTTP? Sem reinventar a roda ou fazer tudo na mão. Equilíbrio entre alta performance e usabilidade. Nossa escolha: https://github.com/go-chi/chi 53
54. router := chi.NewRouter() router.Use( middleware.Logger, render.SetContentType(render.ContentTypeJSON), ) router.Get("/status", statusHandler) func statusHandler(w http.ResponseWriter, r *http.Request) { w.Write([]byte("ok")) } http.ListenAndServe(":8484", router) 54
55. Primeira surpresa Primeira surpresa 55
56. 9,991µs 9,991µs µs µs 56
57. µs µs signi ca microssegundos microssegundos 57
58. 1 segundo 1 segundo é igual a 1 mil milissegundos 1 mil milissegundos que é igual a 1 milhão de microssegundos 1 milhão de microssegundos 58
59. 9,991µs 9,991µs é igual a 0,000009991 segundos 0,000009991 segundos 59
60. Como trabalhamos Como trabalhamos com Elasticsearch? com Elasticsearch? 60
61. Do jeito errado. Do jeito errado. 61
62. O que aprendemos: O que aprendemos: É a melhor opção para buscas complexas em um volume enorme de dados. É tão simples e prático que mesmo fazendo tudo errado ele funciona. A modelagem dos seus documentos é tudo. 62
63. O que aprendemos: O que aprendemos: Não tentar usar o mesmo índice para responder perguntas diferentes. "keyword" ao invés de "text" faz toda diferença. Scripts são malignos. Arredondar datas economiza muito dinheiro. 63
64. Como ler dados do Como ler dados do Elasticsearch com Go? Elasticsearch com Go? Nossa escolha: https://github.com/olivere/elastic 64
65. client, _ := elastic.NewClient( elastic.SetURL("http://127.0.0.1:9201")) searchResult, _ := client.Search(). Index("products"). Query(elastic.NewTermQuery("title", "sandália preta")). Do(context.Background()) var product Product for _, p := range searchResult.Each(reflect.TypeOf(product)) { product := p.(Product) fmt.Printf("%s", product.Title) } 65
66. O primeiro problema... O primeiro problema... "Já ví esse lme antes..." 66
67. Elasticsearch Query DSL Elasticsearch Query DSL Uma lição que aprendemos: Toda biblioteca que tenta criar uma abstração para Elasticsearch resulta em código que ninguém entende. 67
68. Funciona bem para SQL Funciona bem para SQL 68
69. User.where(name: 'David', occupation: 'Code Artist') .order(created_at: :desc) User.where(email: 'david@email.com').first User.where('update_at > ?', 1989).each do |user| puts user.name end 69
70. user := &User{} db.Model(user) .Where("name", "David").Where("occupation", "Code Artist") .Order("created_at DESC").Select() db.Model(user).Where("email", "david@email.com").Select() var users []User db.Model(&users).Where('update_at > ?', 1989).Select() for _, user := range users { fmt.Printf("%s", user.Name) } 70
71. Não funciona bem para Não funciona bem para Elasticsearch Elasticsearch 71
72. query do script_fields distance: { script: "doc['location'].distance(lat, lon)", params: {lat: latitude, lon:longitude} } fields ['_source'] query do filtered do query do multi_match do query str fields %w[title name] end 72
73. query := elastic.NewMatchAllQuery() aggs := elastic.NewDateHistogramAggregation(). Field("time"). Interval("hour"). Format("yyyy-MM-dd HH") aggs.SubAggregation( "count", elastic.NewSumAggregation().Field("no_of_hits")) searchResult, _ := client.Search(). Index("my_index"). Type("_doc"). Query(query). Aggregation("date", aggs). Do(ctx) hour_agg, found := searchResult.Aggregations.Terms("date") 73
74. Qual a solução então? Qual a solução então? 74
75. Templates JSON Templates JSON 75
76. { "size": 10, "query": { "bool": { "must": { "match": { "title": "vestido" } }, "filter": { { "term": { "color": "vermelho" } } } } } } 76
77. Qual engine de templates? Qual engine de templates? Equilíbrio entre alta performance e usabilidade. Nossa escolha: https://github.com/shiyanhui/hero 77
80. <%: func SearchProducts(term string, color string) %> { "size": 10, "query": { "bool": { "must": { "match": { "title": "<%==s term %>" } }, "filter": { { "term": { "color": "<%==s color %>" } } } } } } 80
81. func Search() { jsonBody := new(bytes.Buffer) templates.SearchProducts("vestido", "vermelho", jsonBody) products := elastic.RequestFromJson( "GET", "/products/_search", jsonBody) } 81
82. Precisa da biblioteca para Elasticsearch então? Precisa da biblioteca para Elasticsearch então? Sim Sim Controle de conexões com o Elasticsearch; Autenticação do cliente; Parser de resultados; Bulk API para inserção de dados. https://github.com/olivere/elastic 82
83. Onde entra GraphQL Onde entra GraphQL na história? na história? 83
84. Como funciona conceitualmente Como funciona conceitualmente 84
85. Teoria dos grafos Teoria dos grafos 85
86. Representação de recursos Representação de recursos 86
87. Um produto e o seu vendedor Um produto e o seu vendedor 87
88. product(id: 8945) { title seller { name } } 88
89. query productQuery($id: ID!) { product(id: $id) { title seller { name } } } } { "id": 8945 } 89
90. { "data": { "product": { "title": "vestido vermelho", "seller": { "name": "beatriz" } } } } 90
91. Paginação Paginação 91
92. Paginação baseada em Offset Paginação baseada em Offset 92
93. Esqueça paginação Esqueça paginação baseada em Offset baseada em Offset 93
94. Paginação baseada em Cursores: Paginação baseada em Cursores: 94
95. Metadados nas conexões e arestas Metadados nas conexões e arestas 95
96. Como esses dados são Como esses dados são representados? representados? 96
97. Representação simplifcada: { "product": { "title": "vestido vermelho", "seller": { "name": "lojinha da bia" } } } 97
98. Representação com conexões e arestas: { "user": { "productConnection": { "totalCount": 37, "productEdges": [ { "node": { "title": "vestido vermelho" }, "cursor": "726" } ] } } } 98
99. Como paginar os dados: query userProducts($user_id: ID!, $first: Int, $after: ID) { user(id: $user_id) { products(first: $first, after: $after) { totalCount edges { node { title } cursor } } } } { "user_id": 1873, "first": 10, "after": "726" } 99
100. A estrutura de uma busca A estrutura de uma busca 100
101. Como uma busca é feita: query Search($search: Search, $first: Int, $after: ID) { search(search: $search) { term products(first: $first, after: $after) { totalCount edges { node { title seller { name } } cursor } } } } { "search": { "term": "vestido vermelho" }, "first": 10, "after": "236" } 101
102. O resultado: "search": { "term": "vestido vermelho", "products": { "totalCount": 152836, "edges": [ { "node": { "title": "vestido vermelho", "seller": { "name": "beatriz" } }, "cursor": "245" } ] } } 102
103. Fragmentos Fragmentos 103
104. fragment productWithSeller on Product { title seller { name } } 104
105. search(search: $search) { products(first: $first, after: $after) { edges { node { ...productWithSeller } } } } product(id: $id) { ...productWithSeller } 105
106. Mas por que tudo isso Mas por que tudo isso importa? importa? 106
107. Em uma interface Em uma interface 107
108. Diversas requisições diferentes Diversas requisições diferentes GET /current_user GET /product/7 GET /product/7/seller GET /product/7/comment/4 108
109. 440 milissegundos 440 milissegundos em 1 requisição 109
110. Agora imagine fazer isso... Agora imagine fazer isso... 4 vezes; 4 vezes; Servidor nos EUA; Servidor nos EUA; Celular com 3G. Celular com 3G. 110
111. 100 milissegundos 100 milissegundos Sensação de instantâneo. Sensação de instantâneo. 111
112. 1 requisição para resolver tudo: currentUser { name gender } product { title price seller { name } comments { author { name } message replies { author { name } message } } } 112
113. GraphQL + Go GraphQL + Go 113
114. Goroutines Goroutines 114
115. var waitGroup sync.WaitGroup user := &User{} product := &Product{} waitGroup.Add(1) go loadUser(&waitGroup, user) waitGroup.Add(1) go loadProduct(&waitGroup, product) waitGroup.Wait() 115
116. Como servir dados via Como servir dados via GraphQL? GraphQL? Equilíbrio entre alta performance e usabilidade. Nossa primeira tentativa: https://github.com/graphql-go/graphql 116
117. graphql.NewObject( graphql.ObjectConfig{ Name: "GraphQL", Fields: fields}) graphql.ObjectConfig{ Name: "Query", Fields: graphql.Fields{ "source": &graphql.Field{Type: graphql.String}}}) graphql.NewSchema(graphql.SchemaConfig{Query: queryType}) var query_args = graphql.FieldConfigArgument{ "term": &graphql.ArgumentConfig{Type: graphql.String}, var Query = &graphql.Field{ Type: gq.Query, Args: query_args, Resolve: resolvers.Query,} 117
118. Verboso; Verboso; Complexo; Complexo; Confuso; Confuso; Nada produtivo. Nada produtivo. 118
119. Schema based Schema based 119
120. type Query { user(id: ID!): User product(id: ID!): Product } type User { id: ID name: String } type Product { id: ID title: String seller: User } 120
121. Nossa segunda tentativa: https://github.com/99designs/gqlgen 121
122. Geração de código; Geração de código; Funcionamento obscuro; Funcionamento obscuro; Muita mágica. Muita mágica. 122
123. Nossa escolha nal: https://github.com/graph-gophers/graphql-go 123
124. type Query { user(id: ID!): User product(id: ID!): Product } type User { id: ID name: String } type Product { id: ID title: String seller: User } 124
125. type UserResolver struct { Field fields.Field `graphql:"user"` Model models.User } func (resolver *Resolver) User(id params.Id) *UserResolver { return &UserResolver{Model: userModel.Find(id)} } func (userResolver *UserResolver) Name() *string { return &userResolver.Model.Name } 125
126. Simples; Simples; Direto ao ponto; Direto ao ponto; Paralelismo por padrão. Paralelismo por padrão. 126
127. Paralelismo por padrão: user { name } product { title comments { message author { name } } } 127
129. Tem como melhorar? Tem como melhorar? Sim Sim 129
130. requested-fields requested-fields https://github.com/gbaptista/requested- elds 130
131. hasComments := fields.RequestedForAt(ctx, productResolver, "comments") hasCommentAuthor := fields.RequestedForAt(ctx, productResolver, "comments.author") if hasComments { waitGroup.Add(1) go loadCommentsFor(productResolver.Model) } if hasCommentAuthor { waitGroup.Add(1) go loadCommentAuthorsFor(productResolver.Model) } 131
133. Tem como melhorar? Tem como melhorar? Sim Sim 133
135. Resultados Resultados 135
136. Throughput suportado (rpm) Throughput suportado (rpm) 136
137. Tempo de resposta Tempo de resposta 137
138. Servidores Servidores 138
139. Elasticserach Elasticserach 139
140. Reflexões Reflexões 140
141. Não se apegue a Não se apegue a tecnologias. tecnologias. 141
142. Ruby é incrível, mas não Ruby é incrível, mas não precisa resolver tudo. precisa resolver tudo. Go é só uma das Go é só uma das opções. opções. 142
143. Os problemas de Os problemas de amanhã serão maiores amanhã serão maiores que os de hoje. que os de hoje. Rust está vindo com tudo. Rust está vindo com tudo. 143
144. Sempre tem como Sempre tem como melhorar. melhorar. 144
145. Ainda podemos: Ainda podemos: Usar HTTP2 ao invés de HTTP1; Usar HTTP2 ao invés de HTTP1; Usar gRPC como protocolo de comunicação; Usar gRPC como protocolo de comunicação; Criar estratégias agressivas de cache; Criar estratégias agressivas de cache; Trabalhar com WebAssembly no navegador. Trabalhar com WebAssembly no navegador. 145
146. Não vai ficar perfeito. Não vai ficar perfeito. E tudo bem. 146
147. query( $products: ProductSearch, $first: Int, $after: ID ) { search(search: $products) { term products(first: $first, after: $after) { edges { node { title } cursor } } } } 147
148. query( $products: ProductSearch, $users: UserSearch, $first: Int, $after: ID ) { search(products: $products, users: $users) { term products(first: $first, after: $after) { edges { node { title } cursor } } users(first: $first, after: $after) { edges { node { name } cursor } } } } 148
149. Estudar novas linguagens abre Estudar novas linguagens abre a sua mente e acaba sendo a sua mente e acaba sendo divertido. divertido. Não tenha medo. 149
151. Obrigado! Obrigado! https://github.com/gbaptista https://twitter.com/gbaptistasss https://www.linkedin.com/in/guilhermebaptista 151