Unité 8.1 : Cadres de décision d'architecture
Introduction
À ce stade du cours, chaque primitive a été examinée en profondeur. Cette unité ne les réétudie pas. Il s'agit d'un artefact de référence : un ensemble de matrices de sélection auxquelles vous revenez lorsque un niveau FinCorp nécessite une décision et que vous souhaitez le critère de différenciation, la contrainte stricte qui peut disqualifier un choix purement et simplement, et l'unité qui dérive la raison, le tout en un seul endroit.
Lisez chaque matrice de la même manière. Les critères de différenciation réduisent le champ. Les contraintes d'éligibilité strictes sont absolues : une seule contrainte non respectée élimine une option, quelle que soit sa note ailleurs. La souveraineté et la portée de l'attestation sont appliquées en dernier, sur l'ensemble de la conception, car la conformité restreint les choix plutôt que de les initier. L'unité se termine sur les deux façons dont une conception technique solide échoue encore : associer des primitives qui ne se composent pas, et placer un service fonctionnellement correct en dehors de la portée d'attestation requise par la charge de travail.
1. Sélection de la classe de calcul
La décision de calcul est une division en quatre axes à travers l'isolement du noyau, le contrôle de la famille de CPU, l'attachement du stockage sur bloc, et le modèle opérationnel. La contrainte qui disqualifie le plus souvent est la permanente : un modèle de Cube est immuable après la mise en service, donc un niveau dont la forme ou les besoins de mise à l'échelle peuvent changer est conçu sur une classe qui peut être reconfigurée. Le VM Auto Scaling lui-même est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique au moment du design.
| Classe | Critère de différenciation | Contrainte d'éligibilité stricte | Dérivé dans |
|---|---|---|---|
| Noyau dédié | Noyau physique exclusif ; famille de CPU sélectionnable et modifiable | Le changement de famille de CPU nécessite un redémarrage, et non une opération en direct | Unité 4.1, 4.3 |
| vCPU partagé | Coût le plus bas | Aucune sélection de famille de CPU ; partage des noyaux physiques, donc aucune garantie d'isolement en cas de contention | Unité 4.1 |
| Cubes (instances à modèle fixe) | Modèle à vCPU/RAM/NVMe fixe à un prix fixe | Le volume NVMe inclus ne peut pas être détaché ; le modèle lui-même est immuable. Les Cubes peuvent toujours attacher jusqu'à 23 dispositifs de stockage sur bloc supplémentaires, donc ceci est un piège de modèle, et non une impasse de stockage | Unité 4.1 |
| Private Cloud (VMware dédié) | VMware SDDC géré pour un seul locataire avec licence incluse | Mis en service en libre-service et à la demande, mis à l'échelle verticalement en ajoutant des hôtes ; minimum trois hôtes par cluster | Unité 4.4 |
Le modèle est une classe par niveau : un niveau d'application sans état qui se met à l'échelle prend un Noyau dédié, un nœud utilitaire de taille fixe prend un Cube, une charge de travail réglementée pour un seul locataire prend un Private Cloud. Ne normalisez pas une classe sur tous les niveaux.
2. Sélection de la plateforme de conteneurs
La décision concernant les conteneurs dépend de qui assume le contrôle du cycle de vie de la plateforme de contrôle et de la charge de conformité. Une seule option impose cette charge à IONOS CLOUD.
| Plateforme | Critère de différenciation | Contrainte d'éligibilité stricte | Déduit dans |
|---|---|---|---|
| Managed Kubernetes | Plateforme de contrôle gérée gratuite ; IONOS CLOUD assume le cycle de vie de la plateforme de contrôle ; les pools de nœuds sont facturés comme Compute Engine | Un service LoadBalancer n'est pas un véritable équilibrage de charge externe (une adresse IP statique sur un nœud d'entrée, limitée à la bande passante publique de ce nœud) ; un Managed ALB/NLB séparé est provisionné pour une véritable entrée. Aucune mise à l'échelle vers zéro ; le plancher d'autoscaling est d'un nœud chaud | Unité 6.1, 6.2 |
| Red Hat OpenShift | Plateforme OpenShift complète, déployée par le client sur l'infrastructure IONOS CLOUD | Ce n'est pas un service géré par IONOS CLOUD ; le cycle de vie du cluster repose sur le client en tant que partenaire Red Hat CCSP. Une validation Red Hat est requise avant la production | Unité 6.4 |
| SUSE Rancher Prime | Gestion multi-cluster Rancher sur le calcul IONOS CLOUD | Livraison autonome ; non gérée par IONOS CLOUD ; SUSE facture les licences (apportez votre propre abonnement) | Unité 6.4 |
Pour le parc de conteneurs de FinCorp, le facteur de différenciation est la charge opérationnelle : Managed Kubernetes est la valeur par défaut car IONOS CLOUD possède la plateforme de contrôle, et les alternatives déployées par le client sont choisies uniquement lorsque contrat ou base de compétences OpenShift ou Rancher existe déjà.
3. Sélection du niveau de stockage
Le stockage est adapté au modèle d'accès. La contrainte récurrente est le plancher de performance des SSD et l'asymétrie de zone entre le calcul et le stockage.
| Niveau | Critère de différenciation | Contrainte d'éligibilité stricte | Déduit dans |
|---|---|---|---|
| Stockage sur disque dur Block Storage HDD | Coût le plus bas par Go ; attachement à une seule VM VM | Dispositif à VM unique ; non partagé ; pas un mécanisme de sauvegarde | Unité 5.1, 4.2 |
| Stockage sur disque dur SSD Standard / Premium Block Storage SSD | IOPS et débit plus élevés par GiB ; attachement à une seule VM VM ; jusqu'à 4096 Go par volume | Le SSD Standard en dessous de 100 Go n'atteint pas la pleine performance, il est donc inadapté comme volume de base de données de petite taille | Unité 5.1, 7.3 |
| NFS (fichier partagé géré) | Montage multi-client concurrent dans une région | Régional et privé ; pas disponible dans tous les emplacements (par exemple DE/FRA/2 et GB/WOR) ; actif-passif au niveau du service | Unité 5.1 |
| Object Storage | Cible de sauvegarde S3-compatible en vrac, archive, et magasin d'audit ; verrouillage d'objet pour rétention anti-tampon | Pas un système de fichiers ; espace de noms plat avec authentification par clé et secret ; non attachable en bloc | Unité 5.2 |
Notez l'asymétrie de zone comme contrainte de placement : le Stockage sur disque dur Block Storage offre les zones 1, 2, 3 et Auto, tandis que le calcul n'offre que les zones 1, 2 et Auto. Une paire redondante épinglée à la « zone 3 de calcul » n'est pas possible car la zone 3 de calcul n'existe pas.
4. Sélection du moteur de base de données
La décision de base de données est dictée par le modèle de données en premier, et le modèle de réplication et de continuité en second. Parmi les moteurs relationnels, il n'y a pas de réplicas de lecture, et le Backup Service ne couvre aucune base de données gérée, donc la mise à l'échelle de la lecture et la continuité sont composées, et non achetées.
| Moteur | Critère de différenciation | Contrainte d'éligibilité stricte | Déduit dans |
|---|---|---|---|
| Managed PostgreSQL | Relationnel ; réplication asynchrone (par défaut) ou strictement synchrone pour le RPO le plus bas | La réplication strictement synchrone nécessite deux nœuds opérationnels, avec un minimum de 3 instances recommandées pour la production ; pas de réplicas de lecture ; point de terminaison privé uniquement | Unité 5.3 |
| Managed MariaDB | Relationnel ; profil opérationnel plus simple | Réplication asynchrone uniquement (pas d'option synchrone) ; point de terminaison privé uniquement | Unité 5.3 |
| Managed MongoDB | Modèle document ; partitionnement pour une mise à l'échelle horizontale | Le partitionnement est une fonctionnalité d'édition entreprise ; pas de réplication gérée de flux de modification ; point de terminaison privé uniquement | Unité 5.4 |
| In-Memory DB (cache) | Niveau de lecture sous-milliseconde ; couche de mise à l'échelle et d'externalisation des sessions | Un cache, et non un système d'enregistrement ; point de terminaison privé uniquement | Unité 5.5 |
| Managed Kafka | Diffusion d'événements ; substitut à la capture des données de modification au niveau de l'application | Trois courtiers ; l'ordre est par partition uniquement ; ce n'est pas une base de données | Unité 5.6 |
Pour le noyau transactionnel de FinCorp, PostgreSQL avec réplication strictement synchrone répond au besoin faible RPO, le niveau In-Memory DB répond à la mise à l'échelle des lectures car les réplicas de lecture n'existent pas, et Kafka transporte les événements de modification car il n'y a pas de flux géré des modifications des bases de données.
5. Sélection des primitives de réseau
Chaque primitive de réseau répond à une couche ou une direction de trafic différente. Les contraintes strictes ici sont la source la plus fréquente d'appariements incompatibles (voir Section 7).
| Primitive | Critère de différenciation | Contrainte d'éligibilité stricte | Dérivé dans |
|---|---|---|---|
| Managed ALB | Routage de contenu de la couche 7 (chemin, hôte, en-tête, méthode, cookie, adresse IP source) avec déchargement TLS | HTTP/HTTPS uniquement ; pas de liste blanche IP et pas de NSG sur le LB géré, donc le filtrage appartient aux cibles | Unité 3.3 |
| Managed NLB | Pass-through TCP de la couche 4 ; le backend conserve le certificat | TCP uniquement ; pas de termination TLS ; pas de NSG sur le LB géré | Unité 3.4 |
| NAT Gateway | Chemin de sortie pour les charges de travail privées | SNAT uniquement, pas de DNAT entrant ; nécessite une adresse IP publique réservée | Unité 3.6 |
| VPN Gateway | Connectivité site à site chiffrée | IKEv2 ou WireGuard uniquement (pas IKEv1) ; partage HA actif-passif avec une adresse IP publique unique | Unité 3.6 |
| Cross-Connect | Interconnecteur privé haute bande passante entre VDCs | Même région et même contrat uniquement ; pas inter-région ; un LAN par connexion | Unité 3.6 |
| Network Security Group | Filtrage par défaut deny-all-by-default à l'état pour la carte NIC du serveur | Lie les cartes NIC des serveurs uniquement ; ne s'applique pas aux nœuds du pool de nœuds Managed Kubernetes ou aux Cubes suspendus, et jamais au Managed ALB/NLB géré | Unité 3.2 |
| Cloud DNS | Résolution anycast et gestion d'enregistrements à faible TTL | Pas de basculement basé sur les vérifications de santé natives ; il dirige les nouvelles connexions uniquement, et le TTL minimum de 60 secondes est le levier RTO dominant | Unité 3.7 |
6. Le filtre de souveraineté et d'attestation
Appliquez ce filtre en dernier, sur la conception terminée. La souveraineté et la conformité ne créent pas une architecture ; elles réduisent l'ensemble des emplacements que une conception déjà correcte est autorisée à utiliser. La souveraineté juridique de l'UE est une propriété de la juridiction de l'opérateur, et non de la région seule : une région de l'UE d'un fournisseur opéré aux États-Unis est toujours exposée à la loi CLOUD Act des États-Unis, alors que IONOS CLOUD est opéré dans l'UE.
Les étendues d'attestation diffèrent par service et ne doivent jamais être généralisées à "la plateforme est certifiée". Les deux reconnaissances BSI, toutes deux pour les centres de données allemands, couvrent des ensembles de services différents :
| Service | BSI C5 (attestation de type 1, 2023-11-07) | ISO 27001 basé sur IT-Grundschutz (certificat, 2022-09-14) |
|---|---|---|
| Compute Engine | Dans l'étendue | Dans l'étendue |
| Cloud Cubes | Dans l'étendue | Hors de l'étendue |
| Object Storage | Dans l'étendue | Dans l'étendue |
| Sauvegarde | Hors de l'étendue | Dans l'étendue |
| Managed Kubernetes | Hors de l'étendue | Dans l'étendue |
IONOS CLOUD est le premier fournisseur de cloud allemand à détenir à la fois l'attestation C5 et la certification IT-Grundschutz, mais les deux étendues ne sont pas interchangeables. C5 est une attestation (Testat), de type 1, et non une certification et non de type 2. Les informations d'identification au niveau du centre de données (par exemple ISO 27001 à un emplacement, PCI-DSS, Uptime Tier IV) sont détenues par l'opérateur du centre de données et varient selon l'emplacement ; les listes de certificats de produits dans le marketing ne sont pas contractuelles. NIS2 est une obligation réglementaire, et non une certification détenue.
Pour FinCorp sous le RGPD et BSI, la résidence est une décision d'emplacement prise avant que toute charge de travail ne soit affectée : les centres de données allemands, l'opérateur de l'UE, et chaque service dans l'étendue validé contre l'attestation exacte dont sa classe de données a besoin.
Résumé de la décision
Utilisez les matrices ci-dessus comme artifact à retenir de l'unité. L'ordre de lecture est fixé :
- Restreignez par le critère de différenciation pour le niveau.
- Éliminez chaque option qui échoue à une contrainte d'éligibilité stricte, avant de prendre en compte tout le reste.
- Appliquez le filtre de souveraineté et d'attestation en dernier, sur toute la conception.
7. Les deux erreurs de composition
Un design peut passer tous les tests de matrice par primitive et échouer encore. Deux erreurs comptent pour presque tous ces cas.
Appairer des primitives incompatibles. Deux choix qui sont chacun corrects en isolation ne se composent pas. Placer un groupe de sécurité réseau « devant » un équilibreur de charge géré (Managed ALB) ou un équilibreur de charge réseau géré (Managed NLB) ne fait rien, car les groupes de sécurité réseau sont liés aux cartes réseau des serveurs et jamais à l'équilibreur de charge géré ; le filtrage doit être effectué sur les cibles. S'attendre à un trafic entrant via une passerelle NAT échoue, car NAT est uniquement SNAT ; la publication entrante appartient à un équilibreur de charge ou à une adresse IP publique réservée. Essayer d'utiliser une connexion croisée pour relier deux centres de données virtuels dans différentes régions échoue, car la connexion croisée est limitée à la même région et au même contrat. Chacun est une primitive correcte utilisée là où sa contrainte stricte l'interdit.
Un choix fonctionnellement correct en dehors du périmètre d'attestation requis. Un service peut faire le travail parfaitement et être encore le mauvais choix pour une charge de travail réglementée parce qu'il se situe en dehors de l'attestation que cette charge de travail nécessite. Exécuter le traitement réglementé en conteneurs de FinCorp sur Managed Kubernetes est fonctionnellement solide, mais Managed Kubernetes n'est pas dans le périmètre d'attestation C5, donc une charge de travail qui nécessite contractuellement C5 doit être placée sur un service couvert par C5, tel que Compute Engine. Le choix n'est pas incorrect sur le plan technique ; il est incorrect par rapport au filtre de périmètre, qui est appliqué en dernier sur l'ensemble du design.
Résumé
Les décisions d'architecture sur IONOS CLOUD se réduisent à un processus répétitif : réduire en fonction du critère de différenciation, éliminer en fonction des contraintes strictes, et appliquer enfin la souveraineté et la portée de l'attestation sur la conception terminée. Les matrices dans cette unité recueillent ces critères et contraintes pour le calcul, les conteneurs, le stockage, les bases de données et le réseau, afin qu'une décision puisse être prise et justifiée en un seul endroit, avec les deux erreurs de composition comme vérification finale.
Points clés :
- Les contraintes d'éligibilité strictes disqualifient purement et simplement : une seule contrainte non satisfaite élimine une option, quel que soit son score ailleurs.
- VM Auto Scaling est uniquement horizontal et crée de nouvelles répliques à partir d'un modèle de réplique défini à l'époque de la conception ; les moteurs relationnels n'ont pas de répliques en lecture ; le Backup Service ne couvre aucune base de données gérée. Ces limites décident des niveaux à l'avance.
- Le filtre de souveraineté et d'attestation est appliqué en dernier, car la conformité restreint une conception déjà terminée plutôt que de l'initier.
- Les portées C5 et IT-Grundschutz diffèrent par service : Cubes est dans C5 mais pas dans IT-Grundschutz ; Backup et Managed Kubernetes sont dans IT-Grundschutz mais pas dans C5. Ne généralisez jamais à "la plateforme est certifiée".
- Les deux erreurs de composition sont l'association de primitives dont les contraintes interdisent l'association, et la mise d'un service fonctionnellement correct en dehors de la portée d'attestation requise par la charge de travail.
Terminologie importante :
- Contrainte d'éligibilité stricte : un disqualificateur absolu (par exemple, un modèle immutable d'un Cube, ou le manque de scale-to-zero de Managed Kubernetes) qui élimine une option avant que tout critère pondéré ne soit considéré.
- Portée d'attestation : l'ensemble exact des services couverts par une crédential ; sur IONOS CLOUD, C5 et IT-Grundschutz couvrent différents services, et une revendication doit toujours être liée au service nommé, à l'emplacement du centre de données allemand, à la crédential, à son type et à sa date.
Lecture supplémentaire
- Unité 4.1 Sélection de la classe de calcul, Unité 4.4 Private Cloud (VMware dédié)
- Unité 6.1 Conception de la plateforme Kubernetes, Unité 6.4 Registre de conteneurs et sélection de la plateforme
- Unité 5.7 Protection des données et cycle de vie
- Unité 1.4 Souveraineté et conformité en tant qu'entrées de conception
- Unité 8.2 L'architecture d'entreprise de référence