Après-midi - Track 3 - S1 - Tech Round Table Cette session vous a plû ? Si c'est le cas, n'hésitez pas à vous inscrire à notre Summit !

1. Behind the scenes:
3 startups, 3 stacks techniques

2. Shared Inboxes Built for Teams
Jeremy Bogatirsky

3. Front?
• Paris / San Francisco
• YCombinator S14
• Email was made for 1 to 1 communication, email was not made for
team
• Dealing with shared inboxes is painful
• Intuitive collaboration over shared inboxes (Email, Twitter, SMS)

4. Email client with collaborative features

5. Front architecture on AWS
• Based on micro services (Node.js)
• Communication through message queues (Redis)
• Relational database (MySQL)
• Caching system (Memcached)
• Long-time persistence (Amazon S3)

6. OK, now AWS resources
• Amazon EC2
– 20 running instances (Linux)
– 20 security groups
– 3 Elastic Load Balancers
– 3 Elastic IPs
• Amazon Elasticache
– 1 Memcached cluster (2 nodes of 13.5GB RAM)
– 1 Redis replication group

7. More AWS resources
• Amazon RDS
– 2 instances (MySQL)
• Amazon S3
– 7 buckets in use
• Misc
– 9 IAM users
– 69 records in Amazon Route 53 hosted zone
– 3 web distributions in Amazon CloudFront
– 125 CloudWatch alarms

8. Overall architecture
APIs
Internet
Amazon
S3
Memcached
Redis
Internet
Workers

9. Metrics
• 150 000 Emails/SMS/Tweets per day
• Up to 2 500 simultaneous users
• 20 000 000 push notifications per day (socket.io)
• No SLA agreement but you can't afford downtime when delivering
emails/sms/tweets 

10. Conclusion
• All-in-one cloud
• Flexible
• Scalable friendly
• Not so complicated as it seems at first
• It took minutes to be up and running

11. Realytics
Leverage the AWS cloud

19. Custom analytics
engine
+
TV ads Real Time
tracking
+
Data Science

20.  Exact spot diffusion
timestamp
 Spot position in funnel
 Broadasted spot clues
 Near RT
 High precision
 High granularity
 Ability to tackle specific
media scenario
C u s t o m A n a l y t i c s E n g i n e T V S t r e a m A n a l y s i s

21. 60K + spots
analyzed
200M+
different
profiles
1Mds events
relative to TV
50+
customers
140+
Channels8 countries

22. Leveraging AWS : API Serving V1
Amazon S3
Route 53 Amazon SQSELB

23. Leveraging AWS : Middleware V1
On Premises
Amazon SQS
RDS

24. Issues & Bottlenecks encountered after 1 year
 Data is growing fast (x2 every quarter)
 Inadequate RDBMS design to handle volume / throughput (1TB)
 Computation get slower (from seconds to hours)
 SQS, RDS are getting too expensive
 Multiple risk factors
 Single region (EU-EAST-1)
 Limited HA
 Low security
 …

25. Leveraging AWS : API Serving V2
KINESISRoute 53

26. Leveraging AWS : Middleware V2
Amazon S3
On Premises
KINESIS
RDS Dynamo DBRedis

27. Sébastien MONTEIL
CTO
sebastien@realytics.io
Frédéric ATLAN
fatlan@morea.fr

28. Etsy - A little Market
Plusieurs millions d’utilisateurs
Une migration transparente et (presque) sans douleur
Vincent Paulin – Technology R&D project manager
@Genokilller

29. Qui sommes nous ?
Lancé en 2008, place de marchée dédiée au fait-main et à l’artisanat
français.
Lancé en 2011, place de marché dédiée à l’achat de fournitures pour
créer.

30. Ça donne quoi en chiffres technique ?
– 10 TB d’images
– +200 GB de base de données
• ~ 3500 lectures/seconde
• ~ 350 écritures/seconde
– Cluster Elasticsearch (5 serveurs)
– +20 serveurs au total (frontaux + SQL+ Cache + Varnish,
etc.)
– Jusqu’à 10 deploys/jour

31. Architecture technique
Vue d’ensemble

32. Ce que nous avons
Varnish
Apache - PHP
APIs
Nginx
Internal calls
(APIs)

33. Mais aussi...

34. Migration
Assets

35. Assets
Nginx

36. Comment ?
• Plusieurs TB de données
– Plus de 100 000 dossiers
– 1 dossier = 1 identifiant de vendeur
• Toutes les images de ses produits
dans ce dossier
• Jusqu’à 25 000 fichiers par dossier

37. Double écriture
Upload

38. Synchronisation
● Parcours des IDs de vendeurs
● aws cp du dossier vers le bucket Amazon S3
● Update database SQLite

39. Migration
Databases

40. Databases
• Plusieurs GB de
données
• Plus de 10 bases
de données

41. Comment ?
• Dédier un slave pour les backups
– Le verrouiller :
STOP SLAVE;
FLUSH TABLES WITH READ LOCK;
• Bien noter la position du master
SHOW MASTER STATUS;
• Effectuer un dump complet de chaque base de données
• Une fois terminé
UNLOCK TABLES;
START SLAVE;
mysqldump --no-create-info --skip-triggers <database_name> |gzip > <database>_data.sql.gz
mysqldump --no-data <database_name> > <database>_schema.sql

42. Upload et traitement du dump
Copie du dump sur
Amazon S3
avec AWS CLI
Décompression
Traitement
Intertion

43. Connecter la nouvelle base de données en
slave

44. Ce à quoi il faut faire attention
– Vérifier la durée de rétention des bin logs
• Pour le master en production
– Un dump, c’est long
– Le slave doit avoir suffisamment de temps pour se
resynchroniser avec le master
• Pour le slave qui recevra la connexion du serveur RDS en slave
– L’insertion des données peut-être très longue
– Prévoir une instance EC2 suffisamment puissante pour traiter le
dump SQL.
– Prévoir une instance RDS suffisamment puissante pour être
synchronisée avec le slave de production

45. Des données avec une durée de vie courte ?
• Session
• Autorisation API
• Token utilisateur
• …
Ne perdez pas de temps et d’IOPS avec ces tables
durant la re-synchronisation
Adoptez un schéma de type blackhole jusqu’à la fin
synchronisation.

46. Merci !
recrutement@alittlemarket.fr

47. Jeremy Bogatirsky
Lead Developer
Sébastien Monteil
CTO & Co-Founder
Vincent Paulin
Responsible R&D

48. Inscrivez-vous gratuitement à l’adresse :
aws.amazon.com/summits/paris