Unité 8.2 : L'architecture d'entreprise de référence

Introduction

Chaque unité précédente a décidé d'une chose en isolation : une classe de calcul, un mode de réplication, une couche d'équilibrage de charge, un mécanisme de basculement. Cette unité les rassemble sur une seule toile à la fois. Le but n'est pas de réapprendre un produit, mais de montrer comment les décisions se composent, où un choix dans un niveau restreint un choix dans un autre, et comment les limites honnêtes de la plateforme façonnent l'ensemble de l'image plutôt que juste la partie qui les touche.

L'architecture de référence est celle de FinCorp : une entreprise allemande de services financiers sous GDPR et la surveillance de la BSI, qui migre un grand parc VMware et met en place une capacité d'IA. Il s'agit de l'accumulation de chaque décision prise dans les modules 1 à 7, représentée comme un système unique. Traitez-le comme un modèle que vous instanciez, et non comme un diagramme que vous copiez.

1. Le système assemblé

La conception est organisée par la forme en couches canonique de l'Unité 1.2 : une couche 7 publique, une couche de calcul sans état, un équilibreur de charge privé de la couche 4 et une couche de données privée. Autour de cette colonne vertébrale se trouvent le domaine VMware dédié, la plateforme de conteneurs, la couche d'intelligence artificielle et les liens hybrides vers les locaux de FinCorp. Tout se trouve à l'intérieur d'un contrat (la limite de gouvernance et de facturation de l'Unité 2.1) et est segmenté à travers des centres de données virtuels par région et environnement.

1.1 Segmentation et chemin en couches

Un LAN sur IONOS est privé jusqu'à ce qu'il soit connecté à l'accès internet (Unité 3.1). Le VDC de production de FinCorp comporte trois LAN : un bord public LAN, un bord d'application privé LAN et un bord de données privé LAN. Le trafic nord-sud entre à la limite publique ; le trafic est-ouest entre les couches reste sur les LAN privés et ne traverse jamais un IP public.

Le chemin de la requête est conçu délibérément. Un Managed Application Load Balancer public (ALB) met fin au TLS à la limite et achemine en fonction des attributs de la couche 7 ; il sert de périphérique de limite pour gérer le trafic nord-sud à l'intérieur et à l'extérieur du centre de données. Derrière lui se trouve la couche d'application sans état sur le calcul dédié Core. Ces serveurs atteignent la couche de données via un Managed Network Load Balancer privé (NLB), qui transmet le TCP de la couche 4 aux points de terminaison de la base de données et gère le trafic est-ouest à l'intérieur du centre de données. La composition Managed Application Load Balancer-Managed Network Load Balancer (Unités 3.3 et 3.4) est la colonne vertébrale de l'équilibrage de charge : conscient du contenu à la limite où la logique de routage compte, passage rapide du TCP à l'intérieur où cela n'a pas d'importance.

La couche d'application est sans état intentionnellement. Cette condition préalable est ce qui lui permet de se mettre à l'échelle automatiquement (Unité 4.3) et ce qui permet au Load Balancer frontal de déplacer de nouvelles connexions vers des répliques saines sans laisser la session dans un état incohérent. L'état de session et l'état de lecture sont externalisés vers la couche de cache en mémoire au lieu d'être conservés sur les serveurs.

1.2 VMware dédié pour le traitement réglementé

Le noyau réglementé de FinCorp fonctionne sur IONOS Private Cloud : un VMware dédié géré SDDC (vSphere Enterprise Plus, vSAN, NSX-T) sur du matériel à locataire unique, avec des licences incluses plutôt que fournies (Unité 4.4). Le fait d'être à locataire unique est le moteur de conception ici : les charges de travail qui nécessitent les exigences d'isolement et de prévisibilité les plus strictes se trouvent sur du matériel que aucun autre locataire ne partage. La mise en service est une opération d'engagement guidé, et non une action de console auto-service, c'est pourquoi cette partie du domaine est conçue plutôt que construite dans le Data Center Designer.

Le domaine VMware n'est pas une île. Il se connecte à la limite de calcul standard élastique via la connectivité hybride décrite ci-dessous, ce qui donne à FinCorp le modèle hybride éprouvé : un noyau VMware dédié pour le traitement réglementé et à l'état stable, ainsi qu'un calcul standard élastique pour la charge de bord variable. La pile VMware ici est NSX-T 3.2 avec vCenter pour la gestion dans le Cluster ; l'outil de mobilité et de réplication VMware en scope est ce que la plateforme fournit réellement, couvert sous migration ci-dessous.

1.3 Managed Kubernetes pour les conteneurs

Les services nouveaux et révisés fonctionnent sur Managed Kubernetes (Unité 6.1). Le plan de contrôle est géré et gratuit ; FinCorp paie pour les Node Pools, qui ont leur propre SLA distinct de celui du plan de contrôle. Le Cluster se connecte à la forme en couches via un Load Balancer provisionné séparément et un contrôleur d'entrée dans le Cluster, car un manifeste Kubernetes ne provisionne pas automatiquement un Load Balancer géré IONOS. Un service de type LoadBalancer se résout en une adresse IP statique unique, et non en un équilibreur de charge géré, donc le chemin d'entrée de production est un ALB devant un contrôleur d'entrée dans le Cluster. C'est le remplacement de la passerelle API réalisé : les règles de chemin ALB et l'entrée dans le Cluster tiennent lieu d'un API Gateway géré, que IONOS ne vend pas.

La sécurité sur le Cluster est divisée honnêtement. Les pare-feu Network Security Groups et les pare-feu de carte réseau se connectent aux cartes réseau des travailleurs Node, et non à l'abstraction Cluster, donc le contrôle de pod à pod est appliqué avec des politiques de réseau dans le Cluster. Les images de conteneur proviennent du registre de conteneurs, régi par la discipline des jetons (un jeton étroitement défini par étape de pipeline, avec expiration et rotation ; les jetons sont supprimés, et non désactivés) car le registre n'a pas de RBAC.

1.4 La plateforme de données

La couche de données est privée et se compose de plusieurs moteurs gérés, chacun adapté à un modèle d'accès :

• Relationnel (Managed PostgreSQL / MariaDB) : le système d'enregistrement. Il n'y a pas de répliques de lecture. La réplication est dans le Cluster (PostgreSQL asynchrone par défaut, avec des modes synchrones et strictement synchrones disponibles ; MariaDB asynchrone uniquement) pour la durabilité et l'auto-promotion intra-Cluster, et non pour la mise à l'échelle de la lecture.
• Cache en mémoire : la couche de mise à l'échelle de la lecture et d'externalisation de l'état (Unité 5.5). Il se situe devant la couche relationnelle et absorbe la charge de lecture, et il conserve l'état de session soulevé de la couche d'application sans état. Ce cache est ce qui rend à la fois le modèle sans réplique de lecture et la mise à l'échelle automatique sécurisée ; il n'est pas un décor optional.
• Document (Managed MongoDB) : pour les charges de travail dont la forme convient mieux à un modèle de document qu'à des lignes relationnelles.
• Diffusion en continu (Kafka géré) : la colonne vertébrale d'ingestion et le substitut de la capture de modification de données. Puisqu'il n'y a pas de flux de modification de données géré pour la base de données, les applications publient des événements sur Kafka au niveau de l'application. Les partitions sont l'unité d'ordre et de parallélisme des consommateurs ; la conception du sujet et de la partition est la décision porteuse de charge.
• Archive d'objets (Object Storage) : le magasin à espace de noms plat compatible S3 qui sert de cible de sauvegarde, d'archive d'audit, de magasin de jeux de données et d'artefacts, et de queue de lettres mortes et d'archive pour Kafka. L'object lock fournit une rétention à preuve de falsification.

1.5 La couche d'intelligence artificielle

La capacité d'intelligence artificielle de FinCorp par défaut est l'inférence gérée sur le AI Model Hub : un moteur d'inférence API compatible OpenAI, tarification par jeton, sans état, avec résidence de données UE et traitement dans le pays. La génération assistée par récupération est construite par le client à partir de parties de plateforme : des embeddings à partir du hub, des vecteurs stockés dans Managed PostgreSQL, et le corpus source dans Object Storage. La fonctionnalité de magasin de vecteurs gérée du hub est évitée en faveur de ce modèle composé, qui garde le magasin de récupération sous la gouvernance de base de données de FinCorp.

1.6 Connectivité hybride

Les locaux de FinCorp et son domaine VMware atteignent le cloud via les primitives de connectivité de l'Unité 3.6. Un VPN Gateway (IKEv2 ou WireGuard, pas IKEv1 ; partage actif-passif HA avec un IP public unique) transporte le trafic de site à cloud chiffré. Un NAT Gateway fournit une sortie pour les charges de travail privées qui n'ont pas de IP public ; il est SNAT uniquement, donc c'est un chemin de sortie, et non un point d'entrée. Les liens de connexion privée croisés relient les VDC dans la même région et le même contrat via une interconnexion privée partagée, y compris le trafic Node croisé-VDC qu'un Cluster privé Kubernetes dépend.

1.7 Résilience, observabilité et coût comme enveloppe de fonctionnement

La résilience (Unité 7.1) repose sur les primitives de plateforme plutôt que sur un produit de basculement géré, qui n'existe pas. Les paires redondantes sont placées dans des zones de disponibilité explicites (jamais Auto, qui peut les co-localiser), et les équilibreurs de charge gérés vérifient l'état de leurs cibles et arrêtent l'acheminement vers un backend défaillant ; le Cloud DNS fournit une résolution anycast et un TTL minimum faible pour une propagation rapide d'enregistrements, mais n'effectue pas de basculement basé sur la vérification de l'état natif. Le plan de direction du trafic (DNS) est maintenu séparé du plan de continuité des données (sauvegardes, instantanés, PITR, archive Object Storage). L'observabilité (Unité 7.2) s'étend sur quatre plans de télémétrie à portée fixe, des métriques, des journaux, des audits et des flux Flow Logs, éventés vers un SIEM externe car il n'y a pas d'agrégation inter-contrat et les événements de plan de contrôle Kubernetes ne passent pas par le Logging Service. Le coût (Unité 2.4) est régi par l'allocation par contrat et VDC, le stockage étage à modèle d'accès, et les Plans d'économies sont engagés au plancher d'état stable.

2. Préoccupations transversales, et non des fonctionnalités isolées

L'architecture ne tient ensemble que parce que quatre préoccupations traversent chaque niveau, plutôt que de vivre dans une seule boîte.

La haute disponibilité est composée, et non achetée. L'ALB et le NLB de bordure sont gérés et résilients ; les nœuds de calcul et de données redondants sont placés à travers des zones explicites ; les équilibreurs de charge gérés vérifient la santé de leurs cibles et routent autour des backends défaillants ; et le domaine dédié VMware ajoute une tolérance aux défauts vSAN et une haute disponibilité vSphere à l'intérieur de son Cluster. Aucun produit unique ne livre une haute disponibilité de bout en bout ; la conception superpose ces mécanismes.

L'équilibrage de charge apparaît à deux altitudes pour deux raisons. Le niveau 7 à la bordure publique donne un routage conscient du contenu et une termination TLS ; le niveau 4 à l'intérieur donne un passage rapide TCP avec le backend qui garde son propre certificat. Aucun équilibreur de charge géré n'accepte un groupe de sécurité réseau ou une liste d'autorisation IP, donc le filtrage appartient aux cibles derrière eux.

La sécurité est appliquée où elle se lie : pare-feu de carte réseau et groupes de sécurité réseau sur les cartes réseau de serveur et de travailleur, politiques de réseau à l'intérieur de Kubernetes, discipline de jeton sur le registre, et contrôle d'accès de groupe et d'octroi à travers le contrat. Il n'y a pas de langage de politique IAM et pas de règle de refus ; le privilège minimum est atteint en ne grantant pas, et la fédération (SAML/OIDC) est une authentification uniquement, donc le processus de jointure-mouvement-départ est un runbook manuel.

La connectivité relie le domaine ensemble : réseaux LAN privés pour le trafic de niveau est-ouest, VPN pour le site-nuage, NAT pour la sortie privée, et Cross-Connect pour les liens de région croisée-VDC. La topologie elle-même est un contrôle de sécurité, car isoler le niveau de données sur un réseau privé LAN est ce qui compense le manque de support NSG des équilibreurs de charge gérés.

Le tableau suivant mappe chaque limite de capacité IONOS à la configuration native qui la compose, réalisée dans cette architecture.

La migration vers le noyau réglementé VMware utilise uniquement l'outillage que la plateforme fournit : VMware Cloud Director Availability (VCDA, version 4.7.x) pour la réplication asynchrone, la migration et le basculement en direct à environ 50 EUR par VM protégé par mois ; NSX-T's L2 VPN intégré pour l'extension de réseau de niveau 2 (une fonctionnalité standard NSX-T Edge, et non un module complémentaire séparément licencié) ; et vMotion intra-Cluster. vMotion est uniquement intra-Cluster et n'est pas une capacité de mobilité en direct entre sites. Les charges de travail sans chemin VMware-natif sont réhébergées via la conversion et le téléchargement d'images, et les bases de données migrent par vidange et restauration, puisque le Backup Service ne couvre pas les bases de données gérées.

Résumé de la décision

L'artefact porteur de charge de l'architecture de référence est la carte service par service : où chaque composant est placé, et exactement quelles reconnaissance BSI le couvrent. La conformité est définie pour chaque service et chaque emplacement de centre de données, et non pour l'ensemble de la plateforme, donc la carte est ce que l'auditeur lit. Le BSI C5 est une attestation de type 1 (Testat) accordée le 2023-11-07 ; IT-Grundschutz est un certificat ISO 27001 accordé le 2022-09-14 (BSI). Les deux s'appliquent aux centres de données allemands, et leurs portées diffèrent selon le service. IONOS est le premier fournisseur de cloud allemand à détenir les deux.

Deux règles de lecture régissent ce tableau. Premièrement, « dans la portée » signifie que le service nommé dans les centres de données allemands porte cette reconnaissance BSI ; cela ne concerne jamais une revendication à l'échelle de la plateforme. Le C5 couvre exactement les Compute Engine, Cloud Cubes et S3 Object Storage ; IT-Grundschutz couvre exactement les Compute Engine, S3 Object Storage, la sauvegarde et Managed Kubernetes. Les deux portées divergent : les Cubes sont sous C5 mais pas sous IT-Grundschutz, tandis que Managed Kubernetes et la sauvegarde sont sous IT-Grundschutz mais pas sous C5. Deuxièmement, le filtre de souveraineté de l'unité 1.4 est appliqué en dernier, sur l'ensemble de la conception : chaque composant est exploité sous la juridiction de l'UE, ce qui est une propriété de l'opérateur et non seulement de la région.

Les deux erreurs de composition à vérifier dans la conception assemblée sont l'association de primitives incompatibles (par exemple, s'attendre à ce qu'un NSG protège un équilibreur géré, ou essayer de joindre deux VDC dans différentes régions à l'aide d'une connexion croisée) et le placement d'un service fonctionnellement correct en dehors de sa portée d'attestation requise (par exemple, exécuter un traitement réglementé requis par C5 sur un service que C5 ne couvre pas).

Résumé

L'architecture d'entreprise de référence est l'ensemble du cours représenté en un seul système : un chemin public-L7-privé-L4 en couches sur un niveau de calcul sans état et une plateforme de données privée, avec un noyau VMware dédié pour le traitement réglementé, Managed Kubernetes pour les conteneurs, un niveau d'IA par défaut pour l'inférence gérée, et des liens hybrides qui le relient aux locaux de FinCorp. La haute disponibilité, l'équilibrage de charge, la sécurité et la connectivité ne sont pas des fonctionnalités dans des boîtes, mais des préoccupations qui traversent chaque niveau, et l'ensemble de substitution natif est ce qui remplit les lacunes que la plateforme ne vend pas intentionnellement comme des produits gérés. La carte de placement et de conformité service par service est l'artefact qui rend la conception défendable lors d'une audit.

Points clés :

• La forme en couches est la colonne vertébrale ; tout le reste (noyau VMware, Kubernetes, IA, moteurs de données, liens hybrides) s'attache à celle-ci, et la segmentation plus la configuration privée par défaut déterminent la disposition.
• La haute disponibilité, l'équilibrage de charge, la sécurité et la connectivité sont transversales : chacune est composée à travers les niveaux à partir de primitives de plateforme, et non livrée par un seul produit.
• L'ensemble de substitution natif est réalisé de bout en bout : routage API via ALB plus entrée, mise à l'échelle de lecture via cache, basculement via vérifications de l'état de santé des cibles d'équilibrage de charge sur des points de terminaison zonés, CDC via Kafka, importation VM via conversion d'image, accès via groupe et autorisation.
• La conformité est par service et par emplacement de centre de données : C5 (attestation de type 1, 2023-11-07) et IT-Grundschutz (certificat ISO 27001, 2022-09-14) ont des portées de service différentes, et la carte de placement encode les deux.
• Le noyau VMware réglementé n'utilise que VCDA, NSX-T L2 VPN, et vMotion intra-Cluster ; il n'y a pas de mobilité live entre les sites, et les bases de données migrent par vidange et restauration.

Lecture supplémentaire

• Unité 8.1 : Cadres de décision d'architecture (les matrices de sélection que cette conception instancie)
• Unité 8.3 : Laboratoire de synthèse, qui construit le noyau d'entreprise FinCorp de bout en bout dans le Data Center Designer
• Unité 1.2 : L'architecture canonique en couches ; Unité 1.3 : Le modèle de substitution natif ; Unité 1.4 : La souveraineté et la conformité en tant que données de conception
• Centre d'architecture IONOS Cloud