DynamoDB
Last updated
완전 관리형 데이터베이스로 유지 관리나 패치 없이 항상 사용 가능하다. 데이터베이스를 프로비저닝할 필요가 없다.
데이터가 다중 AZ 간에 복제되므로 가용성이 높다.
NoSQL 데이터베이스이고 RDS나 Aurora 같은 관계형 데이터베이스는 아니지만 트랜잭션을 지원한다.
데이터베이스가 내부에서 분산되어 방대한 워크로드로 확장이 가능하다.
초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 가질 수 있다.
보안과 관련된 모든 기능은 IAM과 통합되어 있다. 보안, 권한 부여, 관리 기능을 제공한다.
비용이 적게 들고 오토 스케일링 기능을 제공한다.
테이블 클래스
Standard 클래스에는 액세스가 빈번한 데이터를 저장한다.
IA 테이블 클래스에는 액세스가 빈번하지 않는 데이터를 저장한다.
DynamoDB 아이템의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다.
다양한 데이터 유형을 지원한다.
문자열, 숫자, Binary, Boolean, null과 같은 스칼라 타입, List, Map, Set 등
데이터의 타입과 설정 면에서 스키마를 빠르게 변경해야 할 때 Aurora, RDS 대신 DynamoDB를 선택하면 좋다.
데이터 구조
단순히 테이블을 생성해 해당 테이블의 용량만 설정하면 된다. 데이터베이스를 따로 생성해줄 필요가 없다.
테이블을 생성 시 기본 키가 부여된다. 테이블에는 무한히 행을 추가할 수 있다.
기본 키는 파티션 키와 정렬 키(optional)로 구성된다.
속성 테이블이 존재한다. 각 아이템은 속성을 가질 수 있으며 나중에 추가될 수도, null이 될 수도 있다. 아이템마다 가지는 속성이 달라도 된다. (NoSQL이기 때문 😎)
읽기/쓰기 용량 모드
프로비전 모드
초당 읽기/쓰기 요청 수를 예측해서 미리 RCU(Read Capacity Units), WCU(Write Capacity Units)을 지정한다.
미리 용량을 계획했더라도 오토스케일링 기능을 통해 테이블의 부하에 따라 자동으로 RCU, WCU를 조정할 수 있다.
트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면 트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합하다.
온디맨드 모드
미리 용량을 계획하지 않으며, 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다.
정확히 사용한 만큼의 비용을 지불한다. 프로비전 모드보다 비싸다.
워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.
수천 개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서는 온디맨드 모드가 적합하다.
DynamoDB를 위한 고가용성의 완전 관리형 인메모리 캐시
DynamoDB 테이블에 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱한다.
캐시 데이터에 마이크로초 수준의 지연 시간을 보장한다.
기존 DynamoDB API와 호환되므로 애플리케이션 로직을 변경할 필요가 없다.
캐시의 기본 TTL은 5분으로 설정되어 있으나 변경할 수 있다.
ElastiCache 대신 DAX를 사용하는 경우는 개별 객체 캐시와 쿼리와 스캔 캐시를 처리하기 위함이다. 집계 결과를 저장하는 경우에는 Amazon ElastiCache가 적합하다. 일반적으로 Amazon DynamoDB에 캐싱 솔루션을 추가할 때 DAX를 사용한다.
테이블의 모든 수정 사항(생성, 업데이트, 삭제)을 포함한 스트림을 생성할 수 있다.
이를 통해 사용자 테이블에 새로운 사용자가 등록됐을 때 환영 이메일을 보내는 등 DynamoDB 테이블의 변경 사항에 실시간으로 반응할 수 있다. 사용 패턴을 분석을 하거나 파생 테이블을 삽입하거나 리전 간 복제를 실행하거나 DynamoDB 테이블 변경 사항에 대해 Lambda 함수를 실행할 수 있다.
DynamoDB 스트림
보존 기간이 24시간이고 소비자 수가 제한된다.
AWS Lambda Trigger와 함께 사용하거나, DynamoDB Stream Kinesis Adapter를 이용해 자체적으로 읽기를 실행할 수 있다.
처리 계층을 두어 EC2 인스턴스에서 애플리케이션을 실행하기 위한 KCL Adapter나 Lambda 함수를 사용할 수 있다. 이 때 SNS로 알림을 보내거나, DynamoDB 테이블을 필터링하거나 변환하는 등의 작업을 수행할 수 있다.
Kinesis Data Streams
보존 기간이 1년이고, 더 많은 수의 소비자 수를 가질 수 있다.
AWS Lambda 함수, Kinesis Data Analytics, Kinesis Data Firehose, AWS Glue 스트리밍, Streaming ETL 등을 사용할 수 있다.
여러 리전 간에 복제가 가능한 테이블
두 테이블 간에는 양방향 복제가 가능하다.
애플리케이션은 모든 리전에서 테이블을 읽고 쓸 수 있다.
DynamoDB Streams를 활성화해야 사용 가능하다.
만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능이다.
ExpTime(TTL)이라는 만료 기간 속성에 타임스탬프를 저장하여 현재 시간이 ExpTime 값을 넘어설 경우 해당 항목을 만료 시키고 삭제 처리를 진행한다.
최근 항목만 저장하도록 하거나 2년 후 데이터를 삭제해야 한다는 규정 등을 따라야 할 때 사용된다.
웹 세션 핸들링 시에도 사용 가능하다.
사용자가 웹사이트에 로그인했을 때 해당 세션을 중앙 저장소인 DynamoDB에 두 시간 동안 저장하도록 하고, 두 시간 동안 세션이 갱신되지 않는다면 만료되어 테이블에서 삭제된다.
지정 시간 복구(PITR, Point-in-time recovery)를 사용한 지속적인 백업
35일 동안 지속되도록 활성화할 수 있다.
백업 기간 내에는 언제든 지정 시간 복구를 실행할 수 있다.
복구를 진행할 경우 새로운 테이블을 생성하게 된다.
온디맨드 백업
직접 삭제할 때까지 보존되는 long-term 백업이다.
DynamoDB의 성능이나 지연 시간에 영향을 주지 않는다.
AWS Backup 서비스를 통해 설정 및 관리가 가능하다. 리전 간 백업을 복사할 수 있다.
복구를 진행할 경우 새로운 테이블을 생성하게 된다.
S3로 데이터 내보내기
지정 시간 복구 기능을 활성화한 후 S3로 데이터를 내보낼 수 있다.
DynamoDB 테이블을 S3로 내보내고 쿼리를 수행하려면 Amazon Athena 엔진을 사용하면 된다.
지속적인 백업을 활성화한 상태이므로 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있다.
테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않는다.
S3로 데이터를 내보낸 후 데이터 분석, 감사 목적의 스냅샷 확보, 데이터 ETL 등 대규모 변경을 실행할 수 있다.
데이터를 내보낼 때는 DynamoDB JSON이나 ION 포맷을 사용한다.
S3에서 데이터 가져오기
CSV, JSON 그리고 ION 형식의 데이터를 DynamoDB로 가져올 수 있다.
새로운 DynamoDB 테이블을 생성한다.
쓰기 용량을 소비하지 않는다.
데이터를 가져올 때 발생한 오류는 CloudWatch Logs에 기록된다.