Schemi di progettazione per le prestazioni di Amazon S3 - Amazon Simple Storage Service

Schemi di progettazione per le prestazioni di 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 sulle prestazioni, che puoi prendere in considerazione quando pianifichi l'architettura dell'applicazione.

Per ottimizzare le prestazioni, puoi utilizzare i seguenti schemi di progettazione.

Utilizzo del caching per i contenuti ad accesso frequente

Molte applicazioni che archiviano dati in Amazon S3 fungono da "working set" dei dati richiesti ripetutamente dagli utenti. Se un carico di lavoro invia richieste GET ripetute di 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 informazioni su MediaStore, consulta la Guida per l'utente di AWS Elemental MediaStore.

Timeout e tentativi 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 ulteriori informazioni sulle tecniche di backoff, consulta Ripetizione dei tentativi in caso di errore e backoff esponenziale in AWS nella Guida di riferimento generale di Amazon Web Services.

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 Limiti nella Guida per gli sviluppatori di AWS Key Management Service per informazioni sui tassi di richiesta supportati per il tuo caso d'uso.

Dimensionamento orizzontale e parallelizzazione delle richieste per throughput elevato

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 Esecuzione di richieste.

Utilizzo di Amazon S3 Transfer Acceleration per accelerare trasferimenti di dati in zone geografiche lontane

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. 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 SDK AWS, consulta Abilitazione e utilizzo di S3 Transfer Acceleration.