Ada banyak cara untuk mempertimbangkan cara bekerja dengan penyewa dalam solusi Anda. Pilihan pendekatan Anda sangat 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 itu dengan cepat menjadi mahal saat bisnis Anda diskalakan dan Anda onboard lebih banyak penyewa.
Ketika Anda mempertimbangkan berbagai model multipenyewa, sangat membantu untuk terlebih dahulu memperhitungkan 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 tradeoff mereka.
Tentukan penyewa
Pertama, Anda perlu menentukan penyewa untuk organisasi Anda. Pertimbangkan siapa pelanggan Anda. Dengan kata lain, kepada siapa Anda menyediakan layanan Anda? Ada dua model umum:
- Business to business (B2B). Jika pelanggan Anda adalah organisasi lain, Anda mungkin akan memetakan penyewa Anda ke pelanggan tersebut. Namun, pertimbangkan apakah pelanggan Anda memiliki divisi (tim atau departemen) dan apakah mereka memiliki kehadiran di beberapa negara/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. Umumnya, satu penyewa memiliki beberapa pengguna. Misalnya, semua karyawan pelanggan adalah pengguna dalam satu penyewa.
- Business to consumer (B2C). Jika pelanggan Anda adalah konsumen, biasanya 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 ini:
- Jika penyewa Anda adalah orang atau keluarga individu, Anda mungkin perlu sangat khawatir tentang cara Anda menangani data pribadi, dan tentang undang-undang kedaulatan data dalam setiap yurisdiksi yang Anda layani.
- Jika penyewa Anda adalah bisnis, Anda mungkin perlu memperhatikan persyaratan pelanggan Anda untuk kepatuhan terhadap peraturan, isolasi data mereka, dan memastikan bahwa Anda memenuhi tujuan tingkat layanan (SLO) tertentu, seperti waktu aktif atau ketersediaan layanan.
Bagaimana cara Anda memutuskan model yang akan digunakan?
Memilih model penyewaan bukan hanya keputusan teknis. Ini juga merupakan keputusan komersial. Anda perlu mempertimbangkan pertanyaan seperti ini:
- Apa tujuan bisnis Anda?
- Apakah pelanggan Anda akan menerima segala bentuk multipenyewaan? Bagaimana setiap model multipenyewa memengaruhi persyaratan kepatuhan Anda, atau persyaratan kepatuhan pelanggan Anda?
- Apakah solusi penyewa tunggal akan diskalakan untuk aspirasi pertumbuhan Anda di masa mendatang?
- Seberapa besar tim operasi Anda, dan berapa banyak manajemen infrastruktur yang dapat Anda otomatisasi?
- Apakah pelanggan mengharapkan Anda untuk memenuhi perjanjian tingkat layanan (SLA), atau apakah Anda memiliki SLA yang Anda bidik?
Jika Anda mengharapkan bisnis Anda untuk menskalakan ke sejumlah besar pelanggan, penting untuk menyebarkan infrastruktur bersama. Jika tidak, Anda harus mempertahankan armada instans sumber daya yang besar dan berkembang. Menyebarkan sumber daya Azure individual untuk setiap pelanggan kemungkinan tidak dapat digunakan, 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 mulai berlaku, dan biaya operasional untuk menyebarkan dan mengonfigurasi ulang 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 arti penyewa untuk solusi khusus Anda, dan apakah Anda harus membedakan antara penyewa logis dan penyebaran.
Misalnya, pertimbangkan layanan streaming musik. Awalnya, Anda dapat membangun solusi yang dapat dengan mudah menangani ribuan (atau bahkan puluhan ribu) pengguna. Namun, saat Anda terus tumbuh, Anda mungkin menemukan bahwa Anda perlu menduplikasi solusi Anda atau beberapa komponennya untuk menskalakan ke permintaan pelanggan baru. Ini berarti Anda perlu menentukan cara menetapkan pelanggan tertentu ke instans tertentu dari solusi Anda. Anda dapat menetapkan pelanggan secara acak, atau geografis, atau dengan mengisi satu instans dan kemudian memulai instans lain (kemasan bin). Namun, Anda mungkin perlu mempertahankan catatan pelanggan Anda dan infrastruktur mana data dan aplikasi mereka tersedia sehingga Anda dapat merutekan lalu lintas mereka ke infrastruktur yang benar. Dalam contoh ini, Anda dapat mewakili setiap pelanggan sebagai penyewa terpisah, lalu memetakan pengguna ke penyebaran yang berisi data mereka. Anda memiliki pemetaan satu-ke-banyak antara penyewa dan penyebaran, dan Anda dapat memindahkan penyewa di antara penyebaran atas kebijakan Anda sendiri.
Sebaliknya, pertimbangkan perusahaan yang membuat perangkat lunak cloud untuk perusahaan hukum. Pelanggan Anda mungkin bersikeras memiliki infrastruktur khusus mereka sendiri untuk mempertahankan standar kepatuhan mereka. 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 Anda memiliki penyewa dengan penyebaran khusus mereka sendiri, mereka memiliki infrastruktur mereka sendiri, sehingga mungkin kurang penting bagi kode Anda untuk menyadari bahwa kode tersebut beroperasi di lingkungan multipenyewa.
Penyebaran terkadang disebut sebagai supertenant atau stempel.
Saat Anda menerima permintaan untuk penyewa tertentu, Anda perlu memetakannya ke penyebaran yang menyimpan data penyewa tersebut, seperti yang ditunjukkan di sini:
Untuk mempelajari 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 berarti hal-hal yang berbeda:
- Memiliki satu infrastruktur bersama, dengan 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 yang terpisah. Di cloud, konfigurasi ini mungkin memerlukan sumber daya Azure terpisah untuk setiap penyewa. Dalam situasi ekstrem, bahkan bisa berarti menyebarkan infrastruktur fisik terpisah dengan menggunakan host khusus.
Daripada menganggap isolasi sebagai properti diskrit, Anda harus menganggapnya sebagai sebuah kontinum. Anda dapat menyebarkan komponen arsitektur Anda yang kurang lebih terisolasi daripada komponen lain dalam arsitektur yang sama, tergantung pada kebutuhan Anda. Diagram berikut menunjukkan kontinum isolasi:
Tingkat isolasi memengaruhi banyak aspek arsitektur Anda, termasuk yang berikut ini:
- Keamanan. Jika Anda berbagi infrastruktur di antara beberapa penyewa, Anda harus sangat berhati-hati 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. Infrastruktur bersama dapat digunakan oleh beberapa penyewa, sehingga lebih murah.
- Performa. Jika Anda berbagi infrastruktur, performa sistem Anda mungkin menderita karena lebih banyak pelanggan menggunakannya, karena sumber daya mungkin dikonsumsi lebih cepat. Masalah performa dapat diperburuk oleh penyewa dengan pola penggunaan yang tidak biasa.
- 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, memungkinkan pelanggan membayar lebih untuk penyebaran yang terisolasi.
Arsitektur solusi Anda dapat memengaruhi opsi yang tersedia untuk isolasi. Misalnya, pertimbangkan arsitektur solusi tiga tingkat:
- Tingkat antarmuka pengguna Anda mungkin merupakan aplikasi web multipenyewa bersama, dengan semua penyewa Anda mengakses satu nama host.
- Tingkat tengah Anda bisa menjadi lapisan aplikasi bersama, dengan antrean pesan bersama.
- Tingkat data Anda bisa berupa database terisolasi, tabel, atau blob kontainer.
Anda dapat mempertimbangkan untuk menggunakan tingkat isolasi yang berbeda pada setiap tingkatan. Anda harus mendasarkan keputusan Anda tentang apa yang dibagikan dan apa yang diisolasi pada banyak pertimbangan, 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 ini:
Aplikasi Anda bertanggung jawab untuk memulai dan mengkoordinasikan penyebaran sumber daya masing-masing penyewa. Biasanya, solusi yang menggunakan model ini menggunakan infrastruktur sebagai kode (IaC) atau API Azure Resource Manager secara luas. Anda dapat menggunakan pendekatan ini ketika Anda perlu menyediakan 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 diisolasi, yang mengurangi risiko kebocoran yang tidak disengaja. Perlindungan ini dapat menjadi penting bagi beberapa pelanggan yang memiliki overhead kepatuhan terhadap peraturan yang tinggi. Selain itu, penyewa tidak mungkin memengaruhi performa sistem satu sama lain, masalah yang terkadang disebut 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) mungkin akan memakan waktu. Pertimbangkan untuk mengotomatisasi 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. Demikian juga, pastikan untuk merencanakan bagaimana Anda dapat mengkueri dan memanipulasi data di beberapa penyebaran.
Penyebaran multipenyewa sepenuhnya
Pada ekstrem yang berlawanan, Anda dapat mempertimbangkan penyebaran multipenyewa sepenuhnya, ketika semua komponen dibagikan. Anda hanya memiliki satu set infrastruktur untuk disebarkan dan dikelola, dan semua penyewa menggunakannya, seperti yang ditunjukkan dalam diagram berikut:
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 dan kunci penyewa, 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. Selain itu, Anda mungkin perlu khawatir tentang efek yang dapat dimiliki penyewa individu 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 melakukannya penting bagi Anda.
Pemeliharaan bisa lebih sederhana dengan 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 mempertimbangkan untuk menyebarkan kumpulan beberapa instans sumber daya Anda (misalnya, 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 melakukannya mungkin meningkat secara non-linier. Misalnya, jika Anda memiliki database bersama tunggal, ketika Anda berjalan pada skala yang sangat tinggi, Anda mungkin menghabiskan throughputnya dan perlu membayar semakin banyak untuk peningkatan throughput untuk mengikuti permintaan Anda.
Penyebaran yang dipartisi secara vertikal
Anda tidak perlu memilih salah satu ekstrem dari skala ini. Sebagai gantinya, Anda dapat mempertimbangkan untuk mempartisi penyewa Anda secara vertikal dengan mengambil pendekatan ini:
- Gunakan kombinasi penyebaran penyewa tunggal dan multipenyewa. Misalnya, Anda mungkin memiliki sebagian besar tingkat data dan aplikasi pelanggan Anda pada infrastruktur multipenyewa, tetapi 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 sangat 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:
Manfaat: Karena Anda masih berbagi beberapa infrastruktur, Anda dapat memperoleh beberapa manfaat biaya menggunakan penyebaran multipenyewa bersama. Anda dapat menyebarkan sumber daya bersama yang lebih murah untuk pelanggan tertentu, seperti pelanggan yang mengevaluasi layanan Anda dengan uji coba. Anda bahkan dapat menagih pelanggan tarif yang lebih tinggi untuk menggunakan penyebaran penyewa tunggal, yang membantu Anda memulihkan beberapa biaya Anda.
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 mempertimbangkan untuk membuat partisi penyebaran 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:
Manfaat: Penyebaran yang dipartisi secara horizontal dapat membantu Anda mengurangi masalah tetangga yang bising: jika Anda mengidentifikasi bahwa sebagian besar beban pada sistem Anda disebabkan oleh komponen tertentu maka Anda dapat menyebarkan komponen terpisah untuk setiap penyewa. Misalnya, database Anda mungkin menyerap sebagian besar beban sistem Anda, karena beban kueri tinggi. Jika penyewa tunggal mengirimkan sejumlah besar permintaan ke solusi Anda, performa database mungkin terpengaruh secara negatif, tetapi database penyewa lain (dan komponen bersama, seperti tingkat aplikasi) tetap tidak terpengaruh.
Risiko: Dengan penyebaran yang dipartisi secara horizontal, Anda masih perlu mempertimbangkan penyebaran otomatis dan manajemen komponen Anda, terutama komponen yang digunakan oleh penyewa tunggal.
Uji 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 yang lain dan bahwa efek tetangga yang berisik dapat diterima. Pertimbangkan untuk menggunakan Azure Chaos Studio untuk dengan sengaja memperkenalkan kesalahan yang menyimulasikan pemadaman dunia nyata dan memverifikasi ketahanan solusi Anda bahkan ketika komponen tidak berfungsi.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- John Downs | Insinyur Perangkat Lunak Utama
Kontributor lain:
- Chad Kittel | Insinyur Perangkat Lunak Utama
- Paolo Salvatori | Teknisi Pelanggan Utama, FastTrack untuk Azure
- Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure
Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.