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.

Utilizzo della cache per i contenuti a cui si accede di frequente

Molte applicazioni che archiviano dati in Amazon S3 servono un «set di lavoro» di dati che viene richiesto 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 ElastiCache, Amazon o AWS Elemental MediaStoreper 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 rapida dei contenuti (CDN) che memorizza in modo trasparente nella cache i dati di Amazon S3 in un ampio set di punti di presenza distribuiti geograficamente (). PoPs Quando è possibile accedere agli oggetti da più regioni o tramite Internet, CloudFront consente di memorizzare i dati nella cache in prossimità degli utenti che accedono agli oggetti. In questo modo, è possibile distribuire contenuti Amazon S3 comuni con prestazioni elevate. Per informazioni in merito CloudFront, consulta l'Amazon CloudFront Developer Guide.

Amazon ElastiCache è una cache gestita in memoria. Con ElastiCache, puoi effettuare il provisioning di EC2 istanze Amazon che memorizzano oggetti nella cache. Il caching porta alla riduzione di grandezza della latenza GET e ad aumenti sostanziali nel throughput del download. Per utilizzarlo ElastiCache, è necessario modificare la logica dell'applicazione per popolare la cache con oggetti caldi e verificare la presenza di oggetti caldi nella cache prima di richiederli da Amazon S3. Per esempi di utilizzo ElastiCache per migliorare le prestazioni di Amazon S3 GET, consulta il post sul blog Turbocharge Amazon S3 con Amazon for Redis. ElastiCache

AWS Elemental MediaStore è un sistema di caching e distribuzione dei contenuti creato specificamente per i flussi di lavoro video e la distribuzione di contenuti multimediali da Amazon S3. MediaStore fornisce uno end-to-end spazio di archiviazione APIs specifico per i video ed è consigliato per carichi di lavoro video sensibili alle prestazioni. Per informazioni in merito MediaStore, consulta la Guida per l'utente.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 Retry behavior nella AWS SDKs and Tools Reference Guide.

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 utilizzi AWS Key Management Service (AWS KMS) per la crittografia lato server, consulta Quotas nella Guida per gli AWS Key Management Service sviluppatori per informazioni sulle frequenze di richiesta supportate per il tuo caso d'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 è supportato da Amazon S3 Transfer Manager nell'SDK AWS Java e la maggior parte degli altri AWS SDKs fornisce 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 il AWS SDKs per emettere direttamente le richieste GET e PUT anziché utilizzare la gestione dei trasferimenti nell'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, ti suggeriamo di effettuare richieste simultanee per intervalli di byte di un oggetto con una granularità compresa tra 8 e 16 MB. Effettua una richiesta simultanea per ogni 85-90% del throughput di rete desiderato. MB/s Per saturare una scheda di interfaccia di Gb/s rete (NIC) da 10, è possibile utilizzare circa 15 richieste simultanee su connessioni separate. È possibile scalare le richieste simultanee su più connessioni per saturarle più velocemente NICs, ad esempio 25 o 100. Gb/s Gb/s NICs

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.

Ottimizzazione per carichi di lavoro ad alta frequenza di richieste

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 per il trasporto dei dati. CloudFront La rete AWS perimetrale ha punti di presenza in più di 50 località. Oggi viene utilizzato per distribuire contenuti CloudFront e fornire risposte rapide alle query DNS effettuate 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 AWS utilizzare le edge location. 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. Le configurazioni e le condizioni della rete variano in base al momento e alla località. Vengono quindi addebitati solo i trasferimenti in cui Amazon S3 Transfer Acceleration può potenzialmente migliorare le prestazioni di caricamento. Per informazioni sull'utilizzo di Transfer Acceleration con diversi, consulta. AWS SDKs Abilitazione e utilizzo di S3 Transfer Acceleration

Ottimizzazione per carichi di lavoro ad alta frequenza di richieste

Le applicazioni che generano tassi di richiesta elevati verso Amazon S3 richiedono modelli di progettazione specifici per ottenere prestazioni ottimali. Quando la tua applicazione genera costantemente più di 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD richieste al secondo per prefisso, devi implementare strategie per distribuire le richieste e gestire il comportamento di scalabilità.

Amazon S3 si ridimensiona automaticamente per soddisfare tassi di richiesta più elevati, ma questo ridimensionamento avviene gradualmente. Durante il processo di scalabilità, potresti ricevere risposte HTTP 503 (Slow Down). Queste risposte sono temporanee e indicano che Amazon S3 sta ottimizzando i propri sistemi interni per il nuovo modello di richiesta. Una volta completata la scalabilità, le richieste verranno evase senza limitazioni.

Per ottimizzare le prestazioni per carichi di lavoro ad alta frequenza di richieste, prendi in considerazione le seguenti strategie:

• Distribuisci le richieste su più prefissi: utilizza uno schema di prefisso casuale o sequenziale per distribuire le richieste su più partizioni. Ad esempio, invece di utilizzare nomi di oggetti sequenziali come, usa prefissi randomizzati come. log-2024-01-01.txt a1b2/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 di riprova con backoff esponenziale. Inizia con un breve ritardo e aumenta gradualmente il tempo di attesa tra un tentativo e l'altro. AWS SDKs Include una logica di ripetizione integrata che lo gestisce automaticamente.

• Monitora i modelli di richiesta: utilizza i CloudWatch parametri di Amazon per monitorare i tassi di richiesta e i tassi di errore. Presta particolare attenzione ai parametri di errore 5xx, che possono indicare quando l'applicazione sta raggiungendo o superando gli attuali limiti di scalabilità.

• Aumenta gradualmente la frequenza delle richieste: quando avvii nuove applicazioni o aumenti significativamente la frequenza delle richieste, aumenta gradualmente il traffico nel tempo anziché passare immediatamente alle frequenze di picco. Ciò consente ad Amazon S3 di scalare in modo proattivo e riduce la probabilità di throttling.

• Usa più connessioni: distribuisci le tue richieste su più connessioni HTTP per massimizzare la velocità effettiva e ridurre l'impatto di ogni singolo problema di connessione.

Per le applicazioni che richiedono prestazioni elevate e costanti, prendi in considerazione l'utilizzo di Amazon S3 Express One Zone, progettato per applicazioni che richiedono latenze di un millisecondo e può supportare centinaia di migliaia di richieste al secondo. Per ulteriori informazioni, consulta S3 Express One Zone.