Etape intermédiaire
7 mai 2009 - 20 commentaires
Suite à cette bonne discussion je vais la jouer plus simple pour la V1, de toutes façons ça ne bloquera pas l’évolution du service pour autant.
Donc, exit Scalr (dommage mes tests passaient très bien) et SimpleDB, on va la jouer simple à base de LAMP / Debian 
Je garde l’API sur une machine dédiée et les deux sites seront surement sur 1 ou 2 tout petits dédiés pour commencer: comme de toutes façons les data seront sur l’API les upgrades ne poseront pas de problème.
Comments closed
Discussion:
Bon tout ça me semble déjà plus raisonnable.
C’est vrai que la solution 3 tiers que tu avais imaginé intégralement en Cloud était aussi sympa qu’ambitieuse.
Aujourd’hui pour avoir fait qques essais en cloud, je constate que c’est finalement assez déroutant à administrer, donc je ne peux que te conseiller d’y aller progressivement.
Typiquement, puisque tu sembles avoir des besoins en termes de perf, je trouve que les infra cloud ne sont pas toujours limpides à ce niveau. Elle nécessite de prendre en compte la scalabilité de manière importante dans l’archi.
Atchoum
(And I mean it)
Comme tu la dit rien ne t’empêchera d’évoluer (sans difficulté) selon le besoin (mais je pense pas que tu va saturer) pour une version 1 c’est plus que GOOD. Vivement le lancement
Je dois avouer que c’est moins excitant comme ça, mais ça me parait beaucoup plus sage et moins onéreux
Bonne continuation !
Oui ca semble bcp plus raisonnable comme ca. Par contre, qui de la latence pour une version US sur un serveur heberge en France? Tu ne ferais pas mieux de prendre un slicehost pour la version us?
En effet à voir où placer le serveur avec l’API…
Mais bon un petit temps de latence constant ce n’est pas un drame: il suffit de placer le front avec un cache dans le pays pour que cela ne pénalise que rarement les lecteurs.
Héhé ravi de voir que tu deviens raisonnable
Mais je vais continuer à faire mon chieur :
Maintenant que tu te sépares des webservices Amazon, tu peux aussi te séparer de S3. Tu vas payer super cher en bande passante alors qu’avec un lighttpd sur une IP fail-over OVH de ton apache consomme rien et délivrera tout ton statique sans broncher.
Ensuite niveau performances ce n’est pas conseillé de mixer un apache avec mysql, donc perso je verrais plutôt un gros serveur mysql avec les deux apache+lighttpd en round robin DNS (oui je radote, mais c’est pour ton bien)
Voilà, je viens de me réveiller désolé si ça paraît un peu confus/incohérent
Maxime> nop ça me semble bien lisible
S3 c’est juste pour du backup (rotatif) donc pas de dépenses de fous en bande passante.
Je regarde tout ça ce we, thx.
Le round robin c’est pas ce qu’il y a de plus propre pour du loadbalancing étant donné que tu ne maitrises pas la répartition. (même si ça fait son boulot correctement, on est d’accord)
Tu pourrais imaginer un serveur avec mysql + apache. Sur ce serveur tu te sers d’apache comme loadbalancer avec mod_proxy, et si tu enlèves tous les modules qui ne sont pas nécessaires, apache consomme peanuts.
Tu prends un second serveur avec un apache en backend qui va servir le contenu au loadbalancer. Pour l’instant, tu fais du loadbalancing avec un seul backend, mais ton architecture est prête à en accueillir d’autres en quelques minutes.
Si ton trafic augmente tu setup un second backend et tu l’intègre à ton loadbalancing et ainsi de suite.
Je reviens à la charge avec memcached, mais en l’utilisant, tu pourras te contenter d’un seul serveur mysql, j’en reste persuadé.
Et si tu cherches à faire tourner ce site à l’économie, tu peux même imaginer un serveur NFS sur lequel tes backends viendront récupérer les fichiers web. Tu peux alors utiliser des RPS pour tes backends, et là niveau cout, c’est ridicule…
Je sais ce que tu penses de la stabilité des RPS, mais si tu en as un qui tombe, le loadbalancer l’éliminera s’il ne réponds plus et l’intègrera à nouveau quand il sera up. (un avantage par rapport à du round robin)
Une telle architecture n’est pas pensée haute dispo, mais en tout cas tu pourras vraiment suivre ta montée en charge et adapter ta config en fonction de celle-ci.
En tout cas, une fois que tu te seras décidé, je serais (et je ne pense pas être le seul
) curieux de savoir pour quoi tu as opté !
Pour faire du load balancing à ce moment-là tu compiles avec le module LVS et tu utilises ldirectord, pas besoin de rajouter la lenteur d’apache là-dessus
mais bon tant que t’as que 2 serveurs identiques le round robin DNS ça suffira et ça t’évite le single point of failure que représente un load balancer unique, d’où mon conseil initial.
@Maxime > C’est amusant de voir que ceux qui ont gouté à lighttpd associent toujours apache et lenteur :p
Les TTL du DNS de videmerde.fr sont extrêmement bas, j’imagine que c’est pour exclure rapidement du round robin un serveur down ?
Encore une fois, le round robin est une solution qui fonctionne je ne dis pas le contraire, ce qui me gêne dans cette solution c’est le coté « loterie » de la répartition de la charge.
Mais je ne peux qu’être d’accord avec ta remarque sur la dispo de service.
Je complète donc ma précédente remarque: le round robin c’est pas ce qu’il y a de plus propre, mais c’est pas si mal pour autant (avec des TTL extrêmement bas ^^)
J’utilise apache pour mon PHP il n’y a pas de soucis, mais le benchmark apache2/mod_proxy et ldirectord je pense qu’il y a pas photo en perfs
J’utilise lighttpd pour mon statique pour une question de perfs aussi, mais il est pas très fort en PHP, donc pas de sectarisme là dedans.
Concernant VDM on a deux load balancers qui répartissent sur le cluster (donc plus de SPOF) mais quand c’était plus petit il y avait effectivement un round robin DNS, le TTL est bas pour des raisons de praticité
Donc nous sommes d’accord
Câlin 
Je n’ai pas encore eu l’occasion de me pencher sur LVS, à l’occasion, si j’en ai le temps et le besoin, c’est promis !
Quand au loadbalancer apache il a un avantage par rapport à LVS: si tu connais bien apache, un loadbalancer est super simple à configurer, quelques lignes de conf seulement.
Bref, j’insiste un peu avec ma solution, mais c’est difficile pour moi de dire « ok Maxime à sans doute raison »
En tout cas, c’est pas fréquent que ceux qui ont réussis dévoilent autant d’infos, et ça c’est vraiment sympa (<– c’est pas un câlin mais c’est tout comme !
p)
Ma conf ldirectord elle prend 10 lignes, c’est super simple aussi ! Et plus rapide, et universel.
Moi je l’utilise pour le load balancing de mes apache/lighttpd/mysqld. Puisqu’on parle ici d’étape intermédiaire, autant prévoir le load balancing de tout, mouahahah
Je te l’accorde, je suis un mec sympa. Non mais je suis content de faire cette discussion et de pouvoir apporter mon humble expérience.
Hop hop, j’arrive après la bataille mais plutôt que de discuter de l’infra à utiliser, je me demande plutôt pourquoi tu ne persistes pas à faire du R&D sur ce projet annexe ?
Si tes moyens te permettent de « t’amuser » à tester des infras « surdimensionnés pour vie de môme », je n’hésiterai pas une seconde. C’est du R&D bien investi pour hellotipi à mon avis…
Maxime & Maxime> merci beaucoup pour toutes les infos, dans un premier temps je vais placer l’API sur un unique serveur (costaud), l’étape d’après (si tout va bien) je séparerais la DB, enfin j’attaquerai le load balancing: étape par étape
Raphaël> C’est clairement de la R&D, mais je vais tout de même y aller par étapes.
J’ai déjà pus tester Scalr la semaine dernière: ça fonctionne plutôt bien et c’est très simple à mettre en œuvre.
C’est pour hellotipi ou pour viedemomes ?
Thierry> Vie de môme, l’hébergement d’Hellotipi ronronne
Juste une question qui n’a aucun rapport, comment fais-tu pour payer les hébergements pour le site « Vie de môme » sans aucune pub ou service payant ? Directement de ta poche ou de celle de Hellotipi ?
Question un peu à côté, je trouve cette discussion très intéressante. Connaissez-vous des sites qui présentes de petites architectures comme celle-ci pour des services web ou de petit entreprises. Je lis highscalability entres autres, mais pas vraiment adapté à ma taille. En tout cas merci du retour d’expérience.