Notes d'Architecture SI PDF

Cours 1 Cloud public -> tous les cloud qu'on connait (google drive, dropbox, icloud) Cloud privé -> propre data center et on déploie un cloud dessus (entreprise cloud privé) Cloud hybride -> mélange des 2 IAAS -> infrastucture as a service -> on achete un bout de machine et c'est à nous de gérer...

Cours 1 Cloud public -> tous les cloud qu'on connait (google drive, dropbox, icloud) Cloud privé -> propre data center et on déploie un cloud dessus (entreprise cloud privé) Cloud hybride -> mélange des 2 IAAS -> infrastucture as a service -> on achete un bout de machine et c'est à nous de gérer pour savoir ce qu'on en fait -> tu gères à partir de l'OS Paas -> plateform as a service -> on a notre appli et on l'a deploie Saas -> software as a service -> on s'occupe de rien -> exemple : Netflix ou Spotify Availbility Zones -> Edge location -> infrastructure + petite, + près des utilisateurs Quand on consomme un service -> je choisis la zone dans lequel on l'a déploie. Dans plusieurs zone -> pour la fiabilité, pour la skybilité (avoir des besoins partout dans le monde ) Service doit suivre 4 -> on demande -> il doit démarrer à la demander pour ca -> 2. On Automatised - > être autmatisé/ il démarre tout seul -> 3. Permettre l'élasticité -> tuer un service et redémarrer un derrière -> 4. "Pay per use " Avant cloud -> pets Après cloud -> tuer des services et ça doit redémarrer Le service tout seul -> ca sert a rien Monolithic -> vieille appli > appli en 1 bloc> reste sur un archi de service simple > pb on livré 3 fois dans l'année > time to market dans dans lequel on désire le faire et le temps que ça arrive dans le marché Maintenant > Microservice > servire des fonctions > on fait des appels d'API 1er driver -> le cout RGPD -> qu'est ce qui a changé depuis cette loi là -> les cookies Quand il n’y a plus de place Horizontal -> on rajoute des machines à côté -> il faut quand même limiter le nombre de service -> ça peut couter très cher très rapidement Vertical -> on en prend une plus grosse Déploie une appli et on déploie une image -> PaaS Faire du cache -> c'est stocker en mémoire au lieu de refaire l'action. base de donnée opérationnel -> notre appli qui fonctionne -> envoie des données au entrepôt -> donnée analytique> prend les données des entrepôts -------------------------------------------------------------------------------------------------------- Cours 2 archi -> def des projet pour qu eles archi solution/systeme pour qu'il puisse developper en fonction du projet/ Archi au niv pour aider à def les projet concret pour aider les archi solution Dans ce cours on va voir : - diff manière de faire ( analyse, ce qu'il faut prendre en compte) - Principes Architecture - 6 piliers du CLOUD - Analyse de besoins du Projet - Cloud Adaption Framework Framework cloud -> ex IAS Principe architecture : - Simplicité - Couplage lache ( = si on met en place d'une appli on veut pas être dépendant à des appli particulier ( ex Oracle) - Elasticité - Sécurité ( plusieurs possibles : sécu physique/ sécu logique...) -> se mettre dans la tête DICT -> Dispo ( quel tps j'attend pour que l'appli soit prete) -> Inegrité ( sur que les données de mon appli soit là et non modifié ou modifiable) -> Confidentialité ( -> Tracabilité ( il faut des logs) ( Forensic = réponse incident ex il y a une atack et on a un compte rendu) PDMA = qu'est ce que j'ai le droit de perdre comme données ( va avec le temps de non réponse) Les piliers ( = manière d'adresse des projet ) = font parti d'un cadre d'archi ou Framework ici AWS parei pour Azur -> un moment c'est écrit collecte ( c'est pour voir ce qui rentre et ce qui sort)  - Execellence opérationnelle ( ici faire en sorte que cça soit tout automatisable. -> ici on fait ( slide) + Organiser Connaitre son role - qui est respon , qui rend des compte, qui doit être informé et il y en a 1 dernier (RASI) workload = c'est comme une VM exploitation -> avec quoi mon appli s'interconnecte Résumé = IAC - Sécurité ( Security by Design = si on fait un developpement de base il faut penser sécu Il faut donner aux exploiteur seulement ceux qu'ils ont besoin pas + ça sert a rien Récoult des journaux -> savoir quand ça va mal Dans nos script il y a TOUT LE TEMPS cet couche de sécu à mettre Protéger les donner -> Classez les données ( RGBD -> c'est toutes les données perso , on DOIT SAVOIr où sont ses données perso) -> Proteger les données vivantes ( c'ets ce qu'on utilise ) et mortes ( = nos archives par ex ) -> on doit souvent les mettres sur des disques. Automatisation des tâches En gros Cloud = c'est un datacenter avec des services qu'ils nous proposent PAKI -> serveur de certificats La détéction -> journalisation -> voir les pannes.... Socks -> service qui peut voir nos nos infras Résumé= Security by Design  - Fiabilité -> faire e sorte que ce soit le + robuste possible en cas de problème -> pour reprendre l'activité = PRA ( = Plan de Reprise d'activité ) -> lz temps de rétablissement -> et le PCA ( = Plan de continuité) -> garantie que le temps de panne soit le + minimal possible Scabilité horizontale -> eviter les SPOF -> si j'ai une seule ordi et 1 seule routeur et il pete alors c'est la merdasse > Ressource distribué -> on a une entrée et 2 serveur si 1 serveur pete l'autre est toujours dispo Gérer les pannes -> Sauvegarder -> si il y a une panne on à la dispo de revenir en arrière. Résume -> PRA ; PCA ; Logs Mex ( Manuel d'exploit - Efficacité des performances Service ( on s'occupe pas de l'infrastructure -> ex Office 360 on l'utilise pour les mails , ppt...) - Optimisation des coûts ROI = retour sur investissement Analysere et affecter.; > tous les services coutes tant Sensibilisation > sur 3 ans peut ê que reerver les ressources cloud c'est peut ê mieux attaque type DOS -> Tarification SPOT -> instance qu'on paye pas du tout cher mais non garantie (c'est des instances mais si AWS en a finalement besoin bah il nous saute notre instance ) -> pour les mini tests en regle général  - Developpement Durable Principe -> moins on consomme moins on a de l'impact sur la planète -> pareil pour le clouder -> moins on consomme mieux c'est Fournisseur ( AWS, Azur...) va faire en sorte d'avoir minimum d'impact Client -> nous on va faiore en sorte de moins consommer Workload -> moins consommateur possible c'est notre enjeu But du jeu -> moins consommer Faut que notre projet coute le moins cher possible -> cela veut dire que l'on utilise le moins d'instaces, d'infrastructures.... = GreenIt Gestion des exigences - > 1. Analyse des besoins > cahier des charges, gerer les bugs... 2. Analyse des flux -> le port, le protocole, qui va ou -> important pour la sécu.../ es ce que j'ai un SPOF 3. Analyse des riques -> qu'est ce que j'ai comme type de donné, ce dont j'ai besoin comme perf d'archi , la dispo, qui est respon de quoi 4. Cout -> es ce que c'est quelques choses de nouv, es ce que je met juste à jour ou ajoute des services.... 95% des cas -> infrasctructe hybride Cout caché -> je suis dans le cloud, il faut que des gens soit formé. Donc prix de formations... Définition de l'architecture > Monolithique -> archi de base -> front-end, back-end + un serveur sur lequel on se connect -> 1 seul point d'entrée, accès facile... -> on l'appelle ancienne architecture Serverless -> ex : Office 365 -> chaque fournisseur à son propre fonctionnement Microservice -> utilisation de API -> du web -> mini serveur qi fait des pages très simples et spécialiser -> faut faire attention , si on utilise pleins de microservices qui veulent discuter entre eux on a du réseaux mais il faut faire attention aux flux, niv de dépendance -> temps de réponse pas rapide/ certaine latence qu'on peut avoir Conclusion -> il faut adapter son archi -> les besoins -> -> le flux -> a quoi on est attaché -> Versatilité -> -> Perf -> ->cour -> pourquoi je met en place ce porjet-> optimsation des couts, si je le met en place ça serra + cher ? Cadre d'adoption AWS> -> quand on met en place il y a touy l'environnement qui va avec -> prduit ( = business), Orga, Processus et Techno CAPEX -> le cout que je vais avoir -> je paye un truc qu'est ce que ça va avoir un impact pdt cb de tps - > j'achete il est à moi définitivement -> ex : j'achete un appart OPEX -> je paye un abonnement -> je le paye chaque mois mais il est pas à moi -> je loue un appart Science de données -> pleins d'infos qui vient partout il faut l'annalyser. Plateforme -> les 3 premier- > qu'est ce que je dois mettre en place On doit aussi gérer qui rentre dans notre salle Opérations -> les logs... Visualisation -> ou on veut aller/ ce dont on a besoin Alignement -> si tout ce qu'on veut mettre en place c'est cohérent Lancement -> Notre pre pord-> si c'est fonctionelle... Mise à l'echelle -> voir si on c'est planté Nous sert niveau organisation si on veut changer --------------------------------------------------------------------------------------------------------- Cours 3 la scabilité = la mise à l'echelle -> besoin : super app + pleisn de nouv clients / expension de notre appli de façon géographiquement Un service ne peut pas répondre à tous nos besoins Au + on va grandir au + on a des probabilité d'incident -> comment faire face... Tjrs rester focus sur le coût -> on a tjrs en tête -> argent ou empreinte carbonne AWS -> c'est du cloud ( = la mise a disposition de services en info quand on utilisepays as you go( = on paye quand on utilise pas on paye pas)) Réseau privée -> permet une fauble latence AWS region -> c'est ce qui va def la localisation de nos données -> généralement 1 dans 1 seul pays -> permet de nous fournir des service pour des appli RGDPR compliance ou comment -> comment rattarper nos infrastucture en cas de pb ou desastre -> chaque region compose au moins de 3 zone de disponibilité (= cluster de datacentre) -> ils sont relier entre eux par un reseau -> fourir protection contre les pannes -> point de presence ( = petite infrastutue partout dans le monde qui permet de delivrer du contenu au plus proche du user)-> utilise par des appli connu de streaming video On a + en + de besoin pour des appli de faible latence -> local zone -> extension de la region ( industrie ) permettant de reduire encore la distance et la latence final Wavelenght -> zone où on va rapporter des compute et du stockage-< jeu mobile infastucure -> oustpost -> extension du cloud AWS chez le clien -> permettre au clien de faire du ultra a nous de prendre les services qu'on a besoin de notre appli Considerations -> 2-way doors decision -> (de quoi j'ai besoin dans 1 ans...) ici ça nous permet de nous tromper -> contruire, créer et on va tirer des renseignements Quel est notre niveau de controle -> parfois toute notre infrastru -> nous que a gerer ce qui donne de la valeur a notre appli et pas le reste ( ex : on a pas la mise en place du reseau ect ) POC -> besoin : IP fixe + 1 instance + le DNS amazon (= Amazon Route 53)  -> si on perd l'instance on a plus rien , on peut pas rajouter de la mémoire... -> pas la bonne idée {1 truc a faire -> separer instance et DB instance} Amazon Aurora = la database opérationnel -> propose MySQL et PostgreSQL -> on peut avoir des grosses base de données sans payer Aurora serveless -> on a même pas a choisr le type d'instance base de donnée relationnel -> une necessité forte d'avoir un schema de donnée claire en cas de perte de donnée NOSQL non relationnel -> pour un besoin bien precis -> moins régide sur la struct des besoins des données -> bien mais en cas d'expension c'est relou -> on l'utulise pour > besoin de latence faible / si on epose les 5 ou 6 T de données/ ingérer des données tres rapidement/ type de donnée non relationnelle Amazon Cognito -> serverless -> fournir un annulaire de user, il fournit une interface de config prefais/ permet d'utiliser les reseaux sociaux / permet la translation des identifiants user et identifiants AWS S3 -> service de stockage objet Load balancer -> partageur de charges ( pour scabilité horizontal)-> couche 7 au nic OSI Pour soulager une base de donnée -> enlever la lecture -> Car 70 read oour 30 write Read replica -> on peut avoir la lecture seule mais on peut rien ecrire dedans On prend la charge du web serveur et on essaye de le soulager -> contenu statique et on le met dans le S3 bucket -> permet de faire du cache local des données statique Stockage objet -> traiter l'objet binaire ( je sais pas la suite ) -> grande durabilité CloudFront -> principalement : serveur de cache, mais pas que : mettre des URL unique Quoi mettre en cache -> image, videos, CSS ,JS ( ca c'est statique) mis aussi contenu d'article... ( ca c'est dynamique) ElastiCache -> = on a rine a faire ( fullymanage) fait du caching ( serveur qu'on met devant la base de données et du coup on met les données dans le cache) avec redis -> on peut aussi du cache d'écriture Amazon DynamoDB-> moteur NOSQL -> nous permet de streamer des changement de donner et les change par rapport à cela auto Scaling -> il permet d'automatique du sizing de notre serveur -> augmenter ou baisser selon nos besoin -> marche avec Cloud watch -> se couple avec load Balancer AWs systeme manager -> manege le systeme de flot Code service -> Develop, Souce, Build, Test et Deploy ( ex modele Canari = on a 2 version, notre v1 mais on veut tester notre V2. Donc on donne accès a 10% de le tester.Si ca fonctionne bien on augmenent le % de la v2 et on diminue la % de la v1, pour qu'on est plus que la v2 soit dispo et plus la v1) Observalibility -> 1. les metrique = c'est pour tout ce qui est numéraire ( expace de stackahe, combien de % de CPU utilisé...) -> 2. les logs = apllicatif ( la requete et la réponse ) et systeme  -> 3. les traces distribué ( quand on a un sys distribué, comprendre par ou passe les requete.;) CloudWatch -> definir des niv a partir duquel on envoie des alerte ou detection d'anomalie un anomalie = pas forcement un pb, c'est un evenement qui nous a afit sortir de notre element CloudWatch Logs-> prend les logs test et en fait un graphique -> nouspermet d'avoir une visibilité de se qui se passe dans dontre infra Maintenat on separe couche web et couche business logique -> toujours un mode monolithic -> monolitics -> si on perd une instance on perd tout Utilisation des micro-service Serveerless -> on a une couche d'abstraction oû nous on voit plus le serveur, pas besoin de sans occuper, mais il y en tjrs SNs -> on créé des topic et consommer par SQS AWS lambda -> service qui nous permet de uploader notre code en s'occupant de rien. Par exemple si la fct doit tourner 1000 fois bah il tournera 1000 fois... AWS ->trace distrubué -> prend toutes les traces de notre infra et prend tout le chemin que fait ta requete, voir si quelques choses à un pb et comment cela impact le reste faire du sharling -> prendre un dataset et le spliter en plusieurs endroit A essayer Amplify Studio Qu'est ce que doit faire pour scabilité (>... -> automatisation de l'infra -> s'assurer niv d'observabilité -> utilisé auto sc quand on est pres -> ne rien inventé les services sont déjà là -------------------------------------------------------------------------------------------------------------------------------------- ----------------- Cours 4 - Les architectures conteneurisées But : ne pas forcement utiliser du Clouder Dev ops: passer du code à notre projet déployé -> Déployé sur un serveur distant 1er solution -> Virtualisarion = VM= rendre plus dynamique l'utilisation des sources -> pas utilisé mémoire CPU -> Hypervisor : Conteneurisaton -> on garde les Os -> conteneur -> plus leger( deployer pleins de conteneur sur notre machine) et plus facile à démarrer -> rendre portable -> on prend 'image et on 'a déploie ou on veut car on a une petit archive -> l'image est stable ( ici GTA tourne à l'interieur) -> pratique -> si on se fait acker on supprime le conteneur en mettant les données à l'exterieur et reprendre l'image -> Image : moment ou ça fonctionne et ca fonctionnera toujours car on l'a rendu stable Standars pour que toutes ltechno de conteneurisation marche entre elles -> OCI : permet de prendre n'importe qu'elle API pour que tout marche ensemble -> Conteneur de bas niv -> contenu direct dans Linux Image docker = toutes les infos pour créer le conteneur Des qu'on rajoute une instruction -> on rajoute une couche dans l'image Simple responsabilité -> fonction fait 1 seul chose -> ici notre image à sa propre base donnée ou son propre conteneur ou pour 1 appli Reduire surface d'attaque -> supp tout ce qui est inutile dans mon image Specifier la version qu'on utilise -> sinon on a des pb exemple jeu Nintendo marche pas sur PS5 parce que pas la meme version latest -> image non taguée pas préciser la version xenial -> ici on précise la version Aspect secu -> root : on a tous les droits et c'est p s bien -> préciser un user non root pour pouvoir seulement avoir certains droits -> Un-privileged -> accès limitée donc le + securisé docker images -> lister les images sur notre pc Image = version stable c'est un template pour dit que ton conteneur va ressembler vs conteneur = instanciation de l'imgame ou utilisation de l'image Docker compose -> deployer des petits projets -> ici on doit se co avec chaques contenur Si on veut que ça marche pour plus de joueur -> kubernetes -> grâce a une cmd il deploie les conteneurs sur toutes les machines -> scheduling : lui même répartie -> Scaling -> étendre ou réduire selon mes besoins  -> Health- checking -> savoir si l'appli tourne ou pas il le fait auto -> Service Discovery ou Organizational Primitives = comme DNS Comment marche Kubernetes : Master -> c'est lui qui m'assure d'avoir ce que je veux sur le reste avec YAML c'est comme json c'est là c'est la configuration Controller Manager -> s'assure l'état désiré et l'état actuel du cluster soit les mêmes Conteneur si on a pas garder nos données à l'exterieur on perd tout. Donc si ça s'arrete tout disparait Kubernetes -> permet de facilité le travailler permettant de deployer plus facilement des choses -> toujours 1 conteneur qui fonctionne en permanence -> le pod : unité de base permet de sauvegarder la donnée -> 1 pod = 1 conteneur -> ou est le conteneur , l'addresse IP pour acceder au conteneur et etiquette sur le conteneur -> Le service -> il a besoin d'un point d'entrée unique et il s'occupe de disperser le reste ou disperser les requetes -> Ingress -> avoir accès a internet grace a Kubernetes volume -> Besoin d'avoir un stockage externe pour pouvoir garder toutes les données.Chaque volume pointe su runne parties du stackage. Important car si on perd le conteneur on ne perd pas toutes les données -> storageClassName Config map -> permet de stocker la config des appli dans les PODS et on peut les avoir pour chaque noeud -> Secret c'est pareil mais plus securisé Namespace -> espace cloisonner -> ex coté developpement et coté deploiement sans nque ça se connecte entre eux. Ils ont juste leurs proprs ressources 1 type de Yaml par type de resources -> Helm dossier des yalm et le gère ou manager de paquet pour kubernete Dockerfile -> là où est mon image Test Dynamique -> permet de tester notre appli jusqu'ou ca av crasher QCM -> diff supervision et observabilité Metricuq : une mesure a 1 instant donnée ( ex : savoir la T° de notre CPU) VS log : pleins d'info ( ex: a quel moment ca c'est passé ou log d'erreur ) Metrique systeme : reseau, stockage... metrique applicative : erreur , latence Metrique métier : L’élasticité : le rapport entre le poucentage de variation de la demande Adapter l’infrastructure pour ne pas payer trop cher (licences office) Extensibilité : capacité a s’adapter en fonction du temps et de devenir plus grand sans causer de problèmes (ne pas avoir trop d’espace pour rien) 5 piliers : 1 bonne opération = bon nombre d’utilisateur pour le bon nombre de demandes(optimiser l’architecture) - 2 sécurité - Optimiser les couts (budget) - Performance - Durabilité Optimisation = optimiser les couts, limiter les erreurs, plus rapide ITIL = Information technologie infrastructure library Elasticité, couplage lache = signifie que deux parties d'un système sont connectées de manière à être relativement indépendantes l'une de l'autre, simplicité, DICT 6 contraintes : - 1 – fiabilité - Efficacité des performances : comprendre le cloud, ne pas être retissant sur nv tech, faire des compromis, ressources - Optimiser les couts - Excellence opé - Sécurité 3 type d’archi : monilitique = tous les composants sont reliés en eux (petite maison Avantages = appels + rapide, debugger, mémoire partagé, , inconvénients = tout peut crash, language limité, elasticité limité serveurless appele a un servive tiers (loue un loyer) Avantages = code simple, deploiement simple, performance constante , inconvénients = pb avec les fournisseurs, latence, utiliser ressources parcimonie Micro-service (villa besoin de sécuriser toute les pièces) Avantages = code simple, langage variable , inconvénients = debbug, latence, surface d’attaque plus grand RACI : responsable accontable cunsulted, informated / support Cloud = service virtuel : service IT, sur demande, 1) Sécurité des fournisseurs 2) Gérer les permissions 3) Utiliser toute les coches reseau 4) Gérer les config 5) Automatiser 6) Surveillance 7) Chercher des conseils