Backpressure Bukan Bug: Ini adalah fitur untuk membangun sistem yang tahan lama

Backpressure adalah negosiasi tersembunyi antara produsen dan konsumen. Menguasai itu, dan sistem Anda skala dengan sopan. Mengabaikannya, dan mereka hancur di bawah beban puncak.

Backpressure adalah negosiasi tersembunyi antara produsen dan konsumen. Menguasai itu, dan sistem Anda skala dengan sopan. Mengabaikannya, dan mereka hancur di bawah beban puncak.

Kutipan di atas menunjukkan bahwa bahkan jembatan yang paling kuat dan dirancang dengan baik tidak dapat menahan kekuatan destruktif banjir yang tidak terkendali dan tidak terkendali.Sistem Distribusi, panggilan yang tidak terkontrol sering dapat membebani seluruh sistem dan menyebabkan kaskadingkegagalan.

Dalam aArtikel sebelumnya, Saya menulis tentang bagaimana badai retry memiliki potensi untuk mengambil seluruh layanan jika pelindung yang tepat tidak ada di tempat. di sini, saya mengeksplorasi kapan layanan harus mempertimbangkan menerapkan backpressure pada panggilan, bagaimana itu dapat diterapkan, dan apa yang dapat dilakukan oleh panggilan untuk mengatasi hal itu.

Backpressure

Seperti namanya, backpressure adalah mekanisme dalam sistem yang didistribusikan yang mengacu pada kemampuan suatu sistem untuk mengecilkan kecepatan dengan mana data dikonsumsi atau diproduksi untuk mencegah overloading dirinya atau komponennya downstream.Sistem yang menerapkan backpressure pada callernya tidak selalu eksplisit, seperti dalam bentuk throttling atau beban buang, tetapi kadang-kadang juga implisit, seperti memperlambat sistemnya sendiri dengan menambahkan latensi pada permintaan yang disampaikan tanpa secara eksplisit tentang hal itu.

Both implicit and explicit backpressure intend to slow down the caller, either when the caller is not behaving well or the service itself is unhealthy and needs time to recover.

Need for Backpressure

Dalam contoh ini, kami membangun layanan kontrol plan dengan tiga komponen utama: frontend di mana permintaan pelanggan diterima, barisan internal di mana permintaan pelanggan dibongkar, dan aplikasi konsumen yang membaca pesan dari barisan dan menulis ke database untuk persistensi.

Producer-Consumer Mismatch

Pertimbangkan skenario di mana aktor / pelanggan memukul ujung depan dengan kecepatan tinggi sehingga baik baris internal penuh atau karyawan yang menulis ke database sibuk, yang mengarah ke baris penuh. Dalam hal itu, permintaan tidak dapat diisi, jadi alih-alih melepaskan permintaan pelanggan, lebih baik untuk menginformasikan pelanggan terlebih dahulu. Ketidaksamaan ini dapat terjadi karena berbagai alasan, seperti ledakan lalu lintas masuk atau kelemahan kecil dalam sistem di mana konsumen telah turun untuk beberapa waktu tetapi sekarang harus bekerja ekstra untuk membuang backlog yang terakumulasi selama downtime.

Resource Constraints and Cascading Failures

Misalnya, Anda dapat menghitung berapa lama waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu yang dibutuhkan untuk menghitung waktu.MTTRMengaplikasikan backpressure di tempat-tempat yang tepat menjadi penting dalam skenario tersebut.

Missed SLAs

Pertimbangkan skenario di mana data yang ditulis ke database diproses setiap 5 menit, dan aplikasi lain mendengarkan untuk tetap up-to-date.Sekarang, jika sistem tidak dapat memenuhi SLA itu karena alasan apa pun, seperti barisan yang 90% penuh dan berpotensi memakan waktu hingga 10 menit untuk menghapus semua pesan, lebih baik menggunakan teknik backpressure.

Anda dapat memberi tahu pelanggan bahwa Anda akan melewatkan SLA dan meminta mereka untuk mencoba lagi nanti, atau menerapkan tekanan balik dengan melepaskan permintaan yang tidak mendesak dari barisan untuk memenuhi SLA untuk peristiwa / permintaan kritis.

Backpressure Challenges

Berdasarkan apa yang dijelaskan di atas, tampaknya kita harus selalu menerapkan backpressur, dan tidak seharusnya ada perdebatan tentang hal itu.Apakahkita harus menerapkan tekanan balik, tetapi sebagian besar sekitarBagaimanauntuk mengidentifikasi titik-titik yang tepat untuk menerapkan backpressure dan mekanisme untuk menerapkannya yang memenuhi kebutuhan layanan / bisnis tertentu.

Backpressure memaksa kompromi antara output dan stabilitas, yang lebih kompleks oleh tantangan prediksi beban.

Identifying the Backpressure Points

Find Bottlenecks/Weak Links

Pikirkan sistem di mana armada pesawat data besar (ibu-ribu host) bergantung pada armada pesawat kontrol kecil (kurang dari 5 host) untuk menerima konfigurasi yang bertahan dalam database, seperti yang ditunjukkan dalam diagram di atas.

Dalam hal ini, untuk melindungi dirinya sendiri, armada kecil harus memiliki mekanisme untuk menerapkan backpressur pada panggilan. Hubungan lemah lain yang umum dalam arsitektur adalah komponen terpusat yang membuat keputusan tentang seluruh sistem, seperti anti-entropy scanner.

Use System Dynamics: Monitors/Metrics

Cara lain yang umum untuk menemukan titik backpressure untuk sistem Anda adalah dengan memiliki monitor / metrik yang tepat di tempat. terus memantau perilaku sistem, termasuk kedalaman baris, pemanfaatan CPU / memori, dan output jaringan. Gunakan data real-time ini untuk mengidentifikasi hambatan botol yang muncul dan menyesuaikan titik backpressure sesuai.

Menciptakan tampilan agregat melalui metrik atau pengamat seperti kanari kinerja di berbagai komponen sistem adalah cara lain untuk mengetahui bahwa sistem Anda berada di bawah tekanan dan harus mengklaim backpressure pada pengguna / panggilan. kanari kinerja ini dapat diisolasi untuk aspek yang berbeda dari sistem untuk menemukan titik tenggelam. juga, memiliki dashboard real-time pada penggunaan sumber daya internal adalah cara lain yang bagus untuk menggunakan dinamika sistem untuk menemukan titik-titik minat dan lebih proaktif.

Boundaries: The Principle of Least Astonishment

Hal yang paling jelas bagi pelanggan adalah area permukaan layanan dengan mana mereka berinteraksi. Ini biasanya adalah API yang digunakan pelanggan untuk mendapatkan permintaan mereka disampaikan. Ini juga adalah tempat di mana pelanggan akan paling sedikit terkejut dalam kasus backpressure, karena jelas menunjukkan bahwa sistem berada di bawah tekanan. Ini bisa dalam bentuk throttling atau pengeluaran beban.

Prinsip yang sama dapat diterapkan dalam layanan itu sendiri di berbagai subkomponen dan antarmuka yang berbeda melalui mana mereka berinteraksi satu sama lain. permukaan ini adalah tempat terbaik untuk melakukan backpressure.

How to Apply Backpressure in Distributed Systems

Dalam bagian terakhir, kami berbicara tentang cara menemukan titik-titik yang tepat untuk menegaskan backpressure.Setelah kita tahu titik-titik itu, berikut adalah beberapa cara kita dapat menegaskan backpressure ini dalam praktek:

Menggunakan Flow Control yang jelas

The idea is to make the queue size visible to your callers and let them control the call rate based on that. By knowing the queue size (or any resource that is a bottleneck), they can increase or decrease the call rate to avoid overwhelming the system. This kind of technique is particularly helpful where multiple internal components work together and behave as well as they can without impacting each other. The equation below can be used anytime to calculate the caller rate. Note: The actual call rate will depend on various other factors, but the equation below should give a good idea.

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

CallRate_new = CallRate_normal * (1 - (Q_currentSize / Q_maxSize))

Invert Responsibilities

Dalam beberapa sistem, adalah mungkin untuk mengubah urutan di mana panggilan tidak secara eksplisit mengirimkan permintaan ke layanan tetapi membiarkan permintaan layanan bekerja sendiri ketika siap untuk melayani. teknik jenis ini memberi layanan penerima kontrol penuh atas berapa banyak yang dapat dilakukan dan dapat secara dinamis mengubah ukuran permintaan berdasarkan status terbaru.Token untuk BucketStrategi di mana layanan penerima mengisi token, dan yang memberitahu pemanggil kapan dan berapa banyak yang dapat mereka kirim ke server.

  # Service requests work if it has capacity

 if Tokens_available > 0: 

             Work_request_size = min (Tokens_available, Work_request_size _max) # Request work, up to a maximum limit 

             send_request_to_caller(Work_request_size) # Caller sends work if it has enough tokens

 

if Tokens_available >= Work_request_size: 

send_work_to_service(Work_request_size)

             Tokens_available = Tokens_available – Work_request_size

# Tokens are replenished at a certain rate

Tokens_available = min (Tokens_available + Token_Refresh_Rate, Token_Bucket_size)

Proactive Adjustments

Kadang-kadang, Anda tahu sebelumnya bahwa sistem Anda akan menjadi tertekan segera, dan Anda mengambil langkah-langkah proaktif seperti meminta pemanggil untuk memperlambat volume panggilan dan perlahan-lahan meningkatkan.

Selama periode itu, Anda menunggui semua pekerjaan dan sekarang siap untuk membuangnya untuk memenuhi kebutuhan Anda.SelaKetika Anda membuangnya lebih cepat dari tingkat normal, Anda berisiko kehilangan layanan downstream.Untuk mengatasi ini, Anda secara proaktif membatasi batas panggilan atau melibatkan panggilan untuk mengurangi volume panggilan dan perlahan-lahan membuka gerbang banjir.

Throttling

Membatasi jumlah permintaan layanan dapat melayani dan membuang permintaan di luar itu. Throttling dapat diterapkan pada tingkat layanan atau tingkat API. throttling ini adalah indikator langsung dari backpressure untuk panggilan untuk memperlambat volume panggilan. Anda dapat mengambil ini lebih jauh dan melakukan throttling prioritas atau fairness throttling untuk memastikan bahwa dampak terkecil terlihat oleh pelanggan.

Load Shedding

Throttling menunjuk pada penolakan permintaan ketika Anda melanggar beberapa batasan yang telah ditentukan sebelumnya. permintaan pelanggan masih dapat ditolak jika layanan menghadapi stres dan memutuskan untuk secara proaktif menurunkan permintaan yang telah dijanjikan untuk melayani.

Conclusion

Backpressure adalah tantangan penting dalam sistem terdistribusi yang dapat berdampak signifikan pada kinerja dan stabilitas.Memahami penyebab dan efek backpressure, bersama dengan teknik manajemen yang efektif, sangat penting untuk membangun sistem terdistribusi yang kuat dan berkinerja tinggi.

Namun, jika disalahgunakan, itu dapat merusak kepercayaan pelanggan dan bahkan berkontribusi pada ketidakstabilan sistem. Proaktif mengatasi backpressure melalui desain sistem yang hati-hati dan pemantauan adalah kunci untuk mempertahankan kesehatan sistem. Sementara menerapkan backpressure dapat melibatkan kompromi, seperti berpotensi mempengaruhi output, manfaat dalam hal resiliensi keseluruhan sistem dan kepuasan pengguna substansial.