Une plateforme d'analyse multi-tenant utilise AKS pour deux charges de travail : (1) un niveau API toujours actif avec un trafic stable et (2) de gros traitements par lots nocturnes qui peuvent tolérer des redémarrages. Azure SQL Database et un portail d'administration basé sur App Service fonctionnent 24h/24 et 7j/7 et ont une utilisation prévisible. La direction exige une réduction de 30 % des coûts de calcul sans impacter les SLO. Quelles sont les deux recommandations qui répondent le mieux à cet objectif ?

L'ajout d'un pool de nœuds Spot AKS dédié aux traitements par lots nocturnes permet de réduire considérablement les coûts pour une charge de travail tolérante aux interruptions. L'utilisation de PodDisruptionBudgets et de tolérances, ainsi que le checkpointing, garantissent que les traitements peuvent redémarrer sans perte de données, respectant ainsi les SLO. L'achat d'instances réservées d'un an pour Azure SQL Database et le plan App Service, qui ont une utilisation stable et prévisible, offre des économies substantielles sur les coûts de calcul sans affecter la disponibilité. Mettre à l'échelle le cluster AKS à zéro pendant les heures ouvrables interromprait l'API toujours active. Migrer l'API vers des machines virtuelles B-series n'est pas adapté à une API "toujours active" avec un trafic stable, car les performances pourraient être imprévisibles. Désactiver l'autoscaling pourrait entraîner des problèmes de performance ou des coûts excessifs si la demande augmente.