4. 요약정리(DynamoDB)

기본 개념

• 테이블의 최대 크기 = 400KB

 

Gateway Endpoint

• VPC에서 인터넷을 거치지 않고 S3나 DynamoDB로 바로 가는 전용 비밀 통로
  
• 원래 AWS 관리 서비스라서 인터넷을 통해 AWS VPC로 가서 사용해야 하지만 보안을 높이기 위해 VPC에서만 사용할 수 있는 인터넷을 거치지 않는 비밀 통로를 만든다
  →  그래서 VPC 내부 리소스가 DynamoDB에 접근 가능하게 한다 
• 지원 서비스 
  
  • AmazonS3
  • Amzon Dynamo DB

 

WCU & RCU

• WCU
  • 항목 최대 크기 1KB
  • 계산법 = (초당 쓰기 횟수) * (크기/1KB) (올림)
• RCU
  • 최종적 일관된 읽기 (기본값)
    • 초당 4KB 당 2회 읽기 = 1 RCU
  • 강력한 일관된 읽기
    
    • 초당 4KB당 1회 일기 = 1 RCU
  • 계산법 = (초당 읽기 횟수 / 모드에 따른 횟수) * (크기/4KB) (올림)

 

Throttling

• 핫 파티션
  
  • 특정 파티션 키에 요청이 몰리면 전체 용량이 남아있어도 Throttling 발생
• 해결법
  • 1. 지수 백오프 전략
  • 2. 파티션 키 분산
  • 3. DAX 이용

 

쿼리 vs Scan

• 쿼리 
  • 동일한 파티션 키 내에서 데이터를 검색
• scan
  • 테이블 전체를 읽어 데이터를 검색 
• API
  • ProjectionExpression
    → 필요한 속성만 골라서 가져온다 
  • FilterExpression
    → 데이터를 전체 읽고 사용자에게 보내기 전에 필터링 (RCU 그대로 소모)
    
  • Pagination
    →  쿼리와 스캔의 결과가 1MB 넘으면 페이지네이

 

Batch 작업 

• 최대 25개 항목 PutItem , Delete Item 가능 Update 불가능
• 최대 100개 읽기 작업 동시 시행 가능
• 오류
  • UnprocessedIten(쓰기) 또는 UnprocessedKeys(읽기) 반환
• 해결책
  • RCU/WCU 증설
  • 지수 백오프 사용

 

낙관적 잠금 & 조건부 쓰기

• 락을 거는 게 아니라 버전 비교를 통해 동시세 제어하는 방식
• 조건부 쓰기를 활용해 논리적으로 제어

 

DB 인덱스

• 로컬 보조 인덱스 (LSI)
  • 동일한 파티션 키 내 기존 정렬 키가 아닌 다른 정렬키로 정렬, 쿼리 하고 싶을 때 사용
  • 한번 테이블을 만들면 나중에 LSI 추가 불가능
• 글로벌 보조 인덱스 (GSI)
  • 기존의 PK가 아닌 다른 속성으로 테이블 전체에서 검색하고 싶을 때 
  • GSI Throttling 전파
    • GSI에 데이터를 쓸 때 WCU가 부족해 Throttling이 발생하면
      → 메인테이블의 쓰기 작업도 함께 중단
      → 메인테이블에 데러를 쓰면 GSI 에도 써야 하는데 GSI가 이를 감당하지 못해 발생하는 데이터 불일치를 막기 위함
      

 

DAX(DynamoDB Accelerator)

• 완전 관리형 DynamoDB 캐시 서비스 
• Hot Key 문제 해결 
• TTL
  • 기본 : 5분 유지
  • WCU 소비 안 함
  • TTL로 삭제되면 DB Stream에 기록

 

DynamoDB 스트림

• DynamoDB 테이블에서 발생하는 생성, 업데이트, 삭제 사항을 시간 순서대로 기록해 저장
• 최대 24시간 동안 보존
• 람다와 DB 스트림
  • 동작 순서
    • DynamoDB 테이블 변경 →스트림에 적재  → 람다(이벤트 소스 맵핑) 동작

 

CLI

• --page-size
  • 전체 데이터를 가져오는데 한 번에 몇 개씩 가져올 건지 (페이지 크기 조절)
  • 최종적으론 아이템 총량 변하지 않는다
• --max-items
  • 최종적으로 보여줄 아이템의 총 개수 제한 
  • 설정한 수만큼 보여주고 더 많은 데이터가 있으면 nextToken 반환
• --starting-token
  • NextToken 입력해 데이터를 멈췄던 지점부터 이어서 가져온다

 

DB Transactional

• Transaction은 2단계 커밋을 수행함으로 일반 작업 보다 2배의 용량을 소비
• WCU 계산 공식
  • (초당 아이템 수 ) * (아이템 크기/1KB)(올림) *2
• RCU 계산 공식
  • (초당 아이템 수 ) * (아이템 크기 / 4KB)(올림) * 2 

 

파티션 전략

• 핫 파티션 문제 
  • 몇 개의 파티션에 쿼리가 몰려서 Throttling 발생
• 해결법 
  • 파티션에 접미사를 추가해서 여러 파티션으로 분산시킨다
    • 예)
      • 기존 파티션 키 : 후보자 A → 여기에만 요청이 가서 과부하 걸림
      • 섀딩 된 키 : Candidate_A_1, Candidate_A_2,.... →  파티션 뒤에 랜덤 값 추가해 분산시킨다

 

동시성 제어

• 1. 낙관적 잠금 전략 사용
• 2. 원자적 쓰기 → UpdateItem API의 원자적 증감 기능 사용
• 3. BatchWriteItem

 

테이블 정리

• 개별 삭제 (Scan+DeleteItem) → 비추천
• 테이블 드롭 ( DropTable+RecreateTable) → 추천, 빠르고 저렴

 

AWS Data Pipeline

• DyanamoDB 데이터를 S3로 보내거나 다른 곳으로 복사할 때 사용하는 도구 

 

보안

• VPC 엔드포인트 
  →  인터넷을 거치지 않고 VPC 안에서 사용할 수 있는 엔드포인트 제공
• 암호화
  • 전송 중 암호화 제공 →  SSL/TLS
  • 데이터 암호화 제공 → KMS
• IAM Role

 

백업

• PITR  
  → 특정 시점으로 복구 가능
• 글로벌 테이블
  → 다중리전으로 복제 가능, DB Stream 활성화 필수 
• DMS
  → 타 DB(MongoDB,...)로 마이그레이션 서비스 제공

 

세밀한 제어

• 사용자가 자신의 데이터만 접근하도록 제한하는 기술
• dynamodb:LeadingKeys
  • 행 제어
  • 사용자 고유 id와 일치하는 행만 쓸 수 있음
• dynamodb:Attributes
  • 열 제어
  • 특정 민감한 칼럼은 못 보도록 제한