Q: Amazon DynamoDB란 무엇입니까?

Amazon DynamoDB는 완전관리형 NoSQL 데이터베이스 서비스로서 원활한 확장성과 함께 빠르고 예측 가능한 성능을 제공합니다. Amazon DynamoDB를 통해 고객은 분산 데이터베이스를 운영하고 AWS로 확장하는 데 따른 관리 부담에서 벗어날 수 있으며, 하드웨어 프로비저닝, 설정 및 구성, 처리 용량 계획, 복제, 소프트웨어 패치 또는 클러스터 확장에 대해서도 걱정할 필요가 없습니다.

Q: Amazon DynamoDB가 사용자 대신 무엇을 관리합니까?

Amazon DynamoDB를 사용하면 데이터베이스 소프트웨어 관리와 이를 실행할 하드웨어의 프로비저닝이라는 데이터베이스 확장의 주요 장애물 하나를 제거할 수 있습니다. 고객은 비관계형 데이터베이스를 단 몇 분 만에 배포할 수 있습니다. DynamoDB는 워크로드 수요에 맞춰 자동으로 처리 용량을 확장하며 테이블 크기가 증가함에 따라 데이터를 파티셔닝 및 재파티셔닝합니다. 또한, Amazon DynamoDB가 AWS 리전의 세 개 시설에 데이터를 동기적으로 복제하여 높은 가용성과 데이터 안정성을 제공합니다.

Q: 읽기 일관성이란 무엇입니까? 일관성은 왜 중요합니까?

Amazon DynamoDB는 높은 가용성 및 데이터 안정성을 위해 각 테이블의 복제본을 세 군데로 지리적으로 분산하여 저장합니다. 읽기 일관성은 데이터 항목의 성공적인 쓰기 또는 업데이트가 동일 항목에 대한 다음 읽기 작업에 반영되는 방법과 시기를 의미합니다. Amazon DynamoDB가 제공하는 로직에 따라 애플리케이션에서 사용자가 원하는 대로 각 읽기 요청에 대한 일관성 특성을 지정할 수 있습니다.

Q: Amazon DynamoDB의 일관성 모델은 무엇입니까?

Amazon DynamoDB에서 데이터를 읽을 때, 사용자는 읽기를 eventually consistent나 strongly consistent로 지정할 수 있습니다.

Eventually Consistent Read(기본) – 최종 일관성 옵션은 읽기 처리량을 최대화합니다. 그러나 eventually consistent read는 최근 완료한 쓰기 결과를 반영하지 못할 수 있습니다. 데이터의 모든 사본에 대한 일관성 작업은 보통 1초 이내에 이뤄집니다. 즉, 짧은 시간 간격으로 읽기를 반복함으로써 업데이트된 데이터를 반환합니다.

Strongly Consistent Read – Amazon DynamoDB는 최종 일관성 외에도 애플리케이션 또는 애플리케이션의 요소에서 요구하는 경우 strongly consistent read를 요청할 수 있는 유연성과 제어도 제공합니다. Strongly Consistent Read는 해당 읽기 전에 성공적인 응답을 수신한 모든 쓰기를 반영한 결과를 반환합니다.

Q: DynamoDB는 내부 원자 단위 업데이트를 지원합니까?

Amazon DynamoDB는 빠른 속도의 내부 업데이트를 지원합니다. 한 번의 API 호출을 사용하여 한 행에서 숫자 속성을 증가하거나 감소할 수 있습니다. 마찬가지로 설정, 목록 또는 맵을 자동으로 추가 또는 제거할 수 있습니다. 원자 단위 업데이트에 대한 자세한 내용은 설명서를 참조하십시오.

Q: Amazon DynamoDB를 SSD(Solid State Drive)에 구축하는 이유가 무엇입니까?

Amazon DynamoDB는 SSD(Solid State Drive)에서만 실행됩니다. SSD는 모든 규모의 데이터 저장 및 액세스에 대해 예측 가능한 짧은 지연 응답 시간을 실현하는 데 도움이 됩니다. 또한, SSD의 높은 I/O 성능을 통해 대용량 요청 워크로드도 비용 효율적으로 지원함으로써 요청 비용을 절감할 수 있습니다.

Q: DynamoDB의 스토리지 비용이 높은 편입니다. 제 사용 사례에서 비용 효율적인 서비스입니까?

다른 모든 제품과 마찬가지로 Amazon DynamoDB의 도입을 생각하는 고객은 요금의 한 단면이 아닌 전체 솔루션의 비용을 고려하시길 당부드립니다. 데이터베이스 워크로드에 대한 서비스의 총비용은 요청하는 트래픽 요구 사항과 저장되는 데이터 양에 따라 달라집니다. 대부분 데이터베이스 워크로드는 저장된 GB당 높은 I/O(높은 읽기/초 및 쓰기/초)에 따라 발생합니다. Amazon DynamoDB는 SSD 드라이브에 구축되기 때문에 스피닝 미디어에 비해 저장된 GB당 비용이 높지만 요청 비용은 크게 줄일 수 있습니다. 통상적인 데이터베이스 워크로드와 비교할 때, SSD 기반 DynamoDB 서비스의 총 사용 비용은 통상적인 스피닝 미디어 기반 관계형 또는 비관계형 데이터베이스의 사용 비용보다 일반적으로 낮습니다. 거의 액세스하지 않는 데이터를 대용량으로 저장하고 있는 사용 사례에는 DynamoDB가 적합하지 않을 수 있습니다. 이러한 사용 사례에는 S3를 사용하는 것이 좋습니다.

AWS 리전의 여러 시설에 각 데이터 항목의 여러 복사본을 저장하는 비용도 스토리지 비용에 포함되어 있음을 참고하시기 바랍니다.

Q: DynamoDB는 규모가 큰 애플리케이션만 대상으로 합니까?

아니요. DynamoDB는 원활한 확장 기능을 제공하므로 애플리케이션 요구 사항이 증가함에 따라 자동으로 확장할 수 있습니다. 규모에 상관없이 빠르고 예측 가능한 성능을 원한다면 DynamoDB를 선택하는 것이 좋습니다.

Q: Amazon DynamoDB를 시작하려면 어떻게 해야 합니까?

지금 Amazon DynamoDB를 시작하려면 "가입"을 클릭합니다. AWS Management Console 또는 Amazon DynamoDB API 중 하나를 사용하여 Amazon DynamoDB 작업을 시작할 수 있습니다. AWS Management Console을 사용하면 몇 번의 클릭만으로 Amazon DynamoDB 테이블을 만들어 사용할 수 있습니다.

Q: DynamoDB는 어떤 종류의 쿼리 기능을 지원합니까?

Amazon DynamoDB에서는 사용자 정의 기본 키를 사용하여 GET/PUT 연산을 지원합니다. 기본 키는 테이블 항목 중 유일한 필수 속성으로서 각 항목을 고유하게 식별해 줍니다. 테이블을 생성할 때 기본 키를 지정합니다. 이외에도 DynamoDB는 글로벌 및 로컬 보조 인덱스를 사용하여 기본 이외의 키 속성에 대해 쿼리할 수 있는 유연한 쿼리 기능을 지원합니다.

기본 키는 단일 속성 파티션 키 또는 복합 파티션-정렬 키 중 하나가 됩니다. 예를 들어, "UserID"가 단일 속성 파티션 기본 키가 될 수 있습니다. 그러면 해당 사용자 ID와 관련된 항목의 데이터를 빠르게 읽고 쓸 수 있습니다.

복합 파티션-정렬 키는 파티션 키 요소 및 정렬 키 요소로 인덱싱됩니다. 이 멀티-파트 키를 사용하여 첫 번째와 두 번째 요소 값 사이의 계층 구조가 유지됩니다. 예를 들어, 복합 파티션-정렬 키는 "UserID"(파티션)와 "Timestamp"(정렬)의 조합이 될 수 있습니다. 파티션 키 요소를 일정하게 유지함으로써 정렬 키 요소를 검색하여 항목을 찾을 수 있습니다. 예를 들어, 쿼리 API를 사용하여 일정 범위의 timestamp에 걸쳐 동일한 UserID가 있는 모든 항목을 검색할 수 있습니다.

글로벌 보조 인덱싱 및 쿼리 기능에 대한 자세한 내용은 FAQ의 보조 인덱스 섹션을 참조하십시오.

 

Q: Amazon DynamoDB에서 어떻게 데이터 항목을 업데이트하고 쿼리합니까?

AWS Management Console 또는 CreateTable API를 사용하여 테이블을 만든 후 PutItem 또는 BatchWriteItem API를 사용하여 항목을 삽입할 수 있습니다. 테이블에 추가한 항목은 GetItem 또는 BatchGetItems를 사용하거나 Query API를 사용하여(테이블에서 복합 기본 키가 활성화되어 사용되고 있는 경우) 검색할 수 있습니다.

Q: Amazon DynamoDB는 조건부 연산을 지원합니까?

항목에서 완료할 삽입, 업데이트, 삭제 연산을 충족하도록 조건을 지정할 수 있습니다. 조건부 연산을 수행하려면 다음을 통해 생성되는 ConditionExpression을 정의하면 됩니다.

  • Boolean 함수: ATTRIBUTE_EXIST, CONTAINS 및 BEGINS_WITH
  • 비교 연산자: =, <>, <, >, <=, >=, BETWEEN 및 IN
  • 논리 연산자: NOT, AND 및 OR 

중첩된 절을 포함해 여러 조건 절이 결합된 자유형 조건부 표현식을 생성할 수 있습니다. 조건부 연산을 사용하면 DynamoDB에서 낙관적 동시성 제어 시스템을 구현할 수 있습니다. 조건부 연산에 대한 자세한 내용은 설명서를 참조하십시오.

Q: 키 조건에서 표현식이 지원됩니까?

예. Query API 호출의 일부로서 표현식을 지정할 때 KeyConditionExpression 파라미터를 사용하여 테이블의 기본 키 값에 따라 결과를 필터링할 수 있습니다.

Q: 파티션 키 및 파티션-정렬 키에서 표현식이 지원됩니까?

예. 파티션 키와 파티션-정렬 키 모두에서 표현식을 사용할 수 있습니다. 파티션 키와 파티션-정렬 키에서 사용할 수 있는 표현식에 대한 자세한 내용은 설명서 페이지를 참조하십시오.

Q: Amazon DynamoDB는 증가 또는 감소 연산을 지원합니까?

예. Amazon DynamoDB는 스칼라 값을 원자 단위로 증가 연산 및 감소 연산할 수 있습니다.

Q: Amazon RDS 또는 Amazon EC2의 관계형 데이터베이스 엔진과 Amazon DynamoDB는 각각 어떤 경우에 사용합니까?

오늘날의 웹 기반 애플리케이션은 막대한 양의 데이터를 생성 및 소모하고 있습니다. 예를 들어, 이제 막 출시된 온라인 게임의 경우, 사용자가 수천 명 남짓으로 초당 10개의 쓰기 작업과 초당 50개의 읽기 작업이 필요한 가벼운 데이터베이스 워크로드가 발생할 수 있습니다. 하지만 게임이 성공하면 사용자 수는 수백만 명으로 급격히 증가하고, 초당 수만 건(또는 수십만 건)의 쓰기/읽기 작업이 발생할 수 있습니다. 또한 하루에 테라바이트 이상의 데이터가 생성될 수도 있습니다. Amazon DynamoDB에서 애플리케이션을 개발하면 작은 규모에서 시작하여 필요에 따라 가동 중지 시간 없이 테이블의 요청 용량을 간단하게 조정할 수 있습니다. 프로비저닝한 요청 용량에 비용 효율적인 요금을 지불하면 Amazon DynamoDB가 데이터와 트래픽을 분할하고 충분한 서버 용량을 제공하여 사용자의 요구 사항을 충족해 드립니다. 데이터베이스 관리를 비롯한 여러 관리 작업은 Amazon DynamoDB가 수행하므로, 고객은 데이터를 저장하고 요청하기만 하면 됩니다. 또한 자동 복제 및 장애 조치를 통해 기본적인 내결함성, 고가용성, 데이터 안정성을 제공합니다. Amazon DynamoDB를 사용하면 데이터베이스가 완전히 관리되고 애플리케이션의 요구 사항에 따라 확장되므로 안심할 수 있습니다.

Amazon DynamoDB는 확장성, 관리, 성능 및 안정성 등 데이터베이스의 주요 문제를 해결하지만, 관계형 데이터베이스의 모든 기능을 제공하지는 않습니다. 복잡한 관계형 쿼리(예: 조인) 또는 복잡한 트랜잭션을 지원하지 않습니다. 이러한 기능이 필요하거나 기존 관계형 엔진과의 호환성을 원한다면 Amazon RDS 또는 Amazon EC2의 관계형 엔진을 실행할 수 있습니다. 관계형 데이터베이스 엔진은 강력한 기능을 제공할 수 있지만, 하나의 관계형 데이터베이스 인스턴스를 넘어 워크로드를 확장하는 작업은 매우 복잡하고 상당한 시간과 전문 지식이 필요합니다. 따라서 새 애플리케이션의 확장이 예상되지만 관계형 기능은 필요하지 않다면 Amazon DynamoDB를 사용하는 것이 좋습니다.

Q: Amazon DynamoDB는 Amazon SimpleDB와 어떻게 다릅니까?

어떤 서비스를 사용해야 합니까? 두 서비스 모두 비관계형 데이터베이스로서 데이터베이스 관리 작업이 필요하지 않습니다. Amazon DynamoDB는 원활한 확장성 및 빠르고 예측 가능한 성능 관리에 주력합니다. 지연이 짧은 응답 시간을 실현하기 위해 SSD(Solid State Disk)에서 실행되고 지정된 테이블의 요청 용량이나 스토리지 크기에 제한이 없습니다. 고객이 제공한 확장 요구 사항에 맞춰 Amazon DynamoDB가 충분한 수의 서버에 걸쳐 데이터와 워크로드를 자동 분할하기 때문입니다. 이와 달리 Amazon SimpleDB의 테이블은 저장 용량에 10GB라는 엄격한 제한이 있으며, 가능한 요청 용량이 제한되어 있습니다(일반적으로 초당 쓰기 25회 미만). 추가 확장이 필요한 경우 추가 SimpleDB 테이블에서 데이터의 분할 및 재분할을 고객이 관리해야 합니다. 확장성에 제한이 있지만 쿼리 유연성이 필요한 적은 규모의 워크로드에 대해서는 SimpleDB가 적합할 수 있습니다. Amazon SimpleDB는 모든 항목 속성이 자동으로 인덱싱되므로 쿼리의 유연성은 지원되지만 대신 성능과 확장성이 저하됩니다.

Amazon CTO인 Werner Vogels의 DynamoDB 블로그 게시물에는 Amazon의 비관계형 데이터베이스 기술이 어떻게 발전되어 왔는지가 자세히 설명되어 있습니다.

Q: Amazon DynamoDB와 Amazon S3는 각각 어떤 경우에 사용합니까?

Amazon DynamoDB에는 기본 키로 색인된 구조적 데이터가 저장되고 1바이트에서 최대 400KB 범위의 항목에 낮은 지연 시간으로 읽기 및 쓰기 액세스가 가능합니다. Amazon S3에는 비정형 BLOB이 저장되며, 최대 5TB의 큰 객체를 저장하는 데 적합합니다. AWS 서비스에서 비용을 절감하려면 대규모 객체나 액세스 빈도가 낮은 데이터세트는 Amazon S3에 저장하고, 작은 데이터 요소나 파일 포인터(Amazon S3 객체에 대한 포인터 등)는 Amazon DynamoDB에 저장하는 것이 좋습니다.

Q: DynamoDB는 운영 체제에 상관없이 실행되는 애플리케이션에서 사용할 수 있습니까?

예. DynamoDB는 API를 통해 액세스하는 완전관리형 클라우드 서비스입니다. DynamoDB는 모든 운영 체제(예, Linux, Windows, iOS, Android, Solaris, AIX, HP-UX 등)에서 실행되는 애플리케이션에서 사용할 수 있습니다. DynamoDB는 AWS SDK를 사용해 시작하는 것이 좋습니다. AWS SDK 목록은 개발자 리소스 페이지에서 확인할 수 있습니다. AWS의 SDK를 설치하거나 사용하는 데 문제가 있다면 관련 AWS 포럼에 해당 내용을 게시해 문의해 주시기 바랍니다.


Q: 데이터 모델이란 무엇입니까?

Amazon DynamoDB의 데이터 모델은 다음과 같습니다.

테이블: 테이블은 데이터 항목의 모음으로, 관계형 데이터베이스의 테이블이 행의 모음인 것과 같습니다. 각 테이블의 데이터 항목 수에는 제한이 없습니다. Amazon DynamoDB에는 스키마가 없으므로 테이블의 데이터 항목에 있는 속성이나 속성 수가 동일하지 않아도 됩니다. 각 테이블에는 기본 키가 있어야 합니다. 기본 키는 단일 속성 키 또는 두 가지 속성이 결합된 "복합" 속성 키 중 하나가 됩니다. 기본 키는 테이블의 각 항목을 고유하게 식별하기 때문에 기본 키로 지정한 속성은 모든 항목에 있어야 합니다.

항목: 항목은 기본 키 또는 복합 키와 여러 속성으로 구성됩니다. 개별 항목과 관련된 속성의 수에는 명시적인 제한이 없지만 모든 속성 이름과 속성 값을 포함한 단일 항목의 총 크기는 400KB를 넘을 수 없습니다.

속성: 데이터 항목과 관련된 각 속성에는 속성 이름(예: "색상")과 함께 값 또는 값 집합(예: "빨강" 또는 "빨강, 노랑, 초록")이 있습니다. 개별 속성의 크기에는 명시적인 제한이 없지만 단일 항목의 총 크기(모든 속성 이름과 값 포함)는 400KB를 초과할 수 없습니다.

Q: 항목 크기에 제한이 있습니까?

단일 항목의 총 크기(모든 속성 이름과 속성 값 포함)는 400KB를 초과할 수 없습니다.

Q: 한 항목이 가질 수 있는 속성 수에는 제한이 있습니까?

한 항목이 가질 수 있는 속성의 수에는 제한이 없습니다. 그러나 단일 항목의 총 크기(모든 속성 이름과 속성 값 포함)는 400KB를 초과할 수 없습니다.

Q: API란 무엇입니까?

  • CreateTable – 테이블을 만들고 데이터 액세스에 사용되는 기본 인덱스를 지정합니다.
  • UpdateTable – 주어진 테이블의 프로비저닝된 처리량 값을 업데이트합니다.
  • DeleteTable – 테이블을 삭제합니다.
  • DescribeTable – 테이블 크기, 상태, 인덱스 정보를 반환합니다.
  • ListTables – 현재 계정 및 엔드포인트와 연결된 모든 테이블의 목록을 반환합니다.
  • PutItem – 새 항목을 만들거나 이전 항목을 새 항목으로 바꿉니다(모든 속성 포함). 지정된 테이블에 동일한 기본 키를 지닌 항목이 이미 존재하는 경우 기존 항목이 새 항목으로 완전히 바뀝니다. 조건 연산자를 사용하여 속성 값이 일정 조건을 만족하는 경우에만 항목을 바꾸거나 해당 항목이 존재하지 않는 경우에만 새 항목을 삽입할 수도 있습니다.
  • BatchWriteItem – 단일 요청으로 여러 테이블에서 여러 항목을 삽입, 교체 및 삭제하지만 단일 트랜잭션으로 처리되지는 않습니다. Put 또는 Delete에 대해 최대 25개 항목의 배치를 지원하며 총 요청의 최대 크기는 16MB입니다.
  • UpdateItem – 기존 항목의 속성을 편집합니다. 조건 연산자를 사용하여 항목의 속성 값이 일정 조건을 만족하는 경우에만 업데이트할 수도 있습니다.
  • DeleteItem – 기본 키로 테이블의 단일 항목을 삭제합니다. 조건 연산자를 사용하여 항목의 속성 값이 일정 조건을 만족하는 경우에만 항목을 삭제할 수도 있습니다.
  • GetItem – GetItem 작업은 기본 키와 일치하는 항목에 대한 속성 세트를 반환합니다. GetItem 작업은 기본적으로 Eventually Consistent Read를 제공합니다. 애플리케이션에서 eventually consistent read를 사용할 수 없는 경우 ConsistentRead를 사용합니다.
  • BatchGetItem – BatchGetItem 작업은 기본 키를 사용하여 여러 테이블에서 다수의 항목에 대한 속성을 반환합니다. 단일 응답의 크기는 16MB로 제한되고 최대 100개 항목이 반환됩니다. 강력한 일관성과 최종 일관성 모두 지원
  • Query – 테이블 기본 키를 사용하거나, 인덱스 키를 사용하여 보조 인덱스에서 하나 이상의 항목을 가져옵니다. 비교 연산자 또는 표현식을 사용하여 테이블의 쿼리 범위를 좁힐 수 있습니다. 키가 아닌 속성에서 필터를 사용하여 쿼리 결과를 필터링할 수도 있습니다. 강력한 일관성과 최종 일관성 모두 지원 단일 응답의 크기는 1MB로 제한됩니다.
  • 스캔 – 테이블 또는 보조 인덱스를 전체 스캔하여 모든 항목 및 속성을 가져옵니다. 하나 이상의 속성에 대해 필터를 지정하여 반환되는 결과 수를 제한할 수 있습니다.

Q: 스캔 작업의 일관성 모델은 무엇입니까?

스캔 작업은 Eventually Consistent Read 및 Consistent Read를 지원합니다. 기본적으로 스캔 작업은 Eventually Consistent입니다. 그러나 Scan API 호출의 선택적 ConsistentRead 파라미터를 사용하여 일관성 모델을 수정할 수 있습니다. ConsistentRead 파라미터를 true로 설정하면 스캔 작업에서 Consistent Read를 만들 수 있게 됩니다. 자세한 내용은 스캔 작업에 대한 설명서를 참조하십시오.

Q: 스캔 작업의 작동 원리는 무엇입니까?

스캔 작업을 반복기로 생각할 수 있습니다. 주어진 Scan API 요청에 대해 검색된 항목의 총 크기가 1MB 한도를 초과하면 해당 요청이 종료되고 가져온 결과가 LastEvaluatedKey와 함께 반환됩니다. 다음 작업 요청 시, 이어서 결과가 검색됩니다.

Q: 스캔 작업에 제한이 있습니까?

테이블 또는 보조 인덱스에서의 스캔 작업은 작업당 1MB의 데이터로 제한됩니다. 1MB 한도를 넘으면 작업이 중지되고 해당 시점까지 일치하는 값과 이후의 작업에서 적용할 LastEvaluatedKey가 반환되므로 나중에 중지된 위치에서 다시 시작할 수 있습니다.

Q: 스캔 작업에서 소모되는 읽기 용량 유닛은 얼마입니까?

필요한 읽기 유닛은 스캔 작업을 통해 가져온 바이트 수를 최대 4KB 단위로 올림하고 4KB로 나눈 수입니다. Consistent Read로 테이블을 스캔하는 경우 Eventually Consistent Read로 스캔할 때보다 읽기 용량을 2배 더 소비합니다.

Q: DynamoDB는 어떤 형식의 데이터를 지원합니까?

DynamoDB는 네 가지 스칼라 데이터 유형, 즉 숫자, 문자열, 바이너리 및 부울을 지원합니다. 또한 DynamoDB는 숫자 세트, 문자열 세트, 바이너리 세트, 이기종 목록 및 이기종 맵 같은 모음 데이터 유형을 지원합니다. 그뿐 아니라 NULL 값도 지원합니다.

Q: DynamoDB는 어떤 유형의 데이터 구조를 지원합니까?

DynamoDB는 키 값 데이터 구조와 문서 데이터 구조를 지원합니다.

Q: 키 값 저장소란 무엇입니까?

키 값 저장소는 저장하는 실제 콘텐츠가 포함된 키와 값으로 식별되는 개체 모음을 저장, 쿼리 및 업데이트할 수 있도록 하는 데이터베이스 서비스입니다.

Q: 문서 저장소란 무엇입니까?

문서 저장소는 JSON, XML, HTML 같은 문서 형식으로 항목을 저장, 쿼리 및 업데이트할 수 있도록 합니다.

Q: DynamoDB에 JSON 데이터 유형이 있습니까?

아니요. 하지만 문서 SDK를 사용하여 JSON 데이터를 DynamoDB로 직접 전달할 수 있습니다. DynamoDB의 데이터 유형은 JSON이 지원하는 데이터 유형의 상위 세트입니다. 문서 SDK는 JSON 문서를 기본 DynamoDB 데이터 유형에 자동으로 매핑합니다.

Q: AWS Management Console을 사용하여 JSON 문서를 보고 편집할 수 있습니까?

예. AWS Management Console에서는 JSON 문서를 포함하여 DynamoDB 테이블에 저장된 데이터를 단순한 UI를 통해 탐색하고 편집할 수 있습니다. 테이블의 데이터를 보거나 편집하려면 AWS Management Console에 로그인하고, DynamoDB를 선택하고, 보려는 테이블을 선택한 후 'Explore Table' 버튼을 클릭하십시오.

Q: DynamoDB에서 JSON 데이터를 쿼리하는 것에 차이점이 있습니까?

아니요. 최상위 JSON 요소에서 글로벌 보조 인덱스 또는 로컬 보조 인덱스를 생성할 수 있습니다. 예를 들어 특정 개인에 대한 정보(이름, 성, 우편 번호 및 전체 친구 목록)가 포함된 JSON 문서를 저장했다고 가정해 보겠습니다. 이 경우 이름, 성 및 우편 번호는 최상위 JSON 요소가 됩니다. 이름, 성 또는 우편 번호를 토대로 쿼리하는 데 사용할 수 있는 인덱스를 생성할 수도 있습니다. 친구 목록은 최상위 요소가 아니므로 인덱싱할 수 없습니다. 글로벌 보조 인덱싱 및 쿼리 기능에 대한 자세한 내용은 이 FAQ의 보조 인덱스 섹션을 참조하십시오.

Q: DynamoDB에 중첩된 JSON 데이터가 있는 경우 이 데이터의 특정 요소만 검색할 수 있습니까?

예. GetItem, BatchGetItem, Query 또는 Scan API를 사용하면 ProjectionExpression을 정의하여 테이블에서 검색되는 속성을 결정할 수 있습니다. 이러한 속성에는 JSON 문서의 스칼라, 세트 또는 요소가 포함될 수 있습니다.

Q: DynamoDB에 중첩된 JSON 데이터가 있는 경우 이 데이터의 특정 요소만 업데이트할 수 있습니까?

예. DynamoDB 항목을 업데이트하는 경우 업데이트하려는 JSON 문서의 하위 요소를 지정할 수 있습니다.

Q: Document SDK란 무엇입니까?

Document SDK는 JS와 DynamoDB 데이터 유형을 손쉽게 함께 사용할 수 있게 해주는 JavaScript용 데이터 유형 래퍼입니다. 이 SDK를 사용하면 요청에 대한 래핑이 처리되며, 응답의 경우에도 마찬가지로 데이터 유형의 래핑이 해제됩니다. 자세한 내용을 알아보고 SDK를 다운로드하려면 여기에서 GitHub 리포지토리를 참조하십시오.

 


Q: Amazon DynamoDB에 저장할 수 있는 데이터 양에 제한이 있습니까?

아니요. Amazon DynamoDB 테이블에 저장할 수 있는 데이터 양에는 제한이 없습니다. 데이터 세트의 크기가 증가하면 스토리지 요구 사항을 충족하기 위해 Amazon DynamoDB가 충분한 시스템 리소스에 데이터를 자동으로 분산합니다.

Q: 단일 테이블에서 가져올 수 있는 처리량에 제한이 있습니까?

아니요. API 또는 AWS Management Console을 사용하여 Auto Scaling의 최대 용량 한도 설정값을 높이거나 수동으로 프로비저닝한 테이블의 처리량을 늘릴 수 있습니다. DynamoDB에서 대규모의 용량 증가가 가능하고, 이론상 달성할 수 있는 최대 처리량에 제한이 없습니다. DynamoDB는 자동으로 테이블을 여러 개의 파티션으로 분할합니다. 각 파티션은 독립적인 병렬 컴퓨팅 장치입니다. DynamoDB는 파티션을 추가하여 처리 속도를 늘려나갈 수 있습니다.

10,000 쓰기/초 또는 10,000 읽기/초 이상의 처리 속도를 원하시면 먼저 이 온라인 양식을 사용하여 Amazon에 문의하십시오.

Q: Auto Scaling이 확장을 트리거하거나 내가 프로비저닝된 처리량을 변경하여 확장 또는 축소를 요청한 경우에도 Amazon DynamoDB를 계속 사용할 수 있습니까?

예. Amazon DynamoDB는 Auto Scaling이든 수동이든 관리 방법과 관계없이 프로비저닝된 처리량을 확장 또는 축소할 때도 계속 사용할 수 있도록 설계되었습니다.

Q: Amazon DynamoDB에서 클라이언트 측 분할을 내가 관리해야 합니까?

아니요. Amazon DynamoDB에서 처리량 확장을 위해 사용자가 직접 데이터베이스 테이블을 분할할 필요가 없습니다.

Q: Amazon DynamoDB의 가용성 수준은 어떻습니까?

이 서비스는 높은 가용성을 갖춘 검증된 Amazon의 데이터 센터에서 실행됩니다. 해당 서비스에서 AWS 리전의 시설 세 곳에 데이터를 복제하여 서버 오류 발생 시나 가용 영역 정지 시에 내결함성을 제공합니다.

Q: Amazon DynamoDB는 어떤 방법으로 높은 가동률과 안정성을 실현합니까?

높은 가용성과 안정성을 실현하기 위해 Amazon DynamoDB는 AWS 리전의 세 개 시설에 걸쳐 데이터를 동기적으로 복제합니다.


Q: DynamoDB Auto Scaling이란 무엇입니까?

DynamoDB Auto Scaling은 애플리케이션 요청이 증가하거나 감소함에 따라 DynamoDB 테이블 또는 글로벌 보조 인덱스의 프로비저닝된 읽기 및 쓰기 용량을 자동으로 확장하거나 축소하는 완전관리형 기능입니다.

Q: Auto Scaling을 사용해야 하는 이유는 무엇입니까?

Auto Scaling을 사용하면 새로운 테이블을 생성할 때 적절한 용량을 프로비저닝하기 위해 추측을 할 필요가 없고, 지속적으로 사용한 처리량을 모니터링하고 수동으로 프로비저닝된 용량을 조정해야 하는 운영 부담이 줄어듭니다. Auto Scaling은 애플리케이션 가용성을 유지하고 사용하지 않은 프로비저닝된 용량에서 발생하는 비용을 줄이는 데 도움이 됩니다.

Q: Auto Scaling에 적합한 애플리케이션 요청 패턴과 워크로드는 무엇입니까?

Auto Scaling은 균일하고 예측 가능한 요청 패턴과 몇 분에서 몇 시간 동안 유지되는 지속적으로 높고 낮은 처리량 사용량에 매우 적합합니다.

Q: DynamoDB 테이블이나 글로벌 보조 인덱스에 Auto Scaling을 활성화하려면 어떻게 해야 합니까?

DynamoDB 콘솔에서 새로운 테이블을 생성할 때 [Use default settings] 옵션을 선택된 상태로 두면, Auto Scaling이 활성화되고 글로벌 보조 인덱스와 동일한 설정이 테이블에 적용됩니다. [Use default settings] 옵션의 선택을 취소하면, 수동으로 프로비저닝된 용량을 설정하거나 목표 사용률과 최소 및 최대 용량에 대한 사용자 지정 값으로 Auto Scaling을 활성화할 수 있습니다. 기존 테이블의 경우 Auto Scaling을 활성화하거나 [Capacity] 탭으로 이동하여 기존 Auto Scaling 설정을 변경할 수 있고, 인덱스의 경우 [Indexes] 탭 아래에서 Auto Scaling을 활성화할 수 있습니다. 또한, Auto Scaling은 CLI 또는 AWS SDK를 사용하여 프로그래밍 방식으로 관리할 수도 있습니다. 자세한 내용은 DynamoDB 개발자 안내서를 참조하십시오.

Q: Auto Scaling에서 구성할 수 있는 설정에는 어떤 것이 있습니까?

Auto Scaling에는 3가지 구성 가능한 설정이 있습니다. 총 프로비저닝된 처리량 대비 실제 사용된 처리량 비율인 목표 사용률, Auto Scaling이 축소할 수 있는 최솟값인 최소 용량, Auto Scaling이 확장할 수 있는 최댓값인 최대 용량을 구성할 수 있습니다. 목표 사용률의 기본값은 70%(허용 범위는 20%~80%로 1% 단위로 조정), 최소 용량은 1유닛, 최대 용량은 리전 내 사용자 계정의 테이블 한도입니다. 리전 수준의 기본 테이블 한도는 DynamoDB의 제한 값 페이지를 참조하십시오.

Q: 기존 Auto Scaling 정책의 설정을 변경할 수 있습니까?

예. 관리 콘솔의 [Capacity] 탭으로 이동하거나 CLI 또는 SDK에서 AutoScaling API를 사용하여 프로그래밍 방식으로 언제든 기존 Auto Scaling 정책의 설정을 변경할 수 있습니다.

Q: Auto Scaling은 어떻게 작동합니까?

DynamoDB 테이블에 대해 새로운 Auto Scaling 정책을 생성하면, 사용자가 지정하는 목표 사용률의 임계값이 적용된 Amazon CloudWatch 경보가 생성됩니다. 이 값은 CloudWatch에 게시된 사용 용량 지표와 프로비저닝된 용량 지표를 기준으로 계산됩니다. 테이블의 실제 사용률이 일정 기간 동안 목표 사용률에서 벗어나면 CloudWatch 경보가 Auto Scaling을 작동시킵니다. 그러면 Auto Scaling이 정책을 평가하고 그에 따라 UpdateTable API 요청을 DynamoDB로 보내 동적으로 테이블의 프로비저닝된 처리 용량을 늘리거나 줄여 실제 사용률을 목표 사용률에 근접하게 만듭니다.

Q: 여러 리전의 여러 테이블 전체에 단일 Auto Scaling 정책을 적용할 수 있습니까?

아니요. Auto Scaling 정책은 같은 리전 내 단일 테이블 또는 글로벌 보조 인덱스에만 설정할 수 있습니다.

Q: 즉시 최대 용량으로 확장하거나 최소 용량으로 축소하도록 Auto Scaling 정책을 강제할 수 있습니까?


아니요. 즉시 최대 용량으로 확장하거나 최소 용량으로 축소하는 기능은 지원되지 않습니다. 대신, 임시로 Auto Scaling을 비활성화하고, 필요한 기간 동안 수동으로 원하는 용량을 설정한 다음, 나중에 Auto Scaling을 다시 활성화할 수 있습니다.

Q: Auto Scaling으로 트리거된 조정 작업은 어디에서 모니터링할 수 있습니까?

관리 콘솔의 [Capacity] 탭 아래에서 그리고 [Metrics] 탭 아래 CloudWatch 그래프에서 Auto Scaling으로 트리거된 조정 작업의 상태를 모니터링할 수 있습니다.

Q: 테이블에 활성 Auto Scaling 정책이 적용되고 있는지 어떻게 알 수 있습니까?

DynamoDB 콘솔에서 왼쪽 메뉴에 있는 [Tables]를 클릭하여 계정 내 모든 DynamoDB 테이블 목록 보기를 표시하면 됩니다. 활성 Auto Scaling 정책이 적용된 테이블의 경우, Auto Scaling이 읽기, 쓰기 또는 둘 다에 대해 활성화되어 있는지에 따라 [Auto Scaling] 열에 READ_CAPACITY, WRITE_CAPACITY 또는 READ_AND_WRITE가 표시됩니다. 또한, 테이블의 [Overview] 탭의 [Table details] 섹션 아래를 보면 프로비저닝된 용량 레이블이 Auto Scaling이 읽기, 쓰기 또는 둘 다에 대해 활성화되어 있는지를 보여줍니다.

Q: 활성 정책이 적용된 테이블이나 글로벌 보조 인덱스를 삭제하는 경우 Auto Scaling 정책은 어떻게 됩니까?

콘솔에서 테이블이나 글로벌 보조 인덱스를 삭제하면, 해당 Auto Scaling 정책과 연결된 Cloud Watch 경보도 삭제됩니다.

Q: Auto Scaling을 사용하려면 추가 비용이 듭니까?

아니요. DynamoDB 및 CloudWatch 경보에 대해 이미 지불하고 있는 비용 외에 Auto Scaling을 사용하는 데 대한 추가 비용은 없습니다. DynamoDB 요금에 대한 자세한 내용은 DynamoDB 요금 페이지를 참조하십시오.

Q: Auto Scaling에서 관리하는 처리 용량은 내 예약 용량과 어떻게 연동됩니까?

Auto Scaling은 현재 수동으로 프로비저닝된 처리 용량과 같은 방식으로 예약 용량을 처리합니다. 예약 용량은 이를 구매한 리전의 총 프로비저닝된 용량에 포함됩니다. Auto Scaling에서 프로비저닝한 용량은 예약 용량을 먼저 사용하게 되며 할인된 요금이 청구됩니다. 초과 용량이 발생하는 경우 표준 요금이 부과됩니다. 구매한 예약 용량에 대한 총사용량을 제한하려면, 누적 용량이 구매한 총 예약 용량보다 적도록 Auto Scaling이 활성화된 모든 테이블에 최대 용량 한도를 적용합니다.


Q: 글로벌 보조 인덱스란 무엇입니까?

글로벌 보조 인덱스는 테이블의 기본 키와는 다를 수 있는 파티션 키 또는 파티션-정렬 키가 포함된 인덱스입니다.

테이블의 데이터에 효율적으로 액세스하기 위해 Amazon DynamoDB는 주요 키 속성에 대한 인덱스를 생성하여 유지 관리합니다. 이를 통해 애플리케이션은 주요 키 값을 지정하여 데이터를 신속하게 검색할 수 있습니다. 그러나 많은 애플리케이션에서는 주요 키가 아닌 속성을 가진 데이터에 효율적으로 액세스할 수 있다는 장점을 활용하기 위해 하나 이상의 보조(또는 대체) 키를 사용하기도 합니다. 이를 해결하기 위해 테이블에 하나 이상의 보조 인덱스를 생성하고 이러한 인덱스에 대한 쿼리 요청을 발행할 수 있습니다.

Amazon DynamoDB는 두 가지 유형의 보조 인덱스를 지원합니다.

  • 로컬 보조 인덱스 – 이 인덱스는 테이블과 파티션 키는 같지만 정렬 키는 다릅니다. 로컬 보조 인덱스는 로컬 보조 인덱스의 모든 파티션이 동일한 파티션 키를 가진 테이블 파티션으로 한정된다는 의미에서 "로컬"이라고 합니다.
  • 글로벌 보조 인덱스 – 이 인덱스의 파티션 키 또는 파티션-정렬 키는 테이블의 파티션 키 또는 파티션-정렬 키와 다를 수 있습니다. 글로벌 보조 인덱스는 인덱스의 쿼리가 파티션 전반에서 테이블의 모든 아이템을 포괄할 수 있으므로 "글로벌"이라고 간주합니다. 

보조 인덱스는 Amazon DynamoDB에 의해 자동으로 스파스 객체로서 유지 관리됩니다. 인덱스가 정의된 테이블에 항목이 존재하는 경우에만 해당 항목이 인덱스에 나타납니다. 이렇게 하면 인덱스에 대한 쿼리가 매우 효율적으로 수행되는데, 인덱스에 있는 항목의 수가 테이블에 있는 항목의 수보다 매우 적어지는 경우가 많기 때문입니다.

글로벌 보조 인덱스는 고유하지 않은 속성을 지원하므로 테이블에 있는 키가 아닌 모든 속성에 대한 쿼리를 가능하게 하여 쿼리의 유연성을 높입니다.

주요 키가 UserId(파티션) 및 GameTitle(정렬)로 이루어진 DynamoDB 테이블에 플레이어 정보를 저장하는 게임 애플리케이션이 있다고 가정해 보겠습니다. 항목에는 TopScore, Timestamp, ZipCode 등의 속성이 있습니다. 테이블을 생성할 때 DynamoDB는 주요 키에 암시적 인덱스(주요 인덱스)를 제공하여 모든 게임에 대해 특정 사용자의 최고 점수를 반환하는 효율적인 쿼리를 지원할 수 있습니다.

그러나 애플리케이션에서 특정 게임에 대한 사용자의 최고 점수를 필요로 하는 경우 이러한 주요 인덱스를 사용하면 전체 테이블을 스캔해야 하기 때문에 비효율적일 수 있습니다. 그 대신, 파티션 키 요소가 GameTitle이고 정렬 키 요소가 TopScore인 글로벌 보조 인덱스를 사용하면 애플리케이션에서 해당 게임에 대한 최고 점수를 신속하게 검색할 수 있습니다.

GSI에 반드시 정렬 키 요소가 있어야 하는 것은 아닙니다. 예를 들어 GSI에는 GameTitle이라는 파티션 요소로만 이루어진 키가 있을 수 있습니다. 아래 예시에서 GSI에 프로젝션된 속성이 없으므로, GSI는 쿼리한 GameTitle과 일치하는 속성이 있는 모든 항목(주요 키에 의해 식별됨)을 반환합니다.

Q: 언제 글로벌 보조 인덱스를 사용해야 합니까?

글로벌 보조 인덱스는 서로 다른 값을 많이 가지고 있는 속성 간 관계를 추적하는 데 특히 유용합니다. 예를 들어 우편번호가 많고 고객도 많은 경우 테이블에 대한 기본 파티션 키가 CustomerID이고 글로벌 보조 인덱스에 대한 파티션 키가 ZipCode인 DynamoDB 테이블을 생성할 수 있습니다. 이 경우 주요 키를 사용하면 모든 고객에 대한 기록을 빠르게 입수할 수 있으며 글로벌 보조 인덱스를 사용하면 해당 우편번호에서 거주하고 있는 모든 고객에 대해 효율적으로 쿼리를 수행할 수 있습니다.

글로벌 보조 인덱스 용량을 최대한으로 활용하려면 균일 워크로드에서의 모범 사례 설명서를 검토하시기 바랍니다.

Q: DynamoDB 테이블에 대한 글로벌 보조 인덱스를 생성하려면 어떻게 해야 합니까?

테이블과 연결된 GSI는 언제든 지정할 수 있습니다. 테이블 및 테이블의 인덱스를 생성하는 자세한 단계는 여기를 참조하십시오. 테이블당 최대 5개의 글로벌 보조 인덱스를 생성할 수 있습니다.

Q: DynamoDB 로컬 버전에서 글로벌 보조 인덱스를 지원합니까?

예. DynamoDB 로컬 버전은 DynamoDB 기반 애플리케이션을 개발하고 테스트하는 데 유용합니다. DynamoDB 로컬 버전을 여기에서 다운로드할 수 있습니다.

Q: 프로젝션된 속성이란 무엇입니까?

보조 인덱스에 있는 데이터는 테이블에서 인덱스로 프로젝션되거나 복사된 속성으로 이루어져 있습니다. 보조 인덱스를 생성할 때 해당 인덱스로 프로젝션되기를 원하는 다른 모든 속성과 함께 인덱스에 대한 대체 키를 정의합니다. Amazon DynamoDB는 이러한 속성을 테이블의 주요 키 속성과 함께 인덱스로 복사합니다. 그러면 사용자는 테이블을 쿼리하는 것처럼 인덱스를 쿼리할 수 있습니다.

Q: 글로벌 보조 인덱스 키는 고유하지 않은 속성에서 정의될 수 있습니까?

예. 테이블의 주요 키와는 달리, GSI의 경우 인덱싱된 속성이 고유하지 않아도 됩니다. 예를 들어 GameTitle의 GSI는 모든 게임에 대해 사용자의 점수를 추적하는 모든 항목을 인덱싱할 수 있습니다. 이 예시에서 이 GSI는 "TicTacToe" 게임을 해본 적이 있는 모든 사용자를 반환하도록 쿼리될 수 있습니다.

Q: 글로벌 보조 인덱스는 로컬 보조 인덱스와 어떻게 다릅니까?

글로벌과 로컬 보조 인덱스 모두 쿼리 유연성을 향상합니다. LSI는 특정 파티션 키 값에 연결되는 반면, GSI는 모든 파티션 키 값을 포괄합니다. 동일한 파티션 키 값을 가진 항목은 DynamoDB에서 동일한 파티션을 공유하므로, "로컬" 보조 인덱스는 동일한 파티션에 함께 저장된 항목만을 다룹니다. 이처럼 LSI의 목적은 파티션 키 값은 같지만 정렬 키 값은 다른 항목을 쿼리하기 위한 것입니다. 예를 들어 고객의 주문을 추적하며 파티션 키가 CustomerId인 DynamoDB 테이블이 있다고 가정해 보겠습니다.

OrderTime의 LSI를 사용하면 특정 고객이 최근에 주문한 항목을 검색할 수 있어 효율적으로 쿼리할 수 있습니다.

반면 GSI는 일반적인 파티션 키 값이 있는 항목으로만 제한되지 않으며, 대신 기본 키와 마찬가지로 테이블의 모든 항목을 포괄합니다. 위 테이블의 경우 ProductId의 GSI는 특정 제품에 대한 모든 주문을 찾는 데 효율적으로 사용될 수 있습니다. 이 경우 어떠한 GSI 정렬 키도 지정되지 않으며 동일한 ProductId를 가진 주문이 많은 경우에도 GSI에서는 개별적인 항목으로 저장된다는 점에 유의하십시오.

테이블의 데이터와 인덱스가 동일한 파티션에 코로케이션되도록 LSI는 모든 요소(테이블 및 인덱스)의 총 크기가 파티션 키 값당 10GB를 넘지 않도록 제한합니다. GSI는 데이터 코로케이션을 강제 수행하지 않으며 이러한 제한도 없습니다.

테이블을 작성할 때 DynamoDB는 영향을 받는 모든 LSI를 자동으로 업데이트합니다. 반면 테이블에서 정의된 GSI에 대해 이루어진 업데이트는 최종 일관성을 갖습니다.

LSI를 사용하면 Query API를 통해 프로젝션 목록에 포함되지 않은 속성을 검색할 수 있습니다. 이는 GSI에서는 지원되지 않는 동작입니다.

Q: 글로벌 보조 인덱스는 어떻게 작동합니까?

GSI 동작은 여러 면에서 DynamoDB 테이블의 동작과 유사합니다. GSI 정렬 키 요소의 조건부 필터와 함께 GSI의 파티션 키 요소를 사용하여 GSI를 쿼리할 수 있습니다. 그러나 반드시 고유해야 하는 DynamoDB 테이블의 주요 키와는 달리, GSI 키는 여러 항목에 대해 동일할 수 있습니다. 여러 항목에 동일한 GSI 키가 존재할 경우, 이러한 항목은 개별적인 GSI 항목으로 추적되며 GSI 쿼리는 이 모든 항목을 개별 항목으로 검색하게 됩니다. 항목이 추가, 제거 또는 업데이트되면 DynamoDB 내부에서 GSI의 콘텐츠가 적절하게 업데이트되었는지 확인합니다.

DynamoDB는 GSI의 프로젝션된 속성을 GSI 키 및 일치하는 항목의 주요 키와 함께 GSI 데이터 구조에 저장합니다. GSI는 소스 테이블에 존재하는 프로젝션된 항목에 대해 스토리지를 사용합니다. 이렇게 하면 테이블보다는 GSI에 대한 쿼리가 수행되므로 쿼리 유연성이 높아지며 워크로드 분산이 개선됩니다. 테이블의 항목에 속하긴 하지만 GSI 키 또는 테이블의 주요 키에는 속하지 않는 속성 또는 프로젝션된 속성은 GSI 인덱스 쿼리 시 반환되지 않습니다. GSI 쿼리 후 테이블에 있는 데이터가 추가로 필요한 애플리케이션의 경우 GSI에서 주요 키를 검색한 다음 GetItem 또는 BatchGetItem API를 사용하여 테이블에서 원하는 속성을 검색할 수 있습니다. GSI는 최종 일관성을 갖기 때문에, 이러한 패턴을 사용하는 애플리케이션은 GSI 및 GetItem/BatchItem에 대한 호출 사이 테이블의 항목 삭제에 맞춰 조정해야 합니다. 

DynamoDB는 테이블에서 변경이 이루어졌을 때 GSI에서 이에 상응하는 항목 추가, 업데이트 및 삭제를 자동으로 처리합니다. GSI 키 속성이 있는 항목이 테이블에 추가되면 DynamoDB는 GSI를 비동기적으로 업데이트하여 새로운 항목을 추가합니다. 이와 유사하게 테이블에서 항목이 삭제된 경우 DynmoDB는 영향을 받는 GSI에서 해당 항목을 삭제합니다.

Q: 파티션 기반 테이블 및 파티션-정렬 스키마 테이블에 대한 글로벌 보조 인덱스를 생성할 수 있습니까?

예. DynamoDB 테이블의 기본 키 유형과 상관없이 글로벌 보조 인덱스를 생성할 수 있습니다. 테이블의 기본 키는 파티션 키만 포함하거나, 파티션 키와 정렬 키를 모두 포함할 수 있습니다.

Q: 글로벌 보조 인덱스에 대한 일관성 모델은 무엇입니까?

GSI는 최종 일관성을 지원합니다. 항목이 테이블에 삽입되었거나 업데이트되었을 때 GSI는 동시에 업데이트되지 않습니다. 일반적인 운영 조건에서 글로벌 보조 인덱스로의 쓰기는 순식간에 전파됩니다. 발생 확률은 낮지만 장애 발생 시, 지연 시간이 길어질 수 있습니다. 그러므로 사용자의 애플리케이션 로직은 오래되었을 가능성이 있는 GSI 쿼리 결과를 처리할 수 있어야 합니다. Eventually consistent read를 지원하는 다른 DynamoDB API에서도 이와 동일한 동작이 나타난다는 점에 유의하십시오.

각 항목에 UserId, GameTitleTopScore 속성이 있으며 최고 점수를 추적하는 테이블이 있다고 가정해 보겠습니다. 파티션 키는 UserId이고 기본 정렬 키는 GameTitle입니다. 애플리케이션에서 GameTitle "TicTacToe" 및 UserId "GAMER123"에 대한 새로운 최고 점수를 나타내는 항목을 추가한 다음 GSI를 쿼리하면 새로운 점수가 쿼리 결과에 나타나지 않을 가능성이 있습니다. 그러나 GSI 전파가 완료되면 GSI의 쿼리에 새로운 항목이 나타나기 시작합니다.

Q: 테이블 및 각 글로벌 보조 인덱스에 대해 개별적으로 처리량을 프로비저닝할 수 있습니까?

예. GSI는 기반이 되는 테이블의 처리량을 독립적으로 처리합니다. 콘솔에서 새로운 테이블이나 기존 테이블에 대해 Auto Scaling을 활성화할 때, 동일 설정을 GSI에 적용하도록 선택할 수 있습니다. 또한, 수동으로 테이블과 글로벌 보조 인덱스에 서로 다른 처리량을 프로비저닝할 수 있습니다.

애플리케이션에 따라 GSI의 요청 워크로드는 테이블 또는 다른 GSI의 요청 워크로드와 크게 차이가 날 수 있습니다. 아래와 같이 일부 시나리오에서 이를 확인할 수 있습니다.

  • 테이블 항목의 작은 부분을 포함하고 있는 GSI는 테이블보다 훨씬 낮은 쓰기 처리량이 필요합니다.
  • 드물게 발생하는 항목 조회에 사용되는 GSI는 테이블보다 훨씬 낮은 읽기 처리량이 필요합니다.
  • 읽기 중심의 백그라운드 작업에 사용되는 GSI는 하루에 몇 시간 동안 높은 읽기 처리량이 필요할 수 있습니다.

필요에 따라 테이블의 프로비저닝된 처리량과 독립적으로 GSI의 프로비저닝된 처리량을 변경할 수 있습니다.

모든 속성을 프로젝션하는 GSI와 항목의 50%에 GSI 키가 있는 DynamoDB 테이블이 있다고 가정해 보겠습니다. 이 경우 GSI의 프로비저닝된 쓰기 용량 유닛은 테이블의 프로비저닝된 쓰기 용량 유닛의 50%로 설정되어야 합니다. GSI의 읽기 처리량 또한 이와 유사한 방식을 사용하여 추정할 수 있습니다. 자세한 내용은 DynamoDB GSI 설명서를 참조하십시오.

Q: 글로벌 보조 인덱스 추가가 테이블에 대해 프로비저닝된 처리량 및 스토리지에 어떤 영향을 미칩니까?

DynamoDB 테이블과 유사하게, GSI는 GSI에 읽기 또는 쓰기가 수행될 때 프로비저닝된 처리량을 사용합니다. GSI 항목을 추가하거나 업데이트하는 쓰기는 업데이트 크기에 따라 쓰기 용량 유닛을 사용합니다. GSI 쓰기에 사용되는 용량은 테이블의 항목을 업데이트하는 데 사용되는 용량에 추가됩니다.

DynamoDB 테이블에 항목을 추가하거나, 삭제하거나, 업데이트하였으며 이러한 작업이 GSI를 변경하지 않는 경우 GSI는 쓰기 용량 유닛을 전혀 사용하지 않습니다. 이는 GSI 키 속성이 없는 항목이 DynamoDB 테이블에 추가되었거나 항목이 GSI 키 또는 프로젝션된 속성 변경 없이 업데이트된 경우에 해당합니다.

GSI로의 쿼리는 쿼리가 검사한 항목 크기에 따라 읽기 용량 유닛을 사용합니다.

GSI에 대한 스토리지 비용은 해당 GSI에 저장된 총 바이트 수에 따라 결정됩니다. 여기에는 인덱싱을 목적으로 한 GSI 키와 프로젝션된 속성 및 값, 100바이트의 오버헤드가 포함됩니다.

Q: DynamoDB가 GSI의 프로비저닝된 처리량으로 인해 애플리케이션에서 테이블로의 쓰기를 제한할 수 있습니까?

DynamoDB 테이블로의 일부 또는 모든 쓰기는 관련 GSI의 쓰기로 이어지기 때문에 GSI의 프로비저닝된 처리량이 고갈될 가능성이 있습니다. 이러한 시나리오에서 이후 테이블로의 쓰기는 제한되며 테이블에 사용 가능한 쓰기 용량 유닛이 있더라도 마찬가지입니다.

Q: 인덱스 수준에서 프로비저닝된 처리량은 얼마나 자주 변경할 수 있습니까?

GSI가 있는 테이블은 일반 테이블과 마찬가지로 처리량 변경 작업에 대한 일일 제한이 있으며 그 횟수도 일반 테이블과 동일합니다.

Q: DynamoDB 글로벌 보조 인덱스의 사용료는 어떻게 청구됩니까?

테이블 및 테이블의 GSI에 대해 프로비저닝된 처리량을 시간별로 집계하여 청구됩니다. 필수는 아니지만 수동으로 프로비저닝하는 경우에는 테이블과 해당 GSI에 대해 총 프로비저닝된 처리량에 대해 시간당 요금이 부과됩니다. 또한, GSI에서 사용한 데이터 스토리지에 대한 요금과 표준 데이터 전송(외부) 요금이 부과됩니다. GSI의 프로비저닝된 처리 용량을 변경하려는 경우 DynamoDB 콘솔, UpdateTable API 또는 PutScalingPolicy API를 사용하여 Auto Scaling 정책 설정을 업데이트하면 됩니다.

Q: 쿼리에 사용될 글로벌 보조 인덱스를 지정할 수 있습니까?

예. 일반적인 쿼리 파라미터에 더하여 GSI Query 명령은 작업을 수행할 GSI의 이름을 명시적으로 포함합니다. 쿼리는 하나의 GSI만을 사용할 수 있다는 점에 유의하십시오.

Q: 글로벌 보조 인덱스에서 지원하는 API 호출은 무엇입니까?

GSI가 지원하는 API 호출은 QueryScan입니다. 쿼리 작업은 인덱스 키 속성 값만 검색하며 비교 연산자의 하위 세트만 지원합니다. GSI는 각각 업데이트되기 때문에 쿼리와 함께 ConsistentRead 파라미터를 사용할 수 없습니다. 쿼리 및 스캔과 함께 GSI를 사용하는 것에 대해 자세히 알아보려면 여기를 참조하십시오.

Q: 글로벌 보조 인덱스를 스캔한 결과는 어떤 순서대로 표시됩니까?

파티션 전용 키 스키마를 사용하는 글로벌 보조 인덱스의 경우, 표시되는 순서가 없습니다. 파티션-정렬 키 스키마를 사용하는 글로벌 보조 인덱스의 경우, 동일한 파티션 키에 표시되는 결과 순서는 정렬 키 속성에 따라 다릅니다.

Q: 테이블을 생성한 이후에 글로벌 보조 인덱스를 변경할 수 있습니까?

예. 글로벌 보조 인덱스는 테이블을 생성한 후라도 언제든 변경할 수 있습니다.

Q: 기존 테이블에 글로벌 보조 인덱스를 어떻게 추가합니까?

콘솔 또는 API 호출을 통해 글로벌 보조 인덱스를 추가할 수 있습니다. DynamoDB 콘솔에서 먼저 글로벌 보조 인덱스를 추가할 테이블을 선택한 다음 "Create Index" 버튼을 클릭하여 새 인덱스를 추가합니다. 인덱스 생성 마법사의 단계대로 수행하고, 모두 마치면 "Create"를 선택합니다. GlobalSecondaryIndexes 파라미터와 함께 UpdateTable API 호출을 사용하여 글로벌 보조 인덱스를 추가 또는 삭제할 수도 있습니다. 설명서 페이지에서 자세히 알아보십시오.

Q: 글로벌 보조 인덱스를 어떻게 삭제합니까?

콘솔 또는 API 호출을 통해 글로벌 보조 인덱스를 삭제할 수 있습니다. DynamoDB 콘솔에서 글로벌 보조 인덱스를 삭제할 테이블을 선택합니다. 그런 다음 "Table Items" 아래의 "Indexes" 탭을 선택하고 삭제할 인덱스 옆의 "Delete" 버튼을 클릭합니다. UpdateTable API 호출을 사용하여 글로벌 보조 인덱스를 삭제할 수도 있습니다. 설명서 페이지에서 자세히 알아보십시오.

Q: 단일 API 호출을 통해 동일한 테이블에서 둘 이상의 인덱스를 추가 또는 삭제할 수 있습니까?

API 호출당 하나의 인덱스만 추가하거나 삭제할 수 있습니다.

Q: 동일한 인덱스 추가를 위한 요청을 여러 번 제출하면 어떻게 됩니까?

첫 번째 추가 요청만 승인되며, 모든 후속 추가 요청은 첫 번째 추가 요청이 완료될 때까지 실패합니다.

Q: 동일한 테이블에서 여러 인덱스를 동시에 추가 또는 삭제할 수 있습니까?

아니요. 테이블에서는 항상 하나의 인덱스 추가 또는 인덱스 삭제 작업만 활성 상태로 수행할 수 있습니다.

Q: 글로벌 보조 인덱스를 추가하려면 처리량을 추가로 프로비저닝해야 합니까?

Auto Scaling을 사용할 때는 테이블과 동일한 설정을 글로벌 보조 인덱스에 적용하는 것이 좋습니다. 필수는 아니지만 수동으로 프로비저닝하는 경우에는 인덱스용 처리량과 별개로 추가 쓰기 처리량을 프로비저닝하는 것이 좋습니다. 쓰기 처리량을 추가로 프로비저닝하지 않으면 인덱스에 대한 쓰기 처리량이 새 인덱스를 추가하는 데 사용됩니다. 이렇게 되면 인덱스 생성 중 인덱스의 쓰기 성능에 영향을 주고, 새 인덱스를 생성하는 데 드는 시간도 증가합니다.

Q: 인덱스를 생성하고 나면 글로벌 보조 인덱스를 위해 프로비저닝한 추가 처리량을 줄여야 합니까?

예. 모든 프로세스를 마치고 나면 인덱스 추가를 위해 프로비저닝한 추가 쓰기 처리량을 줄여야 합니다.

Q: 글로벌 보조 인덱스 추가를 위해 프로비저닝한 쓰기 처리량을 수정할 수 있습니까?

예. 생성 프로세스 중 언제라도 인덱스 생성을 위해 프로비저닝한 쓰기 처리량을 늘리거나 줄일 수 있습니다.

Q: 글로벌 보조 인덱스를 추가하거나 삭제하는 동안에도 테이블을 계속 사용할 수 있습니까?

예. 글로벌 보조 인덱스를 업데이트하는 중에도 테이블을 사용할 수 있습니다.

Q: 글로벌 보조 인덱스를 추가하거나 삭제하는 동안에도 기존 인덱스를 계속 사용할 수 있습니까?

예. 글로벌 보조 인덱스를 업데이트하는 중에도 기존 인덱스를 사용할 수 있습니다.

Q: 글로벌 보조 인덱스를 생성하여 추가하는 동안 생성된 새 인덱스를 사용할 수 있습니까?

아니요. 새 인덱스는 인덱스 생성 프로세스가 완료된 후에만 사용할 수 있게 됩니다.

Q: 글로벌 보조 인덱스를 추가하는 작업은 얼마나 걸립니까?

이 시간은 테이블의 크기와 글로벌 보조 인덱스 생성을 위해 추가로 프로비저닝한 쓰기 처리량의 양에 따라 달라집니다. 인덱스를 추가 또는 삭제하는 데 걸리는 시간은 몇 분부터 몇 시간까지 다양합니다. 예를 들어, 쓰기 용량 500유닛이 프로비저닝되어 있는 1GB 테이블에서 인덱스 및 새 인덱스 생성을 위해 추가로 1000유닛의 쓰기 용량을 프로비저닝했다고 가정해 보겠습니다. 새 인덱스에 테이블의 모든 속성이 포함되어 있고, 테이블이 모든 쓰기 용량 유닛을 사용 중이라면 인덱스 생성에 약 30분이 걸릴 것으로 예상할 수 있습니다.

Q: 글로벌 보조 인덱스를 삭제하는 작업은 얼마나 걸립니까?

대개 인덱스 삭제는 몇 분이면 끝납니다. 예를 들어, 1GB 데이터의 인덱스를 삭제하면 보통 1분도 걸리지 않습니다.

Q: 글로벌 보조 인덱스 추가 또는 삭제 작업의 진행 상황을 어떻게 추적합니까?

DynamoDB 콘솔 또는 DescribeTable API를 사용해 테이블과 연결된 모든 인덱스의 상태를 확인할 수 있습니다. 인덱스 추가 작업의 경우 인덱스를 생성 중인 동안에는 해당 인덱스의 상태가 "CREATING"이 됩니다. 인덱스 생성이 완료되면 인덱스 상태가 "CREATING"에서 "ACTIVE"로 변경됩니다. 인덱스 삭제 작업의 경우 요청이 완료되면 삭제된 인덱스는 없어집니다.

Q: 글로벌 보조 인덱스 추가를 위한 인덱스 생성 프로세스가 완료되면 알림을 받을 수 있습니까?

인덱스 추가가 완료되었다는 알림을 이메일 주소로 전송해달라고 요청할 수 있습니다. 콘솔을 통해 인덱스를 추가할 때 인덱스 생성 전 마지막 단계에서 알림을 요청하면 됩니다. 인덱스 생성이 완료되면 DynamoDB에서 이메일로 SNS 알림을 전송합니다.

Q: 이미 5개의 글로벌 보조 인덱스가 있는데 더 추가하려고 하면 어떻게 됩니까?

현재는 5개 GSI로 제한되어 있습니다. 그 이상의 "Add" 작업은 실패하고, 오류가 표시됩니다.

Q: 같은 이름의 인덱스를 삭제한 후에 그 이름을 글로벌 보조 인덱스에 다시 사용할 수 있습니까?

예. 글로벌 보조 인덱스를 삭제하고 나면 새 인덱스를 추가할 때 그 인덱스 이름을 다시 사용할 수 있습니다.

Q: 인덱스를 생성 중일 때 인덱스 추가를 취소할 수 있습니까?

아니요. 인덱스 생성이 시작되고 나면 인덱스 생성 프로세스를 취소할 수 없습니다.

Q: GSI 키 속성은 DynamoDB 테이블의 모든 항목에서 필요합니까?

아니요. GSI는 스파스 인덱스입니다. 주요 키가 있을 때의 요구 사항과는 다르게 DynamoDB 테이블의 항목에는 GSI 키가 포함되지 않아도 됩니다. GSI 키에 파티션 및 정렬 요소가 모두 있으나 테이블 항목에서 둘 중 하나가 누락된 경우, 해당 GSI에서는 이 항목을 인덱싱하지 않습니다. 이러한 경우 GSI는 특별한 속성을 가진 항목을 효율적으로 찾는 데 매우 유용할 수 있습니다.

Q: DynamoDB 테이블의 모든 속성을 글로벌 보조 인덱스에서 검색할 수 있습니까?

GSI의 쿼리는 생성 시 GSI에 포함되도록 지정한 속성만을 반환할 수 있습니다. GSI의 키 속성 및 테이블의 주요 키 속성과 같이 기본적으로 프로젝션된 속성 및 사용자가 프로젝션되도록 지정한 속성이 GSI에 포함됩니다. 그러므로 GSI 쿼리는 테이블에 속해 있긴 하지만 GSI에 포함되어 있지 않는 항목의 속성은 반환하지 않습니다. 모든 속성을 프로젝션되는 속성으로 지정한 GSI는 모든 테이블 속성을 검색하는 데 사용할 수 있습니다. 쿼리에 GSI를 사용하는 것에 대한 설명서는 여기를 참조하십시오.

Q: 테이블과 연결된 GSI를 나열하려면 어떻게 해야 합니까?

DescribeTable API는 테이블의 글로벌 보조 인덱스에 대한 세부 정보를 반환합니다.

Q: 어떤 데이터 유형을 인덱싱할 수 있습니까?

숫자, 문자열, 바이너리, 부울 등 모든 스칼라 데이터 유형을 로컬 보조 인덱스 키의 정렬 키 요소로 사용할 수 있습니다. 세트, 목록 및 맵 유형은 인덱싱할 수 없습니다.

Q: 복합 속성 인덱스가 가능합니까?

아니요. 그러나 문자열로 속성을 연결하여 이를 키로 사용할 수는 있습니다.

Q: 어떤 데이터 유형이 GSI에 대해 프로젝션된 속성의 일부가 될 수 있습니까?

세트 유형을 비롯한 모든 데이터 유형을 GSI로 프로젝션될 속성으로 지정할 수 있습니다.

Q: GSI의 확장성 고려 사항은 무엇입니까?

DynamoDB 테이블의 주요 키에 대한 성능 고려 사항은 GSI 키에도 적용됩니다. GSI는 모든 키에 비교적 불규칙한 액세스 패턴이 있다고 가정합니다. 보조 인덱스의 프로비저닝된 처리량을 최대한 활용하려면, 고유한 값을 많이 포함하고 있는 GSI 파티션 키 속성과 가능한 무작위로 균일하게 요청되는 GSI 정렬 키 속성을 선택해야 합니다.

Q: 글로벌 보조 인덱스에 대해 CloudWatch에서 사용 가능한 새로운 지표는 무엇입니까?

GSI가 있는 테이블은 테이블 및 GSI에 대한 집계 지표는 물론 테이블 및 각 GSI에 대한 상세 지표도 제공합니다.

개별 GSI에 대한 보고서는 테이블에서 지원하는 CloudWatch 지표의 하위 세트를 지원합니다. 이점은 다음과 같습니다:

  • 읽기 용량(프로비저닝된 읽기 용량, 사용된 읽기 용량)
  • 쓰기 용량(프로비저닝된 쓰기 용량, 사용된 쓰기 용량)
  • 제한된 읽기 이벤트
  • 제한된 쓰기 이벤트

DynamoDB 테이블 및 인덱스가 지원하는 지표에 대해 자세히 알아보려면 여기를 참조하십시오.

Q: 글로벌 보조 인덱스를 어떻게 스캔합니까?

글로벌 보조 인덱스는 콘솔 또는 Scan API를 통해 스캔할 수 있습니다.

글로벌 보조 인덱스를 스캔하려면 스캔하려는 테이블의 이름 및 인덱스를 명시적으로 참조해야 합니다. 인덱스 파티션 속성 이름과 값을 지정해야 합니다. 선택적으로 인덱스 키 정렬 속성에 대한 조건을 지정할 수 있습니다.

Q: 글로벌 보조 인덱스를 스캔하면 프로젝션되지 않은 속성이 결과 집합에 반환되도록 지정할 수 있습니까?

글로벌 보조 인덱스를 스캔하면 프로젝션되지 않은 속성을 가져올 수 없습니다.

Q: 인덱스에 병렬 스캔이 지원됩니까?

예, 인덱스에 병렬 스캔이 지원되며 의미 체계는 기본 테이블의 의미 체계와 동일합니다.


Q: 로컬 보조 인덱스란 무엇입니까?

로컬 보조 인덱스를 사용하면 많은 항목을 검색한 후 결과를 필터링하지 않아도 되므로 일부 일반 쿼리를 보다 빠르고 비용 효율적으로 실행할 수 있습니다. 애플리케이션은 좀 더 넓은 범위의 속성을 기반으로 더욱 유연한 쿼리를 사용할 수 있습니다.

로컬 보조 인덱스가 출시되기 전에는 한 파티션(동일한 파티션 키를 공유한 항목) 안에서 특정 항목을 찾으려는 경우 DynamoDB가 하나의 파티션 키를 공유한 모든 객체를 가져온 후 결과를 필요에 맞게 필터링해야 했습니다. 예를 들어 고객 주문 데이터를 customer id-order timestamp의 파티션-정렬 스키마로 DynamoDB 테이블에 저장하는 전자 상거래 애플리케이션이 있다고 가정해 보겠습니다. LSI를 사용하지 않고 "지난 30일간 배송된 고객 X의 모든 주문을 배송일로 정렬해 보여주십시오."라는 질문에 답하기 위해서는, Query API를 사용하여 파티션 키 'X'의 모든 객체를 검색하고, 결과를 배송일로 정렬한 후, 30일 이전의 기록을 필터링해야 했습니다.

로컬 보조 인덱스를 사용하면 이 작업은 간단해집니다. 이제 "배송일" 속성에 인덱스를 생성하고 쿼리를 효율적으로 실행하면 바로 필요한 항목만 검색할 수 있습니다. 특정 기준을 만족하는 항목만 검색하므로 지연 시간과 쿼리 비용을 상당히 줄일 수 있습니다. 게다가 결과를 필터링하기 위해 고객 로직을 작성할 필요가 없어 애플리케이션의 프로그래밍 모델이 간소화됩니다. 이 새로운 보조 인덱스는 파티션 키와 함께 사용되고 파티션 키 버킷 안에서 로컬로 검색할 수 있으므로, '로컬' 보조 인덱스라고 부릅니다. 이전에는 파티션 키와 정렬 키만을 사용하여 검색할 수 있었지만, 이제는 정렬 키 대신 보조 인덱스를 사용해 검색할 수 있습니다. 따라서 쿼리를 효율적으로 수행하는 데 사용할 수 있는 속성의 수를 증가합니다.

중복된 데이터 속성의 사본은 사용자가 정의한 로컬 보조 인덱스에 복사됩니다. 이러한 속성에는 테이블 파티션 및 정렬 키와 더불어 사용자가 정의한 대체 정렬 키가 포함됩니다. 또한, 테이블에 액세스하지 않고 다른 속성에 액세스하도록 로컬 보조 인덱스에 다른 데이터 속성을 중복 저장할 수도 있습니다.

하지만 로컬 보조 인덱스가 모든 애플리케이션에 적합한 것은 아닙니다. 로컬 보조 인덱스로 인해 단일 파티션 키 값에 저장할 수 있는 데이터 볼륨에 일부 제약 조건이 발생합니다. 자세한 정보는 아래에서 항목 모음에 대한 FAQ 항목을 참조하십시오.

Q: 프로젝션이란 무엇입니까?

로컬 보조 인덱스에 복사된 속성 집합을 프로젝션이라 합니다. 프로젝션으로 가장 효율적으로 검색할 수 있는 속성이 결정됩니다. 로컬 보조 인덱스를 쿼리하는 경우 Amazon DynamoDB는 소유한 테이블 안에 있는 속성과 동일한 성능 특성으로 프로젝션된 모든 속성에 액세스할 수 있습니다. 프로젝션되지 않은 속성을 검색하는 경우 Amazon DynamoDB는 자동으로 테이블에서 해당 속성을 가져옵니다.

로컬 보조 인덱스를 정의할 때 인덱스에 프로젝션될 속성을 지정해야 합니다. 각 인덱스는 최소한 (1) 테이블 파티션 키 값, (2) 인덱스 정렬 키로 사용될 속성, (3) 테이블 정렬 키 값으로 구성됩니다.

최소 구성 요소 이외에 키가 아닌 속성의 사용자 지정 목록을 선택하여 인덱스에 프로젝션할 수도 있습니다. 또한, 인덱스에 모든 속성을 프로젝션하도록 선택할 수 있습니다. 이 경우 인덱스가 테이블과 동일한 데이터를 복제하지만, 데이터는 지정한 대체 정렬 키에 의해 구성됩니다.

Q: LSI는 어떻게 생성합니까?

LSI는 테이블을 만들 때 생성해야 합니다. 현재는 테이블을 생성한 이후에는 추가할 수 없습니다. LSI를 생성하려면 다음 파라미터 두 개를 지정해야 합니다.

인덱싱된 정렬 키 – 인덱싱되고 쿼리될 속성입니다.

프로젝션된 속성 – 로컬 보조 인덱스에 직접 복사될 테이블의 속성 목록으로 테이블의 모든 항목을 포함하는 기본 인덱스에서 데이터를 가져오지 않고 더 빠르게 결과를 반환하는 데 사용됩니다. 프로젝션된 속성이 없으면 로컬 보조 인덱스는 기본 및 보조 인덱스 키로만 구성됩니다.

Q: LSI용 일관성 모델이란 무엇입니까?

로컬 보조 인덱스는 기본 인덱스가 업데이트될 때 자동 업데이트됩니다. 기본 인덱스 읽기와 유사하게 LSI는 strongly consistent read 및 eventually consistent read 옵션을 지원합니다.

Q: 로컬 보조 인덱스는 테이블의 모든 항목에 대한 참조를 포함합니까?

아니요, 포함하지 않을 수도 있습니다. 로컬 보조 인덱스는 해당 LSI에 지정된 인덱싱된 정렬 키를 포함하는 항목만 참조합니다. DynamoDB의 유연한 스키마에서는 모든 항목이 모든 속성을 포함하는 것은 아닙니다.

로컬 보조 인덱스는 기본 인덱스에 비해 수가 적을 수 있습니다. 로컬 보조 인덱스에는 데이터가 항상 저장되지 않아도 되므로 특이한 속성에 대한 쿼리를 지원하는 데 효율적입니다.

예를 들면 위에 설명한 주문의 예에서 고객은 CanceledDateTime과 CanceledReason처럼 주문이 취소된 경우에만 포함할 추가 속성이 있을 수 있습니다. 취소된 항목과 관련된 쿼리의 경우, 인덱스에 참조된 항목에만 해당 속성이 존재하므로 이러한 두 속성에 대해서는 로컬 보조 인덱스가 효율적일 것입니다.

Q: 로컬 보조 인덱스를 쿼리하려면 어떻게 해야 합니까?

로컬 보조 인덱스는 Query API를 통해서만 쿼리할 수 있습니다.

로컬 보조 인덱스를 쿼리하려면 쿼리하려는 테이블의 이름 및 인덱스를 명시적으로 참조해야 합니다. 인덱스 파티션 속성 이름과 값을 지정해야 합니다. 선택적으로 인덱스 키 정렬 속성에 대한 조건을 지정할 수 있습니다.

쿼리는 읽기 용량 유닛을 추가로 소비하는 테이블 가져오기 작업을 수행함으로써 기본 인덱스에 저장된 프로젝션되지 않은 속성을 가져올 수 있습니다.

Strongly consistent read 및 Eventually consistent read 옵션이 로컬 보조 인덱스를 사용하는 쿼리에서 지원됩니다.

Q: 로컬 보조 인덱스를 생성하려면 어떻게 해야 합니까?

로컬 보조 인덱스는 테이블을 생성할 때 정의해야 합니다. 테이블의 기본 인덱스는 파티션-정렬 복합 키를 사용해야 합니다.

Q: 기존 테이블에 로컬 보조 인덱스를 추가할 수 있습니까?

아니요, 현재 기존 테이블에 로컬 보조 인덱스를 추가할 수는 없습니다. 이 기능을 추가하기 위해 작업 중이며 추후에 출시할 예정입니다. 로컬 보조 인덱스가 있는 테이블을 생성하는 경우, 현재는 사용하지 않는 정렬 키 요소를 정의하여 향후 사용을 위해 로컬 보조 인덱스를 생성할 수도 있습니다. 로컬 보조 인덱스에는 데이터가 저장되어 있지 않을 수 있으므로 사용하기 전까지 비용이 발생하지 않습니다.

Q: 한 테이블에 로컬 보조 인덱스는 몇 개나 생성할 수 있습니까?

각 테이블에 로컬 보조 인덱스를 5개까지 생성할 수 있습니다.

Q: 한 테이블에 키가 아닌 프로젝션 속성은 몇 개나 생성할 수 있습니까?

각 테이블에는 테이블 내의 전체 로컬 보조 인덱스에서 키가 아닌 프로젝션된 속성을 총 20개까지 만들 수 있습니다. 또한 각 인덱스는 기본 인덱스의 키 이외의 속성이 모두 프로젝션되도록 지정할 수 있습니다.

Q: 이미 생성된 인덱스를 수정할 수 있습니까?

아니요, 인덱스를 생성한 후에는 수정할 수 없습니다. 추후에 이 기능을 지원하기 위해 작업 중입니다.

Q: 로컬 보조 인덱스를 삭제할 수 있습니까?

아니요, 현재 로컬 보조 인덱스를 생성한 후에는 테이블에서 삭제할 수 없습니다. 물론 전체 테이블을 삭제하는 경우에는 삭제됩니다. 이 기능을 추가하기 위해 작업 중이며 추후에 출시할 예정입니다.

Q: 로컬 보조 인덱스는 프로비저닝된 용량을 어떻게 소비합니까?

로컬 보조 인덱스에 대한 용량을 명시적으로 프로비저닝할 필요는 없습니다. 로컬 보조 인덱스는 연결된 테이블의 일부로서 프로비저닝된 용량을 소비합니다.

LSI 읽기 및 테이블에 LSI 쓰기는 데이터 1KB당 1유닛의 표준 공식에 따라 용량을 소비하며 다음과 같은 차이가 있습니다.

쓰기가 하나 이상의 로컬 보조 인덱스와 관련된 데이터를 포함하는 경우 해당 쓰기는 적합한 로컬 보조 인덱스로 미러링됩니다. 이러한 경우 테이블 자체에 대해 쓰기 용량이 소비되며 관련된 LSI 별로도 추가 쓰기 용량이 소비됩니다.

기존 항목을 덮어쓰는 업데이트는 삭제 및 추가의 두 가지 작업을 발생시키므로 데이터 1KB당 쓰기 용량 유닛을 추가로 소비합니다.

읽기 쿼리가 LSI에 프로젝션되지 않은 속성을 요청하는 경우 DynamoDB는 기본 인덱스에서 해당 속성을 가져옵니다. 이 암시적 GetItem 요청은 가져온 항목 데이터 4KB 당 1유닛의 읽기 용량을 소비합니다.

Q: 로컬 보조 인덱스가 소비하는 스토리지 양은 얼마나 됩니까?

로컬 보조 인덱스는 각 LSI의 기본 및 인덱스 키의 속성 이름 및 값과 키가 아닌 모든 프로젝션된 속성에 대해 스토리지를 소비하며, 추가로 LSI에 반영된 항목당 100바이트의 스토리지를 소비합니다.

Q: 어떤 데이터 유형을 인덱싱할 수 있습니까?

숫자, 문자열, 바이너리 등 모든 스칼라 데이터 유형을 로컬 보조 인덱스 키의 정렬 키 요소로 사용할 수 있습니다. 세트 유형은 사용할 수 없습니다.

Q: 어떤 데이터 유형을 로컬 보조 인덱스로 프로젝션할 수 있습니까?

세트 유형을 포함한 모든 데이터 유형을 로컬 보조 인덱스에 프로젝션할 수 있습니다.

Q: 항목 모음이란 무엇이고 LSI와 어떤 관련이 있습니까?

Amazon DynamoDB에서 항목 모음은 테이블 및 테이블 내의 모든 로컬 보조 인덱스에서 동일한 파티션 키를 가진 항목의 그룹을 말합니다. 기존의 파티셔닝된(또는 샤딩된) 관계형 데이터베이스 시스템에서는 이를 샤드 또는 파티션이라 하며, 하나의 파티션 키 아래에 저장된 모든 데이터베이스 항목 또는 행을 의미합니다.

항목 모음은 로컬 보조 인덱스가 포함된 모든 테이블에 대해 자동으로 생성되어 유지됩니다. DynamoDB는 단일 디스크 파티션에 각 항목 모음을 저장합니다.

Q: 항목 모음의 크기에 제한이 있습니까?

Amazon DynamoDB의 모든 항목 모음 크기는 최대 10GB로 제한됩니다. 고유한 파티션 키 값의 경우, 테이블의 항목 크기 합에 테이블의 모든 로컬 보조 인덱스 항목 크기의 합을 더한 값이 10GB를 초과해서는 안 됩니다.

항목 모음에 대한 10GB 제한은 로컬 보조 인덱스가 없는 테이블에는 적용되지 않고 하나 이상의 로컬 보조 인덱스가 있는 테이블에만 적용됩니다.

개별 항목 모음의 크기는 제한되어 있지만, 로컬 보조 인덱스가 있는 전체 테이블의 스토리지 크기에는 제한이 없습니다. 각 파티션 키 값에 대한 총 스토리지 크기(테이블 및 인덱스)가 10GB를 초과하지 않는 한, Amazon DynamoDB에서 인덱싱된 테이블의 총 크기에는 제한이 없습니다.

Q: 항목 모음의 크기를 추적하려면 어떻게 해야 합니까?

DynamoDB의 쓰기 API(PutItem, UpdateItem, DeleteItem 및 BatchWriteItem)에는 API 응답에 관련 항목 모음의 추정치를 포함하도록 하는 옵션이 있습니다. 이 추정치에는 특정 항목 모음의 데이터에 대한 최소 및 최대 크기 추정치가 포함되며 기가바이트로 측정됩니다.

애플리케이션을 활용하여 항목 모음의 크기를 모니터링하는 것이 좋습니다. 애플리케이션에서는 항목 모음 크기에 대한 API 응답을 점검하여 항목 모음이 사용자가 정한 제한(예를 들면, 8GB)을 초과할 때마다 오류 메시지를 기록해야 합니다. 이는 조기 경보 시스템으로 작동하여 항목 모음이 커지는 것을 알리고 조치를 취할 수 있는 충분한 시간을 제공합니다.

Q: 한 항목 모음이 10GB 제한을 초과하면 어떻게 됩니까?

특정 항목 모음이 10GB 제한을 초과하는 경우 새로운 항목을 쓸 수 없거나 특정 파티션 키에 대한 기존 항목 크기를 늘릴 수 없게 됩니다. 항목 모음의 크기를 줄이는 읽기 및 쓰기 작업은 계속할 수 있습니다. 테이블의 다른 항목 모음은 영향을 받지 않습니다.

이 문제를 해결하려면 모음내의 항목을 삭제하거나 10GB를 초과하는 항목의 크기를 줄입니다. 또는 이 문제에 대한 차선책으로 새로운 파티션 키 값 아래에서 새로운 항목을 생성할 수 있습니다. 테이블에 액세스 빈도가 낮은 오래된 데이터가 포함된 경우 Amazon S3, Amazon Glacier 또는 다른 데이터 스토리지에 오래된 데이터를 보관하는 것을 고려해 볼 수 있습니다.

Q: 로컬 보조 인덱스를 어떻게 스캔합니까?

로컬 보조 인덱스를 스캔하려면 스캔하려는 테이블의 이름 및 인덱스를 명시적으로 참조해야 합니다. 인덱스 파티션 속성 이름과 값을 지정해야 합니다. 선택적으로 인덱스 키 정렬 속성에 대한 조건을 지정할 수 있습니다.

스캔은 읽기 용량 유닛을 추가로 소비하여 테이블 가져오기 작업을 수행함으로써 기본 인덱스에 저장된 프로젝션되지 않은 속성을 가져올 수 있습니다.

Q: 로컬 보조 인덱스를 스캔하면 프로젝션되지 않은 속성이 결과 집합에 반환되도록 지정할 수 있습니까?

로컬 보조 인덱스를 스캔하면 프로젝션되지 않은 속성을 가져올 수 있습니다.

Q: 로컬 보조 인덱스를 스캔한 결과는 어떤 순서대로 표시됩니까?

로컬 보조 인덱스의 경우 결과 모음에서의 순서는 인덱싱된 속성의 순서를 기준으로 합니다.


Q: DynamoDB Fine-Grained Access Control이란 무엇입니까?

Fine-Grained Access Control(FGAC)은 DynamoDB 테이블 소유자가 테이블의 데이터를 높은 수준으로 제어할 수 있도록 합니다. 특히 테이블 소유자는 누가(호출자) 테이블의 어떠한 항목 또는 속성에 액세스할 수 있는지, 무슨 작업(읽기/쓰기 기능)을 수행할 수 있는지 지정할 수 있습니다. FGAC는 보안 자격 증명 및 연결된 권한을 관리하는 AWS Identity and Access Management(IAM)와 함께 사용됩니다.

Q: DynamoDB FGAC에 대한 일반적인 사용 사례에는 어떤 것이 있습니까?

FGAC는 최종 사용자(또는 최종 사용자를 대신하여 작업하는 애플리케이션 클라이언트)가 중간 계층 서비스 없이 테이블을 직접 읽거나 수정하길 원하는 DynamoDB 테이블의 정보를 추적하는 모든 애플리케이션에 유용하게 사용될 수 있습니다. 예를 들어, Acme라는 이름의 모바일 애플리케이션 개발자는 FGAC를 사용하여 DynamoDB 테이블에 있는 모든 Acme 사용자의 최고 점수를 추적할 수 있습니다. FGAC는 해당 애플리케이션 클라이언트가 현재 애플리케이션을 실행 중인 사용자에 대한 최고 점수만 수정할 수 있도록 허용합니다.

Q: Fine Grain Access Control을 JSON 문서에 사용할 수 있습니까?

예. Fine Grain Access Control(FGAC)을 사용하면 문서에서 최상위 속성을 기준으로 데이터에 대한 액세스를 제한할 수 있습니다. FGAC를 사용하여 중첩된 속성을 기준으로 액세스를 제한할 수는 없습니다. 예를 들어 특정 개인에 대한 정보(ID, 이름, 성 및 전체 친구 목록)가 포함된 JSON 문서를 저장했다고 가정해 보겠습니다. 이 경우 FGAC를 사용하여 ID, 이름 또는 성을 기준으로 액세스를 제한할 수는 있지만 친구 목록을 기준으로 제한할 수는 없습니다.

Q: FGAC가 없는 경우, 개발자가 항목 수준 액세스 제어를 달성하려면 어떻게 해야 합니까?

FGAC 없이 이 제어 수준을 달성하려는 개발자는 몇 가지의 까다로운 접근 방식 중 하나를 선택해야 합니다. 다음과 같은 방식이 있습니다.

  1. 프록시: 애플리케이션 클라이언트가 인증 및 권한 부여를 수행하는 중개 프록시에 요청을 보냅니다. 이러한 솔루션은 시스템 아키텍처의 복잡성을 증가시키며 이로 인해 총 소유 비용(TCO)이 매우 높아질 수 있습니다.
  2. 클라이언트마다 테이블 할당: 모든 애플리케이션 클라이언트가 각자의 테이블에 할당됩니다. 애플리케이션 클라이언트는 각각 다른 테이블에 액세스하므로 서로에게서 보호됩니다. 그러나 이 경우 개발자가 수많은 테이블을 생성해야 할 수 있으며, 이로 인해 데이터베이스 관리가 굉장히 힘들어집니다.
  3. 클라이언트마다 내장된 토큰: 보안 토큰이 애플리케이션 클라이언트에 내장됩니다. 하지만 보안 토큰을 변경하는 것이 어려우며 저장된 데이터에 미치는 영향을 처리하기가 어렵다는 단점이 있습니다. 여기에서 클라이언트가 액세스할 수 있는 항목의 키에는 보안 토큰이 포함됩니다.

Q: DynamoDB FGAC는 어떻게 작동합니까?

애플리케이션은 FGAC를 사용하여 보안 토큰을 요청합니다. 이 보안 토큰은 특정 DynamoDB 테이블의 특정 항목에만 액세스할 수 있도록 애플리케이션에 권한을 부여합니다. 최종 사용자 애플리케이션 에이전트는 이 토큰을 사용해 DynamoDB에 직접 요청할 수 있습니다. 요청을 수신하면 먼저 DynamoDB에서 수신 요청의 자격 증명을 평가합니다. 이는 이후 IAM에서 요청을 인증하고 해당 사용자에게 허용할 기능을 결정하는 데 사용됩니다. 사용자의 요청이 허용되지 않는 경우 FGAC는 해당 데이터로의 액세스를 차단합니다.

Q: DynamoDB FGAC의 사용료는 얼마입니까?

FGAC 사용에 대한 추가 비용은 없습니다. 항상 그렇듯이, 프로비저닝된 처리량 및 DynamoDB 테이블과 연결된 스토리지에 대해서만 지불하면 됩니다.

Q: 어떻게 시작할 수 있습니까?

액세스 정책을 생성하고, 애플리케이션에 대한 IAM 역할을 생성하고(예: Facebook app_ip 34567에 대해 이름이 AcmeFacebookUsers로 지정된 역할), 액세스 정책을 해당 역할에 할당하는 방법을 알아보려면 DynamoDB Developer Guide의 Fine-Grained Access Control 섹션을 참조하십시오. 해당 역할의 신뢰 정책은 어떤 자격 증명 공급자(예: Amazon, Facebook, Google로 로그인)를 허용할 것인지 결정하고, 액세스 정책은 어떤 AWS 리소스(예: DynamoDB 테이블)에 액세스할 수 있는지를 설명합니다. 이제 사용자의 애플리케이션은 역할을 사용하여 AWS Security Token Service(STS)의 AssumeRoleWithIdentityRequest API를 호출해 DynamoDB에 대한 임시 자격 증명을 획득할 수 있습니다.

Q: 사용자가 로컬 보조 인덱스에 대한 쿼리를 할 수 있도록 허용하되, 프로젝션되지 않은 속성을 가져오는 테이블 가져오기 작업을 야기하지 않도록 하려면 어떻게 해야 합니까?

로컬 보조 인덱스에서 이루어지는 일부 쿼리 작업이 인덱스로 프로젝션되지 않은 속성을 요청하는 경우 비용이 많이 들 수 있습니다. "dynamodb:Attributes" 컨텍스트 키를 사용하여 프로젝션된 속성만 가져오도록 권한을 제한하여 비용이 많이 들 수 있는 "가져오기" 작업을 제한할 수 있습니다.

Q: 사용자가 특정 속성에 액세스하지 못하도록 하려면 어떻게 해야 합니까?

특정 속성에 대한 액세스를 차단하려면 최소 권한 원칙을 따르고 특정 속성에 대해서만 액세스를 허용하는 것이 가장 좋은 방법입니다.

또는 Deny 정책을 사용하여 허용하지 않을 속성을 지정할 수도 있습니다. 그러나 이 방법은 다음과 같은 이유로 권장되지 않습니다.

  1. Deny 정책을 사용하면 사용자가 자신의 액세스 권한이 차단될 때까지 가능한 모든 속성 이름에 대해 반복 요청을 하여 숨겨진 속성 이름을 알아낼 가능성이 있습니다.
  2. DynamoDB에서 향후 소유자가 이전에 차단을 위해 사용했던 액세스 패턴을 허용하는 새로운 API 기능을 도입할 가능성이 있으므로 Deny 정책은 상당히 취약합니다.

Q: 사용자가 테이블에 유효하지 않은 데이터를 추가하지 못하도록 하려면 어떻게 해야 합니까?

사용 가능한 FGAC 제어는 변경 및 읽기가 가능한 항목과 속성을 결정할 수 있습니다. 사용자는 차단된 속성 없이 새로운 항목을 추가할 수 있으며 수정 가능한 모든 속성 값을 변경할 수 있습니다.

Q: 여러 항목에 대한 액세스 권한을 부여하려는 경우 원하는 모든 권한을 나열하지 않고도 가능합니까?

예. IAM 정책 언어는 StringLike, StringNotLike 등 다양한 비교 작업을 지원합니다.  자세한 내용은 IAM 정책 참조를 확인하십시오.

Q: 적절한 정책을 생성하려면 어떻게 해야 합니까?

DynamoDB 콘솔에서 DynamoDB Policy Generator를 사용하는 것이 좋습니다. Amazon DynamoDB 개발자 안내서에 있는 정책과 자신의 정책을 비교하여 권장 패턴을 따르고 있는지 확인해 볼 수도 있습니다. AWS 포럼에 정책을 게시하여 해당 정책에 대한 DynamoDB 커뮤니티의 의견을 구할 수도 있습니다.

Q: 로그인에 사용된 자격 증명 공급자를 기준으로 한 개별 ID 대신 정규 사용자 ID를 기준으로 사용자에게 액세스를 부여할 수 있습니까?

"TKM(Token Vending Machine)"을 실행하고 있지 않다면 불가능합니다. 사용자가 STS를 통한 Facebook 자격 증명을 사용하여 IAM 역할에 대해 직접 연동된 액세스를 검색하는 경우 이러한 임시 자격 증명으로는 해당 사용자의 Amazon 로그인 또는 Google 로그인이 아닌, Facebook 로그인에 대한 정보만 입수할 수 있습니다. 이러한 각각의 로그인에 대한 매핑을 자신만의 안정적인 식별자를 통해 내부적으로 저장하고 싶은 경우, 사용자가 로그인을 위해 접속하면 STS를 호출하여 지정한 파티션 키 값 범위 내의 자격 증명을 정규화된 사용자 ID로 사용자에게 제공하는 서비스를 실행할 수 있습니다.

Q: FGAC를 사용하는 호출자에게 숨길 수 없는 정보는 무엇입니까?

현재, 테이블의 다음과 같은 항목의 특정 정보는 호출자에게서 숨길 수 없습니다.

  • 항목 모음 지표: 호출자는 추정 항목 수와 항목 모음 크기가 몇 바이트인지 요청할 수 있습니다.
  • 사용 처리량: 호출자는 작업에서 사용한, 프로비저닝된 처리량의 상세 내역과 요약을 요청할 수 있습니다.
  • 검증 사례: 특정한 경우 액세스를 허용하려는 의도가 없었음에도, 호출자가 테이블의 존재 및 주요 키 스키마를 알 수 있습니다. 이런 일이 발생하지 않도록 하려면 최소 권한 원칙을 따르고 액세스를 허용할 테이블과 작업에 대해서만 액세스 권한을 부여하십시오.
  • 특정 속성에 대해 액세스 허용 목록을 만드는 대신, 액세스를 거부하게 되면 호출자는 "allow all except for" 로직과 같이 숨겨진 속성의 이름을 이론적으로 밝혀낼 수 있습니다. 그러므로 특정 속성 이름에 대한 허용 목록을 작성하는 것이 더 안전합니다.

Q: Amazon DynamoDB는 IAM 권한을 지원합니까?

예. DynamoDB는 AWS Identity and Access Management(IAM) 서비스와의 통합을 통해 API 수준의 권한을 지원합니다.

IAM에 대한 자세한 내용은 다음 페이지를 참조하십시오.

Q: DynamoDB 테이블에 대해 보안 분석을 수행하거나 운영 문제를 해결하고 싶습니다. 내 계정에서 이루어진 모든 DynamoDB API 호출 기록을 받을 수 있습니까?

예. AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 사용자에게 전달하는 웹 서비스입니다. AWS CloudTrail에서 작성된 AWS API 호출 기록을 사용하여 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다. CloudTrail용 DynamoDB 지원에 대한 자세한 내용은 여기를 참조하십시오. AWS CloudTrail 세부 정보 페이지에서 CloudTrail에 대해 자세히 알아보고 CloudTrail의 AWS Management Console 홈 페이지에서 CloudTrail을 활성화하십시오.


Q: Amazon DynamoDB의 사용료는 어떻게 청구 및 결제됩니까?

프로비저닝된 읽기 처리량과 쓰기 처리량이 각 DynamoDB 테이블에 지정되어 있습니다. 프리 티어를 초과하는 경우 그 처리 용량에 1시간 단위로 요금이 부과됩니다.

테이블로 요청 전송 여부와 관계없이 처리 용량에 대해 시간당 요금이 부과됩니다. 테이블의 프로비저닝된 처리 용량을 변경하려면 AWS Management Console이나 Auto Scaling용 UpdateTable API 또는 PutScalingPolicy API를 사용합니다.

또한 DynamoDB에서 인덱싱된 데이터 스토리지 요금과 함께 표준 인터넷 데이터 전송 요금이 부과됩니다.

DynamoDB 요금에 대한 자세한 내용은 DynamoDB 요금 페이지를 참조하십시오.

Q: 요금에 대한 예를 들어 주십시오.

다음은 미국 동부(버지니아 북부) 리전의 요금을 사용하여 처리량 비용을 계산하는 방법의 예입니다. 다른 리전의 요금은 요금 페이지를 참조하십시오.

테이블을 생성하고 프로비저닝된 처리량으로 10유닛의 쓰기 용량과 200유닛의 읽기 용량을 요청하면 다음과 같이 청구됩니다.

0.01 USD + (4 * 0.01 USD) = 0.05 USD/시간

처리량 변경이 필요하여 10,000유닛의 쓰기 용량과 50,000유닛의 읽기 용량으로 예약 처리량 요구 용량을 늘리면 다음과 같이 변경되어 청구됩니다.

(1,000 * 0.01 USD) + (1,000 * 0.01 USD) = 20 USD/시간

DynamoDB 요금에 대한 자세한 내용은 DynamoDB 요금 페이지를 참조하십시오.

Q: 요금에 세금이 포함되어 있습니까?

세금에 대한 자세한 내용은 Amazon Web Services Tax Help 페이지를 참조하십시오.

Q: 프로비저닝된 처리량이란 무엇입니까?

Amazon DynamoDB Auto Scaling은 요청 볼륨이 변경됨에 따라 사용자가 원하는 목표 사용률과 최소 및 최대 용량 한도를 기준으로 자동으로 처리 용량을 조정합니다. 아니면 테이블이 구현하길 원하는 요청 처리량을 수동으로 지정할 수도 있습니다. 요청된 처리 속도를 달성하기 위한 리소스 프로비저닝 작업이 배후에서 진행됩니다. Amazon DynamoDB에서는 처리 속도에 영향을 줄 수 있는 인스턴스, 하드웨어, 메모리를 비롯한 기타 요인에 대해 고객에게 의견을 묻는 번거로운 과정을 거칠 필요가 없습니다. 간단하게 원하는 처리량 수준을 프로비저닝하면 됩니다. 이것이 이 서비스에서 말하는 프로비저닝된 처리량 모델입니다.

기본적으로 새로운 테이블이나 글로벌 보조 인덱스를 생성하는 동안 목표 사용률, 최소 및 최대 용량에 대한 기본 설정값으로 Auto Scaling이 활성화됩니다. 아니면 원하는 읽기 및 쓰기 용량을 수동으로 지정할 수도 있습니다. 그러면 Amazon DynamoDB는 처리량 요구 사항에 맞춰 자동으로 적절한 리소스 양을 파티셔닝하고 예약합니다.

Q: 선택하는 기본 키가 내가 달성할 수 있는 확장성에 어떤 영향을 줍니까?

Amazon DynamoDB는 데이터를 저장할 때 테이블을 여러 파티션으로 나누고 기본 키의 파티션 키 요소를 기반으로 데이터를 분산합니다. 용량 리소스를 할당할 때 Amazon DynamoDB는 모든 기본 키에 비교적 랜덤한 액세스 패턴이 있다고 가정합니다. 데이터 모델을 설정할 때 요청에 의한 트래픽이 기본 키 전체에 고르게 분산되도록 해야 합니다. 하나의 테이블에 자주 액세스되는 소수의 파티션 키 요소가 있거나 매우 자주 사용되는 하나의 파티션 키 요소가 있는 경우, 소수의 파티션 또는 단 하나의 파티션에만 트래픽이 집중됩니다. 워크로드에 심각한 불균형이 발생하면, 즉 하나 또는 일부의 파티션에 워크로드가 집중되면 전반적으로 프로비저닝된 처리량 수준을 달성하기 어렵습니다. Amazon DynamoDB 처리량을 최대한 활용하려면, 파티션 키 요소에 고유한 값을 많이 포함하고 가능한 한 무작위로 상당히 균일하게 값이 요청되도록 테이블을 생성합니다. 예를 들어, 애플리케이션에 사용 고객이 많고 다양한 고객 레코드에 대한 요청이 거의 균일한 경우, CustomerID를 기본 키로 사용하면 좋습니다. 큰 편향이 생길 수 있는 기본 키의 예로는 "Product Category Name"을 들 수 있습니다. 이 경우에는 제품 범주에 따라 인기 차이가 클 수 있기 때문입니다.

Q: 읽기/쓰기 용량 유닛이란 무엇입니까?

애플리케이션에 얼마나 많은 읽기 및 쓰기 용량 단위가 필요한지 어떻게 예측할 수 있습니까? 쓰기 용량 1단위를 통해 최대 1KB 크기의 항목에 대한 쓰기를 초당 한 건 수행할 수 있습니다. 이와 유사하게 읽기 용량 1유닛은 최대 4KB 크기의 항목에 대해 초당 한 건의 Strongly Consistent Read(또는 초당 두 건의 Eventually Consistent Read)를 수행할 수 있습니다. 항목이 많을수록 더 높은 용량이 필요합니다. 초당 필요한 읽기 또는 쓰기 항목 수에 항목 크기(KB 단위의 근사치로 반올림)를 곱해서 필요한 읽기 및 쓰기 용량의 유닛 수를 계산할 수 있습니다.

필요한 쓰기 용량 유닛 수 = 초당 쓰기 항목 수 * 항목 크기(1KB 블록)

필요한 읽기 용량 유닛 수* = 초당 읽기 항목 수 * 항목 크기(4KB 블록)

* eventually consistent read를 사용하는 경우 초당 읽기 처리 속도는 두 배가 됩니다.

항목 크기가 1KB보다 작다면 각 유닛의 읽기 용량은 1 strongly consistent read/초의 속도가 되고 각 유닛의 쓰기 용량은 1 읽기/초의 속도가 됩니다. 예를 들어, 항목이 512바이트이고 초당 100개 항목의 읽기를 원한다면 100유닛의 읽기 용량을 프로비저닝해야 합니다.

항목 크기가 4KB보다 크다면 필요한 읽기 용량 및 쓰기 용량의 유닛 수를 계산해야 합니다. 예를 들어, 항목이 4.5KB이고 100 strongly consistent read/초를 원한다면 100(읽기/초) * 2(4.5KB 저장에 필요한 4KB 블록 수) = 200유닛의 읽기 용량을 프로비저닝해야 합니다.

읽기 용량의 유닛 수는 API 호출의 수가 아니라 초당 읽을 항목의 수로 결정됩니다. 예를 들어, 테이블로부터 초당 500개의 항목을 읽으려 하고 항목이 4KB 이하라면 500유닛의 읽기 용량이 필요합니다. 500건의 개별 GetItem 호출을 하든 10개 항목을 반환하는 50건의 BatchGetItem 호출을 하든 상관없습니다.

Q: 프로비저닝된 처리량 수준을 항상 달성할 수 있습니까?

Amazon DynamoDB는 모든 기본 키에 비교적 랜덤한 액세스 패턴이 있다고 가정합니다. 데이터 모델을 설정할 때 요청에 의한 트래픽이 기본 키 전체에 고르게 분산되도록 해야 합니다. 액세스 패턴의 불균형 또는 편향이 매우 큰 경우 프로비저닝된 처리량 수준을 달성하지 못할 수 있습니다.

Amazon DynamoDB는 데이터를 저장할 때 테이블을 여러 파티션으로 나누고 기본 키의 파티션 키 요소를 기반으로 데이터를 분산합니다. 또한 테이블과 관련한 프로비저닝된 처리량을 여러 개의 파티션으로 나눌 수 있습니다. 각 파티션의 처리량은 지정된 할당량에 따라 개별적으로 관리됩니다. 프로비저닝된 처리량은 파티션에 걸쳐 공유되지 않습니다. 따라서 워크로드가 파티션 키 값에 걸쳐 균등하게 분산되는 경우, Amazon DynamoDB의 테이블이 프로비저닝된 처리량 수준을 가장 잘 충족할 수 있습니다. 여러 파티션 키 값에 걸쳐 요청을 분산하면 여러 파티션에 걸쳐 요청이 분산되어, 프로비저닝된 처리량 수준을 완전히 달성하는 데 도움이 됩니다.

기본 키의 워크로드 패턴이 균일하지 않아 프로비저닝된 처리량 수준을 달성할 수 없는 경우, 프로비저닝된 처리량 수준을 올림으로써 각 파티션에 할당되는 처리량을 늘리면 처리량 요구를 충족할 가능성이 커집니다. 그러나 기본 키에 대한 비교적 랜덤한 액세스 패턴을 달성하려면 요청 패턴이나 데이터 모델의 변경을 고려하는 것이 좋습니다.

Q: JSON 문서의 단일 요소만 검색하는 경우 전체 항목을 읽는 사용료가 부과됩니까?

예. DynamoDB에서 데이터를 읽는 경우 전체 항목을 읽는 데 필요한 처리량을 소모하게 됩니다.

Q: 단일 DynamoDB 테이블에 프로비저닝할 수 있는 최대 처리량은 얼마입니까?

DynamoDB의 확장에는 제한이 없습니다. 그러나 10,000개의 쓰기 용량 유닛 또는 10,000개의 읽기 용량 유닛 이상의 개별 테이블 처리 속도를 원하시면, 먼저 이 온라인 양식을 사용하여 Amazon에 문의하십시오. 또한 하나의 가입 계정에서 20,000개 이상의 쓰기 용량 유닛 또는 20,000개 이상의 읽기 용량 유닛을 프로비저닝하는 경우에도 먼저 위의 양식을 사용하여 AWS에 문의해 주십시오.

Q: 단일 DynamoDB 테이블에 프로비저닝할 수 있는 최소 처리량은 얼마입니까?

Auto Scaling과 수동 처리량 프로비저닝 모두 요청할 수 있는 프로비저닝된 처리량의 최소 크기는 쓰기 용량 유닛 1개와 읽기 용량 유닛 1개입니다.

이 용량 수준은 프리 티어 범위 내에 있으며 25유닛의 쓰기 용량과 25유닛의 읽기 용량을 무료로 사용할 수 있습니다. 프리 티어는 테이블 수준이 아닌 계정 수준에 적용됩니다. 즉, 전체 테이블의 프로비저닝 용량을 합산하여 전체 용량이 쓰기 용량 25유닛, 읽기 용량 25유닛을 초과하지 않으면 프로비저닝 용량이 프리 티어 적용 범위에 속하게 됩니다.

Q: 한 번의 요청으로 변경할 수 있는 프로비저닝된 처리량에 제한이 있습니까?

UpdateTable API를 사용하여 테이블의 프로비저닝된 처리 용량을 임의의 크기만큼 늘릴 수 있습니다. 예를 들어 단일 API 호출을 통해 테이블의 프로비저닝된 쓰기 용량을 1쓰기 용량 유닛에서 10,000쓰기 용량 유닛으로 늘릴 수 있습니다. 계정에는 여전히 설명서 페이지에 설명된 대로 용량에 대한 테이블 수준 및 계정 수준 제한이 적용됩니다. 프로비저닝된 용량 제한을 늘리려면 지원 센터를 방문하여 “Open a new case”를 클릭하고 서비스 제한 증가 요청을 제출하면 됩니다.

Q: 프로비저닝된 처리량은 어떻게 청구됩니까?

모든 Amazon DynamoDB 테이블에 고객이 요청한 처리 속도를 달성하는 데 필요한 리소스가 사전에 프로비저닝되어 있습니다. 테이블에 리소스가 유지되는 한, 시간 단위로 부과됩니다. 전체 요금 목록과 예는 DynamoDB 요금 페이지를 참고하십시오.

Q: 기존 DynamoDB 테이블에서 프로비저닝된 처리량을 어떻게 변경합니까?

Amazon DynamoDB 테이블의 프로비저닝된 처리량은 두 가지 방법으로 업데이트할 수 있습니다. 하나는 관리 콘솔에서 변경하는 방법이고 다른 하나는 UpdateTable API 호출을 사용하는 방법입니다. 두 가지 방법 모두에서 프로비저닝된 처리량 수준을 확대 또는 축소하는 동안에도 Amazon DynamoDB를 사용할 수 있습니다.

Q: 프로비저닝된 처리량은 얼마나 자주 변경할 수 있습니까?

프로비저닝된 처리량은 필요할 때마다 늘릴 수 있습니다. 언제든 하루에 최대 4번 줄일 수 있습니다. 날짜는 GMT 시간대를 기준으로 합니다. 또한, 지난 4시간 동안 한 번도 줄이지 않은 경우에는 추가로 축소가 허용되어 하루에 최대 9번 줄일 수 있습니다(하루에 처음 4시간 동안 4번 축소, 이후에 4시간마다 1번씩 축소).

Amazon DynamoDB 테이블에서 프로비저닝된 처리량에 대한 고객의 마지막 변경 요청 처리가 완료될 때까지 프로비저닝된 처리량을 수정할 수 없으니 주의하시기 바랍니다. Management Console 또는 DescribeTables API를 사용하여 테이블의 상태를 확인합니다. 상태가 "CREATING", "DELETING" 또는 "UPDATING"인 경우, 테이블의 처리량을 조정할 수 없습니다. 테이블이 "ACTIVE" 상태가 되면 다시 시도하십시오.

Q: 일관성 수준이 처리 속도에 영향을 줍니까?

예. 동일한 리소스가 할당되었을 때, DynamoDB 테이블이 달성할 수 있는 읽기 속도는 strongly consistent read와 eventually consistent read에서 다릅니다. "1,000개의 읽기 용량 유닛"을 요청하면 DynamoDB는 최대 4KB 항목에 대해 초당 1,000개의 strongly consistent read를 달성할 수 있도록 리소스를 할당합니다. 최대 4KB 항목에 대해 1,000개의 eventually consistent read를 달성하려는 경우에는 절반의 용량, 즉 500개의 읽기 용량 유닛만 필요합니다. 테이블의 적절한 처리 속도 선택에 대한 자세한 내용은 프로비저닝된 처리량 안내를 참고하십시오.

Q: 항목 크기가 처리 속도에 영향을 줍니까?

예. 동일한 리소스가 할당되었을 때, DynamoDB 테이블이 달성할 수 있는 읽기 속도는 항목의 크기에 따라 달라집니다. 달성하고자 하는 프로비저닝된 읽기 처리량을 지정하면 DynamoDB는 항목의 크기가 4KB 미만이라는 가정 하에 리소스를 프로비저닝합니다. 항목이 최대 4KB 증가할 때마다 동일한 처리 속도를 달성하는 데 필요한 리소스도 비례적으로 증가합니다. 예를 들어, 100유닛의 읽기 용량을 가진 DynamoDB 테이블을 프로비저닝하면 이 테이블은 초당 100개의 4KB 읽기, 초당 50개의 8KB 읽기 또는 초당 25개의 16KB 읽기를 처리할 수 있습니다.

마찬가지로 DynamoDB 테이블이 달성할 수 있는 쓰기 속도 역시 항목의 크기에 따라 달라집니다. 달성하고자 하는 프로비저닝된 쓰기 처리량을 지정하면 DynamoDB는 항목의 크기가 1KB 미만이라는 가정 하에 리소스를 프로비저닝합니다. 항목이 최대 1KB 증가할 때마다 동일한 처리 속도를 달성하는 데 필요한 리소스도 비례적으로 증가합니다. 예를 들어, 100유닛의 쓰기 용량을 가진 DynamoDB 테이블을 프로비저닝하면 이 테이블은 초당 100개의 1KB 쓰기, 초당 50개의 2KB 쓰기 또는 초당 25개의 4KB 쓰기를 처리할 수 있습니다.

테이블의 적절한 처리 속도 선택에 대한 자세한 내용은 프로비저닝된 처리량 안내를 참고하십시오.

Q: 애플리케이션의 읽기 또는 쓰기가 프로비저닝된 용량을 초과하면 어떻게 됩니까?

애플리케이션이 테이블에 프로비저닝된 처리 용량을 초과하는 읽기/초 또는 쓰기/초를 수행하면, 프로비저닝된 용량을 초과하는 요청은 제한되며 오류 코드 400이 반환됩니다. 예를 들어, 1,000개의 읽기 용량 유닛을 요청하고 1KB 항목에 대해 1,500 쓰기/초를 시도하는 경우, DynamoDB는 1,000 쓰기/초만 처리할 수 있으며 초과하는 부분에 대해 오류 코드 400을 반환합니다. 필요한 요청 속도를 달성하기에 충분한 프로비저닝된 처리량을 항상 확보하기 위해서는 CloudWatch를 사용하여 요청 속도를 모니터링할 필요가 있습니다.

Q: 프로비저닝된 처리 용량을 초과했는지 확인하려면 어떻게 해야 합니까?

DynamoDB는 CloudWatch 지표를 통해 사용한 처리 용량을 알려줍니다. 이 지표에 경보를 설정하여 프로비저닝된 용량에 근접하면 알림을 받을 수 있습니다.

Q: 테이블의 프로비저닝된 처리량 수준 변경에는 얼마나 걸립니까?

일반적으로 처리량 축소는 몇 초에서 몇 분이 걸리고 처리량 증가는 몇 분에서 몇 시간 정도 걸립니다.

추가적인 처리량이 필요한 시점이 되어서야 처리량 증가를 시도하거나 예약하는 것은 좋지 않습니다. 필요할 때 확실히 사용할 수 있도록 처리 용량 프로비저닝을 사전에 충분히 확보하는 것이 좋습니다.

Q: 예약 용량이란 무엇입니까?

예약 용량은 다음과 같은 조건으로 프로비저닝된 처리량을 구매하는 경우 할인받을 수 있는 결제 기능입니다.

  • 선결제 요금 한 번 결제
  • 계약 기간 동안 월별 최소 사용 수준에 대한 약정입니다.

예약 용량은 단일 AWS 리전에만 적용되며, 1년 또는 3년 단위로 구매할 수 있습니다. Auto Scaling으로 관리되든 테이블을 생성하거나 업데이트할 때 수동으로 프로비저닝하든 관계없이 모든 DynamoDB 테이블에는 프로비저닝된 처리 용량이 연결되어 있습니다. 이 용량은 DynamoDB 테이블이 달성할 수 있는 읽기 및 쓰기 처리 속도를 결정합니다. 예약 용량은 결제 방식이며, DynamoDB 테이블의 성능이나 용량에는 직접 영향을 미치지 않습니다. 예를 들어 쓰기 용량 100유닛이 제공되는 예약 용량을 구매하는 경우, 요금을 할인받는 조건으로 1년 또는 3년의 계약 기간 동안 해당 용량에 대한 요금을 지불할 것에 동의한 것입니다.

Q: 예약 용량을 구매하려면 어떻게 해야 합니까?

AWS Management Console에 로그인하고 DynamoDB 콘솔 페이지로 이동하여 "Reserved Capacity"를 클릭합니다. 그러면 "예약 용량 사용" 페이지로 이동합니다. "Purchase Reserved Capacity"를 클릭하면 예약 용량을 구매하기 위해 작성해야 할 양식으로 이동합니다. 예약 용량을 사용할 AWS 리전을 선택했는지 확인하십시오. 예약 용량 구매를 완료하고 나면 "예약 용량 사용" 페이지에서 구매 항목을 확인할 수 있습니다.

Q: 구매한 예약 용량을 취소할 수 있습니까?

아니요. 예약 용량은 취소할 수 없으며 일시불로 결제한 금액은 환불되지 않습니다. 예약 용량 기간에는 사용량과 관계없이 매시간에 대해 계속해서 지불하게 됩니다.

Q: 예약 용량의 최소 구매 단위는 어떻게 됩니까?

예약 용량 최소 구매 단위는 읽기 또는 쓰기 용량 100유닛입니다.

Q: 예약 용량을 구매하는 데 사용할 수 있는 API가 있습니까?

아니요. 추후에 이에 대한 API를 제공하고 예약 용량 옵션을 추가할 예정입니다.

Q: 한 리전에서 다른 리전으로 예약 용량을 옮길 수 있습니까?

아니요. 예약 용량은 단일 리전과 연결되어 있습니다.

Q: 구매한 예약 용량보다 더 많은 처리량을 프로비저닝할 수 있습니까?

예. 예약 용량을 구매하면, 요금을 할인받는 조건으로 최소 사용 수준에 동의하는 것입니다. 최소 수준보다 더 많은 용량을 프로비저닝하는 경우 추가된 용량에 대해 표준 요금이 부과됩니다.

Q: 예약 용량을 사용하려면 어떻게 해야 합니까?

예약 용량은 청구서에 자동으로 적용됩니다. 예를 들어 쓰기 용량 100유닛이 제공되는 예약 용량을 구매하고 300을 프로비저닝한 경우, 쓰기 용량 100유닛은 구매한 예약 용량에서 제공하고 나머지 쓰기 용량 200유닛에는 표준 요금이 부과됩니다.

Q: 구매한 예약 용량보다 적게 처리량을 프로비저닝하는 경우 어떻게 됩니까?

예약 용량을 구매하는 것은 요금을 할인받는 조건으로 계약 기간 동안 최소 프로비저닝된 처리량에 대한 요금을 지불할 것에 동의하는 것입니다. 구매한 예약 용량보다 적게 사용하는 경우에도 약정한 최소 프로비저닝된 처리량에 대한 요금을 매월 지불해야 합니다.

Q: 여러 DynamoDB 테이블에서 예약 용량을 사용할 수 있습니까?

예. 예약 용량은 예약 용량을 구매한 리전의 프로비저닝된 총 용량에 적용됩니다. 예를 들어 쓰기 용량 5,000유닛이 제공되는 예약 용량을 구매한 경우, 하나의 테이블에 쓰기 용량 5,000유닛을 적용하거나, 100개의 테이블에 쓰기 용량 50유닛을 적용하거나, 1,000개의 테이블에 쓰기 용량 5유닛을 적용할 수 있습니다.

Q: 예약 용량은 통합 결제 계정의 DynamoDB 사용에 적용됩니까?

예. 통합 결제에 연결된 여러 개의 계정을 보유한 경우, 지급인 계정 수준 또는 연결된 계정 수준에서 구매한 예약 용량 유닛은 지급인 계정에 연결된 모든 계정에서 공유됩니다. 예약 용량은 이를 구매한 계정에 먼저 적용된 후, 미사용 용량이 있는 경우 다른 연결된 계정에 적용됩니다.

 

Q: DynamoDB 교차 리전 복제란 무엇입니까?

DynamoDB 교차 리전 복제를 통해 하나 이상의 AWS 리전에서 DynamoDB 테이블(마스터 테이블이라고 함)과 동일한 복사본(복제본이라고 함)을 유지 관리할 수 있습니다. 테이블에 대한 교차 리전 복제를 활성화하면 다른 AWS 리전에 해당 테이블과 동일한 복사본이 생성됩니다. 해당 테이블에 쓰면 자동으로 모든 복제본에 전파됩니다.

 

Q: 언제 교차 리전 복제를 사용해야 합니까?

다음 시나리오의 경우 교차 리전 복제를 사용할 수 있습니다.

  • 효율적인 재해 복구: 여러 데이터 센터에 테이블을 복제함으로써 데이터 센터에 장애가 발생하는 경우 다른 리전의 DynamoDB 테이블을 사용하도록 전환할 수 있습니다.
  • 더 빨라진 읽기: 다양한 리전에 고객이 존재하는 경우 가장 가까운 AWS 데이터 센터의 DynamoDB 테이블을 읽어 더욱 신속하게 데이터를 전송할 수 있습니다.
  • 더욱 손쉬워진 트래픽 관리: 복제본을 사용하여 테이블 간 읽기 워크로드를 분배하므로 마스터 테이블에서 읽기 용량을 더 적게 사용합니다.
  • 손쉬운 리전 마이그레이션: 새로운 리전에서 읽기 전용 복제본을 생성한 다음 해당 복제본을 마스터로 승격하면 해당 리전에 애플리케이션을 더욱 손쉽게 마이그레이션할 수 있습니다.
  • 실시간 데이터 마이그레이션: DynamoDB 테이블을 리전 간 이동하기 위해 대상 리전에서 소스 리전의 테이블 복제본을 생성할 수 있습니다. 테이블이 동기화 중일 때 애플리케이션을 전환하여 대상 리전에 쓸 수 있습니다.

Q: 어떤 교차 리전 복제 모드가 지원됩니까?

교차 리전 복제는 현재 단일 마스터 모드를 지원합니다. 단일 마스터에는 마스터 테이블 1개와 1개 이상의 복제본 테이블이 있습니다.

Q: 테이블에 대한 단일 마스터 교차 리전 복제를 설정하려면 어떻게 해야 합니까?

DynamoDB 교차 리전 복제 라이브러리를 사용하여 교차 리전 복제를 생성할 수 있습니다.

Q: 부트스트랩이 완료되었음을 어떻게 알 수 있습니까?

복제 관리 애플리케이션에서 복제 상태가 Bootstrapping에서 Active로 변경됩니다.

Q: 단일 마스터 테이블의 복제본을 여러 개 가질 수 있습니까?

예. 단일 마스터 테이블에 대한 복제본 테이블 수에는 제한이 없습니다. DynamoDB 스트림 리더는 각 복제본 테이블에 대해 생성되며 마스터 테이블의 데이터를 복사하여 복제본의 동기화를 유지합니다.

Q: 테이블에 대한 교차 리전 복제 설정 비용은 얼마입니까?

DynamoDB 교차 리전 복제DynamoDB 교차 리전 복제 라이브러리를 사용하여 활성화됩니다. 교차 리전 복제 라이브러리에 대한 추가 요금은 없으며, 프로세스에서 사용되는 다음 리소스에 대한 일반 요금을 지불하면 됩니다. 다음에 대한 비용이 청구됩니다.

  • 복제본 테이블에 대해 프로비저닝된 처리량(쓰기 및 읽기)과 스토리지.
  • 리전 간 데이터 전송.
  • 테이블 간 동기화를 유지하기 위해 DynamoDB 스트림에서 데이터 읽기.
  • 복제 프로세스를 호스팅하기 위해 프로비저닝되는 EC2 인스턴스. 인스턴스 비용은 선택한 인스턴스 유형과 인스턴스를 호스팅하는 리전에 따라 달라집니다.

Q: 어느 리전의 Amazon EC2 인스턴스가 교차 리전 복제 실행을 호스팅합니까?

교차 리전 복제 애플리케이션은 해당 애플리케이션이 원래 시작되었던 동일한 리전의 Amazon EC2 인스턴스에서 호스팅됩니다. 이 리전에서 인스턴스 요금이 청구됩니다.

Q: Amazon EC2 인스턴스는 마스터 및 복제본 테이블의 크기와 처리량이 변경됨에 따라 자동 조정됩니까?

현재는 AWS에서는 EC2 인스턴스를 자동 조정하지 않습니다. DynamoDB 교차 리전 복제를 구성할 때 인스턴스 크기를 선택해야 합니다.

Q: Amazon EC2 인스턴스에서 복제 관리 시 장애가 발생하는 경우 어떻게 됩니까?

Amazon EC2 인스턴스는 Auto Scaling 그룹 뒤에서 실행됩니다. 즉, 해당 애플리케이션은 자동으로 다른 인스턴스로 장애 조치를 실행합니다. 애플리케이션은 복사본의 체크포인트로 Kinesis Client Library(KCL)를 사용합니다. 인스턴스 장애가 발생하면 애플리케이션은 체크포인트를 찾아 해당 부분부터 재개합니다.

Q: 읽기 전용 복제본이 생성되는 동안 DynamoDB 테이블을 계속 사용할 수 있습니까?

예. 복제본 생성은 온라인 작업입니다. 읽기 전용 복제본이 생성되는 중에도 테이블에 대한 읽기와 쓰기를 수행할 수 있습니다. 부트스트랩은 소스 테이블에서 복사하기 위해 Scan 작업을 사용합니다. Scan 작업을 지원할 수 있도록 충분한 읽기 용량 유닛으로 테이블을 프로비저닝하는 것이 좋습니다.

 

Q: 복제본을 생성하는 데 얼마나 걸립니까?

마스터 테이블을 복제본 테이블로 처음 복사하는 데 걸리는 시간은 마스터 테이블의 크기, 마스터 테이블 및 복제본 테이블의 프로비저닝된 용량에 따라 달라집니다. 마스터 테이블의 항목 수준 변경이 복제본 테이블로 전파되는 데 걸리는 시간은 마스터 및 복제본 테이블에서 프로비저닝된 용량과 복제본 애플리케이션을 실행하는 Amazon EC2 인스턴스의 크기에 따라 달라집니다.

Q: 마스터 테이블에서 프로비저닝된 용량을 변경하는 경우 복제본 테이블의 프로비저닝된 용량도 함께 업데이트됩니까?

복제본이 생성되고 나면 마스터 테이블에서 프로비저닝된 용량에 변경 사항이 있을 경우 복제본 테이블에서의 처리 용량도 업데이트됩니다.

 

Q: 복제본 테이블에도 마스터 테이블과 동일한 인덱스가 있습니까?

복제 애플리케이션에서 복제본 테이블을 생성하도록 선택한 경우 마스터 테이블의 보조 인덱스는 복제본 테이블에서 자동으로 생성되지 않습니다. 복제 애플리케이션은 마스터 테이블의 보조 인덱스에 이루어진 변경 사항을 복제본 테이블로 전파하지 않습니다. 일반 DynamoDB 테이블처럼 AWS Management Console을 통해 각 복제본 테이블에 인덱스를 추가/업데이트/삭제해야 합니다.

 

Q: 복제본에 마스터 테이블과 동일한 만큼의 프로비저닝된 처리 용량이 주어집니까?

복제본 테이블을 생성할 때 수신되는 모든 쓰기를 처리하기에 용량이 충분하도록 적어도 마스터 테이블과 동일한 쓰기 용량을 프로비저닝하는 것이 좋습니다. 애플리케이션에 적절하다고 생각하는 모든 수준에서 복제본 테이블의 프로비저닝된 읽기 용량을 설정할 수 있습니다.

 

Q: 복제된 테이블에 대한 일관성 모델은 무엇입니까?

복제본은 비동기식으로 업데이트됩니다. 마스터 테이블에서 쓰기 작업이 허용되면 DynamoDB에서 해당 작업을 성공적이라고 확인합니다. 그러면 쓰기 작업이 각 복제본으로 전파됩니다. 즉, 쓰기가 모든 복제본 테이블로 전파되기까지는 약간의 지연 시간이 발생한다는 의미입니다.

Q: 교차 리전 복제에 대한 CloudWatch 지표가 있습니까?

CloudWatch 지표는 모든 복제 구성에 대해 제공됩니다. 복제 그룹을 선택하고 Monitoring 탭으로 이동하여 지표를 확인할 수 있습니다. 처리량 및 처리된 레코드 수 지표가 제공되며 마스터 및 복제본 테이블의 처리량에 대한 모든 차이점을 모니터링할 수 있습니다.

Q: 마스터 테이블과 동일한 리전에 복제본이 존재할 수 있습니까?

예. 복제본 테이블과 마스터 테이블의 이름만 다르다면 동일한 리전에 두 개의 테이블 모두 존재할 수 있습니다.

Q: 복제 그룹을 생성한 후 복제본을 추가하거나 삭제할 수 있습니까?

예. 언제든지 해당 복제 그룹에서 복제본을 추가하거나 삭제할 수 있습니다.

Q: 복제본 그룹이 생성된 후 해당 그룹을 삭제할 수 있습니까?

예. 복제 그룹을 삭제하면 해당 그룹에 대한 EC2 인스턴스가 삭제됩니다. 그러나 DynamoDB 메타데이터 테이블은 수동으로 삭제해야 합니다.

Q: DynamoDB 트리거란 무엇입니까?

DynamoDB 트리거는 DynamoDB 테이블의 항목 수준 업데이트를 기반으로 커스텀 작업을 실행할 수 있게 하는 기능입니다. 코드로 커스텀 작업을 지정할 수 있습니다.

Q: DynamoDB 트리거로 무엇을 할 수 있습니까?

DynamoDB 트리거를 유용하게 활용할 수 있는 몇 가지 애플리케이션 시나리오가 있습니다. 알림을 전송하고, 집계 테이블을 업데이트하고, DynamoDB 테이블을 다른 데이터 소스에 연결하는 등의 사용 사례가 포함됩니다.

Q: DynamoDB 트리거는 어떻게 작동합니까?

DynamoDB 트리거의 커스텀 로직은 AWS Lambda 함수에 코드로 저장됩니다. DynamoDB 스트림을 통해 DynamoDB 테이블에서 스트림에 AWS Lambda 함수를 연결하여 지정된 테이블에 트리거를 생성할 수 있습니다. 테이블이 업데이트되면 해당 업데이트가 DynamoDB 스트림에 게시됩니다. AWS Lambda는 차례로 연결된 스트림의 업데이트를 읽은 다음 함수에서 코드를 실행합니다.

Q: DynamoDB 트리거 사용 비용은 얼마입니까?

DynamoDB 트리거의 경우 AWS Lambda 함수에 대한 요청 수와 AWS Lambda 함수의 실행 시간에 대해서만 지불하면 됩니다. AWS Lambda 요금에 대해 자세히 알아보려면 여기를 참조하십시오. 테이블과 연결된 스트림(DynamoDB 스트림을 통함)에 대한 AWS Lambda 함수의 읽기에 대해서는 비용이 청구되지 않습니다.

Q: 테이블에 대한 트리거 수에 제한이 있습니까?

테이블에 대한 트리거 수에는 제한이 없습니다.

Q: DynamoDB 트리거가 지원하는 언어는 무엇입니까?

현재 DynamoDB 트리거는 JavaScript, Java 및 Python에서 트리거 함수를 지원합니다.

Q: DynamoDB 트리거 생성, 편집, 삭제를 지원하는 API가 있습니까?

아니요. 현재 DynamoDB 트리거를 생성, 편집, 삭제하기 위한 기본 API는 없습니다. AWS Lambda 함수를 생성하고 이를 DynamoDB 스트림의 스트림과 연결하려면 반드시 AWS Lambda 콘솔을 사용해야 합니다. 자세한 내용은 AWS Lambda FAQ 페이지를 참조하십시오.

Q: DynamoDB 트리거는 어떻게 생성합니까?

AWS Lambda 함수를 생성한 다음 해당 함수에 대한 이벤트 소스를 DynamoDB 스트림의 스트림에 연결하여 트리거를 생성할 수 있습니다. 자세한 내용은 AWS Lambda FAQ 페이지를 참조하십시오.

Q: DynamoDB 트리거는 어떻게 삭제합니까?

연결된 AWS Lambda 함수를 삭제하여 트리거를 삭제할 수 있습니다. AWS Lambda 콘솔 또는 AWS Lambda API 호출을 통해 AWS Lambda 함수를 삭제할 수 있습니다. 자세한 내용은 AWS Lambda FAQ설명서 페이지를 참조하십시오.

Q: 기존 AWS Lambda 함수가 있는 경우 이 함수를 사용하여 DynamoDB 트리거를 생성하려면 어떻게 해야 합니까?

AWS Lambda 함수에 대한 이벤트 소스가 DynamoDB 스트림의 스트림을 가리키도록 변경할 수 있습니다. DynamoDB 콘솔에서 이러한 작업을 수행할 수 있습니다. 스트림이 활성화된 테이블에서 스트림을 선택하고 Associate Lambda Function 버튼을 선택합니다. 그런 다음 Lambda 함수 목록 중 DynamoDB 트리거에 사용하려는 함수를 선택합니다.

Q: 어느 리전에서 DynamoDB 트리거를 사용할 수 있습니까?

DynamoDB 트리거는 AWS Lambda 및 DynamoDB를 사용할 수 있는 모든 AWS 리전에서 제공됩니다.

Q: DynamoDB Streams란 무엇입니까?

DynamoDB 스트림은 지난 24시간 테이블에 이루어진 항목 수준 변경 사항을 시간순으로 표시합니다. 간단한 API 호출을 사용하여 스트림에 액세스하고 이를 이용해 DynamoDB에 대한 최신 변경 사항을 적용하여 다른 데이터 스토어를 최신 상태로 유지하거나 테이블 변경 사항에 따라 조치를 취할 수 있습니다.

Q: DynamoDB Streams의 장점은 무엇입니까?

DynamoDB Streams API를 사용하면 개발자가 업데이트를 사용하고 항목이 변경되기 전과 후의 항목 수준 데이터를 수신할 수 있습니다. 이를 사용해 DynamoDB 위에 구축된 애플리케이션에 창의적인 확장 기능을 구축할 수 있습니다. 예를 들어, DynamoDB를 사용해 글로벌 멀티 플레이어 게임을 구축하는 개발자는 DynamoDB Streams API를 활용하여 멀티 마스터 토폴로지를 구축하고 각 마스터의 DynamoDB Streams를 이용해 원격 마스터에서 업데이트를 재생하여 마스터를 동기화된 상태로 유지할 수 있습니다. 또 다른 예로, 개발자는 DynamoDB Streams API를 사용하여 사용자가 새 셀카를 업로드하는 즉시 연결된 모든 친구의 모바일 디바이스에 자동으로 알림을 보내는 모바일 애플리케이션을 구축할 수 있습니다. 또한, 개발자는 DynamoDB 스트림을 사용하여 Amazon Redshift와 같은 데이터 웨어하우징 도구를 모든 DynamoDB 테이블 변경 사항과 동기화된 상태로 유지해 실시간 분석을 수행할 수 있습니다. DynamoDB는 Amazon DynamoDB Logstash 플러그인을 통해 Elasticsearch과도 통합되므로 개발자가 DynamoDB 콘텐츠에 대한 자유 텍스트 검색을 추가할 수 있습니다.

설명서에서 DynamoDB 스트림에 대해 자세히 알아볼 수 있습니다.

Q: DynamoDB Streams를 통해 내 DynamoDB 테이블 변경 사항이 얼마 동안 제공됩니까?

DynamoDB Streams는 모든 테이블 변경 사항에 대한 기록을 24시간 동안 보관합니다. 그 이후에는 기록이 삭제됩니다.

Q: DynamoDB Streams를 활성화하려면 어떻게 해야 합니까?

DynamoDB Streams는 테이블별로 활성화해야 합니다. 기존 DynamoDB 테이블에 대해 DynamoDB Streams를 활성화하려면, AWS Management Console에서 테이블을 선택하고, Overview 탭을 선택한 후, Manage Stream 버튼을 클릭하고, 보기 유형을 선택한 다음, Enable을 클릭합니다.

자세한 내용은 설명서를 참조하십시오.

Q: DynamoDB Streams가 활성화되었는지 어떻게 확인할 수 있습니까?

DynamoDB Streams를 활성화하면 AWS Management Console에서 해당 스트림을 확인할 수 있습니다. 테이블을 선택한 다음, Overview 탭을 선택합니다. Streams 세부 정보에서 Stream enabled가 Yes로 설정되어 있는지 확인합니다.

Q: DynamoDB Streams에 액세스하려면 어떻게 해야 합니까?

DynamoDB SDK 또는 Kinesis Client Library(KCL)를 사용하는 간단한 API 호출으로 DynamoDB 스트림을 통해 제공되는 스트림에 액세스할 수 있습니다. KCL은 스트림의 데이터를 사용 및 처리하고 사용자가 여러 리더 전반의 로드 밸런싱, 인스턴스 장애에 대한 대응, 체크포인트 처리 레코드와 같은 작업을 관리하도록 지원합니다.

DynamoDB 스트림 액세스에 대한 자세한 내용은 설명서를 참조하십시오.

Q: DynamoDB Streams에 내 DynamoDB 테이블에 대한 모든 변경 사항이 순서대로 표시됩니까?

개별 항목에 대한 변경 사항이 올바른 순서로 표시됩니다. 다른 항목에 대한 변경 사항은 수신된 것과 다른 순서로 DynamoDB 스트림에 표시될 수 있습니다.

예를 들어, 게임의 최고 점수를 추적하는 DynamoDB 테이블이 있고 테이블의 각 항목이 개별 플레이어를 나타내며 다음 순서로 다음 3가지 업데이트를 수행한다고 가정해 보겠습니다.

  • 업데이트 1: 플레이어 1의 최고 점수를 100점으로 변경
  • 업데이트 2: 플레이어 2의 최고 점수를 50점으로 변경
  • 업데이트 3: 플레이어 1의 최고 점수를 125점으로 변경

업데이트 1과 업데이트 3에서 동일한 항목(플레이어 1)이 변경되었으므로 DynamoDB 스트림에 업데이트 3이 업데이트 1 다음에 표시됩니다. 따라서 각 플레이어가 가장 최근에 획득한 최고 점수를 검색할 수 있습니다. 스트림에 3개의 업데이트가 모두 동일한 순서로 수행되었다는 사실(업데이트 2는 업데이트 1 이후, 업데이트 3 이전에 수행되었음)은 표시되지 않을 수 있지만 각 개별 플레이어의 레코드에 대한 업데이트는 올바른 순서로 표시됩니다.

Q: DynamoDB 스트림 내 스트림의 용량을 관리해야 합니까?

아니요. 스트림의 용량은 DynamoDB 스트림에서 자동으로 관리됩니다. DynamoDB 테이블에 대한 트래픽을 크게 늘리면 모든 업데이트를 계속 수락할 수 있도록 DynamoDB에서 스트림의 용량을 자동으로 조정합니다.

Q: DynamoDB 스트림에서의 읽기 속도는 어떻게 됩니까?

DynamoDB 테이블의 프로비저닝된 쓰기 용량 속도보다 최대 2배 더 빠른 속도로 DynamoDB 스트림 내 스트림의 업데이트를 읽을 수 있습니다. 예를 들어, DynamoDB 테이블에서 초당 1,000개의 항목을 업데이트할 수 있는 용량을 프로비저닝한 경우 스트림에서 초당 최대 2,000개의 업데이트를 읽을 수 있습니다.

Q: DynamoDB 테이블을 삭제하면 스트림도 DynamoDB 스트림에서 삭제됩니까?

아니요. 즉시 삭제되지는 않습니다. 스트림은 DynamoDB 스트림에서 24시간 동안 유지되어 사용자가 테이블에 적용된 최신 업데이트를 읽을 수 있는 기회를 제공합니다. 24시간이 지난 후에는 DynamoDB 스트림에서 해당 스트림이 자동으로 삭제됩니다.

Q: 내 테이블에 대해 DynamoDB Streams를 끄면 어떻게 됩니까?

DynamoDB Streams를 끄면 스트림이 24시간 동안 유지되지만 DynamoDB 테이블에 대한 추가 변경 사항은 업데이트되지 않습니다.

Q: DynamoDB Streams를 껐다가 다시 켜면 어떻게 됩니까?

DynamoDB Streams를 끄면 스트림이 24시간 동안 유지되지만 DynamoDB 테이블에 대한 추가 변경 사항은 업데이트되지 않습니다. DynamoDB 스트림을 다시 켜면 새 스트림이 생성된 시점부터 DynamoDB 테이블에 적용된 변경 사항을 포함하는 새 스트림이 DynamoDB 스트림에 생성됩니다.

Q: DynamoDB 스트림에 중복 데이터 또는 격차가 있습니까?

아니요. DynamoDB 스트림은 테이블에 대한 모든 업데이트가 스트림에 정확하게 한 번 표시되도록 설계되었습니다.

Q: DynamoDB 스트림에 어떤 정보가 포함됩니까?

DynamoDB 스트림에는 항목의 이전 값과 변경된 값에 대한 정보가 포함됩니다. 또한, 변경된 항목에 대한 변경 유형(INSERT, REMOVE, MODIFY)과 기본 키도 포함됩니다.

Q: DynamoDB 스트림에 포함할 정보를 선택하려면 어떻게 해야 합니까?

새 테이블의 경우 CreateTable API 호출을 사용하고 ViewType 파라미터를 지정해 스트림에 포함할 정보를 선택합니다.
기존 테이블의 경우 UpdateTable API 호출을 사용하고 ViewType 파라미터를 지정해 스트림에 포함할 정보를 선택합니다.

ViewType 파라미터는 다음 값을 가져옵니다.

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

이 값에는 다음과 같은 뜻이 있습니다. KEYS_ONLY: 변경된 항목의 키 이름만 스트림에 포함됩니다.

  • NEW_IMAGE: 키 이름 및 업데이트 후 항목(새 항목)이 스트림에 포함됩니다.
  • OLD_IMAGE: 키 이름 및 업데이트 전 항목(이전 항목)이 스트림에 포함됩니다.
  • NEW_AND_OLD_IMAGES: 키 이름, 업데이트 전 항목(이전 항목), 업데이트 후 항목(새 항목)이 스트림에 포함됩니다.

Q: 내 Kinesis Client Library를 사용하여 DynamoDB Streams에 액세스할 수 있습니까?

예. Kinesis API에 익숙한 개발자는 DynamoDB 스트림을 쉽게 사용할 수 있습니다. Amazon Kinesis 인터페이스를 구현하는 DynamoDB Streams Adapter를 사용하면 애플리케이션에서 DynamoDB Streams에 액세스하는 데 Amazon Kinesis Client Libraries(KCL)를 이용할 수 있습니다. KCL을 사용하여 DynamoDB Streams에 액세스하는 방법에 대한 자세한 내용은 AWS 설명서를 참조하십시오.

Q: DynamoDB 스트림에 포함되는 정보의 유형을 변경할 수 있습니까?

스트림이 생성된 후 해당 스트림에 저장되는 정보의 유형을 변경하려면 스트림을 비활성화하고 UpdateTable API를 사용해 새 스트림을 생성해야 합니다.

Q: DynamoDB 테이블을 변경하면 변경 사항이 DynamoDB 스트림에 얼마나 빨리 나타납니까?

변경 사항은 일반적으로 1초 내에 DynamoDB 스트림에 반영됩니다.

Q: 항목을 삭제하면 해당 변경 사항이 DynamoDB 스트림에 포함됩니까?

예. DynamoDB 스트림의 각 업데이트에 해당 업데이트가 삭제였는지, 새 항목 삽입이었는지, 기존 항목 수정이었는지 지정하는 파라미터가 포함됩니다. 업데이트 유형에 대한 자세한 내용은 설명서를 참조하십시오.

Q: 내 테이블에 대해 DynamoDB Streams를 켠 후 언제 스트림에서 읽어 올 수 있습니까?

DescribeStream API를 사용하여 스트림의 최신 상태를 확인할 수 있습니다. 상태가 ENABLED로 변경되면 테이블에 대한 모든 변경 사항이 스트림에 표시됩니다.

스트림을 생성하는 순간 스트림에서 읽어올 수 있지만 상태가 ENABLED로 변경될 때까지는 스트림에 테이블에 대한 모든 업데이트가 포함되지 않을 수 있습니다.

Q: Elasticsearch용 Amazon DynamoDB Logstash 플러그인이란 무엇입니까?

Elasticsearch는 실시간 검색과 빅 데이터 분석을 간소화하도록 설계된 인기 있는 오픈 소스 검색 및 분석 엔진입니다. Logstash는 Elasticsearch와 함께 사용하여 로그 및 기타 이벤트 데이터를 처리할 수 있는 오픈 소스 데이터 파이프라인입니다. Amazon DynamoDB Logstash 플러그인은 DynamoDB 테이블과 Elasticsearch 클러스터의 통합을 용이하게 만들어줍니다.

Q: Amazon DynamoDB Logstash 플러그인은 비용이 어떻게 됩니까?

Amazon DynamoDB Logstash 플러그인은 다운로드 및 사용이 무료입니다.

Q: Amazon DynamoDB Logstash 플러그인은 어떻게 다운로드하여 설치합니까?

Amazon DynamoDB Logstash 플러그인은 GitHub에서 이용할 수 있습니다. 이 플러그인을 설치 및 실행하는 방법을 자세히 알아보려면 설명서 페이지를 읽으십시오.


Q: Titan용 DynamoDB 스토리지 백엔드란 무엇입니까?

Titan용 DynamoDB 스토리지 백엔드는 DynamoDB를 Titan 그래프 데이터베이스를 위한 기본 스토리지 계층으로 사용할 수 있게 해주는 플러그인입니다. 또한, 빠른 그래프 순회를 위해 DynamoDB상에 인덱스 프리 인접을 구현하는 클라이언트측 솔루션입니다.

Q: 그래프 데이터베이스란 무엇입니까?

그래프 데이터베이스는 정점과 이러한 정점을 연결하는 방향 그래프의 간선을 저장한 장소입니다. 정점과 간선은 모두 속성을 키-값 페어로 저장할 수 있습니다.

그래프 데이터베이스는 순회를 간단하게 만들 수 있도록 간선을 저장하는 데 인접 목록을 사용합니다. 그래프 데이터베이스의 그래프는 특정 간선 유형을 따라 순회하거나 전체 그래프에 걸쳐 순회할 수 있습니다. 그래프 데이터베이스는 행동, 소유권, 계통 등을 사용하여 엔터티가 어떻게 관련되어 있는지 나타낼 수 있습니다.

Q: 그래프 데이터베이스에 적합한 애플리케이션은 무엇입니까?

모델링하려는 데이터의 핵심이 엔터티간의 연결 또는 관계일 경우 그래프 데이터베이스가 적격입니다. 그래프 데이터베이스는 소셜 네트워크, 비즈니스 관계, 종속성, 선박 이동 등을 모델링하고 쿼리하는데 유용합니다.

Q: Titan용 DynamoDB 스토리지 백엔드를 시작하려면 어떻게 해야 합니까?

가장 간편한 방법은 본 설명서 페이지의 CloudFormation 템플릿을 통해 Gremlin 서버가 Titan용 DynamoDB 스토리지 백엔드와 함께 구동되는 EC2 인스턴스를 시작하는 것입니다. 여기 설명서의 지침을 보면서 GitHub 리포지토리에서 프로젝트를 복제하고 본인 컴퓨터의 Marvel 및 Graph-Of-The-Gods 자습서를 따라 시작할 수도 있습니다. 테스트를 확장하거나 프로덕션 환경에서 실행할 준비가 되면 백엔드에서 DynamoDB 서비스를 사용하도록 전환할 수 있습니다. 자세한 지침은 AWS 설명서를 참조하십시오.

Q: DynamoDB 스토리지 백엔드가 다른 Titan 스토리지 백엔드와 다른 점은 무엇입니까?

DynamoDB는 관리형 서비스입니다. 따라서 이를 Titan용 스토리지 백엔드로 사용하면 그래프 스토리지를 위한 자체 클러스터를 관리할 필요 없이 그래프 워크로드를 실행할 수 있습니다.

Q: Titan용 DynamoDB 스토리지 백엔드는 완전관리형 서비스입니까?

아니요. Titan용 DynamoDB 스토리지 백엔드는 Titan 워크로드를 위한 스토리지 계층을 관리합니다. 하지만 플로그인이 클라이언트측을 프로비저닝하고 관리하지는 않습니다. Titan을 간편하게 프로비저닝할 수 있도록 Gremlin 서버와 함께 Titan용 DynamoDB 스토리지 백엔드를 설정하는 CloudFormation 템플릿을 개발했습니다. 지침은 여기를 참조하십시오.

Q: Titan용 DynamoDB 스토리지 백엔드의 비용은 어떻게 됩니까?

일반적인 DynamoDB 처리량 및 스토리지 비용이 청구됩니다. DynamoDB를 Titan 그래프 워크로드를 위한 스토리지 백엔드로 사용하는 데 따른 추가 비용은 없습니다.

Q: DynamoDB 백엔드는 다른 백엔드의 Titan 기능 세트와 완전히 호환됩니까?

설명서에 있는 다른 Titan 스토리지 백엔드의 기능 세트를 비교한 표를 참조하십시오.

Q: 플러그인이 지원되는 Titan 버전은 무엇입니까?

Titan용 DynamoDB 스토리지 백엔드 플러그인 버전 0.5.4. 및 1.0.0가 릴리스되었습니다.

Q: 저는 현재 Titan을 다른 백엔드와 사용하고 있습니다. DynamoDB로 마이그레이션할 수 있습니까?

물론입니다. Titan용 DynamoDB 스토리지 백엔드는 Titan KCV 스토어 인터페이스를 구현하므로 애플리케이션에 대한 최소한의 변경만으로 다른 스토리지 백엔드에서 DynamoDB로 전환할 수 있습니다. Titan용 스토리지 백엔드에 대한 전체 비교 자료는 설명서를 참조하십시오.

Q: 저는 현재 Titan을 다른 백엔드와 사용하고 있습니다. DynamoDB로 마이그레이션하려면 어떻게 해야 합니까?

대용량 로드를 사용하여 사용 중인 스토리지 백엔드에서 Titan용 DynamoDB 스토리지 백엔드로 그래프를 복사할 수 있습니다.

Q: 플러그인을 통해 Titan 인스턴스를 DynamoDB로 연결하려면 어떻게 해야 합니까?

설치된 Titan용 DynamoDB 스토리지 백엔드를 통해 그래프 및 Gremlin 서버 인스턴스를 생성한 경우, 기본 AWS 자격 증명 공급자 체인에 보안 주체/자격 증명 세트를 제공하기만 하면 DynamoDB와 연결됩니다. 해당 세트는 홈 폴더에 있는 자격 증명 파일, 환경 변수 또는 EC2 인스턴스 프로파일을 통해 제공할 수 있습니다. 마지막으로 연결할 DynamoDB 엔드포인트를 선택하면 됩니다.

Q: Titan용 DynamoDB 스토리지 백엔드를 사용하는 경우 데이터의 내구성은 어느 정도입니까?

Titan용 DynamoDB 스토리지 백엔드를 사용하는 경우, 데이터는 Amazon의 입증된 고가용성 데이터 센터 전체에 걸쳐 실행되는 강력한 DynamoDB 보안의 적용을 받게 됩니다. 해당 서비스에서 AWS 리전의 시설 세 곳에 데이터를 복제하여 서버 오류 발생 시나 가용 영역 정지 시에 내결함성을 제공합니다.

Q: Titan용 DynamoDB 스토리지 백엔드는 얼마나 안전합니까?

Titan용 DynamoDB 스토리지 백엔드는 그래프 데이터를 여러 DynamoDB 테이블에 저장하므로 다른 DynamoDB 워크로드와 동일한 높은 수준의 보안이 적용됩니다. 세부적인 액세스 제어, IAM 역할 및 AWS 보안 주체/자격 증명 세트는 DynamoDB 테이블과 DynamoDB 테이블의 항목에 대한 액세스를 제어합니다.

Q: Titan용 DynamoDB 스토리지 백엔드는 어떻게 확장합니까?

Titan용 DynamoDB 스토리지 백엔드는 다른 DynamoDB 워크로드와 마찬가지로 확장됩니다. 언제든지 필요한 처리량을 늘리거나 줄일 수 있습니다.

Q: 그래프에 포함할 수 있는 정점 및 간선의 수는 어떻게 됩니까?

EdgeStore용 복수 항목 모델을 사용하는 경우 그래프의 최대 간선 수와 정점의 절반은 Titan 한도인 (2^60)의 제한을 받게 됩니다. 단일 항목 모델을 사용하는 경우, 특정 아웃-정점 키에 저장할 수 있는 간선의 수는 DynamoDB의 최대 항목 크기의 제한을 받으며 현재 크기 제한은 400KB입니다.

Q: 정점 및 간선 속성의 최대 크기는 어떻게 됩니까?

복수 항목 모델에서 모든 간선 속성의 합은 최대 항목 크기인 400KB를 초과할 수 없습니다. 또한, 복수 항목 모델에서 각 정점 속성의 크기는 최대 400KB까지 가능합니다. 단일 항목 모델에서 총 항목 크기(정점 속성, 간선 및 간선 속성 포함)는 400KB를 초과할 수 없습니다.

Q: 데이터 모델은 몇 개이며, 차이점은 무엇입니까?

Titan용 DynamoDB 스토리지 백엔드에는 두 개의 스토리지 모델(단일 항목 모델과 복수 항목 모델)이 있습니다. 단일 항목 스토리지 모델의 경우, 정점, 정점 속성 및 간선이 하나의 항목으로 저장됩니다. 복수 항목 스토리지 모델의 경우, 정점, 정점 속성 및 간선이 각각 다른 항목으로 저장됩니다. 두 경우 모두, 간선 속성은 해당 간선과 같은 항목으로 저장됩니다.

Q: 어떤 데이터 모델을 사용해야 합니까?

일반적으로 edgestore 및 graphindex 테이블에는 복수 항목 데이터 모델 사용을 추천합니다. 그렇지 않은 경우, 하나의 아웃-정점에 저장할 수 있는 간선/정점-속성의 수가 제한되거나 그래프 인덱스에서 특정 속성 이름-값 페어에 인덱스할 수 있는 엔터티 수가 제한됩니다. 해당 스토어에 저장되는 항목은 보통 400KB 미만이므로, 일반적으로 Titan 버전 0.5.4 및 1.0.0의 다른 4개의 KCV 스토어에는 단일 항목 데이터 모델을 사용할 수 있습니다. Titan 플러그인이 DynamoDB에 생성하는 테이블의 전체 목록은 여기를 참조하십시오.

Q: Titan 그래프 데이터베이스를 위한 스키마를 생성해야 합니까?

Titan은 자동 유형 생성을 지원하므로 새로운 간선/정점 속성 및 레이블은 처음 사용 시에 즉시 등록됩니다(세부 정보는 여기를 참조). Gremlin 구조(간선 레이블=MULTI, 정점 속성=SINGLE)가 기본적으로 사용됩니다.

Q: Titan 그래프 데이터베이스의 스키마를 변경할 수 있습니까?

예. 하지만 기존 정점/간선 속성 및 레이블의 스키마는 변경할 수 없습니다. 세부 정보는 여기를 참조하십시오.

Q: Titan용 DynamoDB 스토리지 백엔드는 수퍼노드를 어떻게 처리합니까?

DynamoDB는 정점 레이블 파티셔닝을 통해 수퍼노드를 처리합니다. 생성 시 관리 시스템에서 정점 레이블을 파티션되도록 정의하는 경우, edgestore 테이블에 있는 파티션-정렬 키 공간상의 다른 파티션 키에서 한 정점에서 나가는 간선 및 정점 속성의 다른 하위 집합을 키로 할 수 있습니다. 이런 경우 edgestore가 하나 이상의 물리적 파티션을 가지고 있는 한, 일반적으로 가상 정점 레이블 파티션이 다른 물리적 DynamoDB 파티션에 저장됩니다. edgestore 테이블을 지원하는 물리적 파티션의 수를 추정하려면 설명서의 지침을 참조하십시오.

Q: Titan용 DynamoDB 스토리지 백엔드는 배치 그래프 작업을 지원합니까?

예. Titan용 DynamoDB 스토리지 백엔드는 Blueprints BatchGraph 구현 및 Titan의 대용량 로드 구성 옵션을 통해 배치 그래프를 지원합니다.

Q: Titan용 DynamoDB 스토리지 백엔드는 트랜잭션을 지원합니까?

Titan용 DynamoDB 스토리지 백엔드는 낙관적 잠금을 지원합니다. 즉, Titan용 DynamoDB 스토리지 백엔드는 기존 키-열 페어 값 또는 키 값에서 개별 키-열 페어(복수 항목 모델에서) 또는 개별 키(단일 항목 모델에서)의 조건부 쓰기를 지원합니다.

Q: Titan 인스턴스가 있는 리전이 아닌 다른 리전에 있는 DynamoDB에 액세스할 수 있습니까?

EC2 Titan 인스턴스가 있는 리전이 아닌 다른 리전의 DynamoDB 엔드포인트를 액세스할 수 있지만 권장하지는 않습니다. EC2상에서 Gremlin 서버를 실행하는 경우, 교차 리전 요청으로 인한 지연 시간의 영향을 줄이기 위해 EC2 인스턴스가 있는 같은 리전의 DynamoDB 엔드포인트에 연결하는 것이 좋습니다. 또한, 네트워크 성능을 향상하도록 VPC에서 EC2 인스턴스를 실행하는 것이 좋습니다. CloudFormation 템플릿에서 이 모든 구성을 수행할 수 있습니다.

Q: 이 플러그인을 업데이트 스트림, 교차 리전 복제 등과 같은 다른 DynamoDB 기능과 함께 사용할 수 있습니까?

DynamoDB 스트림 기능과 함께 교차 리전 복제를 사용하여 다른 리전에 있는 그래프 테이블의 읽기 전용 복제본을 생성할 수 있습니다.


Q: Amazon DynamoDB는 CloudWatch 지표를 보고합니까?

예. Amazon DynamoDB는 CloudWatch의 몇몇 테이블 수준의 지표를 보고합니다. 이러한 지표를 기반으로 Amazon DynamoDB 테이블에 대한 운영 의사 결정을 하고, 경보 설정 등 특정 작업을 수행할 수 있습니다. 보고되는 지표에 대한 전체 목록은 설명서의 CloudWatch를 통한 DynamoDB 모니터링 섹션을 참조하십시오.

Q: Amazon DynamoDB 테이블에 대한 CloudWatch 지표를 보려면 어떻게 해야 합니까?

Amazon DynamoDB 콘솔에서 CloudWatch 지표를 보려는 테이블을 선택한 후에 Metrics 탭을 선택하면 됩니다.

Q: 지표 보고 간격을 어떻게 됩니까?

Amazon DynamoDB에 대한 CloudWatch 지표 대부분은 1분 간격으로 보고되며 나머지 지표는 5분 간격으로 보고됩니다. 자세한 내용은 설명서의 CloudWatch를 통한 DynamoDB 모니터링 섹션을 참조하십시오.


Q: 태그란 무엇입니까?

태그는 AWS 리소스에 할당하는 레이블입니다. 각 태그는 키와 값으로 구성되며 둘 다 사용자가 정의할 수 있습니다. AWS에서는 비용 할당 보고서에서 리소스 비용을 구성하기 위한 메커니즘으로 태그를 사용합니다. 태깅에 대한 자세한 내용은 AWS Billing and Cost Management 사용 설명서를 참조하십시오.

Q: 내가 태그를 지정할 수 있는 DynamoDB 리소스는 무엇입니까?

DynamoDB 테이블에 태그를 지정할 수 있습니다. 태그가 지정된 테이블에 연결된 로컬 보조 인덱스와 글로벌 보조 인덱스는 자동으로 같은 태그가 지정됩니다. 로컬 보조 인덱스와 글로벌 보조 인덱스의 비용은 해당 DynamoDB 테이블에 사용된 태그 아래에 표시됩니다.

Q: DynamoDB에 태깅을 사용해야 하는 이유는 무엇입니까??

비용 할당을 위해 DynamoDB에 태깅을 사용할 수 있습니다. 비용 할당을 위해 태그를 사용하면 DynamoDB 리소스에 레이블을 붙일 수 있으므로 프로젝트나 다른 범주의 비용을 손쉽게 추적하여 자체 비용 구조를 반영할 수 있습니다.

Q: 비용 할당에 태그를 사용할 수 있습니까?

비용 할당 태그를 사용하면 AWS 비용을 분류하고 추적할 수 있습니다. AWS 비용 탐색기와 세부 결제 보고서는 AWS 비용을 태그별로 나눌 수 있는 기능을 지원합니다. 일반적으로 고객은 비용 센터/비즈니스 단위, 고객 또는 프로젝트와 같은 비즈니스 태그를 사용하여 AWS 비용을 기존 비용 할당 범위에 연결합니다. 하지만 비용 할당 보고서는 어떤 태그든 포함할 수 있습니다. 따라서 비용을 특정 애플리케이션, 환경 또는 규정 준수 프로그램과 같은 기술이나 보안 범위에 손쉽게 연결할 수 있습니다.

Q: 내 AWS 태그가 지정된 리소스에 할당된 비용을 보려면 어떻게 해야 합니까?

AWS 태그가 지정된 리소스에 할당된 비용은 비용 탐색기 또는 비용 할당 보고서를 통해 볼 수 있습니다.

비용 탐색기는 이전 최대 13개월의 비용을 확인하고 이후 3개월 동안 지출할 것으로 보이는 금액을 예측하는 데 사용할 수 있는 무료 AWS 도구입니다. "태그"별로 필터링하여 특정 태그에 대한 비용을 보고 태그 키와 값을 선택할 수 있습니다(태그 값이 지정되지 않은 경우 "No tag"를 선택).

비용 할당 보고서에는 각 결제 기간의 모든 AWS 비용이 포함되어 있습니다. 보고서에 태그가 지정된 리소스와 태그가 지정되지 않은 리소스가 모두 포함되어 있으므로 리소스에 대한 요금을 알아보기 쉽게 정리할 수 있습니다. 예를 들어, 애플리케이션 이름으로 리소스에 태그를 지정하면 해당 리소스에서 실행되는 단일 애플리케이션의 총 비용을 추적할 수 있습니다. 비용 할당에 대한 자세한 내용은 AWS Billing and Cost Management 사용 설명서를 참조하십시오.

Q: DynamoDB 스트림 사용량에 태그를 지정할 수 있습니까?

아니요. 현재 DynamoDB 스트림 사용량에는 태그를 지정할 수 없습니다.

Q: 예약 용량 사용량이 내 청구서에서 테이블 태그 아래에 표시됩니까?

예. 테이블별 DynamoDB 예약 용량 요금이 관련 태그 아래에 표시됩니다. 예약 용량은 모든 연결된 AWS 계정에서 DynamoDB 사용량에 선착순으로 적용됩니다. 다시 말해 테이블과 인덱스의 DynamoDB 사용량이 매월 비슷하더라도 예약 용량이 먼저 측정되는 DynamoDB 리소스를 기준으로 배분되므로 태그별 비용 할당 보고서는 월별로 다를 수 있습니다.

Q: 데이터 사용 요금이 내 청구서에서 테이블 태그 아래에 표시됩니까?

아니요. DynamoDB 데이터 사용 요금은 태그가 지정되지 않습니다. 데이터 사용량은 테이블 수준이 아니라 계정 수준에서 청구되기 때문입니다.

Q: 내 태그에 값 속성이 필요합니까?

아니요. 태그 값은 null이 될 수 있습니다.

Q: 태그는 대/소문자를 구분합니까?

예. 태그 키와 값은 대/소문자를 구분합니다.

Q: 단일 DynamoDB 테이블에 몇 개의 태그를 추가할 수 있습니까?

단일 DynamoDB 테이블에 최대 50개의 태그를 추가할 수 있습니다. 접두사가 "aws:"인 태그는 수동으로 생성될 수 없으며 리소스별 태그 한도에 포함되지 않습니다.

Q: 내 DynamoDB 테이블에 태그를 소급 적용할 수 있습니까?

아니요. 태그는 사용자가 이를 적용한 날부터 데이터를 정리하고 추적하기 시작합니다. 1월 1일에 테이블을 생성했지만 2월 1일까지 태그를 지정하지 않은 경우 1월의 모든 테이블 사용량은 태그가 지정이 안 된 상태로 유지됩니다.

Q: 해당 월의 말일이 되기 전에 내 DynamoDB 테이블에서 태그를 제거하는 경우에도 해당 태그가 내 청구서에 표시됩니까?

예. 특정 기간에 대한 비용 추적 보고서를 생성하는 경우 비용 보고서에는 해당 기간 동안 태그가 지정된 리소스 비용이 표시됩니다.

Q: DynamoDB 테이블이 삭제되면 기존 태그는 어떻게 됩니까?

DynamoDB 테이블이 삭제되면 태그가 자동으로 제거됩니다.

Q: 기존 태그의 키와 같은 키를 가진 태그를 추가하면 어떻게 됩니까?

각 DynamoDB 테이블에는 같은 키를 가진 태그를 하나만 지정할 수 있습니다. 기존 태그와 같은 키를 가진 태그를 추가하면 기존 태그가 새로운 값으로 업데이트됩니다.


Q: DynamoDB TTL(Time-to-Live)이란 무엇입니까?

DynamoDB TTL(Time-to-Live)은 특정 타임스탬프를 설정하여 만료된 항목을 테이블에서 삭제할 수 있는 메커니즘입니다. 타임스탬프가 만료되면 해당 항목이 만료로 표시되고 그 후에 테이블에서 삭제됩니다. 이 기능을 사용하면 수동으로 만료된 데이터를 추적하여 삭제할 필요가 없습니다. TTL은 스토리지 사용량을 줄이고 더 이상 관련이 없는 데이터를 저장하는 비용을 절감하는 데 도움이 됩니다.

Q: TTL을 사용해야 하는 이유는 무엇입니까?

TTL이 유용한 2가지 주요 시나리오가 있습니다.

  • 이벤트 로그, 사용 내역, 세션 데이터 등 더 이상 의미가 없는 오래된 데이터를 삭제합니다. 이러한 데이터는 시간이 지나면서 용량이 폭발적으로 늘어날 수 있고, 시스템에 저장된 오래된 데이터가 더 이상 의미가 없을 수 있습니다. 이와 같은 경우에는 시스템에서 이러한 오래된 레코드를 정리하고 이를 저장하는 데 사용되는 비용을 절감하는 것이 좋습니다.
  • 때로는 데이터 보존 및 관리 정책을 준수하기 위해 지정된 기간 동안 데이터를 DynamoDB에 유지해야 할 때가 있습니다. 의무 기간이 만료되면 결국 이 데이터를 삭제해야 할 수 있습니다. 다른 중요한 작업에 사용할 처리량을 확보하기 위해 TTL은 최선 노력 방식으로 작동한다는 점을 유념하시기 바랍니다. DynamoDB는 2일 기간 내에 만료된 항목을 삭제하는 것을 목표로 합니다. 실제로 걸리는 시간은 데이터 크기에 따라 더 길 수도 있습니다.

Q: DynamoDB TTL은 어떻게 작동합니까?

TTL을 테이블에 적용하려면 먼저 테이블의 각 항목에 대한 만료 타임스탬프를 저장할 수 있는 속성이 있어야 합니다. 이 타임스탬프는 Epoch 타임 형식이어야 합니다. 그러면 클라이언트와 서버 간에 시간대가 일치하지 않는 것을 방지할 수 있습니다.

DynamoDB는 모든 항목을 모니터링하는 백그라운드 스캐너를 실행합니다. 타임스탬프가 만료되면, 이 프로세스가 항목을 만료로 표시하고 이후에 삭제되도록 대기열에 올립니다.

참고: TTL에서 데이터의 만료 조건을 지정하려면 Epoch 타임스탬프로 채워진 숫자 형식의 DynamoDB 테이블 속성이 필요합니다. 값이 잘못되면 항목이 너무 일찍 삭제될 수 있으므로 신중하게 TTL 속성 값을 설정해야 합니다.

Q: TTL을 지정하려면 어떻게 해야 합니까?

TTL을 지정하려면, 먼저 테이블의 TTL 설정을 활성화하고 TTL 값으로 사용할 속성을 지정합니다. DynamoDB에서 만료된 항목을 자동으로 삭제하도록 하려면 테이블에 항목을 추가할 때 TTL 속성을 지정하면 됩니다. 이 값이 Epoch 시간 형식으로 지정된 만료 시간입니다. DynamoDB에서 나머지 작업을 처리합니다. TTL은 콘솔에 있는 테이블 개요 탭에서 지정할 수 있습니다. 또는, 개발자가 TTL API를 호출하여 테이블에 TTL을 구성할 수 있습니다. AWS 설명서API 안내서를 참조하십시오.

Q: 기존 테이블에 TTL을 설정할 수 있습니까?

예. 테이블이 이미 생성되었고 항목에 대한 TTL로 사용할 수 있는 속성이 있다면, 테이블에 대한 TTL을 활성화하고 TTL로 사용할 적절한 속성을 지정하기만 하면 됩니다. 테이블에 TTL로 사용할 수 있는 속성이 없다면, 이러한 속성을 생성하고 TTL 값으로 항목을 업데이트합니다.

Q: 전체 테이블에 TTL을 설정하여 모든 테이블을 삭제할 수 있습니까?

아니요. 테이블 수준에서 TTL로 사용할 속성을 정의해야 하지만, 데이터 삭제 단위는 항목 수준입니다. 다시 말해 만료 후 삭제해야 할 테이블의 각 항목에 TTL 속성으로 정의된 값이 있어야 합니다. 전체 테이블을 자동으로 삭제하는 옵션은 없습니다.

Q: 테이블의 하위 집합에 있는 항목에만 TTL을 설정할 수 있습니까?

예. TTL은 TTL 속성에 정의된 값이 있는 항목에만 적용됩니다. 테이블의 다른 항목은 영향을 받지 않습니다.

Q: TTL을 지정할 때는 어떤 형식을 사용합니까?

TTL 값은 1970년 1월 1일 UTC 이후의 초를 나타내는 숫자인 Epoch 시간 형식을 사용해야 합니다. 항목의 TTL 속성에 지정된 값의 형식이 올바르지 않은 경우, 해당 값은 무시되고 항목이 삭제되지 않습니다. 

Q: 내 테이블에 있는 항목의 TTL 값을 읽으려면 어떻게 해야 합니까?

TTL 값도 항목의 다른 속성과 다를 바가 없습니다. 다른 속성과 같은 방식으로 읽을 수 있습니다. TTL 값을 시각적으로 좀 더 쉽게 확인할 수 있도록 DynamoDB 콘솔에서는 TTL 속성에 마우스를 올리면 사람이 읽을 수 있는 현지 및 UTC 시간으로 값이 표시되는 기능을 제공합니다.

Q: 테이블의 항목에 지정된 TTL 값을 기준으로 인덱스를 생성할 수 있습니까?

예. TTL의 작동 방식은 다른 속성과 다를 바가 없습니다. 다른 항목 속성에서 하는 것처럼 인덱스를 생성할 수 있습니다.

Q: TTL 속성이 인덱스에 투영될 수 있습니까?

예. 다른 속성과 마찬가지로 TTL 속성도 인덱스에 투영될 수 있습니다.

Q: 항목에 TTL 속성 값이 설정된 후에도 해당 값을 수정할 수 있습니까?

예. 항목의 다른 속성을 수정하는 것처럼 TTL 속성 값을 수정할 수 있습니다.

Q: 테이블에 대한 TTL 속성을 변경할 수 있습니까?

예. 테이블에 TTL이 이미 활성화되어 있는 상태에서 다른 TTL 속성을 지정하려는 경우, 먼저 테이블에 대한 TTL을 비활성화해야 합니다. 그런 다음 새로운 TTL 속성으로 테이블의 TTL을 다시 활성화하면 됩니다. TTL 비활성화에는 최대 한 시간이 걸릴 수 있습니다. 모든 파티션에 적용해야 하기 때문입니다. 이 작업이 완료되기 전에는 TTL을 다시 활성화할 수 없습니다.

Q: AWS Management Console을 사용하여 TTL 값을 보고 수정할 수 있습니까?

예. AWS Management Console을 사용하면 손쉽게 TTL 값을 보고, 설정 또는 업데이트할 수 있습니다.

Q: TTL 속성이 되도록 JSON 문서 내에서 속성을 설정할 수 있습니까?

아니요. JSON 문서에서 속성을 TTL 속성으로 지정하는 기능은 현재 지원하지 않습니다. TTL을 설정하려면 각 항목에 TTL 속성을 명시적으로 추가해야 합니다.

Q: JSON 문서의 특정 요소에 대해 TTL을 설정할 수 있습니까?

아니요. TTL 값은 전체 문서에 대해서만 설정될 수 있습니다. JSON 문서의 특정 항목이 만료된 후 이를 삭제하는 기능은 지원하지 않습니다.

Q: 특정 항목에 대한 TTL을 제거해야 하는 경우엔 어떻게 해야 합니까?

TTL 제거는 TTL 속성에 지정된 값을 제거하거나 항목에 대한 속성 자체를 제거하는 것만큼 간단합니다.

Q: TTL 타임스탬프 값을 과거 시간으로 설정하면 어떻게 됩니까?

이전 TTL 값으로 항목으로 업데이트하는 것이 허용됩니다. 백그라운드 프로세스가 만료된 항목을 확인할 때마다, 이를 찾아 표시하고 이후에 삭제합니다. 하지만 TTL 속성 값에 5년이 넘은 타임스탬프에 대한 Epoch 값이 포함된 경우, DynamoDB는 해당 타임스탬프를 무시하고 항목을 삭제하지 않습니다. 이는 아주 낮은 값이 TTL 속성에 저장되어 있을 때 실수로 항목을 삭제하는 것을 완화하려는 조치입니다.

Q: 항목의 TTL 만료 시점과 해당 항목이 실제로 삭제되는 시점 간에 지연 시간은 어떻게 됩니까?

TTL은 시스템의 가용 백그라운드 처리량을 사용하여 만료된 항목을 스캔하고 삭제합니다. 따라서 만료된 항목이 테이블에서 즉시 삭제되지 않을 수 있습니다. DynamoDB는 다른 데이터 작업에서 시스템 백그라운드 처리량을 사용할 수 있도록 보장하기 위해 최선 노력 방식으로 2일의 기간 내에 만료된 항목을 삭제하는 것을 목표로 합니다. 만료된 후 실제로 항목이 삭제되기까지 정확한 기간은 워크로드의 특성과 테이블의 크기에 따라 다릅니다.

Q: TTL에 따라 만료된 항목을 쿼리하거나 스캔하려고 시도하면 어떻게 됩니까?

항목이 만료되는 시점과 백그라운드 프로세스에서 이를 삭제하는 시점 간에 지연이 발생하므로, 만료됐지만 아직 삭제되지 않은 항목을 읽으려고 시도하면 반환된 결과에 만료된 항목이 포함됩니다. 만료된 항목을 표시하지 않으려는 경우, TTL 값을 기준으로 이러한 항목을 필터링하면 됩니다.

Q: 항목이 만료된 경우, 내 로컬 보조 인덱스(LSI)의 데이터는 어떻게 됩니까?

미치는 영향은 다른 삭제 작업과 동일합니다. 로컬 보조 인덱스는 항목 자체와 같은 파티션에 저장됩니다. 따라서 항목이 삭제되면 로컬 보조 인덱스의 데이터도 바로 제거됩니다.

Q: 항목이 만료된 경우 내 글로벌 보조 인덱스(GSI)의 데이터는 어떻게 됩니까?

미치는 영향은 다른 삭제 작업과 동일합니다. 글로벌 보조 인덱스(GSI)는 최종 일관성을 따릅니다. 따라서 만료된 원래 항목이 삭제되는 동안 GSI가 업데이트되는 데는 시간이 약간 걸릴 수 있습니다.

Q: TTL은 DynamoDB Streams와 어떻게 연동됩니까?

TTL 값 때문에 테이블의 데이터가 만료되면 제거가 트리거되며 이는 삭제 작업으로 기록됩니다. 따라서 Streams도 삭제 작업을 기록합니다. 사용자가 수행한 삭제와 TTL로 인해 발생한 삭제를 구분할 수 있도록 삭제 레코드에는 추가적인 한정자가 포함됩니다. 레코드가 삭제된 실제 시간을 반영하기 위해 스트림 입력은 TTL 만료 시점이 아니라 삭제 시점에 작성됩니다. AWS 설명서API 안내서를 참조하십시오.

Q: 삭제 작업과 TTL은 각각 언제 사용해야 합니까?

TTL은 테이블에서 만료된 레코드를 제거하는 데 적합합니다. 하지만 이러한 작업은 원하지 않는 데이터를 제거하는 데 도움이 되도록 최선 노력 방식으로 수행되며 삭제 시간 범위를 보장하지는 않습니다. 따라서 테이블의 데이터가 특정 시간 기간(대부분 즉시) 내에 삭제되어야 하는 경우, 삭제 명령을 사용하는 것이 좋습니다.

Q: TTL 값을 설정하거나 업데이트할 수 있는 사용자를 제어할 수 있습니까?

예. TTL 속성은 테이블의 다른 속성과 똑같습니다. 테이블의 속성 수준에서 액세스를 제어할 수 있습니다. TTL 속성은 테이블에 지정된 일반 액세스 제어를 따릅니다.

Q: TTL 만료 후 삭제된 데이터를 검색할 수 있는 방법이 있습니까?

아니요. 만료된 항목은 삭제 전에 백업되지 않습니다. 필요한 경우 DynamoDB Streams를 활용하여 테이블의 변경 사항을 추적하고 값을 복원할 수 있습니다. 삭제 레코드는 삭제된 후 24시간 동안 Streams에 유지됩니다.

Q: 테이블에 TTL이 활성화되었는지 확인하려면 어떻게 해야 합니까?

DescribeTable API를 호출하거나 DynamoDB 콘솔에서 테이블 세부 정보를 보면 언제든 TTL의 상태를 확인할 수 있습니다. AWS 설명서API 안내서를 참조하십시오.

Q: TTL에 따라 삭제된 항목을 추적하려면 어떻게 해야 합니까?

DynamoDB Streams가 활성화된 경우, 모든 TTL 삭제가 DynamoDB Streams에 표시되고 사용자가 수행하는 명시적 삭제와 구별하기 위해 시스템 삭제로 표기됩니다. Streams에서 항목을 읽고 필요에 따라 이를 처리할 수 있습니다. 또한, Lambda 함수를 작성하여 항목을 개별적으로 아카이브할 수도 있습니다. AWS 설명서API 안내서를 참조하십시오.

Q: 내 데이터에 대해 TTL 기능을 활성화하려면 별도의 비용을 지불해야 합니까?

아니요. TTL 활성화에는 추가 비용이 들지 않습니다.

Q: TTL 활성화는 내 프로비저닝된 처리량 사용량 전반에 어떤 영향을 줍니까?

TTL에 필요한 스캔 및 삭제 작업은 시스템에서 수행하며 프로비저닝된 처리량 또는 사용량에 포함되지 않습니다.

Q: TTL을 모니터링하기 위한 스캔 작업에 대해 비용을 지불해야 합니까?

아니요. 항목의 TTL 만료를 모니터링하기 위한 내부 스캔 작업에는 비용이 부과되지 않습니다. 또한, 이러한 작업이 테이블의 처리량 사용량에 영향을 미치지도 않습니다.

Q: 만료된 항목은 삭제될 때까지 스토리지 비용이 발생합니까?

예. 항목이 만료되면 이후 삭제를 위해 삭제 대기열에 항목이 추가됩니다. 하지만 항목이 삭제되기까지는 읽거나 업데이트할 수 있는 일반 항목과 다를 바가 없으며 스토리지 비용이 발생합니다.

Q: 만료된 항목을 쿼리하는 경우 내 읽기 용량이 사용됩니까?

예. 이러한 동작은 테이블에 존재하지 않는 항목을 쿼리할 때와 똑같습니다.


Q: Amazon DynamoDB Accelerator(DAX)란 무엇입니까?

Amazon DynamoDB Accelerator(DAX)는 DynamoDB를 위한 완전관리형 고가용성 인 메모리 캐시로서, 까다로운 애플리케이션의 경우 빠른 인 메모리 성능을 활용할 수 있습니다. DAX는 읽기 집약적인 DynamoDB 워크로드의 성능을 개선하므로, DynamoDB에서 다시 쿼리할 필요 없이 매우 짧은 지연 시간으로 캐시된 데이터를 즉시 반복적으로 읽을 수 있습니다. DAX는 캐시 누락 시 DynamoDB 테이블로부터 데이터를 자동으로 검색합니다. 쓰기는 라이트-스루로 지정됩니다(데이터가 먼저 DynamoDB에 기록된 다음 캐시에 업데이트됨).

DynamoDB에서처럼 DAX는 내결함성을 갖추고 있으며 확장 가능합니다. 하나의 DAX 클러스터는 1개의 기본 노드와 0개 이상의 읽기 전용 복제본 노드로 구성됩니다. 기본 노드에 장애가 발생하면 DAX가 자동으로 장애 조치를 하고 새로운 기본 노드를 선택합니다. 조정 기능을 갖추고 있어 읽기 전용 복제본을 추가하거나 제거할 수 있습니다.

시작하려면 DAX 클러스터를 생성하고, Java용 또는 Node.js용 DAX SDK(DynamoDB API와 호환됨)를 다운로드하고, DynamoDB 클라이언트가 아니라 DAX 클라이언트를 사용하도록 애플리케이션을 다시 빌드하고, 마지막으로 DAX 클라이언트가 DAX 클러스터 엔드포인트를 가리키도록 합니다. DAX 클라이언트는 DynamoDB와 동일한 API 호출을 구현하므로 애플리케이션에 추가적인 캐싱 로직을 구현하지 않아도 됩니다.

Q: 'DynamoDB 호환'이란 무엇을 의미합니까?

현재 이미 DynamoDB와 함께 사용하고 있는 대부분의 코드, 애플리케이션 및 도구를 거의 또는 전혀 변경하지 않고 DAX에서 사용할 수 있다는 의미입니다. DAX 엔진은 DynamoDB의 데이터를 읽고 수정하는 DynamoDB API를 지원하도록 설계되었습니다. CreateTable/DescribeTable/UpdateTable/DeleteTable과 같은 테이블 관리 작업 지원되지 않습니다.

Q: 인 메모리 캐싱이란 무엇이며, 애플리케이션에 어떻게 도움이 됩니까?

캐싱은 중요한 데이터를 메모리에 저장함으로써 액세스 지연 시간을 줄이고 처리량을 높여 애플리케이션 성능을 향상합니다. DAX의 경우 DynamoDB 작업의 결과가 캐시됩니다. 애플리케이션이 캐시에 저장되어 있는 데이터를 요청하는 경우 정규 DynamoDB 테이블에 대해 쿼리를 실행하지 않고 DAX가 해당 데이터를 즉시 제공할 수 있습니다. 데이터에 대해 TTL(Time-to-Live) 값을 지정함으로써 오래된 데이터가 DAX에서 제거되거나, 모든 가용 메모리가 고갈되면 LRU(최소 최근 사용) 알고리즘에 따라 항목이 제거됩니다.

Q: DAX의 일관성 모델이란 무엇입니까?

DAX로부터 데이터를 읽을 때 사용자는 최종적 일관된 읽기를 수행할 것인지 아니면 강력한 일관된 읽기를 수행할 것인지를 지정할 수 있습니다.

최종적 일관된 읽기(기본값) – 최종 일관성 옵션은 읽기 처리량은 최대화하고 지연 시간은 최소화합니다. 캐시 적중의 경우 DAX 클라이언트가 캐시로부터 결과를 직접 반환합니다. 캐시 누락의 경우 DAX가 DynamoDB를 쿼리하고, 캐시를 업데이트한 후, 결과 세트를 반환합니다. 최종적 일관된 읽기는 최근 완료한 쓰기 결과를 반영하지 못할 수 있다는 점에 유의해야 합니다. 애플리케이션에 전체 일관성이 필요한 경우, 강력한 일관된 읽기를 사용하는 것이 좋습니다.

강력한 일관된 읽기 – 최종 일관성과 더불어, DAX는 애플리케이션이나 애플리케이션의 한 요소에 강력한 일관된 읽기가 필요한 경우 강력한 일관된 읽기를 요청할 수 있는 유연성과 제어권을 사용자에게 부여합니다. 강력한 일관된 읽기는 DAX를 패스스루하고, DAX에 결과를 캐시하지 않으며, 성공적인 응답을 받은 모든 쓰기를 반영하는 결과를 DynamoDB에 반환한 후 읽기를 수행합니다.

Q: DAX의 일반 사용 사례에는 어떤 것이 있습니까?

DAX에는 상호 배타적이지 않은 몇 가지 사용 사례가 있습니다.

읽기에서 가장 빠른 응답 시간을 요구하는 애플리케이션. 실시간 입찰, 소셜 게임, 거래 애플리케이션 등을 예로 들 수 있습니다. DAX는 이러한 사용 사례에 대해 빠른 인 메모리 읽기 성능을 제공합니다.

소수의 항목을 다른 항목보다 더 자주 읽는 애플리케이션. 예를 들면, 인기 많은 상품에 대해 하루 동안 할인 행사를 진행하는 전자 상거래 시스템을 들 수 있습니다. 할인 행사 동안 다른 모든 상품에 비해 해당 상품에 대한 수요(및 DynamoDB에 있는 관련 데이터)가 급격하게 늘어납니다. "핫" 키 및 불균일한 데이터 배포의 영향을 완화하기 위해 하루 행사가 종료될 때까지 DAX 캐시에 대한 읽기 작업을 오프로드할 수 있습니다.

읽기 집약적이면서 비용에 민감한 애플리케이션. DynamoDB를 사용하여 애플리케이션에 필요한 초당 읽기 수를 프로비저닝합니다. 읽기 작업이 증가하면 비용을 추가하여 테이블의 프로비저닝된 읽기 처리량을 늘릴 수 있습니다. 또는 애플리케이션의 작업을 DAX 클러스터로 오프로드함으로써 구매해야 할 읽기 용량 단위 수를 줄일 수도 있습니다.

대규모 데이터 집합에 대해 반복적인 읽기가 필요한 애플리케이션. 이러한 애플리케이션은 다른 애플리케이션의 데이터베이스 리소스를 잠재적으로 전용할 수 있습니다. 예를 들어, 지역 날씨 데이터의 장시간 분석은 DynamoDB 테이블의 모든 읽기 용량을 일시적으로 소진하여 동일한 데이터에 액세스해야 하는 다른 애플리케이션에 부정적인 영향을 주게 됩니다. DAX를 사용하면 해당 데이터 대신에 캐시된 데이터에 대해 날씨 분석을 수행할 수 있습니다.

사용 방법

Q: DAX에서 자동으로 수행하는 작업은 무엇입니까?

DAX는 DynamoDB를 위한 완전관리형 캐시입니다. 서버 리소스를 프로비저닝하는 것부터 DAX 소프트웨어를 설치하는 것까지 전용 캐싱 노드 설정과 관련된 작업을 관리합니다. 일단 DAX 캐시 클러스터가 설정되고 실행되면 서비스가 장애 조치 탐지 및 복구, 소프트웨어 패치 적용과 같은 일반적인 관리 작업을 자동화합니다. DAX는클러스터와 관련된 상세한 CloudWatch 모니터링 지표를 제공하므로 사용자가 문제를 빠르게 진단하고 이에 대응할 수 있습니다. 이러한 지표를 사용하여 CloudWatch 경보를 수신할 임계값을 설정할 수 있습니다. DAX가 데이터 캐싱, 검색 및 제거 작업을 모두 처리하므로 애플리케이션은 이러한 작업을 처리할 필요가 없습니다. 사용자는 DynamoDB API를 사용해 데이터를 쓰고 검색하는 작업만 수행하면 되며 DAX가 모든 캐싱 로직을 백그라운드에서 처리하여 성능을 개선합니다.

Q: DAX는 어떤 종류의 데이터를 캐시합니까?

DAX는 모든 읽기 API 호출을 캐시합니다. 강력한 일관된 읽기 요청은 DynamoDB에서 직접 수행하며, 최종적 일관된 읽기는 DAX에서 수행합니다(항목이 있는 경우). 쓰기 API 호출은 라이트-스루입니다(DynamoDB에 동기적으로 쓰기가 수행되고 쓰기가 성공하는 경우 캐시에 업데이트됨).

다음 API 호출은 캐시를 검사하게 됩니다. 적중하는 경우 항목이 반환됩니다. 누락된 경우 요청이 패스스루되고 검색 성공 시 항목이 캐시되고 반환됩니다.

• GetItem
• BatchGetItem
• Query
• Scan

다음 API 호출은 라이트-스루 작업입니다.

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

Q: DAX는 데이터 제거를 어떻게 처리합니까?

DAX는 3가지 방식으로 캐시 제거를 처리합니다. 첫 번째, 캐시에서 항목을 사용할 수 있는 절대 시간을 나타내는 TTL(Time-to-Live) 값을 사용합니다. 두 번째, 캐시가 가득 차면 DAX 클러스터가 LRU(최소 최근 사용) 알고리즘을 사용하여 제거할 항목을 결정합니다. 세 번째, 라이트-스루 기능을 사용합니다. DAX를 통해 새로운 값이 쓰여지면 DAX가 오래된 값을 제거합니다. 이는 단일 API 호출을 사용하여 DAX 항목 캐시를 기본 데이터 스토어와 일관되게 유지하는 데 도움이 됩니다.

Q: DAX는 DynamoDB GSIs 및 LSIs와 연동됩니까?

DynamoDB 테이블과 마찬가지로 DAX는 DynamoDB GSIs 및 LSIs에 대한 쿼리 및 스캔 작업 둘 다로부터 결과 세트를 캐시합니다.

Q: DAX는 어떻게 쿼리 및 스캔 결과 세트를 처리합니까?

DAX 클러스터 내에는 1) 항목 캐시와 2) 쿼리 캐시라는 2가지 캐시 방식이 있습니다. 항목 캐시는 개별 키 값 페어에 대한 GetItem, PutItem 및 DeleteItem 요청을 관리합니다. 쿼리 캐시는 스캔 및 쿼리 요청의 결과 세트를 관리합니다. 여기에서 스캔/쿼리 텍스트는 "키"가 되고 결과 세트는 "값"이 됩니다. 항목 캐시와 쿼리 캐시 모두 같은 클러스터에서 관리하지만(또한 각 캐시에 대해 서로 다른 TTL 값을 지정할 수 있지만), 중첩되지는 않습니다. 예를 들어 테이블 스캔이 항목 캐시를 채우지 않으며 대신에 스캔의 결과 세트를 저장하는 쿼리 캐시에 항목을 기록합니다.

Q: 항목 캐시를 업데이트하면 내 쿼리 캐시의 결과 세트가 업데이트되거나 무효화됩니까?

아니요. 항목 캐시와 쿼리 캐시의 결과 세트 간에 불일치를 완화하는 가장 좋은 방법은 애플리케이션이 이러한 불일치를 처리할 수 있는 적절한 기간으로 쿼리 캐시에 TTL을 설정하는 것입니다.

Q: 내 VPC 외부에서 내 DAX 클러스터에 연결할 수 있습니까?

VPC 외부에서 DAX 클러스터에 연결하는 유일한 방법은 VPN 연결을 사용하는 것입니다.

Q: DAX를 사용할 때 내 기본 DynamoDB 테이블이 제한되면 어떤 일이 발생합니까?

DAX가 DynamoDB 테이블로 쓰기 또는 읽기 작업 중에 조절 예외를 수신하는 경우, DAX는 예외를 DAX 클라이언트로 반환합니다. 또한, DAX 서비스는 서버 측 재시도를 수행하지 않습니다.

Q: DAX는 캐시 사전 워밍을 지원합니까?

DAX는 레이지 로딩 방식을 사용하여 캐시를 채웁니다. 즉, 항목을 처음 읽을 때 DAX는 DynamoDB에서 항목을 가져온 후 캐시를 채웁니다. DAX가 캐시 사전 워밍 기능을 지원하지 않지만, 원하는 데이터를 읽는 외부 스크립트/애플리케이션을 실행함으로써 애플리케이션에 대한 DAX 캐시를 사전 워밍할 수 있습니다.

Q: DAX는 DynamoDB TTL 기능과 어떻게 연동됩니까?

DynamoDB와 DAX 모두 'TTL'(또는 Time to Live) 기능에 대한 개념이 있습니다. DynamoDB의 경우, TTL은 고객이 특정 속성과 이에 상응하는 타임스탬프로 데이터를 태깅하여 데이터를 제거할 수 있는 기능입니다. 예를 들어 고객이 데이터가 한 달이 되면 해당 데이터가 삭제되길 원한다면, 고객이 에이징 워크플로를 관리할 필요 없이 DynamoDB TTL 기능을 사용하여 이러한 작업을 구현할 수 있습니다.

DAX의 경우, TTL은 캐시에 있는 항목이 유효한 시간 기간을 지정합니다. 예를 들어 TTL이 5분으로 설정된 경우 항목이 캐시에 채워지면 해당 항목은 5분 기간이 지나기 전까지 유효하고 캐시에서 제공됩니다. 본 내용에서 가장 중요한 사항은 아니지만 같은 항목의 캐시에 쓰기 작업을 하거나 DAX 노드에 메모리가 부족하고 LRU가 가장 오래전에 사용된 항목을 제거하는 경우에 TTL을 대신할 수 있습니다.

DynamoDB 및 DAX에 대한 TTL이 서로 다른 시간 척도로 운영되지만(예: DAX TTL은 분/시간 범위로 운영되고 DynamoDB TTL은 주/월/년 범위로 운영됨), 두 기능이 서로에게 어떻게 영향을 주는지 알아야 하는 경우가 있습니다. 예를 들어 DynamoDB에 대한 TTL 값이 DAX에 대한 TTL 값보다 작은 시나리오를 생각해보겠습니다. 이 시나리오에서는 항목이 예컨대 DAX에 캐시되고 DynamoDB TTL 기능을 통해 나중에 DynamoDB에서 삭제될 수 있습니다. 이는 일관성이 없는 캐시로 이어집니다. 보통 두 기능의 시간 척도에 큰 차이가 있으므로 위의 경우가 자주 발생할 것으로 예상하지는 않지만, 두 기능이 서로 어떻게 연결되어 있는지 이해하는 것이 도움이 됩니다.

Q: DAX는 교차 리전 복제를 지원합니까?

현재 DAX는 DAX 클러스터로서 같은 AWS 리전에 있는 DynamoDB 테이블만 지원합니다.

Q: DAX는 AWS CloudFormation에서 리소스 유형의 하나로 지원됩니까?

예. AWS CloudFormation을 사용하여 DAX 클러스터, 파라미터 그룹 및 서브넷 그룹을 생성, 업데이트, 삭제할 수 있습니다.

시작하기

Q: DAX를 시작하려면 어떻게 해야 합니까?
AWS 콘솔이나 AWS SDK를 통해 새로운 DAX 클러스터를 생성하여 DAX 클러스터 엔드포인트를 확보할 수 있습니다. 새로운 DAX 엔드포인트를 사용하여 DAX 호환 클라이언트를 다운로드하고 이를 애플리케이션에서 사용해야 합니다.

Q: DAX 클러스터를 생성하려면 어떻게 해야 합니까?

AWS 콘솔 또는 DAX CLI를 사용하면 DAX 클러스터를 생성할 수 있습니다. DAX 클러스터는 R3 인스턴스 유형의 경우 캐시가 13GiB(dax.r3.large)에서 216GiB(dax.r3.8xlarge)이며 R4 인스턴스 유형의 경우 캐시가 GiB(dax.r4.large)에서 488GiB(dax.r4.16xlarge)입니다. AWS 콘솔에서 클릭 몇 번으로 또는 단일 API 호출로, 클러스터에 더 많은 복제본을 추가하여(최대 10개) 처리량을 늘릴 수 있습니다.

단일 노드 구성을 사용하여 DAX를 빠르고 비용 효과적으로 시작할 수 있으며, 수요가 증가함에 따라 다중 노드 구성으로 확장할 수 있습니다. 다중 노드 구성은 쓰기를 관리하는 1개의 기본 노드와 최대 9개의 읽기 전용 복제본 노드로 이루어집니다. 기본 노드는 사용자 대신 자동으로 프로비저닝됩니다.

선호하는 서브넷 그룹/가용 영역(선택 사항), 노드 수, 노드 유형, VPC 서브넷 그룹 및 기타 시스템 설정만 지정하면 됩니다. 사용자가 원하는 구성을 선택하면, DAX가 필요한 리소스를 프로비저닝하고 특별히 DynamoDB에 사용할 캐싱 클러스터를 설정합니다.

Q: DAX를 사용하려면 내 모든 데이터가 메모리에 들어가야 합니까?

아니요. DAX는 노드의 가용 메모리를 활용합니다. TTL 및/또는 LRU를 사용하면 메모리 공간이 고갈되면 새로운 데이터를 위한 자리를 만들기 위해 항목이 삭제됩니다.

Q: DAX는 어떤 언어를 지원합니까?

DAX는 Java용 또는 Node.js용 DAX SDK를 제공하면 지금 다운로드할 수 있습니다. 다른 클라이언트도 곧 지원될 예정입니다.

Q: DAX와 DynamoDB를 동시에 사용할 수 있습니까?

예. DAX 엔드포인트와 DynamoDB를 서로 다른 클라이언트를 통해 동시에 액세스할 수 있습니다. 그러나, DynamoDB에 직접 업데이트된 후에 읽기 작업을 통해 변경 사항을 DAX로 명시적으로 가져오지 않으면 DAX가 DynamoDB에 직접 기록된 데이터 변경 사항을 탐지할 수 없습니다.

Q: 동일한 DynamoDB 테이블에 대해 여러 DAX 클러스터를 사용할 수 있습니까?

예. 동일한 DynamoDB 테이블에 대해 여러 DAX 클러스터를 프로비저닝할 수 있습니다. 이러한 클러스터는 여러 사용 사례에 사용할 수 있는 서로 다른 엔드포인트를 제공하므로 시나리오별로 최적의 캐싱 작업을 수행할 수 있습니다. 두 개의 DAX 클러스터가 서로 독립적이며 상태나 업데이트를 공유하지 않으므로 완전히 서로 다른 테이블에 대해 이를 사용하면 가장 좋습니다.

Q: 내 워크로드에 필요한 DAX 노드 유형을 어떻게 알 수 있습니까?

DAX 클러스터의 크기를 조정하는 것은 반복적인 프로세스입니다. 애플리케이션의 작업 집합이 메모리에 맞도록 충분한 메모리로 노드 3개의 클러스터(고가용성을 위해)를 프로비저닝하는 것이 좋습니다. 원하는 결과를 얻으려면 애플리케이션의 성능 및 처리량, DAX 클러스터의 사용률, 캐시 적중률 및 누락률에 따라, DAX 클러스터를 조정해야 할 수 있습니다.

Q: 어떤 종류의 EC2 인스턴스에서 DAX를 실행할 수 있습니까?

유효한 노드 유형은 다음과 같습니다.

R3:  

• dax.r3.large(13GiB)
• dax.r3.xlarge(26GiB)
• dax.r3.2xlarge(54GiB)
• dax.r3.4xlarge(108GiB)
• dax.r3.8xlarge(216GiB)

R4:

• dax.r4.large(15.25GiB)
• dax.r4.xlarge(30.5GiB)
• dax.r4.2xlarge(61GiB)
• dax.r4.4xlarge(122GiB)
• dax.r4.8xlarge(244GiB)
• dax.r4.16xlarge(488GiB)

Q: DAX는 예약 인스턴스 또는 AWS 프리 티어를 지원합니까?

현재 DAX는 온디맨드 인스턴스만 지원합니다.

Q: DAX 요금은 어떻게 책정됩니까?

DAX는 사용한 노드 시간을 기준으로 요금이 책정됩니다. 사용 시간은 노드가 시작되어 종료될 때까지의 시간입니다. 1시간 미만의 노드 사용 시간은 1시간으로 청구됩니다. 요금은 DAX 클러스터의 모든 개별 노드에 적용됩니다. 예를 들어 노드 3개의 DAX 클러스터가 있는 경우, 개별 노드(총 3개 노드)에 대한 시간당 요금이 청구됩니다.

가용성

Q: 내 DAX 클러스터로 고가용성을 달성하려면 어떻게 해야 합니까?

DAX는 기본적으로 다중 AZ를 지원하므로 사용자가 자신의 DAX 클러스터의 노드에 대해 원하는 가용 영역을 선택할 수 있습니다. DAX는 비동기적 복제를 사용하여 노드 간 일관성을 제공하므로 장애 발생 시 다른 노드가 요청을 지원할 수 있습니다. DAX 클러스터에 대해 고가용성을 달성하려면 계획된 중단 및 계획되지 않은 중단 모두에 대비하여 최소 3개 이상의 노드를 3개의 별도 가용 영역에 배포하는 것이 바람직합니다. 각 AZ는 물리적으로 분리된 자체 독립 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었습니다.

Q: DAX 노드에 장애가 발생하면 어떻게 됩니까?

기본 노드에 장애가 발생하면 DAX가 자동으로 장애를 탐지하고 사용 가능한 읽기 전용 복제본 중 하나를 선택하여 이를 새로운 기본 노드로 승격시킵니다. 또한, DAX는 장애가 발생한 기본 노드와 동일한 가용 영역에서 새로운 노드를 프로비저닝하며, 이 새로운 노드가 새로 승격된 읽기 전용 복제본을 대체합니다. 기본 노드의 장애 발생 원인이 일시적인 가용 영역 중단인 경우 AZ가 복구되면 즉시 새로운 복제본이 시작됩니다. 단일 노드 클러스터에 장애가 발생하는 경우에는 DAX가 동일한 가용 영역에서 새로운 노드를 시작합니다.

확장성

Q: DAX는 어떤 유형의 조정을 지원합니까?

DAX는 현재 두 가지 조정 옵션을 지원합니다. 첫 번째 옵션은 클러스터에 읽기 전용 복제본을 추가하여 처리량을 추가로 확보하는 읽기 조정입니다. 단일 DAX 클러스터는 최대 10개의 노드를 지원하므로 초당 수백만 개의 요청을 처리할 수 있습니다. 복제본 추가 및 제거 작업은 온라인으로 수행됩니다. 클러스터를 조정하는 두 번째 방법은 더 크거나 작은 r3 인스턴스 유형을 선택하여 규모를 확장 또는 축소하는 것입니다. 더 큰 노드를 사용하면 클러스터가 메모리에 더 많은 애플리케이션의 데이터 집합을 저장할 수 있으므로 캐시 누락이 감소하고 애플리케이션의 전반적인 성능이 개선됩니다. DAX 클러스터를 생성할 때는 클러스터에 있는 모든 노드의 인스턴스 유형이 같아야 합니다. 또한, DAX 클러스터의 인스턴스 유형을 변경하려는 경우(예: r3.large에서 r3.2xlarge로 확장) 원하는 인스턴스 유형으로 새로운 DAX 클러스터를 생성해야 합니다. DAX는 현재 온라인 확장 또는 축소 작업을 지원하지 않습니다.

Q: 내 애플리케이션의 쓰기 처리량을 확장하려면 어떻게 해야 합니까?

DAX 클러스터에서는 기본 노드만 DynamoDB로 쓰기 작업을 처리합니다. 따라서 DAX 클러스터에 노드를 추가하면 읽기 처리량이 증가하지만 쓰기 처리량은 증가하지 않습니다. 애플리케이션의 쓰기 처리량을 늘리려면 더 큰 인스턴스 크기로 확장하거나 여러 개의 DAX 클러스터를 프로비저닝하고 애플리케이션 계층에서 키 공간을 샤딩해야 합니다.

모니터링

Q: 내 DAX 클러스터의 성능을 모니터링하려면 어떻게 합니까?
AWS Management Console이나 Amazon CloudWatch API를 통해 DAX 클러스터에 대한 CPU 사용률 지표, 캐시 적중/누락 수 및 읽기/쓰기 트래픽을 확인할 수 있습니다. 또한, Amazon Cloudwatch의 사용자 지정 지표 기능을 사용해 사용자 정의 지표를 추가할 수 있습니다. CloudWatch 지표와 이외에도 DAX는 AWS Management Console을 통해 캐시 적중, 캐시 누락, 쿼리 및 클러스터 성능에 관한 정보도 제공합니다.

유지 관리

Q: 유지 관리 기간이란 무엇입니까? 소프트웨어 유지 관리 중에 내 DAX 클러스터를 사용할 수 있습니까?

DAX 유지 관리 기간을 소프트웨어 패치와 같은 클러스터 수정 작업을 수행할 시점을 제어하는 기회로 생각하면 됩니다. '유지 관리' 이벤트가 특정 주에 예정된 경우 사용자가 지정한 유지 관리 기간에 시작되고 완료됩니다.

필수 패치 적용은 보안 및 안정성과 관련된 패치에 대해서만 자동으로 예약됩니다. 그러한 패치 적용은 드물게 발생합니다(일반적으로는 몇 달에 한 번). 클러스터를 생성할 때 원하는 주별 유지 관리 기간을 지정하지 않으면 기본값이 할당됩니다. 유지 관리가 자동으로 수행되는 시점을 수정하려면 AWS Management Console에서 클러스터를 수정하거나 UpdateCluster API를 사용하여 이러한 작업을 수행하면 됩니다. 클러스터마다 원하는 유지 보수 기간을 다르게 설정할 수 있습니다.

다중 노드 클러스터의 경우 클러스터 내 업데이트가 순차적으로 수행되며 한 번에 노드 1개가 업데이트됩니다. 노드가 업데이트된 후 클러스터 내 피어 중 하나와 동기화되므로 노드가 데이터의 최신 작업 세트를 갖게 됩니다. 단일 노드 클러스터의 경우 AWS에서 복제본을 프로비저닝하고(추가 비용 없음), 최신 데이터로 복제본을 동기화한 후, 장애 조치를 수행하여 새로운 복제본을 기본 노드로 만듭니다. 이렇게 하면 단일 노드 클러스터를 업그레이드할 때 데이터가 손실되지 않습니다.  

Q: DynamoDB용 VPC 엔드포인트(DynamoDB용 VPCE)란 무엇입니까?

Amazon Virtual Private Cloud(VPC)는 Amazon Web Services(AWS) 클라우드에 논리적으로 격리된 섹션을 프로비저닝함으로서 사용자에게 가상 사설 클라우드를 제공하는 AWS 서비스입니다. DynamoDB용 VPC 엔드포인트(VPCE)는 VPC 내 논리적 엔터티로서, 인터넷, NAT 디바이스 또는 VPN 연결 없이 VPC와 DynamoDB 간에 프라이빗 연결을 생성합니다. VPC 엔드포인트에 대한 자세한 내용은 Amazon VPC 사용 설명서를 참조하십시오.

Q: DynamoDB용 VPCE를 사용해야 하는 이유는 무엇입니까??

지금까지는 VPC 내에서 DynamoDB에 액세스하기 위해서는 주로 인터넷을 트래버스해야 했고 이를 위해서는 방화벽 및 VPN과 같은 복잡한 구성이 필요했습니다. DynamoDB용 VPC 엔드포인트는 인터넷 게이트웨이나 NAT 게이트웨이를 사용할 필요 없이 VPC 내에서 DynamoDB로의 프라이빗 연결을 지원함으로써, 특히 규정 준수와 감사 요구 사항이 있는 민감한 워크로드를 다루는 고객의 프라이버시와 보안을 강화합니다. 또한, DynamoDB용 VPC 엔드포인트는 AWS Identity and Access Management(IAM) 정책을 지원하므로 DynamoDB 액세스 제어를 간소화할 수 있습니다. 따라서 이제 간편하게 DynamoDB 테이블에 대한 액세스를 특정 VPC 엔드포인트로 제한할 수 있습니다.

Q: DynamoDB용 VPCE 사용을 시작하려면 어떻게 해야 합니까?

AWS Management Console, AWS SDK 또는 AWS 명령줄 인터페이스(CLI)를 사용하여 DynamoDB용 VPCE를 생성할 수 있습니다. VPC와 VPC 내 기존 라우팅 테이블을 지정하고 엔드포인트에 연결할 IAM 정책을 명시해야 합니다. 지정된 VPC의 라우팅 테이블 각각에 경로가 자동으로 추가됩니다.

Q: DynamoDB용 VPCE는 트래픽이 Amazon 네트워크 외부로 라우팅되지 않도록 보장합니까?

예. DynamoDB용 VPCE를 사용하면, DynamoDB와 VPC 간 데이터 패킷이 Amazon 네트워크 내에 유지됩니다.

Q: DynamoDB용 VPCE를 사용하여 내 VPC와 다른 리전에 있는 테이블에 연결할 수 있습니까?

아니요. VPC 엔드포인트는 VPC와 같은 리전에 있는 DynamoDB 테이블에 대해서만 생성할 수 있습니다.

Q: DynamoDB용 VPCE는 DynamoDB의 처리량을 제한합니까?

아니요. DynamoDB의 처리량은 지금처럼 VPC 내 퍼블릭 IP가 지정된 인스턴스에서와 동일합니다.

Q: DynamoDB용 VPCE 사용 요금은 어떻게 됩니까?

DynamoDB용 VPCE 사용에 따른 추가 요금은 없습니다.

Q: DynamoDB용 VPCE를 사용하여 DynamoDB 스트림에 액세스할 수 있습니까?

현재는 DynamoDB용 VPCE를 사용하여 DynamoDB 스트림에 액세스할 수 없습니다.

Q: 현재 인터넷 게이트웨이와 NAT 게이트웨이를 사용하여 DynamoDB로 요청을 전송합니다. VPCE를 사용할 때는 내 애플리케이션 코드를 변경해야 합니까?

애플리케이션 코드를 변경할 필요는 없습니다. VPC 엔드포인트를 생성하고, DynamoDB VPCE에 있는 DynamoDB 트래픽을 가리키도록 라우팅 테이블을 업데이트한 후, DynamoDB에 직접 액세스하면 됩니다. 계속 같은 코드와 같은 DNS 이름을 사용하여 DynamoDB에 액세스할 수 있습니다.

Q: DynamoDB와 다른 AWS 서비스 양쪽에서 하나의 VPCE를 사용할 수 있습니까?

아니요. 각 VPCE는 하나의 서비스를 지원합니다. 하지만 DynamoDB용 VPCE를 하나 생성하고 다른 AWS 서비스용 VPCE를 하나 생성한 후 라우팅 테이블에서 이 둘을 사용할 수는 있습니다. 

Q: 단일 VPC에 여러 개의 VPC 엔드포인트를 만들 수 있습니까?

예. 단일 VPC에 여러 개의 VPC 엔드포인트를 만들 수 있습니다. 예를 들어 S3용 VPCE 하나와 DynamoDB용 VPCE 하나를 만들 수 있습니다.

Q: 단일 VPC에 여러 개의 DynamoDB용 VPCE를 만들 수 있습니까?

예. 단일 VPC에 여러 개의 DynamoDB용 VPCE를 만들 수 있습니다. 개별 VPCE는 서로 다른 VPCE 정책을 가질 수 있습니다. 예를 들어 한 VPCE는 읽기 전용으로, 다른 하나는 읽기/쓰기가 가능하도록 만들 수 있습니다. 하지만 VPC의 단일 라우팅 테이블은 하나의 DynamoDB용 VPCE에만 연결될 수 있습니다. 해당 라우팅 테이블이 모든 트래픽을 지정된 VPCE를 통해 DynamoDB로 라우팅하기 때문입니다.

Q: S3용 VPCE와 DynamoDB용 VPCE의 차이점은 무엇입니까?

두 VPCE 간 가장 큰 차이점은 S3와 DynamoDB라는 서로 다른 서비스를 지원한다는 것입니다.

Q: DynamoDB용 VPCE에서 수신되는 트래픽의 AWS CloudTrail 로그에는 어떤 IP 주소가 포함됩니까?

DynamoDB용 AWS CloudTrail 로그에는 VPC 내 EC2 인스턴스의 프라이빗 IP 주소와 VPCE 식별자(예: sourceIpAddress=10.89.76.54, VpcEndpointId=vpce-12345678)가 포함됩니다.

Q: AWS 명령줄 인터페이스(CLI)를 사용하여 VPCE를 관리하려면 어떻게 해야 합니까?

create-vpc-endpoint, modify-vpc-endpoint, describe-vpc-endpoints, delete-vpc-endpoint 및 descrive-vpc-endpoint-services와 같은 CLI 명령을 사용하여 VPCE를 관리할 수 있습니다. VPC 및 DynamoDB 리전에 맞춰 서비스 이름을 지정해야 합니다. ‘com.amazon.us.east-1.DynamoDB’를 예로 들 수 있습니다. 자세한 내용은 여기에서 확인할 수 있습니다.

Q: DynamoDB용 VPCE에서는 고객이 DynamoDB의 퍼블릭 IP 주소를 알고 이를 관리해야 합니까?

아니요. 고객이 이 기능을 사용하기 위해 DynamoDB의 퍼블릭 IP 주소 범위를 알거나 관리해야 할 필요는 없습니다. 라우팅 테이블과 보안 그룹에서 사용할 접두사 목록이 제공됩니다. AWS에서는 목록의 주소 범위를 유지 관리합니다. 접두사 목록 이름은 com.amazonaws.<리전>.DynamoDB입니다. 예를 들면 com.amazonaws.us-east-1.DynamoDB이 됩니다.

Q: DynamoDB용 VPCE에서 IAM 정책을 사용할 수 있습니까?

예. IAM 정책을 VPCE에 연결할 수 있으며, 이 정책은 해당 엔드포인트를 통해 모든 트래픽에 적용됩니다. 예를 들어 다음 정책을 사용하는 VPCE는 describe* API 호출만 허용합니다.
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect": "Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

Q: VPC 엔드포인트에서 내 DynamoDB 테이블로의 액세스를 제한할 수 있습니까?

예. 특정 DynamoDB 테이블용 VPCE에 대한 IAM 사용자, 그룹 또는 역할의 액세스를 제한하도록 IAM 정책을 생성할 수 있습니다.

IAM 정책의 Resource 요소를 DynamoDB 테이블로 설정하고 Condition 요소의 키를 aws:sourceVpce로 설정하면 됩니다. 자세한 내용은 IAM 사용 설명서를 참조하십시오.

예를 들어 다음 IAM 정책은 sourceVpce가 'vpce-111bbb22'와 일치하지 않는 한 DynamoDB 테이블에 대한 액세스를 제한합니다.

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect": "Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

Q: DynamoDB용 VPCE는 세분화된 액세스 제어(FGAC)에 대한 IAM 정책 조건을 지원합니까?

예. DynamoDB용 VPCE는 모든 FACC 액세스 키를 지원합니다. FGAC에 대한 IAM 정책 조건을 사용하여 개별 데이터 항목 및 속성에 대한 액세스를 제어할 수 있습니다. FGAC에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

Q: AWS Policy Generator를 사용하여 VPC 엔드포인트 정책 또는 DynamoDB를 생성할 수 있습니까?

AWS Policy Generator를 사용하여 VPC 엔드포인트 정책을 생성할 수 있습니다.

Q: DynamoDB는 S3 버킷 정책과 비슷한 리소스 기반 정책을 지원합니까?

아니요. DynamoDB는 개별 테이블, 항목 등과 관련된 리소스 기반 정책을 지원하지 않습니다.