Exploring AWS !!
Day 42:
Amazon ElastiCache
Overview:
- same way as RDS is used to get managed Relational Database, ElastiCache is to get managed Redis or Memcached.
- Cache are in-memory database with really high performance low latency.
- Helps reduce load off of database for read intensive workloads.
- helps make your application stateless.
- AWS takes care of OS maintenance/patching, optimization. setup, configuration, monitoring, failure recovery and backups.
- Using ElastiCache involves heavy application code changes.
ElastiCache Solution Architecture — Database Cluster:
- Application queries ElastiCache, if not available get from RDS and store in ElastiCache.
- Helps relieve load in RDS.
- Cache must’ve an invalidation strategy to make sure only most current data is used there.
ElastiCache Solution Architecture — User Session Store:
- User logs into any of the application.
- The application writes session data into ElastiCache
- The user hits another instance of our application.
- The instance retrieves the data and user already logged in
Redis v/s Memcached:
Redis:
Multi-AZ with auto failover
Read replicas to scale reads and have high availability.
Data durability using AOF persistence.
Backup and restore.
Memcached:
Multi node for partitioning of data (sharding)
No high availability
Non persistent
No backups and restore
Multi-threaded architecture
ElastiCache for Solutions Architect — Cache Security
All caches in ElastiCache:
- Does not support IAM Authentication
- IAM Policies on ElastiCache are only used for AWS API level security Redis AUTH:
- You can set password/token where you created Redis cluster
- This is extra level section for cache Memcached:
- Supports SAS2-based authentication (advanced)
Patterns for ElastiCache:
- Lazy loading: all read data is cached, data can become stale in cache
- Write Through: add or update data in cache when written to database (no stale data)
- Session store: store temporary session data in cache (using TTL feature)
- Quote: there are only 2 hard things in computer science. Cache invalidation and naming things.
Redis Use Case:
Gaming leaderboards are computationally complex.
Redis sorted guarantee both uniqueness and element ordering.
Each time a new element is added, it is ranked in real time, then added in correct order.
**
**
FTP: 21
SSH: 22
SFTP: 22
HTTP: 80
HTTPS: 443
PostgreSQL: 5432
MySQL: 3306
Oracle RDS: 1521
MSSQL Server: 1433
MariaDB: 3306
Aurora: (5432 if PostgreSQL compatible, 3306 if MySQL compatible)