SAA-C02 자격증 합격 후기에 이어 공부했던 내용들을 간단하게 다시 정리하고 있습니다.
이번에는 RDS, Aurora, DynamoDB에 대해 알아보겠습니다!
Amazon RDS는 관계형 데이터베이스를 운영 및 확장할 수 있는 관리형 서비스입니다.
주의할 점은 완전 관리형 서비스가 아닌 관리형 서비스이기 때문에, Scaling, 읽기전용 복제본 등의 확장 기능을 사용자가 직접 구축해야 한다는 점입니다.
RDS는 인스턴스 백업 및 복구를 위해 두 가지 방법을 제공합니다.
기본적으로 RDS는 DB 인스턴스를 자동으로 백업하는데요, 이때 보존 기간은 7일입니다.
DB 스냅샷과 자동 백업은 S3에 저장됩니다.
각 DB 인스턴스에 대해 SSL/TLS 인증서를 생성하여 애플리케이션과 DB 인스턴스 간 전송되는 데이터를 암호화할 수 있습니다.
RDS DB에 저장된 데이터를 암호화하려면 KMS를 통해 관리하는 키를 사용하여 암호화할 수 있습니다.
Amazon RDS 암호화된 DB 인스턴스에는 다음과 같은 제한이 있습니다.
다중 AZ 배포에서 Amazon RDS는 서로 다른 가용 영역에 동기식
예비 복제본(Synchronous Standby)을 프로비저닝하고 유지합니다.
다만, 고가용성 기능은 읽기 전용 시나리오의 솔루션과 다르기 때문에, 예비 복제본을 사용하여 읽기 전용 복제본처럼 읽기 트래픽을 지원할 수는 없습니다.
(장애 상황이 발생하여 예비 복제본이 승격되기 전까지는 어떠한 경우에도 예비 복제본을 사용할 수 없습니다.)
Amazon RDS 읽기 전용 복제본은 비동기식
으로 복제되며, 손쉽게 단일 DB 인스턴스를 탄력적으로 확장하여 읽기 중심의 데이터베이스 워크로드를 처리할 수 있습니다.
필요한 경우 읽기 전용 복제본은 독립 실행형 DB 인스턴스로 승격될 수 있습니다.
그리고 읽기 전용 복제본을 만들려면 자동 백업을 활성화해야 합니다.
각 내용을 간단히 비교해보자면 다음과 같습니다.
이 옵션을 활성화하고 시간 단위를 설정하면, 정해진 시간 단위에 따라 주요 지표를 수집하고 정보를 처리할 수 있습니다.
CPU, 메모리, 파일 시스템, 디스크 I/O 등의 인스턴스 지표를 수집하고, 해당 정보를 CloudWatch Logs로 전송하여 CloudWatch에서 CloudWatch Logs의 지표 필터를 생성하여 그래프를 표시할 수 있습니다.
CloudWatch는 하이퍼바이저에서 CPU 사용률에 대한 측정치를 수집하는데 반해, 확장 모니터링은 인스턴스 레벨에서 여러 프로세스, 스레드의 CPU 사용률을 수집합니다.
확장 모니터링 프로세스 목록에 표기되는 지표는 다음과 같습니다.
Amazon Aurora는 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진입니다.
Aurora는 RDS에 포함되는 데이터베이스지만, 보통의 RDS와 다른 특징들을 가지고 있기에 시험에 별도의 데이터베이스로 언급되고 있습니다.
Amazon Aurora 는 전형적으로 단일 인스턴스가 아닌 인스턴스 군을 포함합니다.
각각의 커넥션은 특정한 DB 인스턴스에 의해 관리되고, Aurora Cluster에 접근하면, 호스트 이름과 포트번호로 Endpoint라 불리는 특정 핸들러를 지정받을 수 있습니다.
Aurora에서는 각각의 인스턴스 군이 서로 다른 역할을 가져갈 수 있어서, Endpoint를 사용하면 각각의 커넥션을 역할에 맞는 인스턴스 군으로 매핑할 수 있습니다.
Aurora는 SSL(AES-256)을 사용하여 인스턴스와 애플리케이션 간 연결을 보호합니다.
KMS를 통해 관리하는 키를 사용해 데이터베이스를 암호화할 수 있습니다.
암호화되지 않는 기존 데이터베이스는 암호화할 수 없기 때문에 암호화를 활성화한 새로운 DB 인스턴스를 생성하고, 데이터를 마이그레이션 해야합니다.
기본적으로 위에서 소개한 RDB에서의 암호화 제한과 동일한 스냅샷 암호화 제한 조건을 가지고 있습니다.
Amazon Aurora 병렬 쿼리는 데이터를 별도의 시스템으로 복사할 필요 없이 현재 데이터에 대한 분석 쿼리
를 더 빠르게 제공하는 기능입니다.
핵심 트랜잭션 워크로드의 처리량을 높게 유지하면서, 쿼리 속도를 최대 100배로 높일 수 있습니다.
일부 데이터베이스는 하나 또는 몇 개 서버의 CPU에 걸쳐 쿼리 처리를 병렬화할 수 있지만, 병렬 쿼리는 Aurora의 고유한 아키텍처를 활용하여 Aurora 스토리지 계층에 있는 수천 개의 CPU 전체로 쿼리 처리를 푸시 다운
하여 병렬화합니다.
병렬 쿼리는 분석 쿼리 처리를 Aurora 스토리지 계층으로 오프로딩하여 트랜잭션 워크로드의 네트워크, CPU 및 버퍼 풀 경합을 줄이게 됩니다.
Aurora Serverless는 온디맨드 Auto Scaling 구성입니다.
Aurora Serverless DB 클러스터는 요구 사항에 따라 용량을 자동으로 시작, 종료, 확장, 축소합니다.
Aurora Serverless는 사용 빈도가 낮거나 간헐적이거나 예측할 수 없는 워크로드에 대해 기능을 제공합니다.
DynamoDB는 key-value 구조를 가진 완전 관리형 NoSQL 데이터베이스입니다.
프로비저닝, 복제, 버전 관리, 클러스터 확장 등을 모두 관리해줍니다.
워크로드 수요에 맞춰 자동으로 처리 능력을 확장하며 테이블 크기가 증가함에 따라 데이터를 파티셔닝 및 재파티셔닝합니다.
AWS 리전의 세 개 시설에 데이터를 동기적으로 복제하여 높은 가용성과 데이터 안정성을 제공합니다.
기본 키는 단일 속성 파티션 키
또는 복합 파티션-정렬 키
중 하나가 됩니다. (단일 키는 파티션 키, 해시값으로 파티셔닝합니다.)
DynamoDB는 복합 파티션-정렬 키를 파티션 키 요소 및 정렬 키 요소로 인덱싱합니다.
복합 파티션-정렬 키를 사용하는 경우 첫 번째와 두 번째 요소 값 사이의 계층 구조가 유지됩니다.
테이블에서 하나 이상의 보조 인덱스를 생성할 수 있습니다.
DynamoDB 콘솔 또는 CreateTable
API를 사용하여 테이블을 만듭니다.PutItem
또는 BatchWriteItem
API를 사용하여 항목을 삽입하고, GetItem
또는 BatchGetItem
을 사용하거나,
복합 기본 키가 활성화되어 사용되고 있는 경우는 Query API
를 사용하여 테이블에 추가한 항목을 검색할 수 있습니다.
각 DynamoDB 테이블에는 프로비저닝된 읽기 처리량과 쓰기 처리량이 지정되어 있습니다.
프리 티어를 초과하는 경우 그 처리 능력에 1시간 단위로 요금이 부과되고, 테이블로 요청을 전송했는지 여부와 관계없이 처리 능력에 대해 시간당 요금이 부과됩니다.
단일 테이블에 프로비저닝할 수 있는 최대 처리량은 무제한입니다.
최소 처리량은 1개의 쓰기 용량 유닛과 1개의 읽기 용량 유닛이고, 전체 테이블의 용량을 합산하여 1개 계정에서 각 25개 유닛까지 프리 티어 범위가 됩니다.
최종적 일관된 읽기와 강력한 일관된 읽기 옵션의 차이를 정확히 알아두는 것이 좋습니다.
새 테이블을 생성할 때 암호화를 활성화하면 DynamoDB에서 나머지를 모두 처리해 줍니다.
암호화 유형은 다음 세 가지가 있습니다.
DAX는 완전 관리형 In-Memory Read Performance를 향상시켜주는 인메모리 캐시 서비스입니다.
테이블의 실시간 데이터 수정 이벤트를 캡처하는 기능입니다.
테이블에서 스트림을 설정하면 다음과 같은 이벤트가 발생할 때마다 스트림 레코드를 기록합니다.
스트림 레코드의 수명은 24시간입니다.
각 스트림 기록은 스트림에서 한 번만 나타나고, 실제 항목 수정과 동일한 순서로 나타납니다.
스트림과 Lambda를 결합하여 새로운 유저가 생성된 경우에 SES를 통해 이메일을 보내도록 하는 기능 등을 설계할 수 있습니다.
출처: https://wbluke.tistory.com/58 [함께 자라기:티스토리]
댓글 영역