Embed Size (px)
Citation preview
Behind the scenes:
3 startups, 3 stacks techniques
Shared Inboxes Built for Teams
Jeremy Bogatirsky
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)
Email client with collaborative features
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)
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
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
Overall architecture
APIs
Internet
AmazonS3
Memcached
Redis
Internet
Workers
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
Conclusion
• All-in-one cloud
• Flexible
• Scalable friendly
• Not so complicated as it seems at first
• It took minutes to be up and running
Realytics
Leverage the AWS cloud
Custom analytics
engine
+
TV ads Real Time
tracking
+
Data Science
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
60K + spots analyzed
200M+ differentprofiles
1Mds eventsrelative to TV
50+ customers
140+ Channels8 countries
Leveraging AWS : API Serving V1
Amazon S3
Route 53 Amazon SQSELB
Leveraging AWS : Middleware V1
On PremisesAmazon SQS
RDS
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 …
Leveraging AWS : API Serving V2
KINESISRoute 53
Leveraging AWS : Middleware V2
Amazon S3
On Premises
KINESIS
RDS Dynamo DBRedis
Etsy - A little MarketPlusieurs millions d’utilisateurs
Une migration transparente et (presque) sans douleurVincent Paulin – Technology R&D project manager
@Genokilller
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.
Ç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
Architecture technique
Vue d’ensemble
Ce que nous avons
Varnish
Apache - PHP
APIs
Nginx
Internal calls
(APIs)
Mais aussi...
Migration
Assets
Assets
Nginx
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
Double écriture
Upload
Synchronisation
● Parcours des IDs de vendeurs
● aws cp du dossier vers le bucket Amazon S3
● Update database SQLite
Migration
Databases
Databases
• Plusieurs GB de données
• Plus de 10 bases de données
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
Upload et traitement du dump
Copie du dump sur
Amazon S3
avec AWS CLIDécompression
Traitement
Intertion
Connecter la nouvelle base de données en
slave
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
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.
Jeremy Bogatirsky
Lead Developer
Sébastien Monteil
CTO & Co-Founder
Vincent Paulin
Responsible R&D
Inscrivez-vous gratuitement à l’adresse :
aws.amazon.com/summits/paris
