DynamoDB 테이블

DynamoDB는 데이터를 테이블에 저장합니다. 테이블을 생성할 때 테이블 이름과 파티션 키를 지정해야 합니다. 테이블 생성 시에 필요한 엔터티는 이 두 항목 뿐입니다.

DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. 지원되는 기본 키의 2가지 유형은 다음과 같습니다.

• 단순 기본 키
  파티션 키라는 속성 하나만으로 구성된 단순한 기본 키입니다. 파티션 키를 하나만 사용하는 경우 두 항목이 동일한 값을 가질 수 없습니다.
• 복합 기본 키
  복합 기본 키는 파티션 키와 정렬 키로 구성됩니다. 이 경우 여러 항목의 파티션 키 값은 같을 수 있지만 정렬 키 값은 달라야 합니다.

핵심 구성 요소는 테이블, 항목, 및 속성입니다. 테이블은 항목의 모음이고 각 항목은 속성의 모음입니다. 위 예시에서 나와 있는 테이블에는 2개 항목이 포함되어 있고, Hammer57과 FluffyDuffy가 단순 기본 키입니다. 기본 키가 Hammer57인 항목에는 3개의 속성 (게임 ID, 최고점, 장르)이 있습니다. FluffyDuffy의 기본 키에는 구독 여부 속성이 포함되며 장르 속성은 포함되지 않았습니다.

상세

DynamoDB 용량 및 크기 조정

DynamoDB에서 용량을 계획할 때는 초당 읽기/쓰기 요청의 예상 수와 해당 요청의 크기를 고려해야 합니다. 이 정보를 고려하면 테이블용 용량 모드를 쉽게 선택할 수 있습니다. 또한 메시지 크기를 관리할 수 있도록 테이블을 설계할 수 있습니다.

온디맨드 용량 모드는 요청 단위로 요금이 부과되는 모델입니다. 다음과 같은 상황에서는 온디맨드 용량 모드가 유용합니다.

• 워크로드를 알 수 없는 경우
• 트래픽을 예측할 수 없는 경우
• 사용한 만큼만 지불하는 요금제를 사용하려는 경우

프로비저닝된 용량 모드 사용 시에는 RCU와 WCU의 최대 수를 설정합니다. 트래픽이 해당 한도를 초과하면 DynamoDB는 비용 제어를 위해 요청을 스로틀합니다. 자동 크기 조정을 사용해 프로비저닝된 용량을 조정할 수 있습니다. 다음과 같은 상황에서는 프로비저닝된 용량 모드가 유용합니다.

• 애플리케이션 트래픽이 예측 간으한 경우
• 트래픽의 양이 일정하거나 점진적으로 변경되는 경우
• 비용 관리를 위해 용량 요구 사항을 예측할 수 있는 경우

상세

DynamoDB 일관성 옵션

애플리케이션이 DynamoDB 테이블에 데이터를 쓰고 HTTP 200 응답(OK)을 수신하면 쓰기가 발생하며 내구성을 갖습니다. 데이터는 일반적으로 1초 이내에 모든 스토리지 위치에서 최종적으로 일관성을 갖습니다. DynamoDB는 최종적으로 일관된 읽기와 강력한 일관된 읽기를 지원합니다

• 최종적으로 일관된 읽기
  DynamoDB 테이블의 데이터를 읽을 때, 응답은 최근 완료된 쓰기 작업의 결과를 반영하지 않을 수 있습니다. 응답에는 부실 데이터가 일부 포함될 수 있습니다. 잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환합니다.
  (Ex_ YouTube 댓글, 쇼핑 장바구니 등 실시간 동기화가 굳이 필요하지 않은 경우)
  
  
• 강력한 읽기 일관성
  강력한 읽기 일관성을 요청하면 DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트를 반영하여 가장 최신 데이터로 응답을 반환합니다. 강력한 읽기 일관성은 네트워크 지연 또는 중단이 발생하는 경우에 사용이 어려울 수 있습니다.
  (Ex_ 항공권 구매, 티켓팅 등 실시간 동기화가 필요한 경우)

옵션을 지정하지 않을 경우 DynamoDB는 최종적으로 일관된 읽기를 사용합니다. 읽기 작업(GetItem, Query,Scan)은 CnsistentRead 파라미터를 제공합니다. 이 파라미터를 true로 설정하면 DynamoDB는 작업 중에 강력한 읽기 일관성을 사용합니다.

DynamoDB 글로벌 테이블

글로벌 테이블은 단일 AWS 계정이 소유하고 복제 테이블로 식별되는 한 개 이상의 DynamoDB 테이블의 모음입니다. 복제 테이블(이하 복제본)은 글로벌 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 글로벌 테이블은 리전당 한 개의 복제 테이블을 가질 수 있습니다. 모든 복제본은 동일한 테이블 이름과 동일한 기본 키 스키마를 갖습니다.

DynamoDB 글로벌 테이블은 복제 솔루션을 직접 구축하여 관리하지 않고도 다중 리전, 다중 활성 마스터 DB를 배포할 수 있는 완전관리형 솔루션을 제공합니다. 글로벌 테이블을 생성할 때 테이블을 사용할 수 있게 할 리전을 지정해야 합니다. DynamoDB는 이러한 리전에 동일한 테이블을 만들고 이들 모든 테이블에 대한 데이터 변경을 지속적으로 전파하기 위해 필요한 모든 태스크를 수행해야 합니다. DynamoDB는 AWS 네트워크 백본을 통해 이러한 변경 사항을 전달합니다.

상세

Dynamo DB

Dnamo DB는 완전관리형 NoSQL DB 서비스입니다. 이와 같이 대규모 확장이 가능한 분산형 NoSQL 데이터베이스를 관리하는 복잡한 작업은 서비스 자체에서 관리합니다. 그러므로 소프트웨어 개발자가 인프라 관리 대신 애플리케이션 구축에 집중할 수 있습니다.

NoSQL 데이터베이스는 기본적으로 확장이 가능하지만 해당 아키텍처가 정교하므로 대규모 NoSQL 클러스터를 실행하는 경우 상당한 운영 오버헤드가 발생할 수 있습니다. Dynamo DB를 사용하기 위해 고급 분산 컴퓨팅 개념을 다루는 전문가일 필요가 없습니다. 선택한 프로그래밍 언어의 SDK를 사용하여 DynamoDB의 간단한 API를 배우기만 하면 됩니다.

DynamoDB는 비용 효율적입니다. 사용하는 스토리지와 프로비저닝한 I/O 처리량에 대한 요금을 지불하면 됩니다. 이 데이터베이스는 고성능을 유지하면서 탄력적으로 확장 가능하도록 설계되었습니다. 애플리케이션의 스토리지 및 처리량 요구 사항이 낮은 경우 소량의 용량을 프로비저닝하도록 선택할 수 있습니다.

자동 크기 조정을 선택하면 필요한 I/O 처리량이 증가할 경우 사용자가 설정한 한도 내에서 추가 용량이 프로비저닝됩니다. 온디맨드 옵션을 선택하면 데이터베ㅣ스에 초당 수천 건의 동시 요청을 전송하는 수백만명의 사용자를 지원하도록 애플리케이션을 원활히 확장할 수 있습니다.

DynamoDB는 이벤트 중심의 프로그래밍과 세분화된 액세스 제어를 지원합니다.

오버헤드(Overhead)
어떤 처리를 하기 위해 들어가는 간접적인 처리 시간과 메모리 등을 말합니다. 예를들어 a작업을 단순하게 실행하는데 10초가 걸리고, 안정성을 고려하여 부가적인 처리를 한 A를 실행한 결과 15초가 걸렸다면, 오버헤드는 5초가 됩니다. 이를 개선해 A1이 처리하는 시간이 12초가 되었다면, "오버헤드가 3초 줄었다"라고 표현합니다.

SDK(Software Development Kit)
소프트웨어 개발 키드를 줄인 것으로 기본적으로 미리 작성된 코드를 뜻합니다. 여기에는 개발자가 기존 소프트웨어를 사용하여 새 애플리케이션을 구축하는 데 필요한 모든 도구가 포함됩니다. SDK에는 보통 컴파일러와 디버거, API가 있습니다. 이외에도 다양한 요소를 포함할 수 있습니다.

키-값 데이터

NoSQL DB에서는 데이터의 액세스 및 관리를 위해 다양한 데이터 모델을 사용합니다. 이러한 데이터베이스 유형은 큰 데이터 볼륨, 짧은 지연 시간, 유연한 데이터 모델이 필요한 애플리케이션에 최적화되었습니다. NoSQL 데이터베이스에서는 다른 데이터베이스의 데이터 일관성 제약 조건 일부를 완화하는 방식으로 최적화됩니다. 한 가지 일반적인 모델을 키-값 데이터 입니다.

키-값 DB는 요청한 데이터를 단일 키와 연결할 수 있는 사용 사례에 적합합니다. 예를 들어 애플리케이션의 사용자 프로파일 데이터를 키 값 DB에 저장한 후 GamerTag 값을 키로 사용할 수 있습니다. 이 경우 특정 GamerTag만 요청하면 사용자 데이터를 빠르게 검색할 수 있습니다.

DynamoDB 사용 사례

사례1

게임 제작자는 DynamoDB를 사용해 간단한 플레이어 프로파일 페이지를 지원할 수 있습니다. GamerTag를 키로 사용하여 DynamoDB에 사용자 프로파일 데이터를 저장할 수 있습니다. 프로파일 페이지가 로드될 때 애플리케이션은 GamerTag 값을 사용하여 DynamoDB에 읽기 요청을 한 번만 하면 됩니다. 그리고 새 게임이 출시되면 DynamoDB는 크기를 빠르게 조정하여 급증하는 트래픽을 지원하기에 충분한 스토리지와 처리량을 제공할 수 있습니다.

사례 상세

사례2

전자 상거래 애플리케이션을 통해 고객에게 제품을 판매한다고 가정해보겠습니다. 이 경우 정확한 재고 표시를 위한 웹스토어가 필요합니다. 그런데 트래픽이 많은 시기와 명절 할인 행사 기간 등에는 재고를 정확하게 표시하기가 매우 어렵습니다. DynamoDB는 다양한 제품의 데이털르 추가할 수 있는 유동적인 스키마를 지원합니다. 그리고 다수의 동시 읽기와 쓰기 작업을 관리하며, 저장된 데이터의 정확도도 유지 관리합니다.