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

Sébastien MONTEILCTO

sebastien@realytics.io

Frédéric ATLANfatlan@morea.fr

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.

Merci !

recrutement@alittlemarket.fr

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