rds
RDS 에 대해 알아보겠습니다
엔진에는 PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server 가 있습니다. 관리형 데이터베이스죠. 서버를 프로비저닝하고 인스턴스 유형을 선택한 다음, 자동화된 백업, 패칭, 모니터링 등에서 많은 것을 얻게 됩니다.
RDS 데이터베이스는 보통 VPC 내의 프라이빗 서브넷에서 실행되고, 보안 그룹을 통해 데이터베이스에 대한 액세스 를 제어할 수 있는데요. 이때 유의해야 할 점은 RDS 데이터베이스에 액세스 하려고 하는 Lambda 함수가 있는 경우 RDS 데이터베이스와 통신할 수 있도록 프라이빗 VPC 서브넷으로 실행해야 합니다.
EBS의 스토리지는 GP2 또는 io1의 형태로 제공되며, 오토 스케일링을 통해 자동으로 볼륨을 증가시킬 수 있는 옵션이 있는데요, 성능이 충분한 경우 GP2 볼륨을 사용할 수 있죠. 하지만 높은 IO 요구 사항을 가지고 있는 경우, io1을 선택하는 것이 더 좋을 수 있습니다, 다음은 백업입니다
지정 시간 복원으로 자동화되어 백업이 만료되는데요, 스냅샷도 매우 유사하지만 수동으로 이루어지죠, 이 경우 백업을 수행하여 원하는 기간 동안 오래 보관할 수 있습니다. 스냅샷을 생성하여 리전에 걸쳐 복사하면 재해 복구가 필요할 때 무척 유용할 겁니다. RDS 는 또한 데이터베이스에 일어나는 일에 관해 많은 이벤트를 게시합니다.
RDS 의 모든 이벤트를 포함하는 SNS 주제를 얻을 수 있는데 이를 RDS 이벤트 알림이라고 하죠, 작업이나 중단 백업 시작 시기 등에 대해 알림이 제공됩니다.
RDS — Multi AZ & Read Replicas
여러분이 알아야 할 또 다른 개념에 대해 말씀드리겠습니다.
그것은 바로 다중 AZ 로, 중단이 발생한 경우 장애 조치에 관한 대기 인스턴스를 말하죠. 1개의 가용 영역에 마스터 RDS 데이터베이스가 있는데, 이는 다른 AZ 의 다른 대기 인스턴스에 동기식으로 복제됩니다. 즉, AZ-B 가 되는데요, 애플리케이션은 1개의 DNS 이름을 통해 RDS 데이터베이스에만 액세스할 수 있으며, 해당 DNS 이름은 장애 조치 시 자동으로 변경 되죠.
다시 말해, 애플리케이션은 대기 데이터베이스에 결코 액세스하지 않습니다, 오직 마스터 데이터베이스만 액세스하는 거죠. 마스터 인스턴스에서만 직접 읽기와 쓰기가 발생하는데요 다중 AZ는 중단 발생 시 복구를 위해 마련된 것이죠, 백업 데이터베이스이며, 대기 데이터베이스입니다, 하지만 애플리케이션은 이것을 결코 사용하지 않습니다.
읽기를 확장 하려면 읽기 전용 복제본을 사용하면 됩니다.
이 읽기 전용 복제본은 비동기 복제 이므로 최종 일관성을 갖게 되는데요, 교차 리전이 될 수 있기 때문에 복제본을 사용하여 AWS 에 있는 여러 리전의 대기 시간을 줄일 수 있죠.
따라서 RDS 인스턴스는 또 다른 RDS 읽기 전용 복제본에 대해 비동기 복제를 갖게 되며, 이때 리전은 동일할 수도 다를 수도 있습니다, 애플리케이션을 주요 RDS 데이터베이스에 대한 읽기와 쓰기를 실행하지만 읽기 전용 복제본에서만 읽기를 실행할 수 있기도 하죠. 이러한 이유로 이것을 읽기 전용 복제본이라고 하는 겁니다.
RDS — Distributing Reads across Replicas
읽기 전용 복제본을 갖게 되면 애플리케이션의 읽기를 배포하고 어떤 애플리케이션 로직을 제거해야 할 수도 있는데요, 이 경우 Route 53 을 사용해야 하죠. Route 53을 사용하여 가중치 기반 레코드 세트를 생성할 수 있습니다. 잘 아시겠죠?
이 예시의 경우, 모든 읽기 전용 복제본 엔드 포인트의 가중치를 25%로 설정했는데, 원하는 대로 설정이 가능합니다. 하지만 모든 복제본이 동일한 사양을 갖고 있다면 동일한 가중치를 설정하는 것이 좋죠.
Amazon Route 53 내에서 상태 확인을 활성화할 수 있는데요, 이렇게 하면 RDS 읽기 전용 복제본에 문제가 발생한 경우 레코드에 포함하지 않게 됩니다. 따라서 애플리케이션이 Route 53 에 요청할 때마다, 가령 천 개의 애플리케이션이 이 작업을 하고 있다면 각 요청은 각 복제본에 대해 25%씩 분산될 겁니다.
RDS — Security (reminder)
보안으로 넘어가 보죠.
KMS 암호화를 기본 EBS 볼륨 및 스냅샷에 대해 사용할 수 있습니다. Oracle과 SQL Server 에 대해 투명한 데이터 암호화(TDE)를 지원 하는데요. 데이터베이스 전송 중 호출을 위해 RDS 에 대한 SSL 암호화를 적용하고 이를 시행할 수 있죠.
IAM 인증은 MySQL, PostgreSQL, MariaDB에 대해 잘 작동합니다.
IAM 으로 인증받았더라도 여전히 RDS 내에서 인증이 발생하기 때문에 사용자가 RDS 데이터베이스 내에서 할 수 있는 것과 할 수 없는 것을 정의해야 하는데요. IAM 은 이 같은 작업을 지원하지 않죠.
암호화된 스냅샷을 생성할 수 있습니다. 암호화된 RDS 스냅샷을 비 암호화된 RDS 스냅샷에서 생성할 수 있는데요. 즉, 암호화되지 않은 데이터베이스를 스냅샷 과정을 통해 암호화할 수 있다는 뜻입니다, CloudTrail 의 경우 RDS 내에서 만든 쿼리를 추적하는 데 사용할 수 없다는 점에 유의해야 하죠.
RDS — IAM Authentication
RDS IAM 인증에 대해 좀 더 자세히 살펴볼까요, MariaDB, MySQL, PostgreSQL 에 대해 사용할 수 있으며 IAM 인증을 사용하는 경우, 비밀번호가 필요 없으며 RDS API 호출을 통해 얻은 인증 토큰만 있으면 됩니다.
토큰의 수명은 15분이라는 점에 유의해야 하는데요, 토큰은 데이터베이스에 연결하는 목적으로만 사용되므로 특별한 문제는 없을 겁니다. 다시 연결하려면 새 인증 토큰을 얻어야 하고요. 어떻게 작동하는지 알아보겠습니다.
적절한 IAM 역할이 있는 EC2 인스턴스를 통해 AWS 에 대한 API 호출을 수행하여 RDS 서비스에서 인증 토큰을 얻을 수 있다고 가정해 보죠. 그런 다음 SSL 암호화 연결에서 인증 토큰을 사용하여 데이터베이스에 연결할 수 있는데요 물론 보안 그룹은 반드시 적절하게 구성되어야 합니다. 이점은 암호화된 SSL 트래픽만 받을 수 있다는 것이죠.
데이터베이스 내에서 사용자를 관리하는 대신, IAM을 사용하여 중앙에서 관리할 수 있으며 IAM 역할과 EC2 인스턴스 프로파일을 활용하여 매우 쉽게 통합할 수 있습니다.
About RDS for Oracle — Exam Tips
다음으로 Oracle 에 대한 RDS 특이성 중 백업에 대해 알아볼까요?
Oracle 데이터베이스를 백업하는 데 2가지 방법이 있습니다. RDS 백업과 Oracle RMAN 라고 하는 방법인데요.
백업은 Oracle 용 Amazon RDS 로 백업 및 복원하는 데 사용됩니다, 반면 Oracle Recovery Manager 는 비 RDS로 백업하고 복원하죠. RDS 가 지원되지 않거든요. 그래프를 살펴볼까요?
RDS 백업은 RDS 데이터베이스 인스턴스의 백업이 되며 RDS 데이터베이스 인스턴스로만 복원됩니다. 반면에 RMAN 은 RDS 데이터베이스 인스턴스의 백업을 수행할 수 있지만 복원은 외부 Oracle 데이터베이스에 대해서만 발생하죠.
RDS 데이터베이스 인스턴스에 대해서는 발생하지 않습니다.
흐름은 Oracle 의 RDS 데이터베이스 인스턴스에서 AWS 백업으로, 그리고 Oracle의 RDS 데이터베이스 인스턴스로 이어지는데요. 또는 Oracle의 RDS 데이터베이스 인스턴스에서 RMAN 백업, Amazon S3를 거쳐 RDS 외부에 있는 외부 Oracle 데이터베이스로 진행됩니다. 이제 Real Application Cluster(RAC)라는 것이 없기 때문에 Oracle용 RDS는 RAC를 지원하지 않죠.
RAC 는 EC2 인스턴스의 Oracle에서만 작동합니다, EC2 인스턴스에 설정하면 Oracle을 완전히 제어할 수 있거든요.
Oracle은 스토리지에 작성되기 전에 데이터를 암호화하는 TDE를 지원하는데요, DMS도 Oracle에서 작동하기 때문에 클라우드로 복제하려는 Oracle 데이터베이스를 온프레미스로 수행할 수 있죠. 그렇게 하려면 DMS를 사용하여 온프레미스로 Oracle 데이터베이스에서 클라우드로 데이터를 복제하고 마이그레이션하면 됩니다.
About RDS for MySQL
기본 mysqldump 도구를 사용하여 MySQL 데이터베이스를 비 MySQL 데이터베이스로 마이그레이션 할 수 있는데요. 그렇게 하려면 RDS 가 아닌 외부 데이터베이스를 데이터 센터에서 온프레미스로 실행하거나, 직접 실행할 수 있습니다.
가령, Amazon EC2 인스턴스에서 실행할 수 있습니다. 클라우드에 RDS MySQL 데이터베이스 인스턴스가 있으며, 대상은 온프레미스라고 치죠, DB Admin 으로서 mysqldump 도구를 사용하여 데이터를 내보내고, 원하는 곳으로 다시 가져옵니다. 그런 다음 복제 메커니즘을 2개 데이터베이스 사이에서 시작하여 데이터를 동기화하고 복제가 완료되면, 복제를 중단하고 소스 데이터베이스를 중단합니다.
RDS Proxy for AWS Lambda
RDS 의 또 다른 기능은 AWS Lambda용 RDS 프록시인데요.
RDS 를 통해 Lambda 함수를 사용하면 데이터베이스 연결을 열고 유지할 수 있죠. 동시에 실행한 Lambda 함수가 많은 경우, TooManyConnections 예외가 지나치게 많이 발생할 수 있습니다 RDS 프록시를 사용한다면 대기 상태의 연결을 정리하거나 커넥션 풀을 관리하는 코드가 더 이상 필요 없죠, 이 모든 것은 프록시 자체가 수행하니까요.
RDS 프록시는 IAM 인증이나 데이터베이스 인증, 오토 스케일링을 지원하는데요. Lambda 함수가 프록시와 연결되어 있는지 확인해야 합니다, 연결을 위해 퍼블릭 프록시와 퍼블릭 Lambda, 또는 프라이빗 프록시와 VPC의 Lambda를 가지고 있어야 하죠. 다이어그램을 통해 살펴보겠습니다.
Aurora 데이터베이스 클러스터가 있다고 가정해 볼까요.
프라이빗 서브넷에 RDS 프록시를 생성하고, 퍼블릭 서브넷의 경우 현재 공개적으로 작동하고 있는 Lambda 함수는 IAM을 통해 RDS 프록시에 액세스할 수 있으며, 이에 따라 Aurora 데이터베이스 클러스터에 액세스하게 되죠.
RDS Solution Architecture Cross Region Failover
마지막으로 앞서 다뤘던 솔루션 아키텍처를 짚어 보겠습니다, 바로 RDS를 통해 교차 리전 장애 조치를 수행하는 방법인데요.
데이터베이스 상태를 점검해야 하는데, 이때 /health-db route 가 있는 인스턴스나 CloudWatch 알람을 사용할 수 있습니다. 이러한 것은 Route 53 상태 확인이 점검하게 되죠.
상태 확인은 CloudWatch 알람과 연결되어 있으며, CloudWatch 이벤트를 트리거할 겁니다. 이 CloudWatch 이벤트는 Lambda 함수를 트리거하는데, 이 함수의 역할은 데이터베이스에 대한 Route 53 DNS 를 업데이트하고 다른 리전에 있는 읽기 전용 복제본을 승격하는 것이죠, 이 예시 에서는 미국 서부(오리건)(us-west-2)라고 하겠습니다.
이 인스턴스에는 교차 리전 복제가 있으며, 이렇게 교차 리전 장애 조치 아키텍처를 효과적으로 만들게 되었습니다.
