Arsitektur Azure Managed Redis

Azure Managed Redis berjalan di atas tumpukan Redis Enterprise, yang memberikan keuntungan signifikan dibandingkan dengan Redis edisi komunitas. Informasi berikut ini memberikan rincian yang lebih mendetail tentang bagaimana Azure Managed Redis dirancang, termasuk informasi yang dapat bermanfaat bagi pengguna tingkat lanjut.

Perbandingan dengan Azure Cache for Redis

Tingkat Dasar, Standar, dan Premium Azure Cache for Redis berjalan pada edisi komunitas Redis. Edisi komunitas Redis ini memiliki beberapa keterbatasan yang signifikan, termasuk hanya menggunakan satu utas. Batasan ini mengurangi performa secara signifikan dan membuat penskalaan kurang efisien karena layanan tidak sepenuhnya menggunakan lebih banyak vCPU. Instans Azure Cache for Redis yang khas menggunakan arsitektur seperti ini:

Perhatikan bahwa dua VM digunakan - primer dan replika. VM ini juga disebut nodus. Simpul utama menjalankan proses Redis utama dan menerima semua penulisan. Replikasi dilakukan secara asinkron ke simpul replika untuk memberikan salinan cadangan selama pemeliharaan, penskalaan, atau kegagalan yang tidak terduga. Setiap simpul hanya dapat menjalankan satu proses server Redis karena desain satu utas komunitas Redis.

Peningkatan arsitektur Azure Managed Redis

Azure Managed Redis menggunakan arsitektur yang lebih canggih yang terlihat seperti ini:

Ada beberapa perbedaan:

• Setiap komputer virtual (atau node) menjalankan beberapa proses server Redis (disebut shard) secara paralel. Beberapa pecahan memungkinkan pemanfaatan vCPU yang lebih efisien pada setiap komputer virtual dan performa yang lebih tinggi.
• Tidak semua shard Redis utama berada di VM/node yang sama. Sebaliknya, pecahan primer dan replika didistribusikan di kedua simpul. Karena pecahan utama menggunakan lebih banyak sumber daya CPU daripada pecahan replika, pendekatan ini memungkinkan lebih banyak pecahan utama berjalan secara paralel.
• Setiap simpul memiliki proses proksi berkinerja tinggi untuk mengelola pecahan, menangani manajemen koneksi, dan memicu penyembuhan diri.

Arsitektur ini memungkinkan performa yang lebih tinggi dan fitur canggih seperti replikasi geografis aktif.

Pengklusteran

Setiap instans Azure Managed Redis dikonfigurasi secara internal untuk menggunakan pengklusteran, di semua tingkatan dan SKU. Azure Managed Redis didasarkan pada Redis Enterprise, yang dapat menggunakan beberapa pecahan per node. Kemampuan tersebut mencakup instans yang lebih kecil yang hanya disiapkan untuk menggunakan satu shard. Pengklusteran adalah cara untuk membagi data dalam instans Redis di beberapa proses Redis, juga disebut sharding. Azure Managed Redis menawarkan tiga kebijakan kluster yang menentukan protokol mana yang tersedia untuk klien Redis untuk menyambungkan ke instans cache.

Kebijakan kluster

Azure Managed Redis menawarkan tiga kebijakan pengklusteran: OSS, Enterprise, dan Non-Clustered. Kebijakan kluster OSS baik untuk sebagian besar aplikasi karena mendukung throughput maksimum yang lebih tinggi, tetapi setiap versi memiliki kelebihan dan kekurangannya sendiri.

• Jika Anda berpindah dari topologi nonclustered Dasar, Standar, atau Premium, pertimbangkan untuk menggunakan pengklusteran OSS untuk meningkatkan performa. Gunakan konfigurasi nonclustered hanya jika aplikasi Anda tidak dapat mendukung topologi OSS atau Enterprise. Kebijakan pengklusteran OSS menerapkan API yang sama dengan perangkat lunak sumber terbuka Redis. REDIS Cluster API memungkinkan klien Redis untuk terhubung langsung ke shard pada setiap simpul Redis, meminimalkan latensi dan mengoptimalkan throughput jaringan. Throughput berkembang secara hampir linier saat jumlah shard dan vCPU meningkat. Kebijakan pengklusteran OSS umumnya menawarkan latensi terendah dan performa throughput terbaik. Namun, kebijakan kluster OSS mengharuskan pustaka klien Anda untuk mendukung API Kluster Redis. Saat ini, hampir semua klien Redis mendukung REDIS Cluster API, tetapi kompatibilitas mungkin menjadi masalah untuk versi klien yang lebih lama atau pustaka khusus.

Anda tidak dapat menggunakan kebijakan pengklusteran OSS dengan modul RediSearch.

Protokol pengklusteran OSS mengharuskan klien untuk membuat koneksi shard yang benar. Koneksi awal melalui port 10000. Menghubungkan ke simpul individual menggunakan port dengan rentang 85XX. Port 85xx dapat berubah dari waktu ke waktu, dan Anda tidak boleh melakukan hardcode ke dalam aplikasi Anda. Klien Redis yang mendukung pengklusteran menggunakan perintah NODES KLUSTER untuk menentukan port yang tepat yang digunakan untuk shard utama dan replika dan membuat koneksi shard untuk Anda.

Kebijakan pengklusteran Enterprise adalah konfigurasi yang lebih sederhana yang menggunakan satu titik akhir untuk semua koneksi klien. Saat Anda menggunakan kebijakan pengklusteran Enterprise, kebijakan ini merutekan semua permintaan ke satu simpul Redis yang bertindak sebagai proksi. Simpul ini secara internal merutekan permintaan ke simpul yang benar dalam kluster. Keuntungan dari pendekatan ini adalah membuat Azure Managed Redis terlihat tidak berkluster bagi pengguna. Itu berarti bahwa pustaka klien Redis tidak perlu mendukung Pengklusteran Redis untuk mendapatkan beberapa keuntungan performa Redis Enterprise. Menggunakan satu titik akhir meningkatkan kompatibilitas mundur dan membuat koneksi lebih sederhana. Kelemahannya adalah bahwa proksi node tunggal dapat menjadi hambatan dalam pemanfaatan sumber daya komputasi atau throughput jaringan.

Kebijakan pengklusteran Enterprise adalah satu-satunya yang dapat Anda gunakan dengan modul RediSearch. Meskipun kebijakan kluster Enterprise membuat instans Azure Managed Redis tampaknya tidak diklusterkan kepada pengguna, instans ini masih memiliki beberapa batasan dengan Perintah Multi-kunci.

Kebijakan pengklusteran Non-Clustered menyimpan data pada setiap node tanpa proses sharding. Ini hanya berlaku untuk cache berukuran 25 GB dan lebih kecil. Skenario untuk menggunakan kebijakan pengelompokkan tak berkelompok meliputi:

• Saat bermigrasi dari lingkungan Redis yang tidak terpecah-pecah. Misalnya, topologi non-janggut SKU Dasar, Standar, dan Premium dari Azure Cache for Redis.
• Saat menjalankan perintah lintas slot secara ekstensif dan membagi data ke dalam shard dapat menyebabkan kegagalan. Misalnya, perintah MULTI.
• Saat menggunakan Redis sebagai broker pesan dan tidak memerlukan sharding.

Pertimbangan untuk menggunakan kebijakan Nonclustered adalah:

• Kebijakan ini hanya berlaku untuk tingkat Azure Managed Redis yang kurang dari atau sama dengan 25 GB.
• Ini tidak berkinerja seperti kebijakan pengklusteran lainnya, karena CPU hanya dapat melakukan multithread dengan perangkat lunak Redis Enterprise saat cache dipecah.
• Jika Anda ingin meningkatkan cache Azure Managed Redis, Anda harus terlebih dahulu mengubah kebijakan kluster.
• Jika Anda berpindah dari topologi nonclustered Dasar, Standar, atau Premium, pertimbangkan untuk menggunakan kluster OSS untuk meningkatkan performa. Gunakan konfigurasi nonclustered hanya jika aplikasi Anda tidak dapat mendukung topologi OSS atau Enterprise.

Menskalakan keluar atau menambahkan simpul

Perangkat lunak Redis Enterprise inti meningkatkan skalabilitas dengan menggunakan VM berukuran lebih besar atau memperluas dengan menambahkan lebih banyak simpul atau VM. Kedua opsi penskalaan menambahkan lebih banyak memori, lebih banyak vCPU, dan lebih banyak pecahan. Karena redundansi ini, Azure Managed Redis tidak menyediakan kemampuan untuk mengontrol jumlah node tertentu yang digunakan di setiap konfigurasi. Detail implementasi ini diabstraksi untuk menghindari kebingungan, kompleksitas, dan konfigurasi suboptimal. Sebagai gantinya, setiap SKU dirancang dengan konfigurasi node yang memaksimalkan vCPU dan memori. Beberapa SKU Azure Managed Redis menggunakan dua simpul, sementara yang lain menggunakan lebih banyak.

Perintah dengan beberapa kunci

Karena instans Azure Managed Redis menggunakan konfigurasi berkluster, Anda mungkin melihat CROSSSLOT pengecualian pada perintah yang beroperasi pada beberapa kunci. Perilaku bervariasi tergantung pada kebijakan pengklusteran yang digunakan. Jika Anda menggunakan kebijakan pengklusteran OSS, semua kunci dalam perintah multikunci harus dipetakan ke slot hash yang sama.

Anda mungkin juga melihat CROSSSLOT kesalahan dengan kebijakan pengklusteran Perusahaan. Hanya perintah multikey berikut yang diizinkan di seluruh slot dengan pengklusteran perusahaan: DEL, MSET, MGET, EXISTS, UNLINK, dan TOUCH.

Dalam database Active-Active, perintah tulis multikey (DEL, , MSET) UNLINKhanya dapat berjalan pada kunci yang berada di slot yang sama. Namun, perintah multikey berikut diizinkan di seluruh slot dalam database Active-Active: MGET, EXISTS, dan TOUCH. Untuk informasi selengkapnya, lihat Pengklusteran database.

Konfigurasi sharding

Setiap SKU Azure Managed Redis menjalankan sejumlah proses server Redis tertentu, yang disebut shard, secara paralel. Hubungan antara performa throughput, jumlah shard, dan jumlah vCPU yang tersedia pada setiap instans itu kompleks. Anda tidak dapat mengubah jumlah pecahan secara manual.

Untuk ukuran memori tertentu, versi Memory Optimized memiliki jumlah vCPU dan shard paling sedikit, sementara versi Compute Optimized memiliki yang tertinggi.

Meningkatkan jumlah pecahan umumnya meningkatkan performa karena operasi Redis dapat berjalan secara paralel. Tetapi, jika tidak ada vCPU yang tersedia untuk menjalankan perintah, performa dapat menurun.

Shard dipetakan untuk mengoptimalkan penggunaan setiap vCPU sambil mempertahankan siklus vCPU untuk proses server Redis, agen manajemen, dan tugas sistem OS yang juga memengaruhi performa. Aplikasi klien yang Anda buat berinteraksi dengan Azure Managed Redis seolah-olah itu adalah database logis tunggal. Layanan ini menangani perutean di seluruh vCPU dan shard.

Untuk meningkatkan jumlah pecahan dalam SKU, gunakan tingkat yang lebih besar di SKU tersebut. Anda juga dapat mengubah SKU agar sesuai dengan kebutuhan performa Anda.

Tabel berikut menunjukkan rasio vCPU terhadap pecahan utama pada ukuran tingkat tertentu. Data dalam kolom tidak menjamin bahwa ini adalah jumlah vCPU atau shard. Tabel hanya untuk ilustrasi.

Nota

Azure Managed Redis mengoptimalkan performa dari waktu ke waktu dengan mengubah jumlah shard dan vCPU yang digunakan pada setiap SKU.

Versi memori yang dioptimalkan, Seimbang, dan Komputasi yang dioptimalkan

Tabel ini memperlihatkan contoh umum hubungan Ukuran dengan vCPU/pecahan utama.

Tingkatan	Memory Optimized	Seimbang	Compute Optimized
Ukuran (GB)	vCPU/pecahan primer	vCPU/pecahan primer	vCPU/pecahan primer
24 ¹	4/2	8 Juni	16 Desember
60 ¹	8 Juni	16 Desember	32/24

¹ Rasio vCPU terhadap pecahan utama pada ukuran tingkat tertentu bukan merupakan jaminan untuk SKU atau tingkat tersebut.

Versi flash yang dioptimalkan

Tabel ini memperlihatkan contoh umum hubungan Ukuran dengan vCPU/pecahan utama.

Tingkatan	Flash Dioptimalkan (pratinjau)
Ukuran (GB)	vCPU/pecahan primer
480 ¹ ²	16 Desember
720 ¹ ²	24/24

¹ Tingkatan ini berada di pratinjau publik.

² Rasio vCPU terhadap shard utama pada ukuran lapis tertentu tidak mewakili jaminan untuk SKU atau lapis.

Penting

Semua tier memori yang menggunakan penyimpanan lebih dari 350 GB berada di Pratinjau Umum, termasuk Memori yang Dioptimalkan M500 dan lebih tinggi; Seimbang B500 dan lebih tinggi; dan Komputasi yang Dioptimalkan X500 dan lebih tinggi. Semua tingkatan ini dan yang lebih tinggi lagi tersedia dalam Pratinjau Publik.

Semua tingkatan yang dioptimalkan untuk Flash berada dalam Pratinjau Umum.

Berjalan tanpa mengaktifkan mode ketersediaan tinggi

Anda dapat menjalankan tanpa mode ketersediaan tinggi (HA) diaktifkan. Konfigurasi ini berarti bahwa instans Redis Anda tidak mengaktifkan replikasi dan tidak memiliki akses ke SLA ketersediaan. Jangan jalankan dalam mode non-HA di luar skenario pengembangan dan pengujian. Anda tidak dapat menonaktifkan fitur tinggi ketersediaan pada instans yang telah Anda buat. Anda dapat mengaktifkan ketersediaan tinggi pada instans yang saat ini tidak memilikinya. Karena instance yang berjalan tanpa ketersediaan tinggi menggunakan lebih sedikit VM dan simpul, vCPU tidak digunakan dengan efisien, sehingga performa mungkin lebih rendah.

Saat Anda mengaktifkan mode HA, instans Anda disebarkan dengan pecahan utama dan replika yang didistribusikan di setidaknya dua node. Konfigurasi ini direkomendasikan untuk semua skenario produksi dan untuk akses ke SLA ketersediaan. Di wilayah yang mendukung zona ketersediaan, Azure Managed Redis mendistribusikan simpul di seluruh zona secara default. Untuk informasi selengkapnya, lihat Keandalan di Azure Managed Redis.

Memori yang dipesan

Pada setiap Instans Azure Managed Redis, sekitar 20% memori yang tersedia dicadangkan sebagai buffer untuk operasi non-cache, seperti replikasi selama failover dan buffer geo-replikasi aktif. Buffer ini membantu meningkatkan performa cache dan mencegah kelaparan memori.

Mengurangi ukuran

Penurunan skala saat ini tidak didukung di Azure Managed Redis. Untuk informasi selengkapnya, lihat Batasan penskalaan Azure Managed Redis.

Tingkatan Flash yang Dioptimalkan

Tingkat Flash Optimized menggunakan penyimpanan NVMe Flash dan RAM. Karena penyimpanan Flash lebih rendah biayanya, menggunakan tingkat Flash Optimized memungkinkan Anda untuk menukar beberapa performa untuk efisiensi harga.

Pada instance yang dioptimalkan untuk Flash, 20% ruang cache berada di RAM, sementara 80% lainnya menggunakan penyimpanan Flash. Semua kunci disimpan pada RAM, sementara nilai dapat disimpan baik di penyimpanan Flash atau RAM. Perangkat lunak Redis dengan cerdas menentukan lokasi nilai. Nilai panas yang sering diakses disimpan di RAM, sementara nilai Dingin yang kurang umum digunakan disimpan di Flash. Sebelum data dibaca atau ditulis, data harus dipindahkan ke RAM, menjadi data panas.

Karena Redis mengoptimalkan performa terbaik, instans terlebih dahulu mengisi RAM yang tersedia sebelum menambahkan item ke penyimpanan Flash. Mengisi RAM terlebih dahulu memiliki beberapa implikasi untuk performa:

• Performa yang lebih baik dan latensi yang lebih rendah dapat terjadi saat pengujian dengan penggunaan memori yang rendah. Pengujian dengan instans cache penuh dapat menghasilkan performa yang lebih rendah karena hanya RAM yang digunakan dalam fase pengujian penggunaan memori yang rendah.
• Saat Anda menulis lebih banyak data ke cache, proporsi data dalam RAM dibandingkan dengan penyimpanan Flash menurun, biasanya menyebabkan latensi dan performa throughput juga menurun.

Beban kerja sangat cocok untuk tingkat Flash Optimized

Beban kerja yang berjalan dengan baik pada tingkat Flash Optimized sering memiliki karakteristik berikut:

• Pembacaan yang berat, dengan rasio perintah baca yang tinggi dibandingkan dengan perintah tulis.
• Akses berfokus pada subset kunci yang jauh lebih sering Anda gunakan daripada himpunan data lainnya.
• Nilai yang relatif besar dibandingkan dengan nama-nama kunci. (Karena nama kunci selalu disimpan dalam RAM, nilai besar dapat menjadi hambatan untuk pertumbuhan memori.)

Beban kerja yang tidak cocok untuk tingkat Flash Optimized

Beberapa beban kerja memiliki karakteristik akses yang kurang dioptimalkan untuk desain tingkat Flash Optimized:

• Menulis beban kerja yang berat.
• Pola akses data acak atau seragam di sebagian besar himpunan data.
• Nama-nama kunci yang panjang dengan ukuran nilai relatif kecil.

Konten terkait

• Menskalakan instans Azure Managed Redis