애플리케이션이 저수준 BatchGetItem 작업을 사용하여 DynamoDB를 호출하고 UnprocessedKeys에 항목이 포함된 응답을 자주 수신합니다. UnprocessedKeys가 반환될 때 애플리케이션의 복원력을 높이려면 어떤 조치를 취해야 합니까? (두 가지 선택)

DynamoDB의 BatchGetItem 작업에서 UnprocessedKeys가 반환되는 것은 요청된 모든 항목을 한 번에 검색하지 못했음을 의미합니다. 이는 주로 프로비저닝된 처리량 용량 부족이나 일시적인 네트워크 문제 때문입니다. 1. 무작위 지연을 사용하여 지수 백오프 방식으로 배치 작업을 재시도합니다. UnprocessedKeys가 반환될 때 즉시 재시도하면 동일한 문제로 다시 실패할 가능성이 높습니다. 지수 백오프(exponential backoff)는 재시도 간의 대기 시간을 점진적으로 늘려 서버 과부하를 줄이고 성공적인 재시도 가능성을 높입니다. 무작위 지연(jitter)을 추가하면 모든 클라이언트가 동시에 재시도하여 또 다른 스파이크를 유발하는 것을 방지할 수 있습니다. 이는 일시적인 문제에 대한 표준 복원력 전략입니다. 2. 작업이 액세스하는 DynamoDB 테이블의 프로비저닝된 읽기 용량을 늘립니다. BatchGetItem은 읽기 작업이므로, UnprocessedKeys가 자주 반환된다는 것은 테이블의 프로비저닝된 읽기 용량 단위(RCU)가 현재 요청 부하를 처리하기에 부족하다는 강력한 신호입니다. 용량을 늘리면 DynamoDB가 더 많은 읽기 요청을 처리할 수 있게 되어 UnprocessedKeys가 반환될 가능성이 줄어듭니다. 오답 설명: 배치 작업을 즉시 재시도합니다. 이는 서버에 더 많은 부하를 주어 문제를 악화시키고, 다시 실패할 가능성이 높습니다. 요청을 수행하도록 AWS SDK를 사용하도록 애플리케이션을 수정합니다. AWS SDK는 이미 지수 백오프와 같은 재시도 로직을 내장하고 있지만, 이는 애플리케이션 수준의 복원력을 높이는 것이지 UnprocessedKeys 문제의 근본 원인(용량 부족)을 해결하지는 않습니다. 또한, SDK를 사용하더라도 UnprocessedKeys를 처리하는 로직은 여전히 필요합니다. 작업이 액세스하는 DynamoDB 테이블의 프로비저닝된 쓰기 용량을 늘립니다. BatchGetItem은