[SAA] S3

SMALL

1. Amazon S3

AWS의 주요 구성 요소 중 하나
무한하게 확장할 수 있는 스토리지로 소개됨
많은 웺 사이트가 Amazon S3에 의존
많은 AWS 서비스들도 AmazonS3를 통합하여 사용
사용 사례
- 백업 및 스토리지
- 재해 복구
- 아카이브
- 하이브리드 클라우드 스토리지
- 애플리케이션 스토리지
- 미디어 호스팅
- 데이터 레이크 및 대규모 데이터 분석
- 소프트웨어 배포
- 정적 웹사이트 호스팅
- Nasdaq: 7년간의 데이터를 S3 Gracier에 저장핻둠
- Sysco: 자체 데이터에 관한 분석을 실행하여 S3로부터 비즈니스 인사이트를 얻음
버킷(Buckets)
- Amazon S3는 파일을 버킷(디렉토리)에 객체(파일)을 저장함
- 버킷은 전체 지역과 모든 계정에서 전역적으로 고유한 이름을 가져야 함
  - AWS에서 전역적으로 고유한 단 하나의 이름이어야 함
- 버킷은 리전 수준에서 정의
- S3는 전역 서비스처럼 보이지만 버킷은 사실상 리전에서 생성
- Naming Convention
  - 대문자, 밑줄 사용, ip 주소 X
  - 3 ~ 63 length
  - 소문자, 숫자로 시작
  - 접두사 xn-- 시작 X
  - 접미사 -s3alias X
  - 소문자, 숫자, 하이픈만 사용
객체(Objects)
- 객체(파일)은 키(Key)를 가지고 있음
- 키는 전체 경로를 의미
  - s3://my-bucket/my_file.txt
  - s3://my-bukct/my_folder1/folder1_1/my_file.txt
- 키는 접두사(prefix)와 객체 이름으로 구성됨
- amazon s3 그 자체로는 디렉토리의 개념이 없음 (UI에서는 그렇지 않게 보일 수 있음)
- 슬래시를 포함한 아주 긴 이름의 키만 존재
- 객체의 값은 본문의 내용
  - 최대 객체 크기는 5TB
  - 매우 큰 파일을 업로듣하는 경우에는 multi-part upload를 사용해야 함
- 메타데이터(metadata): 텍스트 키/값 쌍의 목록, 시스템 또는 사용자 메타데이터
- 태그(tag): 유니코드 키/값 쌍, 최대 10개, 보안/수명주기에 유용
- 버전 ID: 버전 관리가 활성화된 경우
보안(Security)
- User-Based: IAM Policies: IAM에서 특정 사용자에 대해 허용되어야 하는 API 호출 지정
- Resource-Based
  - Bucket Policies: S3콘솔에서 직접 할당할 수 있는 전체 버킷 규칙
    - 다른 계정의 사용자 허용 = S3 버킷에 엑세스 할 수 있는 교차 계정(cross account)
  - Objeect Access Control List (ACL): 더 세분화된 권한 설정(비활성화 가능)
  - Bucket Access Control List (ACL): 덜 일반적인 권한 설정(비활성화 가능)
- IAM Princibal이 S3 객체에 액세스 하려면, 사용자 IAM 권한이 허용(ALLOW) OR 리소스 정책이 허용해야 함, AND 명시적인 거부(DENY)가 없어야 함
S3 버킷 정책(S3 Bucket Policies)
- JSON based policies
  - Resources: 버킷과 객체
  - Effect: Allow / Deny
  - Actions: 허용하거나 거부할 수 있는 API 집합
  - Principal: 정책을 적용할 계정 또는 사용자
- S3 버킷 정책을 사용하여 다음을 수행
  - 버킷에 댇한 공개 액세스 부여
  - 객체를 업로드할 때 암호화 강제화
  - 다른 계정에 액세스 권한 부여 (cross account)
- Bucket setting for block public access
  - 기업 데이터의 유출을 방지하기 위한 추가 보안 계층
  - 버킷이 절대로 공개하면 안되는 경우에 설정 적용
  - S3 버킷 정책을 설정하여 공개로 만들더라도 이 설정이 활성화되어 있다면 버킷은 절대 공개되지 않음
  - 계정 수준에서 설정 가능
정적 웹사이트 호스팅(Static Website Hosting)
- 정적 웹사이트를 호스팅하고 인터넷에서 액세스할 수 있게 만들 수 있다.
- 정적 웹사이트를 호스팅하는 경우 해당 웹사이트의 url은 리전에 따라 http://buckeet-name.s3-website-aws-region.amazonaws.com 혹은 http://bucket-name.s3-website.aws-region.amazonaws.com으로 호스팅됨
- 403 forbidden 오류 발생 시 버킷 정책이 공개 읽기를 허용하는지 확인
버전 관리(Versioning)
- Amazon S3에서 파일의 버전 관리 가능
- 버전 관리는 버킷 수준에서 활성화
- 동일한 키를 덮어쓰면 버전이 변경됨
- 버킷에 버전 관리를 적용하는 것은 좋은 방법이다.
  - 의도하지 않은 삭제로부터 보호(버전을 복원할 수 있는 기능)
  - 이전 버전으로 쉽게 롤백 가능
- 버전 관리가 활성화됟기 전에 버전관리되지 않은 파일은 "null"버전을 가지게 됨
- 버전 관리를 일시중단해도 이전 버전은 삭제되지 않음
복제(Replication, CRR & SRR)
- 소스 버킷과 복제 대상 버킷에서 둘 모두 버전 관리 기능이 활성화 되어야 함
- Cross-Region Replication(CRR) : 교차 리전 복제
- Same-Region Replication(SRR) : 같은 리전으로 복제
- 버킷은 다른 AWS 계정에 속할 수 있음
- 복제는 비동기적으로 진행됨 - 복제 과정은 백그라운드에서 이루어지게 됨
- S3에 적절한 IAM 권한, 즉 읽기/스기 권한을 부여해야 함
- 사용사례
  - CRR: 법규, 내부 체제 관리, 데이터가 다른 리전에 있어 발생할 수 있는 지연 시간 줄이기, 계정간 복제
  - SRR: 로그 통합, 운영 환경과 개발 환경간의 실시간 복제
- 추가
  - Replication 기능을 활성화 한 이후의 새로운 객체만 복제됨
  - optional로 기존 객체들을 복제하려면 S3 Batch Replication을 사용해야 함
  - delete marker가 붙은 객체는 복제할 수 있지만 default는 disabled, version ID가 붙은 것은 악용 우려하여 복제 불가
  - 연쇄 복제 불가 (버킷 1에서 버킷 2로 복제, 버킷 2에서 버킷 3으로 복제, 버킷 1에서 생성된 객체는 버킷 3으로 복제 불가)
S3 Storage Classes
- Amazon S3 Standard - General Purpose
  - 99.99%의 가용성
  - 자주 액세스하는 데이터에 사용
  - 지연 시간이 짧고 처리량이 높음
  - AWS에서 두 개의 기능 장애를 동시에 버틸 수 있음
  - ex) 빅데이터 분석, 모바일 및 게임 애플리케이션, 콘텐츠 배포 등
- Amazon S3 Standard-Infrequent Access (IA)
  - 99.9%의 가용성
  - 덜 빈번하게 액세스되지만 필요한 경우 빠른 액세스가 필요한 데이터에 사용
  - S3 Standard 보다 저렴한 비용, 검색 비용 발생
  - ex) 재해 복구, 백업
- Amazon S3 One Zone-Infrequent Access
  - 단일 AZ에서 높은 내구성(99.999999999%)을 갖지만 AZ가 파괴되면 데이터 손실
  - 99.5%의 가용성
  - 덜 빈번하게 액세스되지만 필요한 경우 빠른 액세스가 필요한 데이터에 사용
  - S3 Standard 보다 저렴한 비용, 검색 비용 발생
  - ex) 온프레미스 데이터의 보조 백업 복사본, 재생성 가능한 데이터 저장
- Amazon S3 Glacier Storage Classes
  - 아카이빙 및 백업용으로 사용되는 저비용 객체 스토리지
  - 가격: 스토리지 비용 + 객체 검색 비용
  - Amazon S3 Glacier Instant Retrieval
    - 밀리초 단위의 검색 가능
    - 분기마다 한 번 액세스된느 데이터에 적합
    - 최소 보관 기간: 90일
    - 백업이지만 밀리초 이내에 액세스 해야 하는 경우에 적합
  - Amazon S3 Glacier Flexible Retrieval(formerly Amazon S3 Glacier)
    - 데이터 검색 시 소요 시간
      - Expedited: 1 ~ 5분
      - Standard: 3 ~ 5시간
      - Bulk: 5 ~ 12시간
    - 최소 보관 기간: 90일
  - Amazon S3 Glacier Deep Archive - for long term storage
    - 데이터 검색 시 소요 시간
      - Standard: 12시간
      - Bulk: 48시간
    - 최소 보관 기간: 180일
- S3에서 객체 생성 시에 클래스를 선택할 수도 있고, 스토리지 클래스를 수동으로 설정도 가능
- S3 수명주기 구성을 사용해 스토리지 클래스간 객체를 자동으로 이동 가능
- S3 Durability & Availability
  - Durability(내구성)
    - 다중 가용 영역에서 객체의 높은 내구성(99.999999999%를 제공함)
    - S3에 천만개의 객체를 저장했을 때 평균적으로 10,000년에 한 번 객체 손실이 발생할 수 있음
    - 모든 스토리지 클래스의 내구성은 동일
  - Availability(가용성)
    - 서비스가 얼마나 신속하게 사용할 수 있는지를 나타냄
    - 스토리지 클래스에 따라 다름
    - S3 Standard의 가용성은 99.99%, 즉 1년에 약 53분 사용 불가
S3 Intelligent-Tiering
- 소액의 월간 모니터링 및 자동 계층화 비용 발생, 검색 비용 X
- 사용량에 기반하여 객체를 자동으로 액세스 계층간에 이동
- Frequent Access tier (auto) : default tier
- Infrequent Access tier (auto) : objects not accessed for 30 days
- Archive Instant Access tier (auto) : objects not accessed for 90 days
- Archive Access tier (optional): configurable form 90 days to 700+ days
- Deep Archive Access tier (optional): config from 180 days to 700+ days

2. Advanced S3

Moving between Storage Classes
- 스토리지 클래스 간 객체 이동 가능
- 자주 액세스되지 않는 객체는 Standard IA로, 빠른 액세스가 필요하지 않은 아카이브 객체는 Glacier 또는 Glacier Deep Archive 티어로 변경
- 객체는 수동으로 옮기거나 수명 주기 규칙을 이용하여 자동화할 수 있음
- Lifecycle Rules
  - Transition Actions 전환 작업: 객체를 다른 스토리지 클래스로 전환하기 위해 구성
    - 객체 생성 후 60일이 지나면 Standard IA로 이동
    - 6개월 후 아카이빙을 위해 Glacier로 이동
  - Expiration Actions 만료 작업: 일정 시간 후에 객체를 삭제 또는 만료되도록 구성
    - 365일 후에 액세스 로그 파일을 삭제
    - 버전 관리가 활성화된 경우 이전 버전의 파일을 삭제하도록 설정
    - 완료되지 않은 멀티파트 업로드를 삭제하도록 구성
    - 특정 접두사에 대한 규칙 생성 가능 (ex. s3://mybucket/mp3/*)
    - 특정 객체 태그에 대한 규칙 생성 가능(ex. Department: Finance)
  - Senario
  - 프로필 사진이 Amazon S3에 업로드된 후 썸네일이 생성됨. 썸네일은 원본 사진에서 재생성하기 쉬우므로 60일간 보관. 소스 이미지는 이 60일 동안은 바로 검색할 수 있어야하며, 그 이후에는 사용자가 6시간까지 기다릴 수 있음. 어떻게 설계하면 좋은가?
    - 접두사를 이용하여 썸네일과 소스 이미지를 구분
    - 소스 이미지를 Standard에 두고 수명 주기 구성을 한 다음 60일 이후에 Glacier로 전환
    - 썸네일은 One-Zone IA에 두고 수명 주기 구성을 통해 60일 이후 만료 또는 삭제
  - S3 객체 삭제 후 30일 이내에는 즉시 복구가 가능해야 함. 그로부터 365일 동안은 삭제된 객체를 48시간 이내에 복구할 수 있어야 함.
    - S3 버저닝 활성화, 삭제된 객체가 실제로는 삭제 마커에 의해 숨겨지고 복구할 수 있도록 함
    - 객체의 이전 버전은 Standard IA로 이동
    - 이동 후 객체의 이전 버전은 Glacier Deep Archive로 이동
- Amazon S3 Analytics - Storage Class Analysis
  - 객체를 적절한 스토리지 클래스로 전환할 때 도움
  - Standard 및 Standard IA용 권장사항 제공 (One-Zone IA or Glacier는 해당 X)
  - 보고서는 매일 업데이트됨
  - 데이터 분석을 시작하는데 24 ~ 48시간 소요
  - 수명 주기 규칙을 작성하거나 개선하는 데에 좋은 첫번째 단계
Requester Pays
- 일반적으로, 버킷 소유자는 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 부담
- 요청자가 비용을 부담하는 Requester Pays 버킷의 경우, 버킷 소유자 대신 요청자가 요청 및 버킷에서 객체 데이터 다운로드 비용 지불
- 다른 계정과 대규모 데이터셋을 공유하려는 경우 유용
- 요청자는 AWS에서 인증읇 받아야하며, 인증된 상태여야 함(익명 불가)
Event Notifications
- S3: ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication 등의 이벤트유형 필터링
- 객체 이름 필터링
- ex) S3에 업로드된 이미지의 썸네일 생성
- 원하는 만큼 많은 S3 이벤트를 생성할 수 있음
- S3 이벤트 알림은 일반적으로 몇 초 내에 이벤트를 전달하지만 때로는 1분 이상 걸릴 수 있음
- S3 Event Notifications with Amazon EventBridge
  - JSON 규칙을 사용한 Advenced filtering 옵션(메타데이터, 객체 크기, 이름 등)
  - Multiple Destinations: ex) Step Function, Kinesis Streams / Firehose 등
  - EventBridge Capabilities: 이벤트 아카이브, 이벤트 재생, 안정적인 전송
Baseline Performance
- 요청이 아주 많을 때 자동으로 확장, 지연 시간도 100-200ms 수준으로 아주 짧음
- 버킷 내 접두사(prefix)당 3,500개/sec의 PUT/COPY/POST/DELETE 요청 혹은 5,500개의 GET/HEAD 요청 처리 가능
- 버킷 내 접두사의 수에는 제한이 없음
- 모든 접두사에 대해 읽기 요청을 균등하게 분산하면 GET/HEAD 요청을 초당 22,000개 처리가능
- S3 Performance
  - Multi-Part upload
    - reommeended for files > 100mb, must use for files > 5gb
    - 업로드를 병렬화하여 전송 속도를 높여 대역폭을 최대화할 수 있음
    - 모든 파트가 업로드되면 자동으로 모든 파트를 다시 합쳐 다시 하나의 큰 파일로 만듬
  - S3 Transfer acceleration
    - 파일을 AWS Edge Location으로 전송하고 해당 데이터를 대상 지역의 S3 버킷으로 전달
    - Edge Location으로 전송하여 전송 속도를 높임(Edge Location은 region보다 더 많음)
    - 멀티파트 업로드와 호환
  - S3 Byte-Range Fetches
    - 특정 바이트 범위를 요청함으로써 GET을 병렬화하여 수행
    - 특정 바이트 범위를 가져오는데 실패한 경우에도 더 작은 바이트 범위에서 재시도, 실패의 경우에도 복원력이 높음
    - 다운로드 속도를 높일 수 있음
    - 파일의 일부만 검색 시에 사용할 수 있음 ex) file의 header
S3 Select & Glacier Select
- server-side filtering을 통해 sql을 사용하여 데이터의 일부를 검색할 수 있음
- 간단한 sql문을 사용하여 행 및 열로 필터링 가능
- 데이터 전송량을 줄이고 클라이언트 측의 cpu 비용 절감 가능
- 간단한 필터링의 경우 추천
S3 Batch Operations
- 단일 요청으로 기존 S3객체에 대한 대량 작업을 수행하는 서비스
  - 객체 메타데이터 및 속성 수정
  - S3 버킷 간 객체 복사
  - 암호화되지 않은 객체 암호화
  - ACL, 태그 수정
  - S3 Glacier에서 객체 복원
  - Lambda 함수를 호출하여 사용자 지정 작업 수행
- 작업은 객체의 목록, 수행할 작업 및 옵션 매개 변수로 구성됨
- 직접 스크립팅 하지 않고 S3 Batch Operations를 사용하는 이유는?
  - 재시도 관리
  - 진행상황 추적
  - 작업 완료 알림
  - 보고서 생성
- S3 Inventory를 사용하여 객체 목록을 가져오고 S3 Select를 사용하여 객체를 필터링한 후 S3 Batch Operations에 수행할 작업, 매개 변수와 함께 객체 목록을 전달하면 S3 배치가 작업을 수행하고 객체를 처리
- ex) S3 Inventory를 사용해 암호화되지 않은 객체를 찾은 다음 S3 Batch Operations를 사용해 한번에 암호화

LIST

'develop > AWS' 카테고리의 다른 글

[SAA] Global Infrastructure (0)	2024.05.10
[SAA] S3 보안 (0)	2024.05.09
[SAA] Route 53 (0)	2024.04.26
[SAA] RDS, Aurora, ElastiCache (1)	2024.04.24
[SAA] ELB(Elastic Load Balancer), ASG(Auto Scaling Group) (1)	2024.04.20

1. Amazon S3

2. Advanced S3

'develop > AWS' 카테고리의 다른 글

티스토리툴바