Praktik terbaik untuk Memorystore for Redis Cluster

Halaman ini memberikan panduan tentang cara menggunakan Memorystore for Redis Cluster secara optimal. Halaman ini juga menunjukkan potensi masalah yang harus dihindari.

Catatan: Untuk melihat contoh konfigurasi klien cluster Redis, lihat Contoh kode library klien.

Praktik terbaik manajemen memori

Bagian ini menjelaskan strategi pengelolaan memori untuk cluster agar Memorystore for Redis Cluster berfungsi secara efisien untuk aplikasi klien Anda.

Konsep manajemen memori

• Beban tulis - Volume dan kecepatan penambahan atau pembaruan kunci di cluster Redis Anda. Beban tulis Anda dapat berkisar dari normal hingga sangat tinggi, bergantung pada kasus penggunaan Redis dan pola penggunaan aplikasi Anda.

• Kebijakan penghapusan - Memorystore for Redis Cluster menggunakan kebijakan penghapusan volatile-lru. Anda dapat menggunakan perintah seperti perintah EXPIRE untuk menetapkan penghapusan kunci.

Memantau cluster yang memiliki beban tulis normal

Lihat metrik /cluster/memory/maximum_utilization. Jika /cluster/memory/maximum_utilization berada pada 100% atau lebih rendah, cluster Redis Anda akan berperforma baik saat Anda menggunakan beban tulis normal.

Namun, jika penggunaan memori mendekati 100% dan Anda memperkirakan penggunaan data akan bertambah, Anda harus meningkatkan ukuran cluster untuk memberi ruang bagi data baru.

Memantau cluster yang memiliki beban tulis tinggi

Lihat metrik /cluster/memory/maximum_utilization. Bergantung pada tingkat keparahan beban tulis yang tinggi, cluster Anda dapat mengalami masalah performa pada nilai minimum berikut:

• Beban tulis yang sangat tinggi dapat mengalami masalah jika /cluster/memory/maximum_utilization mencapai 65% atau lebih tinggi.

• Beban tulis yang cukup tinggi dapat mengalami masalah jika /cluster/memory/maximum_utilization mencapai 85% atau lebih tinggi.

Dalam skenario ini, Anda harus meningkatkan ukuran cluster untuk meningkatkan performa.

Jika Anda mengalami masalah, atau khawatir cluster Anda memiliki beban tulis yang tinggi, hubungi DukunganGoogle Cloud .

Menskalakan shard

Saat menskalakan jumlah shard dalam cluster, Anda harus melakukan penskalaan selama periode penulisan rendah. Penskalaan selama periode beban tulis yang tinggi dapat memberikan tekanan memori pada cluster Anda karena overhead memori yang disebabkan oleh replikasi atau migrasi slot.

Jika kasus penggunaan Redis Anda menggunakan penghapusan kunci, penskalaan ke ukuran cluster yang lebih kecil dapat mengurangi rasio cache ditemukan. Namun, dalam situasi ini, Anda tidak perlu khawatir akan kehilangan data, karena penghapusan kunci memang diperkirakan akan terjadi.

Untuk kasus penggunaan Redis yang tidak ingin kehilangan kunci, Anda hanya boleh memperkecil skala ke cluster yang lebih kecil yang masih memiliki cukup ruang untuk data Anda. Jumlah shard target baru Anda harus memungkinkan setidaknya 1,5 kali memori yang digunakan oleh data. Dengan kata lain, Anda harus menyediakan shard yang cukup untuk 1,5 kali jumlah data di cluster Anda. Anda dapat menggunakan metrik /cluster/memory/total_used_memory untuk melihat jumlah data yang disimpan di cluster Anda.

Praktik terbaik penggunaan CPU

Jika terjadi pemadaman layanan zona yang tidak terduga, hal ini akan menyebabkan berkurangnya resource CPU untuk cluster Anda karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan cluster dengan ketersediaan tinggi. Menggunakan beberapa replika per shard (bukan satu replika per shard) akan memberikan resource CPU tambahan selama pemadaman layanan. Anda dapat memiliki hingga lima replika per shard.

Selain itu, sebaiknya kelola penggunaan CPU node agar node memiliki overhead CPU yang cukup untuk menangani traffic tambahan dari kapasitas yang hilang jika terjadi pemadaman layanan zona yang tidak terduga. Anda harus memantau penggunaan CPU untuk primer dan replika menggunakan metrik Detik CPU Thread Utama /cluster/cpu/maximum_utilization.

Bergantung pada jumlah replika yang Anda sediakan per node, sebaiknya gunakan target penggunaan CPU /cluster/cpu/maximum_utilization berikut:

• Untuk cluster dengan satu replika per node, targetkan nilai /cluster/cpu/maximum_utilization 0,5 detik untuk primer dan 0,5 detik untuk replika.
• Untuk cluster dengan dua replika per node atau lebih, targetkan nilai /cluster/cpu/maximum_utilization sebesar 0,9 detik untuk replika utama dan 0,5 detik untuk setiap replika.

Jika nilai untuk metrik melebihi rekomendasi ini, sebaiknya tingkatkan jumlah shard di cluster Anda. Jika memiliki kurang dari lima replika untuk cluster, Anda juga dapat meningkatkan jumlah replika, hingga maksimum lima replika.

Jika cluster Anda mengalami penggunaan CPU yang tinggi atau resource cluster habis (misalnya, karena memiliki terlalu banyak koneksi), cluster mungkin akan berperilaku tidak semestinya dan metrik eksternal mungkin akan hilang.

Perintah Redis yang memerlukan banyak resource

Sebaiknya hindari penggunaan perintah Redis yang menggunakan banyak resource. Penggunaan perintah ini dapat menyebabkan masalah performa berikut:

• Latensi tinggi dan waktu tunggu klien
• Tekanan memori yang disebabkan oleh perintah yang meningkatkan penggunaan memori
• Kehilangan data selama replikasi dan sinkronisasi node karena thread utama Redis diblokir
• Health check, kemampuan observasi, dan replikasi yang kekurangan resource

Tabel berikut mencantumkan contoh perintah Redis yang menggunakan banyak resource dan memberikan alternatif yang hemat resource.

Tips: Selain memerlukan banyak resource, seiring bertambahnya ukuran total data Anda, biaya penggunaan perintah ini juga akan meningkat.

Untuk menemukan perintah yang berjalan lama yang Anda gunakan, gunakan SLOWLOG. Alat ini memberi Anda daftar perintah yang memerlukan waktu paling lama untuk dijalankan. Hasilnya, Anda mengetahui perintah yang menyebabkan masalah latensi. Untuk menentukan alternatif yang hemat resource untuk perintah ini, lihat tabel berikut.

Kategori	Perintah yang menggunakan banyak resource	Alternatif yang hemat resource
Jalankan untuk seluruh keyspace	KEYS	SCAN
Menjalankan untuk keyset dengan panjang variabel	LRANGE	Batasi ukuran rentang yang Anda gunakan untuk kueri.
	ZRANGE	Batasi ukuran rentang yang Anda gunakan untuk kueri.
	HGETALL	HSCAN
	SMEMBERS	SSCAN
Memblokir eksekusi skrip	EVAL	Pastikan skrip Anda tidak berjalan tanpa batas waktu.
	EVALSHA	Pastikan skrip Anda tidak berjalan tanpa batas waktu.
Menghapus file dan link	DEL	UNLINK
Publikasikan dan berlangganan	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Praktik terbaik untuk penskalaan nilai minimum

Skenario nilai minimum penskalaan termasuk dalam kategori berikut:

• Penskalaan untuk penggunaan memori
• Penskalaan untuk pemakaian CPU
• Penskalaan untuk mengurangi hotspot

Jika workload Anda mengandalkan penghapusan kunci, Google tidak merekomendasikan penskalaan turun untuk penggunaan CPU atau memori. Dalam workload ini, penggunaan memori sering kali mencapai kapasitas maksimumnya sebelum pengeluaran terjadi secara otomatis. Lonjakan memori yang dihasilkan akan memblokir operasi penurunan skala.

Bagian berikut menjelaskan skenario umum dan nilai minimum metrik yang mungkin memerlukan penskalaan.

Penskalaan penggunaan memori

Untuk menentukan kapan harus melakukan penskalaan berdasarkan penggunaan memori, pantau metrik /cluster/memory/average_utilization dan /cluster/memory/maximum_utilization. Untuk mengetahui informasi selengkapnya tentang metrik ini, lihat Metrik pemantauan yang didukung.

Jika cluster Anda memenuhi salah satu kondisi berikut, pertimbangkan untuk memicu operasi penyebaran skala:

• Penggunaan memori rata-rata cluster Anda melebihi batas yang disarankan, yaitu 70%.
• Penggunaan memori maksimum melebihi 80% dan penggunaan memori rata-rata melebihi 50%.

Jika cluster Anda memenuhi salah satu kondisi berikut, pertimbangkan untuk memicu operasi penurunan skala:

• Penggunaan memori rata-rata cluster Anda turun di bawah nilai minimum yang disarankan, yaitu 50%.
• Penggunaan memori maksimum turun di bawah 60% dan penggunaan memori rata-rata turun di bawah 40%.

Penskalaan pemakaian CPU

Untuk menentukan kapan harus melakukan penskalaan berdasarkan penggunaan CPU, pantau metrik /cluster/cpu/average_utilization dan /cluster/cpu/maximum_utilization.

Jika cluster Anda memenuhi salah satu kondisi berikut, pertimbangkan untuk memicu operasi penyebaran skala:

• Penggunaan CPU rata-rata cluster Anda melebihi batas yang disarankan sebesar 70%.
• Pemakaian CPU maksimum melebihi 80% dan pemakaian CPU rata-rata melebihi 50%.

Jika cluster Anda memenuhi salah satu kondisi berikut, pertimbangkan untuk memicu operasi penurunan skala:

• Pemakaian CPU rata-rata cluster Anda turun di bawah nilai minimum yang disarankan, yaitu 50%.
• Pemakaian CPU maksimum turun di bawah 60% dan pemakaian CPU rata-rata turun di bawah 40%.

Penskalaan untuk mengurangi hotspot

Memorystore for Redis Cluster menyediakan variasi rata-rata dan maksimum dari metrik yang sama, yang dapat Anda gunakan untuk mengidentifikasi hotspot untuk kelompok metrik tersebut. Nilai maksimum mewakili node cluster yang paling banyak dimuat, sedangkan nilai rata-rata mewakili beban untuk seluruh cluster. Jika nilai maksimum secara signifikan lebih tinggi daripada nilai rata-rata, hal ini menunjukkan bahwa node tertentu dimuat secara tidak proporsional (hotspot). Untuk mengatasi masalah ini, sebaiknya lakukan penyebaran skala cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Menskalakan kapasitas cluster.

Saat mengamati perbedaan yang signifikan antara variasi rata-rata dan maksimum, Anda dapat menjalankan perintah INFO memory dan INFO cpu terhadap node cluster untuk mengumpulkan data real-time langsung dari cluster. Untuk mengetahui informasi selengkapnya tentang penggunaan perintah ini, lihat INFO dalam dokumentasi Redis.

Praktik terbaik klien Redis

Aplikasi Anda harus menggunakan klien Redis yang mendukung cluster saat terhubung ke cluster. Untuk contoh klien yang mendukung cluster dan contoh konfigurasi, lihat Contoh kode library klien. Klien Anda harus mempertahankan peta slot hash ke node yang sesuai di cluster untuk mengirim permintaan ke node yang tepat dan menghindari overhead performa yang disebabkan oleh pengalihan cluster.

Pemetaan klien

Klien harus mendapatkan daftar lengkap slot dan node yang dipetakan dalam situasi berikut:

• Saat diinisialisasi, klien harus mengisi pemetaan slot awal ke node.

• Saat pengalihan MOVED diterima dari server, seperti dalam situasi failover ketika semua slot yang dilayani oleh node utama sebelumnya diambil alih oleh replika, atau sharding ulang saat slot dipindahkan dari node utama sumber ke node utama target.

• Saat error CLUSTERDOWN diterima dari server atau koneksi ke server tertentu terus-menerus mengalami waktu tunggu habis.

• Saat error READONLY diterima dari server. Hal ini dapat terjadi saat primary didemosikan ke replika.

• Selain itu, klien harus memperbarui topologi secara berkala agar klien tetap siap menghadapi perubahan dan mempelajari perubahan yang mungkin tidak menyebabkan pengalihan atau error dari server, seperti saat node replika baru ditambahkan. Perhatikan bahwa koneksi yang tidak berlaku juga harus ditutup sebagai bagian dari pembaruan topologi untuk mengurangi kebutuhan penanganan koneksi yang gagal selama runtime perintah.

Penemuan klien

Penemuan klien biasanya dilakukan dengan mengeluarkan perintah CLUSTER SLOT, CLUSTER NODE, atau CLUSTER SHARDS ke server Redis. Sebaiknya gunakan perintah CLUSTER SHARDS. CLUSTER SHARDS menggantikan perintah CLUSTER SLOTS (tidak digunakan lagi), dengan memberikan representasi cluster yang lebih efisien dan dapat diperluas.

Ukuran respons untuk perintah penemuan klien cluster dapat bervariasi berdasarkan ukuran dan topologi cluster. Cluster yang lebih besar dengan lebih banyak node menghasilkan respons yang lebih besar. Oleh karena itu, penting untuk memastikan bahwa jumlah klien yang melakukan penemuan topologi cluster tidak bertambah tanpa batas.

Pembaruan topologi ini memerlukan banyak biaya di server Redis, tetapi juga penting untuk ketersediaan aplikasi. Oleh karena itu, penting untuk memastikan bahwa setiap klien membuat satu permintaan penemuan pada waktu tertentu (dan menyimpan hasil dalam memori), dan jumlah klien yang membuat permintaan tetap dibatasi untuk menghindari kelebihan beban server.

Misalnya, saat aplikasi klien dimulai atau kehilangan koneksi dari server dan harus melakukan penemuan cluster, salah satu kesalahan umum adalah aplikasi klien membuat beberapa permintaan koneksi ulang dan penemuan tanpa menambahkan backoff eksponensial saat mencoba ulang. Hal ini dapat membuat server Redis tidak responsif dalam jangka waktu yang lama, sehingga menyebabkan pemakaian CPU yang sangat tinggi.

Menghindari kelebihan beban penemuan di Redis

Untuk mengurangi dampak yang disebabkan oleh lonjakan permintaan koneksi dan penemuan yang tiba-tiba, sebaiknya lakukan hal berikut:

• Terapkan kumpulan koneksi klien dengan ukuran terbatas dan kecil untuk membatasi jumlah koneksi masuk serentak dari aplikasi klien.

• Saat klien terputus dari server karena waktu tunggu habis, coba lagi dengan backoff eksponensial dengan jitter. Hal ini membantu menghindari beberapa klien membebani server secara bersamaan.

• Gunakan endpoint penemuan Memorystore for Redis Cluster untuk melakukan penemuan cluster. Endpoint penemuan memiliki ketersediaan tinggi dan di-load balance di semua node dalam cluster. Selain itu, endpoint penemuan mencoba merutekan permintaan penemuan cluster ke node dengan tampilan topologi terbaru.

Mendeteksi dan menangani koneksi yang tidak responsif

Sebaiknya konfigurasikan aplikasi klien Anda untuk mendeteksi koneksi yang tidak responsif ke Memorystore for Redis Cluster. Saat koneksi yang tidak responsif terdeteksi, klien harus meresetnya. Untuk membangun aplikasi yang tangguh, sebaiknya gunakan konfigurasi klien berikut:

• Konfigurasikan parameter keep-alive TCP: tetapkan parameter TCP keepalive time, TCP keepalive interval, dan TCP keepalive probes agar klien mendeteksi dan menghapus koneksi yang tidak responsif secara proaktif, bahkan saat koneksi tidak ada aktivitas. Misalnya, jika Anda menetapkan parameter TCP keepalive time ke 30 detik, TCP keepalive interval ke 10 detik, dan TCP keepalive probes ke 3, maka klien akan mereset koneksi tidak ada aktivitas yang tidak responsif dalam waktu satu menit.
• Konfigurasi waktu tunggu pengguna TCP: tetapkan waktu tunggu ini di klien Anda untuk mereset koneksi yang memiliki permintaan yang belum terselesaikan dan berhenti merespons. Misalnya, jika Anda menetapkan waktu tunggu ke 15 detik, klien akan mereset koneksi yang tidak responsif yang memiliki permintaan yang belum terselesaikan setelah 15 detik.

Praktik terbaik persistensi

Bagian ini menjelaskan praktik terbaik untuk persistensi.

Persistensi RDB dan penambahan replika

Untuk hasil terbaik dalam mencadangkan cluster dengan snapshot RDB atau menambahkan replika ke cluster, gunakan praktik terbaik berikut:

Manajemen memori

Snapshot RDB menggunakan fork proses dan mekanisme'copy-on-write' untuk mengambil snapshot data node. Bergantung pada pola penulisan ke node, memori yang digunakan node akan bertambah seiring halaman yang disentuh oleh penulisan disalin. Jejak memori dapat mencapai dua kali ukuran data dalam node.

Untuk memastikan node memiliki memori yang cukup untuk menyelesaikan snapshot, pertahankan atau tetapkan maxmemory pada 80% kapasitas node sehingga 20% dicadangkan untuk overhead. Overhead memori ini, selain memantau snapshot, membantu Anda mengelola workload agar snapshot berhasil. Selain itu, saat Anda menambahkan replika, turunkan traffic tulis sebanyak mungkin. Lihat Memantau cluster yang memiliki beban tulis tinggi untuk mempelajari lebih lanjut.

Catatan: Jika Anda menambahkan replika ke cluster yang menggunakan lebih dari 80% memori maksimum cluster, operasi akan gagal dan Anda akan menerima pesan error.

Untuk mengatasi masalah ini, kurangi penggunaan memori cluster Anda dengan salah satu cara berikut:

• Turunkan jejak memori cluster Anda menjadi kurang dari 80% dari memori maksimum yang diizinkan node.
• Skalakan jenis node untuk cluster Anda agar memiliki lebih banyak memori.

Setelah penggunaan memori cluster Anda berada di bawah batas 80%, tambahkan replika lagi.

Snapshot usang

Memulihkan node dari snapshot yang tidak berlaku dapat menyebabkan masalah performa pada aplikasi Anda saat aplikasi mencoba merekonsiliasi sejumlah besar kunci yang tidak berlaku atau perubahan lain pada database Anda, seperti perubahan skema. Jika Anda khawatir tentang pemulihan dari snapshot yang sudah tidak berlaku, Anda dapat menonaktifkan fitur persistensi RDB. Setelah Anda mengaktifkan kembali persistensi, snapshot akan diambil pada interval snapshot terjadwal berikutnya.

Dampak performa snapshot RDB

Bergantung pada pola workload Anda, snapshot RDB dapat memengaruhi performa cluster dan meningkatkan latensi untuk aplikasi Anda. Anda dapat meminimalkan dampak performa snapshot RDB dengan menjadwalkannya untuk dijalankan selama periode traffic cluster rendah jika Anda merasa nyaman dengan snapshot yang lebih jarang.

Misalnya, jika cluster Anda memiliki traffic rendah dari pukul 01.00 hingga 04.00, Anda dapat menetapkan waktu mulai ke pukul 03.00 dan menetapkan interval ke 24 jam.

Jika sistem Anda memiliki beban yang konstan dan memerlukan snapshot yang sering, Anda harus mengevaluasi dampak performa dengan cermat, dan mempertimbangkan manfaat penggunaan snapshot RDB untuk workload.

Menambahkan replika

Menambahkan replika memerlukan snapshot RDB. Untuk mengetahui informasi selengkapnya tentang snapshot RDB, lihat Manajemen memori.

Kapan harus menggunakan cluster zona tunggal

Jika Anda mengonfigurasi cluster agar tidak menggunakan replika, sebaiknya gunakan cluster zona tunggal. Berikut alasannya:

Biaya dan performa

Jika meminimalkan biaya dan memiliki performa puncak untuk klien yang berada di region yang sama adalah pendorong utama Anda, sebaiknya pilih cluster zona tunggal.

Meminimalkan dampak pemadaman layanan

Jika Anda memilih cluster zona tunggal, pemadaman layanan di zona tertentu cenderung tidak akan memengaruhi cluster Anda. Dengan menempatkan semua node dalam satu zona, kemungkinan pemadaman layanan di zona tersebut yang memengaruhi server Anda akan turun dari 100% menjadi 33%. Ada kemungkinan 33% bahwa zona tempat cluster Anda berada akan mengalami gangguan, dibandingkan dengan kemungkinan 100% bahwa node, yang berada di zona yang tidak tersedia, akan terpengaruh.

Pemulihan cepat

Jika terjadi pemadaman layanan zona untuk cluster zona tunggal, Memorystore for Redis Cluster akan menyederhanakan pemulihan data Anda. Anda dapat menyediakan cluster baru di zona yang berfungsi dengan cepat dan mengalihkan aplikasi Anda untuk operasi yang minim gangguan.

Praktik terbaik perencanaan kapasitas

Untuk memastikan bahwa Anda dapat berhasil menyediakan resource dan membangun arsitektur yang tangguh, sebaiknya ikuti praktik terbaik perencanaan kapasitas berikut:

• Deploy di beberapa lokasi: jika Anda tidak dapat membuat cluster di zona pilihan karena batasan resource sementara, coba buat cluster di zona lain dalam region yang sama atau di region lain.
• Menggunakan akses lintas region: konfigurasikan klien Anda untuk mengakses cluster Anda yang berada di region yang berbeda. Jika Anda perlu menyediakan cluster yang berada di region berbeda karena batasan resource lokal, klien Anda dapat terhubung ke cluster tersebut.
• Gunakan replikasi lintas region: untuk mempromosikan cluster sekunder di region alternatif ke cluster baca atau tulis utama untuk disaster recovery, lakukan pengalihan.

Praktik terbaik Lettuce

Bagian ini menjelaskan praktik terbaik untuk menggunakan Lettuce untuk terhubung ke cluster.

Memperbarui nilai parameter

Saat Anda menggunakan Lettuce, ubah parameter validateClusterNodeMembership menjadi false. Jika tidak, saat topologi berubah, Anda mungkin akan mendapatkan error unknownPartition.

Mengaktifkan Transport Layer Security (TLS)

Bagian ini menjelaskan manfaat keamanan dan implikasi performa dari penggunaan Transport Layer Security (TLS), beserta rekomendasi untuk pengaktifannya.

Manfaat keamanan

Dengan menggunakan TLS, Anda akan mendapatkan manfaat keamanan berikut:

• Autentikasi Identity and Access Management (IAM): TLS menggunakan jenis autentikasi ini untuk melindungi dari serangan spoofing server, seperti serangan person-in-the-middle.
• Enkripsi dalam pengiriman: Enkripsi bawaanGoogle Cloudmelindungi traffic dalam jaringan Google di tingkat infrastruktur. Namun, hal ini melibatkan kepercayaan terhadap stack host dan stack jaringan Google. Meskipun enkripsi ini transparan dan diaktifkan secara default, enkripsi ini tidak bersifat end-to-end. Di sisi lain, TLS menggunakan enkripsi dalam pengiriman di lapisan aplikasi. Enkripsi end-to-end ini memberi Anda kontrol lebih besar atas kunci dan proses enkripsi Anda.
• Perlindungan token autentikasi: Jika Anda menggunakan autentikasi IAM, mengaktifkan TLS akan meminimalkan risiko terekspos dan bocornya token autentikasi Anda.

Implikasi performa

TLS memengaruhi performa dengan cara berikut:

• Membuat koneksi: Klien dan server yang telah membuat sesi TLS dapat melanjutkan sesi tanpa mengulangi proses pembuatan koneksi yang memerlukan banyak resource antara klien dan server. Dengan mengaktifkan TLS resumption, Anda mengurangi overhead pembuatan koneksi antara klien dan server.

  Jika Anda tidak membuat TLS resumption, pembuatan koneksi akan memerlukan banyak resource. Untuk koneksi baru dan yang sudah ada, banyak koneksi antara klien dan server dapat menyebabkan waktu tunggu koneksi habis. Hal ini dapat menyebabkan efek bola salju karena Memorystore for Redis Cluster mencoba membuat ulang koneksi yang waktu tunggunya habis, sehingga meningkatkan resource yang digunakan untuk membuat koneksi.

• Mengenkripsi dan mendekripsi data: Enkripsi dan dekripsi data melibatkan operasi yang menggunakan banyak CPU, yang berdampak pada klien dan server. Hal ini dapat mengurangi kapasitas cluster dan meningkatkan latensi cluster.

Rekomendasi

Saat mempertimbangkan apakah akan mengaktifkan TLS, sebaiknya evaluasi kebijakan keamanan Anda sambil mempertimbangkan manfaat dan kelemahan TLS. Jika Anda memilih untuk mengaktifkan TLS, perhatikan pertimbangan berikut:

• Mengaktifkan pelanjutan TLS akan mengurangi overhead untuk membuat koneksi. Koneksi antara klien dan server hanya diperlukan untuk koneksi awal. Namun, perluasan ukuran cluster klien yang tiba-tiba dapat mengakibatkan gangguan singkat yang disebabkan oleh handshake penuh awal setiap host klien baru.
• Meskipun beberapa library klien mungkin tidak menawarkan kontrol bawaan untuk mengaktifkan TLS, Anda dapat menggunakan kode kustom untuk mengintegrasikan fungsi ini ke dalam cluster Anda.