RDS, Aurora, Elastic Cache

RDS - Relational Database Service, SQL 구문 사용, postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, Aurora 관리 가능, 데이터 프로비저닝, OS 패치 자동화, 지속적인 백업, 타임스태프 활용한 복원, 대시보드 모니터링, 읽기 전용 복제본으로 성능 개선, 재해 복구 목적의 다중 AZ 설정, 업그레이드, 스케일링 가능, EBS에 저장(gp2, io1), RDS 인스턴스에 SSH로 접속 불가능

 

     - Storage Auto Scaling : 최대치 설정, 남은 공간이 10%로 이하일 때, 스토리지 부족 상태가 5분 이상 지속 시, 지난 수정으로부터 6시간이 지났을 때

     - Read Replicas for read scalability : 최대 15개의 복제본 생성, 동일한 AZ, 다른 AZ나 리전에 걸쳐 생성, 복제본을 데이터베이스로 변경 가능, 비동기식 복제, SELECT 구문만 사용 가능, 동일 리전의 다른 AZ에서 복제본을 생성할 때는 비용 X, 다른 리전에 복제본 생성 시 비용 O

     - Multi AZ : 재해 복구 목적으로 사용, 동기적으로 복제, 하나의 DNS 이름을 가짐, 마스터 DB에 문제가 생겼을 때 자동으로 대기하던 복제 DB에 자동으로 장애 조치 수행, 가용성 증가, 전체 AZ, 네트워크 손실, 인스턴스나 스토리지 장애 시, 자동화, 읽기 및 쓰기 불가, 읽기 전용 복제본을 다중 AZ로 변경 가능

     - single AZ -> multi AZ : 다운타임 없음, 전환 시 데이터베이스 중지 필요 없음, 기본 DB의 RDS가 자동으로 스냅샷 생성, 새로운 대기 DB에 복원, 기존 DB와 대기 DB 간 동기화, 기존 DB의 내용을 모두 수용해 다중 AZ 설정 완료

     - custom : Oracle, Microsoft SQL Server에서 OS 및 DB 사용자 지정 기능 사용 가능, 내부 설정 구성, 패치 적용, 네이티브 기능 활성화, SSH나 SSM 세션 매니저를 통해 EC2 인스턴스에 접속 가능, 자동화 모드 비활성화 권장, 스냅샷 권장

 

Aurora - Portgres, MySQL 호환, 자동 스토리지 확장, 읽기 전용 복제본 최대 15개 생성 가능, 즉각적인 장애 조치, 가용성 높음, RDS 보다 스케일링 면에서 효율적, 3개의 AZ를 걸쳐 6개의 복제본 생성, 쓰기에는 4개, 읽기에는 3개만 있으면 됌, 백엔드에서 P2P 복제를 통핸 자가 복구 가능, 수백개의 볼륨 사용, RDS의 다중 AZ와 비슷(마스터 DB가 장애나면 다른 복제 DB가 마스터로 변경, 리전 간 복제 지원), writer endpoint는 DNS 이름으로 마스터 DB를 가르킴, reader endpoint는 writer endpoint와 같은 기능, 연결 로드 밸런싱에 도움, 모든 복제본과 자동으로 연결

 

     - Replica Auto Scaling : 읽기 전용 복제본에 대한 수요가 많을 때 자동 스케일링으로 복제본이 늘어나고 read endpoint 범위가 늘어남

     - Custom Endpoint : 복제본의 크기가 다를 수 있는데 이는 Aurora 인스턴스의 서브셋을 custom endpoint로 정의하기 위함, 크기가 큰 복제본이 더 강력해 분석 쿼리를 실행하는게 더 효율적일 때, read endpoint 생성하지 않음

     - Serverless : 실제 사용량에 기반한 자동 DB 인스턴스화, 자동 스케일링 가능, 비정기적이거나 간헐적인 워크로드에 유용, 초당 비용 지불

     - Multi Master : write node에 대한 즉각적인 장애 조치, 높은 가용성, 모든 노드에서 읽고 쓰기 가능, 원래는 마스터에서만 쓰기 가능

     - Global Aurora : 권장사항, 읽고 쓰기가 가능한 한개의 리전 존재, 지연 시간이 5초 이내인 보조 읽기 전용 리전을 5개까지 설정 가능, 각 보조 리전마다 최대 16개의 읽기 전용 복제본 생성 가능, RTO(복구 시간 목표)는 1분 이내, 리전에 걸쳐 데이터 복제하는 시간은 평균 1초 미만

     - Machine Learning : 머신러닝 기반 예측을 SQL 인터페이스로 어플리케이션에 적용, SageMaker, Amazon Comprehend와 통합 가능

     - DB Cloning : 기존 DB에서 새로운 DB 클러스터 생성 가능, 스냅샷이나 복원보다 빠름

 

Back up

     - RDS 자동 백업: 지정 시간에 DB 전체를 백업, 매 5분마다 트랜잭션 로그 백업

     - RDS 수동 백업 : 수동으로 백업, 원하는만큼 오래 백업 보관 가능

     - 일정 기간마다 사용하고 DB를 냅두는 경우 비용 지불해야 함, 하지만 스냅샷 만들고 DB 지우면 비용 절감

     - Aurora 자동 백업 : 1 ~ 35일 보유 가능, 비활성화 불가, 정해진 범위 내 언제든 복구 가능

     - Aurora 수동 스냅샷 : 수동으로 백업, 원하는만큼 오래 백업 보관 가능

     - 백업이나 스냅샷으로 새 DB를 만들어 복원 가능, S3로부터 MySQL RDS DB 복원 가능(DB 백업), S3로부터 MySQL Aurora 클러스터 복원 가능(Percona XtraBackup 사용해 백업 후 복원)

 

Security - DB의 데이터 암호화 가능, AWS KMS를 사용해 마스터와 복제본의 암호화 이뤄짐, 처음 실행에서 설정, 마스터 DB에서 암호화 설정을 하지 않으면 복제본에서도 암호화 불가능, 암호화 안된 DB를 암호화 하려면 스냅샷을 만들어 DB를 생성해 암호화 설정 해야 함, 전송 중 데이터 암호화, IAM 롤을 통한 DB 접근, 보안그룹을 통한 접근 제어, SSH 접속 불가(RDS Custom은 예외), 감사 로그

 

Proxy - 어플리케이션이 DB 내에서 DB connection Pool을 형성하고 공유 가능, RDS DB 인스턴스에 연결이 많을 경우 DB 리소스 부담을 줄여 효율성 높일 수 있음, 개방된 연결, 시간초과 최소화, 서버리스, Auto Scaling, 가용성 높음, 다중 AZ, RDS DB 인스턴스에 장애 발생 시 대기 인스턴스로 실행, RDS 프록시로 인해 장애 조치 시간을 66% 감소 가능, DB에 IAM 인증을 통해서만 인스턴스에 접근할 수 있도록 설정 가능, 자격 증명은 AWS Secret Manager에 보관, 퍼블릭 접근 불가

 

Elastic Cache - Redis, Memcached 같은 캐시 기술을 관리, 캐시(높은 성능과 낮은 지연 시간을 가지는 인 메모리 DB), Elastic Cache를 사용하면 읽기에 집약된 워크로드의 부하를 줄일 수 있음(일반적인 쿼리가 캐시로 되서 매번 DB에 접근 X, 이런 결과를 검색할 때 사용 가능), 어플리케이션의 상태를 저장해 stateless로 만들 수 있음, 운영체제, 패치, 최적화, 장애 회복, 백업 가능, 몇가지 어려운 코드 변경 요청 가능

 

     - 어플리케이션은 Elastic Cache를 쿼리, 쿼리가 생성되었는지, 생성되어 저장되었는지 확인하는 작업을 Cache Hit(Elastic Cache에서 응답을 얻어 DB에서 작업하는 동선 없앰), Cache miss(DB를 읽어 데이터를 가져옴), 동일한 쿼리가 발생하면 데이터를 캐시에 기록, RDS DB 로드 부하 감소, 캐시 무효화 기능이나 최근 데이터만 사용하고 있는지 확인 필요

     - 사용자가 어플리케이션에 접속하면 Elastic Cache에 세션 데이터 기록, 어플리케이션의 다른 인스턴스로 리다이렉션 되면 세션 캐시를 검색해 로그인 지속 가능

     - Redis : 자동 장애 조치, 다중 AZ 수행, 읽기 전용 복제본은 읽기 스케일링에 사용, 가용성 높음, 지속성으로 데이터 내구성 있음, 백업, 기능 복원 기능

     - Memcached : 데이터 분할에 다중 노드 사용(Sharding), 가용성 높지 않음, 복제 없음, 지속적인 캐시 X, 백업 및 복원 기능 X, 멀티 스레드 아키텍쳐

     - Elastic Cache는 IAM 인증 지원 안함, AWS API 수준 보안에만 IAM 정책 사용(캐시 생성, 삭제 등), Redis를 인증하려면 Redis Auth를 사용해 비밀번호나 토큰 설정 가능, SSL 보안 지원, Memcache는 더 높은 SASL 기반 인증 지원

     - Lazy Loading(모든 읽기 데이터가 캐시, 데이터가 부실해질 수 있음), Write Through(오래된 데이터가 없는 DB에 기록될 때마다 캐시에 데이터 추가, 업데이트), Session Storage(TTL로 만료 가능)

     - Gaming Leaderboard : Redis(고유성, 요소 순서를 모두 보장하는 정렬된 집합 기능 존재, 요소가 추가될 때마다 실시간으로 순위 변경)