여기 정리하는 내용들은 Udemy 강의를 통해 배운 내용들을 정리하였습니다.
출처 - Udemy AWS Certified Developer Associate 2022 - New!

Amazon Aurora

AWS에서 제공하며 RDS에서의 MySQL이나, Postgres보터 높은 성능을 보이는 서비스입니다.


Feature of Aurora

  • 자동적으로 64TB까지 storage가 늘어납니다.
  • Failover가 순간적으로 짧은 시간에 일어나기 때문에 High availability 합니다.
  • Shared storage Volume 이라고 Replication + Self Healing + Auto Expanding 의 기능을 제공할 수 있습니다.
  • master instance에서만 write이 가능합니다. (Single-master, 보편적) <> Multi-master를 사용하여 여러 instances에서 write을 할 수 있습니다.
  • Cross Region Replication 을 지원합니다.
  • 1 Aurora DB Cluster에 15개 까지 Aurora Read Replicas 만들 수 있습니다.


Aurora Security

RDS 와 같은 엔진을 사용하기 때문에 RDS 의 Security 와 유사합니다.

  • KMS를 사용한 encryption at rest
    • Automated backups 와 snapshots 와 replicas 모두 encrypted 됩니다.
  • SSL을 사용한 encryption in flight.
  • IAM token을 사용한 authenticate
  • Security Group을 사용한 instance 보호
  • SSH 불가능


Amazon ElastiCache

Cache = in-memory databases 로서 high performance, low latency를 자랑합니다.
Heavy application code changes를 해야할 경우가 있을 것입니다.


Architecture - DB Cache

query 할때, Cache에 data가 있다면 Cache hit을 통해 application으로 보내주고
data가 없다면 RDS DB에서 읽어오고 cache에 write 해둡니다.
이 과정에서 most current data in used 가 가능하도록 알고리즘을 이용합니다.(invalidation strategy라고도 합니다.)


Architecture - User Session Store

User가 한 application에 로그인 할때 Amazon ElastiCache를 통해서 session data를 기록해두고
다른 application을 들어가면 그 session data를 통해 이미 로그인 돼있는 상태가 됩니다.


Redis vs Memcached

Multi AZ vs Multi node
Read Replicas vs No replicas
Data durability vs No persistent
backup and restore vs No backup and restore
similar architecture with RDS vs Multi-threaded architecture


Strategy

Caching을 사용하기 위해서 항상 확인해야 하는 것이 있습니다.

  1. cache data 하는 것이 안전한가?
  2. 해당 data에 효과적인가? (slowly change 하는 data에 적절합니다.)
  3. caching 하기에 적절한 data structure 인가?
  4. 어떤 caching desgin pattern이 가장 적절한가?


Lazy Loading == Cache-Aside == Lazy Population

application에서 data를 요청하면 Amazon ElastiCache에서 Cache hit
Cache miss 일 경우, Read from DB & write to cache
위 경우,
오직 요청된 data만 cache에 기록됩니다.
Node failures 해도 치명적이지 않습니다.
대신 Cache miss의 경우 latency를 통해 bad user experience가 될 수 있습니다.
Stale data라고 db에서는 update된 data가 cache에서는 update 안된 case 가 존재할 수 있습니다.


Write Through

Add 나 Update 가 일어날 때 사용되는 pattern 입니다.

Cache hit
application에서 write 할 떄 DB로 write 후, cache에 write 합니다.
위 경우,
data가 Stale하지 않습니다.
대신 Cache miss 일 경우 Lazy Loading 까지 일어납니다.


Cache Evictions and Time-to-live(TTL)

Cache라는 자원은 한정되어 있기 때문에 Cache Evictions 가 3가지 방법으로 진행됩니다.

  1. cache에서 명시적으로 item 삭제
  2. List recently Used(LRU) 방식으로 item 삭제
  3. TIme-to-live(지정된 시간만큼만 cache 사용 후) 삭제
    너무 자주 data eviction이 일어난다면, cache size 를 scale up or out 을 고려해보아야합니다.

    Wirte-through 를 사용하는 경우가 아니면 TTL을 사용하는 것이 대부분 나쁜 방법이 아니다.

Redis Cluster Modes

  1. Cluster Mode Disabled
    • One primary node, up to 5 replicas
    • Asynchronous Replication
    • The primary node 가 read/write 합니다.
    • 다른 nodes는 read only 입니다.
    • In one shard (모든 노드를 포함하고 있는 그룹이라고 생각하면 되겠습니다.), 모든 노드에 모든 데이터가 똑같이 있습니다.
    • Multi-AZ 가능 by default for failover
    • scale read performance 에 좋습니다.
  2. Cluster Mode Enabled
    • data가 여러 shard에 분배되어 있습니다. (scale write에 좋습니다.)
    • 각 shard는 primary node를 가지며 5개 까지 replica nodes를 만들 수 있습니다.
    • Multi-AZ 가능
    • up to 500 nodes per cluster
      • 500 shards with 1 master
      • 250 shards with 1 master & 1 replica
      • 83 shards with 1 master & 5 replicas