Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pola desain kinerja untuk Amazon S3

Saat merancang aplikasi untuk mengunggah dan mengambil objek dari Amazon S3, gunakan pola desain praktik terbaik kami untuk mencapai performa terbaik untuk aplikasi Anda. Kami juga menawarkan Pedoman kinerja untuk Amazon S3 untuk Anda pertimbangkan saat sedang merencanakan arsitektur aplikasi Anda.

Untuk mengoptimalkan performa, Anda dapat menggunakan pola desain berikut.

Menggunakan caching untuk konten yang sering diakses

Banyak aplikasi yang menyimpan data di Amazon S3 melayani "perangkat kerja” data yang berulang kali diminta oleh pengguna. Jika beban kerja mengirimkan GET permintaan berulang untuk sekumpulan objek umum, Anda dapat menggunakan cache seperti Amazon CloudFront, Amazon ElastiCache, atau AWS Elemental MediaStoreuntuk mengoptimalkan kinerja. Penerapan cache yang berhasil dapat menghasilkan latensi rendah dan laju transfer data tinggi. Aplikasi yang menggunakan caching juga mengirimkan lebih sedikit permintaan langsung ke Amazon S3, yang dapat membantu mengurangi biaya permintaan.

Amazon CloudFront adalah jaringan pengiriman konten cepat (CDN) yang secara transparan menyimpan data dari Amazon S3 dalam serangkaian besar titik kehadiran yang didistribusikan secara geografis (). PoPs Ketika objek dapat diakses dari beberapa Wilayah, atau melalui internet, CloudFront memungkinkan data untuk di-cache dekat dengan pengguna yang mengakses objek. Ini dapat menghasilkan pengiriman konten Amazon S3 populer dengan performa tinggi. Untuk selengkapnya CloudFront, lihat Panduan CloudFront Pengembang Amazon.

Amazon ElastiCache adalah cache dalam memori yang dikelola. Dengan ElastiCache, Anda dapat menyediakan EC2 instans Amazon yang menyimpan objek cache dalam memori. Caching ini menghasilkan urutan pengurangan magnitudo dalam GET latensi dan peningkatan substansional dalam throughput unduhan. Untuk menggunakannya ElastiCache, Anda memodifikasi logika aplikasi untuk mengisi cache dengan objek panas dan memeriksa cache untuk objek panas sebelum memintanya dari Amazon S3. Untuk contoh penggunaan ElastiCache untuk meningkatkan GET kinerja Amazon S3, lihat posting blog Turbocharge Amazon S3 dengan Amazon untuk Redis. ElastiCache

AWS Elemental MediaStore adalah sistem caching dan distribusi konten yang khusus dibuat untuk alur kerja video dan pengiriman media dari Amazon S3. MediaStore menyediakan end-to-end penyimpanan APIs khusus untuk video, dan direkomendasikan untuk beban kerja video yang sensitif terhadap kinerja. Untuk selengkapnya MediaStore, lihat Panduan AWS Elemental MediaStore Pengguna.

Batas waktu dan percobaan ulang untuk aplikasi yang sensitif terhadap latensi

Ada situasi tertentu ketika aplikasi menerima respons dari Amazon S3 yang menunjukkan bahwa percobaan ulang diperlukan. Bucket peta Amazon S3 dan nama objek ke data objek yang terkait dengannya. Jika aplikasi menghasilkan tingkat permintaan tinggi (biasanya tingkat berkelanjutan lebih dari 5.000 permintaan per detik untuk sejumlah kecil objek), aplikasi mungkin menerima HTTP 503 respons perlambatan. Jika kesalahan ini terjadi, masing-masing AWS SDK mengimplementasikan logika coba ulang otomatis menggunakan backoff eksponensial. Jika Anda tidak menggunakan AWS SDK, Anda harus menerapkan logika coba lagi saat menerima kesalahan HTTP 503. Untuk informasi tentang teknik back-off, lihat Coba lagi perilaku di Panduan Referensi Alat AWS SDKsdan Alat.

Amazon S3 secara otomatis menskalakan dalam menanggapi tingkat permintaan baru yang berkelanjutan, secara dinamis mengoptimalkan performa. Meskipun Amazon S3 mengoptimalkan tingkat permintaan baru secara internal, Anda akan menerima respons permintaan HTTP 503 sementara hingga pengoptimalan selesai. Setelah Amazon S3 secara internal mengoptimalkan performa untuk tingkat permintaan baru, semua permintaan umumnya dilayani tanpa percobaan ulang.

Untuk aplikasi sensitif latensi, Amazon S3 menyarankan pelacakan dan mencoba kembali operasi yang lebih lambat secara agresif. Saat Anda mencoba lagi permintaan, kami sarankan menggunakan koneksi baru ke Amazon S3 dan melakukan pencarian baruDNS.

Saat Anda membuat permintaan berukuran besar (misalnya, lebih dari 128 MB), kami menyarankan untuk melacak throughput yang dicapai, dan mencoba kembali 5 persen paling lambat dari permintaan tersebut. Saat Anda membuat permintaan yang lebih kecil (misalnya, kurang dari 512 KB), di mana latensi median sering berada dalam kisaran puluhan milidetik, pedoman yang baik adalah mencoba kembali a atau operasi setelah 2 detik. GET PUT Jika percobaan ulang tambahan diperlukan, praktik terbaik adalah back off. Misalnya, kami sarankan untuk mengeluarkan satu percobaan ulang setelah 2 detik dan percobaan ulang kedua setelah 4 detik tambahan.

Jika aplikasi Anda membuat permintaan ukuran tetap ke Amazon S3, Anda akan mengharapkan waktu respons yang lebih konsisten untuk setiap permintaan ini. Dalam kasus ini, strategi sederhana adalah mengidentifikasi 1 persen permintaan paling lambat dan mencobanya lagi. Bahkan, satu kali coba ulang sering kali efektif dalam mengurangi latensi.

Jika Anda menggunakan AWS Key Management Service (AWS KMS) untuk enkripsi sisi server, lihat Kuota di Panduan AWS Key Management Service Pengembang untuk informasi tentang tarif permintaan yang didukung untuk kasus penggunaan Anda.

Penskalaan horizontal dan paralelisasi permintaan untuk throughput tinggi

Amazon S3 adalah sistem terdistribusi yang sangat besar. Untuk membantu Anda memanfaatkan skalanya, kami mendorong Anda untuk menskalakan permintaan paralel secara horizontal ke titik akhir layanan Amazon S3. Selain mendistribusikan permintaan di dalam Amazon S3, jenis pendekatan penskalaan ini membantu mendistribusikan muatan melalui beberapa jejak melalui jaringan.

Untuk transfer throughput tinggi, Amazon S3 menyarankan penggunaan aplikasi yang menggunakan beberapa koneksi ke GET atau PUT data secara paralel. Misalnya, ini didukung oleh Amazon S3 Transfer Manager di AWS JavaSDK, dan sebagian besar lainnya AWS SDKs menyediakan konstruksi serupa. Untuk beberapa aplikasi, Anda dapat mencapai koneksi paralel dengan meluncurkan beberapa permintaan secara bersamaan dalam utas aplikasi yang berbeda, atau dalam instans aplikasi yang berbeda. Pendekatan terbaik untuk diambil tergantung pada aplikasi Anda dan struktur objek yang Anda akses.

Anda dapat menggunakan AWS SDKs untuk mengeluarkan GET dan PUT meminta secara langsung daripada menggunakan manajemen transfer di AWS SDK. Pendekatan ini memungkinkan Anda menyetel beban kerja Anda secara lebih langsung, sambil tetap mendapat manfaat dari dukungan untuk percobaan ulang dan penanganannya terhadap HTTP 503 respons yang mungkin SDK terjadi. Sebagai aturan umum, saat Anda mengunduh objek besar dalam Wilayah dari Amazon S3 ke Amazon EC2, kami sarankan untuk membuat permintaan bersamaan untuk rentang byte objek dengan perincian 8-16 MB. Buat satu permintaan bersamaan untuk setiap MB/s of desired network throughput. To saturate a 10 Gb/s network interface card (NIC), you might use about 15 concurrent requests over separate connections. You can scale up the concurrent requests over more connections to saturate faster NICs, such as 25 Gb/s or 100 Gb/s NICs 85—90.

Mengukur performa sangat penting saat Anda menyesuaikan jumlah permintaan untuk masalah secara bersamaan. Kami menyarankan untuk memulai dengan permintaan tunggal pada satu waktu. Mengukur bandwith jaringan yang dicapai dan penggunaan sumber daya lain yang digunakan aplikasi Anda dalam memproses data. Anda kemudian dapat mengidentifikasi sumber daya bottleneck (yaitu, sumber daya dengan penggunaan tertinggi), dan karenanya jumlah permintaan yang mungkin berguna. Misalnya, jika memproses satu permintaan pada satu waktu mengarah ke CPU penggunaan 25 persen, itu menunjukkan bahwa hingga empat permintaan bersamaan dapat diakomodasi. Pengukuran sangat penting, dan perlu mengonfirmasi penggunaan sumber daya karena tingkat permintaan meningkat.

Jika aplikasi Anda mengeluarkan permintaan langsung ke Amazon S3 menggunakan RESTAPI, sebaiknya gunakan kumpulan HTTP koneksi dan gunakan kembali setiap koneksi untuk serangkaian permintaan. Menghindari pengaturan koneksi per permintaan menghilangkan kebutuhan untuk melakukan jabat tangan TCP slow start dan Secure Sockets Layer (SSL) pada setiap permintaan. Untuk informasi tentang penggunaan RESTAPI, lihat APIReferensi Layanan Penyimpanan Sederhana Amazon.

Terakhir, ada baiknya memperhatikan DNS dan memeriksa ulang apakah permintaan tersebar di kumpulan alamat IP Amazon S3 yang luas. DNSkueri untuk siklus Amazon S3 melalui daftar besar titik akhir IP. Namun pemecah cache atau kode aplikasi yang menggunakan kembali satu alamat IP tidak mendapatkan keuntungan dari keragaman alamat dan load balancing yang mengikutinya. Alat utilitas jaringan seperti alat baris netstat perintah dapat menunjukkan alamat IP yang digunakan untuk komunikasi dengan Amazon S3, dan kami menyediakan pedoman untuk DNS konfigurasi yang akan digunakan. Untuk informasi selengkapnya tentang pedoman ini, lihat Membuat permintaan di Referensi Amazon S3 API.

Menggunakan Amazon S3 Transfer Acceleration untuk mempercepat transfer data yang berbeda secara geografis

Mengonfigurasi transfer file yang cepat dan aman menggunakan Amazon S3 Transfer Acceleration terbukti efektif dalam meminimalkan atau menghilangkan latensi yang disebabkan oleh jarak geografis antara klien yang tersebar secara global dan aplikasi regional menggunakan Amazon S3. Transfer Acceleration menggunakan lokasi edge yang didistribusikan secara global CloudFront untuk transportasi data. Jaringan AWS edge memiliki titik kehadiran di lebih dari 50 lokasi. Hari ini, digunakan untuk mendistribusikan konten melalui CloudFront dan untuk memberikan tanggapan cepat terhadap DNS pertanyaan yang dibuat ke Amazon Route 53.

Jaringan edge juga membantu mempercepat transfer data masuk dan keluar dari Amazon S3. Sangat ideal untuk aplikasi yang mentransfer data antar benua, memiliki koneksi internet yang cepat, menggunakan objek besar, atau memiliki banyak konten untuk diunggah. Saat datanya tiba di lokasi edge, data diarahkan ke Amazon S3 melalui jalur jaringan yang dioptimalkan. Secara umum, semakin jauh Anda berada di Wilayah Amazon S3, semakin tinggi peningkatan kecepatan yang dapat Anda harapkan dari penggunaan Transfer Acceleration.

Anda dapat mengatur Transfer Acceleration pada bucket baru atau yang sudah ada. Anda dapat menggunakan endpoint Amazon S3 Transfer Acceleration terpisah untuk menggunakan lokasi AWS tepi. Cara terbaik untuk menguji apakah Transfer Acceleration membantu klien meminta performa adalah menggunakan Alat Amazon S3 Transfer Acceleration Speed Comparison. Konfigurasi dan kondisi jaringan bervariasi dari waktu ke waktu dan dari lokasi ke lokasi. Jadi, Anda hanya dikenakan biaya untuk transfer ketika Amazon S3 Transfer Acceleration dapat meningkatkan performa pengunggahan Anda. Untuk informasi tentang penggunaan Akselerasi Transfer dengan yang berbeda AWS SDKs, lihatMengaktifkan dan menggunakan S3 Transfer Acceleration.