Límite de frecuencia

En esta página se describe cómo utilizar la infraestructura de servicio para implementar un límite de frecuencia en los servicios administrados que están integrados con la API Service Management.

Un servicio administrado puede servir a muchos consumidores de servicios. A fin de proteger la capacidad del sistema y garantizar un uso equitativo, este tipo de servicios suelen utilizar límites de frecuencia para distribuir su capacidad entre los consumidores de servicios. Con las API Service Management y Service Control, puedes gestionar y aplicar dichos límites de frecuencia.

Configurar límites de frecuencia

Para poder usar la función de límite de frecuencia, configura _quota metrics_ y _quota limits_ en la configuración de servicio que se corresponde con tu proyecto de productor de servicios.

Actualmente, el límite de frecuencia admitido es el número de peticiones por minuto y por consumidor de servicios (este último se entiende como un proyecto de Google Cloud Platform, tal y como se identifica con una clave de API, un ID de proyecto o un número de proyecto). A efectos del límite de frecuencia, las peticiones son un concepto opaco. A la hora de elegir las peticiones, un servicio puede decantarse por una petición HTTP o por un byte de carga útil. La función del límite de frecuencia es independiente de la semántica de una petición.

Métricas de cuota

Una métrica es un contador con nombre que sirve para medir un valor determinado a lo largo del tiempo (por ejemplo, el número de peticiones HTTP que recibe un servicio). Por su parte, una métrica de cuota es aquella que se utiliza para limitar la frecuencia y la cuota. Cuando se produce una actividad relacionada con un servicio, pueden aumentar una o más métricas de este tipo. Cuando el valor de la métrica alcanza el límite de cuota predefinido, el servicio debe rechazar la actividad mediante un error 429.

Límites de cuota

El límite de cuota representa un umbral aplicable a una métrica de cuota (por ejemplo, el número de peticiones por consumidor de servicios y por minuto). En este momento, el único tipo que se admite es el límite por minuto y por consumidor (concretamente, 1/min/{project}).

El límite de frecuencia real de un par (ya sea de servicios o de consumidores) está controlado por tres configuraciones:

  • El límite predeterminado que se ha especificado para el servicio administrado.
  • La anulación del productor de servicios para el consumidor de servicios.
  • La anulación del consumidor de servicios para el consumidor de servicios.

Según las condiciones que se den, el límite de frecuencia vigente será uno de los siguientes:

  • El límite predeterminado, si no existe ninguna anulación.
  • La anulación del productor de servicios, si dicha anulación existe pero no la del consumidor de servicios.
  • El mínimo (es decir, la anulación del consumidor de servicios y el límite predeterminado), si hay una anulación del consumidor de servicios pero no del productor de servicios.
  • El mínimo (es decir, la anulación del consumidor de servicios y la anulación del productor de servicios) si hay tanto una anulación del consumidor de servicios como una del productor de servicios.

Aplicar límites de frecuencia

Para aplicar el límite de frecuencia, los servidores que pertenecen a un servicio administrado deben llamar de forma regular al método services.allocateQuota de la API Service Control. Si la respuesta del método services.allocateQuota indica que el uso está por encima del límite, el servidor en cuestión debe rechazar la petición entrante mediante un error 429. Para obtener más información, consulta la documentación de referencia sobre el método services.allocateQuota.

Se recomienda que cada servidor utilice el agrupamiento por lotes, el almacenamiento en caché y la lógica predictiva para mejorar el rendimiento y la fiabilidad del sistema. Generalmente, un servidor solo debe llamar al método services.allocateQuota una vez por segundo en la misma tupla (independientemente de si corresponde al servicio, al consumidor o a la métrica).

En el siguiente ejemplo se muestra cómo llamar al método services.allocateQuota para verificar el límite de frecuencia. Los parámetros importantes de la petición que se deben ajustar correctamente son el nombre del servicio, el ID del consumidor y el nombre y valor de la métrica. El método services.allocateQuota intentará aumentar el uso en la cantidad que se haya especificado para la tupla (que puede ser de servicio, de consumidor o de métrica). Si, una vez aumentado, el uso supera el límite, se mostrará un error.

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"
}

Gestionar errores

Si el código de respuesta HTTP es 200 y dicha respuesta contiene RESOURCE_EXHAUSTED QuotaError, el servidor debería rechazar la petición mediante un error 429. Si la respuesta no contiene ningún error de cuota, el servidor debería seguir administrando las peticiones entrantes. En el caso del resto de errores de cuota, el servidor debe rechazar la petición con un error 409. Te recomendamos que tengas mucho cuidado con la información que incluyas en el mensaje de error, ya que podría implicar riesgos de seguridad.

Si obtienes un código de respuesta HTTP que no sea el anterior, es probable que tu servidor tenga algún fallo de programación. En ese caso, lo más recomendable es que dicho servidor siga administrando las peticiones entrantes mientras depuras el problema en cuestión. Si el método services.allocateQuota devuelve un error inesperado, tu servicio debe registrar el error y aceptar las peticiones entrantes; podrás depurarlo más tarde.

Sistema "fail open" o de apertura en caso de fallo

La función de límite de frecuencia sirve para evitar que el servicio administrado se sobrecargue y distribuir su capacidad de manera equitativa entre sus consumidores. Dado que la mayoría de los consumidores de servicios no deberían alcanzar sus límites de frecuencia con un funcionamiento normal, tu servicio administrado debería aceptar todas las peticiones entrantes si la función de límite de frecuencia no está disponible; esto se denomina fail open o "apertura en caso de fallo". Gracias a esta función, la disponibilidad del servicio no se ve afectada por el sistema de limitación de frecuencia.

Si usas el método services.allocateQuota, el servicio debe ignorar los errores 500, 503 y 504 sin ningún tipo de operación de reintento. Para no depender en exceso de la función de límite de frecuencia, la API Control Service realiza una cantidad limitada de inserción de errores de forma regular.

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Service Infrastructure