AWS Section 8. RDS+Aurora+ElasticCache

📌 RDB (Relational Database)

• RDS는 관계형 데이터베이스 서비스의 약자
• SQL을 쿼리 언어로 사용하는 DB용 관리형 DB 서비스
• 클라우드에서 AWS가 관리하는 RDS 서비스인 데이터베이스를 만들 수 있음
  • Postgres
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • IBM DB2
  • Aurora (AWS 독점 DB)

 

💡 RDS 의 주요 특징

_ EC2에 DB를 배포하는 것보다 RDS를 사용하는 것이 더 유리

 

💡RDS는 관리형 서비스이므로 단순히 DB 제공 외에도 많은 서비스 제공💡

• 자동화된 운영
  • 프로비저닝 및 운영 체제 패치가 자동으로 이루어짐
  • 지속적인 백업 및 특정 시점 복원(Point in Time Restore) 가능.
  • 모니터링 대시보드 제공으로 데이터베이스 성능 모니터링 가능.
• 읽기 복제본 (Read Replicas)
  • 읽기 성능을 향상시키기 위한 복제본 설정 가능.
• 다중 가용 영역 (Multi-AZ)
  • 재해 복구(Disaster Recovery)를 위한 다중 가용 영역 설정 가능.
• 확장 기능
  • 수직적 확장: 인스턴스 크기 증가.
  • 수평적 확장: 읽기 복제본 추가.
• EBS 스토리지
  • RDS 스토리지는 EBS (Elastic Block Store)로 지원됨
• SSH 접근 불가
  • RDS 인스턴스에는 SSH를 사용할 수 없으며, AWS에서 모든 관리가 이루어짐

 

📌 RDS - 스토리지 오토스케일링 (시험)

• 자동 스토리지 확장
  • RDS는 데이터베이스 스토리지가 부족하면 자동으로 스토리지를 확장함

• 사용자가 수동으로 스토리지 확장 작업을 할 필요가 없음.
• 최대 스토리지 임계값을 설정해야 하며, 무한 확장을 방지할 수 있음

• 자동 스케일 조건
  • 할당된 스토리지의 10% 미만이 남고,
  • 5분 이상 스토리지 부족 상태가 지속되며,
  • 마지막 수정 이후 6시간이 지난 경우 스토리지가 자동으로 확장됨
• 유용성
  • 예측 불가능한 업무량을 가진 애플리케이션에서 매우 유용하며, RDS용 모든 데이터베이스 엔진에서 지원됨

 

📌 RDS 읽기 전용 복제본 (Read Replicas)

• 목적: 읽기 성능을 향상시키기 위해 사용.

 

특징:

• 최대 5개의 읽기 전용 복제본 생성 가능.
• 동일 AZ, 다른 AZ, 또는 다른 리전에 복제본 생성 가능.
• 주된 RDS DB와 두 읽기 전용 복제본 사이에 비동기식 복제가 발생 (비동기식 : 결국 읽기가 일관적으로 유지된다는 것을 뜻함)
• 읽기 전용 복제본을 독립적인 데이터베이스로 승격 가능.
  • 이후에는 복제 메커니즘을 완전히 탈피
• 애플리케이션 연결 업데이트 필요
  • 애플리케이션이 복제본을 활용하려면 애플리케이션의 모든 연결을 업데이트해야 함.
  • 이를 통해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록 활용 가능
• 🚨 사용 제한: 읽기 전용 복제본은 SELECT 명령문에만 사용 가능!! (INSERT, UPDATE, DELETE는 불가능).

Use cases

• 메인 RDS에서 인스턴스에 대한 읽기, 쓰기가 수행됨
• 다른 팀이 와 우리의 데이터를 기반으로 보고 및 분석을 실시한다 했을 때 읽기 전용 복제본을 생성!!>> 메인 RDS DB와 읽기 전용 복제본 간 비동기식 복제가 발생
• Reporting application에서 데이터를 읽을 때, production application 에 부담을 주지 않고 복제본에서 읽기 작업을 수행함으로써 성능 저하를 방지.

 

📌 RDS 읽기 전용 복제본 - 네트워크 비용

• 동일 리전 내에서의 복제:
  • 동일 리전의 다른 AZ에 있는 읽기 전용 복제본으로 비동기 복제가 이루어질 경우, 네트워크 비용이 무료

  • 

  • 크로스 리전 복제:
    • 서로 다른 리전으로 복제할 경우, 네트워크 복제 비용이 발생..

      

 

📌 RDS 다중 AZ (Multi-AZ) (재해 복구용)

• 목적: 재해 복구(Disaster Recovery)를 위한 설정.

• 가용영역 AZ A에서 읽기와 쓰기를 수행하는 마스터 데이터베이스 인스턴스
• 그리고 마스터 데이터베이스의 모든 변화를 동기적으로 AZ B에 복제
  • 이는 마스터 애플리케이션의 변경사항이 대기 인스턴스에도 그대로 복제된다는 것을 의미함
  • 즉 하나의 DNS 이름을 가지고 애플리케이션 또한 하나의 DNS 이름으로 통신해 마스터에 문제가 생길 때도 AZ B에 자동으로 장애 조치가 수행됨 (가용성👆🏻)

특징 정리

• 동기화 복제(SYNC Replication): 마스터 인스턴스에서 변경된 모든 데이터가 스탠바이 인스턴스에 동기식으로 복제됨.
• 자동 장애 조치(Failover): 가용 영역 손실, 네트워크 실패, 인스턴스 또는 스토리지 장애 시 자동으로 스탠바이 인스턴스로 장애 조치됨.
• 애플리케이션 수정 불필요: 장애 발생 시 애플리케이션이 자동으로 스탠바이로 연결되므로 수동 개입이 필요 없음.
• 다중 AZ 가능 But 확장 목적이 아님: 다중 AZ는 성능 확장이 아닌, 장애 대비용으로 사용.

 

📌 단일 AZ에서 다중 AZ로의 전환

• 제로 다운타임 (다운타임 없음)
  • 데이터베이스를 중지할 필요 없이 다중 AZ로 전환 가능.
  • ‘수정’만 누르면 됨
• 작업 절차

• 자동으로 스냅샷 생성.
• 새로운 AZ에 스탠바이 데이터베이스 복원.
• 두 데이터베이스 간 동기화 완료.

 

👩🏻‍💻 실습_ Amazon RDS 👩🏻‍💻

 

보안 그룹의 인바운드 규칙 수정

• 포트 3306의 소스 >> 내 IP 에서 Anywhere-IPv4로 수정

 

📌 Aurora (🌟시험 출제 多) _ 작동방식 이해가 중요

• Aurora는 AWS의 독점 기술 (오픈 소스 X)
  • 오픈 소스가 아니지만 Postgres와 MySQL을 지원.
• 성능:
  • 오로라는 "AWS 클라우드에 최적화된" 제품
  • MySQL RDS보다 5배 빠르고, Postgres RDS보다 3배 빠른 성능.
  • 자동 스토리지 확장: 10GB에서 시작해 최대 128TB까지 자동으로 확장. (설계 방식과 관련 O)
  • 복제본: 최대 15개의 읽기 전용 복제본을 가질 수 있으며, 복제 지연이 매우 짧음.
  • 오로라에서 장애 조치를 수행하는 경우, 즉각적으로 이루어짐
  • 비용: RDS보다 약 20% 더 비싸지만 효율적.

 

📌 Aurora 고가용성과 읽기 확장성

• 6개의 데이터 복사본을 3개의 AZ에 분산
  • 쓰기 시 6개 중 4개의 복사본이 필요.
  • 읽기 시 6개 중 3개의 복사본이 필요.
  • 즉 읽기에 대한 가용성이 높음
  • 자가 복구 및 P2P 복제를 통해 데이터 손상 시 자동으로 복구.
  • 볼륨은 수백 개의 볼륨에 의지함
  • 자동 장애 조치: 마스터 인스턴스에 장애가 발생하면 30초 이내에 자동으로 장애 조치.

<다이어그램 관점>

• M 마스터는 쓰기 역할 / R 읽기 복제본은 여러 가용 영역에 분산되어 읽기 작업을 처리함
• 3개의 가용 영역(AZ)
  • 다이어그램에는 3개의 가용 영역이 있음. 각 가용 영역은 데이터 복제를 통해 데이터를 보관
    • 각 가용 영역에 데이터가 분산 저장되는데, 그림 아래쪽에 나오는 여러 색깔의 블록은 데이터가 서로 다른 AZ에 나뉘어 저장되는 방식을 보여줌
      • 각 색깔은 데이터 블록을 의미하며, 같은 데이터를 여러 가용 영역에 복제하여 저장. 예를 들어, 파란색 데이터는 AZ 1, AZ 2, AZ 3 모두에 복제되어 저장됨
• 공유 스토리지 볼륨
  • 각 가용 영역에는 공유 스토리지 볼륨이 있으며, 이는 복제, 자가 복구, 자동 확장 기능을 갖추고 있음
  • 데이터가 여러 AZ에 걸쳐 복제되어 있어 높은 내구성을 제공
• 장애 복구
  • 만약 마스터 인스턴스에 장애가 발생하면, 다른 읽기 전용 복제본이 마스터 역할을 대체할 수 있음. 이 장애 조치는 30초 이내에 완료됨
• 확장성 및 내구성
  • 시스템은 데이터를 자동으로 확장하고 복제하며, 만약 데이터에 문제가 생겨도 자동으로 복구됨
• 복제본
  • 각 AZ에 걸쳐 여러 개의 데이터 사본이 존재하며, 최대 15개의 읽기 전용 복제본이 존재할 수 있음. 이를 통해 많은 양의 읽기 작업을 효율적으로 처리할 수 있음.

 

📌 Aurora DB Cluster

• 클라이언트(Client)
  • 클라이언트는 데이터베이스와 상호작용하는 사용자.
  • 클라이언트는 데이터베이스에 데이터를 읽고 쓰는 요청을 보냄
• Writer Endpoint
  • Writer Endpoint는 데이터베이스에 쓰기 작업을 담당하는 엔드포인트
  • 이 엔드포인트는 항상 마스터 인스턴스(M)를 가리킴.
  • 즉, 클라이언트가 데이터를 저장할 때 Writer Endpoint를 통해 마스터 인스턴스로 데이터를 보냄
  • DNS 이름으로 제공되며, 마스터 인스턴스에 장애가 발생해도 클라이언트는 계속해서 같은 Writer Endpoint로 연결을 시도할 수 있음. Aurora가 자동으로 새로운 마스터로 리디렉션을 해줌
• Reader Endpoint
  • Reader Endpoint는 읽기 작업을 담당하는 엔드포인트
  • 클라이언트가 데이터를 읽으려고 할 때, Reader Endpoint는 여러 읽기 전용 복제본(R) 중 하나에 연결됨
  • 로드 밸런싱이 자동으로 이루어져, 여러 복제본 중에서 사용되지 않은 복제본을 골라 작업을 배분. 이를 통해 효율적으로 읽기 성능을 높일 수 있음
  • 로드 밸런싱은 문장 수준이 아니라 연결 수준에서 이루어짐. 즉, 연결이 성립될 때 어떤 복제본으로 연결할지가 결정됨
• 읽기 전용 복제본(R)
  • 여러 개의 읽기 전용 복제본(R)이 존재하며, 이 복제본들은 오직 읽기 작업만을 처리. 읽기 복제본은 최대 15개까지 만들 수 있으며, 필요에 따라 오토 스케일링으로 개수를 자동으로 조절할 수 있음.
  • Auto Scaling : 읽기 복제본의 수가 증가하거나 감소할 수 있는데, 이는 트래픽 양에 따라 자동으로 조정됨
• 공유 스토리지 볼륨
  • 아래쪽에 Shared Storage Volume이 있는데, 이 스토리지는 10GB에서 최대 128TB까지 자동으로 확장됨. 즉, 저장 공간이 부족해지면 자동으로 더 많은 데이터를 저장할 수 있도록 확장됨.
  • 이 스토리지는 모든 인스턴스와 공유되며, 읽기 복제본과 마스터 인스턴스가 모두 같은 데이터를 공유하고 사용함

 

📌 Aurora의 주요 기능

• 자동 장애 조치 및 백업/복구.
• 격리성 및 보안: 산업 규정 준수.
• 푸시 버튼 확장: 쉽게 스케일링 가능.
• 제로 다운타임으로 자동 패치 수행.
• 고급 모니터링 및 정기적인 유지 관리.
• Backtrack: 백업 없이도 특정 시점으로 데이터 복구 가능.

 

👩🏻‍💻 실습 👩🏻‍💻

• writer instance와 reader instance를 위한 다른 인스턴스가 있다는 것
• 이 둘은 AZ도 다름
• database-2는 연결하기 이전에 엔드포인트가 2개 있음

 

이 엔드포인트들은 우리의 응용 프로그램이 Aurora에 연결하기 위해 사용해야할 것들

 

 

가능한 작업들

• 우리가 정책을 생성했을 때, 복제본의 평균 CPU 활용에 기반한 혹은 Aurora 복제본으로의 평균 연결 수에 기반해 읽기 전용 복제본을 확장시킴

 

호환되는 인스턴스로 교체하면, 데이터베이스 클러스터로 다른 리전을 추가할 수 있게 됨! (내가 만든 건 X)

 

📌 RDS 및 Aurora 보안

1. 미사용 데이터 암호화 (At-rest encryption)

• 데이터가 볼륨에서 암호화됨
• AWS KMS를 사용하여 마스터와 복제본을 암호화해야 함
• 암호화는 데이터베이스 생성 시 설정되어야 함.
• 마스터 DB가 암호화되지 않으면 복제본도 암호화할 수 없음.
• 기존 비암호화 DB를 암호화하려면, 스냅샷을 생성하고 암호화된 DB로 복원해야 함.

2. 전송 중 데이터 암호화 (In-flight encryption)

• 클라이언트와 데이터베이스 간의 암호화
• RDS 및 Aurora는 기본적으로 전송 중 암호화를 지원.
• 클라이언트는 AWS TLS 루트 인증서를 사용해 데이터베이스와 통신할 수 있음.

3. IAM 인증 (IAM Authentication)

• RDS와 Aurora는 전통적인 사용자 이름/암호 인증 방식을 사용할 수 있음.
• IAM 역할을 사용하여 사용자 이름과 비밀번호 없이 인증 가능.
• 예: EC2 인스턴스의 IAM 역할을 통해 데이터베이스에 직접 연결 가능.

4. 보안 그룹 (Security Groups)

• 네트워크 접근 제어: 보안 그룹을 사용해 데이터베이스로의 접근을 허용하거나 차단 가능 (특정 포트, IP).

5. SSH 접근

• RDS와 Aurora는 SSH 접근 불가 (관리형 서비스이므로).
• 단, RDS Custom을 사용하는 경우 SSH 접근 가능.

6. 감사 로그 (Audit Logs)

• 데이터베이스 쿼리와 활동 기록을 위한 감사 로그 활성화 가능.
• 장기 보관을 위해 CloudWatch Logs로 전송 가능.

 

 

📌 RDS Proxy 개요

• 완전 관리형 데이터베이스 프록시로, RDS 및 Aurora 데이터베이스와 애플리케이션 간의 연결을 관리.
• 연결 풀링: 애플리케이션이 RDS 프록시에 연결하면, 프록시는 데이터베이스 인스턴스로의 연결을 풀링하여 리소스 소모를 줄임 (CPU, RAM 등).

 

🛠️ RDS Proxy의 주요 기능

• 서버리스 및 자동 스케일링: 용량 관리를 필요로 하지 않으며, 다중 AZ 지원으로 높은 가용성 보장.
• 장애 조치 시간 단축: RDS 및 Aurora 장애 조치 시간을 66%까지 줄여줌.
• 지원하는 데이터베이스: RDS(MySQL, PostgreSQL, MariaDB) 및 Aurora(MySQL, PostgreSQL).
• 코드 변경 불필요: 애플리케이션 코드를 변경하지 않고 RDS Proxy로 전환 가능.

 

🔒 보안 및 인증

• IAM 인증 강화: 데이터베이스에 연결할 때 IAM 인증을 사용하도록 설정 가능.
• AWS Secrets Manager와 연동하여 자격 증명을 안전하게 저장 및 관리.
• 프록시 접근 제한: RDS Proxy는 VPC 내에서만 접근 가능하며, 공개적으로 접근 불가.

 

👫 Lambda와의 연동

• Lambda 함수와의 통합: Lambda 함수가 다수의 연결을 빠르게 생성하고 종료하는 상황에서 RDS Proxy가 연결 풀링을 통해 효율적으로 관리.
• Lambda 함수가 RDS 데이터베이스 인스턴스에 연결할 때 발생하는 연결 과부하를 해결해 줌.

 

👍🏻 장점 요약

• 데이터베이스 리소스를 절약하고, 연결 효율을 높이며, 장애 조치 시간을 단축하는 동시에 IAM 인증과 보안을 강화해줌.

 

📌 Amazon ElastiCache 개요

• 목적
  • RDS가 관리형 관계형 데이터베이스를 제공하는 것처럼 ElastiCache는 관리형 Redis 또는 Memcached를 제공
• 캐시
  • 인 메모리 데이터베이스로 매우 높은 성능과 낮은 대기 시간을 제공하며, 읽기 집약적인 워크로드에서 데이터베이스 부하를 줄여줌
• 애플리케이션 무상태화
  • 애플리케이션 상태를 캐시에 저장함으로써 무상태 애플리케이션 구현에 도움을 줌
• AWS 관리
  • AWS는 운영 체제 관리, 패칭, 최적화, 설정, 모니터링, 장애 복구 및 백업을 처리
• 코드 변경
  • ElastiCache 사용 시 애플리케이션 코드에 많은 변경이 필요. 단순히 활성화만으로 캐시를 사용할 수 있는 것이 아니며, 애플리케이션이 캐시를 쿼리하도록 코드를 변경해야 함

 

💾 ElastiCache 아키텍처_ DB 캐시

• 애플리케이션이 ElastiCache를 먼저 쿼리하고, 없으면 RDS에서 데이터를 가져와 ElastiCache에 저장
  • 이를 통해 RDS의 부하를 줄여줌
• 캐시 무효화 전략을 통해 항상 최신 데이터만 사용되도록 해야함!

 

💾 ElastiCache 아키텍처_ 사용자 세션 저장소

• 사용자가 애플리케이션에 로그인하면 세션 데이터가 ElastiCache에 저장됨
• 사용자가 다른 인스턴스로 이동할 때 ElastiCache에서 세션 데이터를 불러와 로그인 상태를 유지
• 이를 통해 애플리케이션을 무상태로 만들 수 있음

 

🆚 Redis vs Memcached

• Redis

• 다중 AZ와 자동 장애 조치(Auto-Failover) 지원
• 읽기 복제본(Read Replicas)을 통해 읽기 확장 및 고가용성 제공
• 데이터 내구성(AOF) 지원 및 백업/복원 기능
• 세트 및 정렬 세트(Sorted Sets) 지원

 

• Memcached

• 다중 노드를 통한 데이터 파티셔닝(Sharding)
• 고가용성 없음 (복제 없음)
• 비지속성 (데이터 영구 저장 안 함)
• 백업/복원 기능 없음
• 다중 스레드 아키텍처

 

🤔 캐싱 구현 시 고려사항

• 데이터 캐시가 안전한가?
  • 데이터가 최신이 아닐 수 있고, 결국 일관성이 유지되지만 시간이 소요될 수 있습니다.
• 데이터에 캐싱이 효과적인가?
  • 패턴: 데이터가 천천히 변하고 자주 필요한 키가 적은 경우.
  • 안티 패턴: 데이터가 빠르게 변하고 전체 키 공간이 자주 필요할 경우.
• 데이터 구조가 캐싱에 적합한가?
  • 예를 들어, 키-값 저장이나 집계 결과 캐싱이 적합한 경우.
• 적합한 캐싱 설계 패턴은 무엇인가?
  • 적절한 패턴을 선택하는 것이 중요합니다.

 

📌 Lazy Loading / Cache-Aside / Lazy Population

• 장점:
  • 요청된 데이터만 캐싱되어 불필요한 데이터로 캐시를 채우지 않음.
  • 노드 실패가 발생해도 치명적이지 않음(다만 캐시 예열로 인해 대기 시간이 증가).
• 단점:
  • 캐시 미스로 인한 3번의 네트워크 왕복 발생으로 성능 지연.
  • 캐시의 데이터가 오래되어 최신 상태가 아닐 수 있음.
• 의사 코드 예시

 

 

📌 Write-Through (데이터베이스가 업데이트될 때 캐시를 추가 또는 업데이트)

• 장점:
  • 캐시의 데이터는 절대 오래되지 않으며 읽기가 빠름.
• 단점:
  • 데이터베이스에 데이터가 추가 또는 업데이트되기 전까지는 데이터 누락 발생 가능.
  • 많은 데이터가 캐시에 있지만 실제로는 사용되지 않을 수 있음 (캐시 이탈률).

 

 

📌 Cache Eviction (캐시 제거) 및 Time-to-live (TTL)

• 캐시에서 데이터 제거는 세 가지 방법으로 발생:
  • 명시적으로 삭제.
  • 메모리가 가득 차서 최근 사용되지 않은 데이터 제거(LRU).
  • 타임 투 리브(TTL)를 설정해 일정 시간이 지나면 삭제.
• TTL 활용: 리더보드, 코멘트, 활동 스트림 등에서 유용하며, TTL은 몇 초에서 며칠까지 다양하게 설정할 수 있음.

 

 

💡 중요한 사항 요약

• Lazy Loading은 구현이 쉽고 대부분의 경우에서 유용.
• Write-Through는 Lazy Loading과 함께 사용하여 성능 최적화를 돕는 방식.
• TTL 설정은 일반적으로 나쁜 생각이 아니며 적절한 값으로 설정하는 것이 중요.
• 필요한 데이터만 캐싱해야 하며, 모든 데이터를 캐싱하려 해서는 안 됨.

 

 

📌 Amazon MemoryDB for Redis 개요

• Redis 호환: Redis와 호환되며 내구성이 뛰어난 인 메모리 데이터베이스 서비스.
• 초고속 성능: 초당 1억 6천만 건 이상의 요청을 처리할 수 있는 매우 빠른 성능.
• 내구성 있는 데이터 저장: 다중 AZ 트랜잭션 로그를 사용하여 내구성을 보장하는 인 메모리 데이터 스토리지.
• 확장성: 10GB에서 100TB 이상의 스토리지를 무리 없이 확장 가능.
• 사용 사례: 웹 및 모바일 애플리케이션, 온라인 게임, 미디어 스트리밍 등 성능이 중요한 애플리케이션에 적합.

 

 

🛠️ 주요 기능

• 마이크로서비스와의 적합성: 여러 마이크로서비스가 Redis 호환 인 메모리 데이터베이스에 액세스해야 하는 경우에 적합.
• 다중 AZ 트랜잭션 로그: 여러 가용 영역에 데이터를 저장하여 빠른 복구 및 데이터 내구성 제공.
• 인 메모리 속도: 수백 개의 노드에서 인 메모리로 데이터를 저장해 초고속 성능을 제공.