Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Pola Desain Performa 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 Anda pertimbangkan saat sedang merencanakan arsitektur aplikasi Anda.
Untuk mengoptimalkan performa, Anda dapat menggunakan pola desain berikut.
Topik
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 permintaan GET 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 satu set 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 instans Amazon EC2 yang menyimpan objek cache dalam memori. Hasil caching ini menghasilkan urutan pengurangan besar-besaran dalam latensi GET dan peningkatan substansial 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 kinerja Amazon S3 GET, lihat posting blog Turbocharge Amazon S3 dengan Amazon untuk Redis
AWS Elemental MediaStore adalah sistem caching dan distribusi konten yang khusus dibuat untuk alur kerja video dan pengiriman media dari Amazon S3. MediaStore menyediakan API end-to-end penyimpanan 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 Pengulangan untuk Aplikasi yang Sensitif-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 yang tinggi (biasanya tingkat permintaan lebih dari 5.000 permintaan per detik ke sejumlah kecil objek), aplikasi mungkin akan menerima respons perlambatan HTTP 503. Jika kesalahan ini terjadi, setiap SDK AWS menerapkan logika percobaan ulang otomatis menggunakan mundur eksponensial. Jika Anda tidak menggunakan SDK AWS , Anda harus menerapkan logika percobaan ulang saat menerima kesalahan HTTP 503. Untuk informasi tentang teknik back-off, lihat Error Retries and Exponential Backoff di. AWSReferensi Umum Amazon Web Services
Amazon S3 secara otomatis menskalakan dalam menanggapi tingkat permintaan baru yang berkelanjutan, secara dinamis mengoptimalkan performa. Meskipun Amazon S3 secara internal mengoptimalkan untuk tingkat permintaan baru, Anda akan menerima respons permintaan HTTP 503 secara sementara hingga optimalisasi 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 menyarankan menggunakan koneksi baru ke Amazon S3 dan melakukan pencarian DNS baru.
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), yaitu latensi median sering kali berada dalam rentang milidetik, panduan yang baik adalah mencoba kembali operasi GET atau PUT setelah 2 detik. 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 Batas dalam 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 dengan throughput tinggi, Amazon S3 menyarankan penggunaan aplikasi yang menggunakan beberapa koneksi untuk GET atau PUT data secara paralel. Misalnya, ini didukung oleh Amazon S3 Transfer Manager di AWS Java SDK, dan sebagian besar AWS SDK lainnya 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 SDK untuk mengeluarkan permintaan GET dan PUT secara langsung daripada menggunakan manajemen transfer di SDK AWS . Dengan pendekatan ini, Anda dapat mengatur beban kerja secara lebih langsung, sembari tetap memanfaatkan dukungan SDK untuk percobaan ulang dan penanganannya terhadap setiap respons HTTP 503 yang mungkin terjadi. Sebagai aturan umum, ketika Anda mengunduh objek besar di dalam Wilayah dari Amazon S3 ke Amazon EC2, kami menyarankan untuk membuat permintaan bersamaan untuk kisaran byte objek pada granularitas sebesar 8–16 MB. Ajukan satu permintaan bersamaan untuk setiap 85–90 MB/dtk dari throughput jaringan yang diinginkan. Untuk memenuhi kartu antarmuka jaringan (NIC) 10 Gb/dtk, Anda mungkin menggunakan sekitar 15 permintaan secara bersamaan melalui koneksi terpisah. Anda dapat menaikkan skala permintaan serentak melalui lebih banyak koneksi untuk mensaturasikan NIC yang lebih cepat, seperti NIC 25 Gb/dtk atau 100 Gb/dtk.
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 menghasilkan penggunaan CPU sebesar 25 persen, hal ini menunjukkan bahwa hingga empat permintaan bersamaan dapat diakomodasi. Pengukuran sangat penting, dan perlu mengonfirmasi penggunaan sumber daya karena tingkat permintaan meningkat.
Jika aplikasi Anda menerbitkan permintaan secara langsung ke Amazon S3 menggunakan API REST, kami menyarankan menggunakan kumpulan koneksi HTTP dan menggunakan kembali setiap koneksi untuk serangkaian permintaan. Menghindari penyiapan koneksi per permintaan menghilangkan kebutuhan untuk menjalankan TCP slow-start dan handshake Secure Sockets Layer (SSL) pada setiap permintaan. Untuk informasi selengkapnya tentang API REST, lihat Referensi API Amazon Simple Storage Service.
Terakhir, penting untuk memperhatikan DNS dan pemeriksaan ulang bahwa permintaan tersebar di sejumlah besar alamat IP Amazon S3. Kueri DNS 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 perintah netstat dapat menunjukkan alamat IP yang digunakan untuk komunikasi dengan Amazon S3, dan kami memberikan panduan untuk konfigurasi DNS untuk digunakan. Untuk informasi selengkapnya tentang pedoman ini, lihat Membuat permintaan.
Menggunakan Amazon S3 Transfer Acceleration untuk Mempercepat Transfer Data Terpisah 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. Saat ini, digunakan untuk mendistribusikan konten melalui CloudFront dan untuk memberikan respons cepat terhadap kueri DNS 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