Redis vs Memcached: Memilih Mesin yang Tepat

Amazon ElastiCache adalah layanan caching dalam memori yang dikelola sepenuhnya, sehingga Anda dapat dengan mudah menerapkan, mengelola, dan menskalakan penyimpanan data dalam memori sumber terbuka yang populer di cloud. Layanan ini mendukung dua Engine: Redis dan Memcached. Dengan menyajikan data yang sering diminta dari memori, bukan dari basis data, ElastiCache dapat mengurangi beban basis data secara drastis dan memangkas latensi respons dari milidetik menjadi mikrodetik. Memilih antara Redis dan Memcached merupakan pertanyaan umum dalam ujian SAA-C03.

Memcached adalah penyimpanan key-value terdistribusi dalam memori yang berfokus pada kesederhanaan dan skalabilitas horizontal. Karakteristik utamanya: multi-threaded (dapat menggunakan semua inti CPU pada satu Node), penyimpanan key-value sederhana (hanya String, tanpa struktur data kompleks), tanpa persistensi (data hilang saat Node dimulai ulang), tanpa replikasi (tidak ada standby atau replika), dan sharding horizontal melalui hashing konsisten di sisi klien. Memcached adalah pilihan yang tepat saat Anda memerlukan cache sederhana berskala besar dan tidak memerlukan persistensi, tipe data kompleks, atau ketersediaan tinggi.

Redis (Remote Dictionary Server) adalah penyimpanan struktur data dalam memori yang kaya fitur dan bersifat single-threaded (per instance), yang mendukung String, Hash, daftar, set, set terurut, bitmap, HyperLogLogs, stream, dan indeks geospasial. Keunggulan utamanya dibandingkan Memcached: persistensi opsional (snapshot AOF dan RDB), replikasi (replika baca dan pengalihan otomatis saat gagal), pesan pub/sub, skrip Lua, transaksi (MULTI/EXEC), dan Mode cluster untuk sharding horizontal. Redis adalah pilihan yang tepat untuk sebagian besar skenario caching di dunia nyata.

Redis mendukung dua mekanisme persistensi: RDB (Redis Database) — snapshot pada titik waktu tertentu yang disimpan ke disk secara berkala dengan interval yang dapat dikonfigurasi (dimulai ulang dengan cepat, tetapi data di antara snapshot dapat hilang). AOF (Append-Only File) — mencatat setiap operasi penulisan; saat dimulai ulang, Redis memutar ulang catatan tersebut untuk membangun kembali status (daya tahan data dengan konsekuensi ukuran file yang lebih besar dan proses mulai ulang yang lebih lambat). Di ElastiCache, Anda dapat mengaktifkan AOF untuk mempertahankan data saat Node dimulai ulang. Hal ini penting ketika ElastiCache digunakan bukan hanya sebagai cache, tetapi juga sebagai penyimpanan data utama (misalnya untuk data sesi).

Redis mendukung kelompok replikasi dengan satu Node utama yang menangani semua penulisan dan hingga 5 replika baca yang menangani pembacaan. Dengan Multi-AZ dan pengalihan otomatis saat gagal diaktifkan, ElastiCache secara otomatis menjadikan replika baca sebagai Node utama saat Node utama gagal — biasanya proses pengalihan selesai dalam waktu kurang dari 60 detik. Hal ini memberikan ketersediaan tinggi bagi aplikasi berbasis Redis, yang tidak dapat ditandingi oleh Memcached (Memcached tidak memiliki replikasi). Untuk aplikasi Production yang memerlukan caching dengan HA, selalu gunakan Redis dengan pengalihan otomatis saat gagal.

Set terurut adalah salah satu struktur data Redis yang paling kuat. Setiap anggota memiliki skor pecahan terkait, dan anggota selalu dipertahankan dalam urutan terurut. Hal ini menjadikan set terurut ideal untuk Leaderboard (diurutkan berdasarkan skor), antrean prioritas (memproses pekerjaan dengan prioritas tertinggi terlebih dahulu), dan pembatasan laju (jendela geser dengan stempel waktu sebagai skor). Operasi ZADD, ZRANGE, ZREVRANGE, ZRANK, dan ZRANGEBYSCORE semuanya memiliki kompleksitas O(log n) — sangat efisien bahkan untuk jutaan entri.

pub/sub Redis memungkinkan penerbit menyiarkan pesan ke saluran tanpa mengetahui siapa yang berlangganan. Pelanggan menerima semua pesan yang diterbitkan ke saluran yang mereka ikuti, secara waktu nyata. Pesan pub/sub tidak dipersistenkan — jika pelanggan sedang luring, pesan tersebut akan terlewat. Untuk pesan persisten dengan pengiriman terjamin, gunakan Redis Streams (struktur data yang lebih tangguh dan ditambahkan pada Redis 5) atau layanan pesan khusus seperti SQS atau SNS. Dalam ujian SAA-C03, pub/sub Redis merupakan pilihan untuk notifikasi waktu nyata yang ringan antar-layanan.

Gunakan kerangka berikut untuk memilih dalam ujian SAA-C03: Pilih Memcached saat Anda memerlukan: cache sederhana tanpa persyaratan HA, performa multi-threaded, dan penskalaan horizontal dengan menambahkan Node (cache murni). Pilih Redis saat Anda memerlukan: persistensi (penyimpanan sesi), replikasi dan pengalihan saat gagal (HA), tipe data kompleks (set terurut untuk Leaderboard, set, daftar), pub/sub, transaksi Lua, serta Cluster Mode untuk penskalaan horizontal multi-shard. Jika pertanyaan ujian menyebutkan fitur apa pun di luar caching key-value sederhana, Redis hampir selalu menjadi jawabannya.

ElastiCache menyediakan beberapa keluarga jenis Node: r7g (Graviton 3, dioptimalkan untuk memori — rasio harga/performa terbaik, direkomendasikan untuk sebagian besar caching), m7g (komputasi dan memori seimbang), dan t4g (dapat melonjak, berbiaya rendah untuk pengembangan/pengujian). Ukuran Node berkisar dari cache.t4g.micro (500 MB) hingga cache.r7g.16xlarge (425 GB). Untuk Production, pilih ukuran Node yang dapat menyimpan dataset di memori dengan ruang cadangan 20–25%. Kehabisan memori menyebabkan evictions (Memcached) atau error OOM (Redis).

ElastiCache diterapkan di dalam VPC Anda dengan security group yang mengendalikan akses — secara default tidak ada akses internet publik. Untuk Redis, aktifkan token AUTH (kata sandi yang harus diberikan klien) dan enkripsi saat transit (TLS) untuk koneksi, serta enkripsi saat tersimpan menggunakan KMS. Untuk Memcached, hanya TLS saat transit yang tersedia (tanpa enkripsi saat tersimpan atau AUTH). Saat bermigrasi dari Redis tidak terenkripsi ke Redis terenkripsi, tidak ada migrasi di tempat — Anda harus membuat cluster terenkripsi baru dan mengisinya terlebih dahulu.

Saat cache Redis atau Memcached penuh, kebijakan eviction menentukan key mana yang dihapus untuk menyediakan ruang. Kebijakan eviction Redis yang umum: noeviction (mengembalikan error OOM — baik jika cache adalah penyimpanan utama), allkeys-lru (menghapus key yang paling lama tidak digunakan di antara semua key — baik untuk cache umum), volatile-lru (LRU di antara key yang memiliki TTL — mempertahankan key yang tidak kedaluwarsa), allkeys-random (eviction acak), allkeys-lfu (yang paling jarang digunakan). Untuk kasus penggunaan caching umum, allkeys-lru atau allkeys-lfu direkomendasikan.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda mempelajari: Memcached sederhana, multi-threaded, dan tidak memiliki HA — paling cocok untuk penskalaan horizontal murni pada cache sederhana, Redis mendukung struktur data kompleks, persistensi, pub/sub, dan pengalihan saat gagal Multi-AZ — paling cocok untuk sebagian besar skenario caching Production, dan set terurut menjadikan Redis pilihan alami untuk Leaderboard dan antrean prioritas. Selanjutnya kita akan membahas Kelompok Replikasi Redis dan Mode Cluster untuk sharding horizontal.