{"id":143,"date":"2023-07-02T23:32:53","date_gmt":"2023-07-02T21:32:53","guid":{"rendered":"https:\/\/zoominandout.fr\/?p=143"},"modified":"2023-07-02T23:38:10","modified_gmt":"2023-07-02T21:38:10","slug":"plaidoyer-pour-le-cache","status":"publish","type":"post","link":"https:\/\/zoominandout.fr\/index.php\/2023\/07\/02\/plaidoyer-pour-le-cache\/","title":{"rendered":"Plaidoyer pour le cache"},"content":{"rendered":"\n

Le cache, mal aim\u00e9 et pourtant indispensable<\/h2>\n\n\n\n

La r\u00e9putation du cache de donn\u00e9es dans le monde de l’informatique est bien curieuse. Son usage est largement r\u00e9pandu. Pour autant, le cache appara\u00eet comme une complication ou m\u00eame un risque avec la corruption de cache. Comme toute technique puissante, elle peut avoir des cons\u00e9quences d\u00e9sastreuses par un mauvais emploi. Il est temps de faire le plaidoyer du cache et lui redonner sa place l\u00e9gitime !<\/p>\n\n\n\n

La sortie rapide de la salle d’attente<\/h3>\n\n\n\n

Le cache est employ\u00e9 \u00e0 diff\u00e9rente \u00e9chelle dans les syst\u00e8mes informatiques, du microprocesseur jusqu’au r\u00e9seau Internet. Le cache est un levier de performance tr\u00e8s puissant, en substituant une op\u00e9ration lente par un acc\u00e8s rapide en m\u00e9moire. Les applications passent l’essentiel de leur temps dans une sorte de salle d’attente. Le cache est, en quelque sorte, une sortie rapide dans cette salle d’attente ! R\u00e9duire le temps de pr\u00e9sence des applications dans la salle d’attente est un moyen particuli\u00e8rement efficace pour acc\u00e9l\u00e9rer leur fonctionnement, juste apr\u00e8s celui de la mise \u00e0 disposition de ressources suffisantes aux applications (traitement, m\u00e9moire, r\u00e9seau, stockage).<\/p>\n\n\n\n

\"\"
Piste rapide ou lente ? Cache ou pas cache ? <\/figcaption><\/figure>\n\n\n\n

La d\u00e9raisonnable efficacit\u00e9 du cache<\/h3>\n\n\n\n

Pour que le cache soit effectif, il faut non seulement qu’il dispose d’une alternative rapide aux op\u00e9rations r\u00e9elles, mais aussi qu’il puisse effectuer cette substitution dans un \u00ab\u00a0bon nombre\u00a0\u00bb de cas. La fr\u00e9quence de substitution applicable s’appelle le cache hit rate<\/em>. Il n’y a rien d’\u00e9vident \u00e0 ce que le taux de hit soit \u00e9lev\u00e9, de l’ordre de 80%, et ind\u00e9pendant de la taille relative du cache par rapport au volume des donn\u00e9es op\u00e9rationnelles. Le cache s’appuie sur une heuristique qui se v\u00e9rifie dans les cas courants : la localit\u00e9 temporelle et spatiale. G\u00e9n\u00e9ralement, un utilisateur travaille sur une zone locale de l’espace des donn\u00e9es (un agr\u00e9gat fonctionnel, par exemple) dans un intervalle de temps d\u00e9limit\u00e9. Ce mode op\u00e9ratoire conduit naturellement le cache \u00e0 avoir un taux de hit <\/em>\u00e9lev\u00e9, m\u00eame sans pr\u00e9chauffage de cache. <\/p>\n\n\n\n

\"\"
Heuristique du cache<\/figcaption><\/figure>\n\n\n\n

\u00c0 la rescousse de l’exp\u00e9rience utilisateur<\/h3>\n\n\n\n

Le cache am\u00e9liore le ressenti utilisateur m\u00eame s’il ne suffit pas \u00e0 lui seul \u00e0 atteindre l’objectif de temps de r\u00e9ponse. Par exemple, le taux de hit peut atteindre 80% quand on vise dans 95% des cas \u00e0 rester sous la barre des 3 secondes de temps de r\u00e9ponse. Pour autant, le ressenti utilisateur sera meilleur avec une r\u00e9ponse rapide dans 80% des cas. C’est sur ce principe qu’est calcul\u00e9 l’indice Apdex<\/a> qui \u00e9value le ressenti des clients finaux quant \u00e0 la performance. <\/p>\n\n\n\n

\"\"
Cache et performance<\/figcaption><\/figure>\n\n\n\n

\u00c0 l’inverse, une application trop lente devient inutilisable et les utilisateurs finaux expriment alors leur rejet. Cette lenteur est souvent caus\u00e9e par des op\u00e9rations d’entr\u00e9e-sortie (I\/O) trop nombreuses ou trop lentes (voire les deux !). Le cache est particuli\u00e8rement efficace dans ce genre de situation, en rempla\u00e7ant ces op\u00e9rations lentes par des \u00e9quivalents nettement plus rapides. La mise en place et la configuration de cache ont aussi le bon gout de ne pas trop alt\u00e9rer le code et de r\u00e9duire les risques de r\u00e9gression. C’est donc une m\u00e9thode efficace et rapide de r\u00e9solution de probl\u00e8me de performance, quand elle est applicable (ce qui n’est malheureusement pas toujours le cas \ud83d\ude41 ). Elle m’a permis de redresser des projets, \u00e0 plusieurs reprises dans ma carri\u00e8re. Au passage, la performance appara\u00eet comme une des rares caract\u00e9ristiques d’architecture qui soit perceptible dans l’exp\u00e9rience des utilisateurs finaux ! C’est un \u00e9l\u00e9ment tangible de ce que peut apporter la pratique d’architecture aux projets d’informatique.<\/p>\n\n\n\n

Protection contre la charge<\/h3>\n\n\n\n

Le cache est aussi un r\u00e9ducteur de la consommation des ressources. Il \u00e9vite de r\u00e9aliser sans cesse des op\u00e9rations qui produisent le m\u00eame r\u00e9sultat. Outre le gain d’efficience \u00e9vident, le cache \u00e9vite la saturation des ressources qui va provoquer une d\u00e9rive du syst\u00e8me. Le cache peut ainsi \u00eatre vu comme une mesure de protection contre un nombre de sollicitations trop important, qu’il soit intentionnel (par exemple, une attaque DDoS) ou non. J’avais eu le cas d’un site Internet satur\u00e9 \u00e0 cause du traitement des sollicitations des agr\u00e9gateurs RSS qui prenaient plus de 90% de la capacit\u00e9 de traitement. La mise en cache des flux RSS a r\u00e9solu la situation. Dans cette veine, on peut citer la conception Jamstack<\/a> qui permet de remplacer un site Web dynamique par un site statique facile \u00e0 mettre en cache et aussi \u00e0 distribuer, autour du monde.<\/p>\n\n\n\n

Le cache peut aussi nous faire faire des \u00e9conomies. La m\u00e9moire coute moins cher que le CPU. Il vaut donc mieux mettre un r\u00e9sultat stable en m\u00e9moire que le recalculer. Avec une allocation de 4\u2009Go par CPU sur les gabarits habituels de machine, la m\u00e9moire est de facto tr\u00e8s abondante.<\/p>\n\n\n\n

Le probl\u00e8me de l’invalidation du cache<\/h2>\n\n\n\n
\n

There are only two hard things in Computer Science: cache invalidation and naming things.<\/p>\nPhil Karlton<\/cite><\/blockquote>\n\n\n\n

Mais, alors, pourquoi avec toutes ces qualit\u00e9s, le cache n’a-t-il pas bonne presse ? Le probl\u00e8me est que le cache peut \u00eatre corrompu, c’est-\u00e0-dire contenir des donn\u00e9es qui ne sont plus \u00e0 jour, donc fausses. Les utilisateurs peuvent alors \u00eatre induits en erreur et prendre de mauvaises d\u00e9cisions. Enlever les donn\u00e9es d\u00e9pass\u00e9es du cache (ou les remplacer par des donn\u00e9es fraiches), c’est ce que l’on appelle invalider le cache. Il n’existe pas, dans le cas g\u00e9n\u00e9ral, de m\u00e9thode efficace, correcte et performante pour invalider le cache, une m\u00e9thode qui \u00e0 la fois donne un taux de hit <\/em>du cache \u00e9lev\u00e9 (efficace), \u00e9vite l’utilisation des donn\u00e9es d\u00e9pass\u00e9es (correcte) et n’introduit pas de blocage (performante). La raison profonde est qu’il est difficile d’\u00e9tablir un consensus entre la source de v\u00e9rit\u00e9 et le cache, sans qu’\u00e0 un moment, il n’y ait une suspension pour la synchronisation. On peut faire une analogie avec le probl\u00e8me des g\u00e9n\u00e9raux byzantins, que l’on rencontre dans le monde des blockchains<\/em>.<\/p>\n\n\n\n

La r\u00e9solution de l’invalidation par la maitrise du point de v\u00e9rit\u00e9<\/h3>\n\n\n\n

Le cache peut \u00eatre r\u00e9put\u00e9 non corrompu dans plusieurs cas particuliers, en \u00e9tablissant une acceptation de la fra\u00eecheur du cache sous un ensemble de condition. Le cas le plus favorable est quand l’application qui porte le cache dispose aussi du point de v\u00e9rit\u00e9 de fa\u00e7on unique. Elle peut alors garantir que le cache est mis \u00e0 jour \u00ab\u00a0en m\u00eame temps\u00a0\u00bb que le point de v\u00e9rit\u00e9. Cela correspond aux strat\u00e9gies de cache, Read Through<\/em> et Write Through<\/em>. Quand l’application est d\u00e9ploy\u00e9e en plusieurs instances (ce qui est maintenant la norme), ce cas demeure applicable si l’impl\u00e9mentation du cache supporte la distribution et fournit une s\u00e9mantique garantissant l’atomicit\u00e9 des op\u00e9rations sur le cache. Le deuxi\u00e8me cas, un peu moins favorable, est quand l’application qui a le cache re\u00e7oit des notifications de la source de v\u00e9rit\u00e9. L’application peut consid\u00e9rer le cache comme \u00e0 jour au d\u00e9lai pr\u00e8s de la notification. \u00c9videmment, le d\u00e9lai de notification n’est pas born\u00e9 et peut d\u00e9river en cas de forte charge. Il faudra prendre en consid\u00e9ration cette situation d\u00e9grad\u00e9e. Enfin, l’application peut accepter d’utiliser des donn\u00e9es d\u00e9pass\u00e9es pour les op\u00e9rations en lecture, mais toujours justes lors des op\u00e9rations d’\u00e9criture (on v\u00e9rifie alors que le cache est bien en accord avec la source de v\u00e9rit\u00e9, il s’agit de m\u00e9thode de verrou optimiste<\/em>).<\/p>\n\n\n\n

\"\"
Cache, propri\u00e9taire et utilisateur<\/figcaption><\/figure>\n\n\n\n

La r\u00e9solution de l’invalidation par le cycle de vie de la donn\u00e9e<\/h3>\n\n\n\n

Il existe une fa\u00e7on plus puissante d’avoir un cache \u00e0 jour qui d\u00e9pend du cycle de vie de la donn\u00e9e. La donn\u00e9e immuable est la donn\u00e9e id\u00e9ale pour un cache ! Malheureusement, rien n’est vraiment immuable dans notre monde. Le changement est la seule constante dans la vie\u202f!<\/em> En revanche, on trouve facilement des donn\u00e9es stables, des donn\u00e9es dont l’\u00e9tat change dans une \u00e9chelle de temps sensiblement plus grande que la dur\u00e9e des processus fonctionnels. Par exemple, nous avons un produit en vente. Son prix est r\u00e9vis\u00e9 tous les mois et la dur\u00e9e du tunnel de vente est rapide, moins d’une heure. Dans ce contexte, le prix du produit est une donn\u00e9e stable. On peut g\u00e9rer les donn\u00e9es stables avec la notion de dur\u00e9e de vie (Time To Live) qui permet de faire une invalidation dans un mode distribu\u00e9. Si une donn\u00e9e est versionnable<\/em>, c’est-\u00e0-dire que la version permet de fixer son \u00e9tat de la donn\u00e9e, alors les versions de la donn\u00e9e peuvent \u00eatre mises en cache sans risque de corruption. Enfin, il y a un cas r\u00e9ellement antagoniste \u00e0 la mise en cache : ce sont les s\u00e9ries chronologiques et les flux de donn\u00e9es (data stream<\/em>).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Cache By Design<\/h2>\n\n\n\n

Et, si le cache \u00e9tait pr\u00e9vu d\u00e8s la conception ? On pourrait alors esp\u00e9rer concilier les avantages d\u00e9crits pr\u00e9c\u00e9demment tout en mitigeant le risque de donn\u00e9es d\u00e9pass\u00e9es (Stale data<\/em>). Il s’agit donc essentiellement de privil\u00e9gier la manipulation de donn\u00e9es immuables.<\/p>\n\n\n\n

La premi\u00e8re approche qui vient en t\u00eate est l’Event Sourcing<\/a><\/em> : le changement d’\u00e9tat est d\u00e9fini des \u00e9v\u00e9nements et l’\u00e9tat est la r\u00e9sultante de la s\u00e9rie des \u00e9v\u00e9nements. Les \u00e9v\u00e9nements sont des donn\u00e9es stables, faciles \u00e0 propager et \u00e0 copier. L’\u00e9tat est \u00e9ventuellement consistant<\/em>. La coh\u00e9rence de l’information est assur\u00e9e \u00e0 un \u00e9cart correspondant au d\u00e9lai de propagation global et au taux de perte de transmission des messages. L’\u00e9tat d’une application d\u00e9pend de la somme des \u00e9v\u00e9nements re\u00e7us et sera alt\u00e9r\u00e9 par des \u00e9v\u00e9nements perdus ou arriv\u00e9s trop tard. Dit comme cela, le degr\u00e9 de confiance dans l’exactitude de l’\u00e9tat peut \u00eatre faible. Pour autant, l’application est capable de produire un \u00e9tat dans des conditions d\u00e9grad\u00e9es dans cette configuration alors qu’elle ne le pourrait pas dans une conception strictement synchrone. Pour revenir \u00e0 notre sujet, les \u00e9v\u00e9nements sont de bons candidats \u00e0 mettre en cache et le calcul de l’\u00e9tat peut se faire en m\u00e9moire. <\/p>\n\n\n\n

\"\"
Event sourcing<\/figcaption><\/figure>\n\n\n\n

Sur le sch\u00e9ma ci-dessus, le graphe de propagation des \u00e9v\u00e9nements a la qualit\u00e9 d’\u00eatre acyclique, ce qui permet de garantir la stabilit\u00e9 de l’\u00e9tat \u00e0 terme. En pr\u00e9sence de cycle, la d\u00e9finition de l’\u00e9tat stable pour l’ensemble du syst\u00e8me est plus probl\u00e9matique.<\/p>\n\n\n\n

Une autre approche, moins classique, consiste \u00e0 tracer les versions des objets et aussi les versions des objets ant\u00e9c\u00e9dents, un peu \u00e0 la fa\u00e7on d’une Horloge de Lamport<\/a>. Les versions des objets sont mises en cache comme elles sont immuables. Il est \u00e9galement possible de d\u00e9tecter quand nous manipulons une version d’objet alors qu’une plus r\u00e9cente est disponible et de pouvoir traiter ces cas de corruption de cache. Comment ? L’Horloge de Lamport va nous aider.<\/p>\n\n\n\n

Prenons le cas ci-dessous. Nous avons des \u00e9metteurs de versions d’objets. \u00c0 chaque \u00e9mission, la version est incr\u00e9ment\u00e9e. \u00c9galement, dans les transmissions, nous communiquons la version de l’objet, mais aussi celle de ses ant\u00e9c\u00e9dents. Par exemple, B \u00e9met un message vers C indiquant qu’il envoie la version 2 de B, construite avec la version 1 de A. Si le message de E arrive avant C ou D, un risque de corruption se pr\u00e9sente, car la version 2 de A va \u00eatre ing\u00e9r\u00e9e avant la version 1. On peut le voir autrement, F va r\u00e9cup\u00e9rer des versions de C et D en retard avec la version de A qu’il a re\u00e7u. De fa\u00e7on g\u00e9n\u00e9rale, on a un risque d’incoh\u00e9rence globale. Le cas id\u00e9al est quand les versions des objets \u00e0 chaque point du syst\u00e8me ne font que croitre (ce sont des fonctions monotoniques). <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La d\u00e9tection pourrait \u00eatre r\u00e9alis\u00e9e \u00e0 chaud, avec un diff\u00e9r\u00e9 correspondant au d\u00e9lai de propagation des messages estim\u00e9<\/em>, comme dans le cas de l’Event Sourcing. Mais, on peut aussi opter pour une approche \u00e0 froid : la d\u00e9tection est alors plus efficiente et a un degr\u00e9 de confiance plus \u00e9lev\u00e9e. L’approche \u00e0 froid est s\u00e9duisante, car on peut s’appuyer sur cette heuristique : la plupart des corruptions de cache n’ont pas de cons\u00e9quence. En effet, la donn\u00e9e peut \u00eatre mise \u00e0 jour un plus tard et une r\u00e9paration se fait souvent lors de cette mise \u00e0 jour. Ou encore la donn\u00e9e est conserv\u00e9e \u00e0 titre de m\u00e9moire et n’est pas ensuite exploit\u00e9e. Rares sont les cas o\u00f9 une mauvaise d\u00e9cision est prise alors que la donn\u00e9e n’est pas \u00e0 jour et ne peut \u00eatre compens\u00e9e. Un corollaire \u00e0 cette heuristique est la mauvaise qualit\u00e9 des donn\u00e9es dans le syst\u00e8me d’information qui malgr\u00e9 tout fonctionne. <\/p>\n\n\n\n

Effectivement, les approches de Cache By Design sont plus avanc\u00e9es que celles rencontr\u00e9es habituellement. Pour autant, elles peuvent aller chercher la performance suppl\u00e9mentaire requis pour certains besoins. En architecture, la r\u00e9ponse est souvent : \u00ab\u00a0\u00e7a d\u00e9pend …\u00a0\u00bb \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"

Le cache de donn\u00e9e, bien que performant et r\u00e9pandu, a mauvaise presse. M\u00eame si l’invalidation de cache reste un sujet complexe, le jeu en vaut la chandelle !<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[13,10],"class_list":["post-143","post","type-post","status-publish","format-standard","hentry","category-general","tag-cache","tag-event-sourcing"],"_links":{"self":[{"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/posts\/143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/comments?post=143"}],"version-history":[{"count":7,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/posts\/143\/revisions"}],"predecessor-version":[{"id":174,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/posts\/143\/revisions\/174"}],"wp:attachment":[{"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/media?parent=143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/categories?post=143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zoominandout.fr\/index.php\/wp-json\/wp\/v2\/tags?post=143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}