Skip to content

Latest commit

 

History

History
69 lines (62 loc) · 3.47 KB

9.5. Databases - ElastiCache (Redis & Memcached).md

File metadata and controls

69 lines (62 loc) · 3.47 KB
Raw

ElastiCache

  • ElastiCache is managed Redis or Memcached
  • Key-value store
  • Caches are in-memory databases with really high performance, sub-millisecond latency
  • Leads to faster reads & stateless applications
  • Must provision an EC2 instance type e.g. cache.t2.micro & number of read replicas.
  • Scaling
    • Write Scaling using sharding
  • Availability
    • Multi AZ with Failover Capability
  • An alternative is DynamoDb with DAX.
  • Monitoring through CloudWatch
  • Backup / snapshot / point in time restore features
  • Caching patterns
    • Application queries ElastiCache, if not available, get from RDS and store in ElastiCache
      • Cache hit: Get data directly from ElastiCache
      • Cache miss: Data is not in the DB, application reads from DB and writes to the cache
    • Cache must have an invalidation strategy to make sure only the most current data is used in there.
      • Cache invalidation: whether or not the cache is out of date.
    • Patterns for ElastiCache
      • Lazy Loading: all the read data is cached, data can become stale in cache
      • Write Through: Adds or update data in the cache when written to a DB (no stale data)
      • Session Store: store temporary session data in a cache (using TTL features)
  • ❗ None of the caches support IAM authentication
    • IAM policies are only used for AWS API-level security, such as create a cache, delete a cache etc.
  • Managed and Scheduled maintenance with SNS notifications
    • Subnet group allows you to specify set of subnets in your VPC for your instances.
  • 💡 Use case: Key/Value store, Frequent reads, less writes, cache results for DB queries (writethrough pattern), store session data for websites, cannot use SQL.

Memcached

  • In-memory object store
  • ❗ Cache doesn't survive reboots
  • Memcached support SASL authentication
  • Use cases
    • Quick retrieval of objects from memory
    • Cache often accessed objects

Redis

  • Most popular in-memory key-value store
  • Super low latency (sub ms)
  • Read Scaling using Read Replicas
    • Redis Clustering = Collection of one or more cache nodes
    • One of the nodes is a read/write primary node.
    • All other nodes in the shard are read-only replicas.
  • Cache survive reboots by default (persistent)
  • 💡 Use-cases: User sessions, Leaderboard (for gaming) with Redis Sorted Sets, Distributed states, Relieve pressure on databases (such as RDS), messages with Redis Pub/Sub, recommendation data with Redis Hashes
  • Availability: Multi-AZ with Auto-Failover and enhanced robustness
  • Cluster mode -> more persistence and robustness with specified number of read replicas.
    • Sharding through clustering
  • Security
    • Network: Deploy into subnet, set preferred availability zone(s), security group
    • Encryption at rest (KMS) and in-transit (using SSL)
    • Redis support Redis AUTH (username / password with --auth-token parameter)
  • Import data to cluster through seeding RDB file from S3
  • Automatic back-up
  • Persistence by snapshotting your Redis data using the Backup and Restore feature

Redis vs Memcached

Memcached Redis
Persistence Not supported Supported through snapshots
Authentication SASL Redis Auth
Sub-millisecond latency Yes Yes
Clustering Each node => Different partition 1 master and read replicas of it
Unique features Multi-threading Snapshots, replication, transactions, pub/sub, lua scripting, geospatial support