Groupes de placement EC2 expliqués : cluster, spread, partition

La plupart des parcs EC2 n’ont pas besoin d’un groupe de placement, et en ajouter un « pour la performance » sans raison mesurée achète surtout de nouveaux modes de défaillance. Ils comptent dans trois situations précises : cluster quand les instances doivent se parler avec la latence la plus basse et le débit le plus haut possible (HPC, calcul étroitement couplé), spread quand une poignée d’instances critiques ne doivent jamais partager de matériel (nœuds de quorum, paires HA), et partition quand un magasin de données distribué comme Kafka, Cassandra ou HDFS doit mapper sa conscience des répliques sur de vrais domaines de panne au niveau des racks.

Ce que vous décidez

Un groupe de placement est une instruction à l’ordonnanceur EC2 sur la façon dont les instances peuvent partager le matériel sous-jacent. Par défaut, AWS place les instances là où la capacité est saine, sans promesse de proximité ni de séparation. Les trois stratégies remplacent ce défaut par un contrat :

Cluster : serrer les instances ensemble — même segment réseau à haute bande passante bissectionnelle, dans une seule zone de disponibilité. Vous obtenez la latence nœud-à-nœud la plus basse et la capacité d’utiliser réellement le haut débit réseau (et EFA, si le type d’instance le supporte) entre membres. Le prix : un rayon d’explosion partagé, et les erreurs de capacité insuffisante deviennent un vrai événement opérationnel, parce qu’AWS doit trouver de la capacité contiguë. Lancer toutes les instances d’un coup, même type, idéalement en une seule requête, c’est le conseil éprouvé.
Spread : le contrat inverse — chaque instance sur des racks distincts avec alimentation et réseau séparés. Limite ferme : sept instances en marche par zone par groupe (on peut couvrir plusieurs zones, sept chacune). Conçu pour de petits ensembles d’instances qui ne doivent pas tomber ensemble : quorums etcd/ZooKeeper, serveurs de licences, paires HA qui autrement partageraient un rack en secret.
Partition : la voie du milieu pour les systèmes distribués. Le groupe est divisé en jusqu’à sept partitions par zone, chaque partition sur des racks isolés; les instances d’une même partition peuvent partager du matériel, mais les partitions jamais. Point crucial : la topologie est visible — les métadonnées d’instance exposent le numéro de partition, alors Kafka peut mapper ses brokers, et Cassandra sa conscience de racks, sur de vraies frontières de panne au lieu d’imaginaires. Les groupes partition montent à des centaines d’instances, contrairement à spread.

Ce que les groupes de placement ne font pas : rien ne traverse les régions, les groupes cluster ne traversent pas les zones, et aucun ne change ce que vous payez — le groupe lui-même est sans frais; le coût se manifeste en exploitation, en flexibilité d’ordonnancement réduite et en risque de capacité. Les détails complets des stratégies sont dans la documentation EC2.

Quoi vérifier en premier

Avez-vous un problème réseau est-ouest mesuré? Les groupes cluster corrigent la latence/le débit inter-nœuds — si votre goulot est le disque, la base de données ou le chemin Internet, ils ne corrigent rien.
L’ensemble « ne doit pas tomber ensemble » compte-t-il sept instances ou moins par zone? C’est le territoire de spread; les ensembles plus grands exigent partition.
Votre magasin de données comprend-il les racks? Les groupes partition ne rapportent que si l’application mappe les répliques sur les partitions (broker.rack, snitch Cassandra, script de racks HDFS).
Les types d’instances sont-ils compatibles? Les groupes cluster veulent des types de génération courante avec bon réseau, et mélanger les types augmente les chances d’échecs de placement.
Pouvez-vous tolérer InsufficientInstanceCapacity au moment de la montée en charge? Les contraintes cluster et spread la rendent plus probable, surtout après des cycles d’arrêt/démarrage.

Comment vérifier

Listez les groupes existants et leurs stratégies :

aws ec2 describe-placement-groups \
  --query 'PlacementGroups[].[GroupName,Strategy,State,PartitionCount]' --output table

Voyez dans quel groupe et quelle partition chaque instance a atterri :

aws ec2 describe-instances \
  --filters "Name=placement-group-name,Values=kafka-prod" \
  --query 'Reservations[].Instances[].[InstanceId,Placement.PartitionNumber,Placement.AvailabilityZone,State.Name]' \
  --output table

Depuis l’intérieur d’une instance, le numéro de partition est disponible via les métadonnées d’instance (IMDSv2), sous le chemin placement/partition-number — c’est ce que les applications conscientes des racks devraient lire au démarrage. Dans la console, EC2 > Network & Security > Placement Groups montre les groupes; l’onglet Details de l’instance montre son groupe et sa partition. Pour les groupes cluster, prouvez le gain avec un iperf3 avant/après entre deux membres — si les chiffres ne bougent pas, le groupe est de la décoration.

L’approche

Par défaut, aucun groupe de placement. Les étages web/app sans état derrière un répartiteur tirent leur résilience de l’Auto Scaling multi-AZ, pas de contrats de placement.
Cluster : créez le groupe, puis lancez tout d’un coup. Même type d’instance, une seule requête de lancement ou une séquence scriptée serrée, tout dans une zone :
```
aws ec2 create-placement-group --group-name hpc-prod --strategy cluster
aws ec2 run-instances --count 8 --instance-type c7gn.8xlarge \
  --placement GroupName=hpc-prod \
  --image-id ami-0abc1234def567890 --key-name ops
```
Si vous frappez des erreurs de capacité, arrêter puis redémarrer tous les membres relocalise parfois le groupe; faire grossir un vieux groupe cluster une instance à la fois est l’échec classique.
Spread : réservez-le aux joyaux de la couronne. Membres de quorum, paires primaire/secours. Respectez le plafond de sept par zone et couvrez plusieurs zones quand la charge le permet.
Partition : dimensionnez les partitions selon votre facteur de réplication. Trois partitions pour du Kafka/Cassandra en RF=3, c’est la forme standard; branchez la conscience de racks de l’application sur le numéro de partition pour qu’une perte de rack coûte une réplique, pas deux.
Mettez le groupe dans le modèle de lancement / la config d’ASG, pas dans la mémoire tribale — les ASG peuvent cibler un groupe de placement, et c’est ainsi que le contrat survit au remplacement d’instances.
Planifiez la capacité explicitement pour les groupes cluster : des réservations de capacité à la demande dans le groupe transforment « espérons que le rack a de la place » en garantie tenue, ce qui compte pour les exécutions HPC planifiées.

Quand c’est le mauvais choix

Un groupe cluster sous une pile de microservices ordinaire concentre votre parc sur de l’infrastructure partagée pour un gain de latence que l’application ne peut pas sentir — vous gardez le rayon d’explosion et sautez le bénéfice. Les groupes spread comme réglage général « plus résilient » cassent à la huitième instance et ajoutent de la friction de capacité; les ASG multi-AZ donnent déjà aux étages ordinaires une meilleure protection. Et si vous vous battez pour des microsecondes à un chiffre, vérifiez d’abord le type d’instance et le support EFA — le placement n’est qu’un terme de cette équation. Les parcs à instances mixtes et lourds en Spot, en particulier, s’accommodent mal des contrats de placement rigides (voir instances mixtes Spot et à la demande).

Erreurs fréquentes

Ajouter des instances à un groupe cluster des mois plus tard et traiter le InsufficientInstanceCapacity résultant comme une panne AWS plutôt que le coût attendu du contrat.
Supposer qu’un groupe partition protège les données tout seul. Il ne fait que créer les domaines de panne; le magasin de données doit être configuré pour placer les répliques à travers eux.
Dépasser les limites de spread en « en ajoutant juste une », ce qui échoue au lancement — découvert pendant une montée en charge d’incident.
Croire que les groupes de placement traversent les régions ou rendent le trafic inter-zones gratuit. Ils ne font ni l’un ni l’autre; le transfert de données inter-zones se facture normalement.

Garder le contrôle

Documentez, à côté de chaque groupe, la raison mesurée de son existence; revalidez la mesure chaque année.
Alarmez sur les échecs de lancement des ASG qui ciblent des groupes de placement — la friction de capacité apparaît là en premier.
Pour les groupes partition, vérifiez au déploiement que les répliques atterrissent vraiment dans des partitions distinctes (une vérification au démarrage qui lit les métadonnées de partition bat un audit plus tard).
Répétez la procédure d’arrêt/redémarrage « relocaliser le groupe cluster » avant d’en avoir besoin sous pression.

Les groupes de placement sont un scalpel : cluster pour les besoins de latence mesurés, spread pour les petits ensembles qui ne doivent rien partager, partition pour les magasins de données conscients des racks — et le défaut honnête, c’est aucun. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.