Modelli di progettazione delle prestazioni per Amazon S3
Nel progettare applicazioni per caricare e recuperare oggetti da Amazon S3, utilizza i nostri schemi di progettazione delle best practice per ottenere prestazioni ottimali per l'applicazione. Offriamo anche Linee guida per le prestazioni di Amazon S3 , che puoi prendere in considerazione quando pianifichi l'architettura dell'applicazione.
Per ottimizzare le prestazioni, puoi utilizzare i seguenti schemi di progettazione.
Argomenti
Utilizzo della cache per i contenuti a cui si accede di frequente
Molte applicazioni che archiviano dati in Amazon S3 fungono da “set di lavoro” dei dati richiesti ripetutamente dagli utenti. Se un carico di lavoro invia richieste GET ripetute per un set comune di oggetti, puoi utilizzare una cache come Amazon CloudFront, Amazon ElastiCache o AWS Elemental MediaStore per ottimizzare le prestazioni. L'adozione corretta di una cache può portare a una bassa latenza e a tassi di trasferimento dei dati più alti. Le applicazioni che utilizzano il caching inviano anche meno richieste dirette ad Amazon S3, riducendo i costi delle richieste.
Amazon CloudFront è una rete di distribuzione di contenuti veloce che esegue il caching trasparente dei dati da Amazon S3 in un set di punti di presenza distribuiti in varie regioni di grandi dimensioni. Quando gli oggetti sono accessibili da più regioni o su Internet, CloudFront permette il caching dei dati vicino agli utenti che accedono a tali oggetti. In questo modo, è possibile distribuire contenuti Amazon S3 comuni con prestazioni elevate. Per ulteriori informazioni su CloudFront, consulta la Guida per gli sviluppatori di Amazon CloudFront.
Amazon ElastiCache è una cache in memoria gestita. Con ElastiCache, puoi effettuare il provisioning di istanze Amazon EC2 che eseguono il caching di oggetti in memoria. Il caching porta alla riduzione di grandezza della latenza GET e ad aumenti sostanziali nel throughput del download. Per utilizzare ElastiCache, devi modificare la logica dell'applicazione in modo da popolare la cache con oggetti ad accesso frequente e controllare la presenza di tali oggetti nella cache prima di richiederli da Amazon S3. Per alcuni esempi di utilizzo di ElastiCache per migliorare le prestazioni delle richieste GET in Amazon S3, consulta il post di blog relativo al potenziamento di Amazon S3 con Amazon ElastiCache for Redis
AWS Elemental MediaStore è un sistema di caching e distribuzione di contenuti progettato appositamente per flussi di lavoro video e distribuzione di contenuti multimediali da Amazon S3. MediaStore fornisce API di storage end-to-end specifiche per i contenuti video ed è consigliato per carichi di lavoro video sensibili alle prestazioni. Per ulteriori informazioni su MediaStore, consulta la Guida per l'utente di AWS Elemental MediaStore.
Timeout e retry per applicazioni sensibili alla latenza
In alcune situazioni un'applicazione riceve una risposta da Amazon S3 che indica che è necessario un nuovo tentativo. Amazon S3 mappa i nomi dei bucket e degli oggetti ai dati degli oggetti a essi associati. Se un'applicazione genera alti tassi di richiesta (in genere tassi sostenuti di oltre 5.000 richieste al secondo per un piccolo numero di oggetti) potrebbe ricevere risposte di rallentamento HTTP 503. Se si verifica questo errore, ogni SDK AWS implementa la logica di tentativo automatica utilizzando il backoff esponenziale. Se non stai utilizzando un SDK AWS, quando ricevi un errore HTTP 503 è necessario implementare la logica di tentativo. Per informazioni sulle tecniche di back-off, consulta Comportamento del tentativo nella Guida di riferimento agli SDK e agli strumenti di AWS.
Amazon S3 si ridimensiona automaticamente in risposta a nuovi tassi di richiesta prolungati, ottimizzando dinamicamente le prestazioni. Mentre Amazon S3 ottimizza internamente per sostenere un nuovo tasso di richieste, riceverai temporaneamente risposte di richiesta HTTP 503 fino al completamento dell'ottimizzazione. Dopo che Amazon S3 ha ottimizzato internamente le prestazioni per il nuovo tasso di richiesta, tutte le richieste vengono in genere gestite senza nuovi tentativi.
Per le applicazioni sensibili alla latenza, Amazon S3 consiglia di monitorare e ritentare in modo aggressivo le operazioni più lente. Nel ritentare una richiesta, consigliamo di utilizzare una nuova connessione ad Amazon S3 e di eseguire una nuova ricerca DNS.
Quando effettui richieste di dimensioni grandi e variabili (ad esempio, oltre 128 MB), consigliamo di tracciare il throughput raggiunto e di ritentare il 5 percento più lento delle richieste. Quando effettui richieste più piccole (ad esempio, meno di 512 KB) dove le latenze medie sono spesso dell'ordine di decine di millisecondi, una buona linea guida è ritentare un'operazione GET o PUT dopo 2 secondi. Se sono necessari tentativi aggiuntivi, la best practice è di effettuare il backoff. Ad esempio, consigliamo di emettere un tentativo dopo 2 secondi e un secondo tentativo dopo 4 secondi aggiuntivi.
Se l'applicazione effettua richieste a dimensione fissa ad Amazon S3, il tempo di risposta per ogni richiesta sarà più costante. In questo caso, una strategia semplice è identificare l'1 percento più lento delle richieste e ritentarle. Anche un singolo tentativo è efficace nella riduzione della latenza.
Se si utilizza AWS Key Management Service (AWS KMS) per la crittografia lato server, consulta Quote nella Guida per gli sviluppatori di AWS Key Management Service per informazioni sulle frequenze di richiesta supportate per il caso d’uso in uso.
Scalabilità orizzontale e parallelizzazione delle richieste per un elevato throughput
Amazon S3 è un sistema distribuito di dimensioni molto grandi. Per sfruttarne a pieno la capacità di dimensionamento, consigliamo di ridimensionare orizzontalmente le richieste parallele agli endpoint del servizio Amazon S3. Oltre a distribuire le richieste in Amazon S3, questo tipo di approccio al dimensionamento permette di distribuire il carico su più percorsi nella rete.
Per i trasferimenti a throughput elevato, Amazon S3 consiglia di utilizzare applicazioni che usano più connessioni a dati GET o PUT in parallelo. Ad esempio, questo approccio è supportato da Amazon S3 Transfer Manager nell'SDK Java AWS e la maggior parte degli altri SDK AWS offre costrutti simili. Per alcune applicazioni, puoi raggiungere connessioni parallele lanciando simultaneamente richieste multiple in diversi thread dell'applicazione o in diverse istanze dell'applicazione. Il miglior approccio da adottare dipende dall'applicazione e dalla struttura degli oggetti a cui accedi.
Puoi utilizzare gli SDK AWS per emettere direttamente richieste GET e PUT anziché impiegare la gestione dei trasferimenti negli SDK AWS. Questo approccio ti permette di ottimizzare il carico di lavoro in modo più diretto senza rinunciare al supporto degli SDK per i tentativi e la gestione delle risposte HTTP 503 che potrebbero verificarsi. Come regola generale, quando scarichi oggetti di grandi dimensioni all'interno di una regione da Amazon S3 ad Amazon EC2, consigliamo di effettuare richieste simultanee di intervalli di byte di un oggetto in base a una granularità di 8–16 MB. Effettua una richiesta simultanea per ogni 85–90 MB/s di throughput di rete desiderato. Per saturare una network interface card (NIC) da 10 Gb/s, devi utilizzare circa 15 richieste simultanee su connessioni separate. Puoi scalare le richieste simultanee su più connessioni per saturare più rapidamente le NCI, come quelle da 25 Gb/s o 100 Gb/s.
La misurazione delle prestazioni è importante quando ottimizzi il numero di richieste da emettere simultaneamente. Consigliamo di iniziare con un richiesta alla volta. Misura la larghezza di banda della rete raggiunta e l'uso delle altre risorse che la tua applicazione utilizza nell'elaborazione dei dati. Puoi quindi identificare la risorsa con un collo di bottiglia (ossia, la risorsa con l'utilizzo più elevato) e di conseguenza il numero di richieste che possono essere utili. Ad esempio, se elaborare una richiesta alla volta porta a un utilizzo della CPU del 25 percento, questo dato suggerisce che possono essere emesse fino a quattro richieste simultanee. La misurazione è essenziale ed è utile per confermare l'utilizzo della risorsa quando il tasso di richiesta aumenta.
Se l'applicazione invia richieste direttamente ad Amazon S3 utilizzando l'API REST, ti consigliamo di utilizzare un pool di connessioni HTTP e di riutilizzare ogni connessione per una serie di richieste. Evitare la configurazione della connessione per richiesta elimina la necessità di eseguire handshake slow-start su TCP e Secure Sockets Layer (SSL) su ogni richiesta. Per informazioni sull'utilizzo dell'API REST, consulta la Documentazione di riferimento delle API di Amazon Simple Storage Service.
Infine, è utile considerare con attenzione DNS e verificare accuratamente che le richieste vengano distribuite su un ampio pool di indirizzi IP di Amazon S3. Le query DNS per Amazon S3 passano per un elenco di grandi dimensioni di endpoint IP. Ma effettuare il caching dei resolver o del codice dell'applicazione che riutilizza un singolo indirizzo IP non trae vantaggio dalla diversità degli indirizzi e dal bilanciamento del carico che ne deriva. Utilità di rete come lo strumento a riga di comando netstat possono mostrare gli indirizzi IP utilizzati per la comunicazione con Amazon S3 e forniamo linee guida per le configurazioni DNS da utilizzare. Per ulteriori informazioni su queste linee guida, consulta la sezione Esecuzione di richieste nella documentazione di riferimento delle API di Amazon S3.
Utilizzo di Amazon S3 Transfer Acceleration per accelerare i trasferimenti di dati geograficamente eterogenei
Configurazione di trasferimenti veloci e sicuri di file con Amazon S3 Transfer Acceleration è efficace nel ridurre o eliminare la latenza causata dalla distanza geografica tra client lontani a livello globale e un'applicazione locale che utilizza Amazon S3. Transfer Acceleration utilizza le edge location distribuite a livello globale in CloudFront per il trasferimento dei dati. La rete edge AWS dispone di punti di presenza in oltre 50 località. Oggi viene utilizzata per distribuire contenuti tramite CloudFront e per offrire risposte rapide a query DNS eseguite su Amazon Route 53.
La rete edge permette anche di accelerare i trasferimenti dei dati da e verso Amazon S3. È ideale per le applicazioni che trasferiscono i dati tra continenti, dispongono di connessioni a Internet veloci e utilizzano oggetti di grandi dimensioni o hanno molti contenuti da caricare. Quando arrivano in una edge location, i dati vengono instradati ad Amazon S3 su un percorso di rete ottimizzato. In generale, più lontano ti trovi da una regione Amazon S3, maggiore è il miglioramento della velocità che otterrai utilizzando Transfer Acceleration.
Puoi configurare Transfer Acceleration su bucket nuovi o esistenti. Puoi utilizzare un endpoint Amazon S3 Transfer Acceleration separato per utilizzare le edge location AWS. Il modo migliore per verificare se Transfer Acceleration migliora le prestazioni delle richieste client consiste nell'utilizzare lo strumento Speed Comparison di Amazon S3 Transfer Acceleration
Ottimizzazione per carichi di lavoro a elevata frequenza di richieste
Le applicazioni che generano frequenze di richiesta elevate ad Amazon S3 richiedono modelli di progettazione specifici per ottenere prestazioni ottimali. Quando l’applicazione genera costantemente più di 3.500 richieste PUT/COPY/POST/DELETE o 5.500 richieste GET/HEAD al secondo per prefisso, è necessario implementare strategie per distribuire le richieste e gestire il comportamento di dimensionamento.
Amazon S3 scala automaticamente le risorse per soddisfare frequenze di richiesta più elevate, ma questo dimensionamento avviene gradualmente. Durante il processo di dimensionamento, potresti ricevere risposte HTTP 503 (Slow Down). Queste risposte sono temporanee e indicano che Amazon S3 sta ottimizzando i sistemi interni per il nuovo modello di richiesta. Una volta completato il dimensionamento, le richieste verranno eseguite senza limitazione (della larghezza di banda della rete).
Per ottimizzare le prestazioni per i carichi di lavoro con frequenza di richiesta elevata, considera le seguenti strategie:
-
Distribuisci le richieste su più prefissi: utilizza un modello di prefisso randomizzato o sequenziale per distribuire le richieste su più partizioni. Ad esempio, invece di utilizzare nomi di oggetti sequenziali come
log-2024-01-01.txt, utilizza prefissi randomizzati comea1b2/log-2024-01-01.txt. Questo aiuta Amazon S3 a distribuire il carico in modo più efficace. -
Implementa il backoff esponenziale per gli errori 503: quando ricevi risposte HTTP 503, implementa la logica dei tentativi con backoff esponenziale. Inizia con un breve ritardo e aumenta gradualmente il tempo di attesa tra un tentativo e l’altro. Gli AWS SDK includono una logica dei tentativi integrata che gestisce automaticamente questo comportamento.
-
Monitora i modelli di richiesta: utilizza le metriche di Amazon CloudWatch per monitorare le frequenze di richiesta e i tassi di errore. Presta particolare attenzione alle metriche degli errori 5xx, che possono indicare quando l’applicazione sta raggiungendo o superando gli attuali limiti di dimensionamento.
-
Aumenta gradualmente la frequenza di richiesta: quando si avviano nuove applicazioni o aumenta significativamente la frequenza di richiesta, è opportuno aumentare gradualmente il traffico nel tempo anziché raggiungere immediatamente le frequenze di picco. Ciò consente ad Amazon S3 di scalare in modo proattivo e riduce la probabilità di limitazione (della larghezza di banda della rete).
-
Utilizza più connessioni: distribuisci le richieste su più connessioni HTTP per massimizzare il throughput e ridurre l’impatto di ogni singolo problema di connessione.
Per le applicazioni che richiedono prestazioni elevate e coerenti, prendi in considerazione l’utilizzo di Amazon S3 Express One Zone, progettato per applicazioni che richiedono latenze nell’ordine di millisecondi e può supportare centinaia di migliaia di richieste al secondo. Per ulteriori informazioni, consulta S3 Express One Zone.
