Différentes architectures PHP et MySQL pour dépasser la simple installation de deux serveurs : fermes PHP, réplication MySQL, cluster et partitionnement. Différentes stratégies pour assurer l'évolutivité.
2. Qui parle?
Damien Seguy
Co-phpère des éléphpants
Hébergements nexen Services
damien.seguy@nexen.net
3. Architecture
Organiser son application pour dépasser un
ou deux serveurs
Être capable d'ajouter du matériel
Assurer la montée en charge
4. Quel est le problème?
Trop de traitements?
Trop de données?
Trop de lectures?
Trop d'écritures?
5. Critères d'architecture
Performances
Répond vite
Haute disponibilité
Toujours accessible
Aucun passage obligé
Evolutivité
Ce qui monte doit redescendre
Que se passe-t-il quand on doit ajouter un
serveur?
7. Scale up
Syndrôme du gros serveur
Très cher
à l'achat
à l'entretien
Très faible impact sur le code
Résout les problèmes
Temporairement
Aucun moyen de revenir en arrière!
8. Scale out
Syndrôme de la ferme de serveurs
Économique à raisonnable
Evolutif à la carte
Impact sur l'organisation de
l'application
Possibilité de virtualisation
10. Multiplication des serveurs Web
Beaucoup de travail pour PHP
Personnalisation
Solutions
Exporter les données statiques
dans un CDN
Akamaï, Amazon S3,Youtube,
Mises en cache temporaire
HTML, code PHP, données
Stratégie du 'Share nothing'
11. Multiplication des sites Web
Les sessions : il faut partager
Session via NFS
Session dans un filer
Session en base de données
Zend platform
Session en memcache
12. Base de données
Lecture Écriture Écueil
Réplication Oui Non Lag
Cluster Oui Oui Installation
Partitions Non Oui Application
14. Réplication
Idéale pour les sauvegardes
Limitée par les écritures
Le maître ne travaille pas
Les esclaves au turbin
Le maître est un point critique
On double le maître pour HA
Le persistant problème de lag
Les esclaves arriveront-ils à
rattraper un jour?
15. Solutions de réplications
Doubler le maître
Réplication synchrone Google
Diriger les écritures sur le maître, et
les lectures seules sur les esclaves
Il faut mesurer et maîtriser son retard
de réplication
16. Partitions
Découpage des données en plusieurs
partitions
Permet de résoudre les problèmes de
taille de table
Permet de régler les problèmes
d'écritures
Conduit à des tables de taille
raisonnable
Permet les opérations paralelles
Les jointures deviennent difficiles
17. Partitions + réplication : shard
Utilisé initialement chez Flickr
Réplication réciproque, maître-maître
Les écritures vont sur les deux
serveurs
Facilité à configurer et comprendre
Haute disponibilité
Pas de gaspillage de ressource