TAPTAP estuvo presente en Smash Tech para explicar cómo escalar hasta las 10.000 peticiones por segundo.

1. Escalando
hasta
las
10.000
pe1ciones
por
segundo
Sergio
Arroyo
Cuevas
sergio.arroyo@taptapnetworks.com
@delr3ves

3. @TAPTAP_Networks

6. Proveedor
de
campañas
Proveedor
de
“escaparates”
inventario
AdServer
Forecas1ng

8. SSP
AdExchange
Subasta
DSP
Bidder
SDK
1.
Dame
anuncios
2.
Hay
un
escaparate
disponible,
¿cuánto
me
dais?

9. • ¿Qué
campaña
ponemos?
• ¿Cuánto
pagamos
por
ella?
• Necesitamos
muchísimas
pe1ciones
Problemas
• Tiempo
de
respuesta
<
100ms
• Siempre
hay
que
dar
una
respuesta
válida
• Almacenamos
todas
las
pe1ciones
• No
podemos
precalcular
el
resultado
Restricciones

10. ¿CÓMO
AFRONTAMOS
EL
RETO?

13. Redis
Storm
Hadoop
MongoDB
Amazon
S3

14. Dev Team Bidder

15. Dev Team Bidder

16. Round
0
DRPCSpout
BidRequest
Crea1vi1es
RequestLog
RetrieveCampaignsByGeohash
CampaignCrea1vi1es
PacingReached
IsAc1ve
Scheduling
FrequencyCapping
BlockedByPublisher
Intersec1on
CalculateWinner
BidResponse
ResultLog

17. Round
0

18. ¡40
QPS!
¿Seguro?
KO
Dev Team Bidder

19. • Paralelizar
Iene
un
sobre-­‐coste
• La
serialización
es
cara
y
aburrida
de
programar
• No
sabemos
que
pasa
por
dentro
• “Real1me
processing”
!=
comunicación
sincrona
Lecciones
aprendidas

20. • Paralelizar
1ene
un
sobre-­‐coste
• La
serialización
es
cara
y
aburrida
de
programar
Round
1
DRPCSpout
CojoBolt
RequestLog
ResponseLog

21. ¡500
QPS!
¿Seguro?
KO
Dev Team Bidder

22. • Paralelizar
1ene
un
sobre-­‐coste
• La
serialización
es
cara
y
aburrida
de
programar
• No
sabemos
que
pasa
por
dentro
• “Real1me
processing”
!=
comunicación
sincrona
• Redis
no
nos
sirve
como
Storage
principal
Lecciones
aprendidas

23. Round
2

24. Round
2

25. Round
2

26. ¡500
QPS!
¿Seguro?
KO
Dev Team Bidder

27. • Paralelizar
1ene
un
sobre-­‐coste
• La
serialización
es
cara
y
aburrida
de
programar
• No
sabemos
que
pasa
por
dentro
• “RealIme
processing”
!=
comunicación
sincrona
• Redis
no
nos
sirve
como
Storage
principal
Lecciones
aprendidas

28. • Monitorizar
es
importante
para
nosotros
Round
3

29. Round
3
CORE
PORTS
ADAPTERS

30. Round
3
CORE
STORM
REDIS

31. Round
3
CORE
DROPWIZARD
+
STORM
MONGO
+
REDIS

32. Round
3

33. Cómo
conseguimos
las
métricas?
@Timed(name = "BidRequests")!
public Response bid(...) {!
"//Do your magic here!
}
...!
Histogram validFoundCampaigns = Metrics.newHistogram("FoundCampaigns");!
validFoundCampaigns.update(filteredCampaigns.size());!
...!

34. Métricas
siempre
visibles

35. Enviando
métricas
a
Graphite
public static void configureMetricsReporter(!
" "GraphiteConfiguration graphiteConfiguration) {!
"if (graphiteConfiguration != null && graphiteConfig.isEnabled()) {!
GraphiteReporter.enable( !
" " " "graphiteConfig.getGraphiteSendMetricsPeriodInSeconds(),
" " " "TimeUnit.SECONDS,!
" " " "graphiteConfig.getGraphiteHost(),!
graphiteConfig.getGraphitePort(), "!
" " " "graphiteConfig.getGraphiteMetricsId());!
"}!
}

38. ¡3500
QPS!
¡¡Seguro!!
KO
Dev Team Bidder

39. Round
5

40. Round
5

41. ¡10000
QPS!
KO
Dev Team Bidder

42. • En
cuanto
solucionas
un
cuello
de
botella
aparecerá
el
siguiente.
• Por
mucho
que
lo
intentemos
tendemos
a
la
op1mización
prematura.
• La
algoritmia
no
nos
ha
resuelto
el
problema.
• Busca
una
librería
de
métricas
para
tu
stack.
• Un
entorno
de
trabajo
higiénico
es
imprescindible.
Lecciones
aprendidas

44. Entre
175
y
250
GB
diarios
de
datos
comprimidos
(1,6TB
en
crudo)
• Escritura
en
disco
en
diferido
• Discos
SSD
• Envío
por
lotes
a
S3
Problemas
de
almacenamiento

45. “Si
devuelve
void,
puede
esperar”
public void log(!
final RTBImplementationBean request,!
final AdExchange adExchange) {!
FutureTask futureLog = new FutureTask(new Callable() {!
@Override!
public Object call() throws Exception {!
" synchLog(request, adExchange);!
" " "return null;!
" }!
" );!
futureLog.run();!
}
Rest
Server
Worker
PubSub
DB
A
nivel
de
código
A
nivel
arquitectónico

46. • Si
necesitas
backups,
ten
en
cuenta
que
necesita
el
doble
de
memoria
de
la
que
vas
a
usar.
Redis
va
como
un
1ro
pero…
Backup
instance

47. Cuidado
con
el
tamaño
del
heap

48. • De
dicas
más
1empo
a:
– Programar
vs
Despelgar?
– Diagnos1car
vs
Corregir?
– Bugs
vs
Features?
• Opacidad
• Pérdida
del
control
Cuida
tu
entorno
de
trabajo

49. Cada
pieza
del
puzzle
es
mo1vo
de
preocupaciones.
Sobreingenieria
es
evil

50. • Miedo
al
cambio.
• Sen1miento
de
pertenencia.
• Ser
exesivamente
conservador.
• Fíate
de
tus
ins1ntos.
“La
inercia
te
frena
¿WTF?”

51. Q&A
Muchas
Gracias

52. Spain!
(headquarters)!
!
Pº Castellana 111, 1st floor!
28046 Madrid – Spain!
+34 91 101 1001!
<<<<
USA!
!
!
747 3rd Avenue!
NY, NY 10017!
+1 516 206 2392!
Colombia!
!
!
Carrera 7, nº71 – 21. Torre B!
Piso 13 – 15!
Bogotá, Colombia!
+57 1 31 35 913!
Contact us at :!
www.taptpanetworks.com & www.sonatalocal.com!
info@sonatalocal.com!
@TAPTAP_Networks & @SONATAlocal!