Section 8. RDS+Aurora+ElasticCache

RDS

RDS는 'Relational Database Service'의 약자로 SQL을 쿼리 언어로 사용하는 데이터베이스에 대한 관리형 데이터베이스 서비스를 의미한다.

데이터베이스 엔진 유형
1. Postgres
2. MySQL
3. MariaDB
4. Oracle
5. MSSQL
6. IBM DB2
7. Aurora

 

RDS를 굳이 사용하는 이유?

• 물론 EC2 인스턴스 위에 자체 데이터베이스 서비스를 구축할 수는 있다.
• 하지만 그럼에도 RDS를 사용하는 이유는 관리형 서비스이기 때문에 단순한 데이터베이스 제공 외에도 다양한 서비스를 제공하기 때문이다!

RDS 특징

1. 자동화되어 있는 프로비저닝과 OS 패치
2. 지속적인 백업과 특정 타임스탬프로 복원이 가능
3. 데이터베이스 성능 확인 가능
4. 읽기 복제본 소지 가능
5. 다중 가용 영역 설정 가능
6. 인스턴스 유형을 수직적으로 확장하고 읽기 전용 복제본을 추가하여 수평적으로 확장할 수 있다.

• 우리가 가지지 못한 것은 RDS 인스턴스에 SSH를 적용할 수 없다는 것이다.

RDS - Storage Auto Scaling

• RDS 데이터베이스 인스턴스가 역동적으로 스토리지를 늘릴 수 있는 기능이다.
• 이는 자동으로 수행되며 데이터베이스를 중단할 필요도 없다!
• 이를 위해서는 최대 저장 임계값을 설정해야 한다.
• 자동적으로 스토리지가 수정되게 하기 위해서는 다음과 같은 조건이 있으면 된다:
  • 할당된 스토리지의 10% 미만이 남을 때
  • 적은 용량의 유지가 최소 5분 지속되었을 때
  • 마지막 수정 일시에서 6시간이 지났을 때

---

RDS Read Replicas for read scalability

• 읽기 전용 복제본은 말 그대로 읽기를 스케일링한다.
• 과정은 다음과 같다.
  1. 읽기 전용 복제본은 동일한 가용 영역이나 리전을 걸쳐서 생성될 수 있다.
  2. 주 RDS와 두 읽기 전용 복제본 사이에 비동기식 복제가 발생한다. 비동기식은 읽기가 일관적으로 유지됨을 의미한다.
  3. 이때 읽기 전용 데이터베이스는 데이터베이스로 승격시킬 수 있으며, 권한을 획득하면 복제 메커니즘에서 벗어나고 자체적 생애 주기를 갖는다.

주의!

• 읽기 전용 복제본을 사용할 때는 SELECT문만 사용해야 하며 데이터 변경을 야기하는 insert, update, delete는 사용해서는 안된다. 

Network Cost

• 데이터는 다른 가용 영역으로 이동할 때 네트워크 비용이 발생한다.
• 하지만 만일 읽기 전용 복제본이 동일한 리전에 있을 때는 비용이 발생하지 않는다.
  • 예시로 같은 지역 내 다른 가용 영역에 읽기 전용 복제본을 만든다면 이는 비동기식 복제로 RDS 가 관리형 서비스이기 때문에 비용이 발생하지 않는다.
  • 만일 다른 지역으로의 복제가 필요한 경우에 여러 리전을 넘나들어야 하기 때문에 네트워크에 대한 비용이 발생한다.

Multi AZ(Disaster Recovery)

• 하나의 마스터 RDS 데이터베이스가 있을 때, 스탠바이 데이터베이스를 동기식으로 복제한다.
• 해당 스탠바이 데이터베이스는 하나의 DNS 이름을 갖고 마스터에 문제가 생기더라도 자동으로 스탠바이에 장애 조치가 수행된다.
• 전체 AZ 또는 네트워크가 손실될 때 대비하는 장애 조치이자 마스터 데이터베이스의 인스턴스나 스토리지에 장애가 발생할 때 새로운 마스터가 되기 위한 방안이다.
• 읽기 전용 복제본도 장애 조치를 위한 Multi AZ로 설정할 수 있다!!

시험에서는 Single-AZ가 Multi-AZ로 변환이 가능한지 물을 수 있다.
이 작업에는 다운타임이 없음을 명확히 해야한다. 즉, 단일에서 다중으로 전환 시 데이터베이스를 중단할 필요가 없는 것이다.

데이터베이스 수정을 클릭하고 다중 AZ 기능을 활성화시키기만 하면 된다.
이를 통해 RDS 데이터베이스 인스턴스는 마스터를 갖고 동기식 복제본인 스탠바이 데이터베이스를 확보한다!

 

---

Amazon Aurora

Aurora란?

1. AWS 독점 기술로 Postgres와 MySQL과 호환되도록 만들어졌다.
2. RDS에서 MySQL보다 5배나 뛰어난 성능과 Postgres보다 3배의 성능을 가지고 있다.
3. 용량은 10GB~128TB까지 확장이 가능하다! 이 용량은 시간이 흐르면서 점차 늘어난다.
4. 읽기 전용 복제본의 경우, 15개의 복제본까지 가질 수가 있다.(MySQL은 5개)
5. Multi-AZ보다 장애 조치가 빨리 일어난다.

 

Aurora High Availability and Read Scaling

• Aurora는 3개의 AZ에 걸쳐 무엇이든 쓸때마다 데이터 사본을 6개나 갖는 특징이 있다.
  • 그 중 쓰기에는 4개 사본만 필요하다.
  • 읽기에는 3개 사본만 필요하다.
  • 상태가 좋지 않을 경우 P2P 복제를 실시한다.
• Aurora는 RDS의 Multi-AZ와 같다.
  • 읽기 담당 인스턴스가 단 하나이고, 쓰기를 담당하는 것은 마스터이다.
  • 마스터가 작동하지 않으면 평균 30초 이내에 장애 조치가 일어난다.
  • 만일 마스터에 장애가 발생하면 읽기 전용 복제본이 마스터가 된다.
  • 이 읽기 전용 복제본의 장점은 리전 간 복제를 지원한다는 것이다.

---

RDS & Aurora Security

• RDS와 Aurora 데이터베이스에서 저장된 데이터를 암호화할 수 있다.
  • 데이터가 볼륨에서 암호화 됨을 의미.
  • 이 작업은 데이터베이스를 처음 실행하는 동안 실행 시간에 정의되어야 한다.
• 만일 마스터가 암호화되지 않았다면, 읽기 복제본도 암호화 될 수 없다.
  • 암호화하기 위해서는 데이터베이스 스냅샷을 가져온 다음, 해당 데이터베이스 스냅샷을 암호화 된 데이터베이스로 복원하면 된다.
• IAM Authentication | IAM Role을 사용하여 데이터베이스에 연결할 수 있다!
  • EC2 Instance에 IAM 역할이 있는 경우, IAM 역할을 직접 사용하여 데이터베이스에 인증할 수 있다.
• Security Groups | 보안그룹을 사용하여 데이터베이스에 대한 네트워크 액세스를 제어할 수 있다.
• RDS와 Aurora는 SSH를 가지고 있지 않다. 관리형 서비스이기 때문이다.

---

RDS Proxy

RDS 데이터베이스로 직접 액세스할 수 있다.

Q. 이때 프록시가 필요한 이유는?
A. 애플리케이션이 데이터베이스로 설정된 데이터베이스 연결을 풀링하고 공유할 수 있다.
    인스턴스가 아닌 프록시로 연결한다.
Q. 왜 그렇게 할까?
A. RDS 데이터베이스 인스턴스에 대한 연결이 많으면 프록시를 사용하면 데이터베이스 리소스에 대한 스트레스를 줄여서 데이터베이스 효율성을 증대시킬 수 있다. 또한 열린 열결과 데이터베이스 간의 시간 초과를 최소화하려고 한다.

 

RDS 프록시 특징

• RDS 프록시는 완전 서버리스 상태이고 자동 스케일링이므로 용량을 관리하지 않아도 된다.
  다중 AZ를 사용하기에 가용성도 높다.(장애 조치 시간 66% 효율)
• IAM 인증을 시행하여 RDS 데이터베이스 인스턴스에 연결할 수 있다.
  • 이를 통해 서비스에 안전하게 저장할 수 있다.
• 프록시는 공개적으로 액세스할 수 없다. 오직 VPC에서만 가능하다.
  • 인터넷을 통해서는 보안이 강화된 RDS 프록시로 연결할 수 없다.

---

ElastiCache

ElasticCache는 캐시 기술인 관리형 Redis 또는 Memcached를 얻을 수 있도록 도와준다.

캐시란?
높은 성능과 짧은 대기 시간을 가진 인 메모리 데이터베이스
읽기 집약적인 워크로드에 대한 데이터베이스의 부하를 줄일 수 있도록 도움을 준다.
쿼리의 결과를 검색하는데 사용

 

• RDS와 같은 혜택이 주어지기 때문에, AWS는 동일한 운영 체제와 패칭, 최적화, 설정 구성, 모니터링, 장애 복구, 백업을 처리한다.
• Amazon ElastiCache를 사용하는 경우, 과도한 애플리케이션 코드 변경을 다루어야 한다..
  • 데이터베이스를 쿼리하기 전후에 애플리케이션을 변경하여 캐시를 쿼리해야 한다.

ElastiCache Solution Architecture - DB Cache

1. 애플리케이션이 ElastiCache를 쿼리하여 쿼리 오류가 발생했는지, 그리고 이미 발생하여 ElastiCache에 캐시 히트가 발생했는지 확인한다.
2. 캐시 누락이 발생하면, 데이터베이스에서 데이터를 가져와야 한다.
3. 동일한 쿼리가 수행되는 다른 애플리케이션이나 인스턴스의 경우, 데이터를 쿼리에 다시 쓸 수 있게 되는데 다음에 수행되는 동일한 쿼리가 캐시 적중으로 이어지게 RDS 데이터베이스의 부하를 줄이는 데 유용하다.

ElastiCache Solution Architecture - User Session Store

1. 사용자 세션을 저장하여 애플리케이션을 무상태로 만드는 아키텍쳐
2. 애플리케이션은 ElastiCache에 세션 데이터를 저장한다.
3. 사용자가 애플리케이션의 또 다른 인스턴스로 리디렉션되면, 애플리케이션은 ElastiCache에서 직접 세션의 세션 캐시를 검색한다. 이때 확인된 결과로 다시 로그인을 안해도 된다.

ElastiCache - Redis vs. Memcached

1. Redis
   • 자동 장애 조치를 가진 Multi-AZ가 있다.
   • 읽기 전용 복제본이 있어서 쓰기를 스케일링하고 고가용성을 보유할 수 있다.
   • AOF 지속성을 사용하는 데이터 내구성이 있고 백업과 복구 기능도 탑재하고 있다.
   • 즉, Redis의 핵심은 데이터 내구성과 캐시 기능이다!
2. Memcached
   • 데이터 파티셔닝에 다중 노드를 사용한다.
   • 고가용성이 없기에 복제도 일어나지 않는다.
   • 지속적인 캐시가 아니며 백업과 복구 기능이 없다.
   • 다중 스레드 아키텍쳐로 샤딩을 통해 Memcached에서 작동하는 여러 인스턴스를 보유하고 있다.
   • 즉, 분산된 순수 캐시이다. 손실된 데이터에 대한 책임을 감당해야함.

• 용어정리
  1. 노드 | ElastiCache를 배포할 때의 최소 구성 요소
  2. 샤드 | 노드의 그룹

---

Caching Implementation Considerations

전략을 세우기 전 물어볼 질문

Q. 데이터를 캐싱하기에 안전한가?
A. 데이터가 최신이 아닐 수도 있지만 일관성을 유지할 것이다.

Q. 캐싱이 데이터에 효과적인가?
A. 패턴일 경우 데이터의 변화가 느리고, 자주 필요한 키가 적으면 캐싱이 괜찮다.
그러나 안티 패턴일 경우 데이터가 빠르게 변화하고, 모든 데이터셋의 키가 필요한 경우에 효과적이지 않을 것이다.

Q. 데이터가 캐싱에 맞게 설계되었는가?
A. 만일 키 값이 있고, 집계 결과를 저장하고 싶을 때 캐싱이 좋다. 쿼리 하기에 올바른 방식인지 확인해야 한다.

Q. 어떤 캐싱 설계 패턴이 적합한가?
이 부분에 대해 자세히 알아보자!

 

1. Lazy Loading / Cache-Aside / Lazy Population

 

Ex. DB Cache

1. 장점
   1. 요청한 데이터만 캐싱된다.
   2. 노드 실패가 발생해도 치명적이지 않다. 캐시를 다시 한 번 예열해야 하므로 대기 시간이 늘어난다.
2. 단점
   1. 캐시 미스일 경우 애플리케이션에서 엘라스틱 캐시로 3번의 네트워크 호출이 일어난다.
      1. 애플리케이션에서 RDS로 한 번, 데이터베이스를 읽으면서 한 번, 캐시를 쓰면서 한 번이다.
   2. 오래된 데이터가 캐시에 남아 있을 수 있다.

2. Write Through - Add or Update cache when database is updated

- 데이터베이스가 업데이트 될 때 캐시를 추가하거나 업데이트 하는 것을 의미

 

Ex. DB Cache

상황. 애플리케이션이 RDS 데이터베이스를 수정할 때 먼저 캐시에 쓸 것이다. 이때 write through라 부르는 이유는 엘라스틱 캐시를 통해 RDS에 쓰기 때문이다.

1. 장점
   1. 캐시 데이터는 절대 오래될 수 없다. RDS가 바뀔 때마다 캐시도 자동으로 바뀌게 된다.
   2. 쓰기 페널티를 갖게 된다. 데이터베이스에 쓸 때 두 번의 호출을 요구한다.
      1. 데이터베이스로 한 번, 캐시로 한 번
2. 단점
   1. 데이터가 업데이트되거나 추가될 때까지 데이터 누락이 발생할 수 있다. RDS에 쓰기 전까지 캐시에는 데이터가 들어가지 않기 때문이다!
   2. 캐시 이탈률 | RDS에 많은 데이터를 추가할 경우 절대 읽히지 않을 가능성을 의미한다.

3. Cache Evictions and Time-to-live (TTL)

- 캐시에 제한된 데이터가 있을 때 그 데이터를 제거하기 위해 사용한다.

- LRU나 TTL로 설정하여 최근 사용하지 않은 데이터를 캐시에서 삭제한다.

시험에 나오는 것은?
캐시 어사이드나 레이지 로딩 구조를 읽는 법이 나올 수 있다..!