--- lang: fr tags: ARCHI WEB, MTI, ING2 title: Architecture Web 1 --- # Architecture Web 1 ==cluster==: Ensemble de machines et VM qui gère des connexion et des instances. ### Web application Deux composants: - Processing (l'app elle-meme) - Storage (Souvent une DB) Et d'autres trucs: - Caches, tech tools, monitoring, ... :::info Bien entendu il faut aussi tout monitorer, ce qui demande d'autres outils encore. ::: ## Architecture input Les questions à se poser avec de construire une archi ?? ### Metrics - Traffic attendu (en page/sec) :::danger La metric full bullshit: nombre de visiteurs uniques ::: - User en simultané: un peu con, pcq on peut être log sur le site mais faire 0 requête... Inversement si une app envoie une requête tous les jours à 20h et qu'on a 20000 users on peut avoir un problème :::info Une app simple peut gérer environ 100 (ou 1000 mille je sais plus) requête/sec ::: Des fois, cela ne sert a rien de config de l'auto scaling, autant juste prendre un peu plus de VM et avoir un truc qui fonctionne tout le temps car on va perdre du temps à le config. En fait, cela coûte moins cher de **prévoir** un pic de requête et de louer une machine pour le moment précis plutôt que config de l'auto scaling. (Generalement, 10K de requête par page c'est beaucoup) ### Scalabilité ==horizonral==: J'augmente le nombre de noeud (illimité) ==vertical==:: J'augmente la taille de chaque noeud (limité) Après scaler verticalement c'est aussi moins cher et plus simple donc on favorisera toujours le scaling vertical (jusqu'à une certaine limite) ### Disponibilité Ca se calcule en nombre de 9. Cela décrit le temps que l'app va être down. ## Architecture output Les question à se poser sont: - Comment les datas sont transférés ? GraphQl, RabbitMq, Rest - Roadmap strategy - CI / CD strategy - Backup strategy - etc... ### apache bench Sympa pour tester si notre archi peut gérer un nombre suffisant de requête ```bash= ab -n 1000 -t 100 <host> # lance 1000 requêtes avec 100 threads ``` ## Infrastructure components Firewall: Limiter des accès de l'exterieur DMZ: "Zone demilitarisé" façon corée du nord/sud. Il se situe entre le firewall interne et externe ```graphviz digraph G { node [shape=box] firewal->DMZ->firewall_interne->{paye, Ldap, api_interne} } ```