Votre appli web en Python : de zéro au million d'utilisateurs

Martin Richard, alwaysdata

Votre appli web et Python :
de zéro au million d'utilisateurs

Pourquoi cette présentation :

Quelques conseils pour débuter, quand on vise une large audience

Anciennement CTO d'une startup, sans expérience d'un projet large
Maintenant développeur système & réseau chez alwaysdata, un hébergeur

G I F E E
Google Infra
For Everyone Else

Tweet qui parle d'ETCD et Docker sur un cluster de Raspberry Pi

G U F E E
Google Uptime
For Everyone Else

Uptime ?

Pour chaque requête, une réponse
... et la bonne
... et dans un délai acceptable

Le code

Quoi utiliser ?

Objectif premier : simplicité
Boring techs : Technologies stables et populaires
Choisissez ce que vous connaissez en priorité
Evitez les modules/packages qui ne sont pas activement supportés
vérifiez les tests unitaires, semantic versioning

Peur du monolithe ?

Objectif ~~second~~ premier bis : réduire les points de couplage
Les frameworks web (Django, etc) favorisent le couplage
Organisation du code liée aux équipes
Responsable de leurs objets et du stockage
Responsable de leur API métier de haut niveau

☠ couplage avec la BDD et l'ORM

C'est un détail d'implémentation !
Aucune logique métier, aucune sémantique
Par exemple: pas d'ORM dans la vue

☠ couplage avec HTTP

C'est un détail d'implémentation !
Pas de session, de GET ou POST dans l'API
Ce sont des variables globales !
Empêche l'utilisation de l'API dans des scripts (asynchrone)
@login_required : nope !

La base de données

Marquer les lectures et les écritures

Deux connexions à la base de données (une en lecture seule) (config.DATABASES)
Utilisez celle en lecture seule au maximum
...puis en écriture quand vous n'avez pas le choix
Complique un peu le développement
Facilite l'ajout de répliques (maître - esclave) et caches

Contraintes d'intégrité, transactions

Dans l'implémentation de vos API
Contraintes d'intégrité fortes
Transactions partout (en lecture aussi)
Niveau maximal d'isolation

Dénormalisation ?

Mise à l'échelle de l'organisation, pas technique
< 2TB de données ? Problèmes d'implémentation, pas d'infra
dénormalisez les indexes avant les contraintes :
(indirection, cache, etc.)

Vérification de la cohérence

Scripts qui vérifient la cohérence des données
Exécutés automatiquement (tâches planifiées)
Qui listent les erreurs, plutôt qu'essayer de les corriger
En amont, sourcez l'origine des données

Infrastructure et hébergement

Cloud ou pas cloud ?

IaaS: la fausse bonne idée
Trop de travail de sysadmin et d'ops
Vous n'avez pas besoin de ressources en temps réel (€)
Garanties discutables (noisy neighbors)

IaaS non, PaaS oui

Sous-traitez l'infrastructure et le sysadmin
Laissez-leur le monitoring et les astreintes
Heroku, Google App Engine, AWS Beanstalk, alwaysdata
Attention aux coûts et aux limites : testez
Docker : attention aux fausses promesses, c'est le retour du sysadmin !

Evaluez vos besoins

Calculs sur un coin de table, par exemple :
CPU : QPS = nombre de coeurs / (temps de calcul)
200 QPS = 4 coeurs / 20ms QPS = Query per second
RAM : Taille de la BDD + Ram/requête × QPS
200 * 50MB = 10GB de RAM + 10GB < 24GB (de la place pour cache IO)
Bande passante: moins un problème que la latence

Conclusion

Le scaling est un problème d'organisation avant d'être technique
Viser la simplicité et l'évolution incrémentale
Python est toujours un bon choix.

Des questions ?

N'hésitez pas à venir me voir, moi c'est Martin
martius@martiusweb.net
https://marti.us
Twitter, github, etc : Martiusweb
Lien vers cette présentation : https://marti.us/t/pyconfr-2015/