Peut-on exécuter plusieurs instances d’une application ? Liste de vérification

Que signifie exécuter plusieurs instances ?

La mise à l’échelle horizontale consiste à faire fonctionner plusieurs instances répliquées d’une application. Ce modèle ne doit pas être présumé compatible avec chaque application auto-hébergée : vérifiez d’abord les recommandations officielles qui correspondent à votre application et à votre mode de déploiement.

Les termes employés dans la documentation peuvent désigner des configurations différentes. Une mention de plusieurs environnements ou installations n’établit pas nécessairement que plusieurs instances peuvent servir le même déploiement.

• Précisez le besoin auquel vous cherchez à répondre, par exemple une exigence de capacité ou de disponibilité.
• Cherchez une documentation qui décrit explicitement plusieurs instances du même déploiement.
• Si les indications sont absentes ou ambiguës, demandez confirmation à l’éditeur ou aux responsables du projet.

Lire les recommandations propres à l’application

Vérifiez que la documentation concerne bien l’application, sa version et le mode d’installation que vous utilisez. Notez les prérequis et les limites explicitement indiqués, plutôt que de déduire la compatibilité à partir de la seule infrastructure.

Les termes peuvent prêter à confusion. La page de Retool intitulée « Multi-instance deployment » décrit la définition de plusieurs environnements au sein d’une même instance. Cette description ne suffit pas à établir que plusieurs réplicas de l’application peuvent servir un même déploiement. Consultez la page officielle : [Multi-instance deployment de Retool](https://docs.retool.com/self-hosted/self-managed/concepts/multi-instance-deployment).

La liste de préparation à la production de Temporal pour les déploiements auto-hébergés aborde notamment la mise à l’échelle, les métriques, les tests de charge et le versionnement des workflows. Il s’agit de recommandations propres à Temporal, pas d’une liste universelle pour d’autres applications : [Production readiness checklist de Temporal](https://docs.temporal.io/self-hosted-guide/production-checklist).

• La documentation indique-t-elle explicitement que plusieurs instances peuvent servir le même déploiement ?
• Les prérequis et les limites du modèle sont-ils décrits pour votre version et votre méthode d’installation ?
• Les termes utilisés distinguent-ils clairement les instances, les environnements et les processus de travail ?

Questions à clarifier avant les tests

Les exigences varient selon l’application : il n’existe pas, dans les éléments documentés ici, de réponse universelle sur les sessions, les fichiers, les caches, les connexions à la base de données, les tâches en arrière-plan ou les mises à niveau. Utilisez ces sujets comme questions à poser à l’éditeur, et non comme des prérequis identiques pour toutes les applications.

Demandez comment l’application prévoit de gérer chaque élément pertinent dans le modèle envisagé. Consignez les réponses documentées et distinguez-les des points qui restent à tester.

• État partagé : que dit la documentation au sujet des sessions, des fichiers téléversés et des caches, si ces éléments sont utilisés ?
• Traitements en arrière-plan : comment les tâches planifiées ou en file d’attente sont-elles prises en charge dans ce modèle ?
• Routage : quelles indications l’éditeur donne-t-il sur l’acheminement du trafic et les vérifications d’état ?
• Mises à niveau : quelles instructions sont fournies pour les versions et les migrations ?

Valider le comportement dans un environnement de test

Si la documentation et les responsables de l’application confirment que le modèle est pris en charge, définissez des tests adaptés aux workflows réellement utilisés. Fixez à l’avance les résultats attendus et comparez-les aux consignes de l’application.

La liste de Temporal mentionne les métriques et les tests de charge dans le contexte de ses recommandations de préparation à la production. Pour une autre application, recherchez des conseils équivalents auprès de son éditeur plutôt que de transposer automatiquement ceux de Temporal.

• Choisissez des workflows représentatifs et des données de test.
• Vérifiez les points que la documentation de votre application identifie comme importants.
• Consignez les résultats et les questions qui restent sans réponse.
• N’interprétez pas un test limité comme une preuve de compatibilité dans toutes les conditions.

Choisir un modèle de déploiement adapté

Décidez en fonction des exigences de votre équipe et du modèle que l’éditeur documente. Les éléments disponibles ici ne permettent pas de comparer de façon générale plusieurs instances à une instance unique plus puissante : la pertinence de chaque option dépend de l’application et du besoin.

Si le modèle souhaité n’est pas documenté, demandez conseil à l’éditeur ou aux responsables du projet avant de le déployer. Un hébergement géré peut prendre en charge des opérations d’infrastructure, mais ne prouve pas à lui seul qu’une application particulière accepte plusieurs instances. Les choix liés aux données, aux accès et à la gouvernance restent à examiner.

Airbip propose le déploiement géré d’un catalogue public d’applications métier, de publication, d’analyse, de collaboration et d’IA sous forme de charges de travail Docker sur les serveurs cloud Airbip. Le service comprend des vérifications DNS, la gestion du cycle de vie des services, des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables ainsi que le routage et le TLS automatisés au moyen de Traefik et Let’s Encrypt. Ces capacités d’infrastructure ne déterminent pas la compatibilité d’une application avec plusieurs instances. Consultez le site Web Airbip pour connaître les offres et conditions en vigueur.

• Retenez un modèle explicitement documenté pour l’application.
• Demandez une clarification si la documentation ne répond pas à votre besoin.
• Séparez les capacités de l’infrastructure de celles de l’application.