Réduction du temps de démarrage à froid sur Azure Container Apps

Lorsque votre application conteneur est mise à l’échelle à zéro pendant les périodes d’inactivité, la requête entrante suivante déclenche un démarrage à froid. Un démarrage à froid est le processus fastidieux de téléchargement de l'image du conteneur, de l'approvisionnement des ressources et du démarrage du code de votre application.

Ce délai a un impact sur l’expérience utilisateur, en particulier pour les applications qui nécessitent des temps de réponse rapides. Les démarrages à froid sont souvent les plus visibles dans les scénarios impliquant des images conteneur volumineuses, une initialisation d’application complexe ou des charges de travail ML/AI.

Ce guide vous aide à atténuer les heures de démarrage à froid dans Azure Container Apps.

Optimiser la taille de l’image conteneur

Les charges de travail de Machine Learning et d’IA sont souvent associées à des images conteneur volumineuses. Dans la mesure du possible, réduisez la taille de ces images autant que possible et éliminez toute utilisation de bibliothèques inutiles.

Souvent, les images passent de l’entraînement à l’inférence avec des ajustements minimes uniquement. Veillez à auditer vos conteneurs pour supprimer les outils de développement et les dépendances requis uniquement pour le développement de modèles lorsque vous préparez votre conteneur pour une utilisation d’inférence.

Évitez les registres d'images distants

Utilisez des registres de conteneurs proches de votre environnement Container Apps. Cela signifie généralement que vous souhaitez utiliser un registre Azure Container Registry déployé dans la même région que votre environnement, ou un registre Premium qui propose une distribution mondiale.

Gérer les téléchargements volumineux

Utilisez des montages de stockage pour contenir des données critiques proches de votre application conteneur, en particulier lorsque les tailles de fichier sont volumineuses. Par exemple, si votre application nécessite un modèle de langage volumineux, vous pouvez pré-télécharger le modèle sur votre compte de stockage. En lisant des fichiers volumineux à partir d’un compte de stockage, vous évitez la latence de l’extraction de fichiers sur Internet.

Si vous créez un montage de stockage pour les charges de travail IA, veillez à utiliser les options de montage les plus appropriées pour vos besoins.

Implémenter une sonde d’intégrité liveness personnalisée ou démarrer l'écoute de manière anticipée

Azure Container Apps configure automatiquement une sonde de vivacité lorsque l’entrée est activée. Les images et les applications prennent beaucoup de temps pour démarrer une fois l’image lancée peut entraîner des problèmes avec le conteneur. Container Apps peut tuer l’application de démarrage, car elle échoue à la probe liveness.

Pour empêcher Container Apps de tuer prématurément une image, implémentez une sonde de vivacité personnalisée pour permettre des démarrages plus longs. Vous pouvez également écouter sur le port cible dédié dès le début du cycle de démarrage afin d’établir des connexions simples pour initialiser votre application une fois le port ouvert.

Hébergements côté client

Les heures de démarrage à froid varient en fonction de votre application. Pour réduire autant que possible la perception de ce délai, préparez vos clients à s'y adapter.

Signaler aux utilisateurs qu’une certaine demande peut prendre plus de temps et implémenter des nouvelles tentatives est essentielle. Vous pouvez également renforcer votre code pour éviter des délais d’attente inattendus qui dépassent ce que votre application peut gérer correctement.

Instrumentation côté application

Pour résoudre les problèmes de performances, implémentez les métriques de performances côté application et la journalisation pour chaque étape du cycle de vie de votre application.

Réveillez votre application de manière proactive

Si les recommandations ci-dessus ne fournissent pas les performances souhaitées, réveillez votre application avant toute utilisation réelle. Par exemple, envisagez de configurer un travail à 9h pour réveiller l’application avant que les employés commencent leur journée de travail. Cette approche pourrait éliminer les longs démarrages à froid tout en permettant une mise à l'échelle à zéro pour réaliser des économies chaque fois que l'application n'est pas utilisée.