ReplicatedWriteConflictException

요약 — 다른 리전 의 요청이 같은 항목을 수정하는 동안 다중 리전 강력한 일관성(MRSC) 글로벌 테이블의 항목에 썼습니다. 강력한 다중 리전 일관성은 두 승자를 모두 착지시킬 수 없으므로 한 쓰기가 거부됩니다. AWS는 이를 재시도 가능으로 문서화합니다: 백오프 후 재시도하고, 가능한 곳에서 핫 항목의 리전 간 경합을 줄이세요.

무엇을 의미하나요

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

클래식(최종적 일관성) 글로벌 테이블은 모든 곳에서 동시 쓰기를 수락하고 나중에 last-writer-wins로 조정합니다. MRSC 글로벌 테이블은 반대 트레이드를 합니다: 쓰기는 확인되기 전에 리전 전반에서 조율되어야 하므로, 두 리전이 같은 순간에 같은 항목을 수정하는 것은 진짜 충돌입니다 — 그리고 한쪽이 조용한 덮어쓰기 대신 이 예외를 받습니다.

왜 발생하나요

같은 항목이 여러 리전에서 동시에 쓰임 — 두 애플리케이션 배포가 모두 항목을 자신이 업데이트할 것으로 취급합니다.
핫 조율 항목 — 카운터, 락, 또는 모든 리전이 건드리는 싱글톤 구성 항목은 자연스러운 충돌 자석입니다.
리전 간 재시도 폭풍 — 다른 리전에서 같은 논리적 작업의 동시 재시도가 계속 다시 충돌합니다.

어떻게 고치나요

지수 백오프와 지터로 재시도하세요 — 충돌은 순간적입니다. 다른 리전의 쓰기가 완료되면 재시도가 진행됩니다. AWS는 이 오류를 재시도 가능으로 표시합니다:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
항목에 홈 리전을 주세요 — 주어진 키의 쓰기를 한 리전을 통해 라우팅하고(사용자 거주지, 테넌트, 또는 파티션별) 다른 리전은 대부분 읽기로 유지하세요. 한 리전만 항목을 변경하면 경합이 사라집니다.
동시 업데이트를 가환적으로 만드세요 — 별도 속성에 대한 원자적 카운터 업데이트(ADD / SET x = x + :n)는 전체 항목에 대한 읽기-수정-쓰기 주기보다 덜 충돌합니다.
경합에서 진 후 의도를 재확인하세요 — 다른 리전이 항목을 변경했습니다. 조건부 재시도(버전 속성에 대한 ConditionExpression)는 쓰기가 새 상태에 대해 여전히 유효한지 보장합니다.

리전 전반에서 항목이 변하는 것을 지켜보는 것은 데이터가 눈앞에 있을 때 훨씬 쉽습니다 — DynoTable 데스크톱 앱은 각 복제본 리전에 연결하므로 항목을 나란히 비교할 수 있고, DynamoDB 요금 계산기는 복제 쓰기 비용을 추정합니다.

References

공식 AWS 문서(위 링크)를 기준으로 2026-07-13에 마지막으로 검증되었습니다.

ReplicatedWriteConflictException

무엇을 의미하나요

왜 발생하나요

어떻게 고치나요

관련 오류

References