Résoudre les incohérences des requêtes PUT S3 chez Transloadit
Amazon S3 est formidable. Sauf quand il ne l’est pas. Lorsque vous l’utilisez intensivement (nous avons stocké jusqu’ici environ un million d’objets de clients), vous commencez à remarquer des choses étranges qui ressemblent davantage à de la « folie à terme » qu’à de la « cohérence à terme ».
L’une des choses que nous avons apprises tout de suite, c’est qu’on ne peut pas se fier aux codes
d’erreur de S3. Il vous arrive de voir un 403 Permission Denied, mais lorsque vous exécutez
à nouveau exactement la même requête, elle fonctionne soudain comme par miracle. C’est pourquoi il
faut en général réessayer lorsque vous recevez un message d’erreur. Ce n’est que lorsqu’une erreur
donnée se produit plusieurs fois qu’il convient d’y prêter attention. Nous réessayons actuellement
jusqu’à 6 fois, avec des délais d’expiration croissants.
Le dernier problème que nous avons rencontré, c’est qu’on ne peut pas non plus se fier aux confirmations de S3 pour les requêtes PUT. Le symptôme que nous avons observé était que certaines des URL S3 renvoyées à nos clients ne fonctionnaient tout simplement pas. Reproduire ce problème a été un énorme défi. À un moment, nous avons pu le constater après ~25 PUT, une autre fois rien ne s’est produit après 2500 PUT (10 GB au total). Il reste donc une infime possibilité qu’un bug se trouve quelque part dans notre système, mais à ce stade nous avons de bonnes raisons de croire qu’il s’agit d’un problème d’Amazon qui survient de manière peu fréquente.
Bienvenue au pays de la folie. Face à un système à cohérence à terme, où « à terme » peut parfois signifier « jamais », comment vérifier la réussite d’une opération d’écriture ? Vous pouvez bien sûr consulter le bucket après chaque écriture pour voir si l’objet existe, mais que faire s’il n’existe pas ? À partir de quand cela devient-il une condition d’erreur ? Et, lorsque l’objet existe, qu’est-ce que cela signifie ? On peut raisonnablement supposer qu’au moins un client est capable de voir l’objet, mais pas que sa réplication est terminée et qu’il est donc disponible pour tous les clients.
Bien qu’il n’existe pas de réponse parfaite, nous avons décidé de vérifier la présence d’un fichier stocké avec jusqu’à onze vérifications sur une période de deux minutes. Si le fichier n’existe toujours pas au bout de ce délai, nous relançons la tâche jusqu’à six fois. Même si c’est loin d’être idéal, cela ramènera probablement le risque de fournir des URL S3 invalides à un niveau comparable à celui de gagner un joli lot à la loterie.
Autre point qui nous a semblé intéressant : le modèle de cohérence de S3 n’est pas le même dans toutes les régions. Alors que « US Default » applique le modèle traditionnel de « cohérence à terme », toutes les autres régions offrent une cohérence « lecture après écriture ». Même si c’est extrêmement déroutant du point de vue du client, la raison semble être que « US Default » s’étend de la côte est à la côte ouest, si bien que la vitesse de la lumière empêche d’offrir les mêmes garanties.
Nous sommes en train de recueillir des données plus précises sur notre expérience avec S3, que nous partagerons à l’avenir. S3 fonctionne sans aucun doute très bien pour nous la plupart du temps, et s’il s’avère que nous l’utilisions mal, nous reviendrons également sur ce point.