Perencanaan kapasitas untuk aplikasi Service Fabric

Dokumen ini mengajarkan cara memperkirakan jumlah sumber daya (CPU, RAM, penyimpanan disk) yang Anda perlukan untuk menjalankan aplikasi Azure Service Fabric. Persyaratan sumber daya Anda biasanya berubah dari waktu ke waktu. Anda biasanya memerlukan sedikit sumber daya saat Anda mengembangkan/menguji layanan Anda, dan kemudian membutuhkan lebih banyak sumber daya saat Anda masuk ke produksi dan saat aplikasi Anda semakin populer. Saat Anda merancang aplikasi Anda, pikirkan persyaratan jangka panjang dan buat pilihan yang memungkinkan layanan Anda berskala untuk memenuhi permintaan pelanggan yang tinggi.

Saat Anda membuat klaster Service Fabric, Anda memutuskan jenis komputer virtual (VM) apa yang membentuk klaster tersebut. Setiap VM hadir dengan jumlah sumber daya yang terbatas dalam bentuk CPU (inti dan kecepatan), bandwidth jaringan, RAM, dan penyimpanan disk. Seiring dengan berkembangnya layanan Anda dari waktu ke waktu, Anda dapat meningkatkan ke VM yang menawarkan sumber daya yang lebih besar dan/atau menambahkan lebih banyak VM ke klaster Anda. Untuk melakukan yang terakhir, Anda harus merancang layanan Anda terlebih dahulu agar dapat memanfaatkan VM baru yang ditambahkan secara dinamis ke klaster.

Beberapa layanan mengelola sedikit data bahkan tidak sama sekali pada VM itu sendiri. Oleh karena itu, perencanaan kapasitas untuk layanan ini harus berfokus terutama pada kinerja, yang berarti memilih CPU yang sesuai (inti dan kecepatan) dari VM. Selain itu, Anda harus mempertimbangkan bandwidth jaringan, termasuk seberapa sering transfer jaringan terjadi dan berapa banyak data yang ditransfer. Jika layanan Anda perlu bekerja dengan baik saat penggunaan layanan meningkat, Anda dapat menambahkan lebih banyak VM ke klaster dan menyeimbangkan beban permintaan jaringan di semua VM.

Untuk layanan yang mengelola data dalam jumlah besar pada VM, perencanaan kapasitas harus berfokus terutama pada ukuran. Dengan demikian, Anda harus mempertimbangkan dengan cermat kapasitas RAM dan penyimpanan disk dari VM. Sistem manajemen memori virtual di Windows membuat ruang disk terlihat seperti RAM ke kode aplikasi. Selain itu, runtime Service Fabric menyediakan smart paging yang hanya menyimpan data panas dalam memori dan memindahkan data dingin ke disk. Dengan demikian, aplikasi dapat menggunakan lebih banyak memori daripada yang tersedia secara fisik pada VM. Memiliki lebih banyak RAM akan meningkatkan kinerja, karena VM dapat menyimpan lebih banyak penyimpanan disk dalam RAM. VM yang Anda pilih harus memiliki disk yang cukup besar untuk menyimpan data yang Anda inginkan di VM. Demikian pula, VM harus memiliki RAM yang cukup untuk memberi Anda kinerja yang Anda inginkan. Jika data layanan Anda bertambah dari waktu ke waktu, Anda dapat menambahkan lebih banyak VM ke klaster dan mempartisi data di semua VM.

Tentukan berapa banyak node yang Anda butuhkan

Pemartisian layanan Anda memungkinkan Anda untuk menskalakan data layanan Anda. Untuk informasi selengkapnya tentang pemartisian, lihat Pemartisian Service Fabric. Setiap partisi harus muat dalam satu VM, tetapi beberapa partisi (kecil) dapat ditempatkan pada satu VM. Jadi, memiliki lebih banyak partisi kecil memberi Anda fleksibilitas yang lebih besar daripada memiliki beberapa partisi yang lebih besar. Imbalannya adalah memiliki banyak partisi meningkatkan overhead Service Fabric dan Anda tidak dapat melakukan operasi yang ditransaksikan di seluruh partisi. Ada juga lalu lintas jaringan yang lebih potensial jika kode layanan Anda sering kali perlu mengakses bagian data yang ada di partisi yang berbeda. Saat merancang layanan Anda, Anda harus mempertimbangkan pro dan kontra ini dengan cermat untuk sampai pada strategi partisi yang efektif.

Anggaplah aplikasi Anda memiliki layanan stateful tunggal yang memiliki ukuran penyimpanan yang Anda harapkan akan meningkat menjadi DB_Size GB dalam satu tahun. Anda bersedia menambahkan lebih banyak aplikasi (dan partisi) saat Anda mengalami pertumbuhan setelah tahun itu. Faktor replikasi (RF), yang menentukan jumlah replika untuk layanan Anda, memengaruhi total DB_Size. Total DB_Size di semua replika adalah Faktor Replikasi yang dikalikan dengan DB_Size. Node_Size mewakili ruang disk/RAM per node yang ingin Anda gunakan untuk layanan Anda. Untuk kinerja terbaik, DB_Size harus sesuai dengan memori di seluruh klaster, dan Node_Size yang ada di sekitar RAM VM harus dipilih. Dengan mengalokasikan Node_Size yang lebih besar dari kapasitas RAM, Anda mengandalkan paging yang disediakan oleh runtime Service Fabric. Dengan demikian, kinerja Anda mungkin tidak optimal jika seluruh data Anda dianggap panas (sejak saat itu data dimasuk/keluarkan). Namun, untuk banyak layanan di mana hanya sebagian kecil datanya yang panas, tindakan ini lebih hemat biaya.

Jumlah node yang diperlukan untuk kinerja maksimum dapat dihitung sebagai berikut:

Number of Nodes = (DB_Size * RF)/Node_Size

Akun untuk pertumbuhan

Anda mungkin ingin menghitung jumlah node berdasarkan DB_Size yang Anda harapkan layanan Anda untuk tumbuh, selain DB_Size yang Anda mulai. Kemudian, tingkatkan jumlah node seiring dengan pertumbuhan layanan Anda sehingga Anda tidak menyediakan jumlah node yang berlebihan. Tetapi jumlah partisi harus didasarkan pada jumlah node yang diperlukan saat Anda menjalankan layanan pada pertumbuhan maksimum.

Ada baiknya untuk memiliki beberapa komputer tambahan yang tersedia kapan saja sehingga Anda dapat menangani lonjakan atau kegagalan yang tidak terduga (misalnya, jika beberapa VM mati). Meskipun kapasitas ekstra harus ditentukan dengan menggunakan lonjakan yang diharapkan, titik awalnya adalah memesan beberapa VM tambahan (ekstra 5-10 persen).

Yang sebelumnya mengasumsikan layanan stateful tunggal. Jika Anda memiliki lebih dari satu layanan stateful, Anda harus menambahkan DB_Size terkait dengan layanan lain ke dalam persamaan. Atau, Anda dapat menghitung jumlah node secara terpisah untuk setiap layanan stateful. Layanan Anda mungkin memiliki replika atau partisi yang tidak seimbang. Perlu diingat bahwa partisi mungkin juga memiliki lebih banyak data daripada yang lain. Untuk informasi selengkapnya tentang partisi, lihat praktik terbaik artikel pemartisian. Namun, persamaan sebelumnya adalah partisi dan replika agnostik, karena Service Fabric memastikan bahwa replika tersebar di antara node dengan cara yang dioptimalkan.

Gunakan spreadsheet untuk penghitungan biaya

Sekarang mari kita masukkan beberapa bilangan real dalam rumus. Sebuah contoh spreadsheet menunjukkan bagaimana merencanakan kapasitas untuk aplikasi yang berisi tiga jenis objek data. Untuk setiap objek, kita perkirakan ukurannya dan berapa banyak objek yang ingin kita miliki. Kita juga pilih berapa banyak replika yang kita inginkan dari setiap jenis objek. Spreadsheet menghitung jumlah total memori yang akan disimpan dalam klaster.

Kemudian kita masukkan ukuran VM dan biaya bulanan. Berdasarkan ukuran VM, spreadsheet memberi tahu Anda jumlah minimum partisi yang harus Anda gunakan untuk membagi data agar pas secara fisik pada node. Anda mungkin menginginkan lebih banyak partisi untuk mengakomodasi komputasi spesifik aplikasi Anda dan kebutuhan lalu lintas jaringan. Spreadsheet menunjukkan jumlah partisi yang mengelola objek profil pengguna telah meningkat dari satu menjadi enam.

Sekarang, berdasarkan semua informasi ini, spreadsheet menunjukkan bahwa Anda dapat secara fisik mendapatkan semua data dengan partisi dan replika yang diinginkan pada klaster 26-node. Namun, klaster ini akan sangat padat, jadi Anda mungkin menginginkan beberapa node tambahan untuk mengakomodasi kegagalan node dan peningkatan. Spreadsheet juga menunjukkan bahwa memiliki lebih dari 57 node tidak memberikan nilai tambahan karena Anda akan memiliki node kosong. Sekali lagi, Anda mungkin ingin tetap berada di atas 57 node untuk mengakomodasi kegagalan node dan peningkatan. Anda dapat mengubah spreadsheet agar sesuai dengan kebutuhan spesifik aplikasi Anda.

Langkah berikutnya

Lihat Layanan Pemartisian Service Fabric untuk mempelajari lebih lanjut tentang pemartisian layanan Anda.