Bagikan melalui

Pendekatan arsitektural untuk komputasi dalam solusi multi-penyewa

  • Artikel

Sebagian besar solusi berbasis cloud terdiri dari sejenis sumber daya komputasi, seperti tingkat web dan aplikasi, prosesor batch, pekerjaan terjadwal, dan bahkan sumber daya khusus seperti GPU dan komputasi berkinerja tinggi (HPC). Solusi multitenant sering mendapat manfaat dari sumber daya komputasi bersama. Hal ini karena kepadatan penyewa yang lebih tinggi terhadap infrastruktur akan mengurangi biaya operasional dan manajemen. Sebaiknya pertimbangkan persyaratan isolasi dan implikasi dari infrastruktur bersama.

Artikel ini memberikan panduan tentang pertimbangan dan persyaratan yang penting untuk dipertimbangkan oleh arsitek solusi saat merencanakan tingkat komputasi multipenyewa. Ini termasuk beberapa pola umum untuk menerapkan multitenancy bagi layanan komputasi, beserta beberapa antipattern yang harus dihindari.

Pertimbangan dan persyaratan utama

Multitenancy dan model isolasi yang Anda pilih akan memengaruhi penskalaan, performa, manajemen status, dan keamanan sumber daya komputasi Anda. Pada bagian ini, kami meninjau beberapa keputusan utama yang harus Anda buat ketika merencanakan solusi komputasi multitenant.

Sisik

Sistem harus memiliki performa yang memadai di bawah perubahan permintaan. Karena jumlah penyewa dan jumlah lalu lintas meningkat, Anda mungkin perlu meningkatkan kapasitas sumber daya untuk mengikuti peningkatan jumlah penyewa dan untuk mempertahankan tingkat performa yang dapat diterima. Demikian pula, ketika jumlah pengguna aktif atau jumlah lalu lintas menurun, Anda harus secara otomatis mengurangi kapasitas komputasi untuk mengurangi biaya, tetapi Anda harus mengurangi kapasitas dengan dampak minimal bagi pengguna.

Jika menerapkan sumber daya khusus untuk setiap penyewa, Anda memiliki fleksibilitas untuk menskalakan sumber daya setiap penyewa secara mandiri. Dalam solusi dengan sumber daya komputasi yang dibagi antara beberapa penyewa, jika Anda menskalakan sumber daya tersebut, semua penyewa tersebut dapat menggunakan skala baru tersebut. Namun, mereka semua juga akan merasakan dampak buruknya ketika skala tidak cukup untuk menangani beban mereka secara keseluruhan. Untuk informasi selengkapnya, lihat Masalah Tetangga yang Bising.

Saat membangun solusi cloud, Anda dapat memilih apakah akan menskalakan secara horizontal atau vertikal. Dalam solusi multitenant dengan jumlah penyewa yang semakin banyak, penskalaan secara horizontal biasanya memberi Anda fleksibilitas yang lebih besar dan batas maksimum skala yang lebih tinggi secara keseluruhan.

Masalah performa sering tetap tidak terdeteksi sampai aplikasi berada di bawah beban. Anda dapat menggunakan layanan yang dikelola sepenuhnya, seperti Azure Load Testing, untuk mempelajari bagaimana aplikasi Anda berulah di bawah tekanan.

Pemicu skala

Pendekatan apa pun yang digunakan untuk melakukan penskalaan, Anda biasanya perlu merencanakan pemicu yang menyebabkan komponen Anda melakukan penskalaan. Ketika Anda telah berbagi komponen, pertimbangkan pola beban kerja setiap penyewa yang menggunakan sumber daya, untuk memastikan kapasitas yang disediakan dapat memenuhi total kapasitas yang diperlukan, dan untuk meminimalkan kemungkinan penyewa mengalami masalah Noisy Neighbor. Anda mungkin juga dapat merencanakan kapasitas penskalaan Anda dengan mempertimbangkan jumlah penyewa. Misalnya, jika Anda mengukur sumber daya yang digunakan untuk melayani 100 penyewa, saat menerima lebih banyak penyewa, Anda dapat merencanakan penskalaan sedemikian rupa sehingga sumber daya Anda menjadi dua kali lipat untuk setiap 100 penyewa tambahan.

Provinsi

Sumber daya komputasi bisa menjadi tanpa status atau berstatus. Komponen tanpa status tidak menyimpan data apa pun di antara permintaan. Dari perspektif skalabilitas, komponen tanpa status sering kali mudah diskalakan karena Anda dapat dengan cepat menambahkan pekerja, instans, atau node baru, dan mereka dapat segera mulai memproses permintaan. Jika arsitektur Anda memungkinkan hal ini, Anda juga dapat menggunakan kembali instans yang ditetapkan ke satu penyewa dan mengalokasikannya ke penyewa lain.

Sumber daya berstatus dapat dibagi lagi berdasarkan jenis status yang dipertahankan. Status persisten adalah data yang perlu disimpan secara permanen. Dalam solusi cloud, Anda harus menghindari penyimpanan status persisten di tingkat komputasi Anda. Sebagai gantinya, gunakan layanan penyimpanan seperti database atau akun penyimpanan. Status sementara adalah data yang disimpan sementara, yang mencakup cache dalam memori baca-saja dan penyimpanan file sementara pada disk lokal.

Status sementara sering berguna untuk meningkatkan performa tingkat aplikasi Anda, dengan mengurangi jumlah permintaan ke layanan penyimpanan backend. Misalnya, saat menggunakan cache dalam memori, Anda mungkin dapat melayani permintaan baca, tanpa menyambungkan ke database, dan tanpa melakukan kueri intensif yang baru saja Anda lakukan saat melayani permintaan lain.

Dalam aplikasi yang sensitif terhadap latensi, biaya hidrasi cache dapat menjadi signifikan. Solusi multitenant dapat memperburuk masalah ini, jika setiap penyewa membutuhkan data yang berbeda untuk di-cache. Untuk memitigasi masalah ini, beberapa solusi menggunakan afinitas sesi guna memastikan bahwa semua permintaan untuk pengguna atau penyewa tertentu diproses oleh node pekerja komputasi yang sama. Meskipun afinitas sesi dapat meningkatkan kemampuan tingkat aplikasi untuk menggunakan cache secara efektif, hal ini juga mempersulit penskalaan dan penyeimbangan beban lalu lintas di seluruh pekerja. Pertukaran manfaat dan kerugian ini perlu dipertimbangkan dengan cermat. Untuk banyak aplikasi, afinitas sesi tidak diperlukan.

Anda juga dapat menyimpan data dalam cache eksternal, seperti Azure Cache for Redis. Cache eksternal dioptimalkan untuk pengambilan data latensi rendah, sekaligus menjaga status terisolasi dari sumber daya komputasi, sehingga dapat diskalakan dan dikelola secara terpisah. Dalam banyak solusi, cache eksternal memungkinkan Anda meningkatkan performa aplikasi sekaligus menjaga tingkat komputasi agar tetap tanpa status.

Penting

Jangan membocorkan data antara penyewa setiap kali Anda menggunakan cache dalam memori atau komponen lain yang mempertahankan status. Misalnya, sebaiknya tambahkan pengidentifikasi penyewa sebagai awalan pada semua kunci cache guna memastikan bahwa data dipisahkan untuk setiap penyewa.

Isolasi

Ketika mendesain tingkat komputasi multitenant, Anda sering kali memiliki banyak opsi untuk mempertimbangkan tingkat isolasi antara penyewa, termasuk menyebarkan sumber daya komputasi bersama, yang akan digunakan oleh semua penyewa, sumber daya komputasi khusus untuk setiap penyewa, atau sesuatu di antara kedua hal ini. Setiap opsi memiliki manfaat dan kerugiannya masing-masing. Untuk membantu memutuskan opsi mana yang paling sesuai dengan solusi Anda, pertimbangkan kebutuhan isolasi Anda.

Anda mungkin khawatir dengan isolasi logis penyewa, dan bagaimana memisahkan tanggung jawab manajemen atau kebijakan yang diterapkan pada setiap penyewa. Atau, Anda mungkin perlu menyebarkan konfigurasi sumber daya yang berbeda untuk penyewa tertentu, seperti menyebarkan SKU mesin virtual tertentu agar sesuai dengan beban kerja penyewa.

Terlepas dari model isolasi yang dipilih, pastikan Anda memverifikasi bahwa data penyewa tetap terisolasi dengan sesuai, bahkan jika komponen tidak tersedia atau tidak berfungsi. Sebaiknya gunakan Azure Chaos Studio sebagai bagian dari proses pengujian otomatis reguler Anda. Hal ini bertujuan untuk secara sengaja memperkenalkan kesalahan yang menyimulasikan pemadaman yang sebenarnya, serta memverifikasi bahwa solusi Anda tidak membocorkan data antarpenyewa dan berfungsi dengan baik di bawah tekanan sekalipun.

Pendekatan dan pola yang perlu dipertimbangkan

Skala Otomatis

Layanan komputasi Azure menyediakan berbagai kemampuan untuk menskalakan beban kerja Anda. Banyak layanan komputasi mendukung penskalaan otomatis, yang mengharuskan Anda untuk mempertimbangkan waktu penskalaan serta tingkat skala minimum dan maksimum. Opsi tertentu yang tersedia untuk penskalaan bergantung pada layanan komputasi yang Anda gunakan. Lihat contoh layanan berikut:

Pola Stempel Penyebaran

Untuk informasi selengkapnya tentang bagaimana pola Deployment Stamps dapat digunakan untuk mendukung solusi multitenant, lihat Gambaran Umum.

Pola Konsolidasi Sumber Daya Komputasi

Pola Konsolidasi Sumber Daya Komputasi membantu Anda mencapai kepadatan penyewa yang lebih tinggi terhadap infrastruktur komputasi, dengan berbagi sumber daya komputasi dasar. Dengan berbagi sumber daya komputasi, Anda sering kali dapat mengurangi biaya langsung dari sumber daya tersebut. Selain itu, biaya manajemen Anda sering kali lebih rendah karena ada lebih sedikit komponen untuk dikelola.

Namun, konsolidasi sumber daya komputasi meningkatkan kemungkinan masalah Tetangga yang Bising. Beban kerja penyewa mana pun mungkin mengonsumsi kapasitas komputasi yang tersedia dalam jumlah yang tidak proporsional. Anda sering kali dapat memitigasi risiko ini dengan memastikan penskalaan solusi secara tepat, dan dengan menerapkan kontrol seperti kuota dan batas API, untuk menghindari penyewa yang melakukan konsumsi melebihi porsi kapasitas yang adil.

Pola ini dapat dicapai dengan berbagai cara, tergantung pada layanan komputasi yang Anda gunakan. Lihat contoh layanan berikut:

  • Azure App Service dan Azure Functions: Sebarkan paket App Service bersama, yang mewakili infrastruktur server hosting.
  • Azure Container Apps: Sebarkan lingkungan bersama.
  • Azure Kubernetes Service (AKS): Sebarkan pod bersama, dengan aplikasi yang peka terhadap multitenancy.
  • Mesin virtual: Sebarkan satu set mesin virtual untuk digunakan semua penyewa.

Sumber daya komputasi khusus per penyewa

Anda juga dapat menyebarkan sumber daya komputasi khusus untuk setiap penyewa. Sumber daya khusus mengurangi risiko masalah Noisy Neighbor, dengan memastikan bahwa sumber daya komputasi untuk setiap penyewa diisolasi dari yang lain. Ini juga memungkinkan Anda menyebarkan konfigurasi yang berbeda untuk sumber daya masing-masing penyewa berdasarkan kebutuhan mereka. Namun, sumber daya khusus biasanya datang dengan biaya yang lebih tinggi, karena Anda memiliki kepadatan penyewa yang lebih rendah ke sumber daya.

Bergantung pada layanan komputasi Azure yang digunakan, Anda perlu menyebarkan sumber daya khusus yang berbeda sebagai berikut:

  • Azure App Service dan Azure Functions: Sebarkan paket App Service terpisah untuk setiap penyewa.
  • Azure Container Apps: Sebarkan lingkungan terpisah untuk setiap penyewa.
  • Azure Kubernetes Service (AKS): Sebarkan kluster khusus untuk setiap penyewa.
  • Mesin virtual: Sebarkan mesin virtual khusus untuk setiap penyewa.

Sumber daya komputasi semi-terisolasi

Pendekatan semi-terisolasi mengharuskan Anda untuk menyebarkan aspek solusi dalam konfigurasi yang terisolasi sekaligus berbagi komponen lainnya.

Saat bekerja dengan App Service dan Azure Functions, Anda dapat menyebarkan aplikasi yang berbeda untuk setiap penyewa, dan Anda dapat menghosting aplikasi pada paket App Service bersama. Pendekatan ini mengurangi biaya tingkat komputasi Anda karena paket App Service mewakili unit penagihan. Ini juga memungkinkan Anda menerapkan konfigurasi dan kebijakan yang berbeda untuk setiap aplikasi. Namun, pendekatan ini memiliki risiko masalah Tetangga yang Bising.

Azure Container Apps memungkinkan Anda menyebarkan beberapa aplikasi ke lingkungan bersama, lalu menggunakan Dapr dan alat lainnya untuk mengonfigurasi setiap aplikasi secara terpisah.

Azure Kubernetes Service (AKS), dan Kubernetes pada umumnya, menyediakan berbagai opsi untuk multitenancy, termasuk opsi berikut:

  • Namespace layanan khusus penyewa, untuk isolasi logis sumber daya khusus penyewa, yang disebarkan ke kumpulan node dan kluster bersama.
  • Node atau kumpulan node khusus penyewa pada kluster bersama.
  • Pod khusus penyewa yang mungkin menggunakan kumpulan node yang sama.

AKS juga memungkinkan Anda menerapkan tata kelola tingkat pod untuk memitigasi masalah Tetangga yang Bising. Untuk informasi selengkapnya, lihat Praktik terbaik bagi pengembang aplikasi untuk mengelola sumber daya di Azure Kubernetes Service (AKS).

Penting juga untuk mengetahui komponen bersama dalam kluster Kubernetes, serta bagaimana komponen ini dapat dipengaruhi oleh multitenancy. Misalnya, server Kubernetes API adalah layanan bersama yang digunakan di seluruh kluster. Bahkan jika Anda menyediakan kumpulan node khusus penyewa untuk mengisolasi beban kerja aplikasi penyewa, server API mungkin mengalami perlawanan dari sejumlah besar permintaan di seluruh penyewa.

Antipattern yang perlu dihindari

Antipattern Tetangga yang bising

Setiap kali Anda menyebarkan komponen yang dibagikan antarpenyewa, masalah Tetangga yang Bising adalah risiko yang mungkin terjadi. Pastikan Anda menyertakan tata kelola dan pemantauan sumber daya untuk memitigasi risiko beban kerja komputasi penyewa yang terpengaruh oleh aktivitas penyewa lain.

Kebocoran data lintas penyewa

Tingkat komputasi dapat mengalami kebocoran data lintas penyewa jika tidak ditangani dengan benar. Secara umum, ini bukan sesuatu yang perlu dipertimbangkan jika Anda menggunakan layanan multitenant di Azure, karena Microsoft menyediakan perlindungan di lapisan platform. Namun, jika Anda mengembangkan aplikasi multitenant Anda sendiri, pertimbangkan apakah ada sumber daya bersama (seperti cache disk lokal, RAM, dan cache eksternal) yang mungkin berisi data yang dapat dilihat atau dimodifikasi oleh penyewa lain secara tidak sengaja.

Antipattern Front End yang Sibuk

Untuk menghindari antipattern Front End yang Sibuk, jangan sampai tingkat front end Anda melakukan banyak pekerjaan yang dapat ditangani oleh komponen atau tingkat arsitektur Anda yang lain. Antipattern ini sangat penting ketika Anda membuat front-end bersama untuk solusi multitenant, karena front end yang sibuk akan menurunkan kualitas pengalaman bagi semua penyewa.

Sebagai gantinya, sebaiknya gunakan pemrosesan asinkron dengan memanfaatkan antrean atau layanan olah pesanan lainnya. Pendekatan ini juga memungkinkan Anda menerapkan kontrol kualitas layanan (QoS) untuk berbagai penyewa berdasarkan kebutuhan mereka. Misalnya, semua penyewa mungkin memiliki tingkat front end umum yang sama, tetapi penyewa yang membayar tingkat layanan yang lebih tinggi mungkin memiliki satu set sumber daya khusus yang lebih tinggi untuk memproses pekerjaan dari pesan antrean mereka.

Penskalaan nonelastis atau tidak mencukupi

Solusi multitenant sering kali mengalami pola skala yang melonjak. Komponen bersama sangat rentan terhadap masalah ini karena cakupan untuk lonjakan lebih tinggi, dan dampaknya lebih besar jika Anda memiliki lebih banyak penyewa dengan pola penggunaan yang berbeda.

Pastikan Anda memanfaatkan elastisitas dan skala cloud dengan baik. Pertimbangkan apakah Anda harus menggunakan penskalaan horizontal atau vertikal, dan gunakan penskalaan otomatis untuk menangani lonjakan beban secara otomatis. Uji solusi Anda untuk memahami bagaimana perilakunya di bawah berbagai tingkat beban. Pastikan Anda memasukkan volume beban yang diharapkan dalam produksi dan pertumbuhan yang Anda harapkan. Anda dapat menggunakan layanan yang dikelola sepenuhnya, seperti Azure Load Testing, untuk mempelajari bagaimana aplikasi Anda berulah di bawah tekanan.

Tidak ada antipola Penembolokan

Antipattern Tidak Ada Penembolokan adalah ketika solusi Anda berperforma buruk karena tingkat aplikasi berulang kali meminta atau mengomputasi ulang informasi yang dapat digunakan kembali di seluruh permintaan. Jika Anda memiliki data yang dapat dibagikan, baik antarpenyewa atau pengguna dalam satu penyewa, mungkin sebaiknya Anda menyimpannya dalam cache untuk mengurangi beban pada tingkat backend/database Anda.

Kondisi berstatus yang tidak perlu

Konsekuensi dari antipattern Tidak Ada Penembolokan adalah Anda juga harus menghindari penyimpanan status yang tidak perlu di tingkat komputasi. Bersikaplah eksplisit terkait lokasi dan alasan penyimpanan status. Tingkat front-end atau aplikasi yang berstatus dapat mengurangi kemampuan penskalaan Anda. Tingkat komputasi stateful biasanya juga memerlukan afinitas sesi, yang dapat mengurangi kemampuan Anda untuk memuat lalu lintas keseimbangan secara efektif, di seluruh pekerja atau simpul.

Pertimbangkan manfaat dan kerugian untuk setiap status yang dipertahankan di tingkat komputasi Anda, dan pertimbangkan apakah status tersebut memengaruhi kemampuan Anda untuk melakukan penskalaan atau pertumbuhan seiring berubahnya pola beban kerja penyewa Anda. Anda juga dapat menyimpan status dalam cache eksternal, seperti Azure Cache for Redis.

Kontributor

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

Penulis utama:

  • Dixit Arora | Insinyur Pelanggan Senior, FastTrack untuk Azure
  • John Downs | Insinyur Perangkat Lunak Utama

Kontributor lain:

Langkah berikutnya

Tinjau panduan khusus layanan untuk layanan komputasi Anda: