Model penyewaan untuk solusi multipenyewa

Ada banyak cara untuk mempertimbangkan cara bekerja dengan penyewa dalam solusi Anda. Pendekatan Anda bergantung pada apakah dan bagaimana Anda berbagi sumber daya di antara penyewa Anda. Secara intuitif, Anda mungkin ingin menghindari berbagi sumber daya apa pun, tetapi pendekatan tersebut dapat dengan cepat menjadi mahal ketika bisnis Anda berkembang dan Anda menerima lebih banyak penyewa.

Ketika Anda mempertimbangkan berbagai model multitenansi, sangat membantu untuk terlebih dahulu mempertimbangkan bagaimana Anda menentukan penyewa untuk organisasi Anda, apa itu driver bisnis Anda, dan bagaimana Anda berencana untuk menskalakan solusi Anda. Artikel ini memberikan panduan untuk membantu pembuat keputusan teknis mengevaluasi model penyewaan dan trade-off mereka.

Menentukan penyewa

Anda harus terlebih dahulu menentukan tenant untuk organisasi Anda. Pertimbangkan siapa pelanggan Anda atau siapa yang menerima layanan Anda. Ada dua model umum:

• Bisnis ke bisnis (B2B): Jika pelanggan Anda adalah organisasi lain, Anda mungkin memetakan penyewa Anda ke pelanggan tersebut. Namun, pertimbangkan apakah pelanggan Anda memiliki divisi, seperti tim atau departemen, dan apakah mereka memiliki kehadiran di beberapa negara atau wilayah. Anda mungkin perlu memetakan satu pelanggan ke beberapa penyewa jika ada persyaratan yang berbeda untuk subgrup ini. Demikian pula, pelanggan mungkin ingin mempertahankan dua instans layanan Anda sehingga mereka dapat menjaga lingkungan pengembangan dan produksi mereka terpisah satu sama lain. Penyewa tunggal biasanya memiliki beberapa pengguna. Misalnya, semua karyawan pelanggan adalah pengguna dalam satu penyewa.

• Business to consumer (B2C): Jika pelanggan Anda adalah konsumen, sering kali lebih rumit untuk menghubungkan pelanggan, penyewa, dan pengguna. Dalam beberapa skenario, setiap konsumen mungkin merupakan penyewa terpisah. Namun, pertimbangkan apakah solusi Anda mungkin digunakan oleh keluarga, kelompok teman, klub, asosiasi, atau grup lain yang mungkin perlu mengakses dan mengelola data mereka bersama-sama. Misalnya, layanan streaming musik mungkin mendukung pengguna individu dan keluarga, dan mungkin memperlakukan masing-masing jenis akun ini secara berbeda ketika memisahkannya menjadi penyewa.

Definisi penyewa Anda memengaruhi beberapa hal yang perlu Anda pertimbangkan atau tekankan ketika Anda merancang solusi Anda. Misalnya, pertimbangkan jenis penyewa berikut:

• Jika penyewa Anda adalah orang atau keluarga individual, Anda mungkin perlu mempertimbangkan bagaimana Anda menangani data pribadi dan tentang undang-undang kedaulatan data di setiap yurisdiksi yang Anda layani.

• Jika penyewa Anda adalah bisnis, Anda mungkin perlu memperhatikan persyaratan pelanggan Anda untuk kepatuhan terhadap peraturan dan isolasi data mereka. Pastikan Anda memenuhi tujuan tingkat layanan (SLO) tertentu, seperti waktu aktif atau ketersediaan layanan.

Memutuskan model mana yang akan digunakan

Memilih model penyewaan bukan hanya keputusan teknis. Ini juga merupakan keputusan komersial. Anda perlu mempertimbangkan pertanyaan-pertanyaan berikut:

• Tujuan bisnis: Pertimbangkan apakah mengurangi biaya untuk setiap penyewa atau memaksimalkan pengalaman penyewa selaras lebih erat dengan tujuan strategis.

• Kepatuhan: Pertimbangkan apakah pelanggan Anda akan menerima semua bentuk multitenancy. Bagaimana setiap model multipenyewa memengaruhi persyaratan kepatuhan atau persyaratan kepatuhan pelanggan Anda?

• Skalabilitas: Pertimbangkan apakah solusi penyewa tunggal dapat mengakomodasi aspirasi pertumbuhan Anda di masa mendatang.

• Otomatisasi: Pertimbangkan ukuran tim operasi Anda dan berapa banyak manajemen infrastruktur yang dapat Anda otomatisasi.

• Perjanjian tingkat layanan (SLA): Pertimbangkan apakah pelanggan Anda mengharapkan Anda untuk memenuhi SLA, atau apakah Anda memiliki SLA yang Anda targetkan.

Jika Anda mengharapkan bisnis Anda untuk menskalakan ke sejumlah besar pelanggan, penting untuk menyebarkan infrastruktur bersama. Jika tidak, Anda harus mempertahankan kumpulan instans sumber daya yang besar dan berkembang. Menyebarkan sumber daya Azure individual untuk setiap pelanggan kemungkinan tidak dapat dipertahankan, kecuali Anda memprovisikan dan menggunakan langganan khusus untuk setiap penyewa. Saat Anda berbagi langganan Azure yang sama di beberapa penyewa, kuota dan batas sumber daya Azure mungkin berlaku, dan biaya operasional untuk menyebarkan dan mengonfigurasi kembali sumber daya ini meningkat dengan setiap pelanggan baru.

Sebaliknya, jika Anda mengharapkan bahwa bisnis Anda hanya akan memiliki beberapa pelanggan, Anda mungkin ingin mempertimbangkan untuk menggunakan sumber daya penyewa tunggal yang didedikasikan untuk setiap pelanggan. Selain itu, jika persyaratan isolasi pelanggan Anda tinggi, pendekatan infrastruktur penyewa tunggal mungkin sesuai meskipun lebih mahal.

Penyewa dan penyebaran

Selanjutnya, Anda perlu menentukan apakah Anda harus membedakan antara penyewa logis dan penyebaran.

Misalnya, pertimbangkan layanan streaming musik. Awalnya, Anda mungkin membangun solusi yang dapat dengan mudah menangani ribuan atau bahkan puluhan ribu pengguna. Namun, karena organisasi Anda terus berkembang, Anda mungkin menemukan bahwa Anda perlu menduplikasi solusi Anda atau beberapa komponennya untuk menskalakan ke permintaan pelanggan baru. Untuk menyelesaikan tugas ini, Anda perlu menentukan cara menetapkan pelanggan tertentu ke instans tertentu dari solusi Anda. Anda dapat menugaskan pelanggan secara acak, berdasarkan wilayah geografis, atau dengan mengisi satu instans terlebih dahulu dan kemudian memulai instans lainnya, juga dikenal sebagai penerapan algoritma bin packing. Namun, Anda mungkin perlu mempertahankan catatan pelanggan Anda dan infrastruktur tempat data dan aplikasi mereka berada sehingga Anda dapat merutekan lalu lintas mereka ke lokasi yang benar. Dalam contoh ini, Anda dapat mewakili setiap pelanggan sebagai penyewa yang terpisah dan memetakan pengguna ke penyebaran yang berisi data mereka. Pendekatan ini menciptakan hubungan satu-ke-banyak antara penyewa dan penyebaran, dan Anda dapat memindahkan penyewa di antara penyebaran sesuai kebijakan Anda.

Sebaliknya, pertimbangkan perusahaan yang membuat perangkat lunak cloud untuk perusahaan hukum. Pelanggan Anda mungkin bersikeras memiliki infrastruktur khusus mereka sendiri untuk menjaga kepatuhan terhadap persyaratan peraturan. Oleh karena itu, Anda perlu siap untuk menyebarkan dan mengelola berbagai instans solusi Anda sejak awal. Dalam contoh ini, penyebaran selalu berisi satu penyewa, dan penyewa dipetakan ke penyebaran khususnya sendiri.

Perbedaan utama antara penyewa dan penyebaran adalah bagaimana isolasi diberlakukan. Saat beberapa penyewa berbagi satu penyebaran (sekumpulan infrastruktur), Anda biasanya mengandalkan kode aplikasi dan pengidentifikasi penyewa yang ada dalam database untuk memisahkan data setiap penyewa. Ketika penyewa memiliki penerapan khusus sendiri, mereka memiliki infrastruktur mereka sendiri, sehingga mungkin kurang penting bagi kode Anda untuk mengakomodasi lingkungan dengan banyak penyewa.

Penyebaran terkadang disebut sebagai supertenant atau stempel.

Saat Anda menerima permintaan untuk penyewa tertentu, Anda perlu memetakan permintaan tersebut ke sistem penyebaran yang menyimpan data penyewa tersebut, seperti yang dijelaskan dalam diagram berikut.

Diagram dibagi menjadi tiga bagian utama, yaitu penyewa, solusi Anda, dan ID penyewa serta ID penyebaran. Panah menunjuk dari Penyewa A, B, C, dan D ke kotak berlabel pemetaan penyewa di dalam bagian solusi. Bagian itu juga menyertakan server web dan database untuk penyebaran 1 dan penyebaran 2. Panah lain menunjuk dari kotak pemetaan penyewa ke bagian yang berisi ID penyewa dan ID penerapan. Penyewa A dan B memiliki ID penyebaran 1, dan penyewa C dan D memiliki ID penyebaran 2.

Untuk informasi selengkapnya, lihat Memetakan permintaan ke penyewa.

Isolasi penyewa

Salah satu pertimbangan terbesar dalam desain arsitektur multipenyewa adalah tingkat isolasi yang dibutuhkan setiap penyewa. Isolasi dapat merujuk ke konfigurasi berikut:

• Memiliki satu infrastruktur bersama yang mencakup instans terpisah aplikasi Anda dan database terpisah untuk setiap penyewa.

• Berbagi beberapa sumber daya umum, tetapi memisahkan sumber daya lain untuk setiap penyewa.

• Menyimpan data pada infrastruktur fisik terpisah. Di cloud, konfigurasi ini mungkin memerlukan sumber daya Azure terpisah untuk setiap penyewa. Dalam skenario ekstrem, bahkan dapat mengharuskan Anda untuk menyebarkan infrastruktur fisik terpisah dengan menggunakan host khusus.

Alih-alih melihat isolasi sebagai properti diskrit, anggap saja spektrum. Anda dapat menyebarkan komponen arsitektur Anda yang lebih terisolasi atau kurang terisolasi daripada komponen lain dalam arsitektur yang sama, tergantung pada kebutuhan Anda. Diagram berikut menunjukkan kelanjutan isolasi:

Diagram menunjukkan panah dari sepenuhnya terisolasi (tanpa berbagi) ke sepenuhnya berbagi (berbagi semua). Di sisi yang sepenuhnya terisolasi, kotak biru berisi komputasi terpisah, database terpisah, jaringan terpisah, dan nama domain terpisah. Di tengah panah, kotak hijau berisi komputasi bersama, jaringan bersama, dan nama domain bersama. Kotak biru berisi database terpisah. Di sisi yang dibagikan sepenuhnya, kotak hijau berisi komputasi bersama, database bersama, jaringan bersama, dan nama domain bersama.

Tingkat isolasi memengaruhi banyak aspek arsitektur Anda:

• Keamanan: Jika Anda berbagi infrastruktur di antara beberapa penyewa, berhati-hatilah untuk tidak mengakses data dari satu penyewa saat Anda mengembalikan respons ke penyewa lain. Anda memerlukan fondasi yang kuat untuk strategi identitas Anda, dan Anda perlu mempertimbangkan identitas penyewa dan pengguna dalam proses otorisasi Anda.

• Biaya: Beberapa penyewa dapat menggunakan infrastruktur bersama, sehingga lebih murah.

• Performa: Jika Anda berbagi infrastruktur, performa sistem Anda mungkin menurtur karena lebih banyak pelanggan menggunakannya karena sumber daya mungkin dikonsumsi lebih cepat. Penyewa yang memiliki pola penggunaan yang tidak biasa dapat memperburuk masalah performa.

• Keandalan: Jika Anda menggunakan satu set infrastruktur bersama, masalah dengan satu komponen dapat mengakibatkan pemadaman untuk semua penyewa Anda.

• Responsivitas terhadap kebutuhan penyewa individu: Saat Anda menyebarkan infrastruktur yang didedikasikan untuk satu penyewa, Anda mungkin dapat menyesuaikan konfigurasi untuk sumber daya dengan persyaratan penyewa tertentu. Anda bahkan dapat mempertimbangkan kemampuan ini dalam model harga Anda untuk memungkinkan pelanggan membayar lebih banyak untuk penyebaran yang terisolasi.

Arsitektur solusi Anda dapat memengaruhi opsi yang tersedia untuk isolasi. Misalnya, pertimbangkan arsitektur solusi tiga tingkat:

• Lapisan antarmuka pengguna Anda mungkin merupakan aplikasi web multipenyewa. Semua penyewa Anda mengakses satu nama host.

• Tingkat tengah Anda dapat menjadi lapisan aplikasi bersama yang memiliki antrean pesan bersama.

• Tingkat data Anda dapat menjadi database, tabel, atau kontainer blob yang terisolasi.

Anda dapat menggunakan tingkat isolasi yang berbeda untuk setiap tingkatan. Anda harus mendasarkan keputusan Anda tentang apa yang harus dibagikan dan apa yang harus diisolasi pada beberapa faktor, termasuk biaya, kompleksitas, persyaratan pelanggan Anda, dan jumlah sumber daya yang dapat Anda sebarkan sebelum mencapai kuota dan batas Azure.

Model penyewaan umum

Setelah Anda menetapkan persyaratan Anda, evaluasi terhadap beberapa model penyewaan umum dan pola penyebaran yang sesuai.

Penyebaran penyewa tunggal otomatis

Dalam model penyebaran penyewa tunggal otomatis, Anda menyebarkan sekumpulan infrastruktur khusus untuk setiap penyewa, seperti yang ditunjukkan dalam contoh berikut:

Diagram dibagi menjadi tiga bagian, satu untuk Penyewa A, satu untuk Penyewa B, dan satu untuk Penyewa C. Panah menunjuk dari Penyewa A ke kotak berlabel Penyebaran A. Kotak itu berisi server web untuk penyewa A. Panah lain menunjuk dari Penyewa B ke kotak berlabel Penyebaran B. Kotak itu berisi server web untuk penyewa B. Panah lain menunjuk dari Penyewa C ke kotak berlabel Penyebaran C. Kotak itu berisi server web untuk penyewa C.

Aplikasi Anda bertanggung jawab untuk memulai dan mengoordinasikan penyebaran sumber daya setiap penyewa. Biasanya, solusi yang menggunakan model ini menggunakan infrastruktur sebagai kode atau API Azure Resource Manager secara ekstensif. Anda dapat menggunakan pendekatan ini ketika Anda perlu memprovisikan infrastruktur yang sepenuhnya terpisah untuk setiap pelanggan Anda. Pertimbangkan untuk menggunakan pola Stempel Penyebaran saat Anda merencanakan penyebaran.

Manfaat: Manfaat utama dari pendekatan ini adalah bahwa data untuk setiap penyewa terisolasi, yang mengurangi risiko kebocoran yang tidak disengaja. Perlindungan ini dapat menjadi penting bagi pelanggan yang memiliki overhead kepatuhan terhadap peraturan yang tinggi. Selain itu, penyewa tidak mungkin mempengaruhi performa sistem satu sama lain, juga dikenal sebagai masalah tetangga yang bising . Pembaruan dan perubahan dapat diluncurkan secara progresif di seluruh penyewa, yang mengurangi kemungkinan pemadaman di seluruh sistem.

Risiko: Jika Anda menggunakan pendekatan ini, efisiensi biaya rendah karena Anda tidak berbagi infrastruktur di antara penyewa Anda. Jika satu penyewa memerlukan biaya infrastruktur tertentu, 100 penyewa mungkin memerlukan biaya 100 kali lipat. Selain itu, pemeliharaan yang sedang berlangsung, seperti menerapkan konfigurasi baru atau pembaruan perangkat lunak, dapat memakan waktu. Pertimbangkan untuk mengotomatiskan proses operasional Anda, dan pertimbangkan untuk menerapkan perubahan secara progresif melalui lingkungan Anda. Anda juga harus mempertimbangkan operasi lintas penyebaran lainnya, seperti pelaporan dan analitik di seluruh armada Anda. Rencanakan bagaimana Anda dapat melakukan query dan memanipulasi data di beberapa deployment.

Penyebaran multipenyewa sepenuhnya

Pada ujung spektrum yang berlawanan, Anda dapat mempertimbangkan penyebaran yang sepenuhnya multipenyewa di mana semua komponen digunakan bersama. Anda hanya memiliki satu set infrastruktur untuk disebarkan dan dikelola, dan semua penyewa menggunakannya, seperti yang ditunjukkan dalam diagram berikut:

Dalam diagram ini, panah menunjuk dari kotak berlabel Penyewa A, Penyewa B, dan Penyewa C ke kotak yang diberi label sebagai sumber daya bersama. Kotak itu berisi server web untuk penyewa A, B, dan C.

Manfaat: Model ini menarik karena mengoperasikan solusi yang memiliki komponen bersama lebih murah daripada menggunakan sumber daya individual untuk setiap penyewa. Bahkan jika Anda perlu menyebarkan tingkat atau SKU sumber daya yang lebih tinggi untuk memperhitungkan peningkatan beban, biaya penyebaran keseluruhan seringkali masih lebih rendah daripada biaya sekumpulan sumber daya penyewa tunggal. Selain itu, jika pengguna atau penyewa perlu memindahkan data mereka ke penyewa lain, Anda mungkin dapat memperbarui pengidentifikasi penyewa dan kunci, dan Anda mungkin tidak perlu memigrasikan data antara dua penyebaran terpisah.

Risiko :

• Pastikan untuk memisahkan data untuk setiap penyewa, dan jangan bocorkan data di antara penyewa. Anda mungkin perlu mengelola data sharding. Anda mungkin juga perlu mempertimbangkan efek yang dapat dimiliki penyewa individual pada sistem secara keseluruhan. Misalnya, jika penyewa besar mencoba melakukan kueri atau operasi berat, itu mungkin memengaruhi penyewa lain.

• Tentukan cara melacak dan mengaitkan biaya Azure Anda ke penyewa, jika informasi ini penting bagi Anda.

• Anda dapat menyederhanakan pemeliharaan dengan menggunakan satu penyebaran karena Anda hanya perlu memperbarui satu set sumber daya. Namun, ini juga sering lebih berisiko karena perubahan dapat memengaruhi seluruh basis pelanggan Anda.

• Anda mungkin juga perlu mempertimbangkan skala. Anda lebih mungkin mencapai batas skala sumber daya Azure saat Anda memiliki sekumpulan infrastruktur bersama. Misalnya, jika Anda menggunakan akun penyimpanan sebagai bagian dari solusi Anda, saat skala Anda meningkat, jumlah permintaan ke akun penyimpanan tersebut mungkin mencapai batas apa yang dapat ditangani akun penyimpanan. Untuk menghindari mencapai batas kuota sumber daya, Anda dapat menyebarkan kumpulan beberapa instans sumber daya Anda, seperti beberapa kluster AKS atau akun penyimpanan. Anda bahkan dapat mempertimbangkan untuk mendistribusikan penyewa di seluruh sumber daya yang Anda sebarkan ke beberapa langganan Azure.

• Mungkin ada batasan seberapa jauh Anda dapat menskalakan satu penyebaran, dan biaya penskalaan mungkin meningkat secara nonlinear. Misalnya, jika Anda memiliki satu database bersama yang Anda jalankan dalam skala tinggi, Anda mungkin mencapai batas throughputnya dan perlu membayar lebih mahal untuk peningkatan throughput agar sesuai dengan permintaan Anda.

Penyebaran yang dipartisi secara vertikal

Anda tidak perlu memilih salah satu ekstrem dari skala ini. Sebagai gantinya, Anda dapat mempartisi penyewa Anda secara vertikal dengan mengambil pendekatan berikut:

• Gunakan kombinasi penyewa tunggal dan penyebaran multipenyewa. Misalnya, Anda mungkin memiliki sebagian besar tingkat data dan aplikasi pelanggan pada infrastruktur multipenyewa, tetapi Anda menyebarkan infrastruktur penyewa tunggal untuk pelanggan yang memerlukan performa atau isolasi data yang lebih tinggi.

• Sebarkan beberapa instans solusi Anda secara geografis, dan petakan setiap penyewa ke penyebaran tertentu. Pendekatan ini efektif ketika Anda memiliki penyewa di geografi yang berbeda.

Berikut adalah contoh yang mengilustrasikan penyebaran bersama untuk beberapa penyewa dan penyebaran penyewa tunggal untuk penyewa lain:

Dalam diagram ini, panah menunjuk dari Tenant A dan Tenant B ke kotak berlabel Deployment 1. Kotak itu berisi server web untuk penyewa A dan B. Panah lain menunjuk dari Penyewa C ke kotak berlabel Penyebaran 2. Kotak itu berisi server web untuk Penyewa C.

Manfaat: Karena Anda masih berbagi beberapa infrastruktur, Anda dapat memperoleh beberapa manfaat biaya dari penggunaan penyebaran multipenyewa yang dibagi bersama. Anda dapat menyebarkan sumber daya bersama yang lebih murah untuk pelanggan tertentu, seperti pelanggan yang mengevaluasi layanan Anda dengan menggunakan uji coba. Anda bahkan dapat membebankan tarif lebih tinggi kepada pelanggan untuk menggunakan penyebaran tenant tunggal, yang membantu Anda memulihkan sebagian biaya.

Risiko: Basis kode Anda perlu dirancang untuk mendukung penyebaran multipenyewa dan penyewa tunggal. Jika Anda berencana untuk mengizinkan migrasi antar penyebaran, Anda perlu mempertimbangkan cara memigrasikan pelanggan dari penyebaran multipenyewa ke penyebaran penyewa tunggal mereka sendiri. Anda juga perlu mengetahui penyewa mana yang ada di setiap penyebaran sehingga Anda dapat mengomunikasikan informasi tentang masalah sistem atau peningkatan ke pelanggan yang relevan.

Penyebaran yang dipartisi secara horizontal

Anda juga dapat mempartisi penyebaran Anda secara horizontal. Dalam penyebaran horizontal, Anda memiliki beberapa komponen bersama tetapi mempertahankan komponen lain dengan penyebaran penyewa tunggal. Misalnya, Anda dapat membangun satu tingkat aplikasi lalu menyebarkan database individual untuk setiap penyewa, seperti yang ditunjukkan dalam diagram ini:

Dalam diagram ini, panah menunjuk dari kotak berlabel Penyewa A, Penyewa B, dan Penyewa C ke kotak yang berisi server web yang penyewa berbagi A, B, dan C.

Manfaat: Penyebaran yang dipartisi secara horizontal dapat membantu Anda mengurangi masalah tetangga yang bising. Jika Anda mengidentifikasi bahwa komponen tertentu menyebabkan sebagian besar beban pada sistem Anda, maka Anda dapat menyebarkan komponen terpisah untuk setiap penyewa. Misalnya, database Anda mungkin menyerap sebagian besar beban sistem Anda karena beban kueri tinggi. Jika satu penyewa mengirim sejumlah besar permintaan ke solusi Anda, performa database mungkin terpengaruh secara negatif, tetapi database penyewa dan komponen bersama lainnya, seperti tingkat aplikasi, tetap tidak terpengaruh.

Risiko: Dengan penyebaran yang dipartisi secara horizontal, Anda masih perlu mempertimbangkan penyebaran dan manajemen otomatis komponen Anda, terutama komponen yang digunakan penyewa tunggal.

Menguji model isolasi Anda

Model isolasi apa pun yang Anda pilih, pastikan untuk menguji solusi Anda untuk memverifikasi bahwa data satu penyewa tidak secara tidak sengaja bocor ke lainnya dan bahwa hasil gangguan tetangga dapat diterima. Pertimbangkan untuk menggunakan Azure Chaos Studio untuk secara sengaja memperkenalkan kesalahan yang mensimulasikan pemadaman dunia nyata dan memverifikasi ketahanan solusi Anda bahkan ketika komponen tidak berfungsi.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

• John Downs | Insinyur Perangkat Lunak Utama, Pola & Praktik Azure

Kontributor lain:

• Chad Kittel | Insinyur Perangkat Lunak Utama, Pola & Praktik Azure
• Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah selanjutnya

Pertimbangkan siklus hidup penyewa Anda.