Amazon DynamoDB FAQ

DynamoDB는 모든 규모에서 빠르고 유연한 비관계형 데이터베이스입니다. DynamoDB를 통해 고객은 분산 데이터베이스를 운영하고 AWS로 확장하는 데 따른 관리 부담에서 벗어날 수 있으며, 하드웨어 프로비저닝, 설정 및 구성, 처리량 용량 계획, 복제, 소프트웨어 패치 또는 클러스터 확장에 대해서도 걱정할 필요가 없습니다.

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

DynamoDB 테이블 클래스는 DynamoDB 테이블의 성능 및 비용 최적화 옵션입니다. 사용 가능한 두 개의 테이블 클래스는 DynamoDB Standard(최대 성능이 필요한 워크로드를 위해 설계되고 예측할 수 없는 워크로드가 있는 테이블에 가장 적합한 기본 테이블 클래스)와 DynamoDB Standard-Inrequent Access(스토리지 관련 비용이 대부분인 테이블에 최적화되어 자주 액세스하지 않는 데이터를 저장하는 테이블에 적합한 테이블 클래스)입니다. Standard 테이블은 읽기 및 쓰기 비용은 낮지만 스토리지 비용은 높습니다. Standard-IA 테이블은 스토리지 비용은 낮지만 읽기 및 쓰기 비용은 높습니다. 가동 중지 시간 없이 30일 동안 이러한 테이블 클래스 간에 두 번 전환할 수 있으므로 테이블의 사용 패턴에 따라 비용을 최적화할 수 있습니다. 이러한 클래스 간에 선택은 애플리케이션의 특정 요구 사항과 데이터의 액세스 패턴에 따라 달라집니다.

DynamoDB에서 테이블 클래스를 선택할 때는 몇 가지 요소를 고려해야 합니다. 가장 일반적으로 고려해야 할 사항은 데이터의 액세스 패턴, 비용 고려 사항, 워크로드 예측 가능성입니다. 코딩이나 가동 중지 시간 없이 테이블 클래스 간에 전환할 수 있으므로 시간 경과에 따라 요구 사항이 변경되면 선택을 조정할 수 있습니다.

DynamoDB Standard-IA(Infrequent Access) 테이블은 기존 DynamoDB 기능과 원활하게 작동합니다. 일반 DynamoDB 테이블과 동일한 API를 사용하므로 코드 변경 없이 기존 애플리케이션에서 사용할 수 있습니다. 다중 리전 복제, 시점 복구(PITR), 온디맨드 백업, AWS Key Management Service(KMS)를 사용한 저장 시 암호화, DynamoDB Streams, 항목을 자동으로 삭제하는 Time To Live, 트랜잭션 읽기 및 쓰기 작업을 위한 글로벌 테이블을 지원합니다. Standard-IA 테이블은 DynamoDB Accelerator(DAX)와 호환됩니다.

Amazon DynamoDB는 데이터를 파티션에 저장합니다. 파티션은 Solid State Drive(SSD)의 지원을 받아 AWS 리전 내 여러 가용 영역에 자동으로 복제되는 테이블에 스토리지를 할당하는 것입니다. 파티션 관리는 전적으로 DynamoDB에서 처리하므로 파티션을 직접 관리할 필요가 없습니다.

DynamoDB 테이블에 저장할 수 있는 항목의 최대 크기는 400KB입니다. 사전 정의된 스토리지 한도는 없습니다.

예. DynamoDB는 BLOB을 저장할 수 있지만 일반적으로 문서나 이미지를 저장하는 데는 적합하지 않습니다. 더 나은 아키텍처 패턴은 Amazon S3 객체에 대한 포인터를 DynamoDB 테이블에 저장하는 것입니다.

Amazon DynamoDB 테이블에 저장된 데이터에는 기본적으로 설정된 만료 또는 삭제 시간이 없습니다. Time to Live(TTL)이 활성화된 경우 TTL을 통해 삭제하지 않거나 고객이 명시적으로 삭제하는 한 데이터는 테이블에 무기한 남아 있습니다.

DynamoDB 테이블에 저장할 수 있는 항목 수에는 미리 정의된 제한이 없습니다. DynamoDB는 항목 수에 관계없이 수백 테라바이트 이상의 데이터로 확장됩니다.

DynamoDB에 이미지를 바이너리 데이터(base64로 인코딩)로 저장하는 것이 기술적으로는 가능하지만 400KB 항목 제한 크기로 인한 몇 가지 제한 및 단점이 있습니다. 이미지를 DynamoDB에 직접 저장하는 대신 Amazon S3(Simple Storage Service)에 이미지를 저장한 다음 DynamoDB에 S3 객체 URL 또는 키를 저장하는 것이 좋습니다.

DynamoDB에 목록을 저장하려면 DynamoDB의 목록 데이터 유형 중 하나인 List 또는 Set를 사용해야 합니다. 테이블에 항목을 쓸 때 해당 속성의 값은 문자열, 숫자 등과 같은 스칼라(객체가 아닌) 데이터 유형의 어레이 또는 컬렉션일 수 있습니다. DynamoDB는 자동으로 목록 데이터를 직렬화하고 목록 구조를 유지하는 방식으로 저장합니다. 그런 다음 테이블 속성을 쿼리하여 전체 목록을 검색할 수 있습니다. 목록에서 요소를 추가, 업데이트 또는 제거하는 것은 일반 쓰기 작업과 동일한 방식으로 작동합니다.

예, DynamoDB는 맵을 속성 데이터 유형으로 저장하는 것을 지원합니다. 

예. DynamoDB는 IAM 권한을 지원합니다. ID 기반 정책, 리소스 기반 정책 또는 기타 AWS 정책에서 IAM 권한을 정의하여 DynamoDB 리소스에 대한 액세스를 제어할 수 있습니다. IAM 정책을 IAM 사용자, 그룹, 역할, DynamoDB 테이블 및 스트림에 연결하고 원하는 대로 제어할 수 있습니다.

AWS PrivateLink를 통해 인터페이스 VPC 엔드포인트 및 프라이빗 IP 주소를 사용하여 가상 프라이빗 클라우드(VPC), DynamoDB 및 온프레미스 데이터 센터 간의 프라이빗 네트워크 연결을 간소화할 수 있습니다. PrivateLink를 사용하면 프라이빗 연결에서 DynamoDB 테이블에 액세스할 수 있으며 요청이 Amazon 네트워크를 떠나지 않습니다. 이렇게 하면 트래픽이 모든 네트워크 게이트웨이를 통해 흐르기 때문에 보안이 강화되고 IAM 정책 및 보안 그룹을 사용하여 액세스를 제어할 수 있습니다. PrivateLink는 데이터 보안 요구 사항이 있고 지연 시간이 짧아야 하는 애플리케이션에 유용합니다. 또한 온프레미스 네트워크와 AWS를 망라하는 하이브리드 환경에서 DynamoDB 테이블에 액세스할 수 있습니다.

예. DynamoDB는 테이블 및 스트림에 대한 리소스 기반 정책을 지원합니다. 각 테이블의 리소스 기반 정책에는 테이블의 인덱스(글로벌 보조 인덱스 및 로컬 보조 인덱스)에 대한 액세스 권한도 포함됩니다. 리소스 기반 정책을 통해 고객은 AWS 계정 수준에서 전체 액세스 권한을 부여하지 않고도 DynamoDB 테이블 및 기타 리소스에 대한 세분화된 액세스 권한을 정의할 수 있습니다. 이러한 정책을 통해 고객은 특정 DynamoDB 테이블, 인덱스 및 스트림에서 읽기, 쓰기 또는 삭제와 같은 작업을 수행할 수 있는 사용자, 역할 및 페더레이션 사용자를 제어할 수 있습니다. 리소스 기반 정책은 각 DynamoDB 리소스 내에 연결되고 관리됩니다.

리소스 기반 정책은 AWS Identity and Access Management(IAM) Access Analyzer 및 Block Public Access(BPA)와의 통합을 지원합니다. IAM Access Analyzer는 고객이 권한을 세분화하고 최소 권한을 준수하도록 도와줍니다. BPA는 고객이 DynamoDB 테이블, 인덱스 및 스트림에 대한 퍼블릭 액세스를 방지하는 데 도움이 되며 DynamoDB를 통해 항상 활성화됩니다.
 

DynamoDB는 일반적으로 DynamoDB 테이블 및 인덱스에 사용할 수 있는 속성 기반 액세스 제어를 지원합니다.

예. VPC 엔드포인트를 사용하여 Amazon DynamoDB를 사용할 수 있습니다. DynamoDB는 게이트웨이 엔드포인트와 AWS PrivateLink를 사용하는 두 가지 유형의 VPC 엔드포인트를 지원합니다. 게이트웨이 엔드포인트를 사용하면 VPC에 인터넷 게이트웨이나 NAT 장치가 없어도 VPC에서 DynamoDB에 액세스할 수 있습니다. 하지만 게이트웨이 엔드포인트는 온프레미스 네트워크, 다른 AWS 리전에서 피어링된 VPC 또는 전송 게이트웨이를 통한 액세스를 허용하지 않습니다. 이러한 시나리오에서는 추가 비용을 지불하고 이용할 수 있는 AWS PrivateLink를 사용해야 합니다.

세분화된 액세스 제어(FGAC)를 통해 DynamoDB 테이블 소유자는 AWS Identity and Access Management(IAM) 정책 및 조건을 통해 테이블의 데이터를 세밀하게 제어할 수 있습니다. FGAC를 사용하면 소유자가 테이블의 항목이나 속성 및 관련 작업에 액세스할 수 있는 권한을 제공할 수 있습니다. 세분화된 액세스 제어는 보안 자격 증명 및 관련 권한을 관리하는 AWS IAM과 함께 사용됩니다.

예. Amazon DynamoDB의 모든 사용자 데이터는 전송 및 저장 시 완전히 암호화됩니다.

HTTPS 프로토콜은 Secure Sockets Layer 암호화를 사용하여 네트워크 트래픽을 보호하는 데 사용됩니다.

저장 시 DynamoDB 암호화는 AWS Key Management Service(AWS KMS)에 저장된 암호화 키를 사용합니다. 저장 데이터는 최고 수준의 보안이 요구되는 최적의 표준인 AES-256 기술을 사용하여 암호화됩니다.

저장 데이터를 암호화하는 데 사용할 수 있는 키 유형은 다음과 같습니다.
1. AWS 소유 키: 이 키는 전적으로 AWS에서 관리하며 다른 옵션을 지정하지 않은 경우 기본적으로 사용됩니다. 무료로 사용할 수 있으며 추가 설정이 필요하지 않습니다.
2. AWS 관리형 키: AWS에서 고객을 대신하여 생성, 관리 및 사용하는 AWS Key Management Service(KMS)에 저장된 고객 관리형 키(CMK)입니다. AWS 소유 키에 비해 추가 제어 및 감사 기능을 제공합니다.
3. 고객 관리형 키: AWS KMS에서 생성, 소유 및 관리하는 CMK입니다. 액세스 제어를 생성, 교체, 비활성화 및 정의하는 기능을 포함하여 암호화 키에 대한 최고 수준의 제어 기능을 제공합니다.

이러한 각 키 유형은 편의성, 제어 및 비용 측면에서 서로 다른 균형을 제공합니다. AWS 소유 키는 사용이 가장 간단하지만 고객 관리형 키는 가장 강력한 제어 기능을 제공하지만 관리 오버헤드가 많이 필요합니다.

저장 시 암호화는 중요한 정보가 포함된 파일이 비활성 상태일 때 이를 암호화하여 데이터를 보호하는 데 도움이 됩니다. 데이터가 저장 시 암호화되면 권한이 없는 사용자는 데이터를 저장하는 장치에 물리적으로 액세스할 수 있더라도 일반 텍스트 콘텐츠에 액세스할 수 없습니다. 이는 단순한 액세스 제어 외에도 데이터에 대한 추가 보안 계층을 제공하고 물리적 장치를 분실하거나 도난당한 경우에도 기밀 정보를 기밀로 유지하는 데 도움이 됩니다.

예. DynamoDB는 테이블의 항목 수준 변경 사항에 대한 감사 로깅을 지원합니다. DynamoDB는 항목 수준에서 DynamoDB의 사용자, 역할 또는 AWS 서비스가 수행한 작업의 기록을 제공하는 서비스인 AWS CloudTrail과 통합됩니다. 캡처된 추가 로깅 데이터에는 생성, 업데이트, 삭제 및 모든 조건부 검사 실패가 포함됩니다. 고객은 CloudWatch Logs에 저장된 이러한 로그 레코드에 액세스하고 애플리케이션을 구축하여 감사, 모니터링 또는 기타 목적으로 항목 수준 변경 사항을 분석할 수 있습니다. 감사 로깅은 DynamoDB 테이블의 일반적인 읽기/쓰기 성능에 영향을 주지 않으면서 세부적인 수준에서 데이터 변경 사항을 파악할 수 있습니다.

예, Amazon DynamoDB를 사용하면 AWS에서 HIPAA 규정 준수 애플리케이션을 구축하고 비즈니스 제휴 계약(BAA)에서 규정하는 개인 건강 정보(PHI)를 비롯한 의료 관련 정보를 저장할 수 있습니다.

DynamoDB는 HIPAA 자격, FedRAMP, ISO 27001, SOC 1/SSAE 16/ISAE 3402(이전 명칭은 SAS 70) 및 SOC 2를 비롯한 많은 규정 준수 인증을 충족합니다. 자세한 내용은 DynamoDB에 대한 산업별 규정 준수 검증을 참조하세요. AWS 규정 준수 보고서는 AWS Artifact에서 다운로드할 수 있습니다.

Amazon DynamoDB 글로벌 테이블은 완전 관리형 서버리스, 다중 리전, 다중 활성 데이터베이스입니다. 글로벌 테이블은 99.999% 가용성, 향상된 애플리케이션 복원력, 향상된 비즈니스 연속성을 제공합니다. 글로벌 테이블이 선택한 AWS 리전에서 DynamoDB 테이블을 자동으로 복제하므로 빠른 로컬 읽기 및 쓰기 성능을 얻을 수 있습니다. 글로벌 테이블은 단일 리전 DynamoDB 테이블과 동일한 API를 사용하므로 애플리케이션 변경 없이 DynamoDB 테이블을 전역적으로 쉽게 사용할 수 있습니다.

여러 리전에서 애플리케이션의 복원력을 향상시키려면 글로벌 테이블을 사용해야 합니다. 또한 글로벌 테이블을 사용하면 전체 리전이 격리되거나 성능이 저하되는 예기치 않은 경우에도 애플리케이션이 고가용성을 유지할 수 있습니다.

DynamoDB 글로벌 테이블에는 버전 2019.11.21(최신)과 버전 2017.11.29(레거시)의 두 가지 버전이 있습니다. 고객은 모든 새 글로벌 테이블에 대해 버전 2019.11.21(최신)을 사용해야 합니다. 이 버전은 더 효율적이고 쓰기 용량을 덜 소비하기 때문입니다. 버전 2017.11.29(레거시)를 사용하는 사용자는 글로벌 테이블을 버전 2019.11.21(최신)로 업그레이드해야 합니다.

AWS Management Console에서 클릭 몇 번으로 글로벌 테이블의 버전을 업그레이드할 수 있습니다. 버전 2017.11.29(레거시)에서 2019.11.21(최신) 버전으로 업그레이드하는 것은 일회성 작업이며 되돌릴 수 없습니다. 업그레이드하기 전에 버전 간의 동작 차이를 검토하고 필요한 모든 테스트를 수행했는지 확인하세요. 자세한 내용은 버전 2017.11.29(레거시)에서 버전 2019.11.21(최신)로 글로벌 테이블 업그레이드를 참조하세요.

DynamoDB 글로벌 테이블은 리전 간 다중 활성 복제를 사용합니다. 글로벌 테이블의 모든 리전에 있는 모든 복제본 테이블은 읽기 및 쓰기 트래픽을 지원합니다. 글로벌 테이블에는 기본 리전이 없으므로 읽기 및 쓰기 트래픽을 다른 리전으로 보낼 때 데이터베이스 장애 조치가 필요하지 않습니다. 드문 경우이긴 하지만 AWS 리전이 격리되거나 성능이 저하되는 경우에도 애플리케이션은 영향을 받지 않은 리전의 복제본 테이블에서 간단히 읽고 쓸 수 있습니다. 자세한 내용은 DynamoDB 글로벌 테이블 설계 모범 사례를 참조하세요.

예, Amazon은 변경 데이터 캡처(CDC)를 지원합니다. DynamoDB에서 CDC는 스트리밍 모델을 사용하여 구현되며, 이를 통해 애플리케이션은 거의 실시간으로 DynamoDB 테이블의 항목 수준 변경을 데이터 레코드의 스트림으로 캡처할 수 있습니다. 데이터 레코드의 CDC 스트림을 통해 애플리케이션은 DynamoDB 테이블의 데이터 수정을 효율적으로 처리하고 이에 대응할 수 있습니다. DynamoDB는 CDC를 위한 두 가지 스트리밍 모델, 즉 Amazon DynamoDB Streams와 DynamoDB용 Amazon Kinesis Data Streams를 제공합니다. 애플리케이션에 적합한 솔루션을 선택하는 데 도움이 필요하면 변경 데이터 캡처를 위한 스트리밍 옵션을 참조하세요.

DynamoDB Streams는 DynamoDB 테이블의 항목 변경 사항에 대한 정보의 순서가 지정된 흐름입니다. DynamoDB Streams는 중복 제거되고 시간순으로 정렬된 항목 수준 수정 시퀀스를 테이블에 캡처하고 이 정보를 최대 24시간 동안 로그에 저장합니다. DynamoDB Streams는 용량을 자동으로 확장하므로 용량을 프로비저닝하고 관리할 필요가 없습니다. DynamoDB Streams 구성을 기반으로 데이터 항목이 수정되기 전과 후에 어떻게 표시되는지 볼 수 있습니다. 이러한 스트림 이벤트를 사용하고 이벤트 스트림의 콘텐츠를 기반으로 워크플로를 간접적으로 호출하는 애플리케이션을 구축할 수 있습니다.

DynamoDB Streams는 AWS Lambda와의 기본 통합을 사용하여 데이터 변경에 트리거로 대응하고, 고객 상호 작용을 추적 및 분석하거나, 애플리케이션 성능을 거의 실시간으로 모니터링하고, 순서가 지정된 이벤트 시퀀스를 캡처하고, 항목 수준의 트랜잭션 데이터 복제를 통해 애플리케이션 복원력을 향상하려는 경우에 유용합니다.

Kinesis Data Streams는 모든 DynamoDB 테이블에서 항목 수준 수정을 캡처하고 해당 수정 사항을 Kinesis Data Streams로 복제합니다. 애플리케이션은 이 스트림에 액세스하여 거의 실시간으로 항목 수준의 변경 사항을 볼 수 있습니다. Kinesis Data Streams를 사용하면 특수한 요구 사항에 맞춰 스트리밍 데이터를 처리 또는 분석하는 사용자 지정 애플리케이션을 구축할 수 있습니다. DynamoDB Streams와 달리 DynamoDB용 Kinesis Data Streams는 레코드 정렬이나 중복 제거를 보장하지 않습니다. 레코드 정렬 및 중복 제거는 항목 수준 레코드의 ApproximateCreationDateTime 필드를 사용하여 클라이언트 애플리케이션에서 구현해야 합니다.

DynamoDB용 Kinesis Data Streams는 광범위한 Kinesis 에코시스템(예: Kinesis Client Library, Amazon Managed Service for Apache Flink 또는 Amazon Data Firehose)과의 통합, 더 길어진 데이터 보존 기간 및 재생 가능성(최대 365일), 다운스트림 사용 및 스트리밍 분석을 위한 사용자 지정 샤드 관리가 필요한 경우에 유용합니다.

DynamoDB 테이블에서 DynamoDB Streams 또는 Kinesis Data Streams를 활성화하면 테이블은 해당 테이블 데이터의 모든 변경 사항을 캡처하는 데이터 레코드를 전송합니다. 이 데이터 레코드에는 항목이 최근에 생성, 업데이트 또는 삭제된 특정 시간, 해당 항목의 프라이머리 키, 수정 전 항목 이미지, 수정 후 항목 이미지가 포함됩니다.

AWS Management Console, AWS SDK, AWS Command Line Interface(AWS CLI) 또는 Kinesis Client Library(KCL)를 사용하여 기존 DynamoDB 테이블에서 스트림을 활성화하거나 비활성화할 수 있습니다.

특히 DynamoDB 테이블 변경을 추적해야 하는 경우 DynamoDB Streams를 선택하세요. 더 광범위한 스트리밍 요구 사항, 더 높은 처리량 요구 사항 또는 더 긴 데이터 보존 기간이 필요한 경우 Kinesis Data Streams를 선택하세요.

Amazon DynamoDB TTL(Time to Live) 기능은 테이블에서 더 이상 관련이 없는 만료된 항목을 자동으로 삭제하여 스토리지 사용량을 줄이고 비용을 절감합니다. TTL을 사용하면 항목당 타임스탬프를 정의하여 항목이 더 이상 필요하지 않은 시기를 결정할 수 있으며, DynamoDB는 쓰기 처리량을 소비하지 않고 해당 항목을 테이블에서 자동으로 삭제합니다. 항목을 만들거나 업데이트할 때마다 만료 시간을 계산하여 TTL 속성에 저장할 수 있습니다. TTL은 특정 시간이 지나면 관련성이 없는 항목을 저장할 때 유용합니다.

DynamoDB에서는 사용자가 정의한 프라이머리 키를 사용하여 GET/PUT 작업을 지원합니다. 기본 키는 테이블 항목에 필요한 유일한 속성입니다.. 사용자가 테이블을 생성할 때 프라이머리 키를 명시하며, 이 프라이머리 키가 각 항목을 고유하게 식별합니다. 또한, DynamoDB는 글로벌 보조 인덱스 및 로컬 보조 인덱스를 사용하여 프라이머리가 아닌 키 속성을 쿼리할 수 있어 유연한 쿼리 기능을 이용할 수 있습니다.

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

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

DynamoDB 콘솔 또는 CreateTable API를 사용하여 테이블을 만든 후 PutItem 또는 BatchWriteItem API를 사용하여 항목을 삽입할 수 있습니다. 그런 다음, GetItem 또는 BatchGetItem를 사용하거나 테이블에서 복합 기본 키가 활성화되어 사용되고 있는 경우에는 Query API를 사용하여 테이블에 추가한 항목을 검색할 수 있습니다.

예. DynamoDB는 API를 통해 액세스하는 완전관리형 클라우드 서비스입니다. 특정 운영 체제(Linux, Windows, iOS, Android, Solaris, AIX, HP-UX 등)에서 실행되는 애플리케이션이든 DynamoDB를 사용할 수 있습니다. DynamoDB는 AWS SDK를 사용해 시작하는 것이 좋습니다.