Vous êtes sur la page 1sur 15

Djangocong '13 Belfort

Refonte de Greenbureau

Greenbureau

Un service de centralisaton de factures/relevs Init l'automne 2011, bta en dcembre 2012, ouverture en mars 2012

Beaucoup de technos

Python/django Celery/Rabbitmq phantomjs/casperjs & selenium webdriver/server Postgres Mongodb

Loi Hamon

Certains documents (factures, CGV) doivent tre disponibles pour l'utlisateur hors du fournisseur, afn que celui-ci ne puisse tre juge et parte ; Interventon d'un ters de confance.

Greenbureau
Stocker les donnes d'un million d'utilisateurs tous les mois? Pas de pb!

Infra v1
Front

celery routes back


nginx django mongo postgres FrontDB


Back Rabbitmq celery back Mongodb django selenium hub celery routes front

Nodes WebDriver

selenium node Firefox

postgres celery front

Les problmes

Mongo Celery Composants aux rles mal dfnis Dploiement trop manuel Impossible de personnaliser facilement le profl Firefox avec le serveur En ralit tous les fux passent par un VPN car certains fux ne peuvent tre chiffrs = SPOF

Un dbut de solution

Moins de technos :

Au revoir celery/RabbitMQ/Erlang, Bye bye MongoDB, Ciao Selenium Server/Java, Hasta la vista PhantomJS/Javascript, Auf Wiedersehen supervisord

Des technos prouves et matrises :


Python : Django, Flask, Fabric, bindings Python Selenium WebDriver Postgres MogileFS/Perl (!!)

Un dbut de solution

Une nouveaut : hgmq, un gestonnaire de queue en Python bas sur MQ, Redis et MsgPack. Une infra avec des composants aux rles bien identfs. Dploiement simplif via scripts fabric.

Infra v2

Front

nginx flask hgmq redis Site+API

hgmq

Core nginx django hgmq redis postgres

hgmq

Monitoring Business logic hgmq FortKnox


Back hgmq redis webdriver Firefox Fetching

hgmq Redis postgres MogileFS Stockage

Au final

Jusqu' x10 en perf sur certains scripts dans le back avec hardware. Mme perfs au niveau front avec hardware grce Flask, plus lger que django. Actuellement un front mais aucun pb pour avoir n front avec 1 core. Toutes les communicatons sont chiffres par HGMQ : plus besoin de VPN entre les serveurs (un SPOF en moins) ; tmux pour lancer les process cf cl de chiffrement saisie depuis fabric . Scurit accrue : admin accessible uniquement via le VPN, tout ce qui est chiffr est dans FortKnox

django dans l'infra v2


La part de django s'est rduite par rapport la v1 (oups je suis dans une conf django?) Mais tout est en python :) django utlis l o il excelle : admin, apps rutlisables Flask pour le front : plus lger, incite ne pas implmenter de logique business sur le front, pas d'admin, etc.

Sharding

Aucun pb pour le front et le back, ils n'ont pas de DB. MogileFS se dbrouille pour le stockage dans FortKnox. Pour le core : quasi en shared nothing, sauf l'authent. On peut isoler l'index des users dans un nouveau composant et tout devient scalable. Sharding = n core.

Infra v2 avec le sharding


hgmq Front

Index

hgmq Core nginx django hgmq redis postgres

nginx flask hgmq redis Site+API

nginx django hgmq Redis postgres Auth

hgmq

Monitoring Business logic hgmq hgmq FortKnox


Back hgmq redis webdriver Firefox Fetching

hgmq Redis postgres MogileFS Stockage

Lessons learns

Atenton aux migratons de donnes (prs d'un mois pass sur prparer la migraton) Les hstore c'est pratque mais gare la taille des fchiers pg_toast si vous crivez beaucoup/souvent. requirejs : adapt pour les single page apps mais pas vraiment si on souhaite juste faire du progressive enhancement. Pour sharder : analyser bien votre schma.