메뉴

문서정보

목차

S3 Read-after-write consistency

S3는 99.99%의 가용성을 제공하며, 무한에 가까운 저장용량을 제공하는 특성을 가지고 있다. AWS의 100여개가 넘는 서비스 중에서도 가장 널리 사용되는 서비스일 것이다. S3는 데이터 백업 및 복원, 데이터 아카이빙, 웹 애플리케이션, 빅 데이터, 데이터 레이크, 데이터 분석 등 다양한 방식으로 사용하고 있다.

S3는 (2020년 12월)지금까지 "최종 일관성"이라는 일관성 모델을 제공했다. 굉장히 모호한 용어인데. PUT과 S3 API 함수를 호출을 하면, 요청이 완료(안정적으로 저장)되었지만 GET으로 리스트를 요청 할 경우 아직 표시되지 않을 수 있다. 약간의 지연 시간이 지난 후에는 결과적으로(최종적으로) 쓰기와 읽기 정보가 동기화 된다는게 "최종 일관성"이다. 최종 일관성은 BASE(Basically Available, Soft state, Eventual consistency) 시맨틱을 제공하는 것으로 분류되며 전통적인 ACID 보장과는 대조된다. 최종 일관성은 분산 시스템에서 발생하는데, 분산 시스템의 경우 데이터 변경사항을 전파하는데 시간이 걸리기 때문이다. 최종 일관성은 분산 응용 소프트웨어가 널리 사용되면서 비판을 받아왔다.

 404 NOT Found

쓰기 후 일관성은 데이터를 변경 한 직후 변경사항을 확인 할 수 있는지에 대한 것이다. 사용자 프로필을 수정했다고 가정해보자. 사용자가 프로필을 수정하고 업데이트 했다면, 이후에는 업데이트된 프로필을 읽어야만 한다. 여기에는 지연이 없어야 한다. 예를 들어 어떤 사용자는 업데이트된 내용을 읽고, 어떤 사용자는 이전 내용을 읽어서는 안될 것이다. 시간지연이 생긴다면 이를 read-after-write inconsistency 라고 한다.

일관성은 쓰기를 수행하는 사람에게만 적용된다. 왜냐하면 대규모의 시스템의 경우 약간의 지연이 불가피 하기 때문에, 다른 사람은 잠시 동안 업데이트된 내용을 보지 못할 수 있다. 하지만 원래 작성자는 업데이트 내용을 즉시 확인해야 한다.

쓰기 후 읽기 불일치(read-after-write inconsistency)가 발생하는 근본적인 이유는 분산 시스템하에서 "읽기와 쓰기"소스가 달라질 수 있기 때문이다. 데이터베이스가 하나만 있는 경우에는 문제가 없지만 분산시스템에서는 데이터베이스도 분산되고, "데이터가 전파되는데 시간이 걸리기 때문"이다.

S3 eventual consistency

AWS S3는 분산 객체 스토리지이기 때문에 쓰기 후 읽기 불일치 문제에서 자유로울 수 없다. 그래서 S3는 최종 일관성(eventual consistency)이라는 절충안을 제시했다. 최종 일관성의 아이디어는 아래와 같다.

Strong read-after-write consistency

이제 S3는 모든 S3 GET, PUT, LIST 작업은 물론이고 태그, ACL, 메타데이터에 대한 변경 작업에 대해서 강력한 일관성을 제공한다. 예전처럼 "객체 업데이트 후 어떤 사용자는 업데이트된 데이터를 읽고, 어떤 사용자는 이전 데이터를 읽는" 사건이 발생하지 않는다.

DynamoDB 와 같은 다른 서비스에서 제공했던 기능을 S3에서도 사용할 수 있게 됐다. 이는 당신이 쓰는 내용이 읽는 내용이 되며, 다른 사용자도 동일한 내용을 읽을 수 있다는 것을 의미한다. LIST 결과는 버킷의 내용을 정확히 반영한다. 이러한 일들이 추가적인 비용의 지불없이 이루어진다. S3와 같은 분산 스토리지에서 강력한 일관성을 제공하는 것이 어떻게 기술적으로 가능한지에 대한 일종의 놀라움에 가까운 기사들도 있었다. "성능에 영향을 미치지 않으면서 일관성과 시간지연을 모두 해결 할 수 있는가?"가 핵심일 것이다. 분산 시스템에서 전파에는 시간이 걸릴 수 밖에 없기 때문이다.

Strong read-after-writer consistency를 위한 방법

S3 같은 경우 대규모로 동일한 데이터의 복사본을 유지한다. 이렇게하면 복사본 중에 하나에 문제가 생겨도 계속 서비스를 할 수 있고 복원을 할 수 있기 때문이다. 복제본은 동기화 상태로 유지해야 할 ㅓㅅ이다.

어떤 사용자가 새로운 데이터를 쓰면, 복제본을 쓰는 작업이 발생 할 것이다. 이 경우 쓰기 후 불일치를 방지하려면 성능을 희생해야 한다.

 데이터베이스 복제본

데이터 복제가 동기적으로 발생한다. 즉 모든 데이터가 모든 복제본에 전파되기 전까지는 쓰기 작업이 완료되지 않은 것으로 간주된다. 이 방법은 간단하지만 쓰기 작업이 느려지고 복제본 중 하나가 실패할 경우의 이를 어떻게 처리할 것인지에 대한 문제가 남는다.

데이터 복제가 비동기적으로 이루어질 경우 즉 백그라운드에서 발생하는 경우 사용하는 일반적인 솔류션은 고정 라우팅이라고 하는 방식을 사용한다. 사용자가 접근하는 데이터베이스의 복제본을 고정하는 것이다. 아래는 고정 라우팅 방식을 묘사하고 있다.

 REplication

고정 라우팅은 일반적으로 지리적으로 분산된 데이터베이스에 저장된다. 사용자는 지리적으로 가까운 데이터베이스로 연결이 고정된다. 그리고 각 지역간 데이터베이스가 주기적으로 동기화 된다. 이러한 모델은 지리적으로 멀리있는 사용자끼리 데이터베이스에 접근 할 때, 불일치(업로드한 컨텐츠가 즉시 보이지 않는 등의)가 발생 할 수 있다.

참고