AWS Section 22-2. AWS 서버리스 : DynamoDB

DynamoDB - Time To Live (TTL)

• TTL 기능: 만료된 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능이다. 이로 인해 사용자가 설정한 시간이 지나면 항목이 삭제된다.
• 추가 비용 없음: WCU(쓰기 용량 단위)를 소비하지 않기 때문에, TTL로 삭제된 항목에 대해 추가 비용이 발생하지 않는다.
• 타임스탬프 형식: TTL 속성 값은 "Unix Epoch 타임스탬프"로, 숫자 데이터 타입이어야 한다.
• 삭제 시간: 만료된 항목은 즉시 삭제되지 않고, 만료 시점으로부터 최대 48시간 내에 삭제가 완료된다.

• SessionData 표에서 User_ID, Session_ID와 함께 ExpTime (TTL)이라는 열이 추가되어 있다.
• 이 TTL 열은 각 세션의 만료 시간을 나타내며, 만료 시간이 지나면 항목이 자동으로 삭제된다.

 

• 삭제되지 않은 만료된 항목
  • 아직 삭제되지 않은 만료된 항목은 읽기, 쿼리, 스캔 작업에서 보일 수 있다.
  • 원하지 않는 경우에는 클라이언트 측에서 필터링을 해야 한다.
• 인덱스에서의 삭제
  • 만료된 항목이 삭제되면 로컬 보조 인덱스(LSI)나 글로벌 보조 인덱스(GSI)에서도 함께 삭제된다.
• DynamoDB Streams와 통합
  • TTL로 삭제된 각 항목은 DynamoDB Streams에 기록되며, 이를 통해 필요한 경우 삭제된 데이터를 복구하거나 백업할 수 있다.
• 주요 사용 사례
  • 저장 공간 절약을 위해 현재 항목만 유지
  • 규제 요구사항 준수 (예: 개인정보 보호 규정에 따라 만료된 데이터 삭제)

 

 

DynamoDB CLI – 알아두면 좋은 옵션

• --projection-expression: 한 개 이상의 속성을 지정해 원하는 속성만 가져오는 옵션이다. 모든 속성을 불러오는 대신 필요한 속성만 선택해 데이터를 줄일 수 있다.
• --filter-expression: 반환될 아이템을 조건에 따라 필터링하는 옵션이다. 필터 조건을 지정해 데이터의 양을 줄이고, 원하는 데이터만 결과로 받는다.

 

General AWS CLI Pagination options  (예: DynamoDB, S3 등)

• --page-size
  • 전체 데이터 세트를 가져오면서도 개별 API 호출 크기를 조절하는 옵션이다.
  • 예를 들어, 10,000개의 항목을 한 번에 가져오면 시간 초과가 발생할 수 있는데, --page-size를 100으로 설정하면 API 호출이 100번으로 나눠져 시간 초과를 방지할 수 있다.
• --max-item
  •  CLI 호출 결과에서 보여줄 아이템의 최대 개수를 지정한다.
  • 이 옵션은 NextToken과 결합해 사용되며, 결과를 필요한 만큼만 나눠서 볼 수 있게 한다.
• --starting-token
  • NextToken을 사용해 마지막 호출에서 이어 다음 데이터 세트를 가져온다.
  • 이를 통해 연속적인 호출을 할 때 시작 위치를 설정할 수 있다.

EX ) 사용자가 처음 25개의 아이템을 받고 다음 25개의 아이템을 가져오고 싶을 때 NextToken을 사용하면 된다. 이를 통해 큰 데이터 세트를 필요한 만큼 나눠서 효과적으로 조회할 수 있다. 이 옵션들을 활용하면 AWS CLI에서 더 효율적이고 유연하게 DynamoDB 데이터에 접근할 수 있다.

 

 

트랜잭션 개요

• 트랜잭션은 하나 이상의 테이블에서 여러 아이템에 대한 작업(추가, 수정, 삭제)을 일괄적으로 처리하는 기능이다.
• 트랜잭션은 원자성(Atomicity), 일관성(Consistency), 격리(Isolation), 내구성(Durability)(ACID)을 보장한다.
• 트랜잭션 작업은 모두 성공하거나 모두 실패하는 "All-or-Nothing" 방식이다.

 

트랜잭션 읽기/쓰기 모드

• 읽기 모드는 최종 일관성(Eventual Consistency), 강력한 일관성(Strong Consistency), 트랜잭션 일관성(Transactional) 세 가지가 있다.
• 쓰기 모드는 표준(Standard)과 트랜잭션(Transaction)이 있다.
• 트랜잭션 모드에서는 필요한 쓰기/읽기 용량 단위(WCU/RCU)가 2배로 소비된다.

 

트랜잭션 작업 종류

1. TransactGetItems: 여러 GetItem 작업을 트랜잭션으로 실행.
2. TransactWriteItems: 여러 PutItem, UpdateItem, DeleteItem 작업을 트랜잭션으로 실행.

 

트랜잭션 예시

AccountBalance와 BankTransactions 테이블

• AccountBalance에는 계좌의 잔액과 마지막 트랜잭션 시간이 기록되고, BankTransactions에는 거래 내역이 기록된다.
• 트랜잭션을 통해 AccountBalance에서 UpdateItem을 실행하고, 동시에 BankTransactions에서 PutItem을 실행한다.
• 트랜잭션은 두 테이블에 동시에 적용되거나, 실패 시 둘 다 적용되지 않는다.

 

용량 계산 예시

1. 트랜잭션 쓰기 예시: 초당 3개의 트랜잭션 쓰기, 아이템 크기 5KB
   • 계산: 3 * (5/1) * 2 = 30 WCUs
2. 트랜잭션 읽기 예시: 초당 5개의 트랜잭션 읽기, 아이템 크기 5KB
   • 계산: 5 * (8/4) * 2 = 20 RCUs
   • 여기서 아이템 크기 5KB는 4KB 단위로 반올림되어 8KB로 계산됨.

 

 

세션 상태 캐시로 DynamoDB 사용

 

• DynamoDB는 세션 상태를 저장하는 데 자주 사용된다.
• 이는 웹 애플리케이션에서 사용자 로그인 상태와 같은 세션 데이터를 저장하고 공유하는 데 유용하다.
• DynamoDB는 서버리스 서비스로, 오토 스케일링을 지원하여 세션 데이터의 증가에 따라 유연하게 대응할 수 있다.

 

다른 스토리지와의 비교

1. vs. ElastiCache
   • ElastiCache는 인메모리 캐시로, 속도가 매우 빠르지만 서버리스는 아니다.
   • 둘 다 키/값 저장소 역할을 하지만, ElastiCache는 인메모리로 즉각적인 접근이 필요할 때 적합하고, DynamoDB는 서버리스와 오토 스케일링이 필요할 때 더 적합하다.
2. vs. EFS
   • EFS는 네트워크 파일 시스템으로, 여러 EC2 인스턴스에서 공유할 수 있다.
   • EFS는 EC2 인스턴스에 네트워크 드라이브로 연결되며, 주로 파일 시스템으로 사용된다. DynamoDB는 데이터베이스로 사용된다.
3. vs. EBS & Instance Store
   • EBS와 Instance Store는 각각 EC2 인스턴스에 연결되는 스토리지다.
   • 이들은 로컬 캐싱에는 적합하지만, 한 인스턴스에만 연결 가능하므로 공유 캐싱에는 적합하지 않다.
4. vs. S3
   • S3는 높은 레이턴시를 가지며, 작은 객체보다는 큰 파일 저장에 적합하다.
   • 세션 상태와 같은 작은 데이터를 저장하는 데는 부적합하다.

DynamoDB와 ElastiCache는 세션 상태를 캐싱하는 데 가장 적합한 선택지이다.

ElastiCache는 인메모리 접근이 필요할 때, DynamoDB는 서버리스와 오토 스케일링이 필요할 때 사용한다.

 

 

 

쓰기 샤딩 문제와 해결

DynamoDB에서 특정 파티션 키를 중심으로 데이터가 쏠릴 경우, 핫 파티션(hot partition) 문제가 발생할 수 있다.

예를 들어, 투표 애플리케이션에서 후보자 A와 후보자 B라는 두 명의 후보가 있을 때, 파티션 키가 "Candidate_ID"로 설정되면, A와 B라는 두 개의 파티션만 생성된다.

이렇게 되면 두 파티션에 쓰기 요청이 집중되어 성능에 문제가 발생할 수 있다.

해결 방법: 파티션 키에 접미사 추가

• 이 문제를 해결하기 위해 파티션 키 값에 접미사(suffix)를 추가하여 파티션 분포를 넓힌다.
• 예를 들어, "Candidate_A-11", "Candidate_B-17"과 같이 Candidate_ID에 고유한 접미사를 추가하면 파티션이 여러 개로 분산되어, 읽기와 쓰기 요청이 고르게 분배될 수 있다.

접미사 생성 방법

1. 랜덤 접미사 사용: 각 파티션 키에 랜덤한 접미사를 추가하여 고유성을 확보한다.
2. 계산된 접미사 사용: 해싱(hashing) 알고리즘을 사용하여 파티션 키를 계산하고, 이를 접미사로 활용한다.

 

동시 쓰기

첫 번째 사용자가 값을 1로 업데이트하고, 두 번째 사용자가 값을 2로 업데이트하여 최종 값이 2가 됨.

 

• 두 사용자가 동시에 동일한 아이템을 업데이트하려고 한다. 첫 번째 사용자는 값을 1로 설정하고, 두 번째 사용자는 값을 2로 설정한다.
• 결과: 두 쓰기 요청이 모두 성공하지만, 두 번째 쓰기가 첫 번째 쓰기를 덮어쓰게 된다. 최종 값은 2가 된다.
• 문제점: 두 사용자가 모두 성공하지만, 나중에 실행된 쓰기가 이전 쓰기를 덮어쓰는 문제로 인해 예기치 않은 결과가 발생할 수 있다.

 

 

조건부 쓰기

 

 

 

첫 번째 쓰기 성공 후, 두 번째 쓰기는 실패함

 

• 쓰기 작업에 조건을 추가하여, 특정 조건이 충족될 때만 쓰기를 허용한다. 예를 들어, 첫 번째 사용자는 값이 0일 때만 1로 업데이트하고, 두 번째 사용자는 값이 0일 때만 2로 업데이트한다.
• 결과: 첫 번째 사용자의 쓰기가 허용되어 값이 1로 업데이트되면, 두 번째 사용자의 쓰기는 실패한다. 이는 두 번째 사용자가 요구한 조건인 값이 0이라는 조건이 충족되지 않기 때문이다.
• 특징: 조건부 쓰기는 낙관적 잠금(optimistic locking)으로, 동시성 문제를 방지하는 데 사용된다.

 

 

원자적 쓰기

 

두 사용자의 업데이트가 누적되어 최종 값이 3이 됨

 

• 원자적 쓰기는 값을 누적하여 업데이트하는 방식이다. 예를 들어, 첫 번째 사용자가 값을 1씩 증가시키고, 두 번째 사용자가 값을 2씩 증가시키려 한다.
• 결과: 두 사용자의 요청이 모두 성공하여 최종 값은 3(1 + 2)이 된다.
• 특징: 원자적 쓰기는 값이 덮어쓰이지 않고 누적되는 방식으로, 동시 쓰기에 대한 안전성을 제공한다.

 

 

배치 쓰기

 

 

다수의 아이템에 대한 쓰기 작업이 한 번에 수행됨.

 

• 여러 아이템에 동시에 쓰기 또는 업데이트 작업을 수행한다.
• 특징: 동시성 문제와 관계없이 여러 아이템을 한 번에 처리하는 방식으로, 대량의 데이터를 효율적으로 다룰 때 유용하다.

 

DynamoDB와 S3의 연동을 통한 Large Objects Pattern 저장 및 인덱싱 방법

1. Large Objects Pattern
   
   • DynamoDB는 400KB 이상의 데이터를 직접 저장할 수 없다. 따라서 큰 객체(이미지나 비디오)는 DynamoDB 대신 Amazon S3에 저장하는 것이 일반적이다.
   • 예시로 애플리케이션이 큰 이미지 파일을 S3 버킷에 업로드하면, S3에서 객체 키(파일의 URL)를 반환받는다.
   • DynamoDB에는 이미지 자체가 아니라 관련 메타데이터(상품 ID, 상품 이름, S3 URL)를 저장하여 효율적인 데이터 관리가 가능하다.

 

• 상단 애플리케이션에서 이미지를 업로드하면, 중앙에 있는 S3 버킷에 저장되고 객체 URL이 DynamoDB의 Products 테이블에 저장된다. 테이블에는 Product_ID, Product_Name, Image_URL 속성이 포함되어 있다

 

2. S3 객체 메타데이터 인덱싱 패턴

• S3에 객체를 업로드할 때 람다(Lambda) 함수를 호출하도록 설정하여 객체 메타데이터를 DynamoDB에 저장한다.
• 메타데이터에는 파일 크기, 업로드 날짜, 소유자 등이 포함된다. 이렇게 DynamoDB에 메타데이터를 저장하면 S3 버킷을 직접 스캔하지 않고도 빠르게 쿼리할 수 있다.
• 이 방식으로 사용자는 특정 날짜 범위 내의 객체를 검색하거나, 고객이 사용한 전체 스토리지 양을 조회하는 등 효율적인 데이터를 관리할 수 있다.

• 상단 애플리케이션이 S3에 객체를 업로드하면, S3가 람다 함수를 호출하여 해당 객체의 메타데이터를 DynamoDB에 저장한다.
• 하단의 클라이언트는 DynamoDB 테이블을 통해 원하는 객체 메타데이터를 쿼리할 수 있다.

큰 데이터는 S3에, 메타데이터는 DynamoDB에 저장하여 효율성을 극대화한다.이 두 가지 패턴은 S3와

DynamoDB를 효과적으로 조합해 다양한 시나리오에서 활용할 수 있다.

 

 

DynamoDB 작업 

1. 테이블 정리 (Table Cleanup)
   • 옵션 1: 스캔 + DeleteItem
     • 테이블의 모든 아이템을 스캔한 후 각각을 삭제하는 방식이다.
     • 매우 느리며, 스캔 과정에서 많은 RCU(읽기 용량 단위)를 소비하고, 삭제 작업에서도 많은 WCU(쓰기 용량 단위)를 소비하여 비용이 많이 든다.
   • 옵션 2: 테이블 드롭 후 재생성
     • 테이블을 삭제(dropping)하고 동일한 설정으로 다시 생성하는 방법이다.
     • 빠르고 효율적이며 저렴하다. 이때 기존 테이블의 설정을 정확히 복구하는 것이 중요하다.
2. DynamoDB 테이블 복사 (Copying a DynamoDB Table)
   • 옵션 1: AWS Data Pipeline 사용
     • AWS Data Pipeline을 통해 DynamoDB 테이블을 복사하는 방식이다.
     • 그림설명: AWS Data Pipeline이 Amazon EMR 클러스터를 실행하여 DynamoDB 테이블의 데이터를 S3 버킷에 저장하고, 이후 S3에서 데이터를 읽어 새로운 DynamoDB 테이블로 복사한다.
   • 옵션 2: 백업 및 복구
     • DynamoDB 테이블을 백업한 후 새로운 테이블에 복구하는 방식이다.
     • 시간이 걸리지만, 추가적인 외부 서비스가 필요하지 않아 간편하고 효율적이다.
   • 옵션 3: 스캔 후 PutItem 또는 BatchWriteItem
     • 직접 스캔 후, PutItem이나 BatchWriteItem을 통해 데이터를 쓰는 방식이다.
     • 스스로 코드를 작성해야 하지만, 효율적으로 제어할 수 있어 특정 상황에서 고려할 수 있는 옵션이다.

 

DynamoDB – Security & Other Features

보안 기능

• VPC 엔드포인트: 인터넷 노출 없이 VPC 내에서 DynamoDB에 액세스할 수 있도록 하여 트래픽이 VPC 내부에 머물게 한다.
• IAM을 통한 액세스 제어: DynamoDB에 대한 세부적인 접근 제어를 통해 누가 접근할 수 있는지 명확하게 관리할 수 있다.
• 암호화: 저장 중인 데이터는 AWS KMS로, 전송 중인 데이터는 SSL/TLS로 암호화된다.

백업 및 복구

• 지정 시점 복구(PITR): RDS와 유사하게 성능에 영향을 주지 않고 복구를 가능하게 한다.
• 수동 백업: 데이터 안전을 위한 추가적인 백업 옵션을 제공한다.

글로벌 테이블

• 다중 리전 및 다중 활성화: 여러 리전에서 고성능의 완전 복제 테이블을 지원하며, 리전 간 복제를 위해 DynamoDB Streams를 활성화해야 한다.

DynamoDB 로컬

• 로컬 시뮬레이션: 인터넷 연결 없이 개발 및 테스트를 가능하게 하여 오프라인 테스트에 유용하다.

데이터 마이그레이션

• AWS 데이터베이스 마이그레이션 서비스(DMS): MongoDB, Oracle, MySQL, S3 등 다양한 데이터 소스를 DynamoDB로 마이그레이션할 때 사용된다.

 

DynamoDB와의 직접적인 사용자 상호작용 요약

• 신원 제공자(Identity Providers): 사용자가 Amazon Cognito, Google, Facebook, SAML 등과 같은 제공자를 통해 로그인하여 임시 AWS 자격 증명을 받을 수 있다.
• 권한 관리: 클라이언트와 애플리케이션이 IAM 역할을 얻어 일시적인 권한을 부여받아 직접 DynamoDB에 접근할 수 있다.

 

세분화된 액세스 제어 요약

• 웹 ID 연합: Cognito와 같은 제공자를 통해 사용자가 로그인할 수 있도록 하여 임시 AWS 자격 증명을 부여한다.
• 조건부 IAM 역할: IAM 역할에 조건을 부착하여 사용자가 자신의 데이터에만 제한적으로 접근할 수 있게 한다.
• LeadingKeys: 기본 키를 기반으로 행 수준 액세스를 제한하여 사용자가 자신의 레코드만 접근하도록 보장한다.
• 속성 제한: DynamoDB에서 사용자가 볼 수 있는 속성을 제한할 수 있다.