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. Las APIs Service Management y Service Control te permiten gestionar y aplicar la limitación de frecuencia.

Configurar límites de frecuencia

Para usar la función de limitación de frecuencia, configura _quota metrics_ y _quota limits_ en la configuración del servicio de tu proyecto de productor de servicios.

Actualmente, el límite de frecuencia admitido es el número de solicitudes por minuto y por consumidor de servicios, donde el consumidor de servicios es un Google Cloud proyecto identificado por una clave de API, un ID de proyecto o un número de proyecto. En el caso de la limitación de frecuencia, el concepto de solicitud es opaco. Un servicio puede elegir una solicitud HTTP como solicitud o un byte de carga útil como solicitud. La función de limitación de frecuencia es independiente de la semántica de una solicitud.

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). Por el momento, el único tipo de límite de cuota admitido es 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 del servicio, si existe, pero no la anulación del consumidor del servicio.
• El mínimo entre el valor de sustitución del consumidor del servicio y el límite predeterminado si hay un valor de sustitución del consumidor del servicio, pero no del productor del servicio.
• El mínimo(anulación del consumidor de servicios, anulación del productor de servicios) si hay anulaciones tanto del productor como del consumidor de servicios.

Aplicar límites de frecuencia

Para aplicar la limitación de frecuencia, cada servidor que pertenezca a un servicio gestionado debe llamar al método services.allocateQuota de la API Service Control con regularidad. Si la respuesta del método services.allocateQuota indica que el uso supera el límite, el servidor debe rechazar la solicitud entrante con un error 429. Para obtener más información, consulta la documentación de referencia del 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. Por lo general, un servidor solo debe llamar al método services.allocateQuota una vez por segundo para la misma tupla (servicio, consumidor, métrica).

En el siguiente ejemplo se muestra cómo llamar al método services.allocateQuota para comprobar si se ha aplicado la limitación 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 especificada para la tupla (servicio, consumidor, métrica). Si, una vez aumentado, el uso supera el límite, se mostrará un error. En el siguiente ejemplo se usa el comando gcurl para mostrar la llamada. Para saber cómo configurarlo, consulta la sección Primeros pasos con la 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"
}

Gestión de errores

Si el código de respuesta HTTP es 200 y la respuesta contiene RESOURCE_EXHAUSTED QuotaError, tu servidor debe rechazar la solicitud con 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 de los demás errores de cuota, tu servidor debe rechazar la solicitud 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 registrarlo y aceptar las solicitudes de ingresos. 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, tu servicio debe ignorar los errores 500, 503 y 504 sin volver a intentarlo. 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.