DynamoDB로 스트리밍 데이터 다루기
AWS에서 애플리케이션 개발하기
Ricardo Sueiras
Principal Technologist
DynamoDB Streams 기본 개념
- 거의 실시간으로 데이터베이스 변경 사항에 반응합니다.
- 이벤트 기반 패턴을 기반으로 합니다.
- 삽입, 수정, 삭제가 발생할 때마다 스트림 레코드가 생성됩니다.
- 테이블을 폴링하지 않고도 반응형 앱을 구축할 수 있습니다.
- 기본적으로 비활성화되어 있으며
StreamSpecification으로 활성화합니다.
- 각 스트림은 테이블 ARN과는 별개로 고유한 ARN을 가집니다.
보존 기간
- 스트림 레코드는 24시간 동안 보존됩니다.
- 보존 기간은 고정되어 있으며 설정할 수 없습니다.
- 뷰 타입을 변경하려면 스트림을 다시 생성해야 합니다.
- 새 스트림은 새로운 스트림 ARN을 생성합니다.
스트림과 DynamoDB 읽기 용량 단위
- 스트림 읽기는 읽기 용량 단위(RCU)를 소비하지 않습니다.
- 스트림을 활성화해도 프로비저닝된 처리량에는 영향을 미치지 않습니다.
스트림 레코드
- 각 스트림 레코드는 변경 내용을 설명하는 메타데이터를 포함합니다.
- 스트림은 세 가지 이벤트 유형을 캡처합니다:
- 뷰 타입은 각 레코드에 담기는 데이터를 결정합니다.
KEYS_ONLY: 파티션 키와 정렬 키만 포함합니다.
NEW_IMAGE: 변경 후 전체 항목입니다.
OLD_IMAGE: 변경 전 전체 항목입니다.
NEW_AND_OLD_IMAGES: 변경 전후의 항목입니다.
NEW_AND_OLD_IMAGES는 감사(auditing) 용도로 가장 많이 사용됩니다.
- DynamoDB Global Tables에 필수입니다.
- 스트림은 파티션 키별로 순서를 보존합니다.
- Lambda는 레코드를 배치 단위로 처리합니다.
- 배치가 성공할 때마다 진행 상황을 체크포인트로 기록합니다.
- 실패한 배치는 재시도됩니다.
- 재시도는 성공하거나 레코드가 만료될 때까지 계속됩니다.
- Lambda는 가장 일반적인 스트림 소비자입니다.
- 폴링 기반의 이벤트 소스 매핑을 사용합니다.
- 스트림에서 레코드를 읽습니다.
- 레코드 배치로 함수를 호출합니다.
아키텍처 패턴
- 일반적인 엔드투엔드 패턴은 다음과 같습니다:
- 항목 업데이트가 DynamoDB에 반영됩니다.
- 변경 사항이 스트림 레코드를 생성합니다.
- 레코드가 Lambda를 트리거하여 처리합니다.
확장
- 스트림은 내부적으로 샤드로 나뉩니다.
- Kinesis Data Streams와 유사합니다.
- 각 샤드는 최대 두 개의 동시 소비자를 허용합니다.
- 이 한도를 초과하면 흔히 읽기 제한(throttling)이 발생합니다.
- Lambda 동시성은 샤드 수에 따라 확장됩니다.
- 다음 설정으로 처리를 조정할 수 있습니다:
BatchSize: 호출당 최대 레코드 수입니다.
MaximumBatchingWindow: 부분 배치 전 대기 시간입니다.
MaximumRetryAttempts: 실패 대상(failure destination)으로 보내기 전 재시도 횟수입니다.
MaximumRecordAgeInSeconds: 이 시간이 지난 레코드는 폐기합니다.
ParallelizationFactor: 샤드당 동시 처리 수입니다(최대 10).
필터링과 텀블링 윈도우
- Lambda는 필터 조건을 지원합니다.
- 함수가 호출되기 전에 레코드를 폐기합니다.
- 불필요한 호출과 비용을 줄입니다.
- Lambda는 텀블링 윈도우(tumbling window)를 지원합니다.
중복 레코드 관리
- 스트림은 각 변경 사항을 정확히 한 번만 캡처합니다.
- Lambda는 최소 한 번(at-least-once) 처리 방식으로 레코드를 처리합니다.
- 재시도 시 동일한 레코드가 다시 처리될 수 있습니다.
- 소비자를 멱등성(idempotent) 있게 설계하세요.
- 일반적인 패턴은 처리된
eventID 또는 SequenceNumber를 저장하는 것입니다.
- 이미 처리한 레코드는 건너뜁니다.
- 두 값 모두 재시도 전반에서 안정적으로 유지됩니다.
- 신뢰할 수 있는 멱등성 키입니다.
실패 처리
ReportBatchItemFailures는 실패한 레코드만 재시도합니다.
- 다음으로 Lambda 실패를 처리합니다:
- 배치 분할(bisection)을 위한
BisectBatchOnFunctionError입니다.
- 재시도 제어입니다.
- 재시도를 모두 소진한 문제 배치(poison batch)를 위한 실패 대상입니다.
DynamoDB와 Kinesis 통합
- 테이블은 변경 사항을 Kinesis Data Streams로 직접 전송할 수 있습니다.
- DynamoDB용 Kinesis Data Streams 기능을 통해 가능합니다.
- 연결된 기능이 아니라 별도의 병렬 기능입니다.
- 이벤트는 DynamoDB Streams를 거치지 않습니다.
- 두 기능 모두 같은 테이블에서 동시에 실행할 수 있습니다.
- 서로 독립적으로 작동합니다.
- 더 광범위한 스트리밍 및 분석 아키텍처에 활용됩니다.
모니터링: 일반적인 문제
- 주의해야 할 일반적인 운영 문제:
- 핫 파티션(hot partition)
- 실패한 재시도
- 중복 처리
- 제한(throttling)과 소비자 지연(lag)
모니터링: CloudWatch 지표
- 모니터링해야 할 주요 CloudWatch 지표:
- Lambda Errors: 코드 또는 다운스트림 문제를 드러냅니다.
- IteratorAge: 값이 높으면 느린 소비자를 나타냅니다.
- Throttling metrics: 읽기 한도 초과를 나타냅니다.
- Batch processing failures: 레코드가 DLQ로 전송됩니다.
보안
- 스트림 접근은 IAM 권한으로 제어됩니다.
- 스트림은 테이블의 암호화 설정을 상속합니다.
- KMS를 이용한 저장 데이터의 서버 측 암호화를 포함합니다.
- 소비자와 다운스트림 처리기에 최소 권한(least-privilege) 정책을 적용하세요.
연습해 봅시다!
AWS에서 애플리케이션 개발하기
Preparing Video For Download...