Edit

Bagikan melalui

Antipattern Tetangga yang bising

Azure

Sistem multipenyewa berbagi sumber daya antara dua penyewa atau lebih. Karena penyewa menggunakan sumber daya bersama yang sama, aktivitas satu penyewa dapat berdampak negatif pada penggunaan sistem penyewa lain.

Deskripsi masalah

Saat Anda membangun layanan yang akan dibagikan oleh beberapa pelanggan atau penyewa, Anda dapat membuatnya menjadi multipenyewa. Keuntungan dari sistem multipenyewa adalah sumber daya dapat dikumpulkan dan dibagi di antara penyewa. Hal ini sering menghasilkan biaya yang lebih rendah dan peningkatan efisiensi. Namun, jika satu penyewa menggunakan jumlah sumber daya yang tersedia dalam sistem secara tidak proporsional, performa sistem secara keseluruhan dapat terganggu. Masalah tetangga yang bising terjadi ketika performa penyewa menurun karena aktivitas penyewa lain.

Pertimbangkan contoh sistem multipenyewa dengan dua penyewa. Pola penggunaan penyewa A dan pola penggunaan penyewa B bertepatan. Pada waktu sibuk, penyewa A menggunakan semua sumber daya sistem, yang berarti bahwa setiap permintaan yang dijadikan penyewa B gagal. Dengan kata lain, total penggunaan sumber daya lebih tinggi dari kapasitas sistem:

Gambar yang menunjukkan penggunaan sumber daya dari dua penyewa. Penyewa A menggunakan seperangkat sumber daya sistem yang lengkap, yang berarti B mengalami kegagalan.

Kemungkinan permintaan penyewa mana pun yang tiba terlebih dahulu akan diutamakan. Kemudian penyewa lain akan mengalami masalah, yaitu tetangga yang bising. Atau, kedua penyewa mungkin menemukan performanya menderita.

Masalah tetangga yang bising juga terjadi bahkan ketika setiap penyewa individu menggunakan jumlah kapasitas sistem yang relatif kecil, tetapi penggunaan sumber daya kolektif dari banyak penyewa menghasilkan puncak dalam penggunaan keseluruhan:

Gambar dengan 3 penyewa, masing-masing menggunakan lebih sedikit throughput maksimum dari solusi. Total, tiga penyewa menggunakan sumber daya sistem yang lengkap.

Situasi ini dapat terjadi ketika Anda memiliki beberapa penyewa yang semuanya memiliki pola penggunaan serupa, atau di mana Anda belum menyediakan kapasitas yang memadai untuk beban kolektif pada sistem.

Cara memperbaiki masalah ini

Masalah tetangga yang bising adalah risiko yang melekat ketika Anda berbagi satu sumber daya, dan tidak mungkin untuk sepenuhnya menghilangkan kemungkinan terpengaruh oleh tetangga yang berisik. Namun, ada beberapa langkah yang dapat dilakukan klien dan penyedia layanan untuk mengurangi kemungkinan masalah tetangga yang bising, atau untuk mengurangi efeknya ketika mereka diamati.

Tindakan yang dapat dilakukan klien

Tindakan yang dapat dilakukan penyedia layanan

  • Pantau penggunaan sumber daya untuk sistem Anda. Pantau penggunaan sumber daya keseluruhan dan sumber daya yang digunakan setiap penyewa. Konfigurasikan peringatan untuk mendeteksi lonjakan penggunaan sumber daya, dan jika memungkinkan, konfigurasikan automasi untuk otomatis mengurangi masalah yang diketahui dengan meningkatkan atau memperluas.
  • Menerapkan tata kelola sumber daya. Pertimbangkan untuk menerapkan kebijakan yang menghindari penyewa tunggal yang membuat sistem kewalahan dan mengurangi kapasitas yang tersedia untuk orang lain. Langkah ini dapat berupa pemberlakuan kuota, melalui Pola pembatasan atau Pola Pembatasan Tarif.
  • Provisikan lebih banyak infrastruktur. Proses ini mungkin melibatkan peningkatan skala dengan memutakhirkan beberapa komponen solusi Anda, atau mungkin melibatkan peluasan skala dengan menyediakan pecahan tambahan, jika Anda mengikuti Pola pecahan, atau stempel, jika Anda mengikuti Pola Stempel Penyebaran.
  • Aktifkan penyewa untuk membeli kapasitas yang telah disediakan atau dipesan sebelumnya. Kapasitas ini memberi penyewa lebih pasti bahwa solusi Anda secara memadai menangani beban kerja mereka.
  • Memperlancar penggunaan sumber daya penyewa. Misalnya, Anda dapat mencoba salah satu pendekatan berikut:
    • Jika Anda meng-hosting beberapa instans dari solusi Anda, pertimbangkan untuk menyeimbangkan kembali penyewa di seluruh instans atau stempel. Misalnya, pertimbangkan untuk menempatkan penyewa dengan pola penggunaan yang dapat diprediksi dan serupa di beberapa stempel, untuk meratakan puncak penggunaannya.
    • Pertimbangkan apakah Anda memiliki proses latar belakang atau beban kerja sumber daya intensif yang tidak sensitif terhadap waktu. Jalankan beban kerja ini secara asinkron pada waktu di luar puncak, untuk mempertahankan kapasitas sumber daya puncak Anda untuk beban kerja yang sensitif terhadap waktu.
  • Periksa apakah layanan hilir Anda memberikan kontrol untuk mengurangi masalah tetangga yang bising. Misalnya, saat menggunakan Kubernetes, pertimbangkan untuk menggunakan batas pod, dan saat menggunakan Service Fabric, pertimbangkan untuk menggunakan kemampuan tata kelola bawaan.
  • Batasi operasi yang dapat dilakukan penyewa. Misalnya, batasi penyewa agar tidak menjalankan operasi yang akan menjalankan kueri database yang sangat besar, seperti dengan menentukan jumlah rekaman maksimum yang dapat dikembalikan atau batas waktu pada kueri. Tindakan ini mengurangi risiko penyewa mengambil tindakan yang mungkin berdampak negatif bagi penyewa lain.
  • Menyediakan sistem Quality of Service (QoS). Saat menerapkan QoS, Anda memprioritaskan beberapa proses atau beban kerja daripada yang lain. Dengan memfaktorkan QoS ke dalam desain dan arsitektur Anda, Anda dapat memastikan bahwa operasi prioritas tinggi diutamakan ketika ada tekanan pada sumber daya Anda.

Pertimbangan

Dalam kebanyakan kasus, penyewa individu tidak berniat menyebabkan masalah tetangga yang bising. Penyewa individu bahkan mungkin tidak menyadari bahwa beban kerja mereka menyebabkan masalah tetangga yang bising bagi orang lain. Namun, ada kemungkinan juga bahwa beberapa penyewa dapat mengeksploitasi kerentanan dalam komponen bersama untuk menyerang layanan, baik secara individual atau dengan menjalankan serangan penolakan layanan terdistribusi (DDoS).

Terlepas dari penyebabnya, penting untuk memandang masalah ini sebagai masalah tata kelola sumber daya, dan untuk menerapkan kuota penggunaan, pembatasan, dan kontrol tata kelola untuk mengurangi masalah.

Catatan

Pastikan Anda memberi tahu klien Anda mengenai pembatasan apa pun yang diterapkan, atau kuota penggunaan apa pun pada layanan Anda. Ini sangat penting agar mereka menangani permintaan yang gagal dengan andal, dan mereka tidak terkejut dengan batasan atau kuota yang Anda terapkan.

Cara mendeteksi masalah

Dari perspektif klien, masalah tetangga yang berisik biasanya bermanifestasi sebagai permintaan yang gagal ke layanan, atau sebagai permintaan yang membutuhkan waktu lama untuk diselesaikan. Secara khusus, jika permintaan yang sama berhasil di lain waktu dan tampaknya gagal secara acak, mungkin ada masalah tetangga yang bising. Aplikasi klien akan mencatat telemetri untuk melacak tingkat keberhasilan dan performa permintaan ke layanan, dan aplikasi juga akan mencatat metrik performa dasar untuk tujuan perbandingan.

Dari perspektif layanan, masalah tetangga yang bising mungkin muncul dalam beberapa cara:

  • Lonjakan penggunaan sumber daya. Sangat penting untuk memiliki pemahaman yang jelas tentang penggunaan sumber daya dasar normal Anda, dan untuk mengonfigurasi pemantauan serta peringatan untuk mendeteksi lonjakan penggunaan sumber daya. Pastikan Anda mempertimbangkan semua sumber daya yang dapat memengaruhi performa atau ketersediaan layanan Anda. Sumber daya ini meliputi metrik seperti CPU server dan penggunaan memori, IO disk, penggunaan database, lalu lintas jaringan, dan metrik yang diekspos oleh layanan terkelola, seperti jumlah permintaan dan metrik performa sintetis dan abstrak, seperti unit permintaan Azure Cosmos DB.
  • Kegagalan saat melakukan operasi untuk penyewa. Secara khusus, cari kegagalan yang terjadi ketika penyewa tidak menggunakan sebagian besar sumber daya sistem. Pola seperti itu mungkin menunjukkan bahwa penyewa adalah korban dari masalah tetangga yang bising. Pertimbangkan untuk melacak konsumsi sumber daya oleh penyewa. Misalnya, saat menggunakan Azure Cosmos DB, pertimbangkan untuk mencatat unit permintaan yang digunakan untuk setiap permintaan, dan tambahkan pengidentifikasi penyewa sebagai dimensi ke telemetri, sehingga Anda dapat menggabungkan konsumsi unit permintaan untuk setiap penyewa.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.