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

Traditional Architecture

전통적인 3계층 아키텍처

• 전통적인 3계층 아키텍처
• 클라이언트, Elastic Load Balancer, 애플리케이션 계층 (Auto Scaling 그룹의 EC2 인스턴스), 데이터베이스 계층 (Amazon RDS)로 구성되어 있다.

 

• 전통적인 애플리케이션은 RDBMS 데이터베이스와 SQL 쿼리 언어를 사용한다.
• RDBMS는 구조화된 데이터 모델링, 조인(join), 집계(aggregation), 복잡한 계산을 지원한다.
• 확장 유형
  • 수직적 확장: 더 높은 성능을 위해 CPU/RAM 업그레이드.
  • 수평적 확장: 애플리케이션 계층에 EC2 인스턴스를 추가하거나 데이터베이스 계층에 RDS 읽기 전용 복제본을 추가하여 읽기 용량 향상.
• 제한점: 읽기 용량은 수평 확장이 가능하지만, 쓰기 용량의 수평 확장은 어렵다.

 

NoSQL databases

• NoSQL 데이터베이스는 비관계형이며 분산되어 있다.
• 대표적인 NoSQL 데이터베이스로 MongoDB와 DynamoDB가 있다.
• NoSQL 데이터베이스는 조인(join)을 지원하지 않거나 제한적으로 지원한다.
• 모든 필요한 데이터가 한 행에 포함되어야 한다.
• 집계 연산(SUM, AVG 등)을 지원하지 않는다.
• 수평적 확장: 읽기/쓰기 용량이 필요할 때 인스턴스를 추가하여 확장 가능하다.
• NoSQL과 SQL 중 옳고 그름은 없으며, 데이터 모델링과 사용자 쿼리에 따라 선택이 달라진다.

 

Amazon DynamoDB

• 완전 관리형 고가용성 NoSQL 데이터베이스로, 여러 가용 영역(AZ)에 걸쳐 복제가 이루어잔다.
• 관계형이 아닌 분산형 데이터베이스로 대규모 워크로드로 확장 가능하다.
• 초당 수백만 개의 요청, 수조 개의 행, 수백 테라바이트의 스토리지를 처리할 수 있다.
• 빠르고 일관된 성능(검색 시 낮은 지연 시간).
• IAM 통합으로 보안 및 권한 관리 가능하다.
• DynamoDB Streams를 통해 이벤트 기반 프로그래밍 가능하다.
• 비용 효율적이며 오토 스케일링 기능이 포함되어 있다.
• Standard 및 Infrequent Access(IA) 테이블 클래스를 지원한다.

 

DynamoDB 기초

• DynamoDB는 테이블로 구성되어 있으며 각 테이블에는 기본 키(Primary Key)가 필요하다.
• 각 테이블은 무한한 항목(= 행)을 가질 수 있으며 각 항목에는 속성이 포함될 수 있다.
• 항목 크기의 최대값은 400KB이다.
• 지원되는 데이터 유형
  • 스칼라 유형: 문자열(String), 숫자(Number), 이진(Binary), 불리언(Boolean), null.
  • 문서 유형: 리스트(List), 맵(Map).
  • 집합 유형: 문자열 집합(String Set), 숫자 집합(Number Set), 이진 집합(Binary Set).

 

DynamoDB 기본 키 (옵션 1: 파티션 키)

사용자 테이블 예제, 파티션 키로 User_ID를 사용하고 속성으로 First_Name, Last_Name, Age가 있다.

• 파티션 키(Partition Key)는 각 항목마다 고유해야 한다.
• 파티션 키는 데이터가 분산될 수 있을 만큼 다양해야 한다.
• 예: 사용자 테이블에서 사용자 ID를 파티션 키로 사용하여 데이터를 분산한다.

 

 DynamoDB 기본 키 (옵션 2: 파티션 키 + 정렬 키)

사용자-게임 테이블 예제, 파티션 키로  User_ID 를, 정렬 키로  Game_ID 를 사용하여 데이터가 그룹화된다.

• 파티션 키와 정렬 키의 조합이 각 항목에서 고유해야 한다.
• 데이터는 파티션 키에 의해 그룹화되고, 정렬 키에 의해 순서가 지정된다.
• 예: 사용자-게임 테이블에서 사용자 ID는 파티션 키, 게임 ID는 정렬 키로 설정하여 게임별 데이터를 관리한다.

 

 DynamoDB – 파티션 키 선택 (연습)

• 영화 데이터베이스를 구축할 때, 데이터를 최대한 분산하기 위한 최적의 파티션 키를 선택해야 한다

<후보>

• movie_id
• producer_name
• leader_actor_name
• movie_language

 

• movie_id가 가장 높은 카디널리티를 가지므로 최적의 후보이다.
• movie_language는 값의 다양성이 낮고 특정 언어(예: 영어)에 치우칠 가능성이 있어 파티션 키로 적합하지 않다.

최적의 파티션 키 선택을 위해 데이터의 카디널리티가 높은 것을 선택하는 것이 중요하다.

 

 

DynamoDB - 읽기/쓰기 용량 모드

• DynamoDB의 용량 모드는 Provisioned Mode(기본 모드)와 On-Demand Mode 두 가지가 있다.
  • Provisioned Mode
    • 초당 읽기/쓰기 횟수를 미리 설정하여 용량을 계획해야 한다.
    • 설정된 용량에 따라 비용이 청구된다.
  • On-Demand Mode
    • 워크로드에 따라 자동으로 읽기/쓰기 용량이 조절된다.
    • 사용한 만큼 비용을 지불하나, Provisioned Mode보다 비싸다.
  • 변경 주기: 두 모드는 24시간마다 변경할 수 있다.

 

R/W 용량 모드 - Provisioned

• 테이블은 미리 프로비저닝된 읽기/쓰기 용량 유닛이 필요하다.
• RCU(Read Capacity Units)
  • 읽기 처리량, WCU(Write Capacity Units): 쓰기 처리량을 의미한다.
• 버스트 용량을 통해 일시적으로 처리량을 초과할 수 있지만, 이를 소진하면 ProvisionedThroughputExceededException 예외가 발생한다.
• 예외가 발생하면 지수 백오프(exponential backoff) 방식으로 재시도하는 것이 좋다.

 

쓰기 용량 유닛 (WCU)

• 1 WCU는 1KB 크기의 항목에 대해 초당 1회 쓰기를 의미한다.
• 항목 크기가 1KB를 넘으면 더 많은 WCU가 필요하다.

 

• 예시 1: 10개의 2KB 항목을 초당 쓰려면 20 WCU 필요. 

• 예시 2: 6개의 4.5KB 항목을 초당 쓰려면 30 WCU 필요 (항상 올림하여 계산).

• 예시 3: 분당 120개의 2KB 항목을 쓰려면 4 WCU 필요.

 

Strongly Consistent Read vs. Eventually Consistent Read 

DynamoDB의 내부 구조 Application 이 Amazon DynamoDB의 여러 서버에 데이터를 읽고 쓰는 상황.

• 최종적 일관성 읽기 (기본값): 쓰기 직후 읽을 경우 최신 데이터가 아닐 수 있음.
• 강력한 일관성 읽기: 쓰기 직후 최신 데이터를 얻음. 그러나 RCU를 2배로 사용하여 비용이 더 큼.
• API 호출에서 ConsistentRead를 true로 설정하여 강력한 일관성 읽기를 사용할 수 있다.

 

읽기 용량 유닛 (RCU)

• 1 RCU는 크기 4KB 이하의 항목에 대해 초당 1회의 강력한 일관성 읽기 또는 초당 2회의 최종적 일관성 읽기를 의미한다.

 

• 예시 1: 4KB 항목을 초당 10회 강력한 일관성으로 읽으려면 10 RCU 필요.

 

• 예시 2: 12KB 항목을 초당 16회 최종적 일관성으로 읽으려면 24 RCU 필요.

• 예시 3: 6KB 항목을 초당 10회 강력한 일관성으로 읽으려면 20 RCU 필요 (항상 올림하여 계산).

 

 

DynamoDB 파티션 내부 구조

Application 이 해시 함수를 통해 특정 파티션으로 데이터를 분산하여 DynamoDB에 쓰는 과정

• 데이터는 파티션에 저장되며 파티션 키가 해싱 알고리즘을 통해 특정 파티션에 할당된다.
• 파티션 수는 RCU, WCU, 데이터 크기에 따라 결정되며, 모든 파티션에 WCU와 RCU가 고르게 분배된다.

 

 DynamoDB - 스로틀링 (Throttling)

• RCU 또는 WCU가 초과되면 ProvisionedThroughputExceededException 예외가 발생한다.
• 주요 원인
  • 핫 키: 특정 파티션 키에 집중된 요청.
  • 핫 파티션: 특정 파티션에 과도한 요청.
  • 큰 항목: 항목 크기에 따른 높은 RCU/WCU 소비.
• 해결 방법
  • 지수 백오프를 통해 예외 발생 시 재시도한다.
  • 파티션 키 분산을 최대화한다.
  • DynamoDB Accelerator(DAX) 을 사용한다.

 

R/W 용량 모드 - On-Demand

• 읽기/쓰기가 자동으로 스케일링되며, 사전 용량 계획이 필요하지 않다.
• RRU (Read Request Units)와 WRU (Write Request Units) 단위로 비용 청구된다.
• Provisioned Mode보다 약 2.5배 더 비싸며, 예측할 수 없는 트래픽에 유용하다.

 

DynamoDB - 데이터 쓰기 (Writing Data):

• PutItem
  • 새 항목을 생성하거나 기존 항목을 완전히 대체한다.
  • 동일한 기본 키(Primary Key)를 가진 항목을 완전히 덮어쓴다.
  • 쓰기 용량 유닛(WCU)을 소비한다.
• UpdateItem
  • 기존 항목의 일부 속성을 편집하거나 항목이 없을 경우 새로 추가한다.
  • 원자적 카운터(Atomic Counter)를 구현할 때 유용하다.
  • 원자적 카운터는 조건 없이 숫자를 증가시키는 속성
• Conditional Writes
  • 조건이 충족될 때만 쓰기, 업데이트, 삭제를 허용한다.
  • 동시 접근 문제 해결에 도움을 주며 성능에 영향이 없다.

 

DynamoDB - 데이터 읽기 (GetItem)

• GetItem
  • 기본 키에 따라 데이터를 읽는다. 기본 키는 HASH 또는 HASH+RANGE일 수 있다.
  • 기본적으로 최종적 일관성 읽기를 사용하지만, 더 최신 데이터를 원할 경우 강력한 일관성 읽기 옵션을 선택할 수 있다. (단, RCU가 더 많이 소비되고 속도가 느려질 수 있음)
  • ProjectionExpression을 통해 특정 속성만 선택적으로 가져올 수 있다.

 

DynamoDB - 데이터 읽기 (Query)

• Query
  •  KeyConditionExpression을 통해 항목을 조회한다.
  • 파티션 키 값은 필수로 지정해야 하고, 정렬 키는 선택적으로 사용할 수 있습니다.
• FilterExpression
  • Query 후 데이터를 반환하기 전에 필터링을 추가할 수 있으며, 비키 속성에만 사용된다.
• 제한 사항
  • Limit 파라미터를 사용하여 반환되는 항목 수를 제한하거나 최대 1MB의 데이터를 반환한다. 여러 페이지로 데이터를 받아오는 페이징 처리가 가능하다.
• 로컬 보조 인덱스, 글로벌 보조 인덱스와 함께 테이블 쿼리가 가능하다.

 

DynamoDB - 데이터 읽기 (Scan)

• Scan: 테이블 전체를 읽고 데이터를 필터링한다. 비효율적이며 RCU를 많이 소모한다.
• 최대 1MB의 데이터를 반환하고, 계속해서 읽으려면 페이지네이션이 필요하다.
• Parallel Scan: 여러 작업자가 동시에 여러 데이터 세그먼트를 스캔하여 성능을 높일 수 있다.
• ProjectionExpression과 FilterExpression을 사용해 특정 속성만 가져오거나 클라이언트 측에서 필터링할 수 있다.

 

DynamoDB - 데이터 삭제 (DeleteItem 및 DeleteTable)

• DeleteItem: 개별 항목을 삭제. 조건부 삭제도 가능하다.
• DeleteTable: 테이블 전체를 삭제하여 모든 항목을 제거한다. 개별 항목을 하나씩 삭제하는 것보다 훨씬 빠르다.

 

DynamoDB - 일괄 작업 (Batch Operations)

• 일괄 작업을 통해 API 호출 수를 줄이고 효율성을 높일 수 있다.
• BatchWriteItem
  • 한 번의 호출로 최대 25개의 PutItem 또는 DeleteItem 작업을 수행한다.
  • 실패한 항목은 UnprocessedItems로 반환되어 지수 백오프를 통해 다시 시도할 수 있다.
• BatchGetItem
  • 한 번의 호출로 여러 테이블에서 최대 100개의 항목을 병렬로 가져온다.
  • 실패한 항목은 UnprocessedKeys로 반환된다.

 

DynamoDB - PartiQL

• PartiQL: SQL 호환 쿼리 언어로, SQL 구문을 사용하여 DynamoDB 데이터를 조회, 삽입, 업데이트, 삭제할 수 있다.

SELECT OrderID, Total
FROM Orders
WHERE OrderID IN [1,2,3]
ORDER BY OrderID DESC

• 여러 테이블에서 쿼리를 실행할 수 있지만, 조인은 지원하지 않는다.
• AWS Management Console, NoSQL Workbench, DynamoDB API, CLI, SDK에서 PartiQL을 실행할 수 있다.

 

DynamoDB - 조건부 쓰기 (Conditional Writes)

• 조건부 쓰기는 PutItem, UpdateItem, DeleteItem, BatchWriteItem에 적용된다.
• 특정 조건 표현식을 사용하여 수정할 항목을 결정할 수 있다.
• 사용 가능한 조건 표현식
  • attribute_exists / attribute_not_exists: 속성이 존재하거나 존재하지 않는지 확인.
  • attribute_type: 속성의 데이터 유형 확인.
  • contains, begins_with: 문자열 조건 비교.
  • IN, between: 특정 값 포함 여부 및 범위 비교.
  • size: 문자열 길이 확인.
• 주의: 필터 표현식은 읽기 쿼리 결과를 필터링하고, 조건 표현식은 쓰기 작업에서만 사용된댜ㅏ.

 

조건부 쓰기 - UpdateItem 예제

UpdateItem을 사용하여 조건에 맞는 경우에만 항목을 업데이트하는 예제.

• aws dynamodb update-item 명령을 사용하여 ProductCatalog 테이블의 항목을 업데이트한다.
• 조건 표현식을 통해 Price가 특정 값보다 클 때만 업데이트하도록 설정한다.
• values.json 파일에서 discount와 limit 값을 설정하여 조건에 맞으면 Price가 할인가로 조정된다.
• 예: 항목의 현재 가격이 650이고, 한계값(500)을 초과하므로 Price는 할인이 적용된 500으로 업데이트된다

 

조건부 쓰기 - DeleteItem 예제

• attribute_not_exists: 속성이 존재하지 않는 경우에만 삭제가 성공한다.

예: Price 속성이 없을 때 항목을 삭제.

• attribute_exists: 속성이 존재하는 경우에만 삭제가 성공한다.

예: ProductReviews.OneStar 속성이 있는 경우에만 삭제를 진행. 이 방법으로 특정 조건을 만족하는 항목만 삭제할 수 있다.

 

 

조건부 쓰기 - 덮어쓰기 방지

• attribute_not_exists(partition_key): 항목이 이미 존재할 경우 덮어쓰지 않도록 설정.
• attribute_not_exists(partition_key)와 attribute_not_exists(sort_key): 파티션 키와 정렬 키 조합이 이미 존재하는 경우 덮어쓰지 않도록 설정.
• 기존 데이터를 실수로 덮어쓰지 않도록 조건부 쓰기를 통해 안전하게 관리할 수 있다.

 

조건부 쓰기 - 복잡한 조건 예제

DeleteItem 명령을 사용하여 복잡한 조건을 설정 예: ProductCategory가 Sporting Goods에 속하지만 Price가 500과 600 사이가 아니면 조건이 충족되지 않아 삭제되지 않는다.

• ProductCategory가 특정 카테고리에 속하며 Price가 지정된 범위 안에 있을 때만 항목을 삭제한다.
• values.json 파일에서 cat1, cat2, lo, hi 값을 설정하여 조건을 구성한다.

 

조건부 쓰기 - 문자열 비교 예제

DeleteItem을 사용하여 문자열이 특정 값으로 시작하는지 확인

• begins_with: 문자열이 특정 접두사로 시작하는지 확인한다.
  • 예: URL이 "http://"로 시작하면 삭제한다.
• contains: 문자열에 특정 값이 포함되어 있는지 확인한다.
• values.json 파일에서 조건을 설정하여, 조건에 따라 불필요한 데이터가 삭제된다.

 

 

DynamoDB - 로컬 보조 인덱스 (LSI)

• LSI(Local Secondary Index)는 테이블의 기존 파티션 키와 동일한 파티션 키를 사용하면서, 대체 정렬 키를 추가로 제공한다.
• 정렬 키는 하나의 스칼라 속성(문자열, 숫자, 또는 바이너리)으로 구성된다.
• 각 테이블은 최대 5개의 LSI를 가질 수 있으며, 반드시 테이블 생성 시점에 정의해야 한다.
• 속성 프로젝션(Projection)은 일부 또는 전체 속성을 포함하도록 선택 가능하다 (KEYS_ONLY, INCLUDE, ALL).

• User_ID와 Game_ID로 쿼리할 수 있지만, Game_TS를 기반으로 쿼리하려면 LSI가 필요하다.
• 여기서 Game_TS를 정렬 키로 추가하여, 특정 기간 동안의 사용자의 게임 기록을 쿼리할 수 있다.

 

DynamoDB - 글로벌 보조 인덱스 (GSI)

• GSI(Global Secondary Index)는 기본 테이블과 다른 파티션 키와 정렬 키를 가질 수 있어, 비키 속성(non-key attributes)의 쿼리 속도를 높인다.
• 인덱스는 스칼라 속성(문자열, 숫자, 또는 바이너리)으로 구성되며, 속성 프로젝션을 통해 일부 또는 전체 속성을 선택할 수 있다.
• 테이블 생성 후에도 GSI는 추가/수정이 가능하다는 점이 큰 장점이다.
• GSI는 별도의 읽기/쓰기 용량 단위(RCU/WCU)를 할당해야 한다.

• Game_ID를 파티션 키, Game_TS를 정렬 키로 하는 GSI를 생성하여 Game_ID를 기준으로 쿼리할 수 있다.
• 이를 통해 User_ID를 파티션 키로 사용하는 기존 테이블과는 다른 쿼리가 가능해진다.

 

DynamoDB - 인덱스와 스로틀링 (Throttling)

• GSI
  • GSI에서 쓰기 작업이 스로틀링될 경우, 메인 테이블도 영향을 받아 스로틀링될 수 있다.
  • GSI의 파티션 키를 신중하게 선택하고, WCU 용량을 충분히 할당해야 한다.
• LSI
  • 메인 테이블의 WCU와 RCU를 사용하므로, 별도의 스로틀링 고려가 필요하지 않다.

 

DynamoDB - PartiQL

• PartiQL은 SQL과 유사한 구문을 사용하여 DynamoDB 테이블을 조작할 수 있는 기능이다.
• 이로써 SQL에 익숙한 사용자가 DynamoDB에서도 쉽게 작업할 수 있다.
• PartiQL은 일부 SQL 명령문을 지원한다:
  • INSERT: 새 항목을 테이블에 삽입
  • UPDATE: 기존 항목의 데이터를 수정
  • SELECT: 특정 조건에 맞는 항목을 조회
  • DELETE: 항목을 삭제
• 배치 작업도 지원하여 여러 작업을 동시에 처리할 수 있다.

• 예시 쿼리에서 SELECT * FROM "demo_indexes" WHERE "user_id" = 'partitionKeyValue' AND "game_ts" = 'sortKeyValue'와 같이 SQL 구문으로 DynamoDB 테이블에서 데이터를 조회할 수 있다.

PartiQL은 SQL 형식을 제공하여 DynamoDB 작업의 접근성을 높이고, SQL에 익숙한 사람들이 쉽게 DynamoDB에 적응할 수 있게 한다. 배치 연산 지원으로 효율성 또한 높일 수 있다.

 

DynamoDB - Optimistic Locking (낙관적 잠금)

• DynamoDB에는 조건부 쓰기(Conditional Writes) 기능이 있다.
• 이는 데이터가 수정되기 전에 변경되지 않았는지 확인하는 전략으로, 낙관적 잠금 방식이다.
• 각 항목에는 버전 번호 역할을 하는 속성이 있다.
  • 업데이트나 삭제 작업 시 이 버전 번호가 일치하는지 확인해, 충돌이 발생하지 않도록 한다.

 

클라이언트 1과 클라이언트 2가 동시에 First_Name을 업데이트하려는 상황 클라이언트 2가 먼저 업데이트하여 Version이 2로 변경되고, 이후 클라이언트 1의 요청은 Version 조건이 맞지 않아 실패

• DynamoDB 테이블에는 User_ID, First_Name, Version 속성이 있다. 현재 Version이 1인 상태이다.
• 두 클라이언트가 동시에 First_Name을 업데이트하려고 시도한다.
  • Client 1: Version이 1일 때만 Name = John으로 업데이트를 시도.
  • Client  2: Version이 1일 때만 Name = Lisa로 업데이트를 시도.

• 클라이언트 2의 요청이 먼저 처리되어, First_Name이 Lisa로 변경되고 Version이 2로 업데이트된다.
• 이후 클라이언트 1의 요청이 들어오지만, Version이 1이 아니라 2이기 때문에 DynamoDB는 업데이트를 거부하고 오류를 반환한다.
• 이로 인해 클라이언트 1은 최신 데이터를 다시 가져와야 한다.

낙관적 잠금은 DynamoDB에서 데이터 충돌을 방지하는 중요한 기능이다.
조건부 쓰기를 통해 데이터를 안전하게 업데이트할 수 있으며, 데이터가 동시에 변경될 위험이 있는 상황에서 유용하다.

 

DynamoDB - DAX (DynamoDB Accelerator)

DAX는 DynamoDB를 위한 완전 관리형 인메모리 캐시이다.
주로 자주 호출되는 데이터를 캐싱하여 캐시된 읽기와 쿼리에 대한 지연을 마이크로초로 줄여준다.
애플리케이션 로직을 변경할 필요 없이 기존의 DynamoDB API와 호환되어 쉽게 사용할 수 있다.

• 핫 키 문제 해결: 특정 항목이 너무 자주 읽혀서 발생하는 스로틀 문제를 DAX를 통해 해결할 수 있다.
• 기본 TTL: 캐시의 기본 TTL은 5분이며, 이 시간 동안 데이터가 유지된다.
• 클러스터 구성: 최대 10개의 노드로 구성할 수 있으며, 프로덕션 환경에서는 다중 AZ 설정으로 최소 3개의 노드를 권장한다.
• 보안: DAX는 미사용 시 암호화되고, KMS, VPC, IAM, CloudTrail과 통합하여 보안을 강화할 수 있다.

• DAX 클러스터와 애플리케이션이 연결된 다이어그램
• DAX가 DynamoDB와 애플리케이션 사이에서 캐시 역할을 한다.

 

 

DynamoDB Accelerator (DAX) vs. ElastiCache

 

DAX와 ElastiCache의 차이점을 알아두는 것이 중요하다. (시험에서도 자주 나옴)

 

DAX는 DynamoDB의 쿼리와 스캔에 대한 캐시로 사용되고, ElastiCache는 집계된 결과를 저장하는 데 활용되는 구조를 보여주는 다이어그램

• DAX
  • 개별 객체, 쿼리, 스캔 등의 캐시에 최적화되어 있으며, DynamoDB와의 통합에 특화되어 있다.
• ElastiCache
  • 더 복잡한 집계 결과나 계산 비용이 큰 데이터를 저장하고 빠르게 검색할 수 있도록 도와준다.
  • 애플리케이션에서 연산된 결과를 ElastiCache에 저장해두고 이후 필요한 경우 ElastiCache에서 직접 불러올 수 있다.

 

DynamoDB Streams 개요

• DynamoDB Streams는 테이블에서 발생하는 생성, 업데이트, 삭제와 같은 항목 수준 수정 사항을 실시간으로 스트림에 기록한다. 이를 통해 항목의 변경 사항을 순차적으로 확인할 수 있다.

 

스트림 레코드의 흐름

• DynamoDB Streams는 테이블에서 발생하는 항목 수준의 수정 사항(생성, 업데이트, 삭제)을 순차적으로 스트림에 기록한다.
• 스트림 레코드는 Kinesis Data Streams, AWS Lambda, Kinesis Client Library 애플리케이션에서 읽을 수 있다.
• 데이터 보존 기간은 최대 24시간이다.
• 주요 사용 사례
  • 실시간 변화에 반응 (예: 사용자 환영 이메일 전송)
  • 데이터 분석
  • 파생 테이블 생성
  • OpenSearch Service에 데이터 삽입으로 검색 기능 추가
  • 크로스 리전 복제 구현

 

DynamoDB Streams 아키텍처

• 애플리케이션이 테이블에서 항목을 생성/업데이트/삭제하면, 이 변경 사항이 DynamoDB Streams로 기록된다
• 이후 Kinesis Data Streams와 통합하여 다양한 AWS 서비스로 데이터를 전달한다.

 

• DynamoDB Streams는 다양한 AWS 서비스와 통합하여 활용할 수 있다.
  • Kinesis Data Streams와 연계해 Kinesis Data Firehose를 사용하여 Amazon Redshift나 Amazon S3로 전송할 수 있다. 이를 통해 데이터 분석 및 장기 보관이 가능하다.
  • Amazon SNS를 통한 메시징과 알림 기능도 구현 가능하다.
  • Lambda 또는 KCL 애플리케이션을 사용하여 데이터 필터링, 변환 등 맞춤형 로직을 추가할 수 있다.
  • OpenSearch Service에 데이터를 전송하여 DynamoDB 테이블에 검색 기능을 더할 수 있다.

 

스트림 정보 선택

• 스트림에 기록할 정보를 선택 가능
  • KEYS_ONLY: 수정된 항목의 키 속성만 표시
  • NEW_IMAGE: 수정 후의 전체 항목을 표시
  • OLD_IMAGE: 수정 전의 전체 항목을 표시
  • NEW_AND_OLD_IMAGES: 수정 전후의 전체 항목을 모두 표시해 변경 사항을 확인 가능
• 샤드 구성: DynamoDB Streams는 샤드로 구성되며 AWS가 자동 관리하므로 사용자가 별도 프로비저닝할 필요가 없다.
• 주의사항: 스트림 활성화 이후에는 기존 데이터가 소급 적용되지 않으며, 활성화 후의 변경 사항만 기록된다.

 

 

DynamoDB Streams와 AWS Lambda 통합

• DynamoDB Streams에서 데이터를 읽기 위해서는 Event Source Mapping이 필요하다.
• Lambda 함수에는 DynamoDB Streams에서 데이터를 폴링할 적절한 권한이 있어야 한다.
• Lambda 함수는 동기적으로 호출되며, DynamoDB Streams의 레코드를 배치로 받아 처리한다.

• Lambda 함수가 DynamoDB Streams의 이벤트를 처리하는 구조를 보여준다.
• 이벤트 소스 매핑을 통해 스트림의 레코드가 배치로 Lambda 함수에 전달된다.