Vous trouverez sur cette page la procédure à suivre pour limiter le débit des services gérés intégrés à l'API Service Management via la plate-forme Service Infrastructure.
Un service géré peut desservir de nombreux clients du service. Afin de protéger la capacité du système et d'assurer une utilisation équitable, un service géré limite souvent le débit pour répartir sa capacité entre ses clients. Les API Service Management et Service Control permettent de gérer et d'appliquer la limitation du débit.
Configurer les limites de débit
Pour utiliser la fonctionnalité de limitation du débit, configurez _quota metrics_ et _quota limits_ dans la configuration de service liée à votre projet producteur de services.
Actuellement, la limitation de débit acceptée correspond au nombre de demandes par minute par client de service, où le client de service est un projet Google Cloud identifié par une clé API, un identifiant de projet ou un numéro de projet. Le concept de requête est une notion floue en matière de limitation du débit. Un service peut considérer une requête HTTP ou un octet de charge utile comme une requête. La fonctionnalité de limitation du débit est indépendante de la sémantique des requêtes.
Métriques de quota
Une métrique est un compteur spécifique servant à mesurer une certaine valeur au fil du temps. Par exemple, le nombre de requêtes HTTP qu'un service reçoit constitue une métrique. Une métrique de quota est une métrique utilisée pour limiter le quota et le débit. Lorsqu'un service enregistre une activité, une ou plusieurs métriques de quota peuvent augmenter. Lorsque la valeur de la métrique atteint la limite de quota prédéfinie, le service doit rejeter l'activité avec une erreur 429.
Limites de quota
Une limite de quota est une limite applicable à une métrique de quota. Par exemple, le nombre de requêtes par minute et par client du service constitue une limite de quota. Actuellement, la seule limite de quota compatible est la limite par minute et par client, plus précisément 1/min/{project}.
La limite de débit réelle pour une paire service/client est contrôlée par trois paramètres :
- La limite par défaut spécifiée pour le service géré
- Le dépassement défini par le producteur de services pour le client
- Le dépassement défini par le client du service
La limite de débit effective correspond :
- à la limite par défaut si aucun dépassement n'a été défini ;
- au dépassement défini par le producteur de services s'il en a fixé un, mais que le client n'en a défini aucun ;
- à la plus faible valeur entre le dépassement défini par le client du service et la limite par défaut, si le client a fixé un dépassement mais que le producteur de services n'en a défini aucun ;
- à la plus faible valeur entre le dépassement défini par le client du service et celui défini par le producteur de services, si le producteur et le client ont tous deux défini un dépassement.
Appliquer la limitation du débit
Pour appliquer la limitation du débit, chaque serveur appartenant à un service géré doit régulièrement appeler la méthode services.allocateQuota de l'API Service Control. Si la réponse de la méthode services.allocateQuota indique que l'utilisation est supérieure à la limite, le serveur doit rejeter la requête entrante et générer une erreur 429. Pour en savoir plus, consultez la documentation de la méthode services.allocateQuota.
Il est préférable d'adopter une stratégie de regroupement, de mise en cache et de prévision pour chaque serveur afin d'améliorer les performances et la stabilité du système. En général, un serveur ne doit appeler la méthode services.allocateQuota qu'une fois par seconde pour le même tuple (service, client, métrique).
Dans l'exemple suivant, nous vous expliquons comment appeler la méthode services.allocateQuota pour vérifier la limitation du débit. Le nom du service, l'ID du client, le nom de la métrique et la valeur de la métrique doivent être correctement définis. La méthode services.allocateQuota emploie la valeur spécifiée afin d'augmenter l'utilisation pour le tuple (service, client, métrique). Si la nouvelle utilisation dépasse la limite, une erreur est renvoyée. L'exemple suivant démontre l'appel en question à l'aide de la commande gcurl. Pour savoir comment le configurer, consultez la page Premiers pas avec l'API Service Control.
gcurl -d '{
"allocateOperation": {
"operationId": "123e4567-e89b-12d3-a456-426655440000",
"methodName": "google.example.hello.v1.HelloService.GetHello",
"consumerId": "project:endpointsapis-consumer",
"quotaMetrics": [{
"metricName": "endpointsapis.appspot.com/requests",
"metricValues": [{
"int64Value": 1
}]
}],
"quotaMode": "NORMAL"
}
}' https://servicecontrol.googleapis.com/v1/services/endpointsapis.appspot.com:allocateQuota
{
"operationId": "123e4567-e89b-12d3-a456-426655440000",
"quotaMetrics": [
{
"metricName": "serviceruntime.googleapis.com/api/consumer/quota_used_count",
"metricValues": [
{
"labels": {
"/quota_name": "endpointsapis.appspot.com/requests"
},
"int64Value": "1"
}
]
}
],
"serviceConfigId": "2017-09-10r0"
}
Traiter les erreurs
Si le code de la réponse HTTP est 200 et que la réponse contient RESOURCE_EXHAUSTED QuotaError, votre serveur doit rejeter la requête en générant une erreur 429. Si la réponse ne contient aucune erreur de quota, le serveur doit continuer à traiter les requêtes entrantes. Pour toutes les autres erreurs de quota, le serveur doit rejeter la requête avec une erreur 409. Pour des raisons de sécurité, vous devez faire très attention aux informations d'erreur que vous incluez dans le message d'erreur.
Pour tous les autres codes de réponse HTTP, le serveur est sans doute affecté par un bug de programmation. Il est préférable qu'il continue à traiter les requêtes entrantes pendant que vous déboguez le problème. Si la méthode services.allocateQuota affiche une erreur inattendue, le service doit enregistrer l'erreur et accepter les requêtes entrantes. Vous pouvez déboguer l'erreur plus tard.
Configuration ouverte ("fail open")
La fonctionnalité de limitation du débit permet de protéger votre service géré contre les surcharges et de répartir équitablement votre capacité de service entre les clients. Comme la plupart des clients du service n'atteignent pas leurs limites de débit lors d'une utilisation standard, votre service géré doit accepter toutes les requêtes entrantes lorsque la fonctionnalité de limitation du débit n'est pas disponible. C'est ce qu'on appelle le fail open. Cette technique empêche le système de limitation du débit d'affecter votre disponibilité de service.
Si vous appelez la méthode services.allocateQuota, votre service doit ignorer les erreurs 500, 503, et 504 et n'effectuer aucune autre tentative. Pour éviter une trop grande dépendance à la fonctionnalité de limitation du débit, l'API Service Control injecte régulièrement des erreurs en quantité limitée.