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 limitazione di frequenza.

Configurazione dei limiti di frequenza

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

Attualmente, il limitazione 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 limitazione di frequenza, il concetto di richiesta è un concetto opaco. Un servizio può scegliere una richiesta HTTP come richiesta o un byte di payload come richiesta. La funzionalità di limitazione di frequenza è indipendente dalla semantica di una 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. Al momento, l'unico tipo di limite di quota supportato è per minuto per consumatore, nello specifico 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 se esiste un override del producer di servizi, ma non un override del consumer del servizio.
  • Il valore minimo(sostituzione consumatore di servizi, limite predefinito) se è presente una sostituzione del consumatore di servizi, ma non una sostituzione del producer di servizi.
  • Il valore minimo(override del consumatore di servizi, override del producer di servizi) se sono presenti override sia del producer di servizi sia del consumatore di servizi.

Applicazione della limitazione di frequenza

Per applicare limitazione 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 la documentazione di riferimento per il metodo 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 il metodo services.allocateQuota solo una volta al secondo per la stessa tupla (servizio, consumatore, metrica).

L'esempio seguente mostra come chiamare il metodo services.allocateQuota per verificare la limitazione della 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. L'esempio seguente utilizza il comando gcurl per dimostrare la chiamata. Per scoprire come configurare questa operazione, 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 server deve 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.