Archictectures PHP/MySQLPHP Québec, réunion mensuelle

4 octobre 2007,

Montréal, Québec, Canada

Qui parle?Damien Seguy

Co-phpère des éléphpants

Hébergements nexen Services

damien.seguy@nexen.net

ArchitectureOrganiser son application pour dépasser un ou deux serveurs

Être capable d'ajouter du matériel

Assurer la montée en charge

Quel est le problème?

Trop de traitements?

Trop de données?

Trop de lectures?

Trop d'écritures?

Critères d'architecturePerformances

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?

Différentes approches

Scale outScale up

Scale upSyndrô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!

Scale outSyndrôme de la ferme de serveurs

Économique à raisonnable

Evolutif à la carte

Impact sur l'organisation de l'application

Possibilité de virtualisation

Multiplication des serveur Web

Multiplication des serveurs WebBeaucoup 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'

Multiplication des sites WebLes sessions : il faut partager

Session via NFS

Session dans un filer

Session en base de données

Zend platform

Session en memcache

Base de données

Lecture Écriture Écueil

Réplication Oui Non Lag

Cluster Oui Oui Installation

Partitions Non Oui Application

Réplication

Écritures

Lectures

RéplicationIdé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?

Solutions de réplicationsDoubler 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

PartitionsDé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

Partitions + réplication : shardUtilisé 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

Cluster

GestionSQL

Stockage

ClusterPas avant 4 machines

Les performances individuelles diminuent

Elles n'augmentent pas vite

Beaucoup d'effort de configuration

C'est l'avenir

Questions?http://www.nexen.net/conferences.php

damien.seguy@nexen.net

Elements graphiques