RDS overview
- 정의:
AWS의 데이터베이스를 위한 관리형 데이터베이스(Relational Database Service) + 여러 기능
- 유형
- PostgresQL 포스트그레스큐엘
- MySQL
- MariaDB
- Oracle
- MS SQL Server
- Aurora(AWS Proprietary database)
- 기능(왜 자체 DB 배포안하고 RDS를 사용할까?)
- Automated 프로비저닝
- Automated OS Patch
- Automated 백업 + 타임스탬프
- 매일 DB 전체 백업, 5분마다 일일 트랜잭션 로그 백업 ⇒ 어떤 지정 시점으로 DB 복원 가능
- 모니터링 대시보드를 통한 DB 성능 모니터링
- 읽기 성능 향상을 위한 읽기 복제(Read Replicas)
- 재해복구를 위한 Multi AZ
- 업그레이드를 위한 유지보수
- 확장성(Storage Auto Scaling)
- RDS DB 인스턴스를 동적으로 증가 할 수있다.
- 임계치를 선택해서 가용영역이 10%이하로 떨어지거나, 이 상황이 5분이상 진행되면, 자동으로 스토리지를 수정할 수 있다.
- 이렇게 워크로드를 예측할 수 없는 경우에 유용하다.
- gp2 or io1을 통한 백업
- 그러나! SSH를 통한 접근이 안된다.
RDS Read Replicas for read scalability
한개의 RDS에 너무 많은 요청을 받게 되면 최대 다섯개까지
읽기 복사(Read Replicas)가 가능하다.동일 가용영역(AZ), 리전 걸쳐서 생성이 가능하다.
두 읽기 전용 복제본 사이에 비동기식 복제가 발생한다. 비동기식이란 결국 읽기(Read)가 일관적으로 유지된다는 것을 뜻함. 애플리케이션에서 데이터를 복제하기 전에 읽기 전용 복제본을 읽어들이면 모든 데이터를 얻을 수 있다는 것을 의미한다.
Read Replicas Use Case
예를 들어서 평균적인 로드를 감당하고 있는
생산 데이터베이스가 있다고 해 봅시다
생산 데이터베이스에서는 메인 RDS 데이터베이스 인스턴스에 대한 읽기 및 쓰기가 수행됩니다 이때 새로운 팀이 와서 여러분의 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 한다고 해 보죠 보고 애플리케이션을 메인 RDS 데이터베이스 인스턴스에 연결하면 오버로드가 발생하고 생산 애플리케이션의 속도가 느려질 텐데 이런 현상은 피하고자 합니다 이때 여러분이 해결사로 나서서 새로운 워크로드에 대한 읽기 전용 복제본을 생성하는 겁니다 읽기 전용 복제본을 생성하면 메인 RDS DB 데이터베이스 인스턴스와 읽기 전용 복제본 간 비동기식 복제가 발생합니다 그다음 보고 애플리케이션이 생성한 읽기 전용 복제본에서 읽기 작업과 분석을 실행하게 되는 거죠 이 경우 생산 애플리케이션은 전혀 영향을 받지 않으니 완벽합니다 읽기 전용 복제본이 있는 경우에는 SELECT 명령문에만 사용하는 점을 명심해야 합니다 SELECT는 SQL의 키워드로 읽기를 의미하죠 따라서 데이터베이스 자체를 바꾸는 INSERT, UPDATE, DELETE 같은 키워드는 사용이 불가능합니다 읽기 전용 복제본은 읽기를 위함일 뿐이니 말이죠
Read Read Replicas - Network Cost
Read Replicas - Muli AZ(Avaliability Zone)
목적: 마스터 데이터베이스의 인스턴스 혹은 스토리지에 장애가 발생할 때 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 자동으로 조치를 취해주는것
RDS Security - 암호화 Encryption
- At rest encryption
AWS의 키 매니지먼트 서비스인 AWS KMS를 통해서 마스터 데이터베이스와 읽기 전용 복제본을 암호화할 수 있다. 또한 Oracle과 SQL 서버에서 TDE라고 하는 투명한 데이터 암호화 또한 가능하다.
- In-flight encryptio
- SSL 인증서가 필요한 전송 중에서 RDS 암호화를 제공한다.
- DB를 연결할때 신뢰성있는 인증서와 함께 SSL를 제공함
첫 번째 RDS 백업 암호화
- 만약, 암호화 되지 않은 RDS 데이터베이스에서 스냅샷을 생성하면 스냅샷 자체는 암호화 X
- 반면, 암호화된 RDS 데이터베이스에서 스냅샷을 생성하면 모든 스냅샷이 기본으로 암호화됨 (단, 기본 값은 아니다)
두 번째, 네트워크 보안
- 네트워크 보안의 RDS 데이터베이스는 일반적으로 프라이빗 서브넷에서 배포된다. 즉, 데이터베이스가 WWW에 노출되지 않도록 해야 합니다.
- RDS 보안은 RDS 인스턴스에 연결되어 있는 보안 그룹(Security Group)을 활용해 실행
세 번째, Access Management
- AWS RDS를 관리하는 사람만 제어할 수 있다. 데이터 생성, 삭제, read replicas 생성 등.
- DB 로그인을 하기 위해 Login OR IAM 기반 인증을 할 수 있다. 즉, DB 보안은 주로 데이터베이스 안에서 이루어지는것.
AWS Aurora
Aurora는 AWS의 사유 기술
- 사용법: Aurora는 호환 드라이버가 있어 Postgres와 MySQL 데이터베이스에 연결하면 실행가능
- 성능: 클라우드에 최적화 서비스로 RDS의 MySQL에서는 x5, Postgres에서는 x3 이상 향상된 성능
- 속도: 최대 15개의 read replicas 갖고 있을 수 있고, 복제속도도 훨씬빠르다(MySQL은 최대 5개 읽기복제)
- 비용: 비용이 20% , But, 규모 면에서 효율적 ⇒ 경제적.
하나의 마스터(상단의 M)와 여러개의 읽기 전용 복제본(상단의 R) 그리고 스토리지가 위처럼 작은 블록별로 자가 복구와 자동 확장이 실행된다.
AWS Aurora DB Cluster
- 공유된 스토리지 볼륨: 10GB에서 64TB로 자동 확장되는 기능을 갖고 있다.
- 마스터: 유일하게 스토리지에 기록할 수 있는 역할(Writer Endpoint 를 제공)
- 라이터 엔드 포인트(Writer Endpoint)는 DNS 이름으로 늘 마스터를 향해서 마스터 장애 시에도 클라이언트가 라이터 엔드 포인트와 통신해 올바른 인스턴스로 자동으로 리디렉션 시켜준다.
- 읽기 전용 복제본에 오토 스케일링 적용 가능(최대 15개의 읽기 전용 복제본 + 사용자 지정 읽기 수 지정)
Painpoint
오토 스케일링으로 애플리케이션이 읽기 전용 복제본의 URL을 추적하는 것이 어려워지면서 연결하기 어려워짐.
Solution: 리더 엔드포인트(Reader Endpoint)
Reader Endpoint는 라이터 엔드 포인트와 동일한 기능이 있는데 로드 밸런싱의 연결을 돕고 모든 읽기 전용 복제본에 자동으로 연결한다.
클라이언트가 Reader Endpoint에 연결할 때마다 읽기 전용 복제본 중 하나가 연결하는 식으로 로드밸런싱한다.
한 가지 알아야 할 것은 로드 밸런싱은 명령문 수준이 아니라 연결의 수준에서 발생한다.
More Features of Aurora
- 자동 장애 조치
- 백업 및 복원
- 격리(Isolation), 보안(security)
- 산업 규정 준수 기능(Industry compliance)
- 푸시 버튼식 오토 스케일링
- 자동 패치 w/ zero downtime
- 고급 모니터링
- 정기 유지 보수
- 백트랙(Backtrack): 언제든지 데이터를 복원할 수 있는 기능
Aurora Security
- RDS와 같은 엔진을 쓰기 때문에 Postgres와 MySQL 선택 가능
- KMS를 통한 미사용 데이터 암호화
- 자동 백업, 스냅샷, 복제본 암호화
- SSL을 통한 전송 암호화
- MySQL, Postgres와 동일한 프로세스입니다
- IAM 토큰을 사용한 인증
- 보안 그룹을 통한 인스턴스 보호
- SSH 연결 미지원
Aurora Advanced
PainPoint
리더 엔드 포인트에서 너무나도 많은 읽기 요청이 있어서 Amazon Aurora의 CPU 사용량이 증가하였다.
Solution: Replicas Auto Scaling을 사용한다.
위처럼 오토 스케일링 복제본을 설정할 수 있다. 이를 통해 Amazon 오로라 복제본이 추가되고 이후, 자동으로 Reader Endpoint가 이 새로운 Replica을 포함할 수 있도록 확장될 수 있다.
이 새 복제본은 트래픽을 수신하기 시작하고 전체 CPU 사용량을 낮추기 위해 좀 더 분산된 방식으로 읽기를 수행합니다. 이것이 오토 스케일링 복제본입니다
위처럼 2개는 r3.large 인스턴스를 사용하고 나머지 2개는 r5.2xlarge인 더 큰 인스턴스를 사용한다고 할때,
처음에는 Reader Endpoint로 Client의 요청을 모두 대응 하지만 Custom Endpoint를 추가로 만들어서 분석 쿼리를 실행하도록 한다. 이를 통해서 더 강력한 인스턴스를 적절한 일을 시키도록 한다.
추가적으로 성능이 더 좋은 r5.2xlarge인 애들을 토대로
Aurora Serverless
- 자동화된 데이터베이스 인스턴스화와 실제 사용을 기반으로 한 오토 스케일링을 제공
드물거나 간헐적이거나 예측할 수 없는 워크로드가 있을 때 유용 ⇒ 용량 계획을 수행할 필요가 없다.
비용절감: 스핀 업 상태인 오로라 인스턴스를 토대로 초당 비용을 지불하기 때문에 비용면에 효율적
클라이언트는 오로라에서 관리하는 Proxy Fleet과 통신하고 백엔드에서는 서버리스 방식으로
워크로드를 기반으로 많은 오로라 인스턴스를 생성한다. 그래서 미리 용량을 프로비저닝할 필요가 없다.
Aurora Multi-Master
- Writer 노드에 대한 빠른 장애 조치를 원할때, 즉 Writer 노드에 대한 높은 가용성을 원하는 경우에 쓰인다.
- 오로라 클러스터에 있는 모든 노드가 Read와 Write 작업을 하는데, 만약 쓰기 노드가 하나만 있고 다운돼서실패하게 되면 Read Replicas을 새로운 마스터로 승격시킨다.
여기 오로라 인스턴스가 세 개 있습니다
서로 복제를 수행하고 있죠
공유 스토리지 볼륨이 있고
클라이언트는 데이터베이스 연결을 여러 개 갖습니다
모든 오로라 인스턴스는 쓰기 작업을 수행할 수 있고
만일 어떤 오로라 인스턴스가 실패하면
라이터 노드에 대한 즉각적인 장애 조치를 제공하는
다른 노드로 자동 장애 조치를 수행할 수 있습니다
이는 시험에서 출제될 사용 사례와 시나리오의 종류입니다
Gloal Aurora
- 오로라 리전 간 읽기 전용 복제본이 있다면
- 재해 복구 유용
- 간단한 구현
- 오로라 글로벌 데이터베이스
- 모든 읽기 및 쓰기가 발생하는 하나의 기본 리전이 있지만
- 최대 5개의 보조 읽기 전용 리전을 설정 가능(보조 리전당 복제본 지연시간(lag)이 1초 미만)
- 최대 16개의 읽기 전용 복제본을 가질 수 있습니다
⇒ 전 세계의 읽기 전용 복제본에 대한 지연 시간(latency)을 줄일 수 있다
- 어떤 리전에서 데이터베이스의 중단이 발생하더라도 RTO가 있으므로 복구 시간은 1분 미만이 될 것이다.
Aurora Machine Learning
- SQL 인터페이스를 통해 애플리케이션에 ML 기반 예측을 추가할 수 있는 개념
- 오로라와 다양한 AWS 머신 러닝 서비스 간의 간단하고 최적화된 안전한 통합입니다
- 지원되는 두 서비스
- 백엔드에서 모든 종류의 머신 러닝 모델을 사용할 수 있는 SageMaker
- 감정 분석을 수행할 때 쓰는 Amazon Comprehend가 있죠
Usecase
- 사기 탐지, 광고 타겟팅 감정 분석
- 제품 추천입니다
Amazon ElastiCache
RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있죠
또한, ElastiCache는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 한다
캐시란 무엇일까요?
캐시는 높은 성능과 낮은 지연 시간을 가진 인 메모리 데이터베이스입니다
그리고 일래스틱 캐시를 사용하면 읽기 집약적인 워크로드의 부하를 줄이는데 도움이 됩니다.
이 개념은 일반적인 쿼리가 캐시 되어 데이터베이스가 매번 Query 날리지 않고 캐시는 이러한 쿼리 결과를 검색할 때 사용할 수 있는 것입니다
애플리케이션의 State를 Amazon 일래스틱 캐시에 저장해 애플리케이션을 Stateless 만들 수 있도록 합니다
RDS와 같은 장점을 갖기 때문에 AWS는 동일한 유지 보수를 수행합니다
- 운영 체제, 패치, 최적화, 설정, 구성, 모니터링, 장애 회복 그리고 백업을 수행
일래스틱 캐시를 사용할 때 애플리케이션에 관한 몇 가지 어려운 코드 변경을 요청할 수도 있습니다
단순한 활성화가 아니라 데이터베이스 쿼리 전과 후에 캐시를 쿼리하도록 애플리케이션을 변경해야 하죠
이제 일래스틱 캐시 사용을 위한 아키텍처를 살펴보겠습니다
여러 가지 중에서 예시를 하나 들어보죠
일래스틱 캐시와 RDS 데이터베이스 그리고 애플리케이션이 있고
애플리케이션은 일래스틱 캐시를 쿼리합니다
쿼리가 이미 생성됐는지
이미 생성되어 일래스틱 캐시에 저장됐는지 확인하는 것은
캐시 히트(cache hit)고
이는 일래스틱 캐시에서 바로 응답을 얻어서
쿼리하기 위해 데이터베이스로 이동하는 동선을 줄여줍니다
캐시 미스(cache miss)의 경우에는 데이터베이스에서 데이터를 가져와서
데이터베이스에서 읽습니다
동일한 쿼리가 발생하는 다른 애플리케이션이나 인스턴스에서는
데이터를 캐시에 다시 기록하여
다음에는 같은 쿼리로 캐시 히트를 얻도록 합니다
이는 RDS 데이터베이스에서 부하를 줄이는데 도움을 주는데
데이터를 캐시에 저장하기 때문에
캐시 무효화 전략이 있어야 하며
가장 최근 데이터만 사용하는지 확인해야 합니다
이것이 캐싱 기술 사용과 연관된 어려움이라고 할 수 있죠
다른 아키텍처는 사용자 세션을 저장해 애플리케이션을
무상태로 만드는 것입니다
사용자가 애플리케이션의 모든 계정에 로그인하면
애플리케이션이 일래스틱 캐시에 세션 데이터를 기록하는 것입니다
사용자가 애플리케이션의 다른 인스턴스로 리디렉션 되면
애플리케이션은 일래스틱 캐시에서
직접 세션 캐시를 검색할 수 있습니다
그래서 사용자는 계속 로그인한 상태로 한 번 더 로그인 할 필요가 없죠
사용자의 세션 데이터를
일래스틱 캐시에 기록해서 애플리케이션을
무상태로 만든 것입니다
레디스와 멤캐시트의 차이를 전반적으로 이해하는 것도
시험에 출제될 수 있습니다
레디스(Redis)는 자동 장애 조치로 다중 AZ를 수행하는 기술이며
읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높습니다
약간 RDS와 비슷합니다
그리고 지속성으로 인해 데이터 내구성도 있으며
백업과 기능 복원 기능도 있습니다
RDS와 많이 유사합니다
멤캐시트(Memcached)는 데이터 분할에 다중 노드를 사용하고
이를 샤딩(sharding) 이라고 합니다
가용성이 높지 않고
복제도 발생하지 않습니다
지속적인 캐시가 아닙니다
백업과 복원 기능도 없죠
그리고 다중 스레드 아키텍처로
몇몇 샤딩과 함께 캐시에서 함께 실행되는
여러 인스턴스가 있습니다
여기서 기억해야 할 것은
레디스는 고가용성과 백업
읽기 전용 복제본 등이 있고
멤캐시트는 데이터를 손실할 수 없는
단순한 분산 캐시입니다
가용성이 높지 않고 백업과 복원 기능도 없습니다
바로 이것이 두 기술의 가장 큰 차이점입니다
여기까지입니다 즐거우셨길 바랍니다
다음 강의에서 뵙겠습니다
ElastiCache - Cache Security
- 모든 캐시는 IAM 인증을 지원하지 않는다.
- 일래스티 캐시에서 정의할 IAM 정책은 AWS API 수준 보안에만 사용된다
즉 캐시 생성, 캐시 삭제 같은 종류의 작업을 의미합니다
그러나 캐시 내의 모든 작업은 IAM을 사용하지 않습니다
레디스를 인증하려면 레디스 AUTH를 사용하여 레디스 클러스터를 생성할 때 비밀번호나 토큰를 설정할 수 있다.
이렇게 하면 캐시에 들어갈 때 비밀번호를 사용할 수 있습니다 이는 캐시에 사용할 수 있는 보안 그룹에 대한
추가적인 수준의 보안입니다.
- 전송 중 암호화를 위해 SSL 보안을 지원할 수 있습니다
- 반면 멤캐시트는 좀 더 높은 수준인 SASL 기반 인증을 지원합니다
상당히 고급이라 다른 종류의 인증 메커니즘이죠
캐시의 보안을 살펴보면
EC2 인스턴스에는 자체 보안 그룹도 레디스에
액세스할 수 있는 자체 보안 그룹이 있습니다
그래서 일래스티 캐시를 사용하여 보안 그룹 수준의 보안을 수행할 수 있죠
다음 전송 중 암호화를 위해 SSL 암호화가 있습니다
또 인증을 위해 일래스티 캐시에서 레디스 종류의 캐시를
사용할 때 레디스 AUTH를 가질 수 얻을 수 있습니다
Patterns for ElastiCache
일래스티 캐시에 데이터를 불러오는 패턴에는 세 가지가 있습니다
- 레이지 로딩
- 모든 읽기 데이터가 캐시되고 데이터가 캐시에서 부실해질 수 있습니다
- 라이트 스루
데이터를 오래된 데이터가 없는 데이터베이스에 기록될 때마다 캐시에 데이터를 추가하거나 업데이트하는 겁니다 그리고 이전에 보셨듯 일래스티 캐시를 세션 저장소로 쓸 수 있고 Time To Live(TTL) 속성으로 세션을 만료시킬 수 있습니다
캐싱은 아주 어려워서
컴퓨터 과학 분야에서 유명한 인용구가 있습니다
'컴퓨터 과학에는 어려운 일이 두 개가 있다
바로 캐시 무효화와 이름을 짓는 일이다'
이렇듯 캐싱은 아주 복잡한 주제며 제가 보여드린 건 아주 간단한 개요입니다
어쨌든 레이지 로딩의 전략을 설명드리겠습니다
일래스티 캐시에 캐시가 히트하면 애플리케이션이
캐시로부터 데이터를 받습니다
만일 캐시 미스가 있으면
데이터베이스에서 데이터를 읽고 캐시에 씁니다
이전에 이미 봤던 것들이죠
캐시 히트가 없을 때만 발생하기 때문에 레이지 로딩이라고 합니다
그런 다음 데이터를 Amazon 일래스티 캐시에 불러옵니다
이제 레디스의 사용 사례에 대해 얘기해 볼텐데요
시험을 위해 알아두셔야 할 부분이 있습니다
게임 리더보드 생성에 대한 겁니다
매우 복잡합니다
게임의 어느 시점에서든
누가 1위고 누가 2위고
3위인지 가려내는 개념입니다.
그래서 레디스에는 고유성과 요소 순서를 모두 보장하는
Sorted set 이라는 기능이 있습니다
요소가 추가될 때마다
실시간으로 순위가 매겨진 다음 올바른 순서로 추가됩니다
레디스 클러스터가 있는 경우
실시간으로 1위, 2위, 3위 플레이어가 있는
실시간 리더보드를 생성한다는 개념인 거죠
그리고 모든 레디스 캐시는 동일한 리더보드를 사용할 수 있습니다
즉 레디스로 Amazon
일래스티 캐시와 통신할 때
클라이언트는 이 실시간 리더보드에 액세스할 수 있고
애플리케이션 측에서 이 기능을 프로그래밍할 필요가 없습니다
실시간 리더보드에 액세스하기 위해
레디스의 정렬된 집합을 활용할 수 있습니다
다음은 적어도 한 번은 봐야 할 표준 포트 리스트입니다. 암기할 필요는 없지만(시험을 위해 암기할 필요는 없습니다), 그러나 중요 포트(HTTPS - 포트 443)와 데이터베이스 포트(PostgreSQL - 포트 5432)를 구별할 수 있어야 합니다.
중요 포트:
- FTP: 21
- SSH: 22
- SFTP: 22(SSH와 동일)
- HTTP: 80
- HTTPS: 443
vs RDS 데이터베이스 포트:
- PostgreSQL: 5432
- MySQL: 3306
- Oracle RDS: 1521
- MSSQL 서버: 1433
- MariaDB: 3306(MySQL과 동일)
- Aurora: 5432(PostgreSQL 호환 시) 또는 3306(MySQL 호환 시)
MySQL 데이터베이스를 온프레미스에서 RDS로 이전해 둔 상태입니다.
여러 애플리케이션과 개발자들이 이 데이터베이스와 상호작용을 하고 있습니다.
각 개발자들은 기업의 AWS 계정 내에 IAM 사용자를 가지고 있습니다.
각 개발자들을 위해 DB 사용자를 생성하는 대신, 이들에게 MySQL RDS DB 인스턴스로의 액세스를 부여하기 위해서는 어떤 접근법을 취해야 할까요? ⇒ IAM 데이터베이스 인증 활성화하기
암호화되지 않은 RDS DB 인스턴스로는 암호화된 읽기 전용 복제본을 생성할 수 없습니다.