Croissance illimitée de l'État

Si votre application ne supprime pas correctement les informations d’état obsolètes, elles s’accumuleront continuellement et entraîneront des problèmes de performance ou de stabilité de l’application. Cette section décrit les symptômes et les étapes de résolution de ce problème.

Symptômes

Ce problème peut présenter les symptômes suivants :

• La métrique lastCheckpointDuration augmente progressivement ou connaît des pics.

• La métrique lastCheckpointSize augmente progressivement ou connaît des pics.

Causes et solutions

Les conditions suivantes peuvent amener votre application à accumuler des données d’état :

• Votre application conserve les données d’état plus longtemps que nécessaire.

• Votre application utilise des requêtes de fenêtre d’une durée trop longue.

• Vous n’avez pas défini le TTL pour vos données d’état. Pour plus d'informations, consultez State Time-To-Live (TTL) dans la documentation d'Apache Flink.

• Vous exécutez une application qui dépend de la version 2.25.0 ou ultérieure d’Apache Beam. Vous pouvez vous désinscrire de la nouvelle version de la transformation de lecture en BeamApplicationProperties ajoutant les expériences et les valeurs clésuse_deprecated_read. Pour plus d’informations, consultez la documentation Apache Beam.

Parfois, les applications sont confrontées à une augmentation constante de la taille de l’état, qu’elles ne peuvent supporter à long terme (une application Flink fonctionne indéfiniment, après tout). Parfois, cela peut venir du fait que les applications stockent les données dans leur état, sans permettre le vieillissement correct des anciennes informations. Mais parfois, les attentes quant à ce que Flink peut offrir sont tout simplement déraisonnables. Les applications peuvent utiliser des agrégations sur de longues périodes s’étendant sur des jours, voire des semaines. À moins qu'il AggregateFunctionsne soit utilisé, ce qui permet des agrégations incrémentielles, Flink doit conserver les événements de l'ensemble de la fenêtre en état.

En outre, lors de l’utilisation de fonctions de processus pour implémenter des opérateurs personnalisés, l’application doit supprimer les données d’état qui ne sont plus nécessaires à la logique métier. Dans ce cas, l'état time-to-live peut être utilisé pour vieillir automatiquement les données en fonction du temps de traitement. Le service géré pour Apache Flink utilise des points de contrôle incrémentiels, ainsi l’état TTL est basé sur le compactage RocksDB. Vous ne pouvez observer une réduction réelle de la taille de l’état (indiquée par la taille du point de contrôle) qu’après une opération de compactage. En particulier pour les points de contrôle de taille inférieure à 200 Mo, il est peu probable que vous observiez une réduction de la taille des points de contrôle à la suite de l’expiration de l’état. Cependant, les points de sauvegarde sont basés sur une copie propre de l’état, qui ne contient pas d’anciennes données. Vous pouvez donc déclencher un instantané dans le service géré pour Apache Flink afin de forcer la suppression de l’état obsolète.

À des fins de débogage, il peut être judicieux de désactiver les points de contrôle incrémentiels pour vérifier plus rapidement que la taille du point de contrôle diminue ou se stabilise réellement (et éviter l’effet de compactage dans RocksBS). Pour cela, il faut cependant envoyer un ticket à l’équipe du service.