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

Coba lagi perilaku

Ketika permintaan Layanan AWS gagal karena kesalahan sementara atau pembatasan, SDK dapat mencoba ulang permintaan secara otomatis. Halaman ini mencakup cara mengonfigurasi percobaan ulang dan cara kerjanya secara internal.

Mengkonfigurasi percobaan ulang

Anda mengontrol strategi coba ulang mana yang digunakan SDK dan berapa kali mencoba ulang.

Memilih mode coba lagi

Mode coba lagi menentukan bagaimana SDK berperilaku ketika permintaan gagal. Tiga mode tersedia: standar, adaptif, dan warisan.

Mode standar (default)

Mode standar mencoba ulang permintaan yang gagal menggunakan backoff eksponensial dengan jitter. Ini menggunakan penundaan yang lebih pendek untuk kesalahan sementara (seperti batas waktu jaringan) dan penundaan yang lebih lama untuk kesalahan pelambatan (seperti). ThrottlingException

Mode standar mencakup kuota coba lagi, ember token yang memotong token untuk setiap percobaan ulang dan mengisi kembali token saat permintaan berhasil. Ketika token yang tersedia habis, SDK mengembalikan kesalahan tanpa mencoba lagi, sehingga aplikasi Anda gagal dengan cepat alih-alih menunggu percobaan ulang yang tidak mungkin berhasil. Ini juga membantu gangguan layanan diselesaikan lebih cepat dengan mengurangi lalu lintas coba lagi. Selama operasi normal, kuota tetap penuh dan tidak berpengaruh. Kuota coba lagi tidak pernah menunda atau memblokir permintaan awal. Hanya percobaan ulang yang terpengaruh. Lihat perinciannya di Coba lagi kuota (token bucket).

Gunakan mode standar kecuali Anda memiliki alasan khusus untuk memilih mode lain.

Mode adaptif

Mode adaptif mencakup semuanya dalam mode standar, ditambah pembatas laju sisi klien. Pembatas laju melacak respons pelambatan dan menyesuaikan kecepatan pengiriman permintaan SDK. Tidak seperti mode standar, mode adaptif dapat menunda atau memblokir permintaan awal, bukan hanya mencoba ulang, ketika pelambatan terdeteksi.

Pembatas tarif beroperasi per instance klien SDK. Semua permintaan dari klien memiliki batas tarif yang sama, terlepas dari operasi API atau sumber daya yang mereka targetkan.

Kapan menggunakan mode adaptif:

Kapan tidak menggunakan mode adaptif:

Mode adaptif tidak disarankan sebagai default umum.

Mode warisan

Mode lama adalah perilaku coba ulang setiap SDK yang digunakan sebelum mode standar diperkenalkan. Ini tidak termasuk kuota coba lagi standar. Beberapa SDK (seperti Java) memiliki implementasi kuota coba ulang sendiri dalam mode lama, tetapi perilakunya tidak konsisten di seluruh SDK. Tanpa kuota standar, klien terus mencoba lagi dengan kecepatan penuh selama gangguan layanan. Ini mengikat utas dan koneksi pada permintaan yang tidak mungkin berhasil, sambil menambahkan beban yang dapat menunda pemulihan layanan.

Mode lama bervariasi di seluruh SDK. Hitungan coba lagi, waktu backoff, set kesalahan yang dapat dicoba ulang, dan perilaku pelambatan berbeda antar bahasa. Kode yang bergantung pada perilaku coba lagi lama dapat berperilaku berbeda saat dipindahkan antar SDK.

Tersedia dalam: Java, Python, Ruby, PHP, C++, CLI

Tidak tersedia di: .NET, Go, Kotlin, Rust, Swift, JavaScript

Mode lama ada untuk kompatibilitas mundur. Jika saat ini Anda menggunakan mode lama, beralihlah ke mode standar.

Coba lagi pengaturan

Pengaturan berikut mengontrol perilaku coba lagi. Anda dapat mengaturnya melalui variabel lingkungan, file konfigurasi bersama (~/.aws/config), atau konfigurasi klien dalam kode.

Nilai percobaan maksimal 3 berarti SDK membuat satu permintaan awal dan hingga dua percobaan ulang. Setel upaya maksimal 1 untuk menonaktifkan percobaan ulang sepenuhnya.

Konfigurasi diutamakan

Saat Anda menentukan setelan yang sama di beberapa tempat, SDK akan menyelesaikan nilainya menggunakan prioritas berikut, dari tertinggi ke terendah:

Ini mengikuti prioritas konfigurasi AWS SDK standar. Nilai yang ditetapkan pada level yang lebih tinggi selalu mengesampingkan nilai yang ditetapkan pada level yang lebih rendah. Misalnya, jika Anda menetapkan AWS_RETRY_MODE=adaptive sebagai variabel lingkungan dan retry_mode=standard dalam~/.aws/config, SDK menggunakan mode adaptif.

Language-specific konfigurasi

Pengaturan lintas SDK yang dijelaskan di halaman ini (retry_modedanmax_attempts) berfungsi di semua SDK. Namun, API untuk mengonfigurasi percobaan ulang dalam kode bervariasi menurut bahasa. Lihat panduan developer SDK Anda untuk opsi konfigurasi khusus bahasa seperti strategi backoff khusus, kesalahan tambahan yang dapat dicoba ulang, dan coba lagi penyetelan kuota.

Cara kerja percobaan ulang

Bagian ini menjelaskan cara AWS SDK menangani permintaan yang gagal: kesalahan mana yang memicu percobaan ulang, berapa lama SDK menunggu di antara upaya, dan kapan berhenti mencoba lagi.

Apa yang terjadi ketika permintaan gagal

Saat Anda melakukan panggilan API melalui AWS SDK, SDK mengikuti urutan ini:

SDK mengulangi loop ini hingga permintaan berhasil, jumlah upaya maksimum tercapai, kuota coba lagi habis, atau terjadi kesalahan yang tidak dapat dicoba ulang. Seluruh proses otomatis. Aplikasi Anda melihat respons yang berhasil atau kesalahan terakhir.

Kesalahan mana yang dicoba lagi

SDK mengklasifikasikan setiap permintaan yang gagal ke dalam salah satu dari tiga kategori: transient, throttling, atau non-retryable. Klasifikasi ini menentukan apakah SDK mencoba ulang permintaan dan berapa lama menunggu sebelum mencoba lagi.

Klasifikasi didasarkan pada kode kesalahan dan kode status HTTP dalam respon layanan. Misalnya, HTTP 400 dengan kode kesalahan RequestTimeout diklasifikasikan sebagai sementara dan dicoba lagi. HTTP 400 dengan ValidationException diklasifikasikan sebagai non-retryable dan segera dikembalikan.

Klasifikasi kesalahan

Kesalahan sementara dicoba lagi dengan penundaan dasar pendek (50 ms):

Kesalahan pelambatan dicoba lagi dengan penundaan dasar yang lebih lama (1.000 ms):

Non-retryable kesalahan (sepertiAccessDeniedException,ValidationException,ResourceNotFoundException) segera dikembalikan ke kode Anda.

Kesalahan pelambatan berarti layanan secara aktif menolak permintaan Anda karena batas tarif, sehingga SDK menunggu lebih lama sebelum mencoba lagi memberikan waktu layanan untuk memulihkan kapasitas. Lihat Berapa lama SDK menunggu untuk penundaan spesifik.

Berapa lama SDK menunggu

SDK menggunakan backoff eksponensial dengan jitter penuh. Rata-rata, setiap percobaan lagi menunggu lebih lama dari yang terakhir, dengan pengacakan untuk menyebarkan permintaan dari beberapa klien.

Penundaan dasar berdasarkan jenis kesalahan

Penundaan dasar tergantung pada apakah kesalahan bersifat sementara atau pelambatan:

Rumus backoff

SDK menghitung setiap penundaan coba lagi menggunakan rumus ini:

delay = random(0, 1) × min(20,000 ms, base_delay × 2^retry)

Di mana:

Tutup backoff maksimum adalah 20 detik. Tidak ada penundaan individu yang melebihi 20 detik terlepas dari berapa banyak upaya yang telah terjadi.

Contoh yang dikerjakan

Contoh 1: Kesalahan sementara, 3 upaya maksimal

Total latensi tambahan rata-rata sekitar 75 ms di kedua percobaan ulang.

Contoh 2: Kesalahan pelambatan, 3 upaya maksimal

Total latensi tambahan rata-rata sekitar 1.500 ms di kedua percobaan ulang.

Contoh 3: Kesalahan sementara, mengenai tutup backoff

Dengan penundaan dasar 50 ms, penundaan yang dihitung sebelum pembatasan adalah:

Tutup mulai berlaku pada percobaan ulang ke-10 (upaya ke-11) untuk kesalahan sementara. Untuk kesalahan pelambatan dengan basis 1.000 ms, tutup berlaku pada percobaan ulang ke-6.

Mengapa jitter penting

Pengganda acak disebut jitter penuh. Tanpa itu, semua klien yang mengalami kesalahan pada saat yang sama akan mencoba lagi pada saat yang sama, menciptakan ledakan lalu lintas coba lagi (masalah “kawanan gemuruh”). Jitter penuh menyebar percobaan ulang secara seragam di seluruh jendela backoff sehingga layanan menerima tetesan permintaan yang stabil alih-alih lonjakan yang disinkronkan.

Misalnya, 1.000 klien semuanya menerima 503 pada saat yang sama. Jitter penuh mendistribusikan percobaan ulang pertama mereka secara seragam di seluruh jendela 50 ms alih-alih memiliki semua 1.000 percobaan lagi tepat 50 ms.

Server-directed coba lagi waktu

Beberapa Layanan AWS menyertakan x-amz-retry-after header dalam respons kesalahan. Nilai header adalah penundaan dalam milidetik. Saat header ini ada, SDK menggunakan penundaan yang ditentukan server, dijepit ke minimum penundaan backoff yang dihitung dan maksimum penundaan backoff yang dihitung ditambah 5.000 ms. Karena backoff yang dihitung sendiri dibatasi pada 20 detik, penundaan diarahkan server maksimum yang efektif adalah 25 detik. SDK tidak menerapkan jitter ke nilai ini, karena layanan diharapkan akan menggetarkannya. Hal ini memungkinkan layanan untuk berkomunikasi tepat ketika mengharapkan untuk memiliki kapasitas yang tersedia.

Coba lagi kuota (token bucket)

SDK mempertahankan anggaran token internal yang melacak rasio permintaan yang berhasil terhadap kegagalan. Ketika kegagalan tersebar luas, anggaran habis dan SDK mengembalikan kesalahan secara langsung. Aplikasi Anda gagal dengan cepat alih-alih menunggu percobaan ulang yang tidak mungkin berhasil. Ini juga mengurangi lalu lintas coba lagi, membantu gangguan layanan diselesaikan lebih cepat.

Cara kerja kuota coba lagi

Anggaran token mulai penuh. Setiap upaya coba lagi mengurangi token. Ketika percobaan ulang berhasil, SDK mengembalikan token yang dikonsumsi oleh percobaan ulang itu. Ketika permintaan berhasil pada percobaan pertama (tidak perlu mencoba lagi), SDK mengembalikan 1 token. Ketika anggaran mencapai nol, SDK berhenti mencoba lagi dan mengembalikan kesalahan langsung ke kode Anda.

Biaya yang lebih tinggi untuk percobaan ulang sementara mencerminkan pola kegagalannya yang berbeda. Kesalahan sementara seperti 500s dan kegagalan koneksi sering menunjukkan masalah di seluruh layanan. Dalam situasi ini, terus mencoba lagi tidak mungkin berhasil. Ini menambahkan latensi ke panggilan Anda, mengikat sumber daya klien, dan dapat menunda pemulihan untuk semua orang. Kesalahan pelambatan menandakan bahwa layanan membutuhkan lebih banyak waktu sebelum permintaan dapat berhasil. SDK menunggu lebih lama di antara percobaan ulang untuk meningkatkan kemungkinan keberhasilan.

Kapan blok kuota mencoba lagi

Kuota coba lagi melacak token setiap saat, tetapi hanya memblokir percobaan ulang ketika anggaran habis. Selama operasi normal, hampir semua permintaan berhasil dan anggaran tetap penuh. Kuota tidak memiliki efek yang dapat diamati pada percobaan ulang.

Percobaan ulang yang berhasil hanya mengembalikan biaya tokennya sendiri (14 atau 5 token), bukan biaya percobaan ulang yang gagal sebelumnya dalam permintaan yang sama. Misalnya, jika percobaan ulang pertama gagal dan yang kedua berhasil, anggaran kehilangan 14 token bersih. Anggaran terkuras paling cepat ketika mencoba ulang menghabiskan semua upaya tanpa berhasil, tetapi juga mengalir secara bertahap ketika permintaan membutuhkan beberapa percobaan ulang sebelum berhasil.

Dengan default 3 upaya maksimal, kuota mulai terkuras ketika lebih dari sekitar 22% permintaan menghasilkan kegagalan sementara yang berkelanjutan, atau lebih dari sekitar 32% untuk kesalahan pelambatan. Di bawah tarif ini, permintaan yang berhasil mengisi kembali anggaran lebih cepat daripada percobaan ulang yang gagal mengurasnya.

Saldo awal anggaran 500 token menyediakan buffer yang menyerap ledakan kegagalan singkat. Lonjakan singkat dalam kesalahan, bahkan yang parah, tidak menghalangi percobaan ulang kecuali bertahan cukup lama untuk mengeringkan buffer.

Implikasi praktis

Service-specific perilaku

DynamoDB

Klien DynamoDB menggunakan default yang disetel yang dioptimalkan untuk profil latensi rendah DynamoDB:

Default ini berlaku untuk Amazon DynamoDB dan DynamoDB Streams.

Long-polling operasi

AWS Operasi tertentu menggunakan polling panjang. Mereka dapat mengadakan koneksi terbuka menunggu pekerjaan tiba. Operasi ini menerima perlakuan coba ulang khusus:

Perilaku khusus: Ketika kuota coba lagi habis dan percobaan ulang diblokir (langkah 7 inApa yang terjadi ketika permintaan gagal), SDK masih menerapkan penundaan backoff sebelum mengembalikan kesalahan ke kode Anda.

Ini penting karena operasi pemungutan suara panjang biasanya disebut dalam lingkaran ketat. Kode Anda memanggilReceiveMessage, memproses pesan apa pun, lalu segera menelepon ReceiveMessage lagi. Tanpa backoff paksa, anggaran token yang habis akan menyebabkan SDK mengembalikan kesalahan tanpa penundaan. Loop polling Anda kemudian akan segera mengirim permintaan berikutnya, meningkatkan penggunaan CPU klien dan menghasilkan lalu lintas tambahan. Penundaan backoff paksa memutus siklus ini, menjaga penggunaan sumber daya klien dan tingkat polling dapat dikelola selama kegagalan.

Support oleh AWS SDK dan alat

Tabel berikut mencantumkan ketersediaan perilaku coba ulang yang diperbarui di setiap SDK. Untuk SDK-specific detail termasuk versi minimum, default sebelum dan sesudah, dan contoh kode, lihat masalah pelacakan. GitHub