Penskalaan otomatis di Service Fabric

Azure Service Fabric memudahkan untuk membangun aplikasi yang dapat diskalakan dengan mengelola layanan, partisi, dan replika pada node kluster. Menjalankan banyak beban kerja pada perangkat keras yang sama memungkinkan pemanfaatan sumber daya maksimum, tetapi juga memberikan fleksibilitas dalam hal bagaimana Anda memilih untuk menskalakan beban kerja Anda. Video Saluran 9 ini menjelaskan bagaimana Anda dapat membangun aplikasi layanan mikro yang dapat diskalakan:

Penskalaan dalam Service Fabric dicapai dengan beberapa cara yang berbeda:

1. Penskalaan dengan membuat atau menghapus instans layanan tanpa status
2. Penskalaan dengan membuat atau menghapus layanan bernama baru
3. Penskalaan dengan membuat atau menghapus instans aplikasi bernama baru
4. Penskalaan dengan menggunakan layanan yang dipartisi
5. Penskalaan dengan menambahkan dan menghapus node dari kluster
6. Penskalaan dengan menggunakan metrik Cluster Resource Manager

Penskalaan dengan membuat atau menghapus instans layanan tanpa status

Salah satu cara paling sederhana untuk menskalakan dalam Service Fabric bekerja dengan layanan tanpa status. Ketika Anda membuat layanan tanpa status, Anda mendapatkan kesempatan untuk menentukan InstanceCount. InstanceCount menentukan berapa banyak salinan kode layanan yang berjalan yang dibuat saat layanan dimulai. Katakanlah, misalnya, bahwa ada 100 node dalam kluster. Katakanlah juga bahwa layanan dibuat dengan InstanceCount dari 10. Selama runtime, 10 salinan kode yang berjalan semuanya bisa menjadi terlalu sibuk (atau bisa tidak cukup sibuk). Salah satu cara untuk menskalakan beban kerja tersebut adalah dengan mengubah jumlah instans. Misalnya, beberapa bagian dari pemantauan atau kode manajemen dapat mengubah jumlah instans yang ada menjadi 50, atau ke 5, tergantung apakah beban kerja perlu menurunkan atau meluaskan skala berdasarkan beban.

C#:

StatelessServiceUpdateDescription updateDescription = new StatelessServiceUpdateDescription(); 
updateDescription.InstanceCount = 50;
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

PowerShell:

Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50

Menggunakan Jumlah Instans Dinamis

Khusus untuk layanan tanpa status, Service Fabric menawarkan cara otomatis untuk mengubah jumlah instans. Hal ini memungkinkan layanan untuk menskalakan secara dinamis dengan jumlah node yang tersedia. Cara memilih perilaku ini adalah dengan mengatur jumlah instans = -1. InstanceCount = -1 adalah instruksi untuk Service Fabric yang berarti "Jalankan layanan tanpa status ini di setiap node". Jika jumlah node berubah, Service Fabric otomatis mengubah jumlah instans agar sesuai, memastikan layanan berjalan di semua node valid.

C#:

StatelessServiceDescription serviceDescription = new StatelessServiceDescription();
//Set other service properties necessary for creation....
serviceDescription.InstanceCount = -1;
await fc.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

Penskalaan dengan membuat atau menghapus layanan bernama baru

Instans layanan bernama adalah contoh spesifik dari jenis layanan (lihat masa pakai aplikasi Service Fabric) dalam beberapa instans aplikasi bernama di kluster.

Instans layanan bernama baru dapat dibuat (atau dihapus) karena layanan menjadi kurang atau lebih sibuk. Ini memungkinkan permintaan untuk tersebar di lebih banyak instans layanan, biasanya memungkinkan beban pada layanan yang ada berkurang. Saat membuat layanan, Service Fabric Cluster Resource Manager menempatkan layanan di kluster secara terdistribusi. Keputusan pasti diatur oleh metrik dalam kluster dan aturan penempatan lainnya. Layanan dapat dibuat dengan beberapa cara yang berbeda, tetapi yang paling umum adalah melalui tindakan administratif seperti seseorang yang memanggil New-ServiceFabricService, atau dengan memanggil kode CreateServiceAsync. CreateServiceAsync bahkan dapat dipanggil dari dalam layanan lain yang berjalan di kluster.

Membuat layanan secara dinamis dapat digunakan dalam segala macam skenario, dan merupakan pola yang umum. Misalnya, pertimbangkan layanan bertatus yang mewakili alur kerja tertentu. Panggilan yang mewakili pekerjaan akan muncul ke layanan ini, dan layanan ini akan menjalankan langkah-langkah untuk alur kerja tersebut dan merekam kemajuan.

Bagaimana Anda membuat skala layanan khusus ini? Layanan ini bisa multi-penyewa dalam beberapa formulir, dan menerima panggilan dan memulai langkah-langkah untuk berbagai instans alur kerja yang sama sekaligus. Namun, itu dapat membuat kode lebih kompleks, karena sekarang harus khawatir tentang banyak instans yang berbeda dari alur kerja yang sama, semua pada tahap yang berbeda dan dari pelanggan yang berbeda. Selain itu, menangani beberapa alur kerja secara bersamaan tidak menyelesaikan masalah skala. Ini karena pada titik tertentu layanan ini akan menggunakan terlalu banyak sumber daya agar sesuai dengan mesin tertentu. Banyak layanan yang tidak dibangun untuk pola ini pada awalnya juga mengalami kesulitan karena beberapa penyempitan atau perlambatan yang melekat dalam kodenya. Jenis masalah ini menyebabkan layanan tidak berfungsi juga ketika jumlah alur kerja bersamaan pelacakannya semakin besar.

Solusinya adalah membuat instans layanan ini untuk setiap instans alur kerja yang ingin Anda lacak. Ini adalah pola yang bagus dan bekerja apakah layanan ini tanpa status atau berstatus. Agar pola ini berfungsi, biasanya ada layanan lain yang bertindak sebagai "Workload Manager Service". Tugas layanan ini adalah menerima permintaan dan merutekan permintaan tersebut ke layanan lain. Manajer dapat secara dinamis membuat instans layanan beban kerja saat menerima pesan, lalu meneruskan permintaan ke layanan tersebut. Layanan manajer juga dapat menerima panggilan balik ketika layanan alur kerja tertentu menyelesaikan pekerjaannya. Ketika manajer menerima panggilan balik ini, ia dapat menghapus instans layanan alur kerja tersebut, atau membiarkannya jika lebih banyak panggilan diharapkan.

Versi lanjutan dari jenis manajer ini bahkan dapat membuat kumpulan layanan yang dikelolanya. Kumpulan membantu memastikan bahwa ketika permintaan baru masuk ke dalamnya tidak perlu menunggu layanan berjalan. Sebagai gantinya, manajer hanya dapat memilih layanan alur kerja yang saat ini tidak sibuk dari kumpulan tersebut, atau merutekan secara acak. Menjaga kumpulan layanan yang tersedia membuat penanganan permintaan baru lebih cepat, karena kecil kemungkinan permintaan harus menunggu layanan baru dijalankan. Membuat layanan baru cepat, tetapi tidak gratis atau seketika. Kumpulan tersebut membantu meminimalkan jumlah waktu permintaan harus menunggu sebelum dilayani. Anda akan sering melihat manajer dan pola kumpulan ini ketika waktu respons paling penting. Mengantre permintaan dan membuat layanan di latar belakang dan kemudian meneruskannya juga merupakan pola manajer yang populer, seperti halnya membuat dan menghapus layanan berdasarkan beberapa pelacakan jumlah pekerjaan yang saat ini tertunda layanan.

Penskalaan dengan membuat atau menghapus instans aplikasi bernama baru

Membuat dan menghapus seluruh instans aplikasi mirip dengan pola pembuatan dan penghapusan layanan. Untuk pola ini, ada beberapa layanan manajer yang membuat keputusan berdasarkan permintaan yang dilihatnya dan informasi yang diterimanya dari layanan lain di dalam kluster.

Kapan membuat instans aplikasi bernama baru digunakan sebagai ganti membuat instans layanan bernama baru di beberapa aplikasi yang sudah ada? Ada beberapa kasus:

• Instans aplikasi baru adalah untuk pelanggan yang kodenya perlu dijalankan di bawah beberapa pengaturan identitas atau keamanan tertentu.
  • Service Fabric memungkinkan menentukan paket kode yang berbeda untuk dijalankan di bawah identitas tertentu. Untuk meluncurkan paket kode yang sama di bawah identitas yang berbeda, aktivasi perlu terjadi dalam instans aplikasi yang berbeda. Pertimbangkan kasus di mana Anda memiliki beban kerja pelanggan yang sudah ada yang disebarkan. Ini mungkin berjalan di bawah identitas tertentu sehingga Anda dapat memantau dan mengontrol akses mereka ke sumber daya lain, seperti database jarak jauh atau sistem lainnya. Dalam hal ini, ketika pelanggan baru mendaftar, Anda mungkin tidak ingin mengaktifkan kode mereka dalam konteks yang sama (ruang proses). Meskipun Anda bisa, ini mempersulit kode layanan Anda untuk bertindak dalam konteks identitas tertentu. Anda biasanya harus memiliki lebih banyak kode keamanan, isolasi, dan manajemen identitas. Daripada menggunakan contoh layanan bernama yang berbeda dalam instans aplikasi yang sama dan karenanya ruang proses yang sama, Anda dapat menggunakan instans Aplikasi Service Fabric yang berbeda. Ini membuatnya lebih mudah untuk menentukan konteks identitas yang berbeda.
• Instans aplikasi baru juga berfungsi sebagai sarana konfigurasi
  • Secara default, semua instans layanan bernama dari jenis layanan tertentu dalam instans aplikasi akan berjalan dalam proses yang sama pada node tertentu. Apa artinya ini adalah bahwa sementara Anda dapat mengkonfigurasi setiap instans layanan secara berbeda, melakukannya rumit. Layanan harus memiliki beberapa token yang mereka gunakan untuk mencari konfigurasinya dalam paket konfigurasi. Biasanya ini hanya nama layanan. Ini berfungsi dengan baik, tetapi memiliki konfigurasi dengan nama instans layanan bernama individu dalam instans aplikasi tersebut. Ini bisa membingungkan dan sulit dikelola karena konfigurasi biasanya merupakan artefak waktu desain dengan nilai spesifik instans aplikasi. Membuat lebih banyak layanan selalu berarti lebih banyak peningkatan aplikasi untuk mengubah informasi di dalam paket konfigurasi atau untuk menyebarkan yang baru sehingga layanan baru dapat mencari informasi spesifik mereka. Seringkali lebih mudah untuk membuat instans aplikasi bernama baru. Kemudian Anda dapat menggunakan parameter aplikasi untuk mengatur konfigurasi apa pun yang diperlukan untuk layanan. Dengan cara ini semua layanan yang dibuat dalam instans aplikasi bernama dapat mewarisi pengaturan konfigurasi tertentu. Misalnya, alih-alih memiliki satu file konfigurasi dengan pengaturan dan penyesuaian untuk setiap pelanggan, seperti rahasia atau batas sumber daya pelanggan, Anda akan memiliki instans aplikasi yang berbeda untuk setiap pelanggan dengan pengaturan ini ditimpa.
• Aplikasi baru berfungsi sebagai batas peningkatan
  • Dalam Service Fabric, instans aplikasi bernama yang berbeda berfungsi sebagai batasan untuk ditingkatkan. Peningkatan satu instans aplikasi bernama tidak akan berdampak pada kode yang dijalankan instans aplikasi bernama lain. Aplikasi yang berbeda akan akhirnya menjalankan versi yang berbeda dari kode yang sama pada node yang sama. Ini bisa menjadi faktor ketika Anda perlu membuat keputusan penskalaan karena Anda dapat memilih apakah kode baru harus mengikuti peningkatan yang sama dengan layanan lain atau tidak. Misalnya, katakanlah bahwa panggilan tiba di layanan manajer yang bertanggung jawab untuk meningkatkan beban kerja pelanggan tertentu dengan membuat dan menghapus layanan secara dinamis. Namun, dalam hal ini, panggilan adalah untuk beban kerja yang terkait dengan pelanggan baru. Sebagian besar pelanggan suka diisolasi satu sama lain tidak hanya karena alasan keamanan dan konfigurasi yang tercantum sebelumnya, tetapi karena memberikan lebih banyak fleksibilitas dalam hal menjalankan versi perangkat lunak tertentu dan memilih kapan mereka ditingkatkan. Anda juga dapat membuat instans aplikasi baru dan membuat layanan di sana hanya untuk mempartisi lebih lanjut jumlah layanan Anda yang akan disentuh oleh satu peningkatan. Instans aplikasi terpisah memberikan granularitas yang lebih besar saat melakukan peningkatan aplikasi, dan juga mengaktifkan pengujian A/B dan penyebaran Biru/Hijau.
• Instans aplikasi yang ada penuh
  • Dalam Service Fabric, kapasitas aplikasi adalah konsep yang dapat Anda gunakan untuk mengontrol jumlah sumber daya yang tersedia untuk instans aplikasi tertentu. Misalnya, Anda dapat memutuskan bahwa layanan tertentu harus membuat instans lain untuk menskalakan. Namun, instans aplikasi ini berada di luar kapasitas untuk metrik tertentu. Jika pelanggan atau beban kerja tertentu ini masih harus diberikan lebih banyak sumber daya, maka Anda dapat meningkatkan kapasitas yang ada untuk aplikasi itu atau membuat aplikasi baru.

Penskalaan pada tingkat partisi

Service Fabric mendukung pemartisian. Pemartisian membagi layanan menjadi beberapa bagian logis dan fisik, yang masing-masing beroperasi secara independen. Ini berguna dengan layanan yang penuh keadaan, karena tidak ada satu set replika yang harus menangani semua panggilan dan memanipulasi semua status sekaligus. Ringkasan partisi memberikan informasi tentang jenis skema partisi yang didukung. Replika setiap partisi tersebar di node dalam kluster, mendistribusikan beban layanan itu dan memastikan bahwa layanan secara keseluruhan atau partisi apa pun tidak memiliki satu titik kegagalan.

Pertimbangkan layanan yang menggunakan skema pemartisian rentang dengan kunci rendah 0, kunci tinggi 99, dan jumlah partisi 4. Dalam kluster tiga node, layanan mungkin ditata dengan empat replika yang berbagi sumber daya pada setiap node seperti yang ditunjukkan di sini:

Jika Anda meningkatkan jumlah node, Service Fabric akan memindahkan beberapa replika yang ada di sana. Misalnya, jumlah node meningkat menjadi empat dan replika didistribusikan kembali. Sekarang layanan sekarang memiliki tiga replika yang berjalan pada setiap node, masing-masing milik partisi yang berbeda. Ini memungkinkan pemanfaatan sumber daya yang lebih baik karena node baru tidak dingin. Biasanya, ini juga meningkatkan kinerja karena setiap layanan memiliki lebih banyak sumber daya yang tersedia untuk itu.

Penskalaan dengan menggunakan Service Fabric Cluster Resource Manager dan metrik

Metrik adalah cara layanan mengekspresikan konsumsi sumber daya mereka ke Service Fabric. Menggunakan metrik memberi Cluster Resource Manager kesempatan untuk mengatur ulang dan mengoptimalkan tata letak kluster. Misalnya, mungkin ada banyak sumber daya di kluster, tetapi mereka mungkin tidak dialokasikan ke layanan yang saat ini melakukan pekerjaan. Menggunakan metrik memungkinkan Cluster Resource Manager untuk mengatur ulang kluster untuk memastikan bahwa layanan memiliki akses ke sumber daya yang tersedia.

Penskalaan dengan menambahkan dan menghapus node dari kluster

Pilihan lain untuk penskalaan dengan Service Fabric adalah mengubah ukuran kluster. Mengubah ukuran kluster berarti menambahkan atau menghapus node untuk satu atau beberapa jenis node dalam kluster. Misalnya, pertimbangkan kasus di mana semua node dalam kluster panas. Ini berarti bahwa sumber daya kluster hampir semua digunakan. Dalam hal ini, menambahkan lebih banyak node ke kluster adalah cara terbaik untuk menskalakan. Setelah node baru bergabung dengan kluster, Service Fabric Cluster Resource Manager memindahkan layanan kepada mereka, menghasilkan lebih sedikit total beban pada node yang ada. Untuk layanan tanpa status dengan jumlah instans = -1, lebih banyak instans layanan secara otomatis dibuat. Hal ini memungkinkan beberapa panggilan untuk berpindah dari node yang ada ke node baru.

Untuk informasi selengkapnya, lihat penskalaan kluster.

Memilih platform

Karena perbedaan implementasi antara sistem operasi, memilih untuk menggunakan Service Fabric dengan Windows atau Linux dapat menjadi bagian penting dari penskalaan aplikasi Anda. Salah satu hambatan potensial adalah bagaimana pengelogan bertahap dilakukan. Service Fabric pada Windows menggunakan driver kernel untuk log satu-per-mesin, dibagi antara replika layanan yang dinyatakan. Log ini memiliki berat sekitar 8 GB. Linux, di sisi lain, menggunakan log bertahap 256 MB untuk setiap replika, sehingga kurang ideal untuk aplikasi yang ingin memaksimalkan jumlah replika layanan ringan yang berjalan pada node tertentu. Perbedaan persyaratan penyimpanan sementara ini berpotensi menginformasikan platform yang diinginkan untuk penyebaran kluster Service Fabric.

Menyatukan semuanya

Mari kita ambil semua ide yang telah kita bahas di sini dan berbicara melalui contoh. Pertimbangkan layanan berikut: Anda mencoba membangun layanan yang bertindak sebagai buku alamat, berpegang pada nama dan informasi kontak.

Tepat di depan Anda memiliki banyak pertanyaan yang terkait dengan skala: Berapa banyak pengguna yang akan Anda miliki? Berapa banyak kontak yang akan disimpan setiap pengguna? Sulit untuk mencoba memikirkan ini semua saat Anda berdiri untuk pertama kalinya. Katakanlah Anda akan menggunakan satu layanan statis dengan jumlah partisi tertentu. Konsekuensi dari memilih jumlah partisi yang salah dapat menyebabkan Anda memiliki masalah skala nanti. Demikian pula, bahkan jika Anda memilih hitungan yang tepat, Anda mungkin tidak memiliki semua informasi yang Anda butuhkan. Misalnya, Anda juga harus memutuskan ukuran kluster di depan, baik dalam hal jumlah node dan ukurannya. Biasanya sulit untuk memprediksi berapa banyak sumber daya yang akan dikonsumsi layanan selama masa hidupnya. Mungkin juga sulit untuk mengetahui sebelumnya pola lalu lintas yang benar-benar dilihat oleh layanan. Misalnya, mungkin orang menambahkan dan menghapus kontak mereka hanya hal pertama di pagi hari, atau mungkin didistribusikan secara merata sepanjang hari. Berdasarkan hal ini Anda mungkin perlu melakukan peluasan dan penurunan skala secara dinamis. Mungkin Anda dapat belajar memprediksi kapan Anda akan perlu melakukan peluasan atau penurunan skala, tetapi bagaimanapun Anda mungkin akan perlu bereaksi untuk mengubah konsumsi sumber daya oleh layanan Anda. Ini dapat melibatkan perubahan ukuran kluster untuk menyediakan lebih banyak sumber daya saat mengatur ulang penggunaan sumber daya yang ada tidak cukup.

Tetapi mengapa bahkan mencoba untuk memilih skema partisi tunggal untuk semua pengguna? Mengapa membatasi diri Anda untuk satu layanan dan satu kluster statis? Situasi sebenarnya biasanya lebih dinamis.

Saat membangun skala, pertimbangkan pola dinamis berikut. Anda mungkin perlu menyesuaikannya dengan situasi Anda:

1. Daripada mencoba memilih skema partisi untuk semua orang di depan, bangun "layanan manajer".
2. Pekerjaan layanan manajer adalah melihat informasi pelanggan ketika mereka mendaftar untuk layanan Anda. Lalu, dari informasi itu layanan manajer membuat instans layanan penyimpanan kontak Anda yang sebenarnyahanya untuk pelanggan itu. Jika memerlukan konfigurasi, isolasi, atau peningkatan tertentu, Anda juga dapat memutuskan untuk memutar instans Aplikasi untuk pelanggan ini.

Pola pembuatan dinamis ini memiliki banyak keuntungan:

• Anda tidak mencoba menebak jumlah partisi yang benar untuk semua pengguna di depan atau membangun satu layanan yang dapat diskalakan tanpa batas sendiri.
• Pengguna yang berbeda tidak harus memiliki jumlah partisi, jumlah replika, batasan penempatan, metrik, beban default, nama layanan, pengaturan dns, atau properti lain yang ditentukan di tingkat layanan atau aplikasi.
• Anda mendapatkan segmentasi data tambahan. Setiap pelanggan memiliki salinan layanan mereka sendiri
  • Setiap layanan pelanggan dapat dikonfigurasi secara berbeda dan diberikan lebih banyak atau lebih sedikit sumber daya, dengan lebih banyak atau lebih sedikit partisi atau replika yang diperlukan berdasarkan skala yang diharapkan.
    • Misalnya, katakanlah pelanggan membayar untuk tingkat "Emas" - mereka bisa mendapatkan lebih banyak replika atau jumlah partisi yang lebih besar, dan kemungkinan sumber daya yang didedikasikan untuk layanan mereka melalui metrik dan kapasitas aplikasi.
    • Atau katakanlah mereka memberikan informasi yang menunjukkan jumlah kontak yang mereka butuhkan adalah "Kecil" - mereka hanya akan mendapatkan beberapa partisi, atau bahkan dapat dimasukkan ke dalam kumpulan layanan bersama dengan pelanggan lain.
• Anda tidak menjalankan banyak instans layanan atau replika saat Anda menunggu pelanggan muncul
• Jika pelanggan keluar, maka menghapus informasi mereka dari layanan Anda semudah meminta pengelola menghapus layanan atau aplikasi yang dibuatnya.

Langkah berikutnya

Untuk informasi selengkapnya tentang konsep Service Fabric, lihat artikel berikut ini:

• Ketersediaan layanan Service Fabric
• Layanan Partisi Service Fabric