Dynamo DB 섹션 19. 216~218

• 데이터가 다중 AZ 간에 복제되므로 가용성이 높음.
• 관리형 서버리스 NoSQL 데이터베이스
• 밀리초 수준의 지연 시간
• SQL 쿼리 언어 사용 불가
• 예) 400KB 미만의 문서를 다루는 작은 서버리스 앱 개발, 서버리스 캐시 분산
• NoSQL, 트랜잭션 지원 기능
• 데이터베이스가 내부에서 분산되므로 방대한 워크로드로 확장 가능
• 초당 수백만 개 요청 처리, 수조 개의 행, 수백 TB의 스토리지를 갖음(Millions of requests per seconds, trillions of row, 100s of TB of storage)
• 읽기와 쓰기가 완전히 분리돼 있음
• 빠르고 일관성이 높음(성능 한자리수 밀리초)
• 보안, 권한 부여, 관리 기능은 IAM 과 통합되어 있음
• 적은 비용, 오토 스케일링
• 유지관리 패치 필요 없음
• 데이터베이스 프로비저닝 필요 없음
• 테이블 클래스는 두 종류
  • Standard : 액세스 빈번
  • IA : 액세스 빈번X
• 테이블로 구성되며 DB 생성필요X(오로라, RDS와 달리 DynamoDB는 이미 데이터베이스가 존재함)
• 각 테이블은 기본 키를 가짐(키는 생성 시 결정됨)
• 각 테이블에 데이터를 무한히 추가할 수 있음
• 각 항목은 속성을 가지며 속성은 나중에 추가 가능, null rksmd
• 항목의 최대 크기는 400KB -> 큰 객체 저장 적합X
• 지원하는 데이터 타입
  • Scalar Types – String, Number, Binary, Boolean, Null 
  •  Document Types – List, Map
  •  Set Types – String Set, Number Set, Binary Set

DynamoDB 로 스키마를 빠르게 전개할 수 있음

 

 

DynamoDB 예시

기본 키  : 파티션 키 + sort key (옵션)

 

read/write capacity modes

• 프로비저닝 모드(기본)
  • 초당 읽기/쓰기 요청 수를 예측해서 미리 지정 -> 테이블의 용량이 됨
  • 프로비저닝된 RCU, WCU 만큼의 비용 지불 방식
  • 오토스케일링 가능 - 테이블 로드에 따라 자동으로 RCU, WCU 늘리거나 줄이기 가능
  • 로드를 예측할 수 있고 비용 절감 원할 때 적합
  • 점진적으로 늘어나거나 줄어드는 이중 워크로드가 있을 때 유용
• 온디맨드 모드
  • 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장됨
  • 미리 용량 계획하지 않음(RCU, WCU 개념이 없음)
  • 정확시 사용한 만큼만 지불
  • 워크로드 예측할 수 없거나 급격히 증가하는 경우 유용
  • 예) 수천개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 경우
  • 예)트랜잭션이 없거나 하루에 많아야 4회밖에 되지 않는 워크로드

 

DynamoDB Accelerator(DAX)

• 고가용성 완전 관리형 무결절 인메모리 케시
• 읽기 작업이 많을 때 DAX 클러스터 생성하고 데이터 캐싱 읽기 혼잡 줄임
• 캐시 데이터에 마이크로초 수준의 지연 시간
• 캐시 TTL 기본 5분, 변경 가능
• DynamoDB 테이블과 애플리케이션이 있을 때 몇몇 캐시 노드가 연결된 DAX 클러스터를 생성하면 백그라운드에서 DAX 클러스터가 Amazon DynamoDB 테이블에 연결됨

 

DAX vs ElastiCache

• DAX
  • 읽기 지연 시간이 백만분의 1초
  • 개별 객체 캐시와 쿼리와 스캔캐시 처리시 유용
  • 대용량 연산 저장시 유용
  • DynamoDB 캐싱 솔루션 추가시 보통 DAX 사용
• ElastiCache
  • 집계 결과 저징시 유용

 

스트림 처리

• 생성, 업데이트, 삭제 스트림 생성 가능, 테이블 변경사항에 실시간으로 반응 가능
• ex) 새로운 사용자 등록시 환영 이메일, 실시간 사용 분석, 파생 테이블 삽입, 리전 간 복제, 변경 사항에 대해 람다 함수 실행
• 두 가지 스트림 처리 방식
• DynamoDB Stream
  • 보존기간 24시간
  • 소비자 수 제한
  • 람다 트리거,  DynamoDB Stream Kinesis adapter와 함께 사용하면 좋음,
• Kinesis Data Streams
  • 보존기간 1년
  • 더 많은 소비자 수
  • 데이터 처리방법이 훨씬 많음(lambda, kinesis data analytics, kinesis data firehose glue streaming ETL)

 

 

DynamoDB 스트림 처리 도식 예제

 

 

애플리케이션이 DynamoDB 테이블에서 작업을 생성, 업데이트, 삭제하면이는 DynamoDB 스트림이나 Kinesis Data Streams로 전송됩니다. Kinesis Data Streams을 선택하면 Kinesis Data Firehose를 사용할 수 있어요. 그런 다음 분석 목적으로 데이터를 Amazon Redshift로 전송하고 데이터를 아카이빙하려면 Amazon S3로 전송합니다.

Amazon OpenSearch로 보내면 인덱싱이나 검색을 할 수 있습니다. DynamoDB 스트림을 사용하면 처리 계층을 둘 수 있습니다. EC2 인스턴스에서 애플리케이션을 실행하려면 KCL Adapter나 Lambda 함수를 사용합니다

처리 계층에서 SNS로 알림을 보내거나 DynamoDB 테이블을 필터링하거나 변환할 수 있습니다 Amazon OpenSearch로 처리 계층의 데이터를 전송할 수도 있어요. Kinesis Data Streams에서 EC2 인스턴스로 읽거나 Kinesis Data Streams에서 Kinesis Data Analytics를 사용할 수도 있습니다.

 

 

Global Tables

• 여러 리전 간 복제가 가능한 테이블
• 양방향 복제 가능
• 복수의 리전에서 짧은 지연 시간으로 액세스 가능
• 다중 활성(active-active) 복제 가능 -> 앱이 모든 리전에서 테이블 읽고 쓰기 가능
• DynamoDB 스트림을 활성화해야 리전간 테이블 복제할 수 있는 인프라가 구축됨

 

DynamoDB의 TTL 기능

만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능

사용 예) 최근 항목만 저장, 2년 후 데이터 삭제해야 하는 규정, 웹 세션 핸들링

 

 

 

재해 복구

• 지정시간 복구 point-in-time recovery(PITR) 사용해 지속적인 백업 가능
  • Optionally enabled for the last 35 days
  • 활성화시 백업 기간 내 언제든 지정 시간 복구 실행 가능
  • The recovery process creates a new table

 

• 온디맨드 백업
  • 백업 보유 기간 35일보다 더 길게 가져갈 때 
  • 직접 삭제할 때까지 보존됨
  • DynamoDB의 성능이나 지연 시간에 영향을 주지 않음
  • The recovery process creates a new table

 

S3와 통합

• S3로 내보내기
  • 지정 시간 복구 기능 활성화 필요
  • 최근 35일 이내 어떤 시점으로든 테이블 내보내기 가능
  • 테이블 내보내도 읽기 용량, 성능에 영향 X
  • 데이터 분석 수행, 감사 목적으로 스냅샵 확보, 데이터 ETL등 대규모 변경 실행
  • 내보낼 때는 JSON,ION 형식 사용
• S3에서 테이블 가져오기
  • S3에서 csv, json, ion 형식으로 내보낸 후 새로운 DynamoDB 테이블 생성하는 방식
  • 쓰기용량 소비하지 않고 새로운 테이블 생성
  • 임포트시 발생한 오류는 모두 cloudWatch logs에 기록됨