Praktik terbaik untuk Memorystore for Valkey

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

Praktik terbaik manajemen memori

Bagian ini menjelaskan strategi untuk mengelola memori instance agar Memorystore for Valkey berfungsi secara efisien untuk aplikasi Anda.

Konsep manajemen memori

• Penggunaan memori: jumlah memori yang digunakan instance Anda. Anda memiliki kapasitas memori tetap. Anda dapat menggunakan metrik untuk memantau jumlah memori yang Anda gunakan.

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

Memantau penggunaan memori untuk instance

Untuk memantau penggunaan memori instance Memorystore for Valkey, sebaiknya lihat metrik /instance/memory/maximum_utilization. Jika penggunaan memori instance mendekati 80% dan Anda memperkirakan penggunaan data akan bertambah, tingkatkan ukuran instance untuk memberi ruang bagi data baru.

Jika instance memiliki penggunaan memori yang tinggi, lakukan hal berikut untuk meningkatkan performa:

• Tingkatkan ukuran instance.
• Turunkan parameter konfigurasi maxmemory.

Jika Anda mengalami masalah, hubungi Google Cloud layanan pelanggan.

Menskalakan shard dalam Mode Cluster Diaktifkan

Saat Anda menskalakan jumlah shard dalam instance, sebaiknya lakukan penskalaan selama periode penulisan rendah. Penskalaan selama periode penggunaan tinggi dapat memberikan tekanan memori pada instance Anda karena overhead memori yang disebabkan oleh replikasi atau migrasi slot.

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

Untuk kasus penggunaan Valkey yang tidak ingin kehilangan kunci, Anda hanya boleh memperkecil skala ke instance 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 dalam instance Anda. Anda dapat menggunakan metrik /instance/memory/total_used_memory untuk melihat jumlah data yang disimpan di instance Anda.

Praktik terbaik penggunaan CPU

Jika terjadi pemadaman layanan zona yang tidak terduga, hal ini akan menyebabkan berkurangnya resource CPU untuk instance Anda karena hilangnya kapasitas dari node di zona yang tidak tersedia. Sebaiknya gunakan instance 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 /instance/cpu/maximum_utilization.

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

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

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

Jika instance Anda mengalami penggunaan CPU yang tinggi atau resource instance habis (misalnya, karena terlalu banyak koneksi), instance mungkin akan mengalami gangguan dan metrik eksternal mungkin akan hilang.

Perintah Valkey yang memerlukan banyak resource

Sebaiknya hindari penggunaan perintah Valkey 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 Valkey diblokir
• Health check, kemampuan observasi, dan replikasi yang kekurangan resource

Tabel berikut mencantumkan contoh perintah Valkey yang memerlukan banyak resource dan memberikan alternatif yang efisien 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	DELETE	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 /instance/memory/average_utilization dan /instance/memory/maximum_utilization. Untuk mengetahui informasi selengkapnya tentang metrik ini, lihat Metrik pemantauan yang didukung.

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

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

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

• Penggunaan memori rata-rata instance 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 /instance/cpu/average_utilization dan /instance/cpu/maximum_utilization.

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

• Penggunaan CPU rata-rata instance Anda melebihi batas yang disarankan, yaitu 70%.
• Pemakaian CPU maksimum melebihi 80% dan pemakaian CPU rata-rata melebihi 50%.

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

• Penggunaan CPU rata-rata instance Anda turun di bawah batas 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 Valkey 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 instance yang paling banyak dimuat, sedangkan nilai rata-rata mewakili beban untuk seluruh instance. 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 instance. Untuk mengetahui informasi selengkapnya, lihat Menskalakan kapasitas instance.

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

Praktik terbaik klien Valkey

Menghindari kelebihan beban koneksi di Valkey

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

• Tentukan ukuran kumpulan koneksi klien yang terbaik untuk Anda. Ukuran awal yang baik untuk setiap klien adalah satu koneksi per node Valkey. Kemudian, Anda dapat melakukan tolok ukur untuk melihat apakah lebih banyak koneksi dapat membantu tanpa memenuhi jumlah koneksi maksimum yang diizinkan.

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

Mendeteksi dan menangani koneksi yang tidak responsif

Sebaiknya konfigurasikan aplikasi klien Anda untuk mendeteksi koneksi yang tidak responsif ke Memorystore for Valkey. 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.

Untuk instance Cluster Mode Enabled

Aplikasi Anda harus menggunakan klien Valkey yang mendukung cluster saat terhubung ke instance Memorystore for Valkey Cluster Mode Enabled. 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 dalam instance untuk mengirim permintaan ke node yang benar. Hal ini mencegah overhead performa yang disebabkan oleh pengalihan.

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 menjadi 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 SLOTS, NODES, atau CLUSTER SHARDS ke server Valkey. Sebaiknya gunakan perintah CLUSTER SHARDS. CLUSTER SHARDS menggantikan perintah SLOTS (tidak digunakan lagi), dengan memberikan representasi instance yang lebih efisien dan dapat diperluas.

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

Pembaruan topologi node ini memerlukan biaya yang besar di server Valkey, 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 node, 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 Valkey tidak responsif dalam jangka waktu yang lama, sehingga menyebabkan pemakaian CPU yang sangat tinggi.

Menggunakan endpoint penemuan untuk penemuan node

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

Untuk instance Cluster Mode Disabled

Saat aplikasi Anda terhubung ke instance Cluster Mode Disabled, aplikasi harus terhubung ke endpoint utama untuk menulis ke instance dan mengambil penulisan terbaru. Aplikasi Anda juga dapat terhubung ke endpoint pembaca untuk membaca dari replika dan mengisolasi traffic dari node utama.

Karena instance Cluster Mode Disabled hanya memiliki satu shard, instance tersebut tidak menggunakan topologi dalam memori. Oleh karena itu, pemuatan ulang topologi tidak berlaku.

Selama peristiwa failover dan pemeliharaan, koneksi ke instance akan terputus. Untuk memastikan aplikasi Anda berhasil terhubung kembali setelah peristiwa ini, terapkan mekanisme percobaan ulang dengan backoff eksponensial.

Anda dapat menggunakan strategi buat sebelum hancurkan saat melakukan pemeliharaan pada instance. Untuk mengetahui informasi selengkapnya tentang strategi ini, lihat Strategi siklus proses buat sebelum hancurkan.

Jika menggunakan strategi ini, Anda mungkin menerima pesan error berikut:

READONLY You can't write against a read only replica.

Untuk mengatasi masalah ini, hentikan koneksi ke instance Anda. Kemudian, buat ulang koneksi.

Praktik terbaik persistensi

Bagian ini menjelaskan praktik terbaik untuk persistensi.

Persistensi RDB dan penambahan replika

Untuk mendapatkan hasil terbaik dari pencadangan instance dengan snapshot RDB atau menambahkan replika ke instance, 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 lipat 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. Untuk mengetahui informasi selengkapnya, lihat Memantau penggunaan memori untuk instance.

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

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

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

Setelah penggunaan memori instance 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 instance dan meningkatkan latensi untuk aplikasi Anda. Anda dapat meminimalkan dampak performa snapshot RDB dengan menjadwalkannya untuk dijalankan selama periode traffic instance rendah jika Anda merasa nyaman dengan snapshot yang lebih jarang.

Misalnya, jika instance 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 konstan dan memerlukan snapshot yang sering, sebaiknya evaluasi dampak performa dengan cermat dan pertimbangkan 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 instance zona tunggal

Jika Anda mengonfigurasi instance agar tidak menggunakan replika, sebaiknya gunakan instance 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 instance zona tunggal.

Meminimalkan dampak pemadaman layanan

Saat Anda memilih instance zona tunggal, pemadaman layanan zona cenderung tidak akan memengaruhi instance 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 instance Anda berada akan nonaktif, dibandingkan dengan kemungkinan 100% bahwa node, yang terletak di zona yang tidak tersedia, akan terpengaruh.

Pemulihan cepat

Jika terjadi pemadaman layanan di zona untuk instance zona tunggal, Memorystore for Valkey akan menyederhanakan pemulihan data Anda. Anda dapat menyediakan instance 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 instance di zona pilihan Anda karena batasan resource sementara, coba buat instance di zona lain dalam region yang sama atau di region lain.
• Gunakan akses lintas region: konfigurasikan klien Anda untuk mengakses instance yang berada di region berbeda. Jika Anda perlu menyediakan instance yang berada di region berbeda karena batasan resource lokal, klien Anda dapat terhubung ke instance tersebut.
• Gunakan replikasi lintas region: untuk mempromosikan instance sekunder di region alternatif ke instance baca atau tulis utama untuk disaster recovery, lakukan peralihan.

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 Valkey 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 instance dan meningkatkan latensi instance.

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 instance 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 instance Anda.