Amazon S3 part.2

S3는 저장용량이 엄청나게 큰 만큼 데이터 분석을 위한 연산 및 대규모 분석용{Data Lake(데이터 호수)} 데이터 스토어에 주로 사용한다. 주로 금용 거래 분석, 클릭스트림 분석, 미디어 트랜스코딩등의 처리를 한다.

Data Lake(데이터 호수) = 여러 곳에서 데이터가 흘러 들어와서 한 곳에 모이는것을 의미한다.

우선 한 곳에 모든 데이터를 모은 후 필요한 데이터를 ETL과정을 거친다.{추출(Extract), 변환(Transform), 적재(Load)의 과정} 데이터의 저장 및 관리를 하기 위해 중앙 집중식으로 편리하게 사용하기 위함이다.

 

이것을 만들때 온프레미스 환경에서 가장 큰 고민은 얼마만큼의 저장공간을 확보해야하는지에 대해 고민하고 이 고민은 결국 부담이 되는데 S3의 경우 용량 제한이 없기때문에 자유롭게 사용할 수 있다.

* 실제로 무제한의 용량을 제공하는것이 아닌 AWS에서 모니터링 하여 특정 리전에 S3용량을 모니터링 후 사용페턴을 분석해 시설을 늘린다. ==> 이 부분은 AWS가 해야할 일이니 사용자인 고객은 별 신경을 쓸 필요가 없다.

 

S3는 또한 백업 도구로서의 역할을 한다.

백업 데이터는 문제가 생겼을때 복구를 하기 위해 만들어 둔 데이터 이기 때문에 손상이 되거나 삭제가 되면 안된다. 즉 굉장히 내구성이 좋은 곳에 보관을 해야하는데 S3의 경우 백업기능을 활용하기 아주 훌륭하다.

 

 

S3로 데이터를 이동할때는 어떻게 이동하게 될까?

 

콘솔, CLI, SDK(개발자) ==> API ==> 모든 파일 유형 ==> 객체 수 무제한

 

사람, 어플리케이션, 서버 등이 사용자가 만든 버켓에 요청을 보내게 만들 수 있다는 의미이다. 이때 동일한 종류의 요청이라면 동일 종류의 API를 사용한다. 그리고 어떤 파일이던 무제한의 용량에 저장이 된다.

 

* SDK = 개발자가 사용한다. 내가 만든 app이 AWS로 접근해야하는데 이 방법은 API, SDK 2가지가 있다. 프로그레밍을할때 바로 API로 접근하게 하기 위해서는 굉장히 많은 양의 로직과 함수를 형성해야하는데 이것을 간편화 하게 할 수 있는게 SDK이다.

 

파일을 업로드할때 업로드 속도에 문제가 생기는 경우는 총 3가지 이다.

1. 파일 자체가 워낙 커서 업로드할때 오래걸리는 경우

이때 멀티파트 업로드 라는 기능을 활용하면 된다.

그레픽 환경의 메니지먼트 콘솔(AWS에서 제공하는 그림판 형식의 콘솔이다.)에서는 사용할 수 없다.

CLI(명령창 환경)에서 업로드를 실행하면 기본적으로 적용이 되며 SDK(코딩을할때)에 이것을 선택할지에 대한 설정을 할 수 있다.

파일 하나를 통째로 업로드 하는것이 아닌 잘게 쪼개서 병렬로 업로드 하겠다 라는 의미이다. 당연히 속도가 빨라질 수 밖에없다. 또한 이런 파일은 똑같은 속도로 업로드 되는것이 아닌 용량에따라 다르게 업로드된다. 모든 파일이 업로드 된 이 후 사용할 수 있도록 해 준다.

 

2. 네트워크 속도가 엄청 낮은 경우

예를 들어 서울리전에 버켓이 있는데 사용자는 유럽에 있어서 거리가 멀다거나 하는 등의 경우이다.

Transfer Acceleration을 활용하면된다. 거리가 멀게 되면 라우터나 스위치 등의 중단단계를 많이 거치게 되는데 그러면 당연히 속도가 줄어들 수 밖에 없다. 이럴때 이 기능을 활용하면 되는데 CloudFront 엣지 로케이션을 활용하여 사용한다. 물리적인 거리는 비슷하지만 엣지 로케이션을 활용해 전용선을 타서 훨씬 빠른 속도로 도착할 수 있도록 해 준다.

지역별로 어떤 리전에서 어떤 리전으로 가는것이 빠르고 느린지는 AWS홈페이지에서 확인할 수 있으며 같은 리전인 경우 단순 인터넷을 활용하는것이 더 빠를 수 있다. 즉 엣지로케이션이 무조건적으로 빠르다는 의미는 아니다.

 

3. 파일의 갯수가 너무 많은 경우

total파일의 수가 너무 많은 경우)의 문제가 생길 수 있다.

S3 snowball혹은 snowmobile이라는 서비스를 활용해 사용할 수 있다. 굉장히 많은 용량을 가진 파일을(온프레미스 환경) AWS로 마이그레이션 하고자 할때 주로 사용하는 서비스이다. 데이터 이전 시 굉장히 많은 시간을 할예하게 되는데 snowball은 페타바이트 규모의 데이터를 전송하도록 도와준다. 

aws snowball과 snowmobile

snowball은 1개가 약 80TB정도의 용량을 가지고 있으며 1페타 바이트의 용량을 맞추기 위해 12개의 기기가 배송이 된다. 이 기기에 데이터를 직접 연결해 업로드(카피)하여 AWS로 전송하게 되면 업로드를 할 수 있게 해 준다. 이렇게 해서도 부족할 경우 엑사바이트 규모의 Snowmobile이 온다. 최소 10개의 트레일러가 오는데 1개의 트레일러는 100PB정도의 용량을 가지고 있다.

 

아쉽게도 2021년 기준 한국에는 snowmobile 트럭이 없고 근처 다른 지역의 리전에서 운송을 해야 한다고 한다.

 

 

이런 S3는 어떨때 사용하는게 좋을까?

주로 한 번 쓰고 여러번 읽을 경우, 데이터 엑세스가 일시적으로 급증하는 경우, 사용자가 매우 많고 콘텐츠가 많을 경우, 데이터 세트가 계속 증가할 경우가 좋다. == > 즉 읽기보다 수정을 자주할때 최적화가 잘 되있다.

블록 스토리지 요구 사항이 있을때는 EBS가 제공하는 volume 혹은 instance storage등을 사용하는것이 좋다. 데이터가 자주 바뀌며 공유용 데이터가 아닐 경우 다량의 비용 발생이 될 경우 좋지도 않다. 또한 장기 아카이브 스토리지의 경우 S3 Glacier를 사용하는것이 좋다.

 

S3 Glacier(빙하)

굉장히 오랫동안 자료를 저렴하게 장기적으로 저장하기 위한 장기 저장용 스토리지 이다. 빙하 라는 이름처럼 자료를 꽁꽁 얼려서 저장할 수 있으며 이것을 다시 추출하기 위해서는 특정 장비를 사용해 빙하를 부수는것 처럼 요금을 다른 스토리지보다는 조금 많이 지불하고 자료를 추출할 수 있다.

볼트락 이라는 저장소 잠금 기능이 있는데 이것을 활용하게 되면 사용자가 만든 사용자 소유의 파일을 만들더라도 생성 이후 수정, 삭제가 되지 않는 기능이 있다. 이것은 법적 증명자료를 제출하기 위해서 이것이 켜져있다면 충분히 인정을 받을 수 있을 정도로 강력한 기능이다. 

 

빙하를 뒤지는것처럼 검색을 하기 위해서는 많은 비용이 드는데 약 5분정도 걸리는 신속검색, 5~6시간 정도 걸리는 표준 검색, 12시간 걸리는 대량검색이 있다.

 

S3의 스토리지 클래스를 구분하면 다음과 같다

Standard

평소에 자주 사용하는데이터이다.

 

Standard IA

수명이 길지만 자주 사용하지 않는 데이터를 보관한다.

 

one Zone IA

수명이 길고 자주 사용하지 않지만 엑세스를할때 아주 빠른속도가 필요한 데이터를 보관한다.

 

glacier/deep archive

거희 사용하지 않지만 보관이 필요한 데이터를 보관할때 사용한다.