Une instance massive d'une application ou de nombreuses moyennes?

Question

Une application Web que nous avons écrite et destinée à un client va être adaptée au produit et vendue à des dizaines d’entreprises, et nous ferons l’hébergement.

Je pourrais utiliser certaines indications sur les avantages et les inconvénients du déploiement d'une instance distincte pour chaque client, par opposition à l'utilisation d'une seule (ou d'un très petit nombre) instances multi-locataires.

Au début, à mesure que nous progressons, nous devrons déployer une instance distincte de l'application pour chaque nouveau client (ils viendront en ligne un par un) car c'est la seule option immédiate. . J'imagine que cela ne sera pas très efficace en ce qui concerne la maintenance. Les modifications apportées deviendront très fastidieuses et risquent de générer des erreurs une fois qu'il y a plus de 4 ou 5 instances. Sauf si nous automatisons cela d'une manière ou d'une autre.

En outre, la philosophie de l’instance unique semble donner lieu à de nombreuses contraintes si les utilisateurs ont besoin de personnalisations. Et ce serait bien d’éviter cela.

Alors, quelle a été votre expérience avec cela?

Question complémentaire n ° 1: Quelle est la différence de performances entre 10 serveurs SQL avec 2 m d’enregistrements chacun et 1 énorme avec 20 m? Disons qu'ils sont tous dans une seule table et que nous faisons principalement des insertions et des sélections sur des enregistrements individuels. Parfois, les sélections se trouvent sur un champ indexé varchar (12) ou date.

Question complémentaire n ° 2: , j'imagine que pour éviter toute falsification, il faudrait rendre les personnalisations configurables ou créer une architecture de plug-in. Cependant, cela pourrait augmenter le coût de personnalisation, et je ne veux pas faire partie de ces magasins qui prennent une semaine pour redimensionner une zone de texte, et je ne veux pas trop investir dans Infrastructure. Des idées à ce sujet?

Détails de l'échelle

Chaque client disposera d’une quantité décente de données - jusqu’à quelques millions d’enregistrements.

Il y aura un très petit nombre d'utilisateurs simultanés, quelques-uns par client, plus une poignée de représentants internes.

Il n'est pas clair si chaque client nécessitera des personnalisations, mais je dirais que certains le feront probablement, et que certains de ces changements seront peut-être des éléments que d'autres clients ne voudront pas voir.

Answer 1

Je ne vois pas de bonne raison pour l'une ou l'autre de vos deux options. Je pense que la vraie réponse se situe quelque part au milieu: avoir plusieurs instances, chacune hébergeant plusieurs clients.

Cela ajoute une couche supplémentaire de traitement automatisé, mais cela signifie que vous pouvez garder l’hébergement bon marché (vous n’aurez pas besoin de sortir et acheter un Cray de si tôt) et (espérons-le) cette sorte de mentalité signifie que vous pouvez effectuer un basculement. sauvegarde assez facilement.

Mais ne prenons pas une longueur d'avance sur nous-mêmes… Nous parlons d'une application Web, n'est-ce pas? Obtenez votre base de données et aspnet sur différentes machines. Cluster vos bases de données et vous aurez beaucoup plus de plaisir à jouer avec divers scénarios front-end. Vous serez également en mesure de rehausser le rang de la zone où il n'y a pas de bouffée en premier.

À ce qu'il semble, vous obtiendrez une base de données en cluster sur plus de la moitié, voire une douzaine de machines de base de données, et seulement quelques zones frontales.

En ce qui concerne les personnalisations, vous avez réussi. Vous pouvez soit fournir un ensemble de modèles modifiables hébergé complètement à la base de données, soit vous devez personnaliser les instances who. Je suis tout pour le premier. C'est beaucoup de travail (sans grand retour), mais cela en vaut la peine, car vous ne devriez avoir besoin de changer le code principal que lorsque (vous le ferez!) Vous effectuez des mises à niveau. Recherchez parmi les centaines d'instances personnalisées de cent clients pour vous assurer que leur mise à niveau tuerait un développeur! Les modèles sont la solution. À tout le moins, vous pourriez autoriser le CSS personnalisé sans trop de peine (mais ils auraient besoin de quelqu'un qui connaît leur métier).

Edit: J'ai vu quelques articles utiliser la méthode du tout-en-un. La division des instances en plusieurs machines vous isole de plusieurs choses:

• Si vous introduisez un bogue non détecté lors des tests, seuls quelques clients sont affectés en même temps.

• Le matériel échoue. Si un méga-serveur tombe, cela agace beaucoup de gens à la fois. Avoir un méga-serveur de basculement est extrêmement coûteux. Avoir une boîte de secours disponible pour trois ou quatre serveurs en fonctionnement est beaucoup moins cher et agace moins de gens.

• Les performances peuvent être équilibrées client par client. Vous pouvez donc placer quelques clients légers avec un client lourd ou simplement remplir une boîte avec quelques clients à usage moyen, etc. .

• Sur la même idée, les pointes d’utilisation ou autres ralentissements affectent uniquement les clients situés dans la même boîte. Bien sûr, cela ne signifie pas la même chose pour la base de données, mais vous pouvez le scinder en grappes lorsque vous y arrivez.

Answer 2

face à un défi similaire, voici ce que nous avons fait:

1. nous avons une base de code avec plusieurs serveurs SQL. Nous maintenons plusieurs serveurs IIS avec des copies du même code base. nous sommes libres de déplacer les clients de serveur SQL à serveur SQL pour optimiser les performances.

2. si un client a le $ requis, nous l'installerons sur son propre serveur et lui tiendrons un serveur IIS distinct. Cela convient aux plus gros clients pour lesquels ils paient beaucoup plus chaque mois (10 fois plus d'argent). Cependant, nous ne leur donnons pas une base de code séparée. s’ils ont besoin d’un mod, nous le rendons visible client par client (voir n ° 3)

3. la programmation personnalisée donne généralement lieu à une option configurable. Même les personnes qui nous paient pour avoir leur propre serveur reçoivent la même version du code. Parfois, c’est aussi simple qu’une clause dans le code qui dit "si le client =" notre gros client, puis activez cette option ". oui, c’est du kludgy codage en dur, mais si le client a assez d’argent, c’est bien avec moi.

4. Je ne vous ai pas bien compris si vous vouliez mélanger les données de différents clients dans une seule et même base de données. Notre règle est que nous ne jamais faisons cela. c'est l'un des choix les plus sages que nous ayons jamais faits. cela rend la manipulation de données beaucoup moins risquée et facilite la restauration des données.

Answer 3

Le gros avantage des instances individuelles sera l’extension à mesure que la demande de chaque client augmente. Par exemple, si vous utilisez un seul serveur et qu'un client a soudainement besoin de plus de performances, vous êtes bourré. Mais s’ils sont tous individuels, il est relativement facile de déplacer ce client vers un nouveau serveur brillant.

Le gros inconvénient sera de gérer les instances toutes individuellement. (qu'ils fonctionnent ou non sur le même serveur).

Quoi qu'il en soit, vous ne devriez jamais avoir qu'une seule instance de la base de code. Et la personnalisation doit être contrôlée via les plugins et la configuration. Front-end devrait naturellement être séparé du contenu. Bien que le coût d'un changement puisse être plus élevé, l'avantage en termes de fonctionnalités que vous pouvez offrir à vos autres clients (qui ne seront que les personnalisations qu'il vous a été demandé de faire) sera rentable, j'en suis sûr. Ce qui ne veut pas dire à quel point il sera plus facile de gérer une seule base de code, par opposition à plusieurs.

Answer 4

Je vous conseillerais vivement de n'utiliser que l'instance unique hébergée par votre société. Cela présente les avantages suivants:

• Vous avez un accès physique à tout le code et des bases de données pour apporter des modifications et mises à jour.
• Vous contrôlez la qualité du le matériel sur lequel il fonctionne.
• Lorsque vous corrigez un bogue dans le code commun, vous l'avez corrigé une fois pour toutes clients.
• Vous pouvez refactoriser l'application concevoir pour mieux supporter le client code spécifique et éviter de falsifier.
• À mesure que le nombre de clients augmente, vous peut augmenter et réduire votre serveurs à rencontrer performance / réactivité exigences.
• Votre code d'application et vos bases de données ne peut pas être altéré par "interrogatif" clients.

Je dois dire qu'il est presque plus important où votre application s'exécute, par opposition au nombre d'instances distinctes qu'il contient.

Bien sûr, la maintenance de plusieurs instances distinctes n’est pas idéale en raison de la charge de support / maintenance, mais bien de ces applications. sont tous sur des serveurs que vous contrôlez, la vie est bien plus facile que de requérir un accès distant / physique à différents réseaux et serveurs de clients.

Joel Spolsky en parle également exactement à podcast StackOverflow 67 .

  

Une chose que Joel a apprise de   vendre Fogbugz: logiciel conçu pour   être installé sur un serveur interne à un   le site du client, sous le contrôle total de   ce client, ne vaut presque jamais   le tracas

20 millions d’enregistrements n’est pas une énorme base de données SQL Server. Un seul serveur SQL bien approvisionné pourrait gérer cette taille confortablement. Mais le plus important est le nombre d’accès simultanés à la base de données. Cependant, vous dites qu’il n’y aura que quelques utilisateurs par client et qu’il est donc peu probable que vous vous trouviez touché tant que le niveau de simultanéité n’augmente pas.

Answer 5

Tous les points ci-dessus sont de bons points, mais il vous manque deux questions clés. À quel prix le service est-il offert et combien de clients (ordre de grandeur) devrez-vous prendre en charge au final (taille du marché)? Dans 3 ans, aurez-vous un maximum de 10 clients dont chacun vous paiera 500 000 dollars par an ou 500 clients vous payant chacun 10 000 dollars par an? Pour un petit groupe de clients premium bien rémunérés, les avantages des déploiements individuels sont clairs, tandis que les prix plus bas et les bases de clients plus grandes exigent une solution partagée (le commentaire à la Oli) est la meilleure solution. Ou optez pour une plate-forme en nuage, même si je n’ai lu que le battage publicitaire et bricolé plutôt que de le déployer sur le terrain.

Bonus Question 1: mise en forme des tables, indexation, nombre de lectures / écritures, efficacité et complexité des procédures stockées (vous utilisez des procs ou du moins des instructions préparées, n'est-ce pas?) tout compte beaucoup plus que le nombre de enregistrements physiques dans la base de données à un point. Au-delà de cela, vous devrez probablement fournir des instances individuelles de SQL Server pour chaque client ou pour un pool de clients, encore une fois, en fonction de certaines des questions que j'ai soulevées ci-dessus.

Bonus Question 2: Dans cette situation, il est essentiel de prévoir du temps et une architecture de plug-in dans votre conception. Vous devez le faire le plus tôt possible. Une fois que vous êtes sur le point de personnaliser le code pour payer les clients, vous n'aurez probablement pas le temps de le faire correctement. Ce point ne saurait être assez souligné. Les modèles et les outils d'administration qui vous donnent un accès rapide et complet aux modifications de votre produit basées sur les données vous feront gagner beaucoup de temps. Au fur et à mesure que votre société / groupe s'agrandit, vous pouvez ajouter moins de personnel technique pouvant être des "experts produits". qui peut effectuer 90% des personnalisations et de la maintenance, libérant ainsi votre noyau pour continuer le développement ou passer à d'autres projets. Enfin, ne négligez pas votre niveau de données dans ce processus de planification. Il est très important de disposer d’un noyau de données composé de processus et de tables stockés (presque) immuables, les tables personnalisées et les processus stockés étant clairement délimités à l’aide d’une bonne convention de dénomination.

Bonne chance, n'hésitez pas à fournir plus de détails si vous souhaitez des suggestions plus spécifiques.

Answer 6

Sur la base des conseils reçus, nous avons finalement implémenté une version monolithique à locataires multiples de notre application.

Je suis content que nous l'ayons fait. À la fin, nous avions 3 ou 4 fourchettes de code (principalement des skins personnalisés et des choses pour lesquelles nous n'avions pas de support de niveau n, mais aussi quelques fonctionnalités réelles), et cela devenait de plus en plus fou.

Nous avons mis en place la version multi-locataires et tout plié. Il y avait beaucoup de choses à penser et à suivre, mais nos clients ne savaient même pas qu'ils avaient été transférés dans un nouveau système.

Je dirai que la migration réelle du client était un peu pénible. Au début, je pensais que nous serions capables de le faire à la main dans le backend, mais j'ai fini par devoir écrire des scripts assez compliqués pour faire le travail. Il y avait tout simplement trop de colonnes d'identité, et ce n'est pas comme si vous pouviez simplement désactiver temporairement les contraintes lorsque vous importez dans un système de production réel.