Comparaison des compromis de performance de la persistance AOF vs. RDB

Redis est réputé pour sa vitesse fulgurante, atteignant souvent une latence inférieure à la milliseconde. Cependant, lorsque la persistance est activée—permettant de sauvegarder les données sur disque pour les récupérer après un redémarrage—les développeurs doivent choisir un mécanisme. Les deux principales méthodes de persistance dans Redis sont la sauvegarde par instantané (RDB) et le fichier append-only (AOF). Comprendre les implications en termes de performance, les caractéristiques de durabilité et les compromis de configuration de chacune est crucial pour ajuster Redis afin de répondre aux exigences spécifiques de l'application en matière de vitesse et de sécurité des données.

Ce guide examine en détail RDB et AOF, en expliquant leur fonctionnement, leurs impacts respectifs sur la latence des performances, et en fournissant des informations pratiques pour choisir la bonne stratégie de persistance pour vos déploiements Redis haute performance.

Comprendre la persistance Redis

Redis stocke l'intégralité de son jeu de données en mémoire volatile. Les mécanismes de persistance sont nécessaires pour déplacer ces données sur disque afin que Redis puisse recharger le jeu de données lors d'un redémarrage, assurant ainsi la disponibilité des données en cas d'interruptions de service ou de redémarrages. RDB et AOF atteignent cet objectif par des approches fondamentalement différentes, conduisant à des profils de performance distincts.

1. Sauvegarde par instantané (RDB) de la base de données Redis

RDB crée un instantané compact et ponctuel de l'ensemble du jeu de données à des intervalles spécifiés. Il enregistre ces données dans un fichier binaire (dump.rdb).

Fonctionnement du RDB et son impact sur les performances

La persistance RDB repose fortement sur la commande BGSAVE (Sauvegarde en arrière-plan). Lorsqu'une sauvegarde est déclenchée :

Duplication (Forking) : Redis duplique le processus principal en un processus enfant.
Prise d'instantané : Le processus enfant écrit l'intégralité du jeu de données dans le fichier RDB sur disque.
Fil principal non affecté (principalement) : Le fil principal de Redis continue de servir les requêtes des clients sans être bloqué pendant l'opération d'écriture, car l'enfant gère les E/S disque.

Considérations relatives aux performances :

Latence d'écriture : Généralement, RDB a un impact minimal sur la latence d'écriture pendant l'opération de sauvegarde, car le travail est déchargé. Le coût principal en termes de performance est le pic d'utilisation CPU et la pointe d'E/S initiale requise lors de la duplication et pendant l'écriture du fichier volumineux.
Temps de récupération : RDB se charge très rapidement au redémarrage car il s'agit d'un fichier unique et optimisé, minimisant la latence de récupération.
Compromis sur la durabilité : Si Redis plante entre des sauvegardes planifiées (par exemple, toutes les 5 minutes), toutes les écritures effectuées depuis la dernière sauvegarde sont perdues. Cela rend RDB moins durable qu'AOF.

Configuration des sauvegardes RDB

Les sauvegardes RDB sont configurées à l'aide de la directive save dans le fichier redis.conf, en spécifiant des intervalles de temps et le nombre de changements :

save 900 1     # Sauvegarder si 1 clé a changé en 900 secondes (15 minutes)
save 300 10    # Sauvegarder si 10 clés ont changé en 300 secondes (5 minutes)
save 60 10000  # Sauvegarder si 10000 clés ont changé en 60 secondes (1 minute)

2. Persistance via fichier Append-Only (AOF)

AOF enregistre chaque opération d'écriture reçue par le serveur Redis dans un fichier de journalisation append-only. Lorsque Redis redémarre, il rejoue ces commandes séquentiellement pour reconstruire le jeu de données.

Fonctionnement de l'AOF et son impact sur les performances

Contrairement à RDB, AOF se concentre sur la journalisation transactionnelle. Le profil de performance dépend fortement de la politique fsync, qui dicte la fréquence à laquelle Redis force le système d'exploitation à écrire les données tamponnées sur le disque physique.

Politiques Fsync d'AOF :

Politique	Paramètre `appendfsync`	Durabilité	Impact sur les performances
Chaque seconde	`everysec`	Bonne (perd ~1 seconde de données)	Bon équilibre ; surcharge minime. Recommandé par défaut.
Aucune synchronisation	`no`	Faible (dépend du tampon de l'OS)	Le plus rapide ; risque maximal de perte de données en cas de crash du système d'exploitation.
Toujours	`always`	Excellente (écriture atomique)	Le plus lent ; augmentation significative de la latence due aux E/S disque obligatoires à chaque écriture.

Considérations relatives aux performances :

Latence d'écriture : Lors de l'utilisation de appendfsync always, chaque commande d'écriture entraîne la latence d'une synchronisation disque, ralentissant considérablement les opérations par rapport à RDB ou aux opérations en mémoire. L'utilisation de everysec atténue cela de manière significative en regroupant les fsyncs.
Temps de récupération : Les fichiers AOF peuvent devenir volumineux et rejouer des millions de commandes peut prendre plus de temps que de charger un fichier RDB compact, entraînant une latence de récupération plus élevée.
Taille du fichier : Les fichiers AOF sont généralement beaucoup plus grands que les fichiers RDB car ils stockent des commandes (par exemple, SET key value) plutôt que l'état final de la structure de données.

Activation et configuration de l'AOF

AOF est désactivé par défaut et est activé en définissant appendonly yes dans redis.conf. Le paramètre crucial est appendfsync :

appendonly yes
appendfilename "appendonly.aof"
# Paramètre recommandé pour le compromis durabilité vs. vitesse
appendfsync everysec

Analyse des compromis de performance : AOF vs. RDB

Choisir entre RDB et AOF nécessite de prioriser soit la vitesse opérationnelle brute (latence), soit la récupération garantie des données.

Latence et débit

RDB (Idéal pour la vitesse brute) : Puisque les écritures sont gérées par un processus en arrière-plan, le fil principal de Redis subit un impact direct minimal des E/S pendant les sauvegardes. Cela se traduit généralement par une latence d'écriture globale inférieure, sauf si le système est fortement chargé lors de la duplication BGSAVE.
AOF (mode always) : Cette configuration est la plus lente car la latence du disque est introduite directement dans chaque commande d'écriture client, conduisant à des latences p99 plus élevées.
AOF (mode everysec) : Cela offre des performances presque similaires à RDB pour la plupart des opérations, car les opérations fsync sont mises en tampon et moins fréquentes.

Durabilité et risque de perte de données

AOF (Idéal pour la durabilité) : Offre la plus haute durabilité, surtout avec appendfsync always. Même avec everysec, la perte de données est limitée à une seconde.
RDB (Le moins durable) : La perte de données peut s'étendre sur des minutes ou des heures, selon le calendrier de sauvegarde.

Temps de récupération

RDB (Récupération rapide) : Temps de redémarrage plus rapides grâce au format binaire compact et optimisé.
AOF (Récupération plus lente) : Rejouer un grand journal de commandes peut prendre plus de temps que de charger un instantané, augmentant le temps d'arrêt pendant les redémarrages.

Meilleure pratique : Utiliser les deux méthodes de persistance

Pour les environnements exigeant à la fois des performances élevées et de solides garanties de durabilité, l'approche recommandée est d'activer simultanément les persistances RDB et AOF.

Lorsque les deux sont activées, Redis utilise le fichier AOF pour la relecture au démarrage afin d'atteindre une cohérence maximale des données. Il continue de générer des instantanés RDB périodiquement.

Pourquoi utiliser les deux ?

Récupération plus rapide : Si le fichier AOF est corrompu ou extrêmement volumineux, Redis peut utiliser l'instantané RDB le plus récent comme point de départ, accélérant considérablement le processus de relecture AOF ultérieur.
Efficacité de la réécriture AOF : Redis peut automatiquement déclencher une opération de réécriture AOF (qui génère un nouveau fichier AOF compact en écartant les commandes redondantes) basée sur l'instantané RDB le plus récent, ce qui est souvent plus efficace que de réécrire uniquement à partir du journal AOF existant.

Extrait de configuration pour les deux :

# 1. Activer RDB
save 900 1

# 2. Activer AOF avec la synchronisation 'everysec'
appendonly yes
appendfsync everysec

Gestion de la taille du fichier AOF (Réécriture)

Une préoccupation opérationnelle majeure avec AOF est la croissance de la taille des fichiers. Au fil du temps, le fichier AOF peut devenir massif car il enregistre chaque modification, même celles qui écrasent les valeurs précédentes. Pour contrer cela, Redis propose la réécriture AOF.

La réécriture AOF génère un nouveau fichier AOF optimisé qui ne contient que l'ensemble minimal de commandes nécessaires pour reconstruire l'état actuel du jeu de données. Ce processus est déclenché automatiquement lorsque la taille du fichier AOF actuel dépasse un certain multiple de la taille de base.

auto-aof-rewrite-percentage 100  # Réécrire lorsque le fichier AOF est 100 % plus grand que la taille de base
auto-aof-rewrite-min-size 64mb    # Ne pas réécrire à moins que le fichier ne fasse au moins 64 Mo

Avertissement sur la réécriture : Comme la sauvegarde RDB, la réécriture AOF implique la duplication du processus. Si votre système est limité en mémoire, ce doublement temporaire de l'utilisation de la mémoire (l'instance en direct plus la copie en cours de réécriture) peut entraîner une instabilité ou du swapping.

Conclusion

Les choix de persistance de Redis sont un équilibre direct entre la latence et la durabilité. RDB excelle dans la récupération rapide et la surcharge d'écriture minimale mais risque une perte de données. AOF offre une sécurité des données supérieure mais peut introduire de la latence d'écriture selon la politique fsync.

Pour la plupart des charges de travail de production privilégiant un débit élevé avec une sécurité raisonnable, l'activation de l'AOF avec appendfsync everysec est la recommandation standard. Pour les systèmes critiques nécessitant une perte de données quasi nulle, l'activation des deux (RDB et AOF) offre la meilleure résilience opérationnelle et flexibilité de réglage des performances.