AWS RDS

RDS

RDS는 sql 쿼리문을 사용하는 db를 위한 managed DB service이고

AWS에서 제공하는 서비스는 Postgres,Mysql,MicroSoftSql,maridDB,Oracle,Aurora가 있다.

 

인스턴스 자체에 DB를 설치하는 방법도 있는데 왜 굳이 RDS라는 걸 쓸까 ? 

-- > 데이터 베이스 뿐만아니라 다른 서비스 또한 제공하기 때문이다.

1. 데이터 베이스 프로비저닝, .기본운영체제 패치가 자동화 된다. 

2. 지속적으로 백업이 생성된다.  특정 시점으로 복원이 가능하다.  

3. 데이터 베이스의 성능을 모니터링할 수 있다. 

4. 읽기 전용 복제본을 만들어 사용할 수도 있다.  

4. 재해복구목적으로 다중 AZ설정가능   

5. 수직 수평확장이 가능하다.   

6. 파일스토리지는 EBS로 구성된다  (gp2 or io1)

 

하지만 RDS EC2에  ssh접근은 불가하다.

RDS custom 이라는 것도 있다 비교를 해보자면

RDS는 데이터베이스 전체를 관리한다. 운영체제나 나머지등 전부다 aws가 관리한다.

RDS커스텀은 오라클.Mssql을 사용가능하고 운영체제나 데이터베이스에 접근할 수 있는 어드민 권한을 가지게 된다

즉, Amazon RDS Custom은 데이터베이스 및 OS 패치 적용, 백업 등을 포함한 유지보수 및 사용자 지정을 사용자가 직접 할 수 있다는 것입니다. 또 ssh, 세션매니저를 사용해서 RDS가 있는 EC2에 접근할 수도 있다. ( 기존 rds는 안됨 )

RDS ASG

  rds를 오토 스케일할 수 있다. 예를들어 파일 스토리지 공간을 20gb로 설정해두었는데 사용할 수록 점점 용량이 부족해 질 것이다.

RDS가 이를 감지하고 자동으로 수평확장을 해 나갈 것이다. 용량을 늘리기위해 db서버를 끄거나 할 필요가 전혀 없다.

즉 수동으로 하지 않아도 된다.

you have to set maximum storage threshold ( 스토리지를 확장할 최대치를 정해야 한다 ) 할당된 용량에서 10% 미만으로 남으면 자동으로 확장한다. 

 

예측할 수 없는 ( unpredictable workload를 사용할 때 유용하다 ) 

 

읽기 전용(read replicas) 복제본

최대 읽기전용 인스턴스를 5개 까지 만들 수있다고 한다.

async방식으로 마스터를 복제 한다고 한다. 이건 무슨뜻인지 잘 모르겠다. -> 마스터에서 write한게 바로 읽기복제본에 동기화가 안된다는 뜻 같음

같은 가용영역이나, 심지어 다른 가용영역, 다른 Region에도 만들 수 있다.

읽기전용을 실제 DB로 승격시킬 수도 있다고 한다. 자동으로 동기화가  

 

사용예로 하나의 데이터베이스를 사용하고 있을 때, 이 데이터베이스를 분석하기 위한 레포트 애플리케이션을 생성한다면

과 부하가 걸릴 수 있기 때문에 복제본을 만들어 레포트를 위한 애플리케이션에서는 복제본을 읽어들이는 방식으로 사용하거나 할 수 있다.  

 

AWS는 기본적으로 다른 AZ와 네트워크 통신을 할 때 비용이 발생한다. 하지만. RDS의 경우에는 같은 레전이라면 다른 AZ에 RDS replicas를 생성하더라도 비용이 발생하지 않는다.

다른 레전에 읽기전용 을 만들면 네트워크 비용이 발생한다.

 

, 다중AZ

이건 재해복구에 주로 사용된다 .

다른 AZ에 디비를 만들어 두고  sync방식으로 마스터 디비를 복제한다고 한다 -> 마스터에서 write한게 바로 읽기복제본에 동기화가 된다는 뜻 같음

이건 마스터와 같은 하나의 DNS를 사용하고 마스터에 문제가 생겼을 경우에, 다중AZ를 마스터로 자동으로 승격시키고 

이를 사용하도록 바꾸어준다. 이를 읽기전용이라고 부르지 않고 스탠바이라고 부른다. 언제 문제가 생길지 모르니까 임시로 만들어두는느낌인것같다.

재해복구를 위해서 읽기전용 복제본을 다중AZ로 설정하는것 또한 가능하다.

 

 

단일 AZ에서 다중 AZ로 전환할 때 데이터베이스를 멈추거나 할 필요가 전혀 없다.

 설정하는 방법은 그냥 수정버튼에서 다중 AZ를 선택하면 끝이라고 한다.

먼저 다중az로 선택하면 마스터 디비의 스냅샷을 하나 찍고 이걸로 새로운 스탠바이 디비를 만든다.

이후 생성되면 두 데이터 베이스 간 sync복제가 (동기화) 되므로 마스터 디비의 모든 내용을 수용하여 다중az가 된다고 한다.  

 

Aurora

오로라는 AWS에서 만든 RDS이다. 엄청난 성능을 가지고 있다.

mysql postgres와 호환이 가능하다.

자동으로 스토리지 용량을 10기가에서 128테라바이트까지 늘려준다.

기존 rds가 최대 5개의 읽기전용을 가지는 것에 비해서 오로라는 15개까지 가질 수 있다.

장애조치도 즉각적이다. 클라우드 네이티브이므로 가용성이 높다.

비용은 20%정도 더 비싸다. 근데 기능이 좋아 그 이상의 비용절감이 가능할 것이다.

 

오로라는 high availablity , read scaling을 자랑한다.

무언가를 저장할 때마다 3개의 가용영역에 6개의 복사본을 (각 2개)만든다. 따라서 가용성이 높다는 것이다.

무언가를 쓸 때 (write) 4개의 카피만 있으면 된다고 한다?

읽기에는 3개의 카피만 있으면 된다고 한다.

일부 데이터가 문제가 생기면 자가 복구를 한다.

마스터에 문제가 생기면 다른 복사본이 마스터로 변경되는데 마스터의 엔드포인트가 있으므로 항상 유저는 그 엔드포인트를 통해 젒속을 하기에 스토리지가 바뀌어도 문제없이 잘 접속할 수 있다. 이걸 writer endpoint라고 한다.

reader endpoint라는 것도 존재하는데 이건 오토스케일링이 되면서 생기는 복제본들의 엔드포인트가

모두 하나의 엔드포인트를 가리키고 있다. 그래서 사용자가 리더 엔드포인트로 연결하면 여러 복제본들 중 하나와 연결이 되는 느낌이다.

로드 밸런서역할을 하는 것이다. 이 로드 밸런싱은 스테이트 레벨에서 이루어지는 것이아니라 커넥션 레벨에서 이루어 진다. 

오로라 특징

스토리지가 자동 스케일링 된다 10기가 ~ 128테라

읽기 전용 복제본들이 오토스캐일링이된다.

writer endpoint는 마스터 를 가리키고,

readerendpoint는 읽기전용 복제본들을 가리킨다.

자동장애조치

백업및복구

 

 

Aurora 고급개념

 

하나의 writer포인트 에 마스터가 연결

하나의 readerendpoint에 2개의 읽기복제본이 연결되어있는 상태에서

클라이언트가 많은 요청을 보내면 읽기복제본의 cpu사용량일 늘어나면서 자동 오토스캐일링을 통해 2개가 더 생성이 되면

그 복제본들의 rederendpoint역시 기존의 것을 참조하고 있다. 따라서 리붸스트가 분산이 되면서 cpu사용률이 낮아지게 된다.

이 때에 복제본들은 모두 다 같은 스펙이다.

 

customendpoint라는 것도 존재한다. 

예를들어 읽기 복제본이 4개가 있는데 이 중 2개는 스펙이 다르다. 따라서 이 둘만 따로 접속하고 싶을 때도 있을 것이다.

이 때에는 커스텀 엔드포인트를 생성하여 이 두개와 묶어주면 이 두개에만 따로 접속이 가능하다 ( 리더엔드포인트에도 연결이 되어있긴함) 

사용자 엔드포인트를 만들면 기존의 리더엔드포인트는 사용하지 않게된다고한다.

없어지지는 않는다고 하는데 그럼 또 다른 사용자 엔드포인트를 만들어서 기존 복제본들과 연결시켜 리더엔드포인트 처럼 사용하는 것인가?? 이건 잘 모르겠다.

 

서버리스

실제 사용량에 기반하여 자동 데이터베이스 인스턴스화와 오토스케일링을 가능하게 해준다고한다.

비정기적,간헐적, 예측 불허한 워크로드에 유용하다고 한다.  

프록시 플릿을 사용함

 

멀티마스터

장애조치로써 모든 인스턴스들이 쓰기 및 읽기가 가능해진다.

기존에는 하나의 마스터만 쓰기가 가능하고 나머지 복제본에서 읽기만 가능한 식이었다.

그래서 마스터에서 장애가나면 기존에 있던 읽기복제본에서 마스터로 승격시킨뒤 마스터로 사용하는 방식이었는데

멀티 마스터에서는 모두가 마스터이므로 그런 작업이 필요없어지게된다.

 

global aurora

다른 가용영역이 아닌 다른 리전에도 복사본을 생성할 수 있다.

다른 리전에 복사본을 생성하는데 걸리는 시간은 1초 미만이다.

east-1지역에 오로라를 만들면 거기선 쓰기 읽기가 다 가능하다 ( primary )

west-1지역에 복사본 오로라를 만들면 거기선 읽기만 가능하다. ( secondary )

east-1지역에 장애가 발생하면 west에 있는 복사본을 마스터로 승격시킨다 따라서 쓰기와 읽기가 가능해진다.

이 시간은 1분도 안걸린다고한다.

총 5개의 다른 리전에 만들 수 있다. 각 지역마다 16개의 복제본을 만들 수 있다고 한다. 

 

머신러닝과 통합

머신러닝에 기초한 예측을 sql인터페이스로 애플리케이션에 적용시킨다고 한다. 

 

 

RDS 백업

자동백업 :  RDS서비스가 자동으로 매일 데이터베이스 유지관리 시간에 데이터 베이스 전체를 백업한다. 

거기에 더해 5분마다 트랜잭션 로그도 백업된다고 한다.  따라서 5분 마다 이동할 수 있다는 개념같다. 

1일 10시 5분, 10시 10분, 10시 15분, 이런식으로 

자동백업 기간은 1~ 35일까지 가능하다.

0으로 설정하면 백업을 안함

 

수동백업 : 수동으로 DB스냅샷을 찍는다. 

이건 내가 지우지 않는한 계속 가지고 있을 수 있다 ( 자동백업은 설정 기간이 지나면 사라짐) 

 

비용절감팁 : 만약 일주일에 2시간만 데이터베이스를 사용한다고 가정해보자. 사용할 때만 실행시키고 안할 때는 중지시켜놔도 돈이 빠져나간다. 따라서 사용한 뒤에 스냅샷을 생성하고 데이터베이스를 지우고 다시 사용할 때 만들어 놓은 스냅샷으로 데이터베이스만든 뒤 사용하면 훨씬 비용이 절감된다 ( 스냅샷이 훨씬 저렴하기에 )

 

오로라 백업

자동백업 : 이 역시 1 ~ 35일까지 지정이 가능한데 RDS에서는 0일로 지정하면 자동백업이 비활성화 되는 반면에 Aurora자동백업은 비활성화할수 없다. 정해진 시간 내 어느 시점으로도  복구할 수 있다. 

 

수동백업 : 수동으로 스냅샷을 만들 수 있다.

이건 내가 지우지 않는한 계속 가지고 있을 수 있다 ( 자동백업은 설정 기간이 지나면 사라짐) 

 

오로라 데이터베이스 Cloning

기존의 데이터베이스에서 새로운 오로라 디비 클러스터를 만들 수 있다.

스냅샷을 찍어서 그걸 복원하는 방법보다 훨씬 빠르다.

RDS 오로라 복원

1. RDS 및 오로라의 백업 또는 스냅샷으로 새로운 데이터베이스로 복원이 가능하다.

 

2. S3로부터 Mysql RDS 데이터베이스를 복원할 수 있다고 한다.

 - 온프로미스의 데이터베이스의 백업을 만들고, 그걸 s3에 저장하는 것이다.

 - Mysql을 실행중인 RDS인스턴스에 s3에 저장된 백업파일로 복원을 하면 된다.

 

3. Aurora 클러스터에 복원하는 방법

 - 온프로미스에 있는 데이터베이스의 백업을 Percona XtraBackup을 이용해서 백업본을 만든다.

 - 이 백업파일을 s3에 저장한다.

 - 그리고 나서 이 백업파일을 Mysql를 실행중인 오로라 클러스터에 복원할 수 있다. 

 

RDS와 Aurora클러스터의 차이점은

RDS에 복원할 때는 단순히 데이터베이스의 백업본을 만들면되는데 오로라의 백업본을 만들 땐 저 특정 프로그램을 사용하여 만드는 것이다.

 

RDS, 오로라 시큐리티

데이터 베이스 암호화

RDS 및 오로라의 데이터베이스에 저장된 데이터를 암호화할 수 있다. 

데이터가 볼륨에 암호화 된다는 것이다.

KMS를 사용해 마스터의 모든 복제본이 암호화되며,  이건 데이터베이스를 처음 실행시킬 때 정의 된다.

어떠한 경우라도 마스터를 암호화 하지 않은 경우 읽기 복제본을 암호화할 수는 없다. 

또한 기존에 암호화 되어있지 않은 데이터베이스를 암호화 하려면 그 데이터의 스냅샷을 찍은뒤 스냅샷으로 새로운 

데이터베이스를 생성할 때 암호화 해주어야한다.  

 

클라이언트와 데이터베이스간 암호화

둘다 기본적으로 이 기능을 가지고 있다. 이걸 사용하려면 반드시 클라이언트트 AWS에서 제공하는 TLS 루트 인증서를 사용해야한다.

 

IAM인증

예를들어 ec2에 데이터베이스에 접근할 수 있는 iam role을 지정해주면 아이디나 비밀번호없이도 그 데이터베이스에 접속할 수도있다.

 

보안그룹

보안그룹을 사용해서 네트워크 액세스를 통제할 수 있다. 

 

RDS나 오로라에는 ssh로 접근할 수 없다. 근데 rds커스텀을 사용하면 들어갈 수도 있다.

또한 감사서비스가 있어서 시간에 따라 RDS나 오로라에 어떤 쿼리가 생성되었고 데이터베이스 등으 ㄹ확인하려면 이 기능을 사용하면된다.

금방 사라지며 오래 보관하려면 클라우드 워치 로그로 보내야한다고한다.

 

RDS 프록시

프록시를 사용하면 클라이언트 측의 연결이 이전에는 직접 RDS로 연결이 되었다면, 프록시를 사용하면 프록시로 연결이 들어오고 프록시에서 RDS로 커넥션 시켜주는 방법이다. 이걸 왜 사용하는지 잘 몰랐는데, RDS는 커넥션 수에 제한이 있다고 한다. 근데 람다를 사용하여 커넥션을하면, 커넥션이 많이 생겨버리기에 RDS가 스캐일링을 통해 커넥션을 늘려버린다고 한다. 하지만 프록시를 사용하면 커넥션 수를 제한할 수 있고 커넥션을 컨틀롤 해주기에 좋다고 한다. 이건 단편적인 이점일 뿐 다른 이점또한 많을 것이다. 

 

RDS인스턴스에서 장애가 발생하면 이 전에는 각 인스턴스마다 장애조치를 해줘야했지만 RDS 프록시에서 장애조치를 해준다고 한다. ㄷ시간로 66%나 절약시켜준다고한다.

 

데이터 베이스에 IAM인증을 강제시킴으로써 IAM인증을 통해서만 데이터베이스에 접속이 가능하도록 한다. 

 

이렇게 하면 RDS는 절대 퍼블릭에서 접근이 불가능하다. 아래의 블로그에서 자세히 설명을 해주었다.

 

https://medium.com/harrythegreat/aws-%EC%84%9C%EB%B2%84%EB%A6%AC%EC%8A%A4%EB%A5%BC-%EC%9C%84%ED%95%9C-rds-proxy%EC%84%9C%EB%B9%84%EC%8A%A4-fb5815b83cce

[AWS] 서버리스를 위한 RDS Proxy서비스

 

Amazon ElasticCache

종류가 2가지있는데 redis, memcached

redis는 고가용성, 읽기전용복제본 생성, 마스터에 장애생기면 복제본을 마스터로 승격시켜 사용, 백업 사용

memcahed는 단순한 분산캐시이다  

 

iam인증을 지원하지 않는다.

 

레디스

레디스를 인증하려면 redis auth를 사용하여 레디스를 생성할때 비밀번호나 토큰을 지정할 수 있다. 이렇게 하면 캐시에 들어갈 때 비밀번호 사용가능

전송중 암호화를위해 SSL사용가능 

 

멤캐시드

SASL기반의 인증을 사용한다 ( 더 보안 성이 높음 )

 

레이지로딩 : 먼저 애플리케이션이 엘리스틱 캐시에 캐시 히트를 해서 해당 데이터가 있으면 rds까지 안가고 캐시에서 데이터를 가져오고 없다면 (캐시 미스) 그제서야 rds에 접속하여 데이터를 가져오고 이를 캐시에 저장한다 이걸 레이지 로딩이라고한다.

 

여러분은 게임 개발 업체에서 솔루션 아키텍트로 근무하고 있습니다. 하나의 게임에서, 실시간 점수를 기반으로 플레이어들의 랭킹을 매겨야 합니다. 여러분의 상사가 게임 리더보드 생성을 위해 효율적이고 고가용적인 솔루션을 설계해 구현해 줄 것을 요청했습니다. 무엇을 사용해야 할까요?

-> redis elastic cache 에 정렬된 세트 사용

https://minholee93.tistory.com/entry/AWS-ElastiCache-Redis-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0

[AWS] ElastiCache Redis 사용하기