failing -> failure

_posts/2024-07-31-img-processor.md

@@ -63,11 +63,11 @@ Que ce soit des images très hautes résolutions de la voute céleste, une grill
 ## Failure mode
 
 À mon sens, il n'existe aucune autre solution que la conception d'un failure mode.
-Lorsque qu'une trop grande charge de travail est envoyée au service, ce dernier passe en failing mode le temps d'absorber la charge.
+Lorsque qu'une trop grande charge de travail est envoyée au service, ce dernier passe en *failure mode* le temps d'absorber la charge.
 Une fois la charge absorbée, le service *recover* et repasse dans son mode normal.
-Ce *failing mode* doit forcément être très efficace, sinon il ne sert à rien.
+Ce *failure mode* doit forcément être très efficace, sinon il ne sert à rien.
 
-On peut d'abord envisager un mode de fonctionnement très direct pour notre *failing mode* : envoyer un code d'erreur HTTP, comme le standard `503 service unavaibale` ou le non-standard `529 service overloaded`. Plus ambitieux, on peut envoyer une image placeholder à la place, sans directive de cache bien entendu, ce qui permettrait de donner une indication visuelle plus claire aux internautes, et potentiellement de moins casser le site web. 
+On peut d'abord envisager un mode de fonctionnement très direct pour notre *failure mode* : envoyer un code d'erreur HTTP, comme le standard `503 service unavaibale` ou le non-standard `529 service overloaded`. Plus ambitieux, on peut envoyer une image placeholder à la place, sans directive de cache bien entendu, ce qui permettrait de donner une indication visuelle plus claire aux internautes, et potentiellement de moins casser le site web. 
 Cette image placeholder serait pré-calculée au démarrage du service pour tous les formats supportés (JPEG, HEIC, etc.) et stockée en mémoire vive. Se pose encore la question de la taille : si on envoie une taille différente de celle attenduee, on peut "casser" le rendu du site. À contrario, générer une image à la bonne taille à la volée demande des calculs, bien que si on complète avec une couleur uniforme, ces calculs puissent possiblement être triviaux en fonction du format considéré. Enfin, le problème majeur, c'est que les images sont intégrées de pleins de manières différentes à travers un site web, parfois mélangées avec des filtres : comment s'assurer que notre placeholder sera correctement reçu et compris ?
 
 *Dans le cadre du développement d'une première itération, la solution des codes d'erreur semble de loin être la meilleure.*
@@ -88,7 +88,7 @@ Bien entendu, un tel système s'entend aussi avec un cache, qui pose son lot de
 
 Idéalement, le cache serait imputé par utilisateur-ice, directement dans leur bucket. L'expiration des objets seraient réalisée via le système de [Lifecyle](https://docs.aws.amazon.com/AmazonS3/latest/userguide/intro-lifecycle-rules.html) de S3 (non-implémenté dans Garage à ce jour). Avec les lifecycles, il est trivial d'implémenter un pseudo FIFO en expirant tous les objets X jours après leur création, mais moins évident de faire un LRU ou LFU. Sans considérer les lifecycles ni l'imputation par bucket, on peut imaginer une stratégie différente. En utilisant un seul bucket (par instance), on définirait un nombre fixé de "slots", par exemple 1 000, correspondant à une clé `cache0` à `cache999`. Un mapping entre la clé de cache et l'URL de l'image (son identifiant, sa taille, etc.) est maintenu en mémoire et est régulièrement flush, c'est l'index. Ce dernier contient aussi la date de dernier accès, et toute autre information utile/importante pour la stratégie d'eviction du cache. Il se peut que la clé de cache et l'index se désynchronise, afin d'éviter d'envoyer une donnée "corrompue", on vérifie que l'ETag stocké dans l'index correspond à celui de l'objet. Afin d'éviter une explosion du stockage, on met aussi une borne supérieure sur la taille de ce qui peut être stocké dans le cache. Par exemple, avec une borne à 5Mo et 1000 fichiers, notre cache ne dépassera pas 5Go. Enfin, on peut suivre l'efficacité de notre cache en trackant des métriques bien connus sur ce dernier (cache hit, cache miss, etc.).
 
-*Si on pourrait être tenté dans une première itération de ne pas utiliser S3 pour le cache mais le filesystem ou la mémoire vive, je pense que c'est une erreur. Si le CDN se reschedule sur un autre noeud, on perd le cache, et on risque de passer trop souvent dans le failing mode inutilement, créant du désagrément et de l'incompréhension pour rien auprès des utilisateur-ices.*
+*Si on pourrait être tenté dans une première itération de ne pas utiliser S3 pour le cache mais le filesystem ou la mémoire vive, je pense que c'est une erreur. Si le CDN se reschedule sur un autre noeud, on perd le cache, et on risque de passer trop souvent dans le failure mode inutilement, créant du désagrément et de l'incompréhension pour rien auprès des utilisateur-ices.*
 
 *On peut aussi être tenté d'utiliser des outils de caching existants plutôt que de ré-implémenter notre propre politique de cache. D'abord ça n'est pas évident que ce soit possible dans notre cas. Ensuite les outils de caching ne sont pas prévus pour notre cas d'usage où on a besoin de stocker dans S3. Enfin, ça nous rendrait impossible l'implémentation ultérieure de l'imputation du stockage à l'utilisateur final.*