- 대기열 모델의 경우 - SQS
- pub/sub 모델의 경우 - SNS
- 실시간 스트리밍을 하고 대용량 데이터를 다루는 모델 - Kinesis
248. SQS - 메세지 가시성 시간 초과 (Message Visibility Timeout)
소비자가 메세지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됨 - 가시성 시간 시작
기본값으로 메세지 가시성 시간 초과는 30초
- 30초동안 이 메세지가 처리되어야 한다는 뜻
이 시간동안 동일한 혹은 다른 소비자가 메세지 요청 API 를 호출하면 메세지가 반환되지 않음
- 즉, 가시성 시간 초과 기간 내에서는 그 메세지는 다른 소비자들에게 보이지 않음
- 만약 가시성 시간이 초과되고, 메세지가 삭제되지 않았다면 메세지는 다시 대기열에 올라가고 , 다른 소비자가 ReceiceMessage API call 하면 이 메세지를 또 받게 됨
가기성 시간 초과 기간 내에 메세지를 처리하지 못하면 메세지가 두번 처리될 수 있음
ChangeMessageVisibility - 소비자가 메세지를 처리하는데 시간이 더 필요하다는 것을 알고있고, 해당 메세지를 두번 처리하고 싶지 않다면 이 api 를 호출해서 SQS 에 알려야 함
- 기본적인 시간을 늘리는 방법 - re-processing will take time
- 만약 시간이 너무 짧다면 - 소비자가 메세지를 여러번 읽게 됨 - 중복처리 될 수 있음
사용자는 메세지 처리 시간이 가시성 시간이 초과될 것 같다면 ChangeMessageVisibility api 를 호출하도록 프로그래밍 해야함
메시지: 처리량이 테이블 또는 인덱스의 현재 용량을 초과합니다. DynamoDB가 테이블 또는 인덱스를 자동으로 조정하므로 잠시 후 다시 시도합니다. 예외가 지속되면 파티션 키 설계 핫키가 있는지 확인합니다.
예: 갑작스러운 읽기 급증으로 테이블에 구성된 읽기 용량을 초과했습니다.
재시도 가능? 예
메시지: 테이블 또는 하나 이상의 글로벌 보조 인덱스에게 허용되는 최대 프로비저닝된 처리량을 초과하였습니다. 프로비저닝된 처리량과 소비한 처리량의 성능 지표를 보려면 Amazon CloudWatch 콘솔을 여세요.
예: 요청량이 너무 높습니다. DynamoDB용 AWS SDK가 이 예외를 수신하는 요청을 자동으로 재시도합니다. 재시도 대기열이 너무 많아 완료하지 못하는 경우를 제외하고 결국 요청이 성공합니다. 오류 재시도 횟수 및 지수 백오프를 사용하여 요청 빈도를 줄입니다.
재시도 가능? 예
DynamoDB - Throttling (조절)
파티션 수준에서 RCU 와 WCU 를 초과할 때 프로비저닝 처리량 초과 예외(ProvisionedThroughputExceededException)가 발생
예외 사유
Hot Keys - 하나의 파티션 키가 인기 있는 항목이여서 특정 파티션으로부터 너무 많이 읽혔을 때
Hot Partitions
너무 큰 항목 - WCU 와 RCU 가 계산될 때 항목에 크기에 따라 달라지기 때문
예외 해결
예외가 발생했을때 지수 백오프(Exponential backoff) 를 진행 (SDK 를 사용한다면 이미 포함된 사항임)
파티션 키를 최대한 많이 분산시켜야 함 (예방 차원)
만약 RCU issue 라면 DynamoDB Accelerator(DAX) 라는 기능을 사용
Kinesis - ProvisionedThroughputExceeded (프로비저닝 처리량 초과)
한 샤드에 전송되는 데이터량이 처리량을 초과할 때 예외가 발생함
Solution
- 매우 잘 분산된 파티션 키 사용 (use highly distributed partition key)
- 기하급수적인 백오프를 통해 재시도를 구현 (예외 상황을 재시도 할 수 있게 함)
- 샤드 스케일링(샤드 분할) - 샤드를 분할해서 처리량을 증가시킴
암호화할 파일이 4KB 이상일때 - 봉투 암호화
- 4KB 가 넘어가는 데이터는 봉투 암호화 기술을 사용해 암호화 되어야 함 = GenerateDataKey API
엔빌로프 암호화
데이터를 암호화하면 데이터가 보호되지만 암호화 키를 보호해야 합니다. 암호화하는 것도 하나의 전략입니다. 봉투 암호화는 데이터 키로 일반 텍스트 데이터를 암호화한 후, 다른 키 아래에서 데이터 키를 암호화하는 방법입니다.
데이터 암호화 키를 다른 암호화 키로 암호화하고 해당 암호화 키를 다른 암호화 키로 암호화할 수도 있습니다. 그러나 궁극적으로는 키와 데이터를 해독할 수 있도록 하나의 키는 일반 텍스트로 남겨둬야 합니다. 이러한 최상위 일반 텍스트 키 암호화 키를 루트 키라고 합니다.
AWS KMS는 암호화 키를 안전하게 저장 및 관리하여 보호할 수 있도록 도와줍니다. AWS KMS에 저장된 루트 키(즉, AWS KMS keys)는 AWS KMS FIPS 검증 하드웨어 보안 모듈을 암호화되지 않은 상태로 남겨두지 않습니다. KMS 키를 사용하려면 AWS KMS를 호출해야 합니다.
DynamoDB - Write Capacity Unit (WCU)
쓰기 용량 유닛(WCU) 는 '최대 1KB 항목에 대해 초당 1개의 쓰기'를 의미함
항목이 1KB 보다 클 경우 더 많은 WCU 를 사용하게 됨
예시)
초당 항목 10개를 쓰고 항목의 크기는 평균 2KB 이다. 이때 WCU 의 값은?
- 20 WCUs
초당 6개 항목을 쓰고 항목의 크기는 4.5KB 이다. 이때 WCU 의 값은?
- 30 WCUs
분당 120 개의 항목을 쓰고 항목의 크기는 2KB 이다. 이때 WCU 의 값은?
- 4 WCUs
DynamoDB - Read Capacity Units (RCU)
읽기 용량 유닛 - 크기가 최대 4KB 인 항목마다 초당 '강력한 일관된 읽기 1개' 또는 '최종적 읽기 2개' 를 의미함
만약 항목이 4KB 보다 크다면 더 많은 RCU 가 소비됨
예시)
초당 강력한 일관된 읽기 10개가 있고 항목 크기가 4KB 이다. 이때 RCU 값은?
- 10 RCUs
초당 최종적 일관된 읽기가 16개 이고, 항목 크기가 12KB 이다. 이때 RCU 값은?
- 24 RCUs
초당 강력한 일관된 읽기가 10개 이고, 항목의 크기가 6KB 이다. 이때 RCU 값은?
- 20 RCUs
329. DynamoDB 트랜잭션(Transactions)
트랜잭션을 사용하면 하나 이상 테이블의 여러 아이템에 양단간 작업을 할 수 있음
DynamoDB 에 ACID 기능 (Atomicity, Consistency, Isolation, Durability) (원자성, 일관성, 격리, 영속성) 제공
트랜잭션 읽기 모드
- 최종 일관성 (Eventual Consistency) - 전체적으로 일관된 읽기 기능
- 강력한 일관성 (Strong Consistency) - 모든 테이블에서 동시에 읽기 기능
- 트랜잭션 일관성 (Transactional) - 트랜잭션 상에서 일관된 읽기 기능
트랜잭션 쓰기 모드
- 표준 (Standard) - 전체 테이블에 걸쳐서 쓰기를 많이 하는 기능 , 일부는 실패할 수 있음
- 트랜잭션 (Transactional) - 전체 테이블에 걸쳐 모든 쓰기가 작동하거나 혹은 모두 작동하지 않음
WCU 와 RCU 를 2배로 소비함
- 각 아이템에 두개 작업을 하려면 백그라운드에서 트랜잭션을 준비하고 또 커밋해야 하기 때문
트랜잭션의 두가지 작업
TransactGetItems - 트랜잭션에서 하나 이상의 GetItem 작업을 하는 API 코드
TransactWriteItens - 하나 이상의 PutItem 및 UpdateItem 과 DeleteItem 을 작업함
트랜잭션을 폭 넓게 활용됨 - ACID 기능 전체에 걸쳐 사용됨
- 금융거래, 주문관리, 멀티플레잉 게임 등 일관성이 필요한 경우
Capacity Computations (용량 계산)
예시 1) 초당 세번의 트랜잭션 쓰기, 아이템 크기는 5KB 이다. 이때 WCU 값은?
- 30 WCUs
예시 2) 초당 다섯번의 트랜잭션 읽기, 아이템 크기는 5KB 이다. 이때 RCU 값은?
- 20 RCUs
- 아이템 하나를 처리하는데 2RCU 가 필요하고 5번 횟수 , 트랜잭션이니까 *2
325. DynamoDB 스트림
스트림은 테이블에서 발생하는 생성, 업데이트, 삭제와 같은 항목 수준 수정의 정렬된 목록
- 항목을 편집할때마다 수정 사항을 스트림에서 확인할 수 있음
- 스트림은 테이블의 전체 수정 사항 목록을 나타냄
스트림 데이터는 여러 곳으로 보내지게 됨
- KDS (Kinesis Data Streams)
- AWS Lambda
- KCL (Kinesis Client Library applications)
스트림의 데이터 보존 주기는 최대 24시간
- 보존성이 좋은 다른 스토리지에 저장하는 편이 좋음
use cases :
dynamoDB 테이블에서 발생하는 실시간 변경 사항에 대응할 때 (사용자에게 보내는 환영 메세지 등)
데이터 분석
스트림을 변경할 때
dynamoDB 에서 파생 테이블을 생성할 때
일래스틱서치에 데이터를 보낼 때 (인덱싱 + dynamoDB 에 검색기능 제공)
글로벌 테이블과 cross-resion replication 구현을 위해
'AWS > AWS Certified Developer Associate' 카테고리의 다른 글
AWS-DVA 온라인 시험 합격 후기 (0) | 2023.03.28 |
---|---|
덤프-6-오답노트 (0) | 2023.03.20 |
덤프-5-오답노트 (0) | 2023.03.19 |
덤프-4-오답노트 (0) | 2023.03.18 |
덤프-3-오답노트 (0) | 2023.03.18 |