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

Introduction

Chaque unité précédente a pris une décision de manière isolée : une classe de calcul, un mode de réplication, une couche d'équilibreur de charge, un mécanisme de basculement. Cette unité les réunit toutes sur une même toile d'un seul coup. L'objectif n'est pas de réexpliquer un produit, mais de montrer comment les décisions se combinent, comment un choix à un niveau en restreint un autre à un niveau différent, et comment les limites honnêtes de la plateforme façonnent l'ensemble du schéma, et non seulement la partie qui les touche.

L'architecture de référence est celle de FinCorp : une société de services financiers allemande soumise au RGPD et à la supervision du BSI, qui migre un important parc VMware et met en place une capacité d'IA. Elle représente l'accumulation de toutes les décisions prises dans les modules 1 à 7, représentée comme un système unique. Considérez-la comme un modèle à instancier, et non comme un schéma à copier.

1. Le système assemblé

La conception est organisée selon la forme en couches canonique de l'Unité 1.2 : une couche 7 publique en périphérie, une couche de calcul sans état, un équilibreur de charge privé en couche 4, et une couche de données strictement privée. Autour de cette structure centrale se trouvent l'infrastructure VMware dédiée, la plateforme de conteneurs, la couche IA, et les liens hybrides vers les locaux de FinCorp. L'ensemble est hébergé au sein d'un même contrat (la frontière de gouvernance et de facturation de l'Unité 2.1) et segmenté à travers des centres de données virtuels par région et par environnement.

1.1 Segmentation et chemin en couches

Un LAN sur IONOS CLOUD 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 LAN de périphérie publique, un LAN d'application privé, et un LAN de données privé. Le trafic nord-sud entre par la périphérie publique ; le trafic est-ouest entre les couches reste sur les LAN privés et ne traverse jamais une IP publique.

Le chemin de requête est délibérément organisé en couches. Un Managed Application Load Balancer (ALB) public termine TLS en périphérie et route sur des attributs de couche 7 ; il sert d'appareil de périphérie gérant le trafic nord-sud entrant et sortant du centre de données. Derrière lui se trouve la couche d'application sans état sur des serveurs de calcul Dedicated Core. Ces serveurs atteignent la couche de données via un Managed Network Load Balancer (NLB) privé, qui transmet le TCP de couche 4 vers les points d'accès de la base de données et gère le trafic est-ouest à l'intérieur du centre de données. La composition ALB public vers NLB privé (Unités 3.3 et 3.4) constitue l'ossature de l'équilibrage de charge : consciente du contenu en périphérie où la logique de routage est importante, et en transmission TCP rapide en interne où elle ne l'est pas.

La couche d'application est sans état par conception. Cette condition préalable est ce qui permet la mise à l'échelle automatique (Unité 4.3) et ce qui permet à l'équilibreur de charge frontal de rediriger les nouvelles connexions vers des répliques saines sans laisser à l'abandon l'état de session. L'état de session et l'état de lecture sont externalisés vers la couche de cache en mémoire plutôt que conservés sur les serveurs.

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

Le cœur réglementé de FinCorp fonctionne sur IONOS CLOUD Private Cloud : un SDDC VMware dédié managé (vSphere Enterprise Plus, vSAN, NSX-T) sur du matériel monolocataire, avec la licence incluse plutôt que fournie par le client (Unité 4.4). Le monolocataire est le moteur de conception ici : les charges de travail qui imposent les exigences les plus strictes d'isolation et de prévisibilité sont hébergées sur du matériel non partagé par d'autres locataires. Le provisionnement est une démarche guidée, et non une action en libre-service via une console, c'est pourquoi cette partie de l'infrastructure est conçue plutôt que construite dans Data Center Designer.

L'infrastructure VMware n'est pas une île. Elle est reliée à la périphérie de calcul standard élastique via la connectivité hybride décrite ci-dessous, offrant à FinCorp le modèle hybride éprouvé : un cœur VMware dédié pour le traitement réglementé et stable, plus un calcul standard élastique pour la charge de périphérie variable. La pile VMware ici est NSX-T 3.2 avec vCenter pour la gestion intra-cluster ; les seuls outils de mobilité et de réplication VMware dans le périmètre sont ceux que la plateforme fournit réellement, couverts sous la migration ci-dessous.

1.3 Managed Kubernetes pour les conteneurs

Les nouveaux services et les services refactorisés fonctionnent sur Managed Kubernetes (Unité 6.1). Le plan de contrôle est managé et gratuit ; FinCorp paie pour les pools de nœuds, qui ont leur propre SLA distinct de celui du plan de contrôle. Le cluster est rattaché à la structure en couches via un équilibreur de charge provisionné séparément plus un contrôleur d'ingress intra-cluster, car un manifeste Kubernetes ne provisionne pas automatiquement un équilibreur de charge managé IONOS CLOUD. Un Service de type LoadBalancer se résout en une IP statique mononœud, et non en un équilibreur managé, donc le chemin d'ingress de production est un ALB placé devant un contrôleur d'ingress intra-cluster. C'est la substitution par passerelle API réalisée : les règles de chemin ALB plus l'ingress intra-cluster remplacent une passerelle API managée, que IONOS CLOUD ne vend pas.

La sécurité sur le cluster est partagée honnêtement. Les Network Security Groups et les pare-feu NIC sont liés aux NIC des nœuds de travail, et non à l'abstraction du cluster, donc le contrôle inter-pods est appliqué via des politiques réseau intra-cluster. Les images de conteneurs proviennent du Container Registry, régies par une discipline de jetons (un jeton à portée étroite par étape du pipeline, avec expiration et rotation ; les jetons sont supprimés, et non désactivés) car le registre ne dispose pas de RBAC.

1.4 La plateforme de données

La couche de données est uniquement accessible via des points d'accès privés et composée de plusieurs moteurs managés, chacun adapté à un modèle d'accès :

• Relationnel (Managed PostgreSQL / MariaDB) : le système de référence. Il n'y a pas de répliques de lecture. La réplication est intra-cluster (PostgreSQL asynchrone par défaut, avec des modes synchrones et strictement synchrones disponibles ; MariaDB uniquement asynchrone) pour la durabilité et la promotion automatique 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). Elle fait face à la couche relationnelle et absorbe la charge de lecture, et elle conserve l'état de session déchargé de la couche d'application sans état. Ce cache est ce qui rend fonctionnels à la fois le modèle sans réplique de lecture et la mise à l'échelle automatique sécurisée ; il ne s'agit pas d'une décoration optionnelle.
• Documentaire (Managed MongoDB) : pour les charges de travail dont la forme s'adapte mieux à un modèle documentaire qu'aux lignes relationnelles.
• Flux (Managed Kafka) : l'ossature d'ingestion et le substitut à la capture des données modifiées. Comme il n'y a pas de flux de modification de base de données managé, les applications publient des événements vers Kafka au niveau applicatif. Les partitions sont l'unité d'ordonnancement et de parallélisation des consommateurs ; la conception des sujets et des partitions est la décision porteuse de charge.
• Archive objet (Object Storage) : le stockage à espace de noms plat compatible S3 qui sert de cible de sauvegarde, d'archive d'audit, de stockage de jeux de données et d'artefacts, et de file morte et de queue d'archive pour Kafka. Le verrouillage d'objet fournit une rétention détectable en cas de falsification.

1.5 La couche IA

La capacité IA de FinCorp repose par défaut sur l'inférence managée du AI Model Hub : une API d'inférence compatible OpenAI, une tarification par jeton, sans état, avec résidence des données dans l'UE et traitement dans le pays. La génération augmentée par récupération est construite par le client à partir des composants de la plateforme : embeddings depuis le hub, vecteurs stockés dans Managed PostgreSQL, et le corpus source dans Object Storage. La fonction de stockage vectoriel managé du hub est évitée au profit de ce modèle composé, qui maintient le magasin de récupération sous la gouvernance de base de données propre à FinCorp.

1.6 Connectivité hybride

Les locaux de FinCorp et son infrastructure VMware atteignent le cloud via les primitives de connectivité de l'Unité 3.6. Un VPN Gateway (IKEv2 ou WireGuard, pas d'IKEv1 ; HA actif-passif partageant une IP publique unique) transporte le trafic chiffré site-vers-cloud. Un NAT Gateway fournit une éjection sortante pour les charges de travail privées qui n'ont pas d'IP publique ; il est uniquement SNAT, donc c'est un chemin d'éjection, jamais un point d'entrée entrant. Les liens Private Cross-Connect relient les VDC dans la même région et le même contrat via un interconnect privé partagé, y compris le trafic inter-VDC des nœuds dont un cluster Kubernetes privé dépend.

1.7 Résilience, observabilité et coût comme enveloppe opérationnelle

La résilience (Unité 7.1) repose sur des primitives de plateforme plutôt que sur un produit de basculement managé, 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 managés effectuent des vérifications d'état de leurs cibles et cessent de router vers un backend défaillant ; Cloud DNS fournit une résolution anycast et un TTL minimal bas pour une propagation rapide des enregistrements, mais n'effectue aucun basculement natif basé sur des vérifications d'état. Le plan de guidage 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) couvre quatre plans de télémétrie à périmètre fixe, les métriques, les journaux, l'audit, et les journaux de flux réseau, acheminés vers un SIEM externe car il n'y a pas d'agrégation inter-contrats et les événements du plan de contrôle Kubernetes ne passent pas par le service de journalisation. Le coût (Unité 2.4) est gouverné par l'allocation par contrat et VDC, le stockage hiérarchisé selon le modèle d'accès, et les Savings Plans engagés sur le plancher de l'état stable.

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

L'architecture tient ensemble uniquement parce que quatre préoccupations traversent chaque niveau, au lieu d'être cantonnées dans un seul composant.

La haute disponibilité est composée, et non achetée en bloc. 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 répartis sur des zones explicites ; les équilibreurs de charge gérés effectuent des vérifications d'état sur leurs cibles et détournent le trafic des serveurs en échec ; et le parc VMware dédié ajoute la tolérance aux pannes vSAN et la haute disponibilité vSphere au sein de son cluster. Aucun produit unique n'offre la haute disponibilité de bout en bout ; la conception superpose ces mécanismes.

L'equilibrage de charge apparaît à deux niveaux pour deux raisons. Le niveau 7 sur la bordure publique offre un routage sensible au contenu et une terminaison TLS ; le niveau 4 en interne offre une transmission TCP rapide, le serveur d'arrière-plan conservant son propre certificat. Aucun équilibreur de charge géré n'accepte un Network Security Group ni une liste d'autorisation IP, donc le filtrage doit être appliqué sur les cibles situées derrière eux.

La sécurité est appliquée là où elle est contraignante : pare-feux sur les NIC et NSG sur les NIC des serveurs et des workers, politiques réseau intra-cluster au sein de Kubernetes, discipline des jetons sur le registre, et contrôle d'accès par groupes et autorisations à travers le contrat. Il n'y a pas d'IAM par langage de politique ni de règle de refus ; le moindre privilège est atteint en n'accordant pas, et la fédération (SAML/OIDC) est une authentification uniquement, de sorte que le processus joiner-mover-leaver est un runbook manuel.

La connectivité assemble le parc : des LAN privés pour le trafic est-ouest entre niveaux, un VPN pour le site-vers-cloud, un NAT pour l'émission privée, et Cross-Connect pour les liens inter-VDC dans la même région. La topologie elle-même est un contrôle de sécurité, car l'isolement du niveau de données sur un LAN privé est ce qui compense l'absence de prise en charge des NSG par les équilibreurs de charge gérés.

Le tableau suivant associe chaque limite de capacité d'IONOS CLOUD au modèle natif qui la compose, réalisé dans cette architecture.

La migration vers le cœur VMware réglementé n'utilise que les outils fournis par la plateforme : 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ée par mois ; le VPN L2 intégré de NSX-T pour l'extension réseau de niveau 2 (une fonctionnalité standard de l'Edge NSX-T, et non un module additionnel sous licence séparée) ; et vMotion intra-cluster. vMotion est uniquement intra-cluster et n'est pas une capacité de mobilité en direct inter-sites. Les charges de travail sans chemin natif VMware sont relogées par conversion et téléversement d'image, et les bases de données migrent par déchargement et restauration, car le Backup Service ne couvre pas les bases de données gérées.

Résumé de la décision

L'élément porteur de l'architecture de référence est la carte service par service : l'emplacement de chaque composant et la reconnaissance BSI exacte qui la couvre. La conformité est définie par service et par emplacement de centre de données, jamais à l'échelle de la plateforme, si bien que c'est la carte que l'auditeur consulte. 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 périmètres varient selon le service. IONOS CLOUD est le premier fournisseur de cloud allemand à détenir les deux.

Deux règles de lecture régissent ce tableau. Premièrement, « dans le périmètre » signifie que le service nommé dans les centres de données allemands bénéficie de cette reconnaissance BSI ; cela n'autorise jamais une affirmation à l'échelle de la plateforme. C5 couvre exactement Compute Engine, Cloud Cubes et S3 Object Storage ; IT-Grundschutz couvre exactement Compute Engine, S3 Object Storage, Backup et Managed Kubernetes. Les deux périmètres divergent : Cubes sont couverts par C5 mais pas par IT-Grundschutz, tandis que Managed Kubernetes et Backup sont couverts par IT-Grundschutz mais pas par 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 juridiction de l'UE, ce qui est une propriété de l'opérateur et non simplement de la région.

Les deux erreurs de composition à vérifier dans la conception assemblée consistent à associer des primitives incompatibles (par exemple, s'attendre à ce qu'un NSG protège un équilibreur managé, ou utiliser un Cross-Connect pour relier deux VDC situés dans des régions différentes) et à placer un service fonctionnellement correct hors de son périmètre d'attestation requis (par exemple, exécuter un traitement réglementé exigeant 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é comme un système unique : un chemin en couches, allant du public L7 au privé L4, au-dessus d'une couche de calcul sans état et d'une plateforme de données privée, avec un noyau VMware dédié au traitement réglementé, Managed Kubernetes pour les conteneurs, une couche IA par défaut basée sur l'inférence managée, et des liens hybrides qui la relient aux installations de FinCorp. La haute disponibilité, l'équilibrage de charge, la sécurité et la connectivité ne sont pas des fonctionnalités isolées dans des boîtes, mais des préoccupations qui traversent chaque couche, et le jeu de substitutions natives est ce qui comble les lacunes que la plateforme ne propose pas délibérément en tant que produits managés. Le placement par service et la carte de conformité sont les artefacts qui rendent la conception défendable lors d'un 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'y rattache, et la segmentation ainsi que le principe par défaut de confidentialité 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 couches à partir de primitives de la plateforme, et non livrée par un seul produit.
• Le jeu de substitutions natives est réalisé de bout en bout : routage API via ALB et ingress, mise à l'échelle en lecture via cache, basculement via les vérifications d'état des cibles de l'équilibreur de charge sur des finaux zonés, CDC via Kafka, importation de VM via conversion d'image, accès via groupes et autorisations.
• La conformité est propre à chaque service et à chaque 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 périmètres de services différents, et la carte de placement encode les deux.
• Le noyau VMware réglementé n'utilise que VCDA, VPN L2 NSX-T et vMotion intra-cluster ; il n'y a pas de mobilité en direct inter-sites, et les bases de données sont migrées par déchargement et restauration.

Lectures complémentaires

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