Limitazione di frequenza

Questa pagina descrive come utilizzare Service Infrastructure per implementare la limitazione della frequenza per i servizi gestiti integrati con l'API Service Management.

Un servizio gestito può gestire numerosi consumer di servizi. Per proteggere la capacità del sistema e garantire un utilizzo corretto, spesso un servizio gestito utilizza la limitazione della frequenza per distribuire la capacità disponibile tra i relativi consumer di servizi. Le API Service Management e Service Control ti consentono di gestire e applicare la limitazione della frequenza.

Configurazione dei limiti di frequenza

Per utilizzare la funzionalità di limitazione della frequenza, configura _quota metrics_ e _quota limits_ nella configurazione del servizio per il progetto produttore di servizi.

Attualmente, il limite di frequenza supportato è il numero di richieste al minuto per consumer di servizi, dove il consumer di servizi è un progetto Google Cloud identificato da una chiave API, un ID progetto o un numero di progetto. Per il limite di velocità, il concetto di richiesta è un concetto opaco. Un servizio può scegliere una richiesta HTTP come o un byte di payload. La funzionalità di limitazione di frequenza indipendenti dalla semantica della richiesta.

Metriche della quota

Una metrica è un contatore specifico che misura un determinato valore nel tempo. Ad esempio, il numero di richieste HTTP ricevute da un servizio è una metrica. Una metrica della quota è una metrica che viene utilizzata ai fini della limitazione della frequenza e della quota. Quando si verifica un'attività in un servizio, una o più metriche della quota possono aumentare. Quando il valore della metrica raggiunge il limite di quota predefinito, il servizio deve rifiutare l'attività restituendo un errore 429.

Limiti di quota

Un limite di quota rappresenta un limite applicabile a una metrica della quota. Ad esempio, il numero di richieste per consumer di servizi al minuto è un limite di quota. In questo momento nel tempo, l'unico tipo di limite di quota supportato è al minuto per consumer, in particolare 1/min/{project}.

Il limite di frequenza effettivo per una coppia (servizio, consumer) è controllato da tre impostazioni:

  • Il limite predefinito specificato per il servizio gestito.
  • L'override del producer di servizi per il consumer di servizi.
  • L'override del consumer di servizi per il consumer di servizi.

Il limite di frequenza effettivo è:

  • Il limite predefinito se non vi è alcun override.
  • L'override del producer di servizi in caso di override del producer di servizi, ma non l'override del consumer di servizi.
  • Il valore minimo(sostituzione consumatore di servizi, limite predefinito) se è presente una sostituzione del consumatore di servizi, ma non una sostituzione del produttore di servizi.
  • Il valore minimo(override del consumer del servizio, override del producer del servizio) se sono presenti override sia del producer del servizio sia del consumer del servizio.

Applicazione della limitazione di frequenza

Per applicare il limite di frequenza, ogni server appartenente a un servizio gestito deve chiamare regolarmente il metodo services.allocateQuota dell'API Service Control. Se la risposta del metodo services.allocateQuota indica che l'utilizzo è superiore al limite, il server deve rifiutare la richiesta in arrivo con un errore 429. Per ulteriori informazioni, consulta il riferimento documentazione per gli amministratori services.allocateQuota .

È consigliabile che ogni server utilizzi la logica di creazione batch, memorizzazione nella cache e predittiva per migliorare l'affidabilità e le prestazioni del sistema. In generale, un server deve chiamare solo services.allocateQuota una volta al secondo per la stessa tupla (servizio, consumer, metrica).

L'esempio seguente mostra come chiamare il metodo services.allocateQuota per controllare la limitazione di frequenza. I parametri della richiesta importanti che devono essere impostati correttamente sono il nome del servizio, l'ID del consumer, il nome della metrica e il valore della metrica. Il metodo services.allocateQuota cercherà di aumentare l'utilizzo dell'importo specificato per la tupla (service, consumer, metric). Se l'utilizzo aumentato supera il limite, verrà restituito un errore. Nell'esempio seguente viene utilizzato il comando gcurl per dimostrare il funzionamento chiamata. Per scoprire come eseguire l'impostazione, consulta: Introduzione all'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"
}

Gestione degli errori

Se il codice di risposta HTTP è 200 e la risposta contiene RESOURCE_EXHAUSTED QuotaError, il tuo server dovrebbe rifiutare la richiesta con un errore 429. Se la risposta non contiene alcun errore relativo alla quota, il server deve continuare a gestire le richieste in entrata. Per tutti gli altri errori di quota, il server deve rifiutare la richiesta con un errore 409. A causa dei rischi per la sicurezza, devi prestare particolare attenzione alle informazioni sull'errore che includi nel messaggio di errore.

Per tutti gli altri codici di risposta HTTP, è probabile che il server presenti alcuni bug di programmazione. È consigliabile che il server continui a gestire le richieste in entrata mentre tu esegui il debug del problema. Se il metodo services.allocateQuota restituisce un errore imprevisto, il servizio deve registrare l'errore e accettare le richieste di reddito. Potrai eseguire il debug dell'errore in un secondo momento.

Fail open

La funzionalità di limitazione della frequenza consente di proteggere il tuo servizio gestito dal sovraccarico e di distribuire la capacità del servizio in modo uniforme tra i consumer di servizi. Poiché la maggior parte dei consumer di servizi non dovrebbe raggiungere i limiti di frequenza durante il normale funzionamento, se la funzionalità di limitazione della frequenza non è disponibile, il servizio gestito deve accettare tutte le richieste in entrata, comportamento noto come fail open. In questo modo, il sistema di limitazione della frequenza non avrà effetti sulla disponibilità del servizio.

Se utilizzi il metodo services.allocateQuota , il servizio deve ignorare gli errori 500, 503 e 504 senza alcun riprova. Per evitare una dipendenza rigida dalla funzionalità di limitazione della frequenza, l'API Service Control esegue regolarmente un numero limitato di test di fault injection.