Share via

Mengukur konsumsi setiap penyewa

  • Artikel

Sebagai penyedia solusi, penting untuk mengukur konsumsi setiap penyewa dalam solusi multipenyewa Anda. Dengan mengukur konsumsi setiap penyewa, Anda dapat memastikan bahwa biaya barang yang dijual (COGS), untuk memberikan layanan kepada setiap penyewa, menguntungkan. Pada halaman ini, kami memberikan panduan bagi para pembuat keputusan teknis tentang pentingnya mengukur konsumsi dan pendekatan yang dapat Anda pertimbangkan untuk mengukur konsumsi penyewa, serta pertukaran yang terlibat.

Ada dua masalah utama yang mendorong kebutuhan untuk mengukur konsumsi setiap penyewa:

  • Anda perlu mengukur biaya sebenarnya untuk melayani setiap penyewa. Hal ini penting untuk memantau profitabilitas solusi untuk setiap penyewa.
  • Anda perlu menentukan biaya yang akan dikenakan kepada penyewa, saat Anda menggunakan harga berbasis konsumsi.

Namun, mungkin sulit untuk mengukur sumber daya aktual yang digunakan oleh penyewa dalam solusi multipenyewa. Sebagian besar layanan yang dapat digunakan sebagai bagian dari solusi multipenyewa tidak secara otomatis membedakan atau memecah penggunaan, berdasarkan apa pun yang Anda definisikan sebagai penyewa. Misalnya, pertimbangkan layanan yang menyimpan data untuk semua penyewa dalam satu database hubungan. Sulit untuk menentukan dengan tepat berapa banyak ruang yang digunakan setiap penyewa dari database hubungan, baik dalam hal penyimpanan atau kapasitas komputasi yang diperlukan untuk melayani kueri dan permintaan apa pun.

Sebaliknya, untuk solusi penyewa tunggal, Anda dapat menggunakan Microsoft Cost Management dalam portal Azure, untuk mendapatkan perincian biaya lengkap untuk semua sumber daya Azure yang digunakan oleh penyewa tersebut.

Oleh karena itu, ketika menghadapi tantangan ini, penting untuk mempertimbangkan cara mengukur konsumsi.

Catatan

Dalam beberapa kasus, kerugian saat memberikan layanan kepada penyewa dapat diterima secara komersial. Misalnya, saat Anda memasuki pasar atau wilayah baru. Ini adalah pilihan komersial. Bahkan dalam situasi ini, masih merupakan ide yang baik untuk mengukur konsumsi setiap penyewa, sehingga Anda dapat merencanakan untuk masa yang akan datang.

Metrik konsumsi indikatif

Aplikasi modern (dibangun untuk cloud) biasanya terdiri dari banyak layanan yang berbeda, masing-masing dengan ukuran konsumsi yang berbeda. Misalnya, akun penyimpanan mengukur konsumsi berdasarkan jumlah data yang disimpan, data yang dikirimkan, dan jumlah transaksi. Namun, konsumsi Azure App Service diukur dengan jumlah sumber daya komputasi yang dialokasikan dari waktu ke waktu. Jika Anda memiliki solusi yang mencakup akun penyimpanan dan sumber daya App Service, maka menggabungkan semua pengukuran ini bersama-sama untuk menghitung COGS yang sebenarnya (biaya barang yang dijual) bisa menjadi tugas yang sangat sulit. Seringkali, lebih mudah untuk menggunakan satu pengukuran indikatif untuk mewakili konsumsi dalam solusi.

Misalnya, jika solusi multipenyewa berbagi database relasional tunggal, maka data yang disimpan oleh penyewa mungkin merupakan metrik konsumsi indikatif yang baik.

Catatan

Bahkan jika Anda menggunakan volume data yang disimpan oleh penyewa sebagai ukuran konsumsi indikatif, volume ini mungkin bukan representasi konsumsi yang sebenarnya untuk setiap penyewa. Misalnya, jika penyewa tertentu melakukan lebih banyak pembacaan atau menjalankan lebih banyak pelaporan dari layanan, tetapi tidak menulis banyak data, maka penyewa dapat menggunakan lebih banyak komputasi daripada persyaratan penyimpanan.

Penting untuk sesekali mengukur dan meninjau konsumsi aktual di seluruh penyewa Anda, untuk menentukan apakah asumsi yang Anda buat tentang metrik indikatif Anda sudah benar.

Metrik transaksi

Cara alternatif untuk mengukur konsumsi adalah dengan mengidentifikasi transaksi utama yang mewakili COGS untuk solusinya. Misalnya, dalam solusi manajemen dokumen, hal ini dapat berupa jumlah dokumen yang dibuat. Ini dapat berguna, jika ada fungsi atau fitur inti dalam sistem yang transaksional, dan jika dapat dengan mudah diukur.

Metode ini biasanya mudah dan hemat biaya untuk diterapkan, karena biasanya hanya ada satu titik dalam aplikasi Anda yang perlu mencatat jumlah transaksi yang terjadi.

Metrik per permintaan

Dalam solusi yang terutama berbasis API, mungkin masuk akal untuk menggunakan metrik konsumsi yang didasarkan pada jumlah permintaan API yang dibuat untuk solusi. Ini seringkali bisa sangat mudah diterapkan, tetapi mengharuskan Anda untuk menggunakan API sebagai antarmuka utama ke sistem. Akan ada peningkatan biaya operasional penerapan metrik per permintaan, terutama untuk layanan volume tinggi, karena adanya kebutuhan untuk mencatat pemanfaatan permintaan (untuk tujuan audit dan penagihan).

Catatan

Solusi yang dihadapi pengguna yang terdiri dari aplikasi satu halaman (SPA), atau aplikasi seluler yang menggunakan API, mungkin tidak cocok untuk metrik per permintaan. Ini karena ada sedikit pemahaman oleh pengguna akhir hubungan antara penggunaan aplikasi dan konsumsi API. Aplikasi Anda mungkin menuntut banyak hal (membuat banyak permintaan API) atau kurang aktif (membuat terlalu sedikit permintaan API), dan pengguna tidak akan melihat perbedaan.

Peringatan

Pastikan Anda menyimpan metrik permintaan di penyimpanan data andal yang dirancang untuk tujuan ini. Misalnya, meskipun Application Insights Azure dapat melacak permintaan dan bahkan dapat melacak ID penyewa (dengan menggunakan properti), Application Insights tidak dirancang untuk menyimpan setiap bagian telemetri. Application Insights menghapus data, sebagai bagian dari perilaku pengambilan sampelnya. Untuk tujuan penagihan dan pengukuran, pilih penyimpanan data yang akan memberi Anda tingkat akurasi yang tinggi.

Memperkirakan konsumsi

Saat mengukur konsumsi untuk penyewa, mungkin lebih mudah untuk memberikan perkiraan konsumsi bagi penyewa, daripada mencoba menghitung jumlah konsumsi yang tepat. Misalnya, untuk solusi multipenyewa yang melayani ribuan penyewa dalam satu penyebaran, wajar untuk memperkirakan bahwa biaya melayani penyewa hanyalah persentase dari biaya sumber daya Azure.

Anda dapat mempertimbangkan untuk memperkirakan COGS untuk penyewa, dalam kasus berikut:

  • Anda tidak menggunakan harga berbasis konsumsi.
  • Pola penggunaan dan biaya untuk setiap penyewa serupa, terlepas dari ukurannya.
  • Setiap penyewa mengonsumsi persentase yang rendah (misalnya, <2%), dari keseluruhan sumber daya dalam penyebaran.
  • Biaya per penyewa rendah.

Anda juga dapat memilih untuk memperkirakan konsumsi dalam kombinasi dengan metrik konsumsi indikatif, metrik transaksi, atau metrik per permintaan. Misalnya, untuk aplikasi yang lebih banyak mengelola dokumen, persentase penyimpanan keseluruhan yang digunakan oleh penyewa, untuk menyimpan dokumennya, memberikan representasi yang cukup dekat dari COGS yang sebenarnya. Ini bisa menjadi pendekatan yang berguna saat mengukur COGS dirasa sulit atau saat pengukuran akan menambah terlalu banyak kompleksitas pada aplikasi.

Penagihan biaya

Dalam beberapa solusi, Anda dapat menagih COGS kepada pelanggan Anda untuk sumber daya penyewa mereka. Misalnya, Anda mungkin menggunakan tag sumber daya Azure untuk mengalokasikan sumber daya Azure yang dapat ditagih ke penyewa. Anda kemudian dapat menentukan biaya untuk setiap penyewa untuk serangkaian sumber daya yang didedikasikan untuknya, ditambah margin untuk keuntungan dan operasi.

Catatan

Beberapa layanan Azure tidak mendukung tag. Untuk layanan ini, Anda harus mengaitkan biaya ke penyewa, berdasarkan nama sumber daya, grup sumber daya, atau langganan.

Azure Cost Analysis dapat digunakan untuk menganalisis biaya sumber daya Azure untuk solusi penyewa tunggal yang menggunakan tag, grup sumber daya, atau langganan untuk biaya atribut.

Namun, ini menjadi sangat kompleks dalam sebagian besar solusi multipenyewa modern, karena tantangan menentukan COGS yang tepat secara akurat guna melayani penyewa tunggal. Metode ini hanya boleh dipertimbangkan untuk solusi yang sangat sederhana, solusi yang memiliki penyebaran sumber daya penyewa tunggal, atau fitur add-on kustom penyewa khusus dalam solusi yang lebih besar.

Beberapa layanan Azure menyediakan fitur yang memungkinkan metode atribusi biaya lainnya di lingkungan multipenyewa. Misalnya, Azure Kubernetes Service mendukung beberapa kumpulan node, saat setiap penyewa diberi kumpulan node dengan tag kumpulan node, yang digunakan untuk biaya atribut.

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.

Langkah berikutnya

Pertimbangkan model penyebaran pembaruan yang akan Anda gunakan.