Optimisation du fer et des ressources

Résumé succinct

L'optimisation n'est pas « accélérer quelque chose », mais équilibrer les performances ↔ les coûts ↔ la fiabilité ↔ l'énergie. Étapes de base : mesurer le SLI/SLO et les profils, trouver les goulots d'étranglement, « mesurer correctement » la puissance, automatiser la mise à l'échelle et consolider les améliorations dans les images/charts/politiques.

Objectifs et principes

D'UX vers le fer : nous commençons de SLO (p95 latency, le succès des opérations) → nous cherchons la ressource limitant.
Taille correcte (rightsizing) : ressources et types d'instances sous la nature de la charge.
Cache et proximité : réduisez les « chères » randonnées vers le stockage et les réseaux.
Automatisation : autoscaling, politiques de cycle de vie, IaC.
Observabilité : métriques « quatre signaux », profils CPU/alloc, tracing.
Sécurité = performances : mTLS/signatures/limites - avec accélération matérielle si possible.

CPU et planification

Tâches : minimiser le contour et les erreurs de cache, prendre en compte le NUMA et les interruptions.

Conscience NUMA : pinning par nœuds ('numactl --cpunodebind --membind'), pour les OBD/courtiers - fixer sur le nœud.
IRQ/softirq : répartir par noyau (RSS/RPS), fixer les files d'attente pour les CPU sans rivaliser avec les workers.
Hyperthorse : pour les « sensibles à la latence » - fixer les workers sur les noyaux physiques.
Pulls contextuels : réduire à travers les longues files d'attente/batchings/asynchrons.
Compilateurs/JIT : inclure les profils PGO/LTO (C/C + +), Graal/HotSpot (Java), « GOMAXPROCS » et l'attribution de workers (Go).

bash
IRQ affinity: bind NIC queue to specific CPU echo 2 >/ proc/irq/XX/smp_affinity # kernel mask
Softirq balance on sysctl -w net network cores. core. netdev_budget=600 sysctl -w net. core. netdev_max_backlog=5000

Mémoire et gestion des allocations

THP/HugePages : Pour JVM/DB, il est courant de désactiver le THP et d'utiliser les hugepages manuellement (réduit les défauts de TLB).
NUMA-Balance : Pour stateful, fixez la mémoire sur un nœud local.

• JVM : G1/ZGC, '-Xms = -Xmx' égal, raisonnable 'MaxGCPauseMillis'.
• Go : 'GOGC' (commencer par 100-200), éviter les allocations superflues, profils 'pprof'.
• Python : utiliser 'uvloop', 'asyncio', C-extensions, pool de connexions.
• Swap/zswap : sur la vente généralement swap off pour les services critiques ; sur les nœuds à usage général, zswap pour les charges « douces ».

Stockage et I/O

Types de disques : NVMe sous hot-path, pools distincts pour les logs/checapoints/tempo.
FS : XFS pour les gros fichiers/journaux OBD ; ext4 pour les petits/polyvalents.
RAID/EC : RAID10 pour les faibles retards, RAID6/EC pour les données froides.
I/O-planners : 'none '/' mq-deadline' pour NVMe.
Async/Batch : regroupez les entrées, utilisez Write-Behind/Group-Commit.

bash fio --name=randread --filename=/data/test --size=20G --bs=4k \
--iodepth=64 --rw=randread --ioengine=libaio --numjobs=4 --time_based --runtime=60

Réseau

MTU et offload : 9000 MTU au centre de données (si end-to-end), activer le GRO/LRO là où il est permis.
RSS/RPS/RFS : files d'attente multicanaux sur le NIC, distribution par noyau ; irqbalance - sous contrôle.
SO_REUSEPORT : sockets listen évolutifs répartis sur les noyaux.
Temporisation client et pullings : court TCP-keepalive, limite des connexions ouvertes, backpressure.
TLS: TLS 1. 3, instructions matérielles AES-NI, résolution de session, stapling OCSP.

bash sysctl -w net. core. rmem_max=268435456 sysctl -w net. core. wmem_max=268435456 sysctl -w net. ipv4. tcp_rmem="4096 87380 134217728"
sysctl -w net. ipv4. tcp_wmem="4096 65536 134217728"

GPU/FPGA/SmartNIC (le cas échéant)

GPU : Inference antifroda, recommandations, CV ; surveillez 'util', 'mem', 'sm _ efficiency'.
SmartNIC/eBPF/DPDK : déchargement de L4/L7, filtrage, télémétrie sans transition vers le noyau.
Energoprofili : fixer les fréquences à une latence stable ; éviter les power-save agressifs.

Applications et RSUBD

Pools de connexion : limiter 'max _ conn', appliquer connection pooling (PgBouncer/Hikari).
Index/Planificateurs : profils EXPLAIN/ANALYZE couvrant les index, partitionnement.
Cache : Cache Redis/en ligne, CDN pour statique, cache edge pour API « hot ».
Idempotence et files d'attente : éviter les cascades de rétrograves, allumer dedup.
Gzip/Brotli : compression des réponses en tenant compte du coût CPU ; choisissez l'équilibre.

Conteneurs et Kubernetes

Requests/Limits и bin-packing

Requests = « garantie », Limites = « plafond ». Limites incorrectes par CPU → throttling et p99.
Tenez compte des charges de burst (pics de tournois/matchs) - réserve en p95.
Bin-packing : séparez les pools de nœuds (latency-crit, batch, GPU, spot). Utilisez la topologie (anti-affinité, spread).

Mise à l'échelle automatique

HPA par métriques personnalisées (RPS/p95, pas CPU).
VPA pour "долгоживущих" et "non de pique" ворклоадов.
Cluster Autoscaler + groupes de node distincts (on-demand/spot).
KEDA pour les charges d'événements (files d'attente, Kafka, cron).

Planificateur et gestionnaires

CPU Manager : 'static'pour la pinnage des noyaux complets vers les pods critiques de latitude.
Topology Manager : alignement sur NUMA.
HugePages/Plugins d'appareils : pour OBD/faible latence et GPU/FPGA.

yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-gw }
spec:
scaleTargetRef:
apiVersion: apps/v1 kind: Deployment name: api-gw minReplicas: 6 maxReplicas: 60 metrics:
- type: Pods pods:
metric:
name: http_latency_p95_ms target:
type: AverageValue averageValue: 120

FinOps et coût

Profils tarifaires : sélectionnez les instances par CPU/RAM/disque/réseau (compute-optimized, memory-optimized, storage-optimized).
Spot/Preemptible : pour batch/stajing/cache avec redondance multisonienne.
Reservation/Savings : réserves de 1 à 3 ans pour la partie « permanente ».
Chaud/froid : tiered-storage, objet pour les archives, rétentions de logs.
Idle-resource : les arrêts de nuit/week-end des environnements non critiques.

Efficacité énergétique (GreenOps)

Power profiles : performance vs balanced par service.
Co-placement : scellement pendant les heures « froides », désactivation des nœuds inutilisés.
KPI : watt à la demande, p95/watt, CO₂-métrique du fournisseur.

Observabilité et tests

Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Tracing : tracés distribués pour les « sentiers d'or ».
Profilage : eBPF/Perf/Flamegraphs, 'pprof '/YourKit/JFR.
Tests de charge : SLO orienté, avec des opérations mix réelles, une phase de « réchauffage », une injection fault.

promql
CPU throttling доля sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
/ sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)

Network loss sum (rate (node_net_dropped_total[5m])) by (instance)

Chèque d'optimisation

• Les SLO et les « chemins d'or » (API/paiements/paiements) sont définis.
• Profils CPU/alloc/IO/réseaux collectés, goulets d'étranglement trouvés.
• NUMA/IRQ/RSS sont configurés sur les nœuds critiques latins.
• THP off (si nécessaire), hugepages pour les services OBD/Java.
• NVMe sous les données chaudes, XFS/IO-sched configuré, fio-bench confirmé.
• Pile réseau : MTU, RPS/RFS, SO_REUSEPORT ; Taimauts/pools.
• Kubernetes : Demandes correctes, Limites non étouffées, HPA pour les métriques d'entreprise, VPA/CA incluses.
• Mise en cache et CDN sur des chemins « chers » ; Cache Redis/edge.
• FinOps : rightsizing/réserves/pools spot ; arrêt des environnements idle.
• Auto-tests de performance en IC, régression à p95/p99.

Spécificité pour iGaming/fintech

Les pics sont programmés : tournois/matchs/promotions → un pool « élastique » de fronts, avant l'échauffement des caches/CDN, HPA par RPS/latence.
Paiements et décaissements : IP/domaines « or » distincts, files d'attente prioritaires, isolement des ressources (taints/tolerations), réserve par base.
Antibot/antifrod : modèles heavy - sur les workers GPU ; Scoring en ligne ≤ 50 ms p95 ; cache des fiches.
Réglementation : les logs immuables et le cryptage ne doivent pas briser le SLO - activez les accélérations matérielles et les piplines asynchrones.

Mini-playbooks

1. Vérifier le taux de burn SLO ; 2) les profils 'cpu/alloc' ; 3) retour en arrière/fichflag ; 4) augmenter les répliques/cache API ; 5) RCA et fixation du test.

1. Réchauffer le CDN/cache ; 2) soulever minReplicas ; 3) inclure des limites burst ; 4) faire des files d'attente ; 5) activer le mode read-only pour les fonctions mineures.

Erreurs typiques

Les limites du CPU sont « asphyxiées » par les piques de pointe → p99.
Pool de nœuds incorrect : mélange Laticy-critique et batch.
Aucune configuration NUMA/IRQ sur les bases de données/courtiers.
« Traiter les symptômes » (ajouter un CPU) au lieu de corriger les algorithmes/caches/SQL.
L'HPA par CPU au lieu de RPS/latency → scale tard.
Il n'y a pas de tests de performance dans l'IC → la régression dans la vente.

Résultat

L'optimisation est le travail du système : mesurer le SLI/SLO, profiler, corriger les algorithmes, ajuster le fer (NUMA/IRQ/IO/réseau), « mesurer correctement » les ressources et automatiser la mise à l'échelle. Consolidez les améliorations dans les modèles (images, tableaux, politiques), contrôlez les coûts et l'énergie - et votre plate-forme restera rapide, économique et durable même dans les pics extrêmes.