Simple Storage Service(S3)

최수환·2022년 9월 13일
0

AWS-SAA

목록 보기
7/23
post-thumbnail

지난 포스팅에서 세가지 형태의 스토리지중 블록 스토리지에 대해서 알아보았다.
이번 포스팅에서는 AWS에서 가장 효율적이며 중요한 서비스중 하나인 객체스토리지(S3)에 대해서 알아보겠다.

S3

일반 사용자,애플리케이션 그리고 셀 수 없이 많은 AWS서비스를 위한 데이터 저장소다.
다음 용도로 널리 활용된다.

  • 아카이브, 로그파일, 재난 복구 이미지 등을 이용한 백업관리
  • 저장된 빅데이터의 분석 업무
  • 정적 웹사이트 호스팅

💡 S3파일은 버킷에 보관되며, 버킷이름은 유일해야한다.

장점

  1. 이론상으로 S3는 용량 제한이 없다.
  2. 접근이 매우 용이하다.
  3. 내구성과 가용성이 매우높다
  4. 비용,접근,운영 등 사용자의 목적에 따라 여러가지 클래스 옵션이 존재한다.

클래스 옵션

S3 Standard

가용성 99.99%
📌 USE CASE : 파일에 대한 접근이 빈번하며, 파일 인출 속도가 즉시여야 한다. 파일이 절대 손실되면 안되는 중요한 워크로드.
📌 비용 : 0.46$

S3 Standard-IA

가용성 99.9%
📌 USE CASE : 파일에 대한 접근이 빈번하지않지만, 파일 인출 속도가 즉시여야 한다.
📌 Standard보다 싸다.

S3 One Zone-IA

가용성 99.5%
📌 USE CASE : 파일에 대한 접근이 빈번하지않지만, 파일 인출 속도가 즉시여야 한다.
📌 비용 : 0.65$
💡 하나의 AZ에만 저장하기 때문에 다른 옵션보다 가용성이 떨어진다. 덜 중요한 워크로드에 사용된다.

S3 Intelligent-Tiering

가용성 99.9%
📌 USE CASE : 접속빈도에 따라 자동으로 클래스를 낮춤으로써 비용효율적인 운영을 하고자 할 때
EX) 30일동안은 Standard 사용 후 - > 1년 간 Standard-IA 사용

📌 비용 : 사용하는 옵션 지불.

💡 S3 Standard - 최소과금 X <> Intelligent-Tiering - 최소과금 30일
Intelligent-Tiering이 비용은 더 싸지만 만일 30일 이내로 사용한다면 오히려 Standard가 비용효율적이다.

종국적 일관성 데이터

One Zone을 제외한 S3는 세개 이상의 AZ에 데이터를 분산해서 관리한다. 만일 해당 AZ에 있는 S3에 데이터 삭제, 업데이트 작업을 수행 직후 구 버전을 바로 삭제하면 다른 AZ에 변경사항이 적용 되지 않아 심각한 문제를 초래한다. 따라서 항상 지연시간 1~2초정도 감안한 뒤 관련 작업 수행을 설계해야 한다.

버저닝/Life cycle관리

  • 버저닝 : S3의 매우 중요한 기능으로 사용자가 실수로 파일을 덮어쓰거나 삭제했을 경우 이 기능을 통해 구버전이 저장이 되어 복구를 쉽게 할 수 있다.

  • Life cycle관리 : 버저닝기능을 통해서 구버전을 보관할 수 있다. 하지만 구버전을 무한정 보관하기에는 용량에 무리가 있다. Life cycle을 설정해서 일정기간이 지난 구버전을 삭제할 수 있다.
    🖌 기간을 지정해서 각 기간마다 원하는 옵션 사용하도록 설정가능
    ex) 첫 30일간 s3 Standard -> 다음 30일간 좀 더 저렴한 One zone-IA에 저장 -> 1년간 Glacier에 보관후 삭제.

크로스리전 복제

다른 리전에 동일한 S3를 버킷을 만들어 앞으로 저장되는 객체를 복제한다.

  • 재해 복구 : 해당 리전이 실패할 경우 크로스 리전 복제를 통해 다른 리전에 동일한 버킷을 만들어 다른 리전으로 재해복구
    💡 현재 리전, 다른 리전에 존재하는 각 버킷은 모두 버저닝 기능이 활성화 상태여야 한다.
    💡 S3의 내구성을 향상시킨다.
  • 저지연 데이터 전송 : 거리가 먼 사용자가 해당 리전 버킷에 접근해서 작업하는 것은 느리고 비효율적이다. 따라서 사용자와 가까운 리전에 버킷을 복제해 사용자는 자신과 가까운 버킷에 접근해 저지연의 속도로 작업 할 수 있다.

Object Lock

관리자가 해당 버킷에 대해 다른 사용자가 접근은 할 수 있지만, 임의적인 수정,삭제를 원치않을 경우 Object lock을 통해 버킷을 잠글 수 있다.
📌 버킷 생성 단계에서만 설정할 수 있으며, 버킷을 생성 후 설정하는 것은 안된다.

Glacier

S3와 마찬가지로 객체 스토리지이다 .
S3와 비슷한 부분이 많으며, 내구성과 가용성도 매우 높다.
USE CASE: 데이터 접근도 많이 없고 , 인출도 즉시 할 필요가 없으며 , 비용효율적으로 보관하고자 할 때
📌 '장기 보관용 스토리지'라고 불린다.

S3와 다른점

  • 가장 큰 차이점은 💡인출시간💡 이다.
    S3는 데이터 즉시 인출이지만 GLACIER은 인출 시간이 오래걸린다.
  • S3보다 비용이 더 싸다.
  • 용량제한 40TB
  • S3는 데이터 암호화가 옵션, GLACIER은 기본적으로 데이터가 암호화된다.
  • 버킷이 아닌 볼트에 객체를 저장한다.

인출시간

Glacier Standard - 1분~5분
Glacier Expedited - 3시간~5시간
Glacier Bulk - 5시간~12시간
Glacier Deep Archive - 12시간 이상 (매우 저렴)

마치며

이번 포스팅에서는 객체 스토리지에 대해서 다루어보았다. 공부하면서 느낀점은 이러한 수많은 옵션들을 Life cycle관리로 어떻게 기간별로 설정하여 비용효율적으로 운영하는지가 객체 스토리지부분에서 제일 중요한 것 같다. 다음 포스팅은 마지막 스토리지인 칼럼형 스토리지 - Redshift에 대해서 다루어 보겠다.

profile
성실하게 열심히!

0개의 댓글