[AWS] 솔루션 설계자 관점의 Serverless - DynamoDB

AWS DynamoDB

• 완전 관리형 데이터베이스로 데이터가 다중 AZ 간에 복제되므로 가용성이 높다.
• DynamoDB는 클라우드 네이티브이며, AWS의 독점 서비스이다.
• NoSQL 데이터베이스이고, RDS나 Aurora 같은 관계형 데이터베이스는 아니지만 트랜잭션 지원 기능이 있다.
• DynamoDB를 이용하면 방대한 워크로드로 확장이 가능하다.
    - 데이터베이스가 내부에서 분산되기 대문이다.
• 초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 갖게 된다.
• 성능은 한 자릿수 밀리초를 자랑하고 일관성 또한 높다.
• 보안과 관련된 모든 기능은 IAM과 통합되어 있다.
    - 보안, 권한부여, 관리 기능이 포함된다.
• 비용이 적게 들고 오토 스케일링 기능이 탑재되어 있다.
• 유지 관리나 패치 없이도 항상 사용할 수 있다.
• 데이터베이스를 프로비저닝할 필요가 없다.
• 항상 사용할 수 있으므로 테이블을 생성해 해당 테이블의 용량만 설정하면 된다.
    - Standard 클래스 : 액세스가 빈번한 데이터 저장
    - IA 테이블 클래스 : 액세스가 빈번하지 않는 데이터 저장

 

 

DynamoDB - Basics

• DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다.
    - Aurora나 RDS와 달리 DynamoDB는 데이터베이스가 이미 존재하는 서비스이다.
• DynamoDB에 테이블을 생성하면 각 테이블에 기본 키가 부여되는데 기본 키는 생성 시 결정된다.
• 각 테이블에 데이터를 추가한다.
    - 항목, 즉 행을 무한히 추가할 수 있다.
• 각 항목은 속성을 가지며 속성은 열에 표시된다.
    - 속성은 나중에 추가할 수도 있고, null이 될 수도 있다.
    - RDS나 Aurora 데이터베이스에서는 열을 나중에 추가할 수 있으나 과정이 복잡하고 스키마 전개가 어려울 수 있지만 DynamoDB에서는 사전 요구 사항 없이 나중에 쉽게 속성을 추가할 수 있다.
• DynamoDB 항목의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다.
• DynamoDB는 다양한 데이터 유형을 지언한다.
    - Scalar 유형 : 문자열, 숫자, Binary, Boolean, null 등
    - Document 유형 : 목록, 지도 등
    - Set 유형 : String Set, 숫자 Set 등
• 데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때, Aurora나 RDS보다는 DynamoDB가 더 나은 선택이다.

 

 

DynamoDB - Table example

• DynamoDB 테이블의 예시이다.
• 기본 키는 파티션 키와 선택 사항인 정렬 키로 구성된다.
• 속성테이블도 있고, 데이터베이스 형태이다.
• 속성은 null로 설정하거나 나중에 추가할 수 있다. = DynamoDB의 장점이다.

 

 

DynamoDB - Read/Write Capacity Modes

• DynamoDB를 사용하려면 읽기/쓰기 용량 모드도 설정해야 한다.

테이블 용량 관리 방식을 제어하는 데는 두 가지 모드가 있다.

1. Provisioned Mode (기본)

• 프로비저닝된 모드로, 미리 용량을 프로비저닝한다.
• 초당 읽기/쓰기 요청 수를 예측해서 미리 지정하면 그것이 테이블의 용량이 된다.
• 미리 용량을 계획하고 프로비저닝된 RCU와 WCU만큼의 비용을 지불하는 방식이다.
    - RCU는 읽기 용량 단위, WCU는 쓰기 용량 단위를 뜻한다.
• 미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로 테이블의 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다.
• 프로비저닝된 모드는 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원하 때 적합하다.

2. On-Demand Mode

• 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다.
• 미리 용량 계획을 하지 않으므로 RCU나 WCU 개념 자체가 없다.
• 온디맨드 모드에서는 정확히 사용한 만큼의 비용을 지불한다.
• 모든 읽기와 쓰기에 비용을 지불해야 한다.
• 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.
• 수천 개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서는 빠르게 확장되지 않는 프로비저닝된 모드는 적합하지 않고 온디맨드 모드를 선택해야 한다.
• 트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면 트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합할 것이다.