Architecture système

https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/5670251-decouvrez-le-metier-darchitecte-systeme

Inititation

Principe généraliste

Un architecte, c’est avant tout le dépositaire d’une méthode et d’une vision.

• La méthode permet d’analyser un système selon tous ses axes et surtout de poser les bonnes questions.
• La vision est le fruit d’une réflexion en commun entre les experts des différents composants et l’architecte. Elle constitue la façon optimale d’organiser les composants entre eux afin d’en obtenir la meilleure efficacité globale : c’est l’architecture cible.

On part toujours d'un besoin, on pose des questions et on mène une étude.

Caractéristiques d'une bonne architecture

Elle répond à plusieurs caractéristiques:

• La sécurité : Elle s'appuie sur la disponibilité, l'intégrité, la confidentialité, la traçabilité (DICT) ; ainsi qu'une perte de données maximale admissible.
• L'élasticité (scalabilité) : le système doit pouvoir répondre à des contraintes changeantes. On parle d'élasticité verticale quand on rajoute des ressources (RAM, CPU, etc) et horizontale quand on rajoute des nouveaux éléments (serveurs web, etc).
• Le couplage faible : le couplage est la nature de l'adhérence qu'ont deux systèmes entre eux. Une architecture moderne et bien pensée a une adhérence faible avec ses interfaces externes et internes. L'idée est que si deux services ont un couplage faible : un changement de l'un n'entraînera pas tellement de changements sur l'autre. C'est l'un des buts de l'approche micro-services, par ex. Autre exemple : mettre le nom du PDG devant sa place de parking est un couplage fort, mettre sa fonction (PDG) est un couplage faible qui permet de changer le PDG sans changer la plaque...
• La simplicité : un système simple est compréhensible, et donc plus stable dans la durée.

Représentation de l'architecture

[On nous explique qu'il faut faire des schémas d'architecture, waouh] Que représenter ? Un Si vu sous l'angle de l'architecture technique peut se décomposer en 4 plans :

• Fonctionnel : représente l'aspect métier, que fait l'application et la nature des données qu'elle échange avec le reste du monde
• Le plan applicatif : les flux (protocole, fréquence, sens), les stocks (partage de donnée...), les middlewares (base de données, serveur java…) et les frameworks utilisés (.NET, Java...)
• Le plan infrastructure permet de décrire les choix techniques (serveurs choisis, connexions réseau, etc)
• La couche opérationnelle décrit la gestion du système : mécanismes de sauvegarde, de supervision, de métrologie, etc

Description des 4 couches

Couche fonctionnelle

Quel que soit le projet, la méthode devrait toujours être appliquée.

Donc, la couche fonctionnelle ? Elle traite de tout ce que fait l'application : les données manipulées, et comment elle s'inscrit dans son écosystème applicatif. On part toujours d'un besoin et on mène une étude : le questionnement des besoins est essentiel. Il faut aussi voir les ambitions du système dans le temps (combien d'utilisateurs au final ?) et dans l'organisation (on peut commencer par ne gérer que la paye, et finir avec un soft pour toute la RH). Il faut éviter de se jeter sur la résolution de problème sans faire d'étude fonctionnelle : plus on évite l’analyse fonctionnelle, plus le système défini risque d’être inadapté au besoins réels des utilisateurs. Il faut réussir à prendre du recul pour voir le tableau global. L'analyse fonctionnelle étudie quatre aspects :

• Les utilisateurs
• Les données
• Les traitements
• Les interfaces applicatives

Identifier les utilisateurs

On commence par identifier simplement les utilisateurs. As-t'on une gestion des habilitations ? Est-ce que des partenaires vont intervenir ? Aura-t'on des clients depuis le net ? Dans quels fuseaux horaires ? La volumétrie est très importante à évaluer aussi. Combien au total, en même temps ? Y'a-t'il des populations clefs à prendre en compte ? Des gens en lecture seule ? En gros, on s'intéresse à l'usage.

Analyser les données

Il s'agit d'analyser les données qui seront traitées par le système. Une fois les utilisateurs bien identifiés, on peut commencer à s'intéresser aux données qui sont manipulées : D’où viennent-elles ? Quelle est leur sensibilité (confidentialité) ? Sur quels référentiels s’appuient-elles ? Quel est leur cycle de vie : qui les produit, qui les transforme, qui les consomme ? Quel est leur format ? Quel est leur niveau de qualité ? Ces informations sont importantes en terme de sécurité, mais aussi en terme de référentiel de données.

Si on considère une application traitant l’inventaire magasin de boîtes de petits pois (leur nombre, leur prix, leur emplacement en rayon) qui doit s’interfacer avec l’application gérant l'entrepôt, on doit particulièrement s’assurer que la notion de « boîte de petit pois » est la même partout. Plus d’une fois, on se rendra compte que côté entrepôt, on gère seulement des palettes de boîtes et qu’un traitement est nécessaire pour passer d’un système à un autre.

Les traitements

On sait qui utilise le système et quelles sont les données, alors maintenant, on en fait quoi ? Ici, il est question de lister les grands blocs fonctionnels par type d’usage : gestion d’inventaire, authentification des utilisateurs, production de rapports... Idéalement, c’est ici qu’on va associer des notions de performances : telle fonction doit répondre en moins de 3 secondes, tel rapport doit être produit chaque nuit, etc. Dans la plupart des projets, personne n’est capable de fournir ces indications de manière explicite et immédiate. C’est souvent une fois le projet déployé qu’il faut revenir à cette étape et détailler, en s’appuyant sur les premiers retours utilisateurs. En première instance, un simple gros bloc peut tout à fait faire l’affaire, permettant de représenter la cible ou la destination des échanges avec les autres applications.

Identifier les interfaces

Qui produit la donnée, qui sont les consommateurs ? Les échanges entre les systèmes doivent être caractérisés par 2 éléments :

• La donnée portée
• Le sens de transfert

On ne se demande pas qui initie quoi (ça c'est la couche logique), mais quelles sont applications source et cible. Comprendre les flux permet de s'interroger sur le fonctionnement global. Cela permet aussi d'identifier les problématiques structurelles (connexions, volumétries...) et d'anticiper des problèmes techniques.

Couche applicative (ou logique, ou composant)

L'objectif fonctionnel étant identifié, on peut regarder comment applicativement, le système va répondre aux besoins. Ici, on va plutôt adresser nos questions aux développeurs et aux experts des différents middleware. Il s'agit de décrire principalement :

• Les flux : protocole, fq, sens
• Les gisements de données : types, volumes
• Les middlewares : bdd, java, composant d'authent
• Les frameworks de developpement utilisés

Attention, lors des choix, à prendre en compte l'exploit :)

• Qui va être en charge du composant ?
• Les équipes cibles peuvent-elles assurer les plages horaires de service ?
• Comment avoir de l'expertise en cas de besoin ?

Le principe au niveau de la couche applicative est d'instancier les éléments de l'analyse fonctionnelle:

• À quels flux techniques correspond un flux métier ?
• Dans quelle base sera stockée la donnée ?
• Dans quel serveur d'application porte le traitement identifié ?

On peut aussi faire apparaître des briques de sécurité pour répondre aux contraintes DICT, comme un WAF par exemple, et les zones réseau.

Identifier les flux

Les flux sont une des composantes les plus importantes en architecture sys, notamment avec l'émergence du cloud. En s'appuyant sur l'analyse autour des interfaces on peut ici zoomer sur les apects techniques:

• Le protocole réseau (UDP, TCP, et protocole applicatif comme SMB, HTTP, etc)
• Sens de l'initialisation du flux (pour les fw)
• Volumétrie transmise, globale et unitaire
• Fréquence d'envoi
• Temps imposé entre la réception du flux et la restitution du résultat
• Zones réseau traversées.

Il est important d'identifier les zones de sécurité traversées (DMZ, BCK, etc) : tous les flux ne seront pas possible en fonction de la politique de sécurité. Les identifier est surtout une question de connaissances personnelles et d'expérience. L'expérience permet de porter un regard sur les contraintes et de les identifier. Certains protocoles peuvent par exemple répondre à certaines contraintes de confidentialité avec du chiffrement. Cela peut sembler évident, mais l'agilité amène une tendance à se précipiter. Il faut systématiquement mettre en avant les besoins pour s'assurer que l'on y répond systématiquement : la méthode, c'est tout le temps !

En ce qui concerne les flux, il faut aussi penser à évaluer leur performances et leur capacité ; en évaluant bien les contraintes de volume et de fq, on peut estimer le débit et la latence nécessaires.

Gisements de données

Ici aussi, on s'appuie sur l'analyse fonctionnelle.

• Quelles sont les données à garder—Faut-il en filtrer une partie ?
• Dans quel format ?—Fichier ? Base de données SQL ? NoSQL ?
• Pendant combien de temps ?—et quelle sera la politique de purge ?
• Qui devra y accéder et comment ?

Si la plupart des besoins de 80% des applications sont assez standards, et couverts par des solutions répandues, ces questions peuvent être intéressantes dans certains cas. Et puis, on applique tout le temps la méthode, pour bien se rendre compte des limites et des points d'améliorations, voir pour changer d'approche : partager inutilement des données augmente les risques, par exemple. Dans le cas d’une source de données de type non structurée (fichier ou objet), qui ne nécessite pas de Middleware particulier, on pourra simplement le faire apparaître directement avec son type de protocole de partage (SMB, NFS, CIFS, S3, …).

Middlewares

La couche applicative est l’endroit où mettre en avant tous les logiciels permettant d’instancier concrètement ses flux, ses données et ses traitements. Concrètement:

• Logiciels d'échange comme RabbitMQ, sftpd, etc
• BDD
• Serveurs d'application (Web, Tomcat, etc)
• Services de sécurité réseau (WAF, FW, LB, proxy, reverse, VPN)
• Services d'authent ou de SSO

L'idée est d'être exhaustive sur les briques utilisées. La version d'un middleware est un élément à capturer impérativement. Souvent, les développements et surtout les progiciels sont dépendants de telle ou telle version, ce qui rend les évolutions potentiellement complexes. En identifiant dès le départ ces dépendances, on permet de mettre en avant la dette technique (c’est le coût qu’on est sûr de devoir financer dès lors qu’on a implémenté un composant, ne serait-ce que pour le retirer). Les évolutions de middlewares sont l'occasion de revenir sur l'analyse réalisée. On peut aussi mettre en avant certains mécanismes offerts par des middlewares, comme de la réplication de données, partage de session, clustering, chiffrement, etc.

Couche infrastructure

Globalement, la couche infrastructure traite de l’ensemble des mécanismes sous-jacents qui proposent des ressources et garantissent la performance, la disponibilité et la protection des données. On parle ici de serveurs, de réseau, de stockage, de virtualisation, de sauvegarde, d’archivage, de cloud bien sûr.

On distingue les infras mutualisées des infras dédiées. On va surtout se concentrer sur les infras mutualisées, les plus courantes. C’est la responsabilité de l’architecte d’avoir la curiosité de comprendre comment les infrastructures fonctionnent, et quelles sont les contraintes associées à chaque usage. La compréhension fine d’un service comme AWS S3 ou les Azure VM est indispensable à leur utilisation pertinente et raisonnée.

Ici chaque choix de composant devra se faire en prenant en compte l'exploit, ici aussi. Soyez gentils avec l'exploit :) Choisir de beaux trucs que personne ne maîtrise est toujours la recette d'un désastre à long terme.

Le calcul

Niveau le plus proche de l'applicatif, la partie calcul (serveur, conteneur, VM, etc) est décrite par trois éléments:

• Le dimensionnement : Niveau de perfs requis ? Nb de cpu ? Fréquence en GHz ? Taille mémoire ?
• L'emplacement : Quel datacenter ? Quel fournisseur cloud ?
• Identifiant : permet de faire le lien avec la couche applicative.

On peut aussi mettre en avant des éléments de clustering pour toujours se demander de quelle façon cela répond aux contraintes de service. Dans le cas de l'auto-scaling, on précisera les bornes d'elasticité et les critères de montée en charge.

Le réseau

• Comment les composants sont connectés ?
• Comment ils communiquent ?
• Quel débit ?
• Type de lien ?
• Redondance ?

Stockage

• Méthodes d'accès ? (SAN, NAS, Fibre Channel, Direct Attachment, Local... ?)
• Forme de stockage (bloc, fichier, objet ?)
• Type de disques, matériel ?
• Perfs ?
• Localisation du stockage (géographiquement) ? Important pour un PRA par ex.

On va aussi pouvoir détailler des fonctionnalités particulières : virtualisation, cluster actif/actif, chiffrement (c’est par exemple une fonctionnalité des Azure Storage Account), réplication synchrone et asynchrone, stockage Objet, etc. La couche infrastructure est aussi l’occasion d’analyser et de détailler les différentes machines physiques ou virtuelles dédiées à des usages spécifiques (appliances), comme par exemple un système d’archivage (support physique à écriture unique (WORM)) ou des fermes de calcul utilisant des GPU dédiés.

Couche Opérationnelle

Souvent le parent pauvre de l'architecture et de l'analyse, la partie opérations est essentielle. On doit pouvoir savoir comment le système va être supervisé, mesuré, sauvegardé, ordonnancé car cela influera sur sa résilience et son agilité.

Supervision

On va identifier des points de supervision, soit des éléments à surveiller sur lesquels on déclenche des alertes (des sondes, quoi). On suit la dispo et les perfs du services, je connais bien ça...

La finalité de la supervision est double : résoudre le plus rapidement les incidents, en ayant déjà identifié ses causes potentielles et si possible, les éviter. Côté architecture, on va donc s’assurer que les principaux aspects infrastructure (perte de réseau par exemple), applicatif (réponse d’un service web) et même fonctionnel (présence d’utilisateurs) sont couverts.

On va aussi décrire à quels systèmes de supervision ont est raccordés : les alertes ne seront pas traitées pareil selon qu'elles sont techniques ou fonctionnelles. Pour chaque point de supervision, on définit les seuils auxquels les alarmes doivent se déclencher, les actions à entreprendre et qui devra les faire.

Métrologie

Service complémentaire à la supervision, la métrologie permet de suivre et d’analyser un système à travers la collecte et l’exploitation des métriques.

L'architecte doit aider à identifier quelles sont les caractéristiques de ces métriques. Leur nature, la fq de collecte, la durée de rétention. Le mieux est de partir de quelques métriques que l'on est sûre d'utiliser et d'étendre au besoin. La métrologie sert aussi à mesurer des SLAs, par ex. en collectant des durées d'indispo.

Backup

La backup a pour but de garantir une PDMA. C’est à l’architecte de s’assurer comment la sauvegarde sera réalisée (LAN-Free, agent, à chaud, à froid, mécanisme middleware type archivage de logs…) et surtout si elle permet de respecter la politique de sauvegarde associée, et surtout de garantir les délais de restauration ! Cette politique de sauvegarde décrit la fréquence et la rétention des sauvegardes réalisées. Plus la fréquence est élevée, plus la rétention est courte en général.

Il ne faut pas penser que la réplication de données a valeur de sauvegarde. Une corruption de données ou un drop de base, par exemple, et notre réplication ne sert plus à rien !

La sauvegarde n’est pas importante, seule la capacité à restaurer l’est. Derrière cette tautologie se cache un aspect fondamental : seuls des tests de restauration réguliers peuvent réellement garantir que vos données sont bel et bien protégées.

Ordonnancement

Aspect majeur des applications très complexes et entremêlées, l’ordonnancement est la gestion de l'exécution de traitements successifs, en intégrant des possibilités de reprise et d’embranchement selon les résultats de chacun des traitements.

Il faut se poser la question de la dépendance du système à un mécanisme d'ordonnancement. Cela peut-être aussi simple qu'une crontab, ou aussi complexe qu'une application dédiée. Ce lien peut impacter la capacité à tenir des engagements, même si les chaînes d'ordonnancement peuvent parfois s'exécuter de façon autonome ou en mode dégradé. La compréhension des interdépendances fait partie du travail de l’architecte, tout comme le fait de s’assurer que les cas « classiques » bloquants sont pris en compte. Par exemple, valider avec le métier s’il est possible ou non d’ouvrir le service le matin si les sauvegardes nocturnes ne se sont pas exécutées correctement : ici, on prend une décisioni technique à partir de la compréhension des enjeux métier.

Déploiement, patches, et autres évolutions

L'analyse opérationnelle est aussi le moment de voir les contraintes posées par l'exploit : mécanismes de déploiement CI/CD, gestion des majs, rechargement des bases de données, gestion des logs, du NTP... L'idée est de creuser un peu pour se demander quels services opérationnels auront un impact sur notre système.

POUR CONTINUER

https://openclassrooms.com/fr/courses/1372996-concevez-larchitecture-dun-systeme/6737986-entrainez-vous-a-representer-votre-premiere-architecture