[Re2020] S3가 더 넓은 범위의 Strong Consistency 모델을 제공합니다 (Feat. S3 업데이트 이모저모)
안녕하십니까. 오늘 포스팅에서는 리인벤트에서 발표된 S3와 관련된 업데이트를 한데 모아 살펴보려고 합니다. 아쉽게도 이번 글은 부득이하게 삽화나 캡쳐의 비중이 적고 대부분 글로 구성되어 있습니다. 따라서 이번 S3 업데이트에 관심이 있으신 분은 더욱 집중력을 갖고 글을 읽어 주셔야 합니다.
여러분도 아시다시피 S3는 AWS에서 정말 중요한 역할을 하는 서비스입니다. 굉장히 오래된 서비스이기도 하고, AWS의 타 서비스와 다양하게 연동되어 있기 때문에 뭔가 이슈가 생겼을때 영향도가 굉장히 큰 서비스이기도 합니다. 최근에는 단순 객체 저장소 역할뿐만 아니라 분석 시스템과 연계된 Data Lake로도 많이 활용되고 있구요. S3 Select나 Batch 등 폭넓은 부가기능을 지원하기도 합니다. 무엇보다도 S3는 “높은 내구성과 가용성을 갖춘 스토리지를 낮은 비용으로 제공” 한다는 컨셉의 서비스이기 때문에, 사용자는 아무 생각없이 잘 쓰면 되지만 이것을 실시간으로 관리하는 CSP 입장에서는 꽤나 메인터넌스가 까다로운 녀석이라는 생각도 듭니다. 예를 들어 사용자는 저장하는 객체를 무한정 업로드해도 상관이 없으나, CSP는 실제 저장되는 분산 스토리지를 미리 확충하고, 내부적으로 파티셔닝을 새로 하는 일련의 작업들을 지속적으로 수행해야 합니다.
S3는 이렇게나 중요한 서비스이기 때문에, 기본적인 동작 특성을 명확히 이해할 필요가 있습니다. 그 중 가장 대표적인 것으로 Eventually Consistency라는 개념이 있습니다. 최종 일관성을 제공한다는 뜻인데요. 이는 쉽게 말해 “특정 요청에 대한 응답의 일관성을 언젠가는 보장하나, 보장할때까지 일정 시간이 소요될수도 있다”라는 뜻입니다. 일례로, 같은 Key로 된 Object를 덮어쓰기(Overwrite)하고 나서, 빠른 시간에 GET 요청을 했을때 최종 일관성이 보장되기 전까지 예전 데이터를 반환할 수도 있다는 뜻입니다.
단, S3의 모든 Operation이 이 일관성 모델을 따르고 있는것은 아닙니다. 일부 작업은 Strongly Consistency(쓰기 후 읽기시 일관성을 즉시 보증하는 형태)를 따르고, 또 다른 일부는 Eventually Consistency 모델을 따릅니다. 이것을 사용자가 정확하게 알아야 하는 이유는 특정 어플리케이션에서 S3 데이터를 불러오는 로직에서 그것이 최신 데이터인지 아닌지가 매우 중요하기 때문입니다. 만일 요구사항에는 반드시 최신 데이터를 불러와야 하는데, S3에서 그것을 보장하지 않는다면? 갱신 히스토리를 따로 관리하거나 타임스탬프를 대조하는 등의 로직을 어플리케이션에서 추가로 고려해야 합니다.
이번 업데이트는 Strongly Consistency를 지원하는 Operation의 범위가 확대되었다는 내용입니다. 구체적으로 어떤 Operation이 이전에는 Eventually 모델이었다가, 이번에 Strongly 모델로 바뀌었는지를 파악하기가 좀 어려워서, AWS 공식 문서의 Git 페이지 히스토리를 들고 왔습니다. 업데이트 전인 2020년 11월 13일의 공식 문서 내용부터 보시죠.
내용을 보시면, 이전에도 신규 객체 쓰기(PUTS of new objects)의 경우에는 Strongly(read-after-write) Consistency 모델을 제공해왔음을 알 수 있습니다. 반면 객체 덮어쓰기(overwrite PUTS)와 객체 삭제(Delete)는 Eventual Consistency 모델을 제공해왔네요. 그럼 이어서 2020년 12월 18일에 업데이트 된 문서를 보겠습니다.
변경된 부분이 보이시나요? 이번 업데이트로 객체(Object) 기준 PUTS(신규 또는 덮어쓰기 모두)와 DELETE 작업 모두 Strongly Consistency 모델을 제공하기 시작했습니다. 즉, 기존에는 덮어쓰기 후 읽기(GET) 요청시 일정 시간동안 이전 데이터를 읽어올 가능성도 있었으나, 앞으로는 덮어쓰기된 최신 데이터를 반환하게 됩니다. 삭제(DELETE) 후 읽기(GET) 요청 또한 기존에는 삭제 후에도 삭제 전 데이터를 읽어올 가능성이 있었으나, 앞으로는 그럴 가능성이 없는 셈입니다. 이는 S3 객체의 메타 데이터를 수정하거나 ACL을 수정한 후에도 동일하게 적용되며, GET뿐만 아니라 LIST 작업에도 동일하게 적용됩니다. (단, Object 단위 Operation이 아닌 버킷 삭제와 같은 Bucket Operation의 경우 eventually consistency를 따릅니다) 기타 구체적인 예시는 2번째 보라색으로 박스친 부분을 비교해보시면 됩니다.
그렇다면 이런 변경사항이 적용되는 대상이 어떻게 될까요? 기존 버킷과 신규 버킷 모두 구분 없이 적용됩니다. 사용자가 별도로 무엇을 활성화할 필요도 없습니다. 모든 리전의 버킷에 즉시 적용됩니다. 만일 어플리케이션에서 즉시 일관성을 보장하기 위해 S3Guard와 같은 것을 사용중이었다면, 이제는 그런 추가 계층을 사용할 필요가 없어졌습니다. 실제 객체 단위의 갱신(overwrite) 또는 삭제(delete)가 잦은 성격의 데이터 풀을 S3 상에서 관리해 왔다면, 그리고 해당 S3 버킷에서 직접 최신 데이터를 Access해야 하는 요구사항이 있었다면 굉장히 환영할만한 업데이트라는 생각이 드네요.
이외에도 S3의 Replication 기능과 관련된 업데이트가 있습니다. 하나의 원본 버킷에서 복수의 대상 버킷으로 복제를 설정할 수 있게 되었습니다. 대상 버킷은 같은 리전이어도(Same Region Replication), 다른 리전이어도(Cross Region Replication) 상관이 없습니다. 예를 들어 글로벌 서비스 하는 게임의 패치 파일을 하나의 원본 버킷에 올려 놓으면 세계 각 지역의 Region에 위치한 S3 버킷에 개별적으로 자동 복제되도록 설정할 수 있습니다. (물론 서비스 관점에서 보면 앞에 CF와 같은 CDN을 붙이는 방법도 있습니다) 기타 S3와 관련된 업데이트 내역은 아래 링크를 참고하시기 바랍니다.
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-now-delivers-strong-read-after-write-consistency-automatically-for-all-applications/
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-replication-adds-support-two-way-replication/
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-replication-adds-support-for-multiple-destinations-in-the-same-or-different-aws-regions/
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-bucket-keys-reduce-the-costs-of-server-side-encryption-with-aws-key-management-service-sse-kms/
최신 댓글