Limitar el consumo

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 Administración de servicios y Control de servicios te permiten administrar y aplicar límites de frecuencia.

Cómo configurar los límites de tasa

Para usar la función de límite de frecuencia, configure _quota metrics_ y _quota limits_ en la configuración del servicio de su proyecto de productor de servicio.

Actualmente, el límite de frecuencia admitido es el número de solicitudes por minuto por consumidor de servicio, y el consumidor de servicio es un proyecto de Google Cloud identificado por 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 elegir una solicitud HTTP o un byte de carga útil como solicitud. La función de límite de frecuencia es independiente de la semántica de una 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 tipo de límite de cuota admitido es por minuto por consumidor, en particular, 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 tasas

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 Service Control periódicamente. Si la respuesta del método services.allocateQuota indica que el uso está por encima del 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 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).

El siguiente ejemplo muestra 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 cantidad especificada para la tupla (servicio, consumidor, métrica). Si el aumento del uso supera el límite, se muestra un error. El siguiente ejemplo utiliza el comando de gcurl para demostrar la llamada. Para obtener información sobre cómo realizar la configuración, consulta Comienza a usar la API de 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"
}

Manejo de errores

Si el código de respuesta HTTP es 200, y la respuesta contiene RESOURCE_EXHAUSTED QuotaError, su servidor debe 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, el 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 algún error inesperado, su servicio debe registrar el error y aceptar las solicitudes de ingresos. 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 usas el método services.allocateQuota, tu servicio debe 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 Service Control emite una cantidad limitada de inyección de errores periódicamente.