Hébergement qui peut supporter 250.000 connexions en simultanées

pas sur du mutualisé Ovh

Bonjour,

J'ai pour projet de développer un produit qui va mettre en ligne des sites internet.
Niveau infra comment puis-je héberger, déployer 500 sites qui ne sont pas interconnectés entre eux et qui reçoivent une charge moyenne de 500 connexions par site en simultanées ?

Pour faire plus court, j'ai 500 sites (voir plus) à déployer et héberger qui reçoivent chacun 500 connexions en simultanées soit 250.000 connexions sur la journée.

Comment puis-je réaliser ça à moindre coût ?

Merci !

C'est un projet entier, qui me semble ne pas pouvoir être débattu dans un forum de ce type.

Il y a bien deux ou trois intervenants dont l'avis pourrait valoir la peine ? @janus57 @Sich @Jalinn ?

Hum, 500 sites avec 500 connexions simultanées ou sur la journée ?
Non parce que 500x500 en même temps c'est juste énorme...

Si c'est "en même temps" (ça fera plaisir à Manu) je partirai sur du cluster (cluster galera / mysql pour le sgbd), storage centralisé pour les parties dynamiques (fichers temporaires, image ?, ...) et storage local pour les fichiers qui ne bougent pas, plusieurs serveurs frontaux, un serveur de cache centralisé redis, des serveurs slave (pardon faut plus utiliser ce mot) sur chaque frontaux web... Un loadbalancer devant tout ça...

C'est une infra à une dizaine de serveurs mini...
Ou alors un truc via kubernetes et du scaling auto et tout ça...
Mais j'ai jamais fait (oui je suis à la bourre sur ma veille techno)...


Maintenant si on parle de 500 sites en tout, qui ont d'excellents cache (jamais 2x la même requête sur le SGBD, pages préconstruites en cache en full html), voir qui peuvent être mit derrière CloudFlare en "cache everything", qui n'ont aucun accès privé (tous les visiteurs ont accès au même site, en excluant le back office où peu de personnes se connectent) et qui ont 500 visites JOUR / site là c'est déjà bcp + simple...
Un ADV 5 avec 256Mo de RAM et des disques NVMe "pourrait" éventuellement gérer ça... Mais sans + d'infos (niveau de cache, connexions simultanées, espace privé, etc) c'est difficile de répondre...

J'ai des clients qui tournent sur des rise1 avec 200/300 sites... Bon le serveur pleure, mais ça tient...

Bonjour,

Il me semble qu'il y a une grosse confusion entre le nombre de pages vues sur une journée, le nombre de connexions simultanées et le nombre d'utilisateurs simultanés. Il faudra surement revoir les chiffres.
Pour continuer dans l'analyse du besoin, cet objectif est censé être atteint sous quel délai ?

Si tu débutes dans l'administration système (ce que je suppose) et que le système est tout neuf, je partirais avec un nombre de serveurs limités en prévoyant les moyens de grossir par la suite :

* Séparer chaque fonctionnalité (Web, BDD, indexation, cache, statiques...)
* Prévoir toutes les interconnexions à l'avance (socket, proxy applicatif (qui a dit MySQL Proxy ?), MQ, TCP/IP...)
* Regarder les fonctionnalités de chaque composant pour pouvoir le faire grossir (Clustering, Sharding...)

Si les sites sont identiques en termes de construction, tu pourrais t'appuyer sur du Terraform / Ansible pour pour faire du IAAS sur une plateforme Cloud de ton choix. Parce que dans l'hypothèse où il y aurait vraiment 500 connexions simultanées par site, il faura les séparer les uns des autres.

ProxySQL (https://proxysql.com/) est vraiment top, mais ça demande de bien savoir ce que l'on fait et de bien maitriser son code / son appli / ses besoins...

Mais une fois en place, ça fait des merveilles...

Salut @KevinM26

En plus de ce qui a déjà été dis, je pense effectivement que kubernetes, terraform, ansible et consort pourrais faire ton affaires.

C'est un projet entier, qui me semble ne pas pouvoir être débattu dans un forum de ce type.

Ton projet est assez vaste et "vague" au final...
Là comme ça, j'ai déjà plusieurs interrogations :
- Comment toi déjà tu vois les choses ?
- A quel point tu veux gérer (ou pas) les choses ?
- tu entends quoi par budget "limité" ? (on parle de centaines d'€ ou de milliers d'€ par mois ?)
- Il te faut des IP unitaires pour chaque sites ou tu fais du mutualisé ?
- ce sont des sites "vitrine" ou plus lourd (avec bdd, css, java, ect...).
- tu veux une indépendance complète sur ton infra ou tu veux du +/- managé ?

Selon ces différents critère, les réponses pourrons changer completement !
Pour les budget les plus "gros", tu pourras opter pour du Private Cloud directement.
Pour un budget plus limité mais avec un besoin de ressources garantie et une infra 100% maitrisé, le dédié fais très bien le taf.
Pour un budget plus maîtrisable et scalable a volonté (ou presque), le Public Cloud seras ton amis.

Après, reste la partie purement technique de ton côté.
Soit tu maîtrise et dans ce cas là, part sur plusieurs petit dédiés gérés via kubernetes (ressources garanties, maîtrise totale de ton environnement; ect...), soit tu part sur du Public Cloud avec l'offre managé Kubernetes d'OVH.

Perso, je suis assez friand du Public Cloud dans ce type de scénario :
- ressources ajustables et jetables
- souplesse dans la gestion de ton parc et de tes coûts...
- avantage/inconvénient : c'est managé... tu ne gére pas la partie API K8S, mais tu est dépendant du support en cas de bug.
Aprés, tu peux t'en affranchir en gérant en double ou en assurant un vrai PCA/PRA qui tiens la route via des backup, snapshot et autres solutions (la aussi, technique, budget toussa toussa).

A mon sens, dans le cas présent, le gros avantage du Public Cloud seras sa capacité a absorber la charge et a grossir selon tes besoins.
Une instance est défaillante ? tu la delete et tu en recréé une autre. Besoin de plus d'espace ? resize de l'instance, du volume add ect...
L'inconvénient que tu pourras avoir sera le fait de devoir bien monitorer tes instances (un peu plus que sur du dédié a mon avis).

Tout va dépendre de comment tu vas (veux) gérer ça au final : en mode "jetable" ou en mode hyper scalable et totalement "jetable".

Après, selon ce que tu choisis de faire et comment tu le gère, une infra hybride est également réalisable :
- tu public cloud pour la partie storage, site, compute de base ex...
- du dédié avec du nvme + vRack si grosse bdd a gérer (ou autre selon...)

Bref, l'avantage ici est que tu n'est pas forcement obligé d'être sur une et une seule offre. Rien ne t’empêche de mixer !
Le dédié pour la partie ressources 100% dédié (mais avec l'inconvénients de la gestion harware + prix selon les serveurs) et le public Cloud pour la partie compute, souplesse, charge ect...

A tout ça, tu peux rajouter au besoin du CloudFlare, un ou plusieurs Loadbalancer (kubernetes le gère très bien tout seul ça aussi) ect...

Bref, les solutions sont multiples et varié.
Tous ce qui a été dit plus haut est complémentaire et pertinent...
A toi de voir où tu veux aller et comment :)

Jalinn

Bonjour,

En effet il existe une multitude de solution pour répondre à ce genre de problème.

Pour des sites bien optimisés avec peu d'espace chacun, (moins de 500GO de le tout), tu peux partir sur une infra simple avec en fonction du budget l'ajout de redondance sur multiple serveurs.
J'héberge des sites à plusieurs millions de vues par jour avec du lxc se qui permet d'avoir un cout raisonnable tout en supportant un trafic important.
Dans le cas ou les sites sont un peu plus gourmand et en ayant un besoin de haute disponibilité, il faut préconiser un cluster pour répartir la charge avec des ressources sur plusieurs machines.

A 1ere vue, je partirai sur 3 machines pour former un cluster proxmox type infra 2 ou 4 sur lesquels tu déploies un cluster mariadb sur 3 conteneurs lxc.
Ensuite sur chacun des hotes tu vas pouvoir déployer différents front web qui devrait largement supporter la charge indiquée.
Cette solution reste économique avec une facilité de gestion si on a quelques connaissances.

La solution du moment et qui est aussi la plus poussée serait d'utiliser kubernetes qui permettrait de ne consommer que les ressources nécessaires au bon fonctionnement des sites.
Si demain tu passes à 1000 sites, il sera assez simple de grossir avec la plateforme car on s'affranchit quasiment du matériel.
Le soucis ici c'est le coût d’ingénierie pour prendre en main la solution et conteneuriser propre tous les éléments du projet.
Cependant une fois en place, l'automatisation de la gestion des ressources est très intéressante pour une administration quotidienne.

N'hésite pas à demander, tout est possible en l'état.
- Soit pas trop cher avec une gestion des ressources manuelles
- Soit plus cher au début et ensuite des mises à disposition simple et la facilité d'expansion.

Et si le budget vient avec le temps, alors il faudra basculer de l'un à l'autre.

Bon courage
https://www.captainadmin.com

J'ai l'impression que le monsieur a disparu...

l'est parti acheter de l'aspirine

Bonjour à tous et merci pour vos réponses !

Effectivement l'aspirine est nécessaire haha

Il y a eu beaucoup de réponse, on en train d'étudier les différentes propositions pour trouver celle qui nous correspondrait le mieux.
Et je parle bien de 500 site déployés, qui doivent tourner h24 sans coupure. Sur les heures de pointes (18-00h) on peut avoir, en moyenne, 500 visiteurs uniques par site. Ca peut être plus comme ça peut être moins.
D'ici 2 ans on vise une montée en charge jusqu'à 2000 sites web déployés.

Pour en dire un peu plus sur le projet, même si vous comprendrez que ça reste assez secret, une personne X va venir sur notre plateforme pour déployer son site internet (vitrine uniquement pour le moment) en choisissant son thème et son nom de domaine.
Notre plateforme met tout en place automatiquement et l'utilisateur a juste à taper son url et tomber sur son site. Aucun gestion back-office sur les sites, juste sur la plateforme global (modification de thème, couleur, logo, etc). On déploie uniquement des front et des API en GraphQL.
Le seul hic de ce projet c'est que demain un site peut très bien commencer à 500 visiteurs uniques puis le lendemain avoir 2000 visiteurs uniques, puis à nouveau 500, etc

Pour le budget, on y mettra le prix qu'il faut tant que la rentabilité reste présente.

Encore merci pour vos réponses, ça nous aide beaucoup !

Si la partie publique visiteur est "statique" perso je me collerai derrière cloudflare, même avec l'offre gratuite, et je mettrai ça en cache everything et un edge cache à 1 mois...
Par contre faut avoir le contrôle du nom de domaine, et prévoir une purge du cache (via l'API) en cas de modif dans le back office.

Avec ça je suis monté à plus de 30k visiteurs actifs en simultané et 350k visiteurs dans la soirée... Le tout derrière 2 RISE1 (1 pour le front, l'autre pour le SGBD).