Jasa Managed Redis untuk Cache & Antrean
Cache, penyimpan sesi, dan antrean pekerjaan yang disetel benar.
Jasa managed Redis mencakup pemasangan aman, kebijakan eviction, penyetelan memori, Sentinel untuk ketersediaan, dan integrasi sebagai cache, penyimpan sesi, atau antrean pekerjaan. Kami bantu menetapkan peran Redis agar risiko kehilangan data dan kehabisan memori dapat dikendalikan.
Redis dipasang orang biasanya untuk satu alasan — mempercepat situs — lalu perannya melebar sendiri. Ia menyimpan sesi, menampung antrean pekerjaan, menjadi penghitung, lalu suatu hari data yang sebenarnya penting ada di dalamnya tanpa pernah diputuskan begitu.
Di titik itu satu pertanyaan menjadi mendesak dan sering belum terjawab: kalau Redis mati, apa yang hilang?
Redis cache WordPress dan aplikasi PHP lain
Pemakaian Redis cache WordPress bekerja pada lapisan object cache — hasil kueri basis data disimpan di memori, sehingga pemuatan halaman berikutnya tidak mengulang kueri yang sama. Untuk situs dengan banyak plugin, selisihnya besar karena satu pemuatan halaman bisa menghasilkan ratusan kueri.
Bedanya dengan page cache penting dipahami: page cache menyimpan halaman jadi dan tidak menolong pengguna yang sudah masuk. Object cache tetap bekerja untuk halaman yang dipersonalisasi, dan itu justru yang paling berat — dasbor admin, keranjang WooCommerce, halaman akun.
Keduanya sebaiknya dipakai bersama. Untuk aplikasi Laravel atau framework lain, prinsipnya sama; yang berbeda hanya cara menyambungkannya.
Eviction policy Redis: menentukan apa yang boleh hilang
Penentuan eviction policy Redis adalah keputusan yang paling sering dilewatkan, padahal ia menentukan perilaku ketika memori penuh. Pengaturan bawaan `noeviction` membuat Redis menolak penulisan baru — untuk cache, itu berarti aplikasi mulai melempar error alih-alih sekadar melambat.
Untuk pemakaian sebagai cache murni, `allkeys-lru` adalah pilihan yang wajar: kunci yang paling lama tidak diakses dibuang lebih dulu. Untuk instance yang mencampur data cache dan data yang tidak boleh hilang, `volatile-lru` membatasi pembuangan hanya pada kunci yang punya masa berlaku.
Yang kami sarankan lebih dulu justru pemisahan: satu instance untuk cache dengan eviction agresif, satu lagi untuk sesi dan antrean dengan persistensi aktif. Mencampur keduanya berarti tidak ada satu kebijakan pun yang benar.
Redis sebagai session store dan risikonya
Memakai Redis sebagai session store lebih cepat daripada menyimpan sesi di disk atau basis data, dan ia jadi keharusan ketika aplikasi berjalan di beberapa server di belakang load balancer — sesi harus bisa dibaca dari server mana pun.
Konsekuensinya: Redis mati berarti semua pengguna keluar dari akunnya. Untuk situs berita itu gangguan kecil; untuk aplikasi yang penggunanya sedang mengisi formulir panjang, itu masalah nyata.
Karena itu instance yang menyimpan sesi kami beri persistensi — AOF dengan `appendfsync everysec` sebagai titik tengah antara keamanan data dan performa — dan biasanya juga Sentinel supaya ada peralihan otomatis.
Redis Sentinel untuk peralihan otomatis
Redis Sentinel memantau instance utama dan mengangkat replika menjadi utama ketika yang lama tidak merespons. Jumlah Sentinel-nya minimal tiga supaya keputusan peralihan punya kuorum dan tidak terjadi karena satu pemantau yang jaringannya bermasalah.
Yang perlu diperhatikan: aplikasi harus menyambung lewat Sentinel, bukan langsung ke alamat instance utama. Kalau alamatnya ditulis langsung di konfigurasi aplikasi, peralihan tetap terjadi tetapi aplikasi tidak mengikutinya — jadi seluruh mekanismenya tidak berguna.
Untuk skala yang lebih besar, Redis Cluster membagi data ke beberapa node. Ia menambah kerumitan dan beberapa pembatasan pada perintah multi-kunci, jadi kami sarankan hanya bila data memang tidak lagi masuk ke memori satu server.
Tuning memori Redis dan pengamanannya
Pekerjaan tuning memori Redis dimulai dari `maxmemory`. Membiarkannya tanpa batas berarti Redis akan tumbuh sampai sistem operasi mulai memakai swap atau membunuh prosesnya — dan keduanya jauh lebih buruk daripada eviction yang terkendali.
Angka yang kami pakai biasanya menyisakan ruang untuk sistem dan untuk lonjakan sesaat. Fragmentasi memori juga perlu diawasi lewat `INFO memory`; rasio yang tinggi menandakan perlu penyesuaian atau restart terjadwal.
Sisi keamanan sering terlupakan. Redis bawaan tidak meminta kata sandi dan, kalau terikat ke semua antarmuka, siapa pun yang bisa menjangkau port 6379 bisa membaca dan menghapus seluruh isinya. Yang kami terapkan: mengikat hanya ke alamat lokal atau jaringan privat, mengaktifkan kata sandi yang kuat, dan menonaktifkan perintah berbahaya seperti `FLUSHALL` dan `CONFIG`.
Memantau Redis: angka yang perlu dibaca
Redis jarang mati mendadak; ia lebih sering menurun perlahan sampai ada yang menyadari cache-nya tidak bekerja. Karena itu beberapa angka kami pantau terus-menerus.
Hit rate adalah yang pertama — perbandingan `keyspace_hits` terhadap `keyspace_misses`. Angka yang turun berarti data yang dibutuhkan tidak lagi tersimpan, biasanya karena memori terlalu kecil atau masa berlaku terlalu pendek. Berikutnya jumlah kunci yang dibuang karena eviction; kenaikan tajam pada angka ini adalah peringatan dini sebelum ada keluhan.
Yang ketiga, perintah lambat lewat `SLOWLOG`. Redis bekerja satu utas, jadi satu perintah yang memakan waktu lama menahan seluruh permintaan lain — dan biasanya penyebabnya `KEYS` yang dipakai di kode produksi. Metrik ini masuk ke dasbor pemantauan yang sama dengan metrik server lainnya; perangkat yang kami pakai tercantum di halaman teknologi.
Lainnya seputar Managed Database
Pertanyaan seputar Managed Redis
Redis atau Memcached?
Untuk cache sederhana keduanya setara. Redis unggul bila Anda butuh struktur data selain string, persistensi, atau mekanisme antrean — dan karena kebutuhan itu hampir selalu muncul kelak, kami biasanya menyarankan Redis sejak awal.
Perlu server terpisah untuk Redis?
Untuk satu aplikasi, Redis di server yang sama menghilangkan latensi jaringan dan biasanya paling baik. Server terpisah menjadi perlu ketika ada beberapa server aplikasi yang harus berbagi cache atau sesi yang sama.
Berapa memori yang dibutuhkan?
Bergantung pada apa yang di-cache, jadi cara paling akurat adalah menjalankannya dengan batas tertentu lalu mengamati hit rate. Hit rate yang tinggi dengan memori belum penuh berarti ukurannya sudah cukup.
Apakah data di Redis ikut dicadangkan?
Bila persistensi aktif, berkas RDB atau AOF bisa dicadangkan seperti berkas lain. Untuk instance yang murni cache, mencadangkannya tidak ada gunanya — isinya bisa dibangun ulang dari sumber aslinya.
Apakah upgrade versi Redis berisiko?
Untuk instance yang murni cache, hampir tanpa risiko — isinya bisa dibangun ulang. Untuk yang menyimpan sesi atau antrean, perlu jendela terjadwal dan pemeriksaan kompatibilitas klien.
Aplikasi melambat dan basis data jadi tersangka?
Kirimkan gejalanya beserta jam kejadiannya. Kami mulai dari mengukur, bukan dari menaikkan spesifikasi.