AWS DVA-C02 #26 멱등성 처리

#개발자의도구들 #AWS시험 #멱등성 #Idempotency

​

참고: ExamPotic Disscussion

문제 찾는법 : 여기 최하단

요구사항 분석

• 환경: IoT 디바이스 → REST API (AWS Lambda)
• 특징:

1. 각 API 요청에 고유 ID 부여
2. 트래픽이 랜덤 시점에 폭증 가능
3. Throttling 시 Retry 필요
4. 중복 요청이 발생해도 데이터 불일치나 손실 없이 처리 → Idempotent 동작 필요

• 핵심 과제:
• 중복 요청 여부를 빠르게 판별
• Lambda 성능에 영향을 최소화
• 고가용성/확장성

​

👉 Idempotency를 만족시키기 위한 중복 요청 처리 방법

보기 분석

A. RDS(MySQL) + 고유 ID 테이블 확인

​

❌ 오버헤드가 너무크다, 초당 수청 TPS 이상의 폭주 시 커넥션 풀 한계

​

B. DynamoDB + 고유 ID 테이블 확인

• DynamoDB 테이블에 고유 ID를 넣고 요청 처리전에 테이블을 체크한다.
• DynamoDB는 서버리스, 초당 요청 수 확장이 가능하다.
• Lambda에서 GetItem으로 ID 확인 후 처리

📌 client측에서 DynamoDB에 GetItem, PutItem 쿼리를 두 번 요청하는 방식임, 두 요청사이의 시간차가 존재하기 때문에 Race Condition이 가능하다.

​

❌ 매번 두 번의 I/O (조회 + 쓰기) : 오버헤드가 너무 심하다.

👉 조건부 쓰기가 필요함

​

C. DynamoDB + 고유 ID 저장 + 중복식 Client Error 반환

• 조건부 PutItem
• ID가 존재하면 Client Error를 반환

​

📌 Lambda가 DynamoDB에 한 번 요청 DynamoDB가 서버 내부에서 단일 트랜잭션으로 존재 확인 후 쓰는 것

​

✅ 최적

​

D. ElasticCache(Memchached) + ID 저장

⚠️ 내가 선택한 오답

​

❌ 속도는 빠르지만, 데이터 영속성이 ㅇ벗어서 기록 유실이 가능하다.

중복 요청이 몇 분 ~ 몇 시간 뒤에 올 수 있어서 캐시가 교체되면 멱등성 구현 어려움

개념 정리

Idempotency(멱등성)

• 같은 요청이 여러 번 와도 결과가 동일하게 유지되도록 하는 성질

• 구현 방법
• 고유 요청 ID 부여
• 서버가 해당 ID 처리 여부를 저장
• 동일 IP 재요청 시 새 처리 대신 이전 결과 반환 or 에러 반환

​