[AWS] aws 강의 섹션 8 (Aurora RDS, RDS Proxy, Amazon ElastiCache, MemoryDB)

RDS - 관계형 데이터베이스

 

AWS 에서 지원하는 RDS 종류

1. Postgres
2. MYSQL
3. MariaDB
4. Oracle
5. Microsoft SQL Server
6. IBM DB2
7. Aurora 

EC2 인스턴스 위에 자체 데이터베이스 서비스를 구축하지 않는 이유는?

RDS는 AWS에서 관리하는 서비스이기 때문에 단순히 데이터베이스를 제공하는 것 외에도 많은 서비스를 제공한다.

• 데이터베이스 프로비저닝
• 운영체제 업데이트 자동화
• 지속적인 백업으로, 특정 타임스탬프로의 복원 가능
• 모니터링 대시보드를 통해 데이터베이스 성능을 볼 수도 있다.
• 읽기 성능을 향상시키기 위해 다중 가용 영역 (Multy - AZ)를 설정할 수 있다.
• 인스턴스를 늘려 수직적으로 확장도 가능하며
• 읽기 전용 복제본을 추가하여 수평적으로 확장도 가능하다.

EC2인스턴스 위에 자체 데이터 베이스를 구축할 경우 위의 모든 것들을 수동으로 설정해야 한다.

Read Replica

읽기 전용 인스턴스 (읽기 전용 복제본)

• 읽기 전용 복제본을 최대 5개 까지 생성할 수 있다.
• 이들은 동일한 가용영역(AZ) 또는 가용영역이나 리전에 걸쳐서 생성될 수 있다. (Cross AZ or Cross Region)
• 2개의 Read, 1개의 Master 가 있다고 가정하자.
  • 1개의 Master DB 와 2개의 Read DB 인스턴스 사이에 비동기식 복제가 이루어진다.
  • 비동기식 복제이기 때문에 지연시간에 따른 약간의 데이터 불일치가 발생할 수 있다. 
• Read DB (Replica) 를 자체 DB (master) 로도 승격할 수 있다.

Read Replica 사용사례

언제 Read Replica 를 사용하게 될까?

• 평균적인 트래픽이 발생하고있는 생산 DB 가 있다고 가정한다.
• 이때 새로운 팀이와서 나의 데이터를 기반으로 몇 가지 보고와 분석을 실시한다고 한다.
• 보고와 분석을 메인 RDS DB 에 연결하면 오버로드가 발생하고, 생산 애플리케이션의 속도가 느려진다.
• 이런 상황을 피하고자, 새로운 워크로드에 대한 읽기전용 복제본 (read replica) 를 생성한다.
• read replica 는 오직 SELECT (read) 만 요청을 하며, Insert, Create, Delete 의 작업은 하지않는다.

RDS Read Replioca - Network Cost

RDS 읽기전용 복제본과 관련된 네트워킹 비용을 살펴보자.

• AWS 에서는, 하나의 AZ 에서 다른 AZ 로 데이터가 이동할때에 비용이 발생한다.
• 하지만 예외가 존재하며, 이 예외는 관리형 서비스 (managed service) 에서 나타난다.
• RDS 읽기 전용 복제본은 관리형 서비스이다.
• Read Replica DB 가 다른 AZ 상이지만 동일 Region 에 있을 때는 비용이 발생하지 않는다.
  • ap-northest-2a 에 Master DB 가 있고, ap-northest-2b 에 Read DB 가 있다고 치면
    이는 비동기식 복제로 Read DB 의 복제 트래픽이 하나의 AZ 에서 다른 AZ 로 넘어가더라도
    RDS 는 관리형 서비스이기 때문에 해당 트래픽은 비용 없이 무료로 이동할 수 있습니다.
• 하지만, 서로 다른 Region에 복제본이 존재하는 경우에는 비용이 발생합니다.

RDS Multi AZ

RDS 다중 AZ 에 대해 알아보자.

다중 AZ 는 주로 재해 복구에 사용된다.

• 다중 AZ에는 스탠바이 RDS가 존재한다.
• 스탠바이 RDS는 마스터 RDS의 내용을 동기식으로 복제한다.
• 다중 AZ는 한 개의 DNS 네임만을 사용하며, 애플리케이션은 해당 DNS를 통해서만 접근할 수 있다.
• 재해 상황이 발생하거나 마스터 RDS에 장애가 발생했을 때 DNS 연결은 자동으로
  스탠바이 인스턴스로 변경되고, 스탠바이 RDS는 자동으로 마스터 DNS로 승격된다
• 이를 통해 재해 상황이 발생했더라도 자동으로 복구를 하고 상시로 서비스를 운영할 수 있다.

전체 AZ 또는 네트워크가 손실될 때를 대비한 장애 조치이자 Master DB 또는 Storage에 장애가 발생할 때
스탠바이 DB가 새로운 Master가 될 수 있도록 하는 것이다.

따로 수동으로 설정할 필요가 없다. 자동으로 데이터베이스에 연결이 시도되고 장애 조치가 필요하게 될 때에도
스탠바이가 마스터로 승격되는 과정이 자동으로 이루어지기 때문이다.

• 스탠바이 DB 는 오직 대기 목적 하나만 수행한다.
• 누구도 이를 Read/Write 할 수 없다.
• master DB 에 문제가 발생할 경우를 대비한 장애 조치일 뿐이다.
• 재해 복구를 대비해서 Read DB 를 다중AZ 로 설정가능하다.

단일 AZ에서 다중AZ 설정

 

단일 AZ에서 다중 AZ로 변경이 가능하다.

단순히 설정만 바꿔주면 내부적으로 알아서 다중 AZ로 변경이 된다.

 

1. RDS에서 스냅샷을 생성한다.
2. 스냅샷을 기반으로 다른 AZ에 복제본이 생성된다.
3. 생성된 이후 동기화 설정이 이뤄진다.
4. 마스터 DB의 모든 내용을 복제한 후 다중 AZ가 완료된다.

Amazon Aurora

오로라는 AWS의 독점 기술이다. 오픈 소스가 아니다.

• 오픈소스는 아니지만, postgre, mysql과 호환되도록 만들어졌다.
• 아우라 데이터베이스에는 호환 가능한 드라이버가 있는데,
  포스트 그레, 마이sql 데이터베이스에 드라이브를 연결하는 것처럼 드라이브가 동작한다.
• 클라우드 최적화가 되어 있다.
• 많은 최적화를 통해 RDS에서 MySQL보다 5배 뛰어난 성능과 postgres 보다 3배 뛰어난
  성능을 자랑한다. 

오로라 기능 요약

• 오로라의 스토리지는 자동으로 늘어난다. (10GB 단위로 최대 128TB)
• DB 또는 SysOps로서 디스크 모니터링에 신경 쓰지 않아도 된다. 
  • 자동 스토리지 확장, 다중 AZ 활용, 자동화된 복구 및 유지관리 등의 이유로 디스크 모니터링 부담이 적다.
• 읽기 전용 복제본의 경우, 15개의 복제본까지 가질 수 있다.
  • MySQL은 5개만 가능 
• 복제가 더 빠르게 설계되었다. 
• 장애 조치를 수행하는 경우, 즉각적으로 이루어지게 된다.
  MySQL의 다중 AZ 장애 조치보다 훨씬 더 빠르게 진행된다. 
• 기본적으로 클라우드 네이티브라서 고가용성을 얻을 수 있다.
• 오로라는 RDS보다 약 20% 더 많은 비용을 지불해야 하지만 효율은 훨씬 더 좋다.

오로라의 High Availability와 Read Scaling

오로라는 3개의 가용 영역에 6개의 복제본을 나누어 저장한다.

 

오로라는 저장 (쓰기) 작업을 진행할 때 6개의 복제본 중 4개만 성공적으로 쓰이면 동작한다.

즉, 6개 모두에 한 번에 쓰이지 않아도 4개 이상에 저장이 완료되면 성공적으로 저장한 것으로 간주한다.

 

데이터를 읽을 때는 6개의 사본 중 3개의 사본만 있으면 읽을 수 있다.

데이터가 여러 곳에 분산되어 있기 때문에 한 곳에 장애가 나도 다른 곳에서 데이터를 가져와 안정적으로
읽을 수 있다는 의미다. 

 

자가 복구 프로세스도 갖추고 있다.

데이터가 손상된다면, 백엔드에서 P2P 복제를 한다.

 

볼륨은 하나의 볼륨이 아닌 수백 개의 볼륨에 의지한다.

 

위의 모든 것은 우리가 관리하는게 아니다. AWS 에서 자동으로 관리된다. 

 

• 오로라 RDS는 다중 AZ와 같다.
• 쓰기를 담당하는 인스턴스는 한 개로, 마스터 인스턴스가 작동하지 않으면 평균 30초 이내에 
  장애 조치가 이뤄진다.
• 마스터 외에 최대 15개의 읽기 전용 복제본이 읽기 기능을 제공한다.
• 따라서 마스터에 장애 발생 시 읽기 전용 복제본이 마스터가 될 수 있다.
• RDS 작동 방식과는 꽤 다르지만, 기본적으로 1개의 마스터를 보유하고 있다는 사실을 알면된다.
• 이 읽기 전용 복제본의 장점은 리전 간 복제를 지원한다는 것이다.

간단 정리

• 한 개의 마스터 인스턴스와 다수의 사본을 가지고 있다.
• 스토리지는 복제된다.
  • 오로라의 데이터는 복제된 스토리지에 저장된다.
  • 각 데이터베이스의 데이터를 자동으로 복제하여 여러 가용영역에 분산 저장한다.
• 자가 복구와 자동 확장이 작은 블록단위로 일어난다.

오로라 심층 분석

오로라는 10GB에서 128TB로 자동 확장하는 공유 스토리지 볼륨을 보유하고 있다.

• 오직 마스터 인스턴스만이 스토리지에 데이터를 저장할 수 있다.
• 마스터는 변경되고 장애가 발생할 수 있기 때문에 오로라는 light endpoint 라는 것을 제공한다.
• light endpoint는 DNS name이며 항상 마스터를 가르키고 있다.
• 마스터에 장애가 발생해도 클라이언트는 여전히 light endpoint에 요청을 보낼 수 있다.
  • 해당 요청은 올바른 인스턴스에 자동으로 redirection된다.
• 1-15개의 읽기전용 복제본을 가질 수 있으며, 오토 스케일링을 설정해서 
  올바른 개수의 읽기 전용 복제본을 가질 수 있다.
  • 오토 스케일링을 갖고 있기 때문에 애플리케이션이 추적하기 어려운 사항이 몇 가지 있다.
    • 복제본은 어딨는지
    • URL은 어떻게 되는지
    • 복제본에 어떻게 연결해야 되는지 등등의 문제점이 발생한다.
  • 다음과 같은 문제점을 해결하기 위해 리더 엔드포인트라는 것이 존재한다.
  • 리더 엔드 포인트는 라이트 엔드 포인트와 동일한 기능을 갖는다.
    • 읽기 전용 복제본에 대한 로드 밸런싱을 지원하며,
      자동으로 연결을 시켜준다.
    • 클라이언트가 리더 엔드포인트에 연결할 때마다 읽기 전용 복제본 중 하나에 연결되는 것이다.

 

RDS & Aurora Security

• AWS의 RDS에서는 저장된 데이터를 암호화 할 수 있다.
  • 암호화를 위해 KMS를 사용하여 마스터와 복제본을 암호화 해야 한다.
  • 해당 작업은 RDS가 첫 시작할 때 정의되어야 한다.
  • 마스터 데이터베이스, 즉 주요 데이터베이스를 암호화하지 못한 경우,
    읽기 전용 복제본도 암호화 될 수 없다.
  • 또한 암호화 되지 않은 기존 데이터베이스를 암호화 하려면 
    데이터베이스 스냅샷을 가져온 다음, 해당 스냅샷을 기반으로 암호화된 데이터 베이스를 생성해야 한다.
• 데이터 전송 중 암호화
  • AWS RDS는 기본적으로 전송 중 암호화를 사용할 준비가 되어 있다.
  • 클라이언트는 AWS의 TLS 루트 인증서를 반드시 사용해야하는데, 이는 AWS에서 제공해준다.
• 데이터베이스 인증
  • 사용자 이름과 암호라는 전형적인 조합을 사용할 수 있다.
  • EC2에서 IAM Role을 사용하여 데이터베이스에 연결할 수도 있다.
• 보안 그룹을 통한 데이터베이스 네트워크 액세스 제어
  • 특정 포트나 IP들을 제어할 수 있다.
• RDS와 오로라는 SSH 액세스를 갖고 있지 않다.
  • AWS의 RDS Custom 서비스를 사용하는 경우를 제외하고
• 감사 로그
  • RDS와 오로라에서 만들어지는 쿼리와 데이터베이스에서 일어나는 일을 파악하기 위해선
    감사 로그를 활성화하면 된다.
  • 시간이 다소 지나면 로그가 사라지게 되는데 
    오랜 기간 보관하고 싶다면 AWS의 CloudWatch 로그 서비스를 이용하면 된다.

AWS RDS Proxy

• 데이터베이스만을 위한 프록시도 만들 수 있다.
• 데이터베이스에 연결하기 위해 프록시가 필요한 이유는 무엇일까?
  • 프록시를 사용하면 애플리케이션이 데이터베이스 연결을 풀링하고 공유할 수 있는데 
    모든 애플리케이션을 데이터베이스 인스턴스가 아닌 프록시에 연결한다. 
  • 그러면 프록시는 이 연결을 RDS 데이터베이스 인스턴스에 대한 더 적은 연결로 풀링한다.
    • 풀링을 줄임으로서 CPU, RAM 등 리소스에 대한 스트레스를 줄여 효율성을 높인다.
    • 또한 오픈 커넥션과 타임 아웃을 최소화 시킬 수 있다.
• RDS 프록시는 완전히 서버리스이며 
  오토 스케일링이므로 용량을 관리하지 않아도 된다.
• 다중 AZ를 사용하기 때문에 가용성도 높다.
  • RDS 데이터베이스에 장애가 발생 시 메인 인스턴스에서 대기 인스턴스로 이동하는데
    프록시가 있다면 장애 조치 시간이 최대 66%까지 줄어든다.

모든 애플리케이션을 주요 RDS 데이터베이스 인스턴스에 연결하여 장애 조치를 처리하는 대신

RDS 프록시에 연결하기만 하면 되는데, 

그러면 RDS 프로시는 데이터베이스 인스턴스에 대한 장애 조치를 직접 처리하여 장애 조치 시간을 감소시킨다. 

 

지원 종류

1. MYSQL
2. PostgreSQL
3. MariaDB
4. Aurora

• 애플리케이션 코드를 변경하지 않아도 된다.
  • 데이터베이스 인스턴스에 연결하는 대신 RDS 프록시에 연결하는 것으로 바꾸기만 하면 되기 때문이다.
• 보안 상으로도 이점이 존재하는데, 데이터베이스에 대한 IAM 인증을 강제한다.
  • IAM을 사용해야만 데이터베이스에 연결할 수 있는 것이다.
  • 해당 연결을 위한 자격 증명은 AWS Secrets Manager에서 안전하게 저장된다.
• 데이터베이스에 대한 인증을 진행하는 방법을 확인하려면 RDS 프록시를 떠올리면 된다. 
• 프록시는 결코 public으로 액세스 할 수 없다. 무조건 VPC를 통해서만 액세스 할 수 있다.
  • 인터넷을 통해선 RDS 프록시로 연결할 수 없다.

람다 함수와 프록시

100개 또는 1000개의 람다함수가 나타났다 사라지면서 데이터베이스에 대한 커넥션을 생성했다 끊는다.

해당 연결이 너무 많아지면 큰 문제가 발생하게 될 텐데 

 

이 경우 프록시를 사용하여 람다 함수의 연결을 풀링해야 한다. 

 

프록시는 람다함수의 연결을 더 적고 효울적인 방식으로 관리하여 문제를 해결한다. 

 

결론: RDS 프록시는 데이터베이스에서 연결을 최소화하고 풀링하기 위해 사용된다.

장애 조치 시간을 최소화 하면 해당 시간을 최대 66%까지 줄여준다.

또한 데이터베이스에 대한 IAM 인증을 시행하고, 자격 증명을 Secret Manager 서비스에 안전하게 보관한다.

 

Amazon ElastiCache

RDS가 관리된 관계형 데이터베이스를 갖는 것과 같은 방식으로

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

 

캐시란?

• 캐시란 굉장히 높은 성능과 짧은 대기 시간을 가진 인 메모리 데이터베이스이다.
• 캐시는 읽기 집약적인 워크로드에 대한 데이터베이스의 부하를 줄일 수 있도록 도와준다.
• 쿼리와 결과를 캐시하여 데이터베이스 접근을 줄일 수 있다.
• 애플리케이션 상태를 엘라스틱 캐시에 입력하여 애플리케이션을 무상태로 만드는데 도움을 준다.
• 패칭, 최적화, 설정 구성, 모니터링, 장애 복구, 백업을 지원 받는다.

캐시를 사용할 경우 애플리케이션의 코드를 많이 변경해야 한다.

사용자 세션을 저장하여 애플리케이션을 무상태로 만들기

• 사용자가 로그인을 하면 애플리케이션이 캐시에 세션 데이터를 저장한다.
• 사용자가 애플리케이션의 또 다른 인스턴스로 이동하면 애플리케이션은
  캐시에서 사용자의 세션 정보를 가져와 사용한다. 
  이를 통해 세션을 유지하여 사용자의 불필요한 로그인을 없앨 수 있다.

Redis vs Memcached

Redis

레디스의 경우 자동 장애 조치 기능을 가진 다중 AZ가 있으며,

읽기 전용 복제본이 있다.

 

AOF를 사용하여 데이터 내구성을 증가시키며, 백업과 복원 기능도 존재한다.

 

레디스의 핵심은 데이터 내구성과 캐시 기능이다.

 

set과 sorted set을 지원한다는 것도 장점이다. 

 

Memcached

데이터 파티셔닝에 다중 노드를 사용한다.

이를 샤딩이라고 하는데 고 가용성이 없으며 복제본도 없다.

 

지속적인 캐시가 아니며 백업과 복원 기능도 없다.

 

멀티 스레드 아키텍쳐 이므로 

샤딩을 통해 작동하는 여러 인스턴스를 보유하고 있다.

 

분산된 순수 캐시에 불과하며, 데이터 손실을 감당해야 한다.

 

여러 가지 캐싱 전략과 고려사항

lazy loading / cache-aside / lazy population

레이지 로딩, 캐시 어사이드, 레이지 파풀레이션 모두 같은 뜻이다.

 

단순하게 캐시에 들어가서 키값이 존재하면 히트,

존재하지 않으면 데이터베이스에서 해당 값을 찾아 캐시에 저장하고 반환하는 것이다.

 

장점

• 맨 처음에 캐시는 비어 있으며, 요청을 받을 때만 캐싱을 하기에 효율적이다.
• 만약 캐시가 삭제되거나 장애가 발생해도 치명적이지 않다.
• 다시 한 번 캐시를 채워야 하므로 대기 시간이 늘어난다는 단점은 존재한다. 

단점

• (읽기 패널티)캐시 미스일 경우 애플리케이션 -> 캐시 -> 데이터베이스 -> 캐시 작성
  으로 이동하는 네트워크 지연 시간이 길어진다.
• 데이터베이스가 업데이트 되어도 반드시 캐시에서 해당 데이터가 업데이트 되는 것이 아니다.
  • 따라서 데이터 일관성을 유지할 수 있는지 판단해야 한다.

위 코드는 레이지 로딩의 간단한 예시다.

 

 Write Through 전략 - 데이터베이스가 업데이트 시 캐시도 업데이트

DB에 업데이트가 일어날 때 캐시에 먼저 적고 그 다음에 DB를 업데이트 하는 방식이다.

 

• 캐시가 오래 유지되지 않는다. 쓰기가 발생할 때마다 캐시가 업데이트 된다.
• (쓰기 패널티) 데이터베이스에 뭘 작성할라고 할 때마다 네트워크 지연이 발생한다.
• 강의에서는 오로지 데이터베이스에 write가 날라갈 때만 캐시에 저장을 시켜서 캐시 활용도가
  떨어질 수 있다고 설명했다.
• write Through 전략과 lazy loading 전략을 합쳐 캐시 미스가 날 때도 캐싱을 하는 방법도 있다.
• 캐시 이탈률이 높아질 수 있다. 
  • 전혀 다시 안 쓰일 데이터가 write 되면 공간 낭비다.

데이터베이스가 업데이트 될 때 캐시도 같이 업데이트 되므로 라이트 뜨루 전략이다.

 

Cache Evictions and Time-to-live(TTL)

캐시 제거와 TTL 방식

 

캐시를 제거하는 것은 세 가지 방법이 있다.

1. 명시적으로 key 값을 통해 제거하는 것
2. 메모리가 거의 다 찼을 때 가장 오랜시간 사용되지 않은 캐시를 삭제하는 것(LRU)
3. TTL 설정 (생존 시간을 5분으로 걸어두고, 5분간 사용이 안 되면 삭제)

메모리가 너무 꽉차서 항상 너무 많은 캐시가 제거된다면 메모리 크기를 늘려야 한다.

 

정리

• 레이지 로딩(캐시 어사이드) 전략은 쉽게 구현할 수 있고 기초로 사용된다.
  • 특히 읽기 성능 향상에 많은 도움이 된다.
• 라이트 쓰루는 좀 더 손이 가고 이 자체로 캐시 전략이라 하기엔 무리가 있다.
  • 데이터 최신화를 위한 추가 전략에 가깝다
  • 데이터 최신화가 꼭 필요한 경우 적용하자
• TTL은 라이트 쓰루를 사용할 때를 제외하곤 준수한 성능을 항상 발휘한다.
  • 하지만 적합한 TTL 값을 찾는게 어렵다.

 

레디스 용 Amazon MemoryDB

레디스와 호환되고 내구성이 뛰어난 인 메모리 데이터베이스 서비스다.

 

Memory DB는 레디스와 호환되는 API가 있는 데이터베이스다.

그렇기 때문에 초당 1억 6천만 건의 요청을 처리하는 초고속 성능을 제공한다.

 

인 메모리 데이터 및 내구성이 좋은 데이터 스토리지로서 다중 AZ 트랜잭션 로그를 갖추고 있다.

 

• 10GB에서 100TB 이상에 이르기 까지 원활하게 크기를 조정한다.

많은 마이크로 서비스를 보유하고 있다고 가정하자,

이 마이크로 서비스는 레디스와 호환되는 인 메모리 데이터베이스에 액세스 해야한다.

 

이 경우 memory db의 아주 높은 속도와 다중 AZ 트랜잭션 로그가 큰 도움이 된다. 

 

다중 AZ 트랜잭션 로그는 여러 AZ에 저장되어 원하는 경우 빠른 복구와 데이터 내구성에 대한

액세스를 제공한다.