Une configuration obsolète sur AWS a mis Instapaper KO

Instapaper a connu une panne majeure début février. Propriété de Pinterest depuis l’an passé, ce service qui permet de sauver des pages web pour les lire plus tard (en mode d’affichage allégé) n’a plus du tout fonctionné durant une trentaine d’heures. Les utilisateurs n’ont toutefois pas perdu de données. Instapaper a dans un premier temps été rétabli partiellement, ne donnant qu’accès au contenu archivé des utilisateurs. Les fonctions de sauvegarde et d’organisation des marques-pages n’ont en revanche été restaurées que cinq jours plus tard.

La faute à une limite levée il y a bientôt trois ans

Dans un billet de blog, le responsable d’Instapaper Brian Donohue est revenu en détails sur les causes de la panne et les manœuvres qui ont permis au service d’être à nouveau totalement opérationnel. On y apprend que le problème est survenu quand la base de données d’Instapaper, hébergée sur AWS, a atteint sa limite de stockage de 2 téraoctets. Une limite qui concernait les instances de base de données Amazon RDS MySQL créées avant avril 2014, il y a donc bientôt trois ans. Après quoi AWS a fait passer la limite des ces instances à 6 téraoctets... On aurait a priori tendance à pointé du doigt un flagrant manque de réactivité de la part des équipes d'Instapaper. Mais ça n'est pas si simple.

Aucun avertissement

Début 2015, le service a procédé à un upgrade de sa base de données MySQL via une réplique en lecture de ses premières instances créées sur AWS, en juin 2013, héritant dans ce cadre du système de fichiers anciens incluant la limite des 2 téraoctets. Instapaper souligne en outre n'avoir jamais été au courant de cette limite de stockage, les premières instances AWS ayant été créées en 2013 par un prestataire tiers, chargé par la société possédant Instapaper à l’époque (Betaworks) de migrer du cloud Softlayer vers AWS. Dans son billet, Brian Donohue regrette que la console d'AWS ne prévienne d'aucune façon quand le volume de donnés approche sa taille maximale. En outre, les sauvegardes automatiques et quotidiennes des instances RDS créaient des images du système de fichiers, lesquelles sont du coup également limitées à 2 téraoctets. «Nous n'avions pas de bon plan de reprise après sinistre», en déduit le responsable du service.

Base de données à reconfigurer de zéro

Epaulée par des techniciens de Pinterest, l’équipe d’Instapaper n’a eu d’autre choix que celui de reconfigurer de zéro les instances MySQL RDS, via un processus complet de dump and restore (copie et transfert complets vers une base de données restaurée). Réalisant que la manœuvre allait prendre plusieurs jours, Instapaper a d’abord créé une instance provisoire pour l’accès aux archives. En guise de conclusion, Brian Donohue fait son mea culpa: «Bien que les informations sur la limitation à 2 téraoctets ne m’était pas directement disponibles, il est de ma responsabilité de comprendre les limites des technologies que j'utilise au quotidien.»