Architectures réparties en environnement web

Architecturerépartie en

environnement Web

« Scalabilité »nom fémininbarbarisme (scalability)

Capacité des systèmes informatiques à pouvoir faire évoluer leurs ressources en fonction des besoins, sans nécessiter une refonte de l'architecture matérielle et logicielle.

« Haute disponibilité »

Capacité des systèmes informatiques à fournir le service prévu à tout moment, même en cas de panne d'une partie conséquente de leurs moyens matériels.

Hébergement mutualisé

Partage de ressourcesBon marchéFiablePossibilités et ressources

limitées

Serveur dédié

Ressources dédiéesPuissantMauvaise fiabilitéAdministration ?

Évolution verticale(scaling in)

Augmentation des capacités du serveur

Facile à mettre en œuvreFiabilité limitéeRepousse juste la limite

Évolution horizontale(scaling out)

Augmentation du nombre de serveurs

Théoriquement illimitéFiabilité par redondanceComplexe à mettre en œuvre

Anatomie d'un serveur

Matériel

Processeur(s)Mémoire viveDisque(s) dur(s)

Anatomie d'un serveur

Système d'exploitation

Linux, Windows,Mac OS X, Solaris,BSD, ...

Anatomie d'un serveur

Applicatif

Serveur HTTP(Apache, Lighttpd, Nginx, …)

Application(JEE, PHP, Perl, Ruby, .NET, ...)

Anatomie d'un serveur

Stockage de fichiers

Disque dur local

Anatomie d'un serveur

Base de données

MySQL, PostgreSQL,Oracle, SQL Server, DB2, Informix, ...

Applicatif : bonne scalabilité

Installation identique sur chaque serveur

Répartition de charge

Haute disponibilité

Problèmes ?

Base de donnéesStockage de

fichiers

Problèmes ?

Base de donnéesDifficile à répartir et redonder

Technologie “friable”

Problèmes ?

Stockage de fichiersSolutions sans garantie

Solutions très coûteuses

Le vrai problème ?

Le coût !

Les solutions existent

(il suffit d'être millionnaire)

Cluster base de données(ex : Oracle RAC sur serveurs SUN)

Baies de stockage(ex : NetApp)

Frontaux web

Serveurs de fichiers(NAS / SAN)

Base de données(Oracle RAC, MySQL cluster, ...)

Réplication mono-directionnelle

Ces solutions sont chères

Impossible de démarrer un projet en utilisant ces technologies

Ces solutions sont chères

Impossible de démarrer un projet en utilisant ces technologies

Concrètement, on fait quoi ?

Scale in + scale out

Lectures Écritures

Scale in + scale out + réplication

Écritures

Lecturesen local

Réplication

Mais les requêtes SQL sont très gourmandes en ressources

On essaye d'en faire le moins souvent possible

On exécute les requêtes une fois puis on stocke leurs résultats en cache pour les accès suivants

Scale in + scale out + cache

Écritures

Lecturesen cache

Requêtes pour remplir le cache

Avec le cache, les données sont agrégées telles qu'on les utilise dans l'application

Pourquoi ne pas stocker directement les données sous ce format ?

En réduisant les fonctionnalités des bases de données, on peut augmenter leur scalabilité.

Avec le cache, les données sont agrégées telles qu'on les utilise dans l'application

Pourquoi ne pas stocker directement les données sous ce format ?

En réduisant les fonctionnalités des bases de données, on peut augmenter leur scalabilité.

Bases de données non relationnelles

User

- id- name- login

Article

- id- title- content- user_id

Comment

- id- date- text- article_id

{name: "Amaury Bouchard",login: "amaury",articles: [

{title: "Article de test",content: "Bla bla bla",comments: [

{date: "2010-05-20",text: "Super !"

},{

date: "2010-05-21",text: "Génial !"

}]

},{ ... },{ ... }

]}

Solutions SQL alternatives

ShardingDécouper une base en plusieurs morceaux pour alléger et paralléliser les traitements

DénormalisationDupliquer les données pour réduire le nombre de jointures nécessaires

Solutions SQL alternatives

ShardingDécouper une base en plusieurs morceaux pour alléger et paralléliser les traitements

DénormalisationDupliquer les données pour réduire le nombre de jointures nécessaires

Amélioration des performancesInutile pour la haute-disponibilitéEst-ce encore un modèle relationnel ?

Théorème de Brewer

Dans un environnement distribué, il est impossible de garantir à la fois :

La consistanceLa disponibilitéLa tolérance aux pannes

Théorème de Brewer

Dans un environnement distribué, il est impossible de garantir à la fois :

La consistanceLa disponibilitéLa tolérance aux pannes

Haute-disponibilité : consistance réduite

Modèles de duplication de données

CentraliséServeur de méta-données uniqueMultiples serveurs de données

DécentraliséDonnées réparties sur plusieurs serveurs en fonction d'une clé de hachage

Et le cloud computing ?

Virtualisation des serveursUtilisation de ressources à la demande

Participer à des projets intéressants ?

FineFSSystème de fichiers redondé écrit en PHPComplètement décentraliséSynchrone et asynchronePlus rapide que Memcache en lecture

FineDBBase de données non relationnelleOrienté document (stockage JSON)Stockage basé sur FineFS

geek-directeur-technique.com/udm

finefs.googlecode.comfinedb.googlecode.com

amaury@amaury.net