Bagikan melalui

Data untuk beban kerja SaaS di Azure

  • Artikel

Perlakukan data sebagai aset paling berharga dari solusi Anda. Sebagai vendor perangkat lunak independen (ISV), Anda bertanggung jawab untuk mengelola data pelanggan Anda. Strategi desain data dan pilihan penyimpanan data Anda dapat secara signifikan memengaruhi pelanggan Anda.

Artikel ini memberikan panduan tentang cara memastikan integritas dan kerahasiaan data bagi pelanggan Anda sambil memenuhi persyaratan performa bisnis. Ini menyoroti pertimbangan utama untuk membantu Anda mencapai tujuan ini secara efektif.

Memilih penyimpanan data

Penyimpanan data dalam solusi software as a service (SaaS) memengaruhi arsitektur, performa, keandalan, dan kompleksitas transaksionalnya. Bandingkan kemampuan layanan terkelola Azure dengan penawaran non-Microsoft serupa. Dalam beberapa situasi, Anda mungkin juga mempertimbangkan untuk menjalankan produk sumber terbuka pada komputer virtual.

Pertimbangan Desain

  • Membedakan antara operasi transaksional dan analitik Anda. Penyimpanan data transaksional dirancang untuk mendukung aplikasi Anda, dan penyimpanan data analitis digunakan untuk pelaporan dan tugas seperti pembelajaran mesin. Toko-toko ini dibangun dengan produk khusus dan memiliki kebutuhan unik untuk performa, pola akses, skema, dan kasus penggunaan.

    Panduan ini berfokus pada penyimpanan data transaksional.

  • Pahami kebutuhan data Anda. Perkirakan volume, frekuensi di mana volume dapat berubah, dan jenis data yang perlu Anda simpan.

    Harapkan data tumbuh secara signifikan dari waktu ke waktu. Untuk solusi SaaS, pertumbuhan terjadi dalam beberapa dimensi. Mengantisipasi peningkatan volume dan jenis data seiring bertambahnya jumlah pelanggan. Pastikan Anda merencanakan pertumbuhan tersebut dan berinvestasi dalam teknologi yang dapat mendukungnya.

    Putuskan antara platform data relasional atau nonrelasional berdasarkan sifat data Anda. Untuk banyak beban kerja transaksional, database relasional adalah opsi yang baik untuk memodelkan entitas aplikasi sebagai tabel diskrit. Pendekatan ini memungkinkan kueri beroperasi di seluruh model data relasional. Atau, jika data Anda secara alami sesuai dengan model dokumen atau mengikuti struktur grafik, pendekatan nonrelasi mungkin lebih cocok.

    Untuk informasi selengkapnya, lihat platform data SQL versus NoSQL.

  • Minimalkan jenis penyimpanan data. Menyimpan berbagai jenis data dalam beberapa penyimpanan data yang berbeda dapat bermanfaat bagi organisasi dewasa yang memiliki keahlian di berbagai platform data. Namun, pendekatan ini sering memperkenalkan kompleksitas yang tidak perlu untuk startup dan organisasi yang lebih kecil. Lebih efektif untuk fokus pada satu atau sejumlah kecil penyimpanan data.

    Jika Anda tidak memiliki pembenaran bisnis untuk menggunakan beberapa penyimpanan data, maka fokuskan upaya Anda pada satu atau sejumlah kecil penyimpanan data.

  • Gunakan apa yang Anda ketahui, dan investasikan di dalamnya. Jika tim Anda sudah memiliki keahlian dengan penyimpanan data tertentu, seringkali lebih baik menggunakan penyimpanan data tersebut alih-alih berinvestasi dalam mempelajari keterampilan baru. Penyimpanan dan platform data rumit, dan keputusan desain bisa sulit untuk dibalik.

    Namun, ingatlah potensi pertumbuhan. Jika penyimpanan data Anda saat ini tidak lagi memenuhi kebutuhan Anda, pilih penyimpanan data yang dapat meningkatkan performa, ketahanan, keamanan, dan efisiensi operasional solusi Anda. Ini juga harus membantu tim Anda memperdalam keahlian mereka.

Rekomendasi desain

Rekomendasi Keuntungan
Pisahkan penyimpanan data transaksional untuk operasi sehari-hari dari penyimpanan data analitik dan pelaporan. Mencampur niat penyimpanan data Anda dapat menyebabkan kompleksitas yang tidak perlu. Segmentasi data meningkatkan efisiensi operasional dan memaksimalkan pemanfaatan setiap penyimpanan data.
Pilih antara struktur data relasional atau nonrelasional berdasarkan kebutuhan Anda. Mulailah dengan satu atau sejumlah kecil penyimpanan data.

Prioritaskan penyimpanan data terkelola. Pilihan umum termasuk Azure Cosmos DB, Azure SQL, MySQL, MongoDB, dan PostgreSQL.		 Pendekatan ini membantu meminimalkan kompleksitas dan memastikan bahwa Anda menggunakan produk yang tepat untuk memaksimalkan efisiensi. Penyimpanan data terkelola memberikan fleksibilitas dalam mengelola sumber daya dan biaya secara elastis dan menskalakan dengan kebutuhan Anda. Menggunakan penyimpanan data terkelola menciptakan beban manajemen yang lebih sedikit daripada menyebarkan penyimpanan data Anda sendiri pada infrastruktur Anda sendiri.
Berinvestasi dalam mempelajari teknologi pilihan Anda. Lengkapi tim Anda untuk mengelola persyaratan penskalaan tinggi dan kompleksitas solusi SaaS lainnya. Pelajari tentang alat yang Anda gunakan dan ekosistemnya yang lebih luas sehingga Anda dapat menggunakan platform data secara efektif saat Anda menskalakan.
Mengadopsi fleksibilitas dalam desain data Anda. Saat solusi SaaS Anda tumbuh atau kebutuhan Anda berubah, Anda dapat beradaptasi dengan menambahkan atau mengubah penyimpanan data. Fleksibilitas ini memungkinkan Anda memulai dengan satu penyimpanan data dan berkembang dari waktu ke waktu untuk memenuhi kebutuhan Anda.

Model penyewaan dan strategi database

Aspek utama dari desain data adalah keputusan untuk menghosting sumber daya atas nama pelanggan Anda atau untuk menghosting sumber daya di lingkungan mereka. Sebagian besar penyedia SaaS menghosting sumber daya untuk semua pelanggan, yang memberikan fleksibilitas dalam manajemen database. Jika Anda menghosting sumber daya di lingkungan pelanggan, pertimbangkan cara Anda mengakses dan mengelola sumber daya tersebut.

Pertimbangan Desain

  • Rencanakan segmentasi database Anda. Dalam solusi SaaS business-to-business (B2B), kami sarankan Anda membuat database khusus untuk setiap pelanggan. Pendekatan ini meningkatkan keamanan data dengan mempertahankan isolasi ketat antara pelanggan, yang mengurangi risiko pencampuran data dan mendukung kunci enkripsi yang dikelola pelanggan. Ini juga membantu Anda memenuhi persyaratan kepatuhan peraturan untuk beberapa pelanggan.

    Memisahkan data pelanggan ke dalam database individual dapat meningkatkan performa dengan meminimalkan masalah tetangga yang bising. Beberapa penyimpanan data terkelola mencakup kontrol alokasi sumber daya untuk mengurangi masalah ini, memberikan efisiensi biaya, dan menggabungkan alat untuk mengelola beberapa database dalam skala besar.

    Dalam beberapa kasus, sangat tepat untuk menyimpan data beberapa pelanggan dalam satu penyimpanan data. Misalnya, dalam solusi business-to-consumer (B2C), Anda dapat menyimpan data dalam satu penyimpanan dengan partisi logis berdasarkan ID pelanggan. Dalam solusi B2B yang berbagi komponen, Anda dapat menggunakan satu penyimpanan data untuk bagian tertentu, seperti penyimpanan peristiwa, sambil memastikan bahwa Anda menyertakan ID pelanggan pada setiap peristiwa.

  • Kolokasikan penyimpanan data dengan komponen aplikasi. Jika Anda menghosting sumber daya atas nama pelanggan, sebarkan di wilayah Azure yang sama untuk menghindari biaya dan latensi bandwidth keluar. Saat Anda menghosting aplikasi dan penyimpanan data di lingkungan pelanggan, sebarkan bersama-sama di lingkungan yang sama untuk menghindari kompleksitas lintas lingkungan.

  • Menstandarkan manajemen penyimpanan data sebanyak yang praktis. Keseragaman adalah kunci untuk mengelola data di seluruh pelanggan. Seiring berkembangnya bisnis Anda, perbedaan antara pelanggan meningkatkan risiko dan kompleksitas. Perbedaan ini juga dapat membuat pemadaman produksi lebih mungkin dan pemecahan masalah lebih sulit.

    Hindari perubahan satu kali dalam manajemen Anda untuk mendukung pelanggan individual. Misalnya, untuk mendukung metadata yang dikelola pelanggan, hindari perubahan skema seperti menambahkan kolom tambahan ke database Anda. Sebagai gantinya, bangun fungsionalitas bagi pelanggan untuk menambahkan metadata mereka sendiri. Demikian pula, jika Anda perlu memberikan tingkat performa database yang berbeda untuk pelanggan yang berbeda, buat satu proses yang dapat Anda gunakan untuk menerapkan konfigurasi yang berbeda ke tingkat pelanggan yang berbeda.

Untuk informasi selengkapnya tentang bagaimana model penyewaan Anda memengaruhi strategi data Anda, lihat.

Rekomendasi desain

Rekomendasi Keuntungan
Mengevaluasi apakah akan berbagi database antara beberapa pelanggan atau menyediakan platform data bersama.

Sebarkan database tunggal untuk data setiap pelanggan, jika sesuai. Rilekskan strategi ini jika isolasi ketat bukan persyaratan, seperti dalam solusi B2C.		 Pendekatan ini meminimalkan masalah tetangga yang bising dan dapat mendukung persyaratan kepatuhan bagi beberapa pelanggan.
Menyebarkan aplikasi dan database mereka di wilayah yang sama. Pendekatan ini mengoptimalkan biaya bandwidth dan latensi yang dikeluarkan oleh akses database lintas wilayah.
Merancang pendekatan standar untuk menyimpan data atau metadata yang ditentukan pelanggan. Hindari mengubah skema untuk pelanggan individu atau menyebabkan lingkungan pelanggan berbeda. Pendekatan ini membantu Anda menghindari beban operasional dalam mengelola inkonsistensi antar database untuk setiap pelanggan.
Rencanakan operasi pemeliharaan rutin di lingkungan yang disebarkan pelanggan.

Rencanakan cara mengakses database untuk pembaruan, perubahan skema, pemeliharaan, dan operasi lainnya.		 Pendekatan proaktif ini meminimalkan masalah dari kurangnya pemeliharaan dan mengurangi risiko waktu henti dan masalah performa.

Merencanakan kapasitas

Perencanaan kapasitas mengacu pada manajemen pemanfaatan sumber daya, dengan fokus pada operasi CPU, memori, penyimpanan, dan disk seperti operasi input dan output per detik (IOPS). Beberapa penyimpanan data menggabungkan sumber daya ini ke dalam metrik konsumsi sumber daya sintetis sederhana, seperti unit throughput database (DTU) di Azure SQL atau unit permintaan (RU) di Azure Cosmos DB. Penyimpanan data terkelola memberikan fleksibilitas dalam manajemen sumber daya, yang memungkinkan perubahan dari waktu ke waktu. Sangat penting untuk menetapkan rencana awal dan melakukan iterasi seiring berkembangnya kebutuhan Anda.

Pertimbangan Desain

  • Pahami persyaratan alokasi sumber daya Anda. Pelanggan yang berbeda dalam solusi SaaS mungkin memiliki berbagai kebutuhan sumber daya. Pelanggan yang lebih kecil mungkin memerlukan sumber daya minimal, dan pelanggan yang lebih besar mungkin membutuhkan lebih banyak. Pelanggan yang lebih besar sering membayar lebih banyak, yang justifikasi alokasi sumber daya yang lebih tinggi. Dengan menggunakan database terpisah untuk setiap pelanggan, Anda dapat menyesuaikan alokasi sumber daya berdasarkan ukuran dan kebutuhan mereka.

  • Pahami berbagai model kapasitas yang ditawarkan platform data. Platform data berbasis cloud sering menyediakan beberapa model sumber daya. Misalnya, beberapa layanan Azure seperti Azure Cosmos DB menyediakan model berbasis throughput yang disediakan dan model tanpa server. Azure SQL Database juga menyediakan kumpulan elastis.

    Throughput yang disediakan memerlukan alokasi sumber daya yang telah ditentukan, baik dari database tunggal atau sekelompok database. Kumpulan elastis memungkinkan berbagi sumber daya di antara beberapa database. Kumpulan elastis umumnya digunakan dalam solusi SaaS.

    Meskipun throughput yang disediakan mengharuskan Anda mengalokasikan sumber daya sebelumnya, layanan seperti Azure Cosmos DB menyediakan throughput skala otomatis. Anda dapat mengatur aturan untuk menambahkan atau menghapus sumber daya secara dinamis berdasarkan pemicu yang ditentukan.

    Model sumber daya tanpa server secara otomatis diskalakan berdasarkan permintaan. Kemampuan ini menjadikannya titik awal yang baik jika Anda tidak dapat memprediksi persyaratan kapasitas Anda sebelumnya. Namun, mereka mungkin mendukung lebih sedikit fitur dan menjadi tidak efisien biaya saat Anda tumbuh. Model tanpa server tersedia di Azure SQL Database dan Azure Cosmos DB.

Rekomendasi desain

Rekomendasi Keuntungan
Buat model persyaratan database Anda untuk setiap pelanggan. Tentukan apakah Anda harus memiliki banyak database kecil, lebih sedikit database besar, atau campuran keduanya.

Gunakan latihan ukuran kaos untuk mengategorikan pelanggan ke dalam wadah kecil, sedang, dan besar.		 Pendekatan ini memberikan perkiraan kasar tentang sumber daya yang diperlukan per pelanggan dan membantu Anda memetakan pelanggan ke model penagihan Anda.
Segmentasikan kumpulan sumber daya berdasarkan ukuran database pelanggan yang menggunakannya.

Gunakan kapasitas yang disediakan untuk keuntungan Anda. Misalnya, Anda dapat membuat kumpulan elastis SQL bersama untuk pelanggan yang lebih kecil, kumpulan terpisah untuk pelanggan menengah, dan sumber daya khusus untuk pelanggan besar.		 Dengan mengelompokkan kumpulan sumber daya berdasarkan ukuran database pelanggan, Anda dapat mengoptimalkan alokasi sumber daya dan efisiensi biaya.
Manfaatkan kemampuan penskalaan bawaan yang disediakan layanan terkelola. Anda dapat membongkar tanggung jawab penskalakan ke platform. Fitur seperti kumpulan elastis dan skala otomatis dapat membantu mengoptimalkan penggunaan sumber daya.
Tinjau penyimpanan data tanpa server secara teratur untuk memastikan bahwa mereka terus memenuhi kebutuhan Anda. Anda dapat memastikan bahwa penyimpanan data tetap efektif dengan kebutuhan Anda yang terus berkembang. Optimalkan performa dan efisiensi biaya saat kebutuhan Anda berubah.

Ketersediaan tinggi dan pemulihan bencana

Pelanggan solusi SaaS sering memiliki harapan tinggi untuk ketersediaan tinggi (HA) dan pemulihan bencana (DR). Jika pelanggan Anda beroperasi di industri yang diatur atau mengandalkan solusi Anda untuk operasi harian, persyaratan mereka mungkin bahkan lebih ketat.

HA dan DR bukan solusi satu ukuran yang cocok untuk semua dan bergantung pada berbagai faktor. Memiliki pemahaman yang jelas tentang opsi yang tersedia yang berlaku untuk persyaratan Anda dan pelanggan Anda untuk membuat keputusan berdasarkan informasi tentang mengurangi risiko yang berbeda.

Tradeoff: Keandalan, biaya, dan performa: Ketahanan untuk layanan data sering memerlukan pendistribusian replika atau salinan data Anda di seluruh area geografis yang lebih luas untuk mengurangi risiko. Namun, ada tradeoff. Semakin lama jarak yang harus dilalui data, semakin banyak perlindungan yang Anda miliki terhadap kegagalan yang dilokalkan. Tetapi, menyalin data di jarak yang lebih panjang meningkatkan latensi dan sering kali lebih mahal. Banyak penyimpanan data terkelola menyediakan replikasi data otomatis, tetapi mungkin memberlakukan batasan pada jenis replikasi yang dapat Anda lakukan di berbagai jarak untuk mempertahankan performa.

Pertimbangan Desain

  • Mengukur ketahanan. Mengukur persyaratan ketahanan dengan menggunakan tujuan tingkat layanan (SLO), yang mencakup metrik seperti waktu aktif, waktu pemulihan, dan titik pemulihan. Metrik ini didorong oleh persyaratan bisnis Anda dan pelanggan Anda, yang mungkin memiliki berbagai kebutuhan. Jika Anda menyimpan data dalam jumlah besar atas nama pelanggan Anda, solusi HA dan DR Anda mungkin harus lebih kompleks untuk memenuhi persyaratan yang ketat.

    Untuk informasi selengkapnya tentang metrik ketahanan, lihat Rekomendasi RE:04 untuk menentukan target keandalan.

  • Gunakan fitur platform. Azure menyediakan kemampuan untuk ketahanan dalam pusat data, dalam suatu wilayah dengan menggunakan zona ketersediaan, dan di seluruh area geografis yang lebih luas dengan menggunakan beberapa wilayah. Gabungkan strategi seperti zona ketersediaan, pencadangan lintas wilayah, dan penyebaran multiregion untuk mencapai tingkat ketahanan yang tepat untuk solusi Anda. Untuk persyaratan ketahanan tinggi, pertimbangkan arsitektur multiregion dan pasif aktif dengan replikasi data asinkron antar wilayah. Pendekatan ini dapat mengakibatkan beberapa kehilangan data selama pemadaman bencana.

    Tradeoff: Desain multiregion dan aktif-aktif dengan replikasi adalah yang paling tangguh tetapi kompleks untuk dibangun dan diuji. Untuk sebagian besar solusi aktif-aktif, Anda perlu merancang pendekatan resolusi konflik yang memperhitungkan keterlambatan sinkronisasi data. Sebagian besar solusi tidak memerlukan tingkat ketahanan ini.

    Lihat Rekomendasi RE:05 untuk menggunakan zona dan wilayah ketersediaan.

  • Gunakan stempel penyebaran untuk mengisolasi radius ledakan komponen. Pola stempel penyebaran banyak digunakan dalam solusi SaaS karena memberikan manfaat untuk penyebaran, manajemen, performa, dan ketahanan. Misalnya, menyebarkan satu stempel di Amerika Serikat dan stempel lain di Eropa memastikan bahwa pelanggan di satu wilayah terisolasi dari pemadaman di wilayah lain dan dapat beroperasi secara independen.

Rekomendasi desain

Rekomendasi Keuntungan
Fokus pada persyaratan ketahanan saat Anda memikirkan persyaratan data keseluruhan untuk pelanggan Anda dan Anda. Dengan membumikan keputusan desain Anda dalam persyaratan tersebut, Anda dapat memastikan bahwa Anda membuat tradeoff yang sesuai dan menghindari under- atau over-engineering untuk kebutuhan Anda.
Mencerminkan berbagai tingkat ketahanan dalam model penagihan Anda.

Tetapkan harapan dengan pelanggan Anda. Tidak ada kehilangan data selama pemadaman bencana atau waktu aktif 100% mungkin tidak realistis.		 Model penagihan dapat membantu pelanggan Anda memahami berapa banyak jaminan ketahanan yang mereka daftarkan. Misalnya, dengan tingkat yang lebih rendah, pelanggan mendapatkan jaminan minimal. Di tingkat yang lebih tinggi, pelanggan menerima lebih banyak ketahanan karena Anda mampu mereplikasi sumber daya mereka di beberapa wilayah.
Gunakan zona ketersediaan Azure untuk solusi produksi. Jika memungkinkan, gunakan penyimpanan data zona redundan. Zona ketersediaan memberikan ketahanan terhadap pemadaman pusat data, tanpa secara signifikan meningkatkan biaya, latensi, atau kompleksitas solusi Anda.
Simpan cadangan penyimpanan data Anda dalam format redundan global dengan menggunakan replikasi lintas wilayah jika tersedia. Pencadangan data lintas wilayah menambahkan tingkat ketahanan tambahan.
Gunakan stempel penyebaran untuk membuat instans terpisah solusi Anda di lokasi yang didistribusikan secara geografis. Dengan menggunakan stempel penyebaran untuk membuat instans terpisah solusi Anda di lokasi yang didistribusikan secara geografis, Anda dapat meningkatkan ketahanan dan memberikan lebih banyak manfaat, seperti manajemen operasi yang lebih mudah.
Evaluasi jika Anda memerlukan penyebaran multiregion dan jika Anda memerlukan desain aktif-aktif untuk memenuhi persyaratan.

Pertimbangkan tradeoff yang terlibat. Komponen stateless lebih mudah direplikasi daripada komponen stateful seperti penyimpanan data.		 Menyebarkan solusi atau stempel Anda di seluruh wilayah memberikan tingkat ketahanan yang lebih tinggi dengan mereplikasi data antar wilayah.

Keamanan dan kepatuhan

Anda bertanggung jawab untuk memastikan kerahasiaan dan integritas data pelanggan Anda. Saat Anda membangun garis besar keamanan, pertimbangkan persyaratan dan janji keamanan Anda. Rencanakan untuk memenuhi kebutuhan kepatuhan pelanggan Anda, termasuk retensi data.

Pertimbangan Desain

  • Jaringan: Pertimbangkan siapa yang akan mengakses penyimpanan data Anda. Biasanya, hanya aplikasi Anda yang membutuhkan komunikasi langsung, jadi konfigurasikan untuk jaringan privat saja.

  • Identitas: Pertimbangkan bagaimana penyimpanan data Anda akan diakses. Banyak solusi SaaS menggunakan satu identitas aplikasi untuk semua penyimpanan data, dengan tingkat aplikasi memberlakukan isolasi dan otorisasi. Untuk keamanan tingkat baris atau otorisasi tingkat database, Anda mungkin perlu menyebarluaskan identitas pengguna ke penyimpanan data, yang kompleks di lingkungan multipenyewa.

  • Retensi data: Rencanakan kebijakan retensi data Anda terlebih dahulu. Mempertahankan lebih banyak data meningkatkan biaya penyimpanan dan kompleksitas manajemen. Misalnya, sejumlah besar data dalam database transaksional dapat mempersulit proses kueri dan pemotongan.

    Untuk retensi data jangka panjang, seperti untuk kepatuhan atau analisis di masa mendatang, pertimbangkan untuk memindahkan data ke penyimpanan yang cocok untuk retensi jangka panjang.

Rekomendasi desain

Rekomendasi Keuntungan
Konfigurasikan penyimpanan data Anda untuk menggunakan titik akhir privat, dan nonaktifkan titik akhir publik. Pendekatan ini meningkatkan keamanan dengan membatasi akses ke jaringan internal Anda. Dengan membatasi akses, Anda dapat mengurangi risiko akses yang tidak sah dan potensi pelanggaran data.
Gunakan identitas terkelola dan ID Microsoft Entra untuk autentikasi. Hindari penggunaan kunci database atau kredensial. Identitas terkelola menghilangkan kebutuhan akan kunci atau kredensial database, yang mengurangi risiko pencurian kredensial dan menyederhanakan manajemen akses.
Saat Anda bekerja dengan penyimpanan data bersama, pastikan bahwa aplikasi mencakup semua permintaan ke satu penyewa dengan menyertakan pengidentifikasi penyewa dalam WHERE klausul. Proses ini membantu mengurangi risiko kebocoran atau peniruan data lintas penyewa.
Rencanakan strategi retensi data Anda berdasarkan kepatuhan dan kebutuhan bisnis. Hindari menyimpan data historis yang tidak perlu. Untuk retensi jangka panjang, pindahkan data dari penyimpanan utama ke penyimpanan arsip. Dengan menghindari retensi yang tidak perlu, Anda mempertahankan area permukaan yang lebih kecil.
Gunakan fitur penyimpanan data untuk mendukung kebutuhan siklus hidup data Anda.

Di Azure Cosmos DB, atur waktu untuk hidup di dokumen. Di Azure SQL, terapkan strategi jendela geser dengan menggunakan partisi tabel untuk meminimalkan dampak proses pengarsipan pada database.		 Pendekatan ini memastikan manajemen siklus hidup data yang efisien, mengoptimalkan penyimpanan dengan mengarsipkan atau menghapus data yang sudah usang, dan mengurangi intervensi manual jika memungkinkan.

Operasional

Solusi SaaS sering mencakup sejumlah besar database atau penyimpanan lainnya. Penting untuk merencanakan pemeliharaan rutin pada armada Anda dan menjelajahi opsi otomatisasi untuk mengelola tugas-tugas ini secara efisien.

Pertimbangan Desain

  • Pahami kemampuan tim Anda. Jika Anda tidak memiliki tim besar administrator database yang dapat melakukan analisis terperinci pada database pelanggan individu, memiliki rencana untuk melakukan operasi dalam skala besar, dan menggunakan alat platform jika memungkinkan.

  • Rencanakan prosedur pemeliharaan rutin Anda. Cantumkan operasi pemeliharaan reguler yang diperlukan dan frekuensinya. Operasi tertentu bervariasi berdasarkan jenis penyimpanan data yang Anda gunakan. Contohnya:

    • Pantau jumlah total data dan data yang terletak di entitas tertentu, seperti tabel penting.
    • Membangun ulang indeks.
    • Membuat atau menghapus indeks berdasarkan mengubah pola kueri.
    • Partisi penyeimbangan ulang.

    Jelajahi fitur platform yang dapat membantu Anda melakukan pemeliharaan rutin dan secara proaktif mencari masalah baru. Misalnya, SQL Database Advisor di Azure SQL Database memantau masalah.

  • Desain untuk otomatisasi. Operasi otomatis sangat penting bagi solusi SaaS untuk menskalakan secara efektif. Identifikasi tugas reguler dan sesekali dan buat playbook atau skrip otomatisasi untuk mereka. Untuk tugas yang tidak dapat Anda otomatisasi dengan segera, dokumentasikan proses secara menyeluruh untuk memastikan konsistensi dan kejelasan.

Rekomendasi desain

Rekomendasi Keuntungan
Berusahalah untuk konsistensi antara penyimpanan data pelanggan jika memungkinkan.

Jika pelanggan memerlukan akomodasi khusus, integrasikan ke dalam proses keseluruhan daripada menyesuaikan konfigurasi untuk pelanggan tersebut. Misalnya, gunakan skema yang sama untuk setiap database, dan gunakan proses yang sama untuk menyebarkan dan mengelola sumber daya Anda.		 Konsistensi memudahkan untuk membuat perubahan dalam skala besar dan meminimalkan risiko masalah yang tidak disengaja selama penyebaran atau prosedur pemeliharaan.
Sebarkan sumber daya terbatas dengan hati-hati dan cari peluang untuk menyederhanakan operasi. Anda dapat menghindari efisiensi kecil dan memiliki pemanfaatan sumber daya yang lebih baik dan performa keseluruhan.
Buat otomatisasi untuk tugas berulang. Pilih untuk membeli alat otomatis alih-alih membangun solusi kustom.

Jelajahi opsi yang disediakan platform dan vendor non-Microsoft.		 Dengan berinvestasi dalam otomatisasi kualitas, Anda dapat berulang kali menggunakan aset ini dan mengurangi tugas manual yang sering rentan terhadap kesalahan. Alat otomatis sangat berharga jika Anda bukan ahli dalam penyimpanan data yang Anda gunakan atau jika Anda tidak yakin tentang tugas pemeliharaan yang diperlukan.
Sebarkan kapasitas administrasi database tim Anda dengan hati-hati. Pesan administrator database manusia untuk aktivitas yang paling berdampak, seperti berurusan dengan pelanggan besar atau membangun otomatisasi yang dapat menskalakan di banyak pelanggan. Dengan memprioritaskan fungsi berharga, Anda dapat memaksimalkan efisiensi.

Akses pelanggan ke data

Beberapa pelanggan Anda mungkin meminta akses langsung ke data mereka untuk pelaporan atau analitik kustom. Pertimbangkan dengan cermat bagaimana pelanggan dapat mengakses data dalam solusi Anda dan apakah akan memberikan permintaan ini atau menyediakan metode alternatif untuk memenuhi kebutuhan mereka.

Pertimbangan Desain

  • Membenarkan alasan untuk akses langsung. Pahami mengapa pelanggan memerlukan akses ke data mentah dengan mendapatkan informasi tentang masalah bisnis mereka. Berkolaborasi untuk menemukan solusi yang memenuhi kebutuhan mereka tanpa menimbulkan risiko pada platform Anda.

    Temukan cara alternatif untuk memenuhi persyaratan daripada memberikan akses langsung. Jika akses diperlukan untuk tujuan pelaporan, pendekatan tingkat aplikasi lebih disukai. Misalnya, Anda mungkin membuat laporan untuk mereka dengan menggunakan Microsoft Power BI, atau Anda bisa mengekspor subset data Anda ke file yang Anda berikan kepada mereka. Anda juga dapat membuat API yang dapat mereka gunakan untuk mengakses data Anda.

  • Mengevaluasi implikasi keamanan dan isolasi. Menyediakan akses langsung ke penyimpanan data menimbulkan risiko keamanan yang signifikan. Hindari mengekspos sumber daya internal kepada pihak eksternal, termasuk pelanggan. Dalam lingkungan SaaS yang memiliki banyak pelanggan yang berbagi solusi, risikonya bahkan lebih tinggi karena lingkungan dapat dieksploitasi untuk mengakses data pelanggan lain.

    Pertimbangkan untuk menyediakan akses pelanggan ke data mereka dengan cara yang aman dan terisolasi yang tidak memengaruhi sistem produksi Anda dan memungkinkan Anda membuat perubahan desain database internal tanpa merusak kueri pelanggan.

  • Pertimbangkan efek pada performa. Mengizinkan akses langsung ke penyimpanan data transaksional Anda dapat menyebabkan masalah performa untuk aplikasi utama Anda. Misalnya, pelanggan mungkin menjalankan kueri intensif sumber daya yang mengganggu fungsionalitas aplikasi.

Rekomendasi desain

Rekomendasi Keuntungan
Hindari memberikan akses langsung ke penyimpanan data Anda.

Jika Anda harus memberikan akses langsung, berikan akses ke replika baca-saja, jika platform data mendukungnya.		 Pendekatan tingkat aplikasi memberi Anda kontrol atas cara pelanggan menggunakan data Anda. Jika tidak memungkinkan untuk membuat konstruksi tingkat aplikasi, akses melalui replika baca-saja mengurangi ketegangan kueri pelanggan pada operasi Anda.
Hindari mengekspos detail implementasi internal. Dengan mengontrol akses ke struktur data, Anda mencegah pelanggan membuat asumsi tentang fungsionalitas skema database Anda. Fleksibilitas ini memungkinkan Anda untuk berevolusi dan mengoptimalkan struktur database Anda dari waktu ke waktu tanpa batasan alat yang dibuat pelanggan atau asumsi yang tidak akurat.

Sumber Daya Tambahan:

Multitenancy adalah metodologi bisnis inti untuk merancang beban kerja SaaS. Artikel ini memberikan informasi selengkapnya tentang pertimbangan desain data:

Langkah selanjutnya

Pelajari tentang pertimbangan DevOps untuk beban kerja SaaS, termasuk manajemen siklus hidup pelanggan yang efisien dan praktik penyebaran yang aman.

Area desain: Praktik DevOps untuk beban kerja SaaS di Azure