Límites de frecuencia

Esta página describe cómo utilizar la infraestructura de servicio para implementar límites de tasas en los servicios administrados que estén integrados a la API de Service Management.

Un servicio administrado puede ser útil para muchos consumidores del servicio. Para proteger la capacidad del sistema y asegurar su uso correcto, un servicio administrado a menudo utiliza un límite de tasa para distribuir su capacidad entre los consumidores del servicio. Las API de Service Management y Control de servicios te permiten administrar y aplicar límites de frecuencia.

Cómo configurar los límites de tasa

Para utilizar la característica de límite de frecuencia, configura _quota metrics_ y _quota limits_ en la configuración del servicio para el proyecto del productor de servicios.

Actualmente, el límite de frecuencia admitido es la cantidad de solicitudes por minuto por consumidor de servicios. El consumidor de servicios es un proyecto de Google Cloud Platform identificado con una clave de API, un ID de proyecto o un número de proyecto. Para el límite de frecuencia, el concepto de solicitud es un concepto impreciso. Un servicio puede seleccionar una solicitud HTTP como solicitud, o un byte de carga útil como solicitud. La función de límite de frecuencia es independiente de la semántica de la solicitud.

Métricas de cuota

Una métrica es un contador para medir un determinado valor en el tiempo. Por ejemplo, la cantidad de solicitudes HTTP que recibe un servicio es una métrica. Una métrica de cuota es una métrica que se utiliza para fines de limitaciones de cuota y tasa. Cuando un servicio produce una actividad, una o más métricas de cuota pueden aumentar. Cuando el valor de la métrica alcanza el límite de cuota predefinido, el servicio debe rechazar la actividad con un error 429.

Límites de cuota

Un límite de cuota representa un límite en una métrica de cuota. Por ejemplo, la cantidad de solicitudes por consumidor de servicio por minuto es un límite de cuota. En este momento, el único límite de cuota admitido es por minuto por consumidor, específicamente 1/min/{project}.

El límite de tasa real para un par servicio-consumidor está controlado por 3 configuraciones:

  • El límite predeterminado especificado para el servicio administrado
  • La anulación del productor del servicio para el consumidor del servicio
  • La anulación del consumidor del servicio para el consumidor del servicio

El límite de tasa efectivo es uno de los siguientes:

  • El límite predeterminado si no hay anulación
  • La anulación del productor del servicio, si la hay, pero sin anulación del consumidor de servicios
  • El valor de la anulación del consumidor de servicios o el límite predeterminado, el que sea menor, si hay una anulación del consumidor de servicios, pero no del productor del servicio.
  • El valor de la anulación del consumidor de servicios o del productor del servicio, el que sea menor, si hay una anulación tanto del productor del servicio como del consumidor de servicios.

Cómo aplicar los límites de frecuencia

Para aplicar límites de frecuencia, cada servidor que pertenezca a un servicio administrado debe llamar al método services.allocateQuota de la API de Control de servicios periódicamente. Si la respuesta del método services.allocateQuota indica que el uso supera el límite, el servidor rechazará la solicitud entrante con un error 429. Para obtener más información, consulta la documentación de referencia para el método services.allocateQuota.

Se recomienda que cada servidor utilice lotes, almacenamiento en caché y lógica predictiva para mejorar el rendimiento y la confiabilidad del sistema. En general, un servidor debería llamar al método services.allocateQuota solo una vez por segundo para la misma tupla (servicio, consumidor, métrica).

En el siguiente ejemplo se demuestra cómo llamar al método services.allocateQuota para verificar el límite de frecuencia. Los parámetros de solicitud importantes que se deben configurar correctamente son el nombre del servicio, la ID del consumidor, el nombre de la métrica y el valor de la métrica. El método services.allocateQuota intentará aumentar el uso según la tupla especificada (servicio, consumidor, métrica). Si el aumento del uso supera el límite, se muestra un error. En el siguiente ejemplo se utiliza el comando gcurl para demostrar la llamada. Para obtener información sobre cómo realizar la configuración, consulta Comienza a usar la API de Control de servicios.

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

Manejo de errores

Si el código de respuesta HTTP es 200, y la respuesta contiene RESOURCE_EXHAUSTED QuotaError, el servidor rechazará la solicitud con un error 429. Si la respuesta no contiene ningún error de cuota, tu servidor continuará entregando las solicitudes entrantes. Para todos los demás errores de cuota, tu servidor rechazará las solicitudes con un error 409 . Debido a los riesgos de seguridad, debes tener mucho cuidado con la información de error que incluyas en el mensaje de error.

Para todos los demás códigos de respuesta HTTP, es probable que tu servidor tenga algún error de programación. Se recomienda que tu servidor continúe atendiendo las solicitudes entrantes mientras depuras el problema. Si el método services.allocateQuota muestra un error inesperado, el servicio debe registrar el error y aceptar las solicitudes entrantes. Puedes depurar el error más tarde.

Fail Open

La función de limitación de tasa existe para proteger tu servicio administrado de las sobrecargas y distribuir la capacidad del servicio de manera equitativa entre los consumidores del servicio. Debido a que la mayoría de los consumidores de servicios no llegan a alcanzar el límite de tasa durante las operaciones normales, el servicio administrado aceptará todas las solicitudes entrantes si la función de limitación de tasa no está disponible, también conocido como fail open. Esto evita que la disponibilidad del servicio se vea afectada por el sistema de límites de frecuencia.

Si utilizas el método services.allocateQuota, el servicio ignorará los errores 500, 503 y 504 sin ningún reintento. Para evitar una dependencia excesiva de la característica de límites de frecuencia, la API de Control de servicios emite una cantidad limitada de inyección de errores periódicamente.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…

Service Infrastructure