앱에서 데이터베이스 인스턴스에 읽기와 쓰기를 수행할 때 인스턴스가 충분히 확장될 수 없어 읽기를 확장하고자 할 때 동일한 AZ영역이나 교차 AZ영역, 교차 구역에 최대 5개의 Read Replica를 생성할 수 있음 또 다른 RDS 인스턴스 Read Replica가 두 개 더 있다고 하면 메인 RDS 데이터베이스 인스턴스와 그 두 개의 Read Replica 사이에 비동기식 복제가 적용되어 읽기가 궁극적으로 유지됨 만약 복제본 중 하나를 선택한다면 이것은 데이터베이스가 되고 복제 메커니즘에서 벗어나 자신만의 라이프 사이클을 갖게 됨
RDS에 있는 모든 Read Replica 리스트를 사용하고자 하는 경우 메인 앱이 연결 문자열을 업데이트해야 함
RDS Read Replicas – Use Cases
정상 로드를 받는 생산 엡이 있을 때, 이 데이터베이스는 메인 RDS 데이터베이스 인스턴스로 읽기와 쓰기를 가짐 그 때 새로운 팀이 들어와서 데이터 위에 몇 가지 보고와 분석을 하고 싶다면 과부화되어 생산 앱의 속도를 저하시킬 수 있음 이럴 때 새로운 워크로드를 실행하는 Read Replica를 생성하여 메인 RDS 데이터베이스의 인스턴스와 Read Replica 사이에 비동기식 복제가 적용되고 분석 앱은 그저 Read Replica로부터 읽기를 하고 분석을 실행하면 됨 이 경우 생산 앱은 영향을 완전히 받지 않을 수 있음
기억해야 할 것은 Read Replica의 경우 반드시 SELECT 타입의 명령만을 수행하므로 오직 Read만 가능 (INSERT, UPDATE, DELETE 등의 키워드는 사용할 수 없음)
RDS Read Replicas – Network Cost
AWS에서는 일반적으로 데이터가 어떤 AZ영역에서 다른 AZ영역으로 넘어갈 때 비용이 발생함
반면 관리형 서비스의 경우 예외에 해당하여 관리형 서비스인 RDS Read Replica의 경우 동일한 리전 내의 RDS 읽기 전용 복제본의 경우 해당 요금을 지불하지 않음 영역(리전)을 가로지르는 복제를 가질 경우 그 네트워크에 대한 복제 비용이 발생
RDS Multi AZ (Disaster Recovery)
Multi AZ는 주로 재해 복구를 위해 사용
AZ A영역에 있는 Master DB 인스턴스로 읽기와 쓰기를 행하고 AZ B에 있는 standby 인스턴스로 동기식 복제를 갖게 될 때 Master 인스턴스의 모든 변화를 동시에 복제하게 됨 즉, Master로 쓰기가 발생할 때 이를 위해서 그 변화가 standby에도 복제되어야 하며 이로부터 도출하는 것이 DNS name Master에 문제가 생기는 경우에는 DNS name으로 인해, standby 데이터베이스에 자동적인 장애 조치가 발생되어 가용성이 증가하고 standby 데이터베이스는 새로운 Master 데이터베이스가 됨
AZ 전체가 네트워크를 잃거나 Master 데이터베이스 인스턴스나 스토리지 오류가 발생하는 경우 장애 조치가 발생
확장을 위해 사용되지 않으며 standby 데이터베이스는 standby만의 것이며 읽기, 쓰기 모두 불가능 단지 Master 데이터베이스에 무슨 일이 생길 것을 대비하기 위한 장애 조치일 뿐임
또한 원한다면 Read Replica를 Multi AZ로 셋업할 수 있음
RDS – From Single-AZ to Multi-AZ
RDS를 Sing AZ에서 Multi AZ로 가기 위해서는 Zero Downtime 작동이므로 데이터베이스를 멈출 필요가 없음
단지 데이터베이스에 대한 modify를 누르고 Multi AZ를 작동시킴
이 경우 RDS 데이터베이스 인스턴스가 Master를 가질 것이며 standby DB 사이에서 동기적 복제가 적용됨
메인 데이터베이스 RDS로부터 자동적으로 도출되는 스냅샷을 이용해 새로운 standby 데이터베이스에 저장하면 두 데이터베이스 사이에 동기적 복제가 형성되고 Multi AZ 셋업이 되는 것
<Amazon RDS 실습>
RDS를 사용해 데이터베이스 생성 모든 옵션을 이용하는 표준 생성과 과정이 신속한 손쉬운 생성이 존재하며 표준 생성을 통해 생성
엔진 유형에는 Aurora, MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server가 존재하며 MySQL을 사용
MySQL에는 여러 옵션이 존재하며 사용 사례에 맞게 지정할 수 있는 템플릿이 존재하고, 특정 구성에 대한 구성 매개변수가 지정되어 있기도 함 (프로덕션, 개발/테스트, 프리티어) 프로덕션을 선택하고 데이터베이스 식별자 이름을 database-1로 설정하고 마스터 사용자 이름과 비밀번호를 admin, password로 설정
이후 데이터베이스 클래스로 원하는 vCPU, RAM, 네트워크 속도를 제공하는 인스턴스 유형을 선택 프리티어를 사용할 수 있어야 하므로 Burstable 클래스로 고른 후 dbt2.micro를 선택
스토리지의 경우 gp2를 고른 후 프리티어 내에 있기 위해 범용 SSD 유형인 gp2 선택 스토리지 오토 스케일링을 활성화하면 데이터베이스 스토리지에 동적 스케일링이 지원되어 스토리지 사용량이 증가하여 20GB에 가까워지면 다른 작업 없이 자동으로 증가하게 되고, 반대로 감소하기도 함
아주 중요한 가용성과 내구성에 대해서는 프로덕션 템플릿을 선택하며 기본적으로 다중 AZ로 설정되어 있지만 비활성화 다중 AZ를 활성화하면 RDS 데이터베이스에 대한 스탠바이 인스턴스를 갖게 되고 생산에 있어서 권고되는 사항으로 데이터 중복에 대하여 스탠바이 인스턴스가 제공되어 I/O 동결 시 백업으로 이용되거나 백업 도중 지연 시간의 급증을 최소화, 메인 인스턴스에 문제가 생기거나 리부팅이 필요할 때를 대비해서 존재
네트워크 셋팅에서 기본 서브넷을 사용하며, 퍼블릭 액세스는 허용하도록 하여 데이터베이스를 공개적으로 테스트하도록 하며 VPC 보안 그룹은 demo-database-mysql이라는 이름으로 새로 생성
데이터베이스 인증에는 세 가지 옵션이 있는데 1) 암호 인증 2) 암호 및 IAM 데이터베이스 인증 3) 암호 및 Kerberos 인증 가장 간단한 옵션인 비밀번호 인증으로 사용
추가 구성으로는 초기 데이터베이스의 이름 지정이 가능하므로 mydb로 설정하고 백업의 경우 보관 기간을 0에서 35일 중에서 7일로 설정 지표를 위해 Enhanced 모니터링을 설정하고 CloudWatch 로그로 로그를 내보낼 수 있으며, 감사 로그, 에러 로그, 일반 로그, 느린 쿼리 로그 옵션이 존재 유지 관리에서는 오토 마이너 버전 업그레이드를 활성화하도록 하며 이에 대한 유지 보수 기간을 설정할 수 있음 또한 데이터베이스를 실수로 삭제할 때를 대비해서 삭제 보호 기능을 활성화하여 RDS 생성
생성된 데이터베이스 엔드포인트과 3306 포트가 나와 있고 보안 그룹에 연결된 상태 보안 그룹을 누르면 인바운드 규칙이 나오는데 TCP와 포트가 3306임을 확인할 수 있음
Sqlectron을 이용해 엔드포인트를 연결하여 새로운 데이터베이스를 추가 RDSDemo로 이름을 지정하고 MySQL 데이터베이스 유형을 입력한 후 Teset를 눌러 연결이 성공적인지 확인 후 연결
표를 생성하기 위해 명령문을 입력하고 생성된 테이블을 클릭한 후 표에 데이터를 입력 후 확인
표 생성생성된 mytable 테이블데이터 입력확인
데이터베이스에 읽기 전용 복제본 생성 콘솔에서 읽기 전용 복제본 생성을 클릭하면 데이터베이스에 대한 읽기 용량이 더 늘어나므로 아주 유용함
모니터링을 보게 되면 데이터베이스에 대한 CPU 사용률이 모니터링되면서 연결이 너무 많은 경우 스케일링이 수행될 수 있고 DB Connections를 통해 데이터베이스에 연결된 클라이언트의 수와 전체 지표 수를 확인할 수 있음 또한 RDS를 사용해 스냅샷을 생성할 수 있어 데이터베이스가 스냅샷으로 저장되어서 원할 때 이를 복구할 수 있으며 지정한 시점에 데이터베이스를 복원하거나 스냅샷을 다른 리전으로 옮기는 작업도 가능함
