Best practice per latenza delle richieste e gestione degli errori

Questa pagina descrive le best practice per ottimizzare la latenza delle richieste e gestire gli errori nell'API Cloud Healthcare. Implementa queste pratiche durante la pianificazione e la progettazione dell'architettura del sistema.

Google fornisce un accordo sul livello del servizio (SLA) che definisce il tempo di attività previsto del servizio API Cloud Healthcare e la modalità di gestione degli errori da parte dei client. Per ulteriori informazioni, vedi Accordo sul livello del servizio (SLA) di Cloud Healthcare.

Implementare la logica dei nuovi tentativi e i timeout

Per gestire i ritardi e gli errori causati da richieste non riuscite, implementa la logica di ripetizione e i timeout appropriati. Quando imposti la durata del timeout, lascia un tempo sufficiente per svolgere le seguenti operazioni:

• Consenti all'API Cloud Healthcare di elaborare la richiesta.
• Determina se l'errore ha avuto origine dal servizio o dal client.

Puoi riprovare per alcuni errori, ma altri non sono ripetibili e persistono anche dopo più tentativi. Ad esempio, se i dati della richiesta sono formattati in modo errato, il server risponde con un codice di stato 400 Bad Request. La richiesta non riuscire finché non correggi i dati.

Per gestire queste situazioni, devi prevedere gli stati di errore finali.

Per ulteriori informazioni sulla logica dei nuovi tentativi e sui timeout, consulta Riprovare le richieste non riuscite.

Gestire gli errori su più livelli

Quando il middleware interagisce con l'API Cloud Healthcare, implementa la logica per i nuovi tentativi e timeout nel client e nel middleware. Se un client riscontra errori oltre il limite di tentativi, devi essere in grado di identificare se l'errore si è verificato nel client, nel middleware o nel servizio API Cloud Healthcare sottostante. Ciò è particolarmente importante quando e pianificare gli stati di errore finali.

Considera il seguente scenario:

1. Il middleware riceve un errore 500 Internal Server Error dall'API Cloud Healthcare quando invia una richiesta.
2. Il livello middleware riprova la richiesta altre cinque volte, raggiunge il suo limite e poi smette di riprovare.
3. Il client riceve un errore finale 500 Internal Server Error.

È importante capire che l'errore dall'API Cloud Healthcare, non dal middleware. Per semplificare il debug, fornisci queste informazioni nell'errore restituito al client.

Il seguente diagramma mostra uno scenario in cui un proxy middleware riceve errori 500 Internal Server Error durante l'inoltro di una richiesta da un client all'API Cloud Healthcare. Sia il client sia il proxy implementano la gestione degli errori e i tentativi di nuovo invio.

Figura 1. I livelli in cui devi implementare la logica di ripetizione e i timeout sono Client e Proxy.

La figura 1 mostra i seguenti passaggi:

1. Il client invia una richiesta valida all'API Cloud Healthcare tramite un proxy middleware.
2. Il proxy inoltra la richiesta all'API Cloud Healthcare.
3. L'API Cloud Healthcare restituisce un errore 500 Internal Server Error al proxy. Il proxy ritenta la richiesta altre cinque volte fino a quando è stato raggiunto il limite di nuovi tentativi.

4. Il proxy restituisce al client lo stato di errore finale, 500 Internal Server Error.

   Grazie ai consigli mostrati in precedenza, puoi esegui il debug dello stato di errore finale facendo in modo che il proxy restituisca quanto segue. al client:

   Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

   Aggiungi eventuali altre informazioni sull'errore restituito dall'API Cloud Healthcare.

A volte, il client o il proxy riceve errori 500 Internal Server Error dopo aver superato i limiti di ripetizione e non può più riprovare. In questo caso, un essere umano potrebbe dover intervenire per diagnosticare se l'errore proviene dal proxy API Cloud Healthcare.

Scegliere gli errori per cui eseguire nuovamente l'operazione

A seconda dell'architettura del sistema, puoi riprovare per alcune errori e ignora gli altri. Di seguito è riportato un elenco non esaustivo di API Cloud Healthcare riprovabili codici di errore:

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

In genere questi errori non si verificano con la stessa frequenza e alcuni potrebbero non verificarsi mai.

Effetti dell'architettura del sistema

L'architettura del sistema influisce su come e quando riprovare in caso di errori.

Ad esempio, in un'architettura client-server diretta, un client che riceve un errore 401 UNAUTHENTICATED dal L'API Cloud Healthcare può eseguire nuovamente l'autenticazione e riprovare la richiesta.

Supponiamo che un sistema abbia un livello di middleware tra il client e l'API Cloud Healthcare. Se il client si è autenticato correttamente e il problema è stato causato da un token di autenticazione scaduto, il middleware deve aggiornare il token e riprovare a inviare la richiesta.

Dopo aver analizzato gli stati di errore finali, puoi modificare gli errori del client nuovi tentativi in base ai risultati.

Piano per gli stati di errore finali

Anche dopo aver implementato la logica di ripetizione e i timeout, un client o un middleware potrebbe ricevere errori fino a quando non sono stati esauriti i tentativi di ripetizione. L'ultimo errore restituito prima di nuovi tentativi e esauriti è lo stato di errore finale. Potresti riscontrare un errore finale per rilevare eventuali errori di coerenza dei dati.

A volte, uno stato di errore finale richiede l'intervento umano. Prova a implementare una soluzione per risolvere lo stato di errore finale di una richiesta. In caso contrario, registra lo stato di errore finale in modo che una persona possa esaminarlo.

Tieni presente quanto segue quando pianifichi la gestione degli stati di errore finali:

• Indica se sono presenti dipendenze di elaborazione che devono essere interrotte se una transazione o un bundle FHIR non può essere completato correttamente.
• Se molte istanze di macchine virtuali (VM) iniziano a generare errori definitivamente, Il client deve segnalare le richieste non riuscite. Una volta risolto il problema, il cliente deve riprovare a inviare le richieste.
• Il monitoraggio, i sistemi di avviso e gli obiettivi del livello di servizio (SLO) sono necessari per garantire la stabilità del sistema. Per ulteriori informazioni, consulta Testa e monitora.

Pianifica un aumento della latenza

L'API Cloud Healthcare è un servizio scalabile e performante, ma la latenza delle richieste può comunque variare per i seguenti motivi:

• Piccole differenze tra le richieste, anche se sembrano non significative, tempi di elaborazione aggiuntivi.
• Le richieste simili potrebbero avere latenze diverse. Ad esempio, due richieste simili che aggiungono un record all'archiviazione dati hanno latenze diverse se una di queste supera una soglia che attiva ad esempio lo spazio di archiviazione aggiuntivo.
• L'API Cloud Healthcare gestisce molte richieste contemporaneamente. L'ora in cui un client invia una richiesta, misurata in frazioni di secondo, potrebbe coincidere con un periodo in cui l'API Cloud Healthcare è sottoposta a un carico maggiore del solito.
• Se una risorsa fisica dell'API Cloud Healthcare, ad esempio un disco, gestisce molte richieste, deve completare le attività in coda prima di gestire altre richieste.
• A volte l'API Cloud Healthcare ritenta gli errori sul lato server, il che può aumentare per i client.
• Potrebbero esserci più copie dei dati in data center diversi in una località regionale o multiregionale. Se le tue richieste vengono indirizzate su più data center, a seguito della richiesta originale o di un nuovo tentativo, potrebbe verificarsi un aumento della latenza.

Pianificare utilizzando la latenza percentile

Puoi prevedere un aumento della latenza analizzando la latenza percentile delle tue richieste. La I seguenti esempi descrivono la latenza del 50° percentile e Latenza del 99° percentile:

• La latenza del 50° percentile è la latenza massima, in secondi, per il 50% delle richieste più rapide. Ad esempio, se la latenza del 50° percentile è di 0,5 secondi, l'API Cloud Healthcare ha elaborato il 50% delle richieste in 0,5 secondi. La latenza del 50° percentile è detta anche la "latenza mediana".
• La latenza al 99° percentile è la latenza massima, in secondi, per più veloce per il 99% delle richieste. Ad esempio, se la latenza del 99° percentile è di due secondi, l'API Cloud Healthcare ha elaborato il 99% delle richieste entro due secondi.

Se analizzi la latenza percentile in un intervallo in cui l'API Cloud Healthcare ha elaborato solo alcune richieste, la latenza percentile potrebbe non essere utile o indicativa del rendimento complessivo perché le richieste outlier possono avere un'influenza significativa.

Ad esempio, supponiamo che un processo nell'API Cloud Healthcare elabori 100 richieste in 100 minuti. La latenza del 99° percentile per i 100 minuti sulla base della singola richiesta più lenta. Una misurazione della latenza che utilizza una singola richiesta non è sufficiente per capire se ci sono problemi di rendimento.

Raccogliere un campione di richieste più ampio in un periodo di tempo più lungo, ad esempio 24 ore, può fornire maggiori informazioni sul comportamento complessivo del sistema. Puoi utilizzare questi esempi per determinare in che modo il sistema risponde al traffico intenso.