Gesaan dan konteks
Sebuah perkhidmatan membuat panggilan ke pangkalan data, penyedia pembayaran dan sistem pengesyoran. Pengesyoran menjadi perlahan daripada 10 ms kepada 1 saat. Permintaan dalam penerbangan meningkat sehingga bebenang dan sambungan habis digunakan, dan API yang tidak memerlukan pengesyoran turut gagal. Reka bentuk bulkhead supaya kebergantungan yang perlahan hanya menjejaskan kefungsian yang berkaitan.
AWS Builders’ Library menerangkan perkara ini sebagai beban lampau konkurensi didorong kependaman: had masa tamat (timeout) bukanlah had konkurensi. Sumber mesti diasingkan di sekitar setiap kebergantungan atau klien, melindungi kedua-dua perkhidmatan dan sistem hiliran.
Perkara yang dinilai oleh penemu duga
- Anda menerangkan intuisi Hukum Little bahawa masa perkhidmatan yang lebih tinggi meningkatkan kerja dalam penerbangan pada kadar ketibaan yang sama.
- Anda memperuntukkan konkurensi mengikut kebergantungan, API, penyewa (tenant), atau kolam sumber supaya satu kebergantungan yang perlahan tidak dapat menghabiskan kapasiti global.
- Anda membandingkan kuota keras, lembut dan dinamik berserta pertukaran antara keadilan dan penggunaannya.
- Anda mereka bentuk penolakan pantas, degradasi, tarikh akhir (deadline), tingkah laku litar, pemulihan dan kebolehcerapan.
- Anda membuktikan API yang tidak berkaitan kekal sihat tanpa giliran tidak terhad atau kebuluran sumber.
Soalan untuk dijelaskan terlebih dahulu
- API manakah yang memanggil pengesyoran dan yang manakah kritikal? Bolehkah mana-mana laluan didegradasi?
- Apakah had bebenang, sambungan, memori dan giliran serta taburan konkurensi semasa?
- Adakah kebergantungan menyokong pembatalan, keidempoteman, pemprosesan kelompok, atau pemuatan cache? Bagaimanakah tarikh akhir pemanggil dipancarkan?
- Adakah belanjawan diasingkan mengikut API, kebergantungan, penyewa, atau Availability Zone? Adakah peminjaman diperlukan?
- Apakah pengalaman pengguna, kontrak ralat dan objektif pemulihan yang diguna pakai semasa kegagalan?
Jawapan 30 saat
“Saya mencipta bulkhead konkurensi terikat dan giliran bagi setiap kebergantungan, dengan kolam berasingan untuk API kritikal dan API yang boleh didegradasi. Permintaan membawa tarikh akhir; kerja yang melebihi bajet akan gagal pantas atau menyediakan cache dan bukannya menunggu selama-lamanya. Saya menggunakan kuota lembut untuk penggunaan tetapi menetapkan had global dan setiap kelas yang keras, dengan peminjaman terikat. Metrik merangkumi kerja dalam penerbangan, penolakan, tunggu, masa tamat, degradasi dan pemulihan mengikut kebergantungan dan API. Ujian kebergantungan perlahan mesti memastikan API yang tidak berkaitan kekal sihat.”
Penyelesaian langkah demi langkah
Langkah 1: Kuantifikasikan konkurensi didorong kependaman
Ukur kadar ketibaan, masa perkhidmatan, permintaan dalam penerbangan dan masa tamat bagi setiap kebergantungan. Jika masa perkhidmatan meningkat daripada 10 ms kepada 1 s, kerja dalam penerbangan boleh meningkat sekitar 100 kali ganda pada kadar ketibaan yang sama. Kenal pasti sumber yang terhad sebelum menentukan saiz bulkhead.
Langkah 2: Partisikan kolam sumber
Berikan setiap kebergantungan kolam sambungan, semafor dan giliran terikatnya yang tersendiri; asingkan API kritikal dan API yang boleh didegradasi untuk kebergantungan yang sama. Sahkan bahawa pengasingan adalah nyata: bebenang, sambungan dan keadaan tidak boleh kekal dikongsi di sebalik pembilang berasingan.
Langkah 3: Pilih kuota keras, lembut dan dinamik
Kuota keras melindungi API tetapi membazirkan kapasiti apabila berlaku ketidakseimbangan beban. Kuota lembut meminjam kapasiti terbiar di bawah had global. Kuota dinamik menyesuaikan diri dengan beban tetapi memerlukan jaminan minimum, had maksimum dan kadar perubahan yang selamat. Tambah pembahagian penyewa apabila keadilan menjadi keutamaan.
global_limit = 500
payments = hard 150
recommendations = soft 200, borrow <= 100
other_apis = reserved 50Langkah 4: Tolak dan degradasi secara sengaja
Jika tiada permit tersedia, kembalikan ralat eksplisit atau hasil cache dan bukannya memasuki giliran tanpa had. Patuhi tarikh akhir pemanggil dan batalkan kerja yang boleh dibatalkan. Percubaan semula memerlukan belanjawan, pengunduran (backoff) dan keidempoteman; operasi tulis yang kritikal tidak boleh didegradasi secara senyap.
Langkah 5: Pulih tanpa ayunan
Selepas pemulihan, tingkatkan permit secara beransur-ansur dan gunakan probe separa terbuka (half-open) untuk mengelakkan lonjakan mendadak. Kekalkan siri masa untuk penolakan, masa tamat dan tanda aras giliran, yang disegmenkan mengikut kebergantungan, API, penyewa dan sel. Buat versi konfigurasi dan sediakan keupayaan pengunduran (rollback).
Langkah 6: Sahkan sempadan pengasingan
Suntik kependaman, ralat dan keletihan sambungan ke dalam satu kebergantungan. Perhatikan penolakan pengesyoran, kejayaan pembayaran, penggunaan bebenang/sambungan global dan kependaman ekor (tail latency). Uji lonjakan, ketidakseimbangan penyewa, perubahan konfigurasi dan kegagalan sel; SLO API yang tidak berkaitan dan had giliran merupakan kriteria penerimaan.
Contoh jawapan yang kukuh
“Saya menggunakan kadar ketibaan, masa perkhidmatan dan kerja dalam penerbangan untuk menunjukkan sebab kebergantungan pengesyoran yang perlahan menggandakan konkurensi. Setiap kebergantungan mempunyai semafor, kolam dan giliran terikat tersendiri; API kritikal dan boleh didegradasi diasingkan. Pembayaran mendapat tempahan keras; pengesyoran menggunakan kuota lembut dengan peminjaman terikat. Setiap panggilan menyebarkan tarikh akhir dan gagal pantas atau mengembalikan cache apabila permit habis.”
“Pemulihan menggunakan probe separa terbuka dan peningkatan permit secara beransur-ansur. Metrik merangkumi kerja dalam penerbangan, penolakan, tunggu, masa tamat, kekerapan degradasi, ralat hiliran dan masa pemulihan. Latihan simulasi hanya memperlahankan pengesyoran dan memeriksa bahawa ekor pembayaran serta API yang tidak berkaitan, kolam dan bebenang kekal dalam had.”
Kesilapan biasa
- Hanya meningkatkan had masa tamat → kerja dalam penerbangan bertambah → tetapkan had konkurensi peringkat kebergantungan.
- Berkongsi satu kolam bebenang dan sambungan → satu kebergantungan perlahan melumpuhkan perkhidmatan → partisikan mengikut kebergantungan dan kekritikalan.
- Menggunakan giliran tanpa had → memori dan kependaman menjadi tidak terkawal → hadkannya dan tolak dengan pantas.
- Kuota keras statik di semua tempat → ketidakseimbangan beban membiarkan kapasiti tidak digunakan → benarkan peminjaman lembut yang terikat.
- Mencuba semula tanpa belanjawan → beban lampau hiliran diperkuatkan → pancarkan tarikh akhir, hadkan percubaan dan wajibkan keidempoteman.
- Hanya menguji kebergantungan yang gagal → pengasingan tidak terbukti → sahkan SLO API yang tidak berkaitan secara serentak.
Soalan susulan dan jawapan
Mengapakah had masa tamat bukan had konkurensi?
Ia mengehadkan satu tempoh menunggu, tetapi permintaan yang menunggu itu masih menduduki bebenang, sambungan dan memori. Kependaman kebergantungan yang lebih tinggi menyebabkan lebih banyak permintaan dalam penerbangan, jadi permit mesti dihadkan.
Bagaimanakah peminjaman lembut menghalang satu API daripada mengambil semua sumber?
Gunakan had global, tempahan minimum bagi setiap API, peminjaman maksimum dan kadar tuntut semula. Sebaik sahaja peminjam mencapai hadnya, ia akan gagal pantas dan bukannya terus berkembang tanpa had.
Bilakah mengembalikan cache adalah selamat?
Bagi operasi baca yang boleh menerima data lapuk terikat (bounded staleness), kembalikan nilai cache dengan cap masa. Hasil pembayaran, pengesahan dan penulisan tidak boleh digantikan secara senyap oleh data lapuk.
Bagaimanakah anda membuktikan bahawa pengasingan berfungsi?
Suntik kelembapan dan ralat ke dalam satu kebergantungan, kemudian periksa kerja dalam penerbangan, kependaman ekor, penggunaan bebenang/sambungan dan kadar kejayaan bagi API yang tidak berkaitan. Degradasi serentak bermakna sumber kongsi atau sempadan giliran masih wujud.