Dimensionnement App Service

Notions de base

SCEPman dépend principalement des ressources CPU. La mémoire et le disque sont beaucoup moins importants.

Une instance SCEPman (version 3.0 et plus récente) dans un App Service Plan Azure P0V3 (195 ACU) peut servir environ 4000 requêtes par minute dans des conditions habituelles. Les requêtes sont

• Requêtes d'émission SCEP et

• Requêtes OCSP.

Cela signifie que SCEPman peut servir environ 20 requêtes par minute et par ACU.

Puisqu'un certificat est inscrit une seule fois, mais que sa validité est vérifiée de nombreuses fois, il y aura en total beaucoup plus de requêtes OCSP que de requêtes SCEP. Par conséquent, vous devriez dimensionner votre instance SCEPman en fonction de vos requêtes OCSP.

Dépendances

La charge pour votre service SCEPman a plusieurs dépendances et varie selon les environnements. Les dépendances importantes sont :

1. Répartition des requêtes

2. Fréquence des connexions aux ressources réseau

3. Fréquence des demandes/renouvellements de certificats

La répartition des requêtes a une importance particulière. Si tous les clients effectuent des requêtes en même temps, vos instances SCEPman subissent une forte charge. Vous devriez vous efforcer de permettre à SCEPman de répondre aux requêtes SCEP en moins d'une minute dans tous les cas.

Veuillez ne pas attribuer de profils SCEP à un grand nombre d'utilisateurs/appareils en même temps, car cela peut entraîner un pic de requêtes sur vos instances SCEPman.

Recommandation

Nous recommandons le dimensionnement suivant en Azure Compute Units (ACU) pour les App Service Plans Azure comme point de départ :

Nombre d'utilisateurs/clients	Conception unique	Conception géo-redondante
< 5000 clients	~100 ACU (par ex. 1 x S1)	2 x ~100 ACU (par ex. 2 x S1)
< 10.000 clients	~200 ACU (par ex. 1 x P0V3)	2 x ~200 ACU (par ex. 2 x P0V3)
< 25.000 clients	~400 ACU (par ex. 2 x P0V3)	2 x ~400 ACU (par ex. 4 x P0V3)
< 50.000 clients	~800 ACU (par ex. 4 x P0V3)	2 x ~800 ACU (par ex. 8 x P0V3)
< 100.000 clients	~1600 ACU (par ex. 4 x P1V3)	2 x ~1600 ACU (par ex. 8 x P1V3)
> 100.000 clients	~3200 ACU (par ex. 4 x P2V3)	2 x ~3200 ACU (par ex. 2 x 4 x P2V3)

Sur la base de ces recommandations, vous pouvez surveiller votre trafic et voir si vous pouvez réduire la capacité comme décrit dans la section Ajustements fins ci-dessous.

Prévision des coûts Azure

Les principaux coûts Azure concerneront le(s) App Service Plan(s). Vous pouvez déduire votre coût à partir des exigences dans le tableau ci-dessus et votre liste de prix Azure ou le tarification App Service générale.

Les ressources Azure supplémentaires (Key Vault, compte de stockage, Log Analytics, ressources réseau pour points de terminaison privés) jouent un rôle mineur dans le coût. Selon les cas d'utilisation dans votre environnement, vous devriez prévoir 5 % à 25 % supplémentaires en plus du coût de l'App Service Plan pour ces ressources Azure additionnelles.

Cette projection de coût est juste une règle empirique pour vous aider à estimer le coût d'Azure. Elle peut varier de manière significative selon les environnements.

Ajustements fins

Chaque environnement a sa propre répartition de charge au cours de la journée. Dans de nombreux environnements, le matin (début du travail) génère un pic de charge pour votre SCEPman.

Mise à l'échelle manuelle

Vous pouvez adapter la puissance de calcul de votre App Service à votre répartition de charge quotidienne individuelle avec les fonctionnalités de mise à l'échelle d'Azure App Service. Par ex. vous pourriez définir 2 x S1 le matin de 08:00 à 10:00 pour couvrir le pic matinal, tandis que vous réduisez à 1 x S1 pour le reste de la journée.

Mise à l'échelle automatique

Alternativement, vous pouvez utiliser la fonctionnalité d'autoscaling d'Azure App pour vous adapter aux ressources nécessaires. En savoir plus à ce sujet dans Autoscaling.

Manuelle vs. automatique

Si vous êtes capable de prédire bien votre charge (par ex. dérivée de l'historique de charge), nous recommandons la mise à l'échelle manuelle plutôt que l'automatique, car l'autoscaling doit se comporter de manière prudente (hystérésis) pour éviter des oscillations entre niveaux de mise à l'échelle.