La conférence Agile France ouvrira ses portes au Chalet de la Porte Jaune les 24 et 25 mai. OCTO sera présent avec pas moins de sept sessions cette année.

• Contrôlez vous ce que vous mesurez ? Thomas Lissajoux et Jonathan Scher : faut-il mesurer ce qu’on veut améliorer ? Vous mesurez certainement la vélocité ou les coûts de vos projets, mais à part ça ? Et que se passerait-il si ces données étaient ouvertes et publiques ?
• eXtreme Quotation : le planning poker sous stéroïdes Jonathan Scher et Guillaume Duquesnay : apprenez à estimer 90 stories en moins de 20 minutes, sans perdre en confiance par rapport à un planning poker.
• Des codeuses dans votre équipe ? Guillaume Duquesnay : pourquoi y a-t-il si peu de développeuses dans nos DSI ? Que gagnerait votre équipe en y remédiant ?
• Des outils de coaching pour améliorer la dynamique de votre équipe Jean-François Hélie et Guillaume Duquesnay : un gros projet en situation critique. Un virage vers l’agile réussi. Les outils de coaching qui ont permis à l’équipe de prendre ses responsabilités et s’auto-organiser.
• Agile sur un projet court : êtes vous prêts ? Guillaume Duquesnay et Jonathan Scher : sur un projet de moins de 2 mois, pas le temps de laisser les choses se tasser. Les règles du jeu pour réussir un projet court en agile.
• Entre Technical Leaders : Comment faire un Dojo ? Guillaume Duquesnay et Frederic Merizen : un cercle de pratiques : partageons nos expériences, écrivons ensemble le guide d’un coding dojo réussi.
• Retour d’expérience sur un projet Agile à large échelle Mathieu Despriee et Hervé Lourdin : un projet : 80 personnes sur 9 équipes dans 4 pays. Oui, l’agilité fonctionne pour les gros projets. Voici comment.

Nous suivrons avec intérêt les autres sessions. Quelques highlights :

• Le manager agile : Hors de la zone de confort par Gabriel Le Van
• Mon binôme m’a tuer par Jonathan Perret et Emmanuel Gaillot
• The recent evolution of consumer products par Régis Medina
• Retour d’expérience : Agile contre Cycle en V : Le match par Étienne Charignon

Vous voulez parler d’agilité ? Venez nous rencontrer à Agile France les 24 et 25 mai prochains, les Octos seront présents.

Suggestion d'articles :

1. Octo présente cinq sessions dans le cadre de la conférence Agile France
2. Interview des orateurs OCTO pour la conférence Agile France
3. Octo soutient : Agile Open France 2009

L’aspect incontournable de la performance

Il existe une conviction partagée chez les grands du Web : la performance perçue par l’utilisateur est critique. Cette performance a en effet un impact direct sur l’adoption du service et son utilisation dans la durée. Et le ressenti utilisateur est directement lié à la rapidité d’affichage des interfaces.

Le grand public se moque bien de l’architecture logicielle, de la puissance des serveurs, de la latence réseau provoquée par l’appel à des Web services… Tout ce qui lui importe, c’est l’impression de fluidité dans l’usage.

Les grands du Web l’ont bien compris et parlent ainsi de mesure en “battement de cils”. Tout se joue donc à l’échelle du 1/10^ème de seconde. Leurs études, réalisées notamment grâce à du test A/B (cf. article à ce sujet), le démontrent clairement :

• Amazon : une augmentation de + 100 ms de la latence signifie -1 % de ventes
• Google : plus de 500 ms au chargement signifie – 20 % de trafic (pages vues)
• Yahoo : plus de 400 ms au chargement signifie + 5 à  9 % d’abandon (rebond)
• Bing : plus d’une 1 seconde au chargement signifie – 2,8 % de revenu publicitaire

Comment assurer cette performance

Suivant en cela le Pattern “device agnostic”, les grands du Web développent parfois des interfaces natives, parfois des interfaces Web, afin de toujours offrir la meilleure expérience utilisateur. Dans les deux cas, la performance perçue par l’utilisateur doit être maximisée.

Applications natives

Avec l’iPhone, Apple a réintroduit le développement au plus près du matériel (sans revenir à l’assembleur, tout de même) pour maximiser les performances perçues. Ainsi les technologies Java et Flash sont bannies de l’iPhone. La plateforme utilise aussi des artifices visuels : au lancement d’une application, il peut charger la vue du dernier état de l’application pour maximiser l’impression d’instantanéité, la véritable application étant chargée en tâche de fond. Sur Android, les applications Java sont exécutées sur une machine virtuelle optimisée pour la plateforme. Elles peuvent aussi être écrite en C pour maximiser les performances.

De manière générale, un consensus s’est dessiné autour du développement natif, en particulier sur plateformes mobiles : il doit être au plus près du matériel. Et des technologies multiplateformes comme JME, Flash ou Silverlight tendent à tomber en désuétude pour privilégier l’expérience utilisateur.

Applications Web

Le chargement complet d’un écran Web est souvent de l’ordre de 4 à 10 secondes tout compris (avec les images, le JavaScript, Le Flash, etc.)

Il apparaît que la lenteur d’affichage perçue est généralement liée pour 5% aux traitements sur serveurs, et pour 95% aux traitements du navigateur. Les grands du Web apportent donc un soin tout particulier à l’optimisation de l’affichage des pages Web.

Voici une liste des principales bonnes pratiques qui font consensus :

• Il est crucial de mettre en cache les ressources statiques (les images, les feuilles de style CSS, les scripts JavaScript, les films Flash, etc.) lorsque c’est possible. Il existe pour cela diverses technologies de cache HTTP. L’optimisation de la durée de vie des ressources dans le cache est ainsi une compétence à acquérir.
• Il est recommandé d’utiliser un réseau de cache, ou Content Delivery Network (CDN),  pour placer les ressources au plus près des utilisateurs et limiter l’impact de la latence réseau. Disposer de serveurs de cache dans tous les pays où résident des utilisateurs est vivement recommandé.
• Le chargement en tâche de fond permet de masquer la lenteur d’affichage de certains éléments de la page.
• Une pratique, très fréquente consiste à utiliser des “sprites” : il s’agit d’agréger des images dans un même fichier pour limiter le nombre de ressources à charger ; elles seront ensuite découpées à la volée par le navigateur (voir l’exemple Gmail ci dessous).
• Le recours à des noms de domaines multiples permet de maximiser la parallélisation dans le chargement simultané de ressources par le navigateur. En effet, les navigateurs sont soumis à un nombre maximal de requêtes simultanées sur un même domaine. Ainsi Yahoo.fr charge ses images à partir de l.yimg.com
• Placer les ressources JavaScript en toute fin de page pour que le visuel apparaisse le plus vite possible
• Minifier, c’est à dire supprimer du code tous les caractères (retour chariot, commentaires) servant à la relecture mais pas l’exécution du code.
• Compacter les différents fichiers de code source tels que JavaScript dans un seul fichier, quand c’est possible

Chez qui ça fonctionne ?

Les exemples d’usage du pattern sont nombreux chez les grands du Web : on peut citer Google, Gmail, Amazon, Yahoo, …

Les références chez les grands du Web

Google possède le réseau de cache distribué le plus maillé des grands du Web : le géant de la recherche disposerait de machines dans toutes les grandes villes, et même d’un réseau privé mondial, selon des rumeurs difficiles à vérifier.

Google Search pousse l’expérience utilisateur temps réel très loin avec “Instant Search” qui charge les résultats de recherche au fur et à mesure de la frappe clavier. Cette fonction est une prouesse technique : elle a soulevé nombre de questions dans la communauté des architectes (cf. liens ci dessous).

Gmail est construit quasiment en HTML : les images de l‘interface sont réduites au strict nécessaire (2 “sprites” d’icônes, voir ci dessous), et  le site fait un usage extensif du cache et du chargement JavaScript en tâche de fond.

France

Sites utilisant ou ayant utilisé le réseau de cache distribué (CDN) Akamai :

• cite-sciences.fr
• LeMonde.fr
• Allocine.com
• UrbanDive.com

Et chez moi ?

L’effet de la latence d’affichage est le même sur les applications internes, propres à une DSI : exaspération des utilisateurs et abandon du recours à l’application.

Le pattern s’applique donc parfaitement en interne.

Exceptions !

Elles sont rares : on peut évoquer les applications asynchrones et les batchs.

Sources

• Présentation “Performance des applications web, quoi faire et pourquoi ?” lors de l’USI 2010 : http://goo.gl/C57B8

• Article sur Google Instant Search : http://highscalability.com/blog/2010/9/9/how-did-google-instant-become-faster-with-5-7x-more-results.html
• http://googleblog.blogspot.com/2010/09/google-instant-behind-scenes.html

Suggestion d'articles :

1. Les Patterns des Grands du Web – Sharding
2. Les Patterns des Grands du Web : « OpenAPI » ou écosystème ouvert
3. Les Patterns des Grands du Web – Test A/B

Prenons d’abord les précautions d’usage: il ne reflète que nos opinions personnelles et pas celles de notre employeur.

4G = tout IP

Les nouveaux réseaux 4G seront des réseaux full IP. Même la voix n’est plus qu’un service parmi d’autres, construits sur la stack IP, qui a décidément bien réussi à enterrer les protocoles de la téléphonie traditionnelle… Cela tend à simplifier l’architecture réseaux des opérateurs : plus de MSC par exemple. Quel est l’impact de ce changement de protocole ? Les opérateurs n’auront plus la maîtrise de certains services. Quelques exemples : iCloud qui remplace les SMS, Viber ou Skype qui remplace le téléphone.

L’opérateur mobile devient donc un opérateur IP. Or le business model des opérateurs IP (des entreprises inconnues du grand public), est différent des opérateurs grand public : il est entièrement orienté tuyau : pas ou très peu de services à valeur ajoutée, facturation à la bande passante ou au volume de donnée transporté… Les seuls services que vendent ces opérateurs sont des services « techniques » de communication : hosting, routage… Rien qui puisse intéresser le grand public ni faire la différence entre deux offres, si ce n’est la qualité du réseau en terme de couverture et de débit.

Les services

Nous sommes toujours surpris quand nous découvrons les interfaces web offertes par les opérateurs pour consulter sa messagerie @mon_opérateur.fr. Quel retard face à Gmail, Windows Live, ou Yahoo ! Ce genre de service n’est pas, et, pour nous, ne sera jamais le « core business » d’un opérateur. De plus, un opérateur ne pourra pas concurrencer les « pure players » sur ce terrain. Un exemple : une offre de vidéo à la demande. Certes la proximité du réseau va avantager l’opérateur en termes de performances. Mais en termes de fonctionnalité et de catalogue, un acteur spécialisé s’en sortira mieux qu’un opérateur, puisqu’il ne fait que ça. Par ailleurs, la réglementation de l’Arcep permet, en France, de changer facilement d’opérateur. Du coup, pourquoi choisir un service lié à un opérateur, plutôt qu’un autre, indépendant de l’opérateur, multi-device et donc accessible sur un téléphone Android, sur un iPad ou sur son ordinateur ? A ce titre, certains opérateurs ont des partenariats (deezer, canalplus) et proposent ces services dans leurs catalogues. Ce service n’est cependant pas lié à l’opérateur.

D’un autre côté, ayant le contrôle du réseau, les opérateurs sont capables d’offrir de meilleurs performances à certains fournisseurs de services ou de garantir des performances à leurs utilisateurs. L’utilisation de tels systèmes peut, dans certains cas, porter atteinte à la neutralité du réseau. Un exemple : Orange propose un abonnement Deezer. Depuis un portable Orange, la QoS (Quality Of Service) vers Deezer devrait donc être meilleure que vers Spotify ou autre (soit dit en passant, le problème se pose déjà sur l’ADSL, ou certains opérateurs limitaient le débit vers certains services : au hasard feu MegaUpload, ou à un certain moment, DailyMotion). Pour un opérateur télécom, fournir un service et assurer la neutralité du réseau est donc un exercice difficile, voire impossible : favoriser le service que l’on vend sans défavoriser les concurrents de ce service…

Y a-t-il des services qui seraient vraiment plus efficaces proposés par un opérateur, plutôt que par un tiers sur Internet ? Personnellement, pour un usage grand public, nous n’en voyons pas, du moins en full-IP comme sur la 4G. Même la TV devrait pouvoir passer normalement sur de la 4G, de la même façon que sur Internet. Et si les opérateurs proposent des services avec de meilleures performances, on revient au problème évoqué ci-dessus sur la neutralité du réseau. Les services sur lesquels les opérateurs devraient garder la main sont des services « bas niveau », très liés au réseau : géolocalisation, authentification, identification, paiement… Ces services sont des briques sur lesquels les fournisseurs de services de plus haut niveau pourront s’appuyer pour améliorer leur offre.

Relation client

Les opérateurs actuels gèrent la relation client. Ils peuvent utiliser cette position pour leur fournir des services à valeur ajoutée. Il est néanmoins probable que cet avantage se réduise. Apple et Google gèrent aussi des clients, via IOS et iTunes, Android et GoogleApps. Facebook et Twitter aussi. La part de ces acteurs « nouveaux » va s’amplifier, au détriment des opérateurs, car la valeur de leur marque est souvent plus puissante que celle des opérateurs pour attirer les clients à utiliser leur service. Un exemple, la messagerie visuelle de l’iPhone : c’est Apple qui a imposé aux opérateurs la façon de travailler. Un autre exemple : on assiste souvent à des débats sans fin iPhone versus Android. Rarement à des débats Orange versus SFR versus Bouyges Telecom. Ce choix-là ne se faisant généralement plus que sur le prix, ou la qualité du réseau.

Dans ce nouveau modèle économique que l’OCDE désigne comme modèle de la « connectivité sponsorisée », la relation entre le client et le fournisseur d’accès n’existe pas, la relation client étant portée par le prestataire de service. Cette transformation a déjà eu lieu pour Tomtom Live services ou Kindle Amazon, l’utilisateur n’a pas d’abonnement à un opérateur et ne sait pas quel est l’opérateur utilisé. L’opérateur télécom devient fournisseur d’infrastructure, et le fournisseur de service ou de terminal électronique (désigné comme « device subscriber ») package l’accès au réseau dans son produit. Il est intéressant de constater qu’en seulement 1 an, chez AT&T, le nombre d’abonnement lié aux « device subscribers » a plus que doublé en passant de 3,3 Millions à 7,8 millions soit environ 9% du total de leur souscriptions d’abonnement mobiles .

Conclusion

Que va-t-il se passer ? Le plus probable est que, hélas, nous assistions à la fin de la neutralité des réseaux. Pour compenser les coûts induits par la toujours plus grande consommation de bande passante, les opérateurs vont probablement vendre des services sans maintenir l’équité de entre fournisseurs. Le bras de fer entre les opérateurs et les défenseurs de la neutralité est en cours… Une neutralité maintenue et revendiquée pourrait alors devenir un argument commercial.

Un autre scénario est que les opérateurs recentrent leur business model autour du modèle fournisseur de tuyau, voir fournisseur de tuyau ++ (avec les services / API de bas niveau évoqué ci-dessus). Cela leur permettrait de réduire leur coûts en terme de complexité d’offre, de marketing, de développement de services, et de se recentrer sur leur « core business », le réseau. Egalement de se positionner les uns par rapport aux autres sur le plus important : la qualité de l’accès réseau.

Suggestion d'articles :

1. Combien de temps doit prendre un build Maven ?

Le sharding décrit ainsi un ensemble de techniques qui permet de répartir les données sur plusieurs machines pour assurer la scalabilité de l’architecture.

Les besoins 

Avant de détailler l’implémentation, revenons sur les besoins d’origine. On retrouve chez les grands du web plusieurs problématiques communes assez connues : le stockage et l’analyse d’énormes quantités de données, [2],  des enjeux forts de performance pour avoir des temps de réponse faibles, des enjeux de scalabilité [3] voire d’élasticité [4] liés aux pics de consultation.

Je souhaiterais insister sur une particularité de ce type d’acteur qui sous-tend nombre des problématiques précédentes. La rémunération des grands du web est bien souvent indépendante de la quantité de données manipulées : rémunération par la publicité, facturation de l’utilisateur au forfait [5]. Cela nécessite d’avoir un coût unitaire par transaction très faible. En effet, dans un SI classique, une transaction peut facilement être rattachée à un flux physique (vente, stockage d’un produit). Ce flux permet d’avoir une facturation du SI proportionnelle au nombre de transactions (conceptuellement par une sorte de taxe). Mais sur un site de commerce marchand par exemple, chaque consultation du catalogue ou ajout dans le panier ne générera pas forcément du revenu car l’utilisateur peut quitter le site juste avant la validation du paiement.

En somme, les Systèmes d’Information des grands du web sont contraints d’assurer une scalabilité à coût marginal très faible pour répondre à leur business mode

Le sharding pour diminuer les coûts

Les bases de données restent encore majoritairement sur  un modèle centralisé : un serveur unique, éventuellement redondé en mode actif/passif pour la disponibilité.  La solution la plus courante pour supporter plus de transactions est la scalabilité verticale ou « scale up » : acheter une machine plus puissante (plus d’IO, de CPU, de RAM…)

Cependant cette approche présente des limitations : une seule machine très puissante ne peut pas suffire pour indexer le web.

Mais au-delà de cela, c’est souvent l’aspect coût et investissement qui conduit à rechercher une autre approche.

Une étude [6] menée par des ingénieurs de Google montre que dès que la charge dépasse la taille d’un grand système, le coût unitaire sur des grands systèmes est très supérieur au coût unitaire sur des machines de grande série [7].

Même si l’équation pour comparer des coûts par transaction n’est pas simple à poser et peut être sujette à débat  – complexification de l’architecture, charge réseau à prendre en compte dans les coûts – les grands du web ont largement choisi d’utiliser des machines de grande série.

Pour mettre en œuvre cette scalabilité horizontale, le sharding devient nécessaire.

L’implémentation du sharding

Il existe de fait 2 façons de partitionner (« sharder ») la donnée : verticalement ou horizontalement.

Le partitionnement vertical est le plus communément utilisé : il s’agit d’isoler, de séparer des concepts métier. Par exemple, on décidera de stocker les clients sur une base et leur contrat sur une autre.

La notion de partitionnement horizontal renvoie à l’idée de répartir l’ensemble des enregistrements d’une table (au sens d’une base de données) sur plusieurs machines. Ainsi, on choisira par exemple de stocker les clients de A à M sur une machine #1 et les clients de N à Z sur une autre machine #2.  Le sharding horizontal nécessite une clé de répartition – la première lettre du nom dans l’exemple.

C’est principalement le type de sharding horizontal qui est mis en œuvre chez les grands du web. Il présente notamment l’avantage de ne pas être limité par le nombre de concepts comme c’est le cas pour le sharding vertical.

Figure 1

Les techniques liées au sharding

Les grands du web ont, sur la base de ce choix de scalabilité horizontale, développé des solutions spécifiques (regroupées sous l’acronyme NoSQL) répondant à ces enjeux  et ayant les caractéristiques suivantes :

• une implémentation à partir de machines de grande série
• une distribution (sharding) des données gérées au niveau du logiciel.

Si le sharding permet de répondre aux problèmes évoqués plus haut, il nécessite aussi de mettre en œuvre de nouvelles techniques.

• La gestion de la disponibilité, devient plus complexe. Dans un système centralisé ou considéré comme tel, le système est disponible ou indisponible et on ne mesurera qu’un taux d’indisponibilité. Dans un système shardé, certains nœuds peuvent être disponibles et d’autres indisponibles. Si la chute d’un seul nœud rend tout le système indisponible, le taux d’indisponibilité est égal au produit de l’indisponibilité de chacun des nœuds. Ce taux va ainsi chuter très rapidement : 100 machines indisponibles chacune 1 jour par an donneront un système avec près de 3 mois d’indisponibilité [8]. Si le système distribué est capable de rester disponible malgré la chute d’un des nœuds mais avec un service dégradé, la disponibilité devra alors être mesurée par deux chiffres : le yield – le taux d’indisponibilité défini précédemment – et le harvest – la complétude de la réponse qui mesure en quelque sorte l’absence d’indisponibilité [9].
• La répartition de la charge  devra  être généralement adaptée à l’utilisation qui est faite des données. Ainsi un référentiel produit (massivement accédé en lecture) n’aura pas les mêmes enjeux de performance qu’un caddie virtuel (massivement accédé en écriture). Le taux de réplication par exemple ne sera pas le même dans ces deux cas.
• Ensuite la gestion de l’ajout de nouveaux nœuds et des problèmes de répartition de la donnée (rééquilibrage du cluster) sont de nouveaux problèmes spécifiques au sharding. Foursquare, par exemple, a subi une indisponibilité de 11 heures en octobre 2010 [10] suite à une surcharge d’un des nœuds puis à des soucis lors de l’ajout du nœud de secours qui a finalement causé la chute complète du site.  Des algorithmes de répartition des données comme le consistent hashing [11]  limitent ainsi le coût de recopie des données lors de l’ajout ou le retrait d’un nœud pour répondre à ces problématiques.

Le sharding nécessite également d’adapter les architectures applicatives :

• les requêtes doivent être adaptées pour tenir compte de la distribution, notamment en évitant toute requête inter-shard car le coût d’accès à plusieurs nœuds distant est prohibitif. Les APIs de ces systèmes limitent ainsi les possibilités de jointure à des données situées sur le même shard.
• Que l’on utilise des bases relationnelles ou des systèmes types NoSQL, la modélisation est mise à mal et on se limite majoritairement dans ces systèmes à une modélisation du niveau clé/valeur, clé/document ou en familles de colonnes pour lesquelles la clé ou l’index de ligne servent de clé de partitionnement.
• L’atomicité (le A de ACID) est souvent limitée afin d’éviter des mises à jour atomiques incluant plusieurs shards et donc des transactions distribuées sur plusieurs machines coûteuses en performance.

Chez qui ça fonctionne ?

La mise en œuvre de ces techniques diffère entre les acteurs. Certains ont simplement adapté leurs bases de données pour faciliter le sharding. D’autres ont écrit des solutions NoSQL qui leur sont propre. En suivant ce cheminement de SQL à NoSQL je vous propose de découvrir quelques implémentations représentatives :

Wikipédia

La célèbre encyclopédie collaborative est basée sur de nombreuses instances de MySQL réparties et un cache mémoire memcached. C’est ainsi un exemple de mise en œuvre du sharding avec des composants assez répandus.

Figure 2

L’architecture utilise d’une part la réplication maître esclave pour séparer les charges de lecture et d’écriture et en partitionne d’autre part les données par Wiki et par cas d’utilisation. Le texte des articles est également déporté dans des instances dédiées. Ils utilisent ainsi des instances MySQL avec 200 à 300 GB de données.

Flickr

L’architecture de ce site de partage de photos est basée là aussi  sur une organisation de plusieurs instances MySQL (les shards) maîtres et esclaves mais cette fois autour d’un anneau de réplication pour faciliter l’ajout de noeuds.

Figure 3

Un identifiant sert de clé de partitionnement (le plus souvent l’identifiant du propriétaire de la photo) qui répartit les données sur les différentes machines. En cas de chute d’un nœud, les écritures sont redirigées vers le nœud suivant sur l’anneau. Chaque instance sur l’anneau est également répliquée sur deux nœuds esclaves qui servent en lecture seule en cas de chute du nœud master associé.

Facebook

L’architecture de Facebook présente l’intérêt de montrer l’évolution d’une base relationnelle vers un modèle complètement distribué.

Facebook a ainsi débuté en se basant sur MySQL, solution Open Source très efficace. Ils ont ensuite mis en œuvre un ensemble d’extensions permettant de partitionner les données.

Figure 4

Désormais tout stockage de données de façon centralisée est banni dans l’architecture Facebook. Un accès centralisé est assuré par du cache (Memcached) ou un service spécialisé. L’architecture retenue continue d’utiliser MySQL mais uniquement comme système de stockage. Le système de réplication de MySQL est également utilisé après extension pour répliquer les instances entre plusieurs datacenters. Cependant son utilisation est très éloignée d’une base de données relationnelle. Les données sont accédées uniquement sous forme clé/valeur.  Plus aucune jointure n’est réalisée à ce niveau. Enfin la structure des données est prise en compte pour colocaliser les données utilisées simultanément.

Amazon

L’architecture Amazon se distingue par une gestion plus avancée de la perte d’un ou plusieurs nœuds sur Dynamo.

Amazon a débuté dans les années 1990 avec un seul serveur web et une base de données Oracle. Ils ont ensuite mis en place un ensemble de services métiers en 2001 avec des stockages indépendants. A côté des bases de données, deux systèmes utilisent le sharding : S3 et Dynamo.  S3 est un stockage de BLOB sur Internet identifié par une URL. Dynamo (utilisé en interne puis très récemment proposé sur Amazon Web Services) est un système de stockage clé/valeur distribué, réparti,  destiné à assurer une très haute disponibilité et des temps de réponse très faibles.

Afin de privilégier la disponibilité sur Dynamo, plusieurs versions d’une même donnée peuvent coexister : on parle de cohérence « à terme » (eventual consistency) [12].

Figure 5

A la lecture, un algorithme comme le vector clock ou en dernier recours l’application cliente devront résoudre le conflit. Le curseur peut être également ajusté entre la réplication pour tolérer la perte d’un nœud et les performances du système.

LinkedIn

Le cheminement de LinkedIn présente des similitudes avec Amazon : sortie d’une approche monobase en 2003, un découpage en service et la mise en place d’un système distribué avec des concepts similaires à Dynamo : Voldemort. Contrairement à Dynamo, il est open source. A noter : les index et graphes sociaux ont toujours été stockés de façon séparée chez LinkedIn.

Google

Google a, le premier, publié des informations sur son système de stockage distribué. Celui-ci tire ses gênes non pas des bases de données mais des systèmes de fichiers.

Google évoque dans sa publication [13] sur le Google File System (GFS) les faiblesses précédemment observées et le choix structurant du commodity hardware. Ce système de fichier distribué sert directement, ou indirectement, aux stockages des données chez Google (index, mail).

Figure 6

Son architecture repose sur un serveur de métadonnées centralisé (pour orienter l’application cliente) et un très grand nombre de serveurs de stockage. Le degré de consistance des données est inférieur à ce que peut garantir un système de fichiers classique, mais ce point à lui tout seul pourrait faire l’objet d’un article. Google utilise en production des clusters de plusieurs centaines de machines lui permettant ainsi de stocker des petabytes de données à indexer.

Exceptions

Il est cependant indéniable qu’un nombre important de sites restent sur des technologies de base de données relationnelle sans sharding (ou sans communiquer sur le sujet) : Stack Overflow, SalesForce, Voyages-SNCF, Vente privées… La liste est difficilement exhaustive dans un cas comme dans l’autre. Pourtant nous pensons que le sharding est désormais une stratégie classique sur les sites web à grand trafic. En effet, l’architecture de SalesForce est certes basée sur une base de données Oracle, mais elle utilise la base de données de façon très différente des pratiques qui ont cours dans nos SI : tables avec une multitude de colonnes non typées et nommées de façon générique (col1, col2), moteur d’exécution des requêtes en amont de celui d’Oracle pour prendre en compte ces spécificités… Les optimisations montrent les limites d’une pure architecture relationnelle. L’exception la plus marquante vient selon nous de chez StackOverflow, dont l’architecture repose sur une unique base relationnelle SQL Serveur. Ce site a entièrement fait le choix d’une architecture basée sur la scalabilité verticale, leur architecture initialement inspirée de Wikipédia ayant évolué pour mieux se conformer à cette stratégie. Face à cela, il faut noter que le besoin en scalabilité de StackOverflow n’est pas forcément comparable à celui d’autres sites car la communauté ciblée (celle des experts en informatique) est assez limitée, et le modèle favorise la qualité des contributions à leur quantité. Par ailleurs, le choix d’une plateforme sous licence Microsoft, leur offre un outil efficace mais pour lequel les coûts de licences deviendraient probablement prohibitifs en cas de scalabilité horizontale.

Et dans mon entreprise ?

La distribution des données est l’une des clés qui a permis aux grands du web d’atteindre leur taille actuelle et de fournir des services qu’aucune autre architecture ne pourrait supporter. Mais qu’on ne s’y trompe pas, ce n’est pas un exercice facile : des problématiques toutes simples dans le monde relationnel (jointures, consistance de la donnée) demandent la maîtrise de nouveaux outils ou de nouvelles méthodes.

Les domaines avec de forts enjeux de volumétrie mais des enjeux de consistance limités – cas des données partitionnables notamment – sont ceux pour lesquels la distribution des données aura le plus de bénéfice. Des offres autour de Hadoop utilisent ses principes et sont pertinentes dans la BI et plus particulièrement dans l’analyse de données non structurées. Côté transactionnel, les problématiques de consistance sont plus importantes.  Les contraintes sur les API d’accès sont aussi limitantes mais de nouvelles offres comme SQLFire de VMWare ou NuoDB tentent de mixer sharding et interface SQL. A suivre donc.

En somme, il faut se demander quelles sont les données utilisées dans un même use case (quelle partition est possible ?) et quelles seraient pour chaque donnée les conséquences d’une perte de consistance ? En fonction de ces réponses, vous pourrez identifier vos grands enjeux d’architecture qui vous permettront de choisir, au-delà de la seule problématique de sharding, l’outil qui répondra le mieux à vos besoins. Plus qu’une solution magique, le partitionnement des données doit être abordé comme un outil permettant de franchir des frontières de scalabilité inaccessibles sans son utilisation.

Pattern connexes

L’utilisation de produits Open Source ou maison, maîtrisés en interne, est inextricablement liée à l’utilisation du partitionnement des données du fait du tuning très fin requis.  Le modèle transactionnel ACID est également remis en question par le partitionnement des données.  Le pattern Eventually Consistent (consistance finale) propose une autre vision et une autre façon de répondre au besoin des utilisateurs tout en tolérant cette remise en question. Là encore, une maîtrise de ce pattern est très utile pour mettre en œuvre la distribution des données. Enfin et surtout, le sharding est indissociable du choix du commodity hardware fait par les grands du web.

Sources

• http://blog.octo.com/datacenter-as-a-computer-une-plongee-dans-les-datacenters-des-acteurs-du-cloud/
• http://www.worldwidewebsize.com/
• http://www.tpc.org/results/individual_results/Oracle/Oracle_SPARC_SuperCluster_with_T3-4s_TPC-C_ES_120210.pdf
• http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/fr//papers/gfs-sosp2003.pdf
• http://www.paragon-cs.com/wordpress/?p=144

Définition

• http://en.wikipedia.org/wiki/Shard_(database_architecture)
• http://en.wikipedia.org/wiki/Partition_%28database%29

Wikipedia

• http://www.codefutures.com/weblog/database-sharding/2008/06/wikipedias-scalability-architecture.html

eBay

• http://www.codefutures.com/weblog/database-sharding/2008/05/database-sharding-at-ebay.html

Friendster and Flickr

• http://www.codefutures.com/weblog/database-sharding/2007/09/database-sharding-at-friendster-and.html

HighScalability

• http://highscalability.com/

Amazon

• http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

Suggestion d'articles :

1. Les patterns des grands du Web – Fluidité de l’expérience l’utilisateur
2. Les Patterns des Grands du Web : « OpenAPI » ou écosystème ouvert
3. Les Patterns des Grands du Web – Test A/B

Puis un jour, on a jeté un œil sur le graphe de temps de chargement de notre appli – merci Google Analytics. Et là le drame : une moyenne de plus de 5 secondes pour la page d’accueil, et je ne vous parle pas sur mobile. On se dépêche alors d’aller faire un petit tour sur Google Pagespeed, notre score : 44/100 (bof bof).

On décide d’investiguer point par point nos hypothèses, en voici un résumé.

Les faux problèmes – a.k.a. de la pub pour Rails

1 JavaScript pour tous les gouverner. Ça marche aussi avec le CSS!

On est en Rails 3.2, on a donc l’asset pipeline qui nous compresse nos JS et CSS en un seul fichier, merci Rails.

Tu rendras ton JS & tes CSS minimal (& illisible)

De même, l’asset pipeline est notre ami, il minifie les JS et CSS tout seul. Ça enlève tous les caractères inutiles, sans changer le fonctionnel, pour réduire les temps de transfert. Accessoirement ça sert aussi d’offuscation sur notre code. Encore merci Rails.

Et les vrais problèmes ?

Tu utiliseras le cache du navigateur

Là pas merci Heroku. Avant, il y avait varnish qui était devant vos serveurs et il faisait la magie tout seul. Sur la nouvelle stack Heroku (Cedar), varnish a disparu. Il faut donc le faire à la main. Ici on a plusieurs solutions :

• Mettre les assets sur un CDN
• Utiliser un autre système de cache

On a préféré la deuxième solution, en mettant en cache nos assets dans un memcache. Ce n’est pas compliqué à faire, il y a un tutoriel. On peut se permettre de mettre une durée de cache très grande, car à chaque déploiement Rails regénère les assets avec un nom différent. Et donc le navigateur ne gardera en cache que les derniers assets.

On a choisi cette solution pour une seule raison. On n’a pas de compte AWS, pas forcément les moyens d’en avoir un rapidement (process d’achat). On a donc opté pour la solution la plus rapide à mettre en place.

Tu compresseras tes JS/CSS

Là c’est facile, il suffit de rajouter un engine à rails qui va gziper les requêtes sortantes si le client cible supporte le gzip. On rajoute donc juste Rack::Deflater dans le fichier config.ru :

 # This file is used by Rack-based servers to start the application.
require ::File.expand_path('../config/environment',  __FILE__)
use Rack::Deflater # Required for Heroku CEDAR stack
run ChooseYourBoss::Application

Des sprites tu créeras

Dans le but de minimiser le nombre de requêtes entre le client et le serveur, on a voulu mettre en sprites nos images. Les sprites à la main c’est c’est long, ennuyeux, sujets à erreur, et à recommencer dès que l’on rajoute une image. Heureusement pour nous, la gem compass permet de faire des sprites automatiquement. En plus, c’est cool, on fait du SASS et compass est en SASS.

Son utilisation est assez simple :

• Rajouter compas comme dépendance, ainsi que oily_png pour la génération du sprinte en png
• Mettre toutes les images à spriter dans un répertoire : sprites/ pour nous
• Dans un fichier SASS :
• Indiquer que l’on veut qu’il optimise l’agencement des images dans notre sprite : $sprites-layout: smart;
• Inclure toute les images de notre répertoire : @import « sprites/*.png »;
• Générer le css / sprite : @include all-sprites-sprites;

Tout ceci va générer une classe CSS par image, avec ce qu’il faut dedans. Ex : Mon image sprites/toto.png va générer la classe .sprites-toto.

Pour plus de détails, la doc peut vous éclairer.

Du chargement JS en bas de page tu feras

Un grand classique, on a mis nos JS tout à la fin de notre page HTML, ce qui permet de ne les charger qu’après le chargement de l’HTML et du CSS.

Du chargement JS asynchrone tu ferras

C’est bien le JS en bas de page, mais à cause nos boutons like Facebook et follow Twitter, on chargeait respectivement 200ko et 100ko de JS en plus dans notre page, ce qui bloquait son chargement. On a donc passé le chargement de ces 2 boutons en asynchrone. Attention, nos exemples sont en CoffeeScript.

Pour Facebook :

id = 'facebook-jssdk'
ref = document.getElementsByTagName('script')[0]
return if document.getElementById(id)
js = document.createElement('script')
js.id = id
js.async = true
js.src = "//connect.facebook.net/en_US/all.js#xfbml=1"
ref.parentNode.insertBefore(js, ref)

Même chose pour Twitter

id = 'twitter-jssdk'
ref = document.getElementsByTagName('script')[0]
return if document.getElementById(id)
js = document.createElement('script')
js.id = id
js.async = true
js.src = "//platform.twitter.com/widgets.js"
ref.parentNode.insertBefore(js, ref)

De même, on a rajouté l’attribut async sur nos balises script. Ce qui permet de charger les assets en asynchrone, merci HTML5 :

= javascript_include_tag "application", async: true

Du chargement JS asynchrone tu referas

On avait fait de belles optimisations, sauf que notre site était cassé 1 requête sur 2. En effet, notre JS dépend de l’API de Google Maps. Et une fois sur deux l’API était chargée après notre js, donc on obtenait des erreurs.
Il a fallut donc trouver une autre solution pour le chargement en asynchrone. Et la, on a utilisé une petite lib nommée head.js, qui permet de faire du chargement asynchrone d’assets, mais de garantir leur ordre d’exécution.

On a donc en rails :

= javascript_include_tag "loader", async: true

loader correspond à un fichier JS qui inclus head.js en premier, puis notre fichier de chargement de JS spécifique, attention c’est du CoffeeScript avec de l’ERB (un language de template pour Ruby) :

@CYB = @CYB || {} #On déclare notre namespace global JS.

<% if Rails.env.production? %>
#Le JS de notre application
application_path = '<%= javascript_path "application" %>'

#Chemins vers nos différentes lib JS
gmaps_path = '<%= "https://maps.googleapis.com/maps/api/js?key=#{GMAPS_BROWSER}&sensor=false" %>'
viadeo_path = 'http://cdn.viadeo.com/javascript/sdk.js'
linkedin_path = 'http://platform.linkedin.com/in.js?async=true'

#Le chargement par head.js
head.js gmaps_path, viadeo_path, linkedin_path, application_path
<% end %>

Le seul problème c’est que tout ça, ne marche qu’en mode production, il faut donc rajouter le bout de code suivant pour avoir tous vos JS en mode dev. Re attention, c’est du HAML :

- options = {}
- options = {async: true} if Rails.env.production?
= javascript_include_tag "loader", options

- #We need this, because head.js can not generate all the JS assets in dev & test
- unless Rails.env.production?
  = javascript_include_tag "https://maps.googleapis.com/maps/api/js?key=#{GMAPS_BROWSER}&sensor=false"
  = javascript_include_tag 'http://cdn.viadeo.com/javascript/sdk.js'
  = javascript_include_tag 'http://platform.linkedin.com/in.js?async=true'
  = javascript_include_tag "application"

Oui, il y a de la duplication, mais c’est facile à corriger. A savoir que ce mécanisme de chargement asynchrone peut être aussi mis en jeu si vous utilisez d’autres médias (ex : une pub, une vidéo, etc.)

Des images tu supprimeras

On avait pas mal d’images sur notre site, et les images (même en sprite) c’est gros. Donc on a tenté au maximum de les remplacer par du CSS. On a abusé des pseudos élément ::before et ::after qui permettent de rajouter des éléments html mais que visible dans le css. Ce qui permet, par exemple de créée des puces pour une liste à partir d’un dessin fait en css, ou d’un texte spécifique. Ce qui nous permet de transformer 2ko d’image en quelques lignes de SASS.

Ex :

#mon_id {
  ul {
    list-style: none;
  }
  li::before {
    content: "\02713";
    margin-right: 10px;
    font-size: 1.3em;
  }
}

Des webfonts tu chargeras en asynchrone (ou pas)

Comme on a un site bleeding edge (web 3.5, HTML10.3 et CSS14.2 au minimum), on utilise des webfonts pour avoir des polices plus sympas. C’est bien beau tout ça, mais c’est long à télécharger. On avait déjà décidé de n’utiliser que des polices venant de Google webfonts, ce qui nous permettait de profiter des CDN de Google. On a donc suivi la procédure sur leur site pour rendre le chargement asynchrone.

Mais, en fait ça donnait un rendu étrange à notre page. En effet, la page était affichée avec certaines polices, et d’un coup elles changeaient toutes pour les webfonts.

On a donc décidé de remettre leur chargement en synchrone.

Conclusion

Toutes ses optimisations nous ont pris entre 2-3 jh et nous ont permis de passer notre score Google pagespeed de 44/100 à 94/100, y compris sur mobile.

Pagespeed nous donne encore quelques points d’amélioration, mais ceux-ci sont majoritairement indépendants de nous. Par exemple, le JS de twitter n’est mis en cache que 30 minutes.

Notre prochaine étape est donc indéterminée. Par contre, nous avons un indicateur de qualité produit que nous ne négligerons plus.

Suggestion d'articles :

1. Platform as a Service avec Ruby on Rails
2. Rails += Tests
3. Présentation Rails au Paris JUG

• Présenter les bases du caching HTTP
• Présenter les nouvelles fonctionnalités que j’ai implémentées dans le module Nginx Memcached pour faciliter le caching HTTP sur les serveurs

Un cache c’est quoi ?

Les caches sont utilisés pour améliorer les performances d’accès à une ressource. Cette amélioration peut se faire de 2 manière.

La première est de réduire le temps d’accès à la ressource en copiant la ressource au plus prês de son utilisateur. Quelques exemples : le cache L2 d’un processeur, le cache de base de données, le cache de navigateur web, un CDN.

La deuxième est d’accélérer la construction de la ressource en réduisant son nombre d’accès : par exemple, on va mettre en cache la page d’accueil d’un blog, pour qu’elle ne soit pas reconstruite à toutes les requêtes, mais seulement toutes les 30 secondes. C’est ce principe que nous allons maintenant étudier : un cache HTTP.

Le cache HTTP

Architecture

Le cache HTTP se place généralement devant votre serveur web. Cela donne une architecture qui ressemble à ça :

Le principe est le suivant : pour une URL donnée, le cache HTTP va demander la page au serveur web à la première requête d’un client, puis va stocker cette page et la servir pour les requêtes suivantes. Comme on l’a expliqué ci dessus, cela permet d’alléger la charge sur le serveur web, et d’accélérer le site, puisque la page n’est plus calculée dynamiquement, mais juste sortie du cache.

Il y a de nombreuses implémentations de cache HTTP. Les plus connues sont

• Varnish
• Squid
• Nginx avec cache sur disque
• Apache2 avec cache sur disque

Comment cela marche ?

C’est assez simple : le cache HTTP va réutiliser les headers de cache HTTP prévus pour le cache du navigateur du client. Par exemple, si votre serveur web renvoie pour une URL donnée un header HTTP : Expires: Thu, 31 Dec 2037 23:55:55 GMT, cela indique que cette ressource ne sera pas modifiée avant le 31 décembre 2037. Et cela permet donc à tous les utilisateurs de cette ressource de la récupérer une seule fois et de la stocker jusqu’à sa date d’expiration. C’est exactement ce que va faire le cache HTTP.

En plus de Expires, il existe d’autres headers HTTP impliqués dans les mécanismes de cache, notamment Cache-Control et Vary. Je vous invite à consulter la RFC 2616 pour plus de détails. Et hélas, c’est un domaine assez compliqué : les différents navigateurs / reverse proxy / cache HTTP ne gèrent pas ces headers de la même manière.

L’architecture simplifiée d’un cache HTTP est donc la suivante :

Un point important à noter est que le cache HTTP ne va pas stocker seulement le contenu de l’URL, il va aussi stocker des headers HTTP, des temps d’expiration …

Certains produits permettent de configurer le caching sans utiliser les headers, si on ne veut pas (ou on ne peut pas) modifier son application. Voir par exemple la VCL de varnish. Je vous invite cependant à utiliser les headers HTTP, car c’est standard et plus simple à déployer (tout est dans l’applicatif).

Dans les implémentations ci dessus, Varnish et Squid vont être des démons séparés du serveur Web. Ces deux outils vont faire du caching en mémoire et/ou sur disque. Apache2 et Nginx vont pouvoir faire du caching HTTP, directement dans le serveur Web. La différence de performances ne sera pas gigantesque (au moins coté Nginx). L’architecture avec un cache séparée a cependant d’autres avantages. Elle permet de mutualiser le cache entre plusieurs applications, ou de lui confier d’autres fonctions : load balancing, aiguillage des certaines urls sur des serveurs spécifiques …

Limitations

Le système de cache fonctionne tellement bien qu’on va souvent chercher à lui faire faire autre chose. Prenons un exemple : mon site web affiche un classement. Ce classement est recalculé toutes les 3 minutes par un démon. Il est stocké dans une page web chargée en Ajax. Comment faire ? La solution la plus simple est d’écrire un fichier sur le disque qui sera ensuite servi par un serveur web, comme une page statique. Un problème est que le fichier ne contient que les données : pas de meta data, comme par exemple le temps d’expiration de la ressource. On aimerait donc bien placer notre classement directement dans un cache HTTP, en précisant le temps d’expiration. C’est assez compliqué en fait, puisque c’est un démon qui met à jour notre classement, et que le cache est alimenté par un serveur web …

Pour ce besoin, on va plutôt chercher une architecture du genre :

Dans cette architecture, pour chaque requête HTTP entrante (ou seulement sur un pattern d’URL), le reverse proxy HTTP se connecte sur le stockage et lui demande si il contient des données pour l’URL en question. Si oui, le reverse proxy HTTP renvoie les données. Si non, le reverse proxy interroge le serveur Web. Dans ce cas, ce n’est pas le reverse proxy qui remplit le stockage. Il est rempli soit par un autre serveur qui execute des traitements métiers (le serveur back office du dessin), soit par le serveur web, qui le remplit sur certains requêtes en plus de renvoyer des pages HTML.

C’est en fait un cache HTTP « éclaté » : on sépare la partie reverse proxy de la partie stockage, et on supprime l’alimentation du stockage par analyse des headers HTTP.

Cette architecture n’est pertinente que si le coût de régénération de la ressource est supérieur au coût d’aller la chercher dans le stockage. C’est très souvent le cas : une interrogation d’un stockage comme a href= »http://memcached.org/ »>Memcached sera bien plus rapide qu’un appel en base de données. On architecturera le site web pour que toutes les URLs que l’on peut mettre en cache soit facilement identifiables : /cache par exemple, de manière à ne pas faire d’appels sur le cache inutilement.

Ce besoin est en fait de plus en plus important : aujourd’hui, il n’y a plus besoin de démontrer l’impact de la vitesse d’un site web sur son business : « Amazon a découvert que chaque 100ms de latence lui coûte 1% de chiffre d’affaire ». Il est donc vital d’accélérer l’affichage des pages. Et une solution pour le faire est de réaliser certains traitements trop long de manière asynchrone. Quelques exemples : envoyer un mail, calculer un classement, mettre à disposition le pdf d’une facture …
Ce mécanisme de jobs asynchrones est intégré dans certains frameworks de dévelopement web, par exemple Rails et ses delayed jobs.

Nginx / memcached module

Le module Nginx / Memcached permet de réaliser l’architecture précédente, en utilisant Nginx comme reverse proxy HTTP et Memcached comme stockage. (Note : memcached est souvent utilisé pour stocker les sessions HTTP de manière partagée).

Le module Nginx memcached de base fonctionne très bien. Il a cependant une grosse limitation : on ne peut stocker les headers HTTP avec les données. Par exemple, les pages servies par Nginx et des données dans Memcached ont le Content-Type par défaut de Nginx : impossible donc de stocker plusieurs types de données dans le cache (CSS, JS, images, HTML, json…). On peut ajouter des headers HTTP spécifiques, mais seulement dans la configuration Nginx. Ces headers seront donc communs pour tous les resources servies par Nginx/Memcached (à moins de mettre des ifs partout dans la configuration).

Cette limitation rend donc plus difficile l’utilisation de ce module.
Note : le module Nginx Redis présente le même type de limitation.

J’ai donc modifié le module Nginx / Memcached afin de pouvoir stocker des headers HTTP dans Memcached. Pour l’utiliser, il suffit d’insérer dans Memcached quelque chose du genre :

EXTRACT_HEADERS
Content-Type: text/xml

<toto></toto>

Nginx renverra une page qui contiendra juste <toto></toto>, mais avec un header HTTP Content-Type: text/xml.

J’en ai profité pour ajouter des fonctionnalitées :

• Gère les headers If-Modified-Since, pour renvoyer un code 304 Not modified quand la donnée dans Memcached contient un header Last-Modified.
• Hasher les clés utilisées dans Memcached pour contourner la limite de taille des clés dans Memcached (250 caractères)
• Insertion dans Memcached via Nginx, par une URL spécifique. Cela permet d’utiliser le cache avec un simple client HTTP, au lieu d’un client Memcached. C’est aussi utile quand on va répartir les données sur plusieurs serveurs : les mêmes load balancers HTTP pourront être utilisés en lecture et écriture
• Purge Memcached via Nginx, par une URL spécifique. Comme précédemment, cela permet de purger Memcached avec un simple client HTTP (curl par exemple)
• Purge partielle de Memcached gràce à un mécanisme de namespace. Utile quand on cache des données pour plusieurs domaines, et que l’on veut en purger un seul.

Un exemple de configuration Nginx, où Nginx regarde pour toutes les URLs si il y a des données dans memcached avant de passer les requêtes aux servers webs :

  location / {
    error_page 404 = @fallback;

    if ($http_pragma ~* "no-cache") {
       return 404;
    }
    if ($http_cache_control ~* "no-cache") {
       return 404;
    }
    set $enhanced_memcached_key "$request_uri";
    set $enhanced_memcached_key_namespace "$host";
    enhanced_memcached_hash_keys_with_md5 on;
    enhanced_memcached_pass memcached_upstream;
  }

  location @fallback {
    proxy_pass http://backend_upstream;
  }

Ce module est open source et disponible ici.
Il est utilisé en production chez fasterize, et toutes ces fonctionnalités sont utilisées et fonctionnent très bien.

J’espère que ce module vous sera utile !

Suggestion d'articles :

1. Memcached : une alternative aux caches classiques

Esper, édité par EsperTech, est une plateforme Java dédiée au CEP et au traitement de flux d’événements (ESP – event stream processing). C’est une collection de frameworks et d’outils servant à construire et intégrer des applications orientées événements.

Les 3 packages de la suite Esper couvrent la plupart du socle technique de telles applications. EsperTech s’y réfère en tant que 3 « éditions », mais ce sont en fait des groupes d’outils complémentaires.

La construction d’une application orientée événement avec Esper implique :

• le développement de la logique applicative au moyen d’instructions de traitement d’événements, instructions comprises par le coeur algorithmique de la suite, le moteur Esper Event Stream and Complex Event Processing (ou, en plus court, Esper Engine). Le moteur est distribué en open source sous licence GPLv2
• le packaging, l’intégration et le déploiement de l’application – Esper Enterprise Edition (EsperEE) peut assurer ce rôle
• si nécessaire, la sécurisation du traitement des événements avec EsperHA, qui ajoute des fonctions de persistance pour les scénarios de haute disponibilité et de reprise sur erreur

L’article complet, en anglais, offre un tour d’horizon de la plateforme CEP constituée par cet écosystème Esper. Le discours s’appuie sur la version 4.5.0 de la suite (à ce jour, la dernière version est la 4.6.0).

Suggestion d'articles :

1. Complex Event Processing avec Esper
2. Complex Event Processing
3. Complex Event Processing (CEP), de quoi s’agit-il?

Au cours de la vie d’un logiciel, beaucoup de temps est consacré à son déploiement sur différentes plates-formes (recette, preprod, prod…). Bien souvent, nous réalisons des sous-projets de création d’environnements pour les logiciels nouvellement développés. Ce type de sous-projet est rarement capitalisé techniquement et peu contributeur à la valeur métier. Être capable de composer,  monter et démonter des environnements à la demande offrirait une flexibilité appréciable. Pour cela, il est efficace de standardiser les ressources d’infrastructure pour les utiliser comme des composants combinables. C’est ce que propose le cloud computing en offrant des capacités de production industrialisées sur Internet.
Construire des environnements requiert cependant des types de ressources d’infrastructure variés dont quelques exemples sont présentés ci-dessous :

A la manière de ce qui est fait pour les capacités de calcul et de stockage (avec les API EC2 et S3 d’Amazon par exemple), les autres ressources peuvent aussi être requises à la demande et assemblées à travers des réseaux. C’est la vision de l’Infrastructure agile, où des ressources « standard » sont mises à disposition en self-service via une interface humaine ou par appel de web-services. La figure suivante donne un exemple d’infrastructure réalisée par un tel assemblage :

Ainsi, un système d’information modélisé par des capacités et des réseaux pourrait se réaliser par une « simple » instanciation de ressources « cloud » sans mener « un projet spécifique d’infrastructure ». Vision utopique ou réalité ? Le deuxième choix est déjà le bon !

Il se pose quatre questions essentielles pour réaliser une telle vision :

• Comment définir et gouverner les ressources utiles aux usages de l’entreprise  (périmètre fonctionnel, modèle de financement et de facturation aux utilisateurs, SLA) ?
• Comment donner aux utilisateurs l’accès à ces ressources ?
• Comment implémenter les ressources à fournir (architecture, technologies) ?
• Comment opérer techniquement les ressources ?

Nous allons passer en revue ces différents sujets au cours d’une série d’articles sur ce blog. Mais nous pouvons d’ores et déjà en donner un aperçu.

Un exemple de fonctionnement

Examinons la dynamique permettant aux utilisateurs d’obtenir des capacités de manière agile. Ces dernières doivent disposer des caractéristiques du « cloud » c’est à dire être :

• disponibles dès que demandées via une interface humaine ou programmatique (approche « à la demande ») ;
• payées à la consommation ;
• en ligne avec un SLA donné ;
• de capacité infinie vue de l’utilisateur.

Prenons par exemple une capacité de transport et routage de messages (Broker MOM). La figure suivante montre un système de déploiement d’application qui invoque l’API de l’Infrastructure agile pour créer une ressource de transport de message :

La ressource de transport de message instanciée (MOM Messaging sur la figure) est composée d’un Broker, d’une console de paramétrage et d’exploitation. Les paramètres d’invocation de la demande précisent les services de messaging souhaités (par exemple les patterns d’intégration que le MOM doit fournir, la qualité de service attendue). Une fois le MOM créé, l’API d’accès à la ressource est active et présente dans ce cas l’accès au Broker. Un SLA définit les qualités opérationnelles de la ressource.

Il y a donc 3 composantes essentielles :

• L’API de demande de mise à disposition, qui une fois invoquée déclenche la création de la ressource et la mise à disposition des informations d’usage à l’utilisateur (réponse au web-service de demande ou vue dans le portail) ;
• L’API d’usage des ressources qui permet l’accès aux capacités créées ;
• Le Portail qui offre une vue d’interface humaine sur les ressources créées et utilisées.

Notre capacité de messaging est donc :

• Disponible à la demande via une API (ou une IHM style « portail ») ;
• De capacité infinie car on peut créer autant de brokers que l’on souhaite ;
• Facturable au broker instancié et aux trafic de messages effectif ;
• Ajustée en fonction d’un SLA définissant la disponibilité du service, sa fiabilité et ses performances maximales (niveau de disponibilité, latence de transmission…).

Cette approche est généralisable à toutes les ressources d’infrastructure et de middleware.

Les API sont utilisables depuis par exemple une usine de développement « 2.0 » qui consomme de manière intensive l’infrastructure agile :

Grâce à l’Infrastructure agile, les environnements de test et de production sont déployables à la demande. Les Développeurs, devenus Opérateurs applicatifs dans une organisation DevOps, consomment les ressources sans se soucier de la technologie sous-jacente. Ils déploient leurs applications sur des capacités et laissent leurs collègues Opérateurs d’infrastructure assurer l’opération de l’Infrastructure agile selon les SLAs convenus.

Comment découvrir et préciser les capacités de l’Infrastructure agile ?

Il convient de spécifier fonctionnellement les capacités d’infrastructure et d’indiquer par quels mécanismes techniques l’utilisateur pourra y accéder.
Concernant l’aspect fonctionnel, l’essentiel est dans l’organisation : qui participe à la spécification des capacités offertes ?
Deux organisations et méthodes projet sont possibles :

• Le marketing interne proactif, c’est à dire que les responsables de l’infrastructure sont à l’initiative et démarchent les utilisateurs de façon anticipée pour découvrir quelles capacités sont ou seront requises ;
• La réalisation réactive, où les responsables de l’infrastructure attendent les demandes (venant des équipes de développement la plupart du temps) pour faire évoluer leurs actifs dans un but de factorisation et de rationalisation progressive.

Ces deux modes d’engagement de la réflexion débouchent cependant sur un travail de collaboration entre le monde de l’application et celui de l’infrastructure.

Concernant l’aspect technique, quel cadre de spécification et de réalisation utiliser ?
Les spécifications EC2, S3, OCCI, font apparaître des spécialisations plus ou moins marquées vers des capacités. Par exemple S3 adresse le stockage et non les MOMs. Il convient de rendre le plus homogène possible l’API afin de constituer un catalogue aisément utilisable et surtout actionnable en terme de combinaison des capacités. Nous examinerons l’utilisation d’OCCI pour une description quasi universelle des capacités d’infrastructure dans un prochain article.

Comment réaliser et opérer l’Infrastructure agile ?

La promesse de l’Infrastructure agile impose de respecter les principes suivants lors de sa conception :

• Automatisation totale, pour obtenir une qualité « industrielle » ;
• Standardisation totale des composants (matériel, logiciel), pour réduire les coûts ;
• Opération dédiée, pour libérer l’Opérateur d’infrastructure qui ne connaît plus les applications mais se focalise sur le SLA des capacités livrées.

Architecture

L’Infrastructure agile a deux facettes :

• Les ressources matérielles et logicielles (Machines, OS, stockage… qui permettent de livrer les ressources requises via l’API de mise à disposition). On appelle ces ressources des « Capacités sous-jacentes », non visibles en tant que telles par les utilisateurs de l’API ;
• Les ressources effectivement livrées et fonctionnant dans un contexte utilisateur (VM, VLAN, Consoles de supervision, stockages…), ce sont les « Capacités livrées ».

Les composants fournissant les ressources peuvent être utilisés à la fois pour les capacités sous-jacentes et les capacités livrées. Typiquement, la supervision peut fournir des informations sur les machines à l’Opérateur d’infrastructure, mais également des informations concernant les capacités livrées (supervision de VM par exemple) à leurs utilisateurs. Ce double usage est à considérer avec soin, car il entraine la création de contraintes bien spécifiques (sécurité, multi-tenant…).

Composants essentiels

La figure ci-dessous présente des composants connectés dont les rôles sont les suivants :

Suggestion d'articles :

1. Annonce : Kanban depuis les tranchées à Agile Grenoble 2010
2. Octo présente cinq sessions dans le cadre de la conférence Agile France
3. Apéro Agile chez OCTO Technology

Imaginer ce que sera l’environnement bancaire dans un futur à moyen terme à la fois proche et lointain. Proche pour le rattacher à des signaux faibles et des tendances que nous observons aujourd’hui, et assez lointain pour ne pas rester englué dans la situation actuelle et amorcer une dynamique d’évolution.

La Banque dans dix ans… 

Sous quelles formes seront réalisées les interactions entre les institutions financières et la population au quotidien ?

La tendance virtuelle, électronique qui a débuté au début des années 2000 va-t-elle se poursuivre ou la banque va-t-elle réinverser la tendance en replaçant la relation physique au coeur du système Homme-Banque ?

Ces nouveaux modèles de relation vont-ils apporter avec eux une révolution dans la conception informatique des outils bancaires, dans l’architecture même des briques informatiques qui composent son SI ? 

Notre mode de fonctionnement

Nous nous sommes donc prêtés à un exercice original et difficile : le jeu des scenarios.

L’objectif d’un tel exercice est de lancer des idées, raisonnables ou plus folles, les rassembler en groupes cohérents, et faire ressortir de ces tendances quelques scenarios, schématisés par une appellation révélatrice. Ensuite, il s’agit d’identifier les signaux faibles actuels qui concourent à ces prévisions.

D’un tel exercice se dégagent des scenarios qu’il ne convient pas de prendre au pied de la lettre. Les tendances de fond, les révolutions technologiques ou de conception sont des éléments prolongeant des évolutions que nous constatons aujourd’hui, et qui sont éclairantes dès aujourd’hui pour commencer à amorcer des virages et repenser la façon dont on va pouvoir faire de l’informatique bancaire demain.

Le résultat

Nous avons abouti à 3 scénarios :

• Le scenario « Tout concret » :

Le défaut de l’Italie, après celui de l’Espagne 3 ans plus tôt, a bouleversé les certitudes des consommateurs européens. Ils se sont massivement tournés vers des investissements concrets : immobilier, terre et métaux précieux, boudant les produits financiers obscurs car ils n’accordent plus de crédit aux banques.

Ces dernières se sont vu obliges de revoir leur image et de regagner la confiance perdue. Elles ont donc misé sur la relation avec leur clientèle en repensant leur modèle d’agence à travers un espace convivial renouant avec leurs origines : Proximité et Conseil.

Ces agences se recentrent sur les domaines où la banque excelle : gestio de l’épargne et patrimoniale, octroi de crédit et financement des entreprises. L’écoute du terrain étant privilégiée, son personnel d’agence se spécialise pour répondre aux questions toujours plus pointues de clients échaudés. Des outils d’aide à la décision intéractifs (tablettes, tables tactiles) permettent au conseiller de bâtir avec le client une solution sur mesure.

Le contexte socio-économique oblige à adapter les produits proposés : simplification des offres pour les rendre plus accessibles et plus transparentes, adaptation des produits à la clientèle (vieillissement de la population), introduction du financement participatif sont autant d’avancées. Côté BtoB, le succès de l’auto-entreprenariat a favorisé l’émergence de nombreuses TPE/PME demandeuses de solutions simples et peu coûteuses (paiement, crédit, …) avec l’aval d’un gouvernement désireux de voir repartir la croissance.

Recentrées sur leurs métiers historiques, toutes les banques, ayant fait l’effort de se rapprocher de leurs clients, au propre comme au sens figuré, ont vu leur côte de confiance repartir à la hausse et retrouver des niveaux de profitabilité qu’elles croyaient ne plus revoir de si tôt.

• Le scenario « Tout virtuel » :

Le succès des banques en ligne ne se dément plus. Toute la population française d’un accès Internet, d’une identité numérique et les « digital natives » sont majoritaires en cette année 2020. De fait, très peu de gens prennent encore la peine de se déplacer en agence conduisant les banques à diviser par 10 leur nombre et à automatiser la quasi-totalité des actes pour diminuer le personnel présent.

Désormais, tout peut se faire seul de chez soi. La banalisation des analyses biométriques (voix, visage, veine, …) a résolu les problématiques d’identification des individus notamment à la signature des contrats. Ces documents, tout comme la plupart des pièces administratives, sont collectés et archivés durablement dans des coffres forts électroniques qui garantissent leur intégrité et permettent par leur moteur de recherche avancé de tout retrouver facilement.

Mais si la virtualisation des actes bancaires s’est étendue ces 10 dernières années, que dire des solutions de paiement qui ont été révolutionnées au cours de cette même période. Qui aurait pu pronostiquer que la carte bleue plastique disparaitrait de notre quotidien avant le chèque ? Qui aurait pu prévoir une telle adhésion pour l’argent virtuel et les portemonnaies électroniques multifonctions sur mobile quand on se souvient des tentatives peu fructueuses de Moneo ?

Et l’usage même de notre accès à Internet s’est modifié, passant de l’austère PC familial aux IHMs tabulaires, aux tablettes tactiles, améliorant l’expérience client en utilisant judicieusement notre gestuelle. Car ne nous y trompons pas, ce sont bien les tablettes qui ont conquis les plus seniors ou les moins technophiles d’entre nous. La simplicité et la transparence d’utilisation sont plus que jamais des gages de fiabilité et de confiance.

En 10 ans, l’image de la banque s’est métamorphosée ; elle figure aujourd’hui au côté des grands acteurs du WEB sur le plan des avancées technologiques.

• Le scenario « Tout distribué » :

Juillet 2020, Composite Bank vient de détrôner CityGroup en nombre de clients particuliers et gère un encours considérable qui attise la convoitise d’états fortement affaiblis budgétairement, un succès inimaginable 8 ans plus tôt en plein marasme économique… car CompositeBank n’existait pas ! Et pourtant, tous les ingrédients nécessaires à la cette success-story étaient déjà présents à cette époque-là.

Souvenez-vous fin 2011, BankSimple avait ouvert la voie en proposant une offre en rupture basée sur un back-end temps réel et une relation client totalement repensées. Comment avait-elle réussi ce tour de force en un temps aussi court ? Simplement en se concentrant sur leur différenciant, et en complétant leur SI avec des briques prêtes à l’emploi, en avance sur le marché, proposées par des acteurs déjà implantés.

CompositeBank représente l’aboutissement de cette stratégie : externaliser les processus métier offrant le moins de valeur ajoutée à l’organisation en intégrant des offres clé-en-main en marque blanche ou via des APIs ouvertes. Pourtant de nombreux acteurs se sont lancés sur cette piste-là mais seulement très peu ont réussi le passage à l’échelle. Pourquoi ?

Dès le début, CompositeBank a assumé son statut de consommateur de solutions et bâti une organisation en conséquence : un pôle « expérience client » très développé qui collabore étroitement avec un pôle IT réduit mais composé d’experts, eux-mêmes dialoguant avec une communauté de partenaires. Fini le découpage historique Etude / Production, place à une organisation par ligne produit qui fluidifie la communication entre les équipes, aligne tous les acteurs sur le même enjeu et dynamise l’innovation.

Car c’est cette même innovation qui a permis à CompositeBank de se faire un nom à ses débuts et qui, aujourd’hui encore, malgré la taille de l’entreprise, la rend capable de nous surprendre… et a contraint ses concurrents, y compris les acteurs historiques, à modifier leurs organisations.

Conclusion

Cet exercice a été salué par les participants à ce petit déjeuner. Il a mis en avant des tendances sociétales, économiques, mais aussi un ancrage fort sur les impacts informatiques et organisationnels qui en découlent.

OCTO travaille depuis 13 ans sur des problématiques de création ou de transformation des systèmes d’information, et adresse aujourd’hui des sujets tels que les APIs, le Big Data, le PFM, la mobilité, les technologies web et les récentes normes HTML5, l’interfaçage de briques externes avec le SI, la sécurité applicative, les cibles et trajectoires d’évolution des SI en voie d’obsolescence…

Si vous avez des besoins, des projets ou que vous souhaitez notre retour d’expérience sur ces sujets, n’hésitez pas à nous contacter.
Voici le lien vers les slides du petit déjeuner ainsi que le lien vers la vidéo.

Suggestion d'articles :

1. Banque de détail du futur : scénarios 2020
2. Petit déjeuner mobilité – iPad, iPhone Android en banque et assurance, préparez-vous au coup d’après !
3. Petit-déjeuner OCTO – L’agilité à grande échelle : Retour d’experience avec Strator

Avant d’introduire la bêta perpétuelle, il est nécessaire de revenir sur un pattern classique du monde Open Source : “Release early, release often”. Le principe de ce pattern consiste à mettre régulièrement le code à la disposition de la communauté afin de permettre aux développeurs, testeurs, utilisateurs de donner un feedback en continu sur le produit. Cette pratique a été décrite dans “La cathédrale et le bazar” d’Eric Steven Raymond. Elle rejoint le principe d’itération courte des méthodes agiles.

Le principe de la “bêta perpétuelle” a été introduit dans le manifeste du Web 2.0, écrit par Tim O’Reilly, et où il nous dit la chose suivante :

“ Les utilisateurs doivent être considérés comme des co-développeurs, en suivant les principes Open Source (…). Avec le Web 2.0, ce principe évolue vers une position plus radicale, la bêta perpétuelle, dans laquelle le produit est développé de manière ouverte, avec de nouvelles fonctionnalités offertes sur une base mensuelle, hebdomadaire, ou même quotidienne. ”

Le terme « bêta perpétuelle » désigne le fait que l’application n’est jamais finalisée, mais toujours en évolution : il n’y a pas de livraison de nouvelle version à proprement parler. L’enjeu de ce mode de fonctionnement est de réussir à mettre en place le « Continuous Delivery ».

Cette évolution continue est possible car on parle de services en ligne et non de logiciels :

• Dans le cadre de logiciels, la gestion de versions suit généralement une roadmap avec des jalons de publication : des « releases ». Ces releases sont espacées dans le temps pour 2 raisons : la nécessité de déployer les versions chez les utilisateurs, et le besoin s’assurer la maintenance et le support des différentes versions déployées chez les utilisateurs. Assurer le support, les mises à jour de sécurité et la maintenance évolutive sur plusieurs versions d’un même logiciel est un terrible casse-tête, et un casse-tête coûteux. Prenons l’exemple de Microsoft : l’éditeur de Redmond a du, à un moment donné, gérer les évolutions de Windows XP, Vista et Seven. On imagine les 3 équipes de développeurs mobilisées pour un seul et même logiciel : une terrible dispersion d‘énergie et un cauchemar pour un éditeur moins fortuné que Microsoft. Ce syndrome est appelé “perversion des versions”.
• Dans le cadre des services en ligne, il est possible de ne gérer qu’une seule version de l’application. Et comme les grands du Web se chargent de mettre en ligne et d’héberger leurs applications, les utilisateurs peuvent bénéficier des nouveautés sans avoir à gérer de déploiement logiciel.

Les services en ligne sont donc mis à jour en continu par leurs opérateurs sans que les utilisateurs soient informés de l’existence d’une nouvelle version. Les nouvelles fonctionnalités apparaissent au fil de l’eau et elles sont découvertes par hasard par les usagers. Ce mode de fonctionnement permet un apprentissage progressif des nouveautés applicatives. En règle générale, les problématiques de compatibilité ascendante sont bien gérées (il existe quelques exceptions, comme le support du mode déconnecté dans Gmail suite à l’abandon de Google Gears). Ce modèle est largement utilisé par les acteurs du Cloud Computing.

La « Customer driven roadmap » est un élément complémentaire et vertueux de la «bêta perpétuelle». Comme les grands du Web maîtrisent la plateforme de production, ils peuvent faire des statistiques sur l’usage de leur logiciel. Cela leur permet de mesurer l’accueil qui est fait aux nouvelles fonctionnalités offertes. A ce titre, les grands du Web suivent énormément de métriques : on dit d’ailleurs qu’ils ont le « culte de la mesure ».

De manière plus classique, le fait de maîtriser la plateforme de production permet de lancer des sondages auprès de certains segments de population afin d’obtenir un feedback utilisateurs.

Pour utiliser le pattern bêta perpétuelle, il est indispensable d’avoir les moyens de faire des déploiement réguliers. Les pré-requis sont donc :

• la mise en oeuvre d’une usine logicielle avec build automatisé
• des pratiques de “continuous delivery”
• la capacité à faire un rollback rapide en cas de problème…

Il existe une polémique sur la bêta perpétuelle : certains utilisateurs considèrent que bêta est synonyme de produit non fini, et que les services qui suivent ce pattern ne sont pas assez fiables pour être utilisés. Cette polémique a poussé certains opérateurs de services a supprimer la mention “bêta” de leur site, sans pour autant changer leurs pratiques.

Chez qui ça fonctionne ?

La référence était Gmail dont le logo intégrait la mention bêta jusqu’en 2009 (une fonction « back to Beta » a depuis été ajoutée).

La pratique existe chez de nombreux grands du Web : Facebook, Amazon, Twitter, Flickr, Delicious.com, etc.

Une bonne illustration de la « bêta perpétuelle » est fournie par les Labs de Gmail : ce sont de petites fonctionnalités unitaires que les utilisateurs peuvent décider d’activer ou non. En fonction de leur adoption, Google décide ou non de les intégrer à la version standard de son service.

En France, des services en ligne affichent ou ont affiché le bêta sur leur page d’accueil :

• urbandive.com : service de navigation en vue piétonne du groupe Pages Jaunes
• sen.se : service de stockage et d’analyse de données personnelles
• etc.

Et chez moi ?

Nous vous engageons à tester ce pattern, en déployant les : continous delivery, A/B testing, développement agile.

Dépendances à d’autres patterns

Pattern “continous delivery”

Pattern “A/B testing” & « culte de la mesure »

Pattern “développement agile”

Exceptions!

Certains grands du Web choisissent de continuer à utiliser le principe de coexistence des versions. Il est en particulier utile de maintenir plusieurs versions d’une API afin d’éviter de forcer les développeurs à mettre à jour leur code immédiatement à la sortie d’une nouvelle version de l’API.

Voir en particulier l’API Amazon Web Services

Sources

The Perpetual Beta, manifeste du Web2.0, Tim Oreilly

La bêta perpétuelle sur Wikipedia

“La cathédrale et le bazar”, Eric Steven Raymond

Suggestion d'articles :

1. Les Patterns des Grands du Web : « OpenAPI » ou écosystème ouvert
2. Les Patterns des Grands du Web – Test A/B
3. Les Patterns des Grands du Web – L’obsession de la mesure