Introduce
aws solutions architect를 준비하며 공부한 s3에 대해 정리합니다.
공식문서 및 백서, 활용 아키텍처를 중심으로 천천히 살펴보았습니다.
A. S3 Overall
0. What is a S3?
- Simple Storage Service의 약자로 객체 스토리지 서비스.
- 99.999999999% (9가 11)의 내구성을 제공.
- 높은 처리량, 낮은 지연 시간
스토리지 종류
1. Block Storage : 데이터를 고정된 크기의 블록으로 나누어 저장함.
주로 데이터베이스나 가상 머신에 사용되는 고성능 저장소. ex) Amazon EBS
2. File Storage : 디렉토리 구조로 데이터를 저장하고 NAS와 같은 방식으로 공유하여 사용함. ex) Amazon EFS
3. Object Storage : 데이터를 객체 단위로 저장함.
메타데이터와 함께 확장성이 뛰어나 비정형 데이터를 저장하는 데 적합함 ex) Amazon S3
1. S3 Bucket
- S3에서 데이터를 저장하는 컨테이너.
- 각 버킷은 고유한 이름을 가지고 있으며, 객체(object)를 보관하는 공간
- 버킷은 계정안에 생성됨 (AWS account)
- 버킷명은 AWS 전역적으로 고유해야 함
- 버킷은 리전 수준에서 정의됨
- 버킷은 상위 레벨 디렉토리로 표시
2. S3 Object
- 버킷에 저장되는 데이터 단위
- 객체의 구조는 데이터, 메타데이터, 키로 구성되어 있음
- data: 객체에 저장된 실제 파일 내용으로, 이미지, 비디오, 문서 등 다양한 형식의 데이터.
- meta: 객체에 대한 설명 정보로, 객체 크기, 생성 날짜, 사용자 정의 메타데이터 등을 포함.
- key: 객체를 고유하게 식별하는 이름으로, S3 버킷 내에서 각 객체를 구분하는 역할.
- 단일 객체의 최대 크기는 5TB.
- 메타 데이타 : 객체의 key-value 쌍 리스트
- 시스템이나 사용자에 의해 설정됨
- 파일에 관한 요소나 태그를 설정할 수 있음
- 객체 (file)는 key를 가지고 있음
- Key는 full path. 즉, 파일의 전체경로를 뜻함
- 객체를 폴더에 중첩하려는 경우, 키는 전체 경로가 됨
ex)
s3://my-bucket/my_file.txt
s3://my-bucket/my_folder/another_folder/my_file.txt
-> The Key is composed of 'prefix' + 'object name'
즉,my_folder/another_folder가 prefix,my_file.txt가 object name. - 버킷 자체로는 디렉토리 개념이 없음
3. S3 Security
-
User-Based
- IAM : IAM Policies를 통해 액세스 관리 가능. 최소권한 원칙 적용, MFA 활용 등 다양한 옵션 -
Resource-Based
- Bucket Polices : 버킷 단위로 적용되는 JSON 형식의 정책으로, 버킷 및 그 안의 객체에 대한 접근 권한을 정의하고 관리
- Object Access Control List (ACL) : 개별 객체에 대한 접근 권한을 제어하며, 각 객체마다 읽기/쓰기 권한을 사용자나 그룹별로 설정함
- Bucket Access Control List (ACL) : 버킷 전체에 대한 접근 권한을 제어하며, 버킷에 대한 읽기/쓰기 권한을 사용자나 그룹별로 설정함 -
Public Access 설정을 통해 버킷/객체에 대한 차단 설정이 가능하여, 실수로 인한 데이터 유출을 방지할 수 있음.
-
객체 수준에서의
SSE-S3,SSE-KMS,SSE-C옵션1. SSE-S3 - 활용 사례: 기본적인 보안 요구가 있을 때, 별도의 키 관리 없이 자동으로 데이터를 암호화하려는 경우. - 사용 시점: 키 관리가 필요 없고 S3에서 모든 암호화 과정을 처리하도록 맡기고 싶을 때 사용하면 좋음 2. SSE-KMS 활용 사례: 엄격한 보안 요구가 있고, KMS를 통해 키의 생성, 관리, 권한 제어를 세밀하게 설정해야 할 때. 사용 시점: 규제 준수나 감사 요구 사항이 있고, 키 관리에 대한 제어가 필요한 상황에서 적합 3. SSE-C 활용 사례: 고객이 암호화 키를 직접 관리하고 싶고, AWS가 키를 저장하거나 관리하지 않기를 원할 때. 사용 시점: 데이터 보호를 위해 키를 스스로 관리하고 AWS가 해당 키를 저장하지 않도록 하려는 경우에 적합
4. S3 Replication
- S3는 한 버킷의 객체를 자동으로 다른 버킷으로 복사(복제)하는 기능을 제공함.
- Cross-Region Replication (CRR) : 다른 리전 간 복제
- Same-Region Replication (SRR) : 같은 리전 간 복제
- 버킷 복제는 서로 다른 aws account에서도 가능
- 복제 기능을 활성화 한 이후에 생성된 객체부터 복제가 가능함
이전의 객체를 복제해야 할 경우, S3 Batch Replication을 이용해야함
이는 기존 객체부터 복제에 실패한 객체까지 복제를 처리가 가능 - 체이닝 복제는 불가능함.
- UseCase
- CRR : compliance (법규 및 내부 체제 관리), 데이터가 다른 리전에 있어 발생할 수 있는 지연 문제 해결
- SRR : 다수의 버킷간의 로그 통합, 개발 환경이 별도로 있어 실시간 복제를 필요로 할 때
5. S3 Storage Class
- Amazon S3 Standard: 기본 스토리지 클래스, 자주 접근하는 데이터에 적합
- S3 Intelligent-Tiering: 액세스 패턴이 변경되는 데이터에 적합, 자동으로 가장 비용 효율적인 계층으로 이동
- S3 Standard-Infrequent Access (S3 Standard-IA): 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합
- S3 One Zone-Infrequent Access (S3 One Zone-IA): Standard-IA와 유사하지만 단일 가용 영역에만 저장되어 더 저렴
- S3 Glacier Instant Retrieval: 분기에 한 번 정도 액세스하는 장기 보관 데이터에 적합, 밀리초 단위의 검색
- S3 Glacier Flexible Retrieval: 장기 백업 및 아카이브에 적합, 검색에 몇 분에서 몇 시간 소요
- S3 Glacier Deep Archive: 가장 저렴한 스토리지 클래스, 연 1-2회 액세스하는 데이터에 적합, 검색에 12시간 소요
- Life Cycle : 객체 수명 주기를 설정하여, 자동으로 스토리지 이전을 처리할 수 있음
1. Transition Actions : 객체를 다른 스토리지 클래스로 이전하기 위한 작업
- 생성된 지 60일 후에 Standard IA 클래스로 이전
- 6개월 후에 Gracier로 아카이빙을 처리
2. Expiration actions : 일정한 시간 뒤에 만료(삭제)되도록 설정하는 작업
- 액세스 로그 파일을 356일 뒤에 삭제 할 수 있음
- 버저닝을 활성화 했다면 모든 파일 버전 삭제도 가능함
- 불완전한 멀티파트 업로드를 삭제할 수도 있음
3. 규칙은 특정한 접두어(prefix)에 대해 지정할 수 있음
또는 버킷 전체에 적용하거나 버킷 안의 특정한 경로, 특정한 객체 태그에 대해 규칙을 지정할 수 있음
4. Amazon S3 Analytics를 이용하면 추천사항과 통계를 통해 합리적인 라이프사이클 규칙을 조합하거나 개선에
도움을 줄 수 있음
6. S3 Versioning
- 버킷 단위로 버전 관리를 활성화 할 수 있으며, 필요에 따라 언제든 일시 중지 가능.
- 객체의 각 버전은 고유한 버전 ID를 가지며, 특정 버전의 객체를 식별할 수 있음.
- 객체를 처음 업로드하면 null. 객체 덮어쓰면 새로운 버전. 객체 삭제 시 삭제마커만 뜨고 실제 삭제는 아님.
- 버전 관리로 인해 스토리지 사용량 증가 가능성. life cycle 정책으로 자동으로 삭제하여 비용 관리 가능.
- 실수로 인한 삭제 혹은 덮어 쓰기 시, 이전 버전으로 복구 가능.
- 특정 버전으로 롤백하는 등 데이터 복구 시나리오에 활용 가능함.
7. S3 Batch Operations
- S3 Batch Operations: 단일 요청으로 여러 S3 객체에 대량 작업을 수행하는 서비스.
- 사용 사례: 많은 객체의 메타데이터 및 속성 수정, S3 버킷 간 객체 복사, 암호화되지 않은 객체 암호화, ACL 및 태그 수정, S3 Glacier에서 다수 객체 복원, Lambda 함수 호출을 통한 사용자 지정 작업 등.
- 작업 구성: 객체 목록과 작업 옵션 매개 변수로 작업을 설정하며, 재시도 관리, 진행 상황 추적, 알림, 보고서 생성 등의 기능을 제공
- 객체 목록 생성:
- S3 Inventory를 사용해 객체 목록을 가져오고, S3 Select로 필터링해 필요한 객체를 선택한 후 S3 Batch Operations에 전달.
- 주요 사용 사례: S3 Inventory로 암호화되지 않은 객체를 찾은 후, S3 Batch Operations를 사용해 한 번에 모두 암호화하는 것이 대표적인 예시.
8. S3 Event Notification
- S3 이벤트 (객체 생성, 복구, 복제, 삭제 등) 혹은 특정 파일 형식(ex: .jpg)에 대해 필터링해 이벤트 관리 가능
- S3 이벤트 관리는 SNS, SQS, Lambda로 전송 할 수 있으며, 각 서비스엔 IAM 권한 필요 (ex: SNS Resource Policy)
- Amazon EventBridge를 이용해 보다 많은 고급 필터링과 다양한 서비스에 통합이 가능함 (ex: Step Function, Kinesis Streams)
9. S3 Performance
- 기본 성능
- S3는 자동으로 스케일링 되며, 첫번째 바이트를 가져오는 데, 100~200ms 지연 시간 있음.
- 버킷 내 접두사(prefix)당 초당 3,500개의 PUT, COPY, POST, DELETE 요청,
초당 5,500개의 GET, HEAD 요청을 처리할 수 있음
- 성능은 접두사에 따라 확장됨. 필요처리량 달성을 위해 얼마든지 병렬로 접두사 추가 가능.
- 접두사란 객체 경로에서 파일 이름 앞의 모든 경로를 의미하며, 접두사마다 별도의 성능 한도를 가짐.
- 즉, 데이터 추가 시, 초당 최소 3,500개의 요청 지원
- 즉, 데이터 조회 시, 초당 최소 5,500개의 요청 지원 - 성능최적화 방안
- 멀티파트 업로드: 100MB 이상의 파일을 업로드할 때는 멀티파트 업로드를 권장하며, 5GB 이상의 파일에는 필수. 파일을 여러 부분으로 나누어 병렬로 업로드해 전송 속도를 높임
- S3 Transfer Acceleration: 파일을 엣지 위치를 통해 업로드하여 전송 속도를 향상시킴.
AWS의 프라이빗 네트워크를 사용해 공공 인터넷 사용을 최소화
- 바이트 범위 가져오기: 파일의 특정 바이트 범위를 병렬로 가져와 다운로드 속도를 높이고, 필요시 파일의 일부만 검색할 수 있음.
B. Think Best Practice
1. S3 성능 개선 방안
- 객체 크기
- 작은 객체의 (1mb 미만) 경우 데이터 추가 작업 (Put, Copy, Post, List) 속도가 빠르나, 요청 오버헤드 비용이 상대적으로 높음.
- 작은 객체에 대한 요청 오버헤드를 줄이기 위해 여러개의 객체를 하나로 병합하는 방법을 고려해볼 수 있음.
- 큰 객체 (100mb 이상) 업로드/다운로드 시 멀티파트를 이용하는 것이 좋음. 성능 향상 및 재시도를 통해 신뢰성 높아짐.
- 큰 객체에 대한 파트 크기를 적절히 조회하여 성능 최적화 할 수 있으며, SDK에서 제공하는 멀티스레드를 통해 병렬 처리를 고려해볼 수 있음. - 버킷 구조
- 버킷 내 객체의 수가 많아지면 성능 저하 가능성 존재함.
- 이를 방지하기 위해 버킷 구조를 세분화 혹은 접두사를 활용하여 객체 분산을 시도할 수 있음. - 기타
- S3 Transfer Acceleration을 활용하여 원격 지역의 데이터 전송 속도를 높일 수 있음.
- S3 Intelligent-Tiering을 사용하여 자주 사용되지 않는 데이터를 더 저렴한 스토리지 클래스로 자동 이동을 고려.
- CloudWatch와 같은 모니터링 기능을 통해 S3 성능을 지속적으로 모니터링하고 최적화할 수 있음.
2. S3 비용 관리
-
스토리지 클래스 선택
- 데이터 액세스 빈도에 따라 적절한 스토리지 클래스를 선택하여 비용 최적화 수행
- 수명 주기 정책(life-cycle)을 통해 데이터 수명 주기에 따라 적절한 스토리지 클래스로 데이터를 이전 시켜, 비용 절감. -
S3 Transfer Acceleration
- CloudFront의 엣지 로케이션을 이용하여 더 빠르고 효율적인 전송 -> 전송시간 단축 -> 전송 비용 절감.
- 즉, 데이터 전송 비용 절감 -
S3 Batch Operation
- 객체에 대한 일괄처리를(복사, 삭제, 태그지정 등) 수행하면 개별적으로 수행할 때보다 요청 비용이 줄어듬
- 즉, 데이터 요청 비용 절감ex) standard class에서 객체 1000개에 대한 태그 지정 작업 시?
- > 개별 요청 : 1,000 0.005 (PUT Object 태그 지정 요청 비용) = $5
- > 배치 : 0.05 (batch api 1회 비용) + 1,000 0.0001 (PUT 태그 지정 비용) = $0.10 -
기타
- 버전 관리와 MFA 삭제 활성화를 통해 데이터 보호와 실수로 인한 삭제를 방지시켜 비용을 절감
3. S3 스토리지 클래스별 활용 방안
- Standard
- 가장 일반적인 스토리지, 자주 접근하는 데이터에 적합
- 웹사이트 콘텐츠, 동영상, 이미지, 애플리케이션 데이터 등 저장에 적합
- ex) 자주 액세스 되는 비즈니스 데이터, 실시간 분석에 사용되는 데이터 등 - Intelligent-Tiering
- 자동으로 데이터 액세스 패턴을 모니터링하여 비용 효율적인 계층으로 이동
- 엑세스 빈도가 변동적인 경우 추천됨
- 자주 액세스 -> standard 계층, 가끔 액세스 -> 인프리퀀트 계층 자동 이동
- 데이터 마이그레이션 없이 비용 절감 가능
- ex) 액세스 패턴 불규칙한 비즈니스 데이터 (계약서, 보고서, 인사 기록 등), 예측 분석을 위한 데이터 (고객행동, 센서데이터) 등 - Standard-IA (Infrequent Access)
- Standard보다 저렴하지만 액세스 요금이 추가
- 장기 보관이 필요하지만, 자주 액세스 되지 않는 데이터에 적합
- ex) 규제 대상 데이터 (감사 기록, 의료 기록), 재해 복구 및 백업용 데이터, 과거 프로젝트 관련 데이터 등 - One Zone-IA
- Standard-IA보다 저렴하지만 내구성이 낮음
- 단일 가용 영역에 데이터 저장
- 개발 및 테스트 환경의 데이터, 자주 액세스되지 않는 로그 파일, 백업용 데이터 (중요도가 낮은 데이터)
- Glacier
- 가장 저렴한 스토리지 클래스 중 하나
- 자주 액세스 되지 않으나, 장기 보관이 필요한 아카이브 데이터를 저장하는데 적합
- 규정 준수 요구사항이 있는 경우 적합함
- 데이터 복구 시간이 12-24시간 소요
- ex) 역사적 기록, 법적 증거 자료 등, 규제 준수를 위한 데이터, 재해 복구를 위한 데이터 등 - Glacier Deep Archive
- Glacier보다 더 저렴한 스토리지 클래스
- 10년 이상 장기 보관이 필요한 데이터에 적합
- 데이터 복구 시간이 12-48시간 소요
- ex) 10년 이상 장기 보관이 필요한 법적/규제/으료 기록, 역사적 가치가 있는 데이터 등
- 10년 이상 장기 보관이 필요한 데이터에 적합
- Glacier보다 더 저렴한 스토리지 클래스
4. Additions
- 계정당 최대 100개의 버킷이 생성 가능하다. 이것은 soft limit? hard limit?
-> soft limit. 아마존 요청 시 최대 1000개까지 가능 - 객체의 메타데이터는 수정이 가능한가?
-> 불가능. 덮어써야함 - 브라질에 사는 사람이 서울리전 버킷 데이터를 접근할 때, 지연시간 최적화 하려면? (단, cdn 사용 x)
-> CRR을 이용하여 서울 버킷을 브라질 버킷으로 복제하여 사용한다 (CRR)
