Pengembangan

  • Artikel

Ketahanan koneksi dan beban server

Saat mengembangkan aplikasi klien, pastikan untuk mempertimbangkan praktik terbaik yang relevan untuk ketahanan koneksi dan mengelola beban server.

Pertimbangkan lebih banyak kunci dan nilai yang lebih kecil

Azure Cache for Redis bekerja paling baik dengan nilai yang lebih kecil. Untuk menyebarkan data melalui beberapa kunci, pertimbangkan untuk membagi potongan data yang lebih besar ke potongan yang lebih kecil. Selengkapnya tentang ukuran nilai ideal, lihat artikel ini.

Permintaan atau ukuran respons besar

Permintaan/respons yang besar dapat menyebabkan waktu habis. Sebagai contoh, misalkan nilai batas waktu Anda yang dikonfigurasi pada klien Anda adalah 1 detik. Aplikasi Anda meminta dua kunci (misalnya, 'A' dan 'B') secara bersamaan (menggunakan koneksi jaringan fisik yang sama). Sebagian besar klien mendukung alur permintaan, di mana permintaan 'A' dan 'B' dikirim satu demi satu tanpa menunggu respons mereka. Server mengirim respons kembali dalam urutan yang sama. Jika respons 'A' besar, itu bisa memakan sebagian besar habisnya waktu untuk permintaan nanti.

Dalam contoh berikut, permintaan 'A' dan 'B' dikirim dengan cepat ke server. Server mulai mengirim respons 'A' dan 'B' dengan cepat. Karena waktu transfer data, respons 'B' harus menunggu waktu habis di balik respons 'A' meskipun server merespons dengan cepat.

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

Permintaan/respons ini sulit diukur. Anda dapat membuat instrumen kode klien untuk melacak permintaan dan respons besar.

Resolusi untuk ukuran respons besar bervariasi tetapi mencakup:

  • Optimalkan aplikasi Anda untuk sejumlah besar nilai kecil, bukan beberapa nilai besar.
  • Tingkatkan ukuran komputer virtual (VM) Anda untuk mendapatkan kemampuan bandwidth yang lebih tinggi
    • Lebih banyak bandwidth pada komputer virtual klien atau server Anda dapat mengurangi waktu transfer data untuk respons yang lebih besar.
    • Bandingkan penggunaan jaringan Anda saat ini pada kedua mesin dengan batas ukuran komputer virtual Anda saat ini. Lebih banyak bandwidth hanya pada server atau hanya pada klien mungkin tidak cukup.
  • Tingkatkan jumlah objek koneksi yang digunakan aplikasi Anda.
    • Gunakan pendekatan round-robin untuk membuat permintaan atas objek koneksi yang berbeda.

Distribusi kunci

Jika Anda berencana menggunakan pengklusteran Redis, baca dulu Praktik Terbaik Pengklusteran Redis dengan Kunci.

Gunakan alur

Cobalah untuk memilih klien Redis yang mendukung Redis pipelining. Pipelining membantu memanfaatkan jaringan secara efisien dan mendapatkan throughput terbaik.

Hindari operasi yang mahal

Beberapa operasi Redis, seperti perintah KEYS, mahal dan harus dihindari. Untuk beberapa pertimbangan seputar perintah yang berjalan lama, lihat perintah yang berjalan lama.

Memilih tingkat yang sesuai

Gunakan tingkat Standar, Premium, Enterprise, atau Enterprise Flash untuk sistem produksi. Jangan gunakan tingkat Dasar dalam produksi. Tingkat Dasar adalah sistem simpul tunggal tanpa replikasi data dan tanpa SLA. Selain itu, gunakan setidaknya cache C1. C0 {i>cache

  • Berbagi inti CPU
  • menggunakan sedikit memori
  • rentan terhadap masalah tetangga yang bising

Kami merekomendasikan pengujian performa untuk memilih tingkat yang tepat dan memvalidasi pengaturan koneksi. Selengkapnya, lihat Pengujian kinerja.

Klien di wilayah yang sama dengan cache

Temukan instans cache dan aplikasi Anda di wilayah yang sama. Menyambungkan ke cache di wilayah yang berbeda dapat secara signifikan meningkatkan latensi dan mengurangi keandalan.

Meskipun Anda dapat terhubung dari luar Azure, tidak disarankan, terutama saat menggunakan Redis sebagai cache. Jika Anda menggunakan server Redis hanya sebagai penyimpanan kunci/nilai, latensi mungkin bukan perhatian utama.

Mengandalkan nama host bukan alamat IP publik

Alamat IP publik yang ditetapkan ke cache Anda dapat berubah sebagai hasil dari operasi skala atau peningkatan backend. Sebaiknya andalkan nama host, bukan alamat IP publik eksplisit. Berikut adalah formulir yang direkomendasikan untuk berbagai tingkatan:

Tingkat Formulir
Dasar, Standar, Premium <cachename>.redis.cache.windows.net
Enterprise, Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

Pilih versi Redis yang sesuai

Versi default Redis yang digunakan saat membuat cache dapat berubah dari waktu ke waktu. Azure Cache for Redis mungkin mengadopsi versi baru saat versi baru Redis sumber terbuka dirilis. Jika Anda memerlukan versi Redis tertentu untuk aplikasi Anda, sebaiknya pilih versi Redis secara eksplisit saat Anda membuat cache.

Panduan khusus untuk tingkat Enterprise

Karena tingkat Enterprise dan Enterprise Flash dibangun di Redis Enterprise daripada Redis sumber terbuka, ada beberapa perbedaan dalam praktik terbaik pengembangan. Untuk informasi selengkapnya, lihat Praktik Terbaik untuk tingkat Enterprise dan Enterprise Flash.

Menggunakan enkripsi TLS (Keamanan Lapisan Transportasi)

Azure Cache for Redis memerlukan komunikasi terenkripsi TLS secara {i>default.

Jika pustaka atau alat klien Anda tidak mendukung TLS (Keamanan Lapisan Transportasi), maka mengaktifkan koneksi tidak terenkripsi dimungkinkan melalui portal Microsoft Azure atau API manajemen. Jika koneksi terenkripsi tidak memungkinkan, sebaiknya tempatkan {i>cachetabel ini.

Perubahan Sertifikat Azure TLS

Microsoft memperbarui layanan Azure untuk menggunakan sertifikat TLS dari kumpulan Certificate Authorities (CA) yang berbeda. Perubahan ini diluncurkan secara bertahap mulai tanggal 13 Agustus 2020 hingga 26 Oktober 2020 (estimasi). Azure melakukan perubahan ini karena sertifikat CA saat ini tidak memenuhi salah satu persyaratan CA/Forum Browser Baseline. Masalah ini dilaporkan pada tanggal 1 Juli 2020 dan berlaku untuk beberapa penyedia Infrastruktur Utama Publik (PKI) yang populer di seluruh dunia. Sebagian besar sertifikat TLS yang digunakan oleh layanan Azure saat ini berasal dari Baltimore CyberTrust Root PKI. Layanan Azure Cache for Redis terus dirantai ke Baltimore CyberTrust Root. Namun, sertifikat server TLS-nya akan diterbitkan oleh Intermediate Certificate Authorities (IPA) yang baru mulai tanggal 12 Oktober 2020.

Catatan

Perubahan ini terbatas pada layanan di wilayah Azure umum. Ini tidak termasuk cloud pemerintah (misalnya, Tiongkok) atau independen.

Apakah perubahan ini memengaruhi saya?

Sebagian besar pelanggan Azure Cache for Redis tidak terpengaruh oleh perubahan tersebut. Aplikasi Anda mungkin terpengaruh jika secara eksplisit menentukan daftar sertifikat yang dapat diterima, praktik yang dikenal sebagai penyematan sertifikat. Jika disematkan pada sertifikat menengah atau leaf, bukan Baltimore CyberTrust Root, Anda harus segera mengambil tindakan untuk mengubah konfigurasi sertifikat.

Azure Cache for Redis tidak mendukung stapling OCSP.

Tabel berikut ini menyediakan informasi tentang sertifikat yang sedang diluncurkan. Bergantung pada sertifikat mana yang digunakan aplikasi, Anda mungkin perlu memperbaruinya untuk mencegah hilangnya konektivitas ke instans Azure Cache for Redis Anda.

Tipe CA Saat ini Pascapeluncuran (12 Okt 2020) Perbuatan
Akar Thumbprint: d4de20d05e66fc53fe1a50882c78db2852cae474

Kedaluwarsa: Senin, 12 Mei 2025, 16:59:00

Nama Subjek:
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 Tidak berubah Tidak
Menengah Thumbprint:
CN = Microsoft IT TLS CA 1
Thumbprint: 417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
Thumbprint: 54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
Thumbprint: 8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
Thumbprint: Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

Kedaluwarsa: ‎Jumat, ‎20 ‎Mei ‎2024 05:52:38

Nama Subjek:
OU = Microsoft IT
O = Microsoft Corporation
L = Redmond
S = Washington
C = AS
 Thumbprint:
CN = Microsoft RSA TLS CA 01
Thumbprint: 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
Thumbprint: b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

Kedaluwarsa: ‎Selasa, ‎8 ‎Oktober ‎2024 12:00:00;

Nama Subjek:
O = Microsoft Corporation
C = AS
 Wajib

Tindakan apa yang harus saya ambil?

Jika aplikasi Anda menggunakan penyimpanan sertifikat sistem operasi atau menyematkan root Baltimore antara lain, tidak ada tindakan yang diperlukan.

Jika aplikasi Anda menyematkan sertifikat TLS menengah atau leaf, kami sarankan Anda menyematkan root berikut:

Sertifikat Thumbprint
Baltimore Root CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

Tip

Baik sertifikat menengah maupun leaf diperkirakan akan sering berubah. Kami menyarankan untuk tidak mengambil ketergantungan pada sertifikat. Sebaliknya sematkan aplikasi Anda ke sertifikat akar karena penyediaan lebih jarang.

Untuk terus menyematkan sertifikat menengah, tambahkan yang berikut ini ke daftar sertifikat menengah yang disematkan, yang mencakup beberapa sertifikat tambahan untuk meminimalkan perubahan pada masa mendatang:

Nama umum CA Thumbprint
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Issuing CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

Jika aplikasi Anda memvalidasi sertifikat dalam kode, Anda harus memodifikasinya untuk mengenali properti --- misalnya, Penerbit, Thumbprint --- dari sertifikat yang baru disematkan. Verifikasi tambahan ini harus mencakup semua sertifikat yang disematkan agar lebih siap untuk menghadapi masa depan.

Panduan khusus pustaka klien

Untuk informasi selengkapnya, lihat Pustaka klien.

Langkah berikutnya