스토리지 서비스

스토리지

데이터를 보관하는 장소, 우리가 사용하는 모든 저장 장치를 스토리지

데이터 보관 방식과 데이터 사용 용도에 따라 여러 형태가 있음

Ex) 이동성 및 휴대성을 고려해서 간단한 데이터를 보관할 때 사용하는 USB (Universal Serial Bus), 대용량의 데이터를 보관하거나 백업할 때 사용하는 외장 하드 (SSD, HDD)가 있음

 

AWS에서 제공하는 스토리지 서비스

데이터의 사용 목적에 따라 여러 스토리지 종류가 있음

(1) 블록 (block) 스토리지

(2) 파일 (file) 스토리지

(3) 객체 (object) 스토리지

 

 

블록 (block) 스토리지

단일 스토리지 볼륨(Volume)을 블록 (block)이라는 개발 단위로 분할해서 저장

각 블록은 저장된 위치에 고유한 주소가 있기 때문에 서버에서 파일을 요청하면 블록들을 재구성하여 하나의 데이터로 서버에 전달

그렇기때문에 파일 수정 시, 일부분의 블록 데이터만 변경되므로 낮은 I/O 레이턴시를 자랑하며

Read/Write 작업이 빠르다는 장점이 있음

자주 파일이 업데이트 되고, Read/Write 작업이 빈번한 상황에서 사용하면 좋음

Ex) 일반 컴퓨터에 하드디스크를 추가하여 C드라이브, D 드라이브

왼쪽 Block Level Storage 파일 수정 전 / 오른쪽 Block Level Storage 파일 수정 후

 

파일 (file) 스토리지

파일 수준 또는 파일 기반 스토리지라고 하며, 디렉터리 (directory) 구조로 파일을 저장함

각 파일은 폴더에 종속되고 폴더 역시 다른 폴도에 종속되어 계층 구조를 이룸

따라서 파일을 찾으려면 어느 위치에 있는지 알아야함

파일 스토리지는 개인용 컴퓨터와 서버에서 일상적인 작업을 공유하여 사용할 수 있지만, 파일이 늘어나면 분류하거나 정리 (file system indexing) 하는데 시간이 점점 더 소요된다는 단점이 있음

일반적으로 파일 스토리지는 NAS(Network Attached Storage) 에 사용됨

 

 

객체 (Object) 스토리지

각 데이터 조각을 가져와서 객체로 지정하고, 개별 단위로 저장

파일 스토리지와 다르게 모든 객체는 중첩된 계층 구조 없이 단일한 평면적인 주소 공간에 저장

이 평면 주소 공간에는 데이터 및 관련 메타데이터로 구성된 객체에 고유 식별자가 있음

OS나 파일 시스템에 의존하지 않으면서 데이터를 저장하고 객체에 쉽게 접근할 수 있음

데이터 수정 시, 일부분만 변경하더라도 해당 데이터를 전부 지웠다 다시 생성해야하므로 

Read/Write가 빈번한 환경이라면 작업이 오래걸리는 단점이 있음

하지만 단순한 구조로 읽기 속도가 빠르다는 점과 높은 확장성 그리고 비용이 저렴한 장점이 있음

object 구성

1. id

2. Data

3. metadata : Data를 설명하는 데이터

4. Attribute : versioning, timestamp, author 와 같은 정보

 

 

 

 

객체 스토리지 서비스

스토리지 클래스 제공,

 

 

	블록 스토리지	파일 스토리지	객체 스토리지
데이터 구조	평면 구조	계층 구조	평면 구조
장점	1. 저장된 데이터의 고유 주소가 있어 계층 구조가 필요 없고, 경로도 하나만 있는것이 아니라 다양하여 데이터를 신속하게 검색 2. 파티션으로 분할될 수 있어 서로 다른 운영 체제 OS에서 액세스 가능 3. 자유롭고 효율적이고 안정적이기 때문에 대규모 DB 운여에 적합	1. 오래전부터 사용해온 전통적인 데이터 스토리지 시스템이어 사용자 친숙, 표준화가 잘됨	1. 평면 구조로 데이터 접근이 빠르고 확장성이 좋음 2. 메타데이터가 오브젝트 자체로 저장되므로 접근과 검색이 쉬움
단점	1. 비용이 많이 듦 2. 메타데이터 처리가 제한적이기 때문에 데이터 단위가 아닌 어플리케이션 또는 데이터베이스 수준이어서 작업을 진행하여 관리자의 부담이 큼	1. 데이터가 많아지면 파일과 폴더를 찾기 위하여 리소스가 많이 들어 성능이 나쁨	1. 오브젝트를 수정할 수 없어 덮어쓰는 방법을 사용하여 자주 변경되는 데이터에 맞지 않아 수정이 잘 일어나지 않는 이미지나 영상 데이터에 적합
사용 사례	Amazon EBS 호스트에서 직접 파일을 액세스하고 기록하며 빠른 I/O성능을 요하는 경우	Amazon EFS 다수의 장치가 데이터를 공유하여 동일한 서비스를 사용해야 하는 경우	Amazon S3 대량의 데이터를 저장하거나 다수의 서버에서 해당 데이터에 접근해야 하는 경우

 

https://www.youtube.com/watch?v=sswLpKeAoxs

 

 

https://www.youtube.com/watch?v=Akpu35MKzrA

 

 

 

목적에 맞게 구축 된 AWS DB

 

스토리지 관리 항목과 선택 기준

관리 항목 : 비용, 규정 요구 사항 충족 여부, 대기 시간 단축, 규정 준수 요구 사항에 맞는 데이터 복제본 저장 등...

S3 수명 주기, S3 객체 잠금, S3 복제, S3 배치 작업

	내구성	가용성	보안	비용	확장성	성능	통합
주요 내용	데이터 손실 가능성	서비스 지속 시간	저장 및 전송 중 데이터 보안	스토리지 단위 가격	스토리지 크기 및 사용자 수 변경	스토리지 크기 및 사용자수 변경	다른 서비스와 호환성

 

AWS S3 란? (Simple Storage Service)

객체 스토리지 서비스

스토리지 클래스 제공

 

 

작동 방식

데이터를 버킷 내의 객체로 저장하는 객체 스토리지 서비스

객체는 해당 파일을 설명하는 모든 메타 데이터

버킷은 객체에 대한 컨테이너 (컨테이너는 객체를 계층화 할 수 있는 그릇 같은 개념)

객체는 키(이름) 및 버전 ID를 통해 고유하게 식별됨

버킷에 저장할 수 있는 객체 수에는 제한이 없음

 

 

버킷 

S3는 글로벌 버킷을 지원함

즉, 각 버킷 이름은 파티션 내 모든 AWS 리전의 AWS 계정에서 고유해야함

파티션은 리전 그룹임

aws에는 aws(표준 리전), aws-cn(중국 리전) 및 aws-us-gov(AWS GovCloud (US))의 세가지 파티션이 있음

버킷이 생성된 후에는 해당 버킷이 삭제될 때까지 동일한 파티션의 다른 AWS 계정이 해당 버킷 이름을 사용할 수 없음

가용성 또는 보안 확인 목적을 위해 특정 버킷 명명 규칙에 의존하면 안됨

 

그러면 글로벌 서비스인 S3의 버킷은 어느 리전에 생성될까?

기본적으로 사용자가 지정한 리전에 버킷을 만듦. 지연 시간을 줄이고 비용을 최소화하며 규제 요건을 해결하려면 지리적으로 사용자와 가까운 AWS 리전을 선택함

 

 

참고

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/UsingBucket.html

 

객체 

객체는 S3에 저장되는 기본 개체

객체는 객체 데이터와 메타 데이터로 구성

메타 데이터는 객체를 설명하는 이름-값 페어의 집합 ← 마지막 수정한 날짜와 같은 몇가지 기본 메타데이터 및 Content-Type 같은 표준 HTTP 메타데이터가 포함

 

리전

AWS S3에서 사용자가 만드는 버킷을 저장할 지리적 AWS 리전을 선택할 수 있음

지연 시간 최적화, 비용 최적화, 규정 요구 사항 준수 등... 다양한 필요에 따라 리전을 선택할 수 있음

AWS 리전에 저장된 객체는 사용자가 명시적으로 객체를 다른 리전으로 전송하거나 복제하지 않는 한 해당 리전을 벗어나지 않음

예를 들어, 유럽(아일랜드) 리전에 저장된 객체는 유럽 밖으로 이동하지 않음

 

 

 

 

 

https://kaikaikai.tistory.com/95

2. AWS 기본 아키텍처 - S3에 대한 이해

 

 

https://hidekuma.github.io/aws/s3/s3-data-model/

AWS: s3의 데이터 모델

 

 

딥다이브 내용!

https://devocean.sk.com/blog/techBoardDetail.do?ID=163606

AWS S3 활용 및 단점 분석

 

 

https://aws.amazon.com/ko/s3/faqs/

Amazon Simple Storage Service(S3) – 클라우드 스토리지 – AWS

 

https://choiblog.tistory.com/186

고급 Amazon S3

 

 

S3 버킷 종류

버킷은 Amazon S3에 저장된 객체의 컨테이너

1. S3 General purpose buckets

버킷에 원하는 수의 객체를 저장할 수 있음

단일 범용 버킷에는 S3 Express One Zone을 제외한 모든 스토리지 클래스에 저장된 객체가 포함될 수 있음

대부분의 사용 사례와 액세스 패턴에 권장됨

 

2. Directory buckets

S3 디렉토리 버킷은 단일 가용 영역 내에서 더 빠른 데이터 처리를 제공하는 S3 Express One Zone 스토리지 클래스에 객체만 저장할 수 있음

지연 시간이 짧은 사용 사례에 권장됨

각 S3 디렉토리 버킷은 버킷 내 디렉토리 수에 관계없이 수십만 TPS를 (초당 트랜잭션) 지원할 수 있음 

 

 

S3 버킷에 객체는 최소 3개의 가용 영역에 걸쳐 여러 디바이스에 자동 저장

AZ는 다른 모든 AZ와 수 킬로미터에 상당하는 유의미한 거리를 두고 물리적으로 분리되어 있음

 

 

 

스토리지 관리

S3 객체 태그는 S3 객체에 적용되는 키 값 페어로, 객체의 수명 주기 동안 언제든 이를 생성, 업데이트 또는 삭제할 수 있음

참고 : 유튜브 S3 고급 활용 기법

 

객체 태그

데이터의 저장 위치가 아닌 데이터의 특성을 기반으로 데이터를 관리하기 위해서 사용

Ex) 나중에 

 

 

 

Object Key naming  관리

왼쪽 그림처럼 object들의 key 이름을 아래와 같이 동일한 패턴으로 구성한다면

오른쪽 그림처럼 Storage의 특정 Partition에 Object들이 저장이 됨

 

높은 TPS 확보를 위해 임의성이 있는 키 이름을 지정해함

아래 왼쪽 처럼 object key 이름의 시작 부분에 임의성을 추가해주면 ( hash 또는 reversed timestamp (ssmmhhddmmyy) )

오른쪽 그림 처럼 여러 partition에 저장이 되어, 나중에 조회 요청이 많거나 한번에 많은 object를 조회할 때, 조회 속도가 느려지지 않음

 

S3는 내부적으로 여러개의 파일을 저정하기 위해서 물리적으로 파일을 여러개의 디스크에 분할 저장하는데, 이 분할 하는 로직을 파일명을 가지고 해쉬를 사용한다. 그래서 파일명이 유사하게 되면, 같은 파티션(디스크)에 파일이 써지기 때문에, 하나의 파티션에 많은 물리적인 IO를 유발하고 결과적으로 성능이 떨어지게 되는 것이다.

S3는 파일명을 가지고 hashing을 하여 파일을 분산 저장한다고 했다. 더 정확하게 이야기 하면 파일명의 앞부분인 prefix를 가지고 분산 키로 사용한다.

 

S3에서 내부적으로 어떤 원리로 partitioning을 하는지는 정확하게 나와 있지 않다. 단지 prefix를 이용한다고만 나와 있는데, 최소한 파일명(또는 디렉토리명)을 다른 문자로 시작하게 하면, 골고루 파티션에 분산하여 저장할 수 있다고 가이드 하고 있다.

최소한 50 TPS 이상의 S3 IO를 요구할 경우에는 파티션을 권장하고 있다.

※     참고 : http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html

이 키 기반의 파티셔닝은 단지 S3 뿐만 아니라, NoSQL이나 HDFS와 같은 분산 파일 시스템에도 동일한 원리로 적용되기 때문에 반드시 참고하기 바란다.

 

 

 

Object Storage는 단일 Object 를 블록으로 나누지 않고 한번에 저장

데이터의 위치는 해시 함수를 사용하여 결정되므로 병목 현상을 일으킬 수 있는 lookup table 또는 기타 매핑 구성 요소가

필요하지 않음

또한 Object Storage 시스템은 효율적인 검색을 지원하고 블록 스토리지로는 불가능한 일부 관리 기능을 지원하는 풍부하고 광범위한 메타 데이터를 제공

대부분의 Object Storage 시스템에는 단일 관리자가 블록 스토리지 시스템의 관리자 보다 더 많은 데이터를 관리할 수 있는 자동화 및 자체 관리 기능이 포함되어 있음 

 

 

블록 스토리지는 낮은 대기 시간이 필요한 시나리오와 데이터에 자주 액세스해야 하는 상황에서 여전히 비용 효율적인 대안입니다. 그럼에도 불구하고 블록 스토리지에는 몇 가지 단점이 있습니다. 예를 들어 블록 스토리지는 일반적으로 더 비싸고 대규모 데이터 세트로 확장되지 않습니다. 빈번한 액세스가 필요하지 않은 비정형 데이터, 백업, 아카이브 및 기타 시나리오의 경우 오브젝트 스토리지가 더 나은 선택으로 떠오릅니다. 

오브젝트 스토리지는 단일 오브젝트 (예: 파일)를 블록으로 나누지 않고 한 번에 저장합니다. 데이터의 위치는 해시 함수를 사용하여 결정되므로 병목 현상을 일으킬 수있는 룩업 테이블 또는 기타 매핑 구성 요소가 필요하지 않습니다. 또한 개체 스토리지 시스템은 효율적인 검색을 지원하고 블록 스토리지로는 불가능한 일부 관리 기능을 지원하는 풍부하고 광범위한 메타 데이터를 제공합니다.

대부분의 개체 스토리지 시스템에는 단일 관리자가 블록 스토리지 시스템의 관리자보다 더 많은 데이터를 관리할 수 있는 자동화 및 자체 관리 기능이 포함되어 있습니다. 효율성이 높을수록 GB당 비용이 낮아집니다. 자동화 및 자체 관리에 대한 강조는개체 스토리지가 DevOps 환경에 적합하다는 것을 의미합니다.

 

ObjectIdentifier

1. Key

2. VersionId

 

 

 

 

 

 

슬라이드 자료 

https://www.slideshare.net/AmazonWebServices/deep-dive-on-object-storage-amazon-s3-and-amazon-glacier-79931704

Deep Dive on Object Storage: Amazon S3 and Amazon Glacier

 

 

https://medium.com/@heizence6626/hash-table-%EC%84%A4%EB%AA%85-62c41fcd58fc

Hash Table 설명

 

 

https://joooing.tistory.com/entry/Data-Structure-3

Data Structure(3) Hash Table(해시 테이블)