Partizioni ad accesso frequente in Archiviazione BLOB di Azure: rilevamento, monitoraggio e mitigazione

Archiviazione BLOB di Azure distribuisce i dati tra le partizioni per garantire prestazioni scalabili. Quando il traffico si concentra su una singola partizione, quest'ultima può diventare un collo di bottiglia, condizione nota come partizione ad accesso frequente. Questo articolo spiega cosa sono le hot partition, come riconoscerle tramite metriche e log di risorse di Monitoraggio di Azure, e quali passi puoi adottare per distribuire il carico in modo più uniforme e ridurre gli errori di throttling.

Informazioni sulle partizioni ad accesso frequente

Archiviazione BLOB di Azure distribuisce automaticamente i dati tra le partizioni per scalare prestazioni e throughput. Quando una singola partizione riceve significativamente più traffico rispetto ad altre partizioni, diventa una partizione hot. Una partizione hot si verifica quando un gran numero di richieste di lettura, scrittura o aggiornamento va alla stessa partizione, limitando la capacità del servizio di bilanciare efficacemente il carico di lavoro. Di conseguenza, le richieste subiscono un aumento della latenza, del throttling e degli errori di timeout finché il carico di lavoro non viene ridistribuito o il modello di accesso ottimizzato. Schemi di partizionamento o denominazione che concentrano il traffico su un piccolo sottoinsieme di dati invece di distribuire le richieste su più partizioni spesso causano partizioni hot.

Sintomi e impatto delle pareti calde

Quando una partizione di storage diventa calda, non può più elaborare le richieste in modo efficiente. Man mano che la partizione si avvicina ai limiti di scalabilità, Archiviazione di Azure inizia a limitare le richieste per proteggere il servizio e mantenere l'affidabilità per altri carichi di lavoro. Le applicazioni client sperimentano maggiore latenza, riduzione della velocità e fallimenti delle richieste transitorie.

I sintomi comuni di una partizione calda includono:

• Risposte HTTP 503 (Server occupato) che indicano che la partizione non è temporaneamente in grado di gestire ulteriori richieste.
• HTTP 500 (Operation Timeout) risponde quando le richieste impiegano troppo tempo a essere completate perché la partizione è sotto forte carico.
• Latenza delle richieste aumentata, anche per richieste che alla fine hanno successo.
• Tentativi automatici dei client, che possono aumentare ulteriormente il traffico e prolungare i problemi di prestazioni se molti client rieseguono i tentativi simultaneamente.
• Throughput ridotto, in cui l'applicazione elabora meno operazioni al secondo del previsto nonostante una capacità complessiva sufficiente dell'account di archiviazione.

Le partizioni hot sono spesso causate da pattern di accesso che concentrano il traffico su una singola partizione. Esempi comuni includono nomi di blob sequenziali, carichi di lavoro con sola aggiunta e schemi di chiavi di partizione che indirizzano una quantità sproporzionata di traffico verso una singola partizione. Quando il carico di lavoro non è distribuito uniformemente, la partizione interessata raggiunge i suoi limiti prima del resto dell'account di storage, creando un collo di bottiglia che influisce sulle prestazioni dell'applicazione.

In molte applicazioni, il primo segnale di una partizione sovraccarica è una combinazione di latenza in aumento, tassi di nuovi tentativi in crescita e un numero crescente di errori 503 o 500 durante i periodi di picco della domanda.

Rileva gli errori di throttling utilizzando metriche e log delle risorse di Monitoraggio di Azure

Archiviazione di Azure limita le richieste quando un carico di lavoro supera gli obiettivi di scalabilità di un account o di una partizione di storage. Il throttling si manifesta in genere con risposte HTTP 503 (Server Busy) o 500 (Operation Timeout). Le librerie client di Archiviazione di Azure ritentano spesso automaticamente le richieste soggette a limitazione, quindi il monitoraggio è essenziale per rilevare il throttling prima che influisca in modo significativo sulle prestazioni dell'applicazione.

Usa le metriche di Monitoraggio di Azure per identificare gli errori di throttling

Per rilevare il throttling, analizza le metriche di Monitoraggio di Azure per un account di storage. La metrica Transazioni , combinata con la dimensione ResponseType , fornisce visibilità sull'esito delle richieste di archiviazione e aiuta a identificare i guasti legati al throttling.

Metriche per identificare la limitazione

Le seguenti metriche di Monitoraggio di Azure sono utili per indagare il throttling:

Uno schema comune di limitazione è un aumento della latenza, accompagnato da un incremento dei tipi di risposta associati alla limitazione e da una diminuzione della disponibilità.

Usare la dimensione ResponseType per identificare la limitazione

La dimensione ResponseType è lo strumento principale per identificare le condizioni di throttling nelle metriche di Monitoraggio di Azure. I valori rilevanti includono:

Monitorare questi valori nel tempo può aiutarti a identificare picchi di throttling transitorio così come problemi di scalabilità sostenuti.

Usare le dimensioni per individuare l'origine della limitazione

Le dimensioni delle metriche di Monitoraggio di Azure possono aiutare a isolare il carico di lavoro responsabile della limitazione:

Ad esempio, se la limitazione si verifica principalmente nelle operazioni PutBlob, il carico di lavoro potrebbe essere a elevata intensità di scrittura. Se una specifica operazione API mostra tassi di throttling elevati, gli sforzi di ottimizzazione possono concentrarsi su quell'operazione piuttosto che sull'intera applicazione.

Analizzare i log delle risorse di Monitoraggio di Azure

Mentre le metriche identificano la presenza di throttling, i log di risorse di Monitoraggio di Azure forniscono dettagli a livello di richiesta che possono aiutare a diagnosticare la causa principale. I log delle risorse catturano sia richieste riuscite che fallite, inclusi throttling, timeout, autorizzazione e errori legati alla rete.

Per Archiviazione BLOB di Azure, i record sono disponibili nella tabella StorageBlobLogs dopo che i log delle risorse sono stati inviati a uno spazio di lavoro Log Analytics.

Eseguire query sui log delle risorse per eventi di limitazione

Prima di eseguire queste query, assicurati che i log delle risorse vengano inviati a uno spazio di lavoro Log Analytics.

Usa Kusto Query Language (KQL) per identificare le richieste che restituiscono codici di stato comuni associati al throttling:

StorageBlobLogs
| where StatusCode in (500, 503)
| summarize RequestCount = count() by OperationName, StatusCode, bin(TimeGenerated, 15m)
| order by TimeGenerated desc

Estendi questa query raggruppando i risultati per operazione, tipo di autenticazione, indirizzo IP del chiamante o identità dell'applicazione per identificare il carico di lavoro che genera richieste limitate. I log delle risorse sono particolarmente utili per determinare se la limitazione è concentrata in un'applicazione, un'operazione o un intervallo di tempo specifico.

Condizioni di allerta per la limitazione

Creare avvisi di Monitoraggio di Azure per:

• Occorrenze prolungate di transazioni con errore ServerBusyError.
• Aumenti dei valori ResponseType correlati alla limitazione.
• La metrica di Disponibilità scende sotto una soglia accettabile.
• Aumenti della latenza che si correlano con eventi di throttling.
• Aumenti improvvisi del volume di richieste che si avvicinano ai limiti di scalabilità dello storage.

Flusso di lavoro di monitoraggio consigliato

1. Monitora la metrica Transazioni e suddividi i risultati per ResponseType.
2. Verificare l'aumento dei tipi di risposta correlati al throttling, ad esempio ServerBusyError e ClientThrottlingError.
3. Usa la dimensione ApiName per identificare le operazioni interessate.
4. Correlare gli eventi di limitazione con modifiche in Disponibilità, Latenza end-to-end richieste riuscite e Latenza server operazioni riuscite.
5. Usa i log delle risorse di Monitoraggio di Azure per determinare quali richieste, operazioni o applicazioni generano traffico limitato.
6. Configura gli avvisi in modo che i problemi di throttling vengano rilevati prima che riguardino gli utenti.

Combinando metriche, dimensioni e log delle risorse di Monitoraggio di Azure, puoi rilevare rapidamente le condizioni di throttling, identificare la fonte della domanda eccessiva e adottare azioni correttive prima che le prestazioni dell'applicazione peggiorino.

Ridurre le partizioni con elevato carico

Per prevenire partizioni surriscaldate, distribuire le richieste in modo equilibrato tra le partizioni e assicurarsi che le applicazioni rispondano adeguatamente quando si verifica il throttling.

Usa schemi efficienti di partizionamento e denominazione

Progetta chiavi di partizione, nomi di blob e altri identificatori in modo che le richieste siano distribuite su più partizioni. Evita schemi di denominazione sequenziali o basati solo su accodamento che convogliano la maggior parte delle richieste verso la stessa partizione. Vedi Ottimizza partizioni blob e schemi di denominazione.

Usare il backoff incrementale per le ripetizioni dei tentativi

Se le richieste vengono limitate e restituiscono errori 503 (Server occupato) o 500 (Timeout dell'operazione), ritentare le richieste utilizzando una strategia di backoff esponenziale. Questo approccio riduce la pressione sulla partizione interessata e dà ad Archiviazione di Azure il tempo di riequilibrare il carico o di recuperare da picchi temporanei di domanda.

Il comportamento di ripetizione dei tentativi con backoff esponenziale è particolarmente rilevante per le applicazioni personalizzate che accedono ad Archiviazione di Azure tramite librerie client, SDK o API REST di Archiviazione di Azure. Molti servizi Microsoft, applicazioni gestite e client di terze parti implementano già una logica appropriata di ripetizione dei tentativi, quindi potresti non dover configurare nulla di aggiuntivo. Se stai sviluppando un'applicazione personalizzata, assicurati che le politiche di ritentativi siano abilitate e configurate secondo le migliori pratiche di Archiviazione di Azure. Vedere uno di questi articoli:

• Implementa una politica di ritentativi per .NET
• Implementa una politica di ritentativi per Java
• Implementa una policy di ritentazione per JavaScript
• Implementa una politica di ritentativi per Python
• Implementare un criterio di ripetizione dei tentativi per Go

Evitare improvvisi picchi nel volume delle richieste

Quando si introduce un nuovo carico di lavoro, si esegue test di prestazioni o si elaborano grandi quantità di dati, aumentare gradualmente i tassi di richiesta invece di generare immediatamente picchi di traffico. Archiviazione di Azure bilancia automaticamente le partizioni man mano che cambia la domanda, ma picchi improvvisi di traffico possono temporaneamente sovraccaricare una partizione e causare un throttling finché il servizio non ha l'opportunità di adattarsi.

Passaggi successivi

Per indicazioni dettagliate sull'implementazione, vedi:

• Scalabilità e obiettivi di prestazioni per Archiviazione di Azure
• Ottimizzare le partizioni blob e gli schemi di denominazione
• Monitorare Archivio BLOB di Azure
• Le migliori pratiche per il monitoraggio di Archiviazione BLOB di Azure
• Metriche di Monitoraggio di Azure e documentazione di riferimento dei log delle risorse per Archiviazione di Azure
• Elenco di controllo delle prestazioni per Archiviazione BLOB di Azure
• Elenco di controllo delle prestazioni per gli sviluppatori (Archiviazione BLOB di Azure)