FICHE PRODUIT COREYE CACHE Architecture technique En bref Plateforme Clients Web Coreye Cache applicative Références Principe de fonctionnement

Transcription

1 COREYE CACHE Solution d absorption de charge pour une disponibilité et une performance optimales des applications Web En bref Architecture technique La plateforme Coreye Cache délivre la majeure partie du contenu d une application Web à la place de la plateforme hôte. Les serveurs applicatifs gagnent en disponibilité et en réactivité tout en minimisant les frais d infrastructure (moins de serveurs pour plus de trafic). La géo-localisation permet en plus de simplifier l accès à l application depuis l étranger. Références Clients Web Coreye Cache Plateforme applicative Plateforme mutualisée reposant sur l infrastructure réseau Coreye : Points de présence multiples (Europe, USA, Russie) Redondance intégrale de la plateforme (aucun SPOF) Interface de gestion Web Disponibilité 24/24-7j/7 API REST/Json Principe de fonctionnement Le flux http de l application Web est envoyé vers la plateforme Coreye Cache qui filtre, selon des règles personnalisables, les requêtes devant être cachées (enregistrées). Les autres requêtes sont transmises sans modification vers la plateforme applicative (source). Chaque requête cachée n est transmise qu une seule et unique fois vers la source et les requêtes identiques suivantes seront directement servies par les serveurs de cache, sans solliciter la plateforme source. Une durée de vie («TTL» = Time To Live) est définie pour chaque requête afin d assurer un rafraichissement du contenu à intervalle régulier.

2 Avantages Absorption des pics de charge, anticipés ou pas Réduction des frais d hébergement de la plateforme applicative : o Moins de charge à traiter = moins de serveurs à provisionner o Réduction du trafic émis par la plateforme source Performance des liaisons Internet du réseau Coreye o Temps d accès depuis Paris : 7ms en moyenne o Disponibilité : 99% Compression HTTP permettant d accélérer les temps de téléchargement pour les utilisateurs Sécurité accrue : o L application n est pas visible directement sur Internet, ce qui réduit fortement la surface d exposition de la plateforme applicative. o Protection native contre les attaques de type DDoS (Déni de Service Distribué) Suivi en temps réel du trafic consommé Purge La purge permet de forcer le rafraichissement de contenu pour une ou plusieurs requêtes. Elle peut être déclenchée manuellement via l interface de gestion ou de façon planifiée grâce à l API Coreye. La purge totale permet de rafraichir instantanément l intégralité du cache pour une application. La purge sélective permet de ne purger qu une partie du contenu afin de limiter l impact sur la plateforme applicative. Souplesse de configuration : o Interface de gestion développée en interne par Coreye et optimisée régulièrement grâce aux remarques de ses utilisateurs o Accompagnement à la configuration par les équipes Coreye Absorption des pics de charge La vocation première de la plateforme Coreye Cache est d absorber les pics de charge, anticipés ou non, d une application Web. Le graphique ci-dessous montre en bleu l intégralité des requêtes envoyées par les utilisateurs d un site Web et, en rouge, la proportion de ces requêtes qui sont transmises à la plateforme source. On voit que les pics d utilisation, même importants, n ont qu un faible impact sur la charge subie par l application. Cet effet de lissage est d autant plus efficace que la configuration de cache est optimisée. Dans cet exemple, le «Cache Hit Ratio» (rapport entre les requêtes soumises par les utilisateurs et les requêtes transmises à la plateforme source) est de 96% (la plateforme source ne reçoit que 4% du total des requêtes). Ce graphique, mis à jour en quasi temps réel, est disponible pour chaque application Web prise en charge par Coreye Cache, via l interface de gestion.

3 Pré-requis techniques Application Web sur protocole HTTP accessible publiquement (non compatible avec les intranets) Capacité à modifier la configuration DNS pointant vers l application Idéalement, capacité à adapter l application en vue de l optimisation de sa «cachabilité» Périmètre d intervention Coreye Maintenance opérationnelle de la plateforme Le client n a pas à se soucier de la disponibilité de la plateforme de cache : elle est surveillée en permanence, comme l intégralité du réseau Coreye. Le provisionnement de nouveaux serveurs est anticipé grâce à un contrôle permanent des ressources disponibles. Le dimensionnement de la plateforme est toujours largement supérieur au strict nécessaire. Cela permet de supporter d importants pics de trafic à tout moment. Accompagnement à la configuration Coreye fournit une documentation complète des fonctionnalités du service, ainsi que de nombreuses bonnes pratiques applicables sur une grande majorité des applications Web. Contenu statique/dynamique La plateforme Coreye Cache permet de traiter aussi bien des requêtes statiques que dynamiques. Les requêtes dynamiques retournent un contenu qui est généré à la demande par le serveur d application, ce qui peut consommer beaucoup de ressources sur la plateforme hôte (processeur, mémoire, base de données, ). Ces contenus sont parfois spécifiques à un utilisateur, auquel cas la réutilisation, et donc la cachabilité, est souvent très limitée, mais il peut également s agir de contenu générique réutilisable et donc cachable. C est donc sur les contenus dynamiques génériques que l utilisation du cache est la plus rentable. Au contraire, les contenus statiques (images, feuilles de style CSS, code client JavaScript, ) ne sont pas générés lors de l envoi de la requête et sont donc naturellement génériques et parfaitement cachables. L envoi de contenu statique par la plateforme hôte consomme moins de ressources mais il s agit souvent d un volume beaucoup plus conséquent que le contenu dynamique. L intérêt du cache de contenu statique reste donc très important pour libérer des ressources sur la plateforme d hébergement. Fortes d une longue expérience d infogérance d applications Web, les équipes Coreye sont disponibles pour assister ou prendre en charge la configuration spécifique de chaque application exploitant le service. Outre la configuration initiale, les ingénieurs Coreye peuvent également fournir une expertise d optimisation de la configuration pour tirer le meilleur parti du service (certaines optimisations peuvent nécessiter des modifications applicatives). Evolution du service La plateforme Coreye Cache est en constante évolution et de nouvelles fonctionnalités sont régulièrement mises à dispositions. Le plus souvent, les nouvelles fonctionnalités ne viennent pas combler un manque mais elles permettent au contraire de faciliter la gestion de l accès frontal d une application Web en centralisant un grand nombre de fonctionnalités annexes du cache. Une feuille de route des évolutions à venir est disponible sur demande. Coreye est également à l écoute des remarques émises par les utilisateurs. De nombreuses améliorations, allant de simples optimisations d interface à d importantes évolutions fonctionnelles, ont été apportées suite à la demande de nos clients.

4 Avant-vente Afin de valider le niveau de compatibilité d une application avec le cache préalablement à la commande du service, Coreye propose les prestations suivantes : Audit de compatibilité L expérience de Coreye et du groupe Pictime dans le développement et l infogérance d applications à haute disponibilité et performance nous permet d auditer de façon détaillée la compatibilité d une application Web avec les fonctionnalités du cache et ce, sans nécessiter d accès spécifique sur la plateforme applicative (nous auditons ce qui serait susceptible d être caché, donc ce qui est accessible publiquement). Cette étape permet d identifier les sections de l application pouvant être cachées. Cet audit fournira comme résultat une première ébauche de règles de cache permettant de commencer à définir la configuration et valider le bon fonctionnement de l application au travers du cache. Il en ressortira peut peut-être également des recommandations d optimisations applicatives en vue d améliorer la cachabilité de l application. Audit de performance En plus de la compatibilité, Coreye est en mesure d auditer la performance d une plateforme d hébergement et de fournir, si besoin, des solutions d amélioration. Le cache est souvent l une de ces solutions de par sa facilité de déploiement et son efficacité immédiate. Essai Coreye propose une offre d essai gratuit de sa plateforme de cache sur une durée et un trafic convenus. Plusieurs niveaux de test sont possibles, allant du simple accès à l interface de gestion, au passage du trafic de production par la plateforme de cache. Du type de résultats attendus (fonctionnalités, performances, économie de ressources, ) dépendra le niveau de test proposé. Processus de mise en service Mise en service «express» Les étapes de mise en service du cache sur une application dépendent de plusieurs facteurs et une étude préalable est systématiquement nécessaire. Il existe toutefois des cas «simples» dans lesquels une mise en service «express» est envisageable, c est par exemple le cas du cache de statique qui ne présente aucun risque de partage abusif de contenu confidentiel et dont les formats sont clairement identifiés. Audit de compatibilité Voir descriptif dans les prestations d avant-vente ci-dessus. Cet audit est facultatif si le client souhaite gérer lui-même la configuration du cache mais sera obligatoire (s il n a pas été réalisé en avant-vente) pour toute mise en production de cache dynamique par les équipes Coreye. Test internes L application d un cache dynamique sur une application Web implique la réalisation de tests spécifiquement orientés sur les problèmes pouvant survenir avec ce type de service. Ces tests sont réalisés dans un mode de simulation hors production, sans aucun impact possible sur le trafic public de l application.

5 Validation client Toute mise en production de cache est précédée par une validation écrite du client. Coreye peut, selon la nature et la complexité de l application, fournir une liste de tests spécifiques à réaliser afin de s assurer du bon fonctionnement de celle-ci au travers du cache, le but n étant pas d obtenir une validation basée sur des tests inadéquats. Passage en production Cela consiste à aiguiller les utilisateurs de l application vers la plateforme Coreye. Concrètement, il s agit d effectuer une modification sur la configuration du ou des noms de domaine pointant vers l application (DNS) pour que les requêtes pointent vers des adresses IP Coreye. En fonction de contraintes internes spécifiques à certaines entreprises, ce processus peut être relativement long. Il est donc possible d anticiper cette modification avant la mise en production pour que Coreye soit en mesure d effectuer une bascule rapide le moment venu. Application progressive Il est possible, pour faciliter une mise en production rapide du cache, d étendre progressivement sa surface d application, c'est-à-dire, par exemple, d appliquer rapidement un cache de contenu statique, délestant rapidement la plateforme d hébergement d une part de trafic importante mais clairement identifiée, puis d intégrer progressivement des éléments de contenu dynamiques, en prenant le temps d en tester scrupuleusement le bon fonctionnement. Problèmes possibles Comme pour toute composante d une application Web critique, une mauvaise configuration du cache peut engendrer des disfonctionnements plus ou moins gênants. Le principal problème pouvant survenir est le «partage de session», qui consiste à enregistrer, dans la mémoire du cache, des contenus spécifiques à un ou plusieurs utilisateurs et de les envoyer ensuite à d autres (le principe du cache étant la réutilisation de contenu). La plateforme Coreye Cache embarque plusieurs mécanismes de protection contre ce type de désagrément, mais il reste indispensable d en vérifier l absence préalablement à toute mise en production ou modification importante de la configuration ou de l application. Il est en effet impossible d établir des règles de protection universellement compatibles avec les spécificités de toutes les applications. Coreye dispose d outils et de méthodes spécifiques permettant l analyse détaillée du comportement d une application Web et ainsi d éviter toute dégradation de service suite à l application du cache. Délais de mise en production Comme expliqué précédemment, la mise en production d un cache de contenu statique peut être réalisée très rapidement, c'est-à-dire en quelques heures (hors contraintes internes du client). Les étapes de mise en production d un cache de contenu dynamique prennent forcément plus de temps, et le délai sera dépendant de la nature et de la complexité de l application. En pratique, cette phase de préparation prend environs une semaine.

6 Fonctionnalités clés Fonctionnalité Sites multiples Noms d hôtes multiples Nom de domaine principal Sources multiples Règles de cache détaillées Collections réutilisables Purge Redirections HTTP Réécriture des en-têtes de cache Mode débug Mode shunté Nettoyage de requêtes Description Chaque compte client peut contenir plusieurs sites ayant chacun une configuration spécifique (une application pouvant contenir plusieurs sections distinctes, qui peuvent être matérialisées par autant de sites déclarés sur la plateforme Coreye Cache). Chaque site peut être accessible depuis plusieurs noms de domaine. Par défaut, les noms de domaine secondaires forcent une redirection vers un domaine principal pour favoriser l indexation par les moteurs de recherche. Ce comportement est débrayable. Pour chaque site, une source est définie, identifiant l adresse à laquelle est joignable la plateforme applicative source. Il est possible de définir plusieurs sources pouvant être situées dans des centres de données distincts. Le cache ira donc s alimenter successivement sur chacune de ces sources et détectera si l une d elle est indisponible (continuité d activité). Pour chaque site, il est possible de définir des règles de cache aussi précises que nécessaire. Il existe 4 types de règles de cache : Ne pas cacher TTL par défaut (la durée de vie du contenu dans le cache est déterminée par la plateforme source) TTL forcé (la durée de vie est forcée par la plateforme de cache pour une durée personnalisable) Connexion directe (mode «non cache» spécifique aux applications de type Web-Service) Les règles de cache sont basées sur des collections, qui sont des listes d expressions rationnelles permettant la sélection précise du contenu à cacher (ou ne pas cacher). Ces collections peuvent être communes à plusieurs sites d un même compte (pour baser différents sites sur les mêmes règles de cache) et peuvent également servir à effectuer des purges rapides sur toutes les requêtes correspondant à une collection. Expiration de cache anticipée (voir encart en p.2). Les requêtes passant par la plateforme de cache peuvent être redirigées vers une adresse donnée en fonction de critères configurables (code de statut HTTP, correspondance d URL). Il est également possible de configurer une redirection systématique, par exemple pour placer un site ou une application en maintenance sans aucune action nécessaire sur la plateforme source. La plateforme de cache peut réécrire les en-têtes http contenues dans les réponses aux requêtes afin de synchroniser les expirations de cache navigateur/proxy avec l expiration dans le cache Coreye. Ce mode ajoute des en-têtes HTTP dans les réponses aux requêtes du site concerné. Ces en-têtes, visualisables facilement avec certains navigateurs web, permettent de suivre de façon détaillée le comportement de la plateforme de cache sur chaque requête d une application. Permet de désactiver très rapidement le cache pour un site sans avoir à en supprimer la configuration ou à effectuer une modification DNS. Cela peut s avérer utile pour le diagnostic de problèmes applicatifs que le cache pourrait masquer. La plateforme de cache peut nettoyer les requêtes HTTP qui seraient mal formées afin d assurer un respect accru des normes établies.

7