RDS(Relational Database Service)
- SQL을 쿼리 언어로 사용하는 DB에 대한 관리형 데이터베이스 서비스
- AWS에서 관리하는 DB엔진 : Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora(AWS독점)
- RDS 인스턴스에 SSH를 적용할 수 없음
EC2 인스턴스 위에 자체 DB서비스를 구축하는 대신 RDS를 사용하는 이유
- 관리형 시스템
- DB프로비저닝 완전 자동화
- 지속적인 백업으로 특정 타임스탬프로 복원 가능
- 모니터링 대시보드 사용
- 읽기 복제본을 가질 수 있다.
- 읽기 성능향상을 위해 다중AZ를 설정할 수 있다.
- 유지보수를 위한 창이 있음
- 인스턴스 수직/수평 확장 가능
- 스토리지는 EBS의 지원을 받는다(gp2 or io1)
RDS Storage Auto Scailng
- RDS 데이터베이스를 생성할 때는 원하는 스토리지 용량을 지정해야 한다
- 이미 지정해둔 용량에서 스케일링이 필요할 때 사용
- 스토리지를 늘리기 위해 DB를 중단하는 작업을 할 필요가 없음
- 최대 저장 임계값을 설정해야 함
- 할당된 저장 공간의 10% 미만이 남고, 부족한 저장 공간이 5분 이상 지속, 마지막 수정 이후 6시간이 지났을 경우 저장 공간을 자동으로 늘어난다.
RDS Read Replicas for read scalability (읽기 전용 복제본)
- DB인스턴스가 너무 많은 요청으로 충분히 스케일링할 수 없을 때 읽기 전용 복제본을 최대 15개까지 생성 가능
- 동일한 AZ , 다른 AZ, 다른 리전을 걸쳐 생성될 수 있다.
- 메인 DB 인스턴스와 읽기 전용 복제본 사이에 비동기식 복제가 발생한다.
- 변경 사항을 일정한 시간 간격으로 복제하여 약간의 지연이 있음.
- 권한을 얻으면 데이터베이스로 승격시켜 사용할 수 있음
- 메인 DB 내용으로 분석을 하고자 하면 읽기전용 복제본을 사용할 수 있음
- SELECT 명령문만 사용 가능 (읽기 전용)
- AWS에서 관리형 서비스들은 다른 AZ로 전송시 비용이 발생하지 않음. 따라서 RDS 읽기 전용 복제본도 동일 리전 내에서 다른 AZ로 전송 시 비용이 발생하지 않는다. (다른 리전이라면 비용 발생)
RDS 다중 AZ
- 스토리지나 AZ에 장애가 생겼을 때 재해 복구에 사용됨
- 동기식으로 RDS 마스터 DB 인스턴스를 스탠바이 인스턴스로 복제해 사용할 수 있음. (마스터DB의 모든 변동사항을 동기적으로 복제)
- 하나의 DNS이름을 가지고 통신하여 마스터DB에 문제가 생기면 스탠바이DB에 자동으로 장애 조치가 수행되며 마스터로 승격된다.
- 스케일링에 이용되지 않고 수동으로 조치를 취할 필요가 없다.
- 누구도 스탠바이 인스턴스를 읽거나 쓸 수 없다. 오직 장애 조치를 위한 대기만 수행한다.
- 원한다면 읽기 전용 복제본을 다중 AZ로 사용할 수 있다.
- 단일 AZ에서 다중 AZ로 전환할 때는 DB를 중지할 필요가 없다. DB수정을 클릭하고 다중 AZ 기능을 활성화시키기만 하면 된다.
RDS 실습
RDS 생성 실습
1. RDS > Create database 선택해 생성
표준 생성, 간편 생성 중 선택할 수 있다.(여기서는 표준 생성)
엔진 옵션으로 DB엔진을 선택한다.
템플릿은 환경에 따라 선택한다. (여기서는 프리티어)
프리티어를 선택하면 아래 설정을 건들지 못한다
가용성과 내구성에서 다중AZ 여부를 선택한다.
자격증명에서 AWS Secret Manager를 선택하면 추가요금이 부과된다.
Self managed를 선택해 비밀번호를 설정해준다.
인스턴스의 구성에서는 인스턴스 크기를 설정할 수 있다.
클래스를 선택하고 원하는 인스턴스를 고른다.
스토리지도 설정해주면 되는데 지금 프리티어를 골라서 기본 설정대로 둔다.
Storage autoscaling 기능을 활성화하면 임계값을 넘어서면 저장 공간의 용량이 확장된다. 활성화한다면 최대저장 임계값을 설정해야 한다.
연결성에서 EC2인스턴스와 RDS를 연결할건지 선택할 수 있다.
- 연결하면 EC2인스턴스와 네트워킹 측면이 자동으로 구성된다. 따라서 보안 그룹 등을 처리할 필요가 없어서 유용하다.
- 연결하지 않으면 지정된 VPC에 배포해야 한다. 서브넷 그룹을 지정한다.
데이터베이스에 대한 공개 엑세스 여부에 대해서도 선택해야 한다.🚨Public Access 설정시 IPv4 과금 주의
Public Access 설정 시 Yes를 선택하면 EC2인스턴스 말고 외부에서 접근이 가능하다. 그러기 위해 자동으로 AWS로부터 public IP를 부여받기 때문에 과금이 발생할 수 있다!!!
외부에서 EC2 거쳐서 RDS 접속하기 👈이 블로그를 참고하면 스프링부트로 개발 시에 퍼블릭 엑세스를 사용하지 않으면서 외부에서 RDS로 접근할 수 있다.
Public IPv4는 시간별로 0.005달러가 과금되는데 링크에서 Public Ipv4가 사용되는 서비스들을 확인할 수 있다.
또 대쉬보드에서 VPC IP address manager를 선택 > 퍼블릭 IP 인사이트(IPAM 프리티어 생성) > 퍼블릭 IP주소 섹션을 확인하면 현재 사용중인 퍼블릭 IPv4주소를 확인할 수 있다.
보안 그룹도 지정해야 한다.
연결을 하지 않으면 VPC 보안그룹을 만들거나 선택할 수 있고 포트도 설정할 수 있다.
데이터베이스 인증을 선택한다.
비밀번호로 접근하는 방법, IAM데이터베이스 인증을 통해 IAM사용자와 역할로 접근하는 방법, 커버로스로 접근하는 방법이 있다.
(여기서는 비밀번호)
모니터링을 사용한다면 리소스를 선택한 초만큼 세분화할 수 있다. (여기서는 비활성화)
추가적인 설정에서 초기 DB이름을 입력할 수 있고 백업을 활성화/비활성화할 수 있다. 활성화하면 1~35일 동안 백업파일이 보관된다.
Backup window에서는 백업 시간을 정할 수 있다. (여기선 비활)
원하는 로그를 RDS에서 CloudWatch 로그로 내보내 장기간 보관할 수 있다.
아래에서는 마이너 버전 업그레이드를 위한 윈도우 유지보수 기간설정과 실수로 DB를 삭제하는 것을 막는 삭제방지기능도 활성화할 수 있다.
월간 비용을 확인할 수 있다. 현재는 프리티어가 적용된다.
2. SQL 클라이언트 프로그램 (sql electron)을 설치
3. 만들어진 RDS 확인 및 보안그룹 수정
RDS > Databases에서 엔드포인트와 포트번호, 보안그룹을 볼 수 있다.
보안그룹의 인바운드 규칙에서 3306포트의 소스를 현재는 나의 IP만 되는데 이를 누구나로 수정해준다.
4. SQL 클라이언트 프로그램에서 접속
sql electron에서 Add로 새로운 DB를 추가해준다.
DB이름과 타입, 서버 주소는 RDS의 Endpoint를 복사해서 붙여넣고 포트도 RDS의 3306포트로 설정한다. User는 RDS생성 당시의 관리자 이름을 넣어주고 패스워드를 입력한다. initial Database는 RDS에서 설정한 이름으로 하고 TEST를 누른다.
접속이 안된다면 보안그룹과 Public Access를 활성화했는지 확인한다.
이렇게 정상적으로 접근이 되면 SAVE를 누른다.
그러면 SQL클라이언트 사용이 가능하다.
mydb를 선택하고 아래처럼 테이블하나를 추가한다.
CREATE TABLE mytable (name VARCHAR(20), first_name VARCHAR(19));
그러면 이처럼 테이블이 만들어진다. 이렇게 SQL클라이언트 프로그램으로 RDS에 접근해 사용할 수 있다.
RDS 기타 실습
RDS 읽기 전용 복제본 생성
👉 만들어진 RDS를 선택하고 Actions > Create read replica를 선택한다.
RDS 스냅샷 생성
👉 만들어진 RDS를 선택하고 Actions > Take snapshot을 선택한다.
생성하면 원하는 시점으로 복원할 수 있고 스냅샷을 다른 지역으로 이동할 수 있다.
RDS 삭제하기
👉 만들어진 RDS를 선택하고 Modify를 눌러 삭제방지기능을 비활성화해야한다. 그 다음 삭제하기를 눌러 스냅샷 생성을 비활성화(비용청구 방지)하고 delete me를 입력한 다음 삭제에 동의한다고 체크하면 삭제가 가능하다.
RDS 커스텀
- RDS에서는 OS나 사용자 지정 기능에 엑세스할 수 없지만 RDS Custom에서는 가능하다.
- Oracle, Microsoft SQL Server에서만 가능하다.
- 내부 설정 구성, 패치 적용, 네이티브 기능 활성화가 가능하다.
- SSH 또는 SSM 세션 관리자를 사용해 RDS 뒤에 있는 기저 EC2 인스턴스에 엑세스할 수 있다.
- RDS 커스텀을 사용하려면 자동화, 유지관리, 스케일링 같은 작업을 하지 않도록 자동화를 꺼두는게 좋다.
- 기저 EC2 인스턴스에 접근이 가능해 문제가 쉽게 발생할 수 있어 스냅샷을 생성하는 것이 좋다.
Amazon Aurora
- AWS의 고유 기술(오픈소스가 아님)
- Postgres와 MySQL와 호환되기 때문에 해당 DB를 연결하면 작동함.
- 클라우드에 최적화되어 있음 (RDS의 MySQL, Postgres의 각각 5배, 3배 높은 성능)
- 공유 스토리지 볼륨 자동 확장. 10GB에서 시작하여 자동으로 128TB까지 확장 가능.
- MySQL에서는 5개만 가능했던 읽기전용 복제본이 15개까지 가능하며 복제 속도도 빠름.
- 비용은 RDS에 비해 약 20% 높음. 하지만 스케일링 측면에서 훨씬 효율적이라 비용을 절감할 수도 있음.
- 3개의 AZ에 걸쳐 무언가를 기록할 때마다 6개의 사본을 저장함.(높은 가용성)
👉 쓰기에는 6개 사본 중 4개만 있으면 됨 (=하나의 AZ에서 작동하지 않아도 괜찮음)
👉 읽기에는 6개 사본 중 3개만 있으면 됨 - 일부 데이터가 손상되면 백엔드에서 P2P 복제를 통한 자가복구가 진행됨
- 단일 볼륨에 의존하지 않고 수 백 개의 볼륨을 사용함(사용자가 관리X)
- 정의된 커스텀 엔드포인트로 읽기클러스터의 부분집합(다른 종류의 인스턴스 타입)을 다른 용도(ex 분석 쿼리 처리용도)로 사용할 수 있다.
- 자동화 오토스케일링으로 용량 계획이 필요없고 사용한만큼 비용을 지불할 수 있다.
Aurora는 RDS의 다중 AZ와 유사하다
- 쓰기를 받는 인스턴스는 하나(마스터). DNS 이름으로 항상 마스터를 가르키는 Writer Endpoint를 제공한다.
- 마스터가 작동하지 않으면 평균 30초 이내로 장애 조치가 시작된다.
- 읽기 복제본은 15개까지 생성 가능(자동 스케일링도 가능)하고 복제본을 많이 둬 읽기 워크로드를 스케일링 할 수 있다. Reader Endpoint가 모든 읽기 전용 복제본과 자동으로 연결되어 로드밸런싱을 지원한다.
- 마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체함.
- 복제본들은 리전간 복제를 지원한다.
Aurora 생성 실습
- RDS 생성 시 Aurora를 선택한다.
- Availability & durability 에서 다중 AZ 설정을 할 수 있는데 이때 Create an Aurora Replica or Reader node in a different AZ를 선택하면 Aurora replica나 다른 AZ의 리더 노드를 생성하게 된다. 개선된 가동률과 AZ, 고속 장애조치(failover)를 더 잘 읽도록 해준 다.
- 네트워크 타입은 IPv4로 하되 VPC에 IPv6가 있다면 Dual-stack mode를 사용해도 된다.
- Read replica write forwarding에서 '로컬 쓰기 전달'을 켤 수 있다. 쓰기는 읽기 전용 복제본에 적용되어, 쓰기 인스턴스로 자동적으로 전달된다.
- 다른 설정을 마치고 생성을 완료한다.
- 생성 시 비용이 발생한다.
- Aurora를 생성하면 쓰기인스턴스와 읽기인스턴스가 한 묶음으로 생성되는데 이들은 AZ도 다르다. 엔드포인트도 read,write의 엔드포인트가 따로 생성된다.
Aurora 기타 실습
- reader클러스터에 reader를 추가하고싶으면 Actions > Add reader를 하면 된다.
- 다른 리전에 복제본을 만들려면 Actions > Create cross-Region read replica를 선택한다. 재해복구에 도움되고 실행하기 간단하다.
- 시간에 맞춰 포인트를 되돌리고 싶으면 Actions > Restore to point in time을 선택한다.
- 복제본 오토스케일링을 원하면 Actions > Add replica auto scaling을 선택한다. 타겟 지표와 타겟 값을 설정해 오토스케일링 할 수 있다.
Aurora에서의 오토스케일링
✔ Aurora Standard(Provisioned) 모드에서는 Read Replica가 자동으로 늘어나거나 줄어들지 않음.
✔ Aurora Serverless를 사용해야만 완전한 오토스케일링이 가능함.
✔ Provisioned 모드에서도 Auto Scaling 정책을 설정(Add replica auto scaling)하면 자동 추가는 가능하지만 자동 감소는 안 됨. 🚀 - Actions > Add AWS Region을 선택해 데이터베이스 리전을 다른 리전에 추가할 수 있다. 클로벌 클러스터로 호환되는 사이즈의 인스턴스가 필요하다.
- 삭제하려면 reader인스턴스를 먼저 삭제 > writer인스턴스 삭제 > 클러스터(DB) 전체 삭제가 가능하다.
Aurora Global DB(추천)
- 모든 읽기, 쓰기가 일어나는 1개의 기본 리전이 있다.
- 최대 5개의 보조 읽기 전용 리전을 만들 수 있다. (응답지연 1초 이하)
- 보조 리전 당 최대 16개의 읽기 전용 복제본을 사용할 수 있다.
- 한 리전에 데이터베이스가 멈출 경우 재해 복구를 위해 다른 리전을 진급시킨다. 복구시간이 1분 이내이다.
- 평균적으로 다른 리전으로 데이터를 복제하는 데에 1초 이하의 시간이 걸린다.
Aurora 머신러닝
- SQL 인터페이스를 통해 응용프로그램에 기계 학습 기반의 예측을 추가할 수 있다.
- SageMaker(어떤 ML모델도 사용할 수 있게함)와 Comprehend(감정분석)을 지원한다.
- 이상 행위 탐지, 광고 타겟팅, 감정 분석, 상품 추천 등에 이용될 수 있다.
- 애플리케이션에서 SQL 쿼리(ex. 상품 추천)를 Aurora에게 보내면 Aurora는 데이터(ex.사용자 프로필, 구매이력 등)를 SageMaker나 Comprehend로 보내 예측을 받아 반환하는 식이다.
DB 백업
RDS 백업
자동 백업
- RDS 서비스는 데이터베이스 백업 기간동안 자동으로 매일 데이터베이스의 전체 백업을 수행한다.
- 5분마다 트랜잭션 로그가 백업된다. (=자동 백업을 통해 언제라도 5분 전으로 복원할 수 있다.)
- 자동 백업 보존 기간은 1~35일 사이로 설정. 사용하지 않으려면 0으로 설정.
- RDS 인스턴스가 삭제되면 자동 백업도 함께 삭제된다.
수동 백업(DB 스냅샷)
- 사용자가 수동으로 트리거하고 백업을 원하는 기간동안 유지할 수 있다.
- 짧은 기간동안만 사용(ex. 한달에 2시간)하는 RDS라면 DB를 중지해도 스토리지 비용을 지불해야 하는데 스냅샷을 만들어 원래 DB를 삭제하고 스냅샷으로 필요할때 복원한다면 스냅샷 보관 비용이 훨씬 저렴하기 때문에 비용절감이 가능하다.
- RDS 인스턴스를 삭제해도 이 수동 스냅샷은 삭제되지 않고 남아있다.
Aurora 백업
자동 백업
- 1~35일까지 가능하고 비활성화할 수 없음
- 백업기간의 어느 시점으로든 복구 가능
수동 백업(DB 스냅샷)
- RDS의 수동백업과 매우비슷
RDS, Aurora 백업 옵션
- 스냅샷을 통해 복원하면 새 DB(RDS or Aurora)가 생성된다.
- S3에서 MySQL RDS 데이터베이스를 복원할 수 있다.
-> RDS의 경우 온프레미스 데이터베이스의 백업을 생성한 다음 객체 스토리지인 S3에 배치하여 RDS에서 S3에 위치한 백업파일을 복원하는 옵션을 선택한다.
-> Aurora의 경우 온프레미스 데이터베이스를 Percona XtraBackup을 사용해 다시 백업. 백업 파일을 S3로 보내 백업을 복원할 수 있음.
Aurora 데이터베이스 복제
- 처음 복제 시 원래 DB와 같은 볼륨을 공유하고 이후 업데이트가 발생하면 그때 새로운 추가 스토리지가 할당되고 데이터가 복사 및 분리됨. 그래서 복제가 DB 복원에 비해 매우 빠름.
데이터베이스 복제본(Aurora Replica)을 만들면, 원본 DB가 삭제되거나 장애가 나더라도
→ 복제본을 독립적으로 보관할 수 있어 장기 백업처럼 활용 가능.
→ 원본이 손상되었을 때, 즉시 읽기 전용 복제본을 승격(Promotion)해서 복구 가능
RDS, Aurora 보안
- KMS를 사용해 마스터와 모든 복제본의 암호화가 이루어진다. (DB 첫 실행시 정의됨)
- 마스터 DB를 암호화 하지 않았다면 읽기 전용 복제본을 암호화 할 수 없음
- 암호화 되지 않은 DB를 암호화하려면 스냅샷으로 복원시 암호화 가능
- 클라이언트와 DB간 전송 중 데이터 암호화가 기본적으로 지원됨
-> 따라서 클라이언트는 AWS의 TLS 루트 인증서를 사용해야함. - 유저이름/비밀번호 대신 IAM Roles를 사용해 DB에 접속할 수 있음.(ex EC2인스턴스가 RDS에 접속할 수 있는 권한(IAM Role)을 부여받으면 접속가능)
- 보안그룹으로 네트워크 엑세스를 정의 가능
- 감사 로그 작성을 활성화하면 로그 확인 가능. 로그는 시간이 지나면 자동삭제됨. 장기간 보관을 원하면 AWS의 CloudWatch Logs를 사용.
RDS Proxy
- VPC 내에 완전 관리형 RDS 데이터베이스 프록시도 배포할 수 있다.
- RDS 프록시를 사용하면 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있다.
- 애플리케이션을 RDS 데이터베이스 인스턴스에 일일이 연결하는 대신 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아 RDS 데이터베이스 인스턴스로 가는 연결이 줄어든다.
- RDS 데이터베이스 인스턴스에 연결이 많은 경우 프록시를 통해 CPU와 RAM등 데이터베이스 리소스의 부담을 줄여 데이터베이스 효율성을 향상시킬 수 있고 데이터베이스에 개방된 연결과 시간초과를 최소화할 수 있다.
- 완전한 서버리스로 오토스케일링이 가능해 용량을 관리할 필요가 없다.
- 다중 AZ를 지원한다
- 장애가 발생하면 메인 RDS 인스턴스에 연결된 각 애플리케이션들이 각자 장애조치를 하는 대신 장애조치와 무관한 RDS 프록시에 연결해 프록시가 장애조치가 발생한 RDS 인스턴스를 처리하므로 장애조치 시간이 66% 개선됨
- MySQL, PostgreSQL, MariaDB용 RDS와 Aurora를 지원한다.
- 애플리케이션의 코드를 변경하지 않아도 되며 RDS나 Aurora인스턴스에 연결하는 대신 RDS 프록시에 연결하면 됨.
- IAM인증을 통해서만 RDS 데이터베이스 인스턴스에 연결하도록 할 수 있음. 자격 증명은 AWS Secrets Manager에 저장됨.
- RDS 프록시는 퍼블릭 엑세스가 절대로 불가능함 (VPC를 통해서만 접근)
- Lambda함수 서비스에서 사용하면 유용함. Lambda 함수는 많은 수가 생겼다가 사라지는데 이때마다 DB연결을 하면 응답시간에 문제가 생길 수 있는데 이를 해결해줌.
ElastiCache
- RDS가 관계형DB를 관리하는 것과 같은 방식
- 캐싱 기술인 Redis 또는 Memcached를 관리할 수 있도록 도와줌
캐시는 매우 높은 성능과 짧은 지연 시간을 가진 인메모리 데이터베이스. 읽기 집약적인 워크로드에서 데이터베이스의 로드를 줄여준다.
- 일반적인 쿼리는 캐시에 저장되므로, 매번 데이터베이스를 쿼리하지 않아도 된다. 캐시만 사용해 쿼리의 결과를 검색할 수 있다.
- 애플리케이션의 상태를 ElastiCache에 저장해 애플리케이션을 비저장형으로 운영할 수 있다.
- ElastiCache를 사용할 경우 애플리케이션의 코드를 DB쿼리 전,후를 캐시를 쿼리하도록 바꿔야 함.
ElastiCache를 사용하기 위한 아키텍쳐
DB 캐시 아키텍처
가정: ElastiCache, RDS DB, 애플리케이션이 존재
1) 애플리케이션은 쿼리가 이미 발생했는지 확인을 위해 ElastiCache를 쿼리한다.
2) 이미 쿼리가 발생해 ElastiCache에 저장되어 있으면 캐시 히트. 바로 ElastiCache에서 답을 반환 (DB조회 불필요)
3) 캐시 미스면 애플리케이션이 DB에서 데이터를 가져온다.
4) 다른 애플리케이션이나 다른 인스턴스에서 같은 쿼리가 발생하면 데이터를 캐시에 다시 쓸 수 있다. 다음에 동일 쿼리가 발생하면 캐시 히트.
- 캐시 무효화 전략이 있어야 한다. 가장 최신 데이터만 사용되어야 하기 때문. (가장 어려운 점)
사용자 저장 세션 아키텍처
1) 사용자가 어떤 애플리케이션에 로그인하면, 애플리케이션이 세션 데이터를 Amazon ElastiCache에 쓴다.
2) 사용자가 애플리케이션의 다른 인스턴스로 리디렉션되면, 애플리케이션은 그 세션의 세션 캐시를 ElastiCache에서 직접 검색할 수 있기에 사용자는 여전히 로그인 상태이다.
즉 애플리케이션을 상태 비저장형으로 만든다!
Redis vs Memcached vs Valkey 비교
Redis (복제를 통한 내구성, 가용성👍)
- 자동 장애 조치 기능이 있는 다중AZ가 있고, 읽기 복제본이 있음.
- 읽기를 확장하고 고가용성을 가지려면 RDS와 매우 유사하다.
- AOF 지속성을 이용한 데이터 내구성이 있고 백업 및 복원 기능이 있다.
Memcached (분산되어 있는 순수한 캐시)
- 데이터 분할을 위해 멀티 노드 사용(=sharding)
- 고가용성이 없고 복제가 일어나지 않으며 영구캐시가 아님
- 백업, 복원이 없음
- 멀티스레드 아키텍처
Valkey
- 'AWS, Ericsson, Google Cloud, Oracle, Verizon' 등의 기업들이 Redis의 오픈소스 라이선스 변경에 반발하여 만들어짐
Redis에서 오픈소스 라이선스를 BSD 라이선스에서 SSPL이 포함된 듀얼라이선스 체계로 변경했다. 개발자들이 redis를 설치해서 사용하고, redis client library를 활용하는 데는 문제가 안되지만 경쟁 클라우드 업체에서 redis를 상업적으로 제공하는데 어려움이 생긴다.
- Redis OSS API 및 데이터 형식과 호환.
- 자동 확장, 다중 AZ 배포를 통한 고가용성, 지역 간 복제 등의 기능을 활용하여 비즈니스 연속성과 재해 복구를 보장
- AWS에서 Valkey를 33%할인해 제공하고 있으며 프리티어 또한 제공된다.
참고: Valkey란?, Amazon ElastiCache Valkey 시작하기
ElastiCache 실습
1. ElastiCache에서 생성하고 싶은 캐시 타입을 선택한다.
2. 클러스터 세팅하기
자체 캐시를 설계할 수 있고 서버리스를 선택할 수도 있다.
서버리스는 훨씬 비싸지만 관리하기 쉽다.
(여기서는 자체 캐시 설계)
생성 옵션으로 간편한 생성 / 클러스터 캐시(직접 모든 설정)/ 백업에서 복원 중 선택하여 ElastiCache를 만들 수 있다.
간편 설정을 선택하면 클러스터의 노드 유형과 기본 구성을 프로덕션 / 개발, 테스트 / 데모 중 선택할 수 있다.
클러스터 모드를 활성화하면 여러 서버에 여러 샤드를 설치하고, 비활성화하면 프라이머리 노드 하나와 최대 5개의 읽기 전용 복제본을 포함하는 단일 샤드가 있는 상태로 만든다.
장소는 AWS, 온프레미스 중 고를 수 있다.
다중AZ를 활성화하면 고가용성 장애조치에 유용하지만 더 많은 비용이 발생한다.(여기선 비활성화)
다중AZ를 비활성화 하면 자동 장애 조치를 활성화할지 선택할 수 있다.(여기선 활성화)
노드 타입은 프리티어에서는 t2마이크로와 t3마이크로만 지원하니 주의해서 선택한다.
복제본 개수는 클러스터 모드에서 확장할 때 유용한데 지금은 비용목적으로 0으로 둔다.
프리티어 참고
서브넷까지 설정하면 AZ배치에서 각 AZ에 어떤 복제본이 배치될지 지정할 수 있다. 지금은 다중AZ를 비활성화 했기 때문에 그냥 넘어간다.
3. 추가 설정하기
저장 데이터 암호화를 원하는지 선택하고, 선택했다면 키를 지정해야 한다.
전송 중 데이터 암호화도 활성화 할 수 있고, 활성화 하면 엑세스 제어기능이 제공된다. 캐시에 엑세스 할 수 있는 것으로 토큰이나 사용자 그룹 중 선택하면 된다.(여기선 비활성화)
보안그룹을 설정해 네트워크 측면에서 클러스터에 어떤 어플리케이션이 엑세스할 수 있는지를 관리할 수 있다.
그 아래로는 원하는 대로 설정하면 된다.
4. 생성을 완료
애플리케이션에서는 Primary endpoint를 이용해 접속하면 되고, 읽기전용 복제본이 있다면 Reader endpoint를 사용해 캐시에서 읽을 수 있다.
ElastiCache 보안
- ElastiCache는 Redis에서만 IAM인증을 지원한다. 나머지 경우에는 사용자 이름과 비밀번호를 설정해서 사용한다.
- IAM 정책을 정의하면 AWS API수준 보안에만 사용된다.
Redis AUTH
- Redis 클러스터를 만들 때 Redis내 보안을 위해 비밀번호와 토큰을 설정할 수 있다.(보안그룹에 추가로 보안 수준 제공)
- SSL 전송 중 암호화 지원
Memcached
- SASL 기반 승인을 제공한다.
ElastiCache의 데이터로드 패턴
1) 지연로딩(Lazy loading) : 모든 데이터가 캐시되고 데이터가 캐시에서 지체될 수 있다. 캐시 미스일 경우에만 데이터를 DB(RDS)에서 ElastiCache에 로드한다.
2) Write Through : 데이터베이스에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트하는 것
3) Session Store : 유지 시간 기능을 사용해 세션을 만료할 수 있다.
Redis의 Sorted sets으로 실시간 리더보드를 애플리케이션측에서 프로그래밍하지 않고서도 Redis를 활용해 엑세스 할 수 있다.
중요 포트 정리
일반적인 서비스 포트
| 서비스 | 포트 |
|---|---|
| FTP | 21 |
| SSH | 22 |
| SFTP | 22 (SSH와 동일) |
| HTTP | 80 |
| HTTPS | 443 |
RDS 데이터베이스 포트
| 데이터베이스 | 포트 | 비고 |
|---|---|---|
| PostgreSQL | 5432 | |
| MySQL | 3306 | |
| Oracle RDS | 1521 | |
| MSSQL Server | 1433 | |
| MariaDB | 3306 | MySQL과 동일 |
| Aurora | 5432 (PostgreSQL 호환) / 3306 (MySQL 호환) |
