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)
