5. AWS의 스토리지 서비스

IoT나 빅데이터, 기계학습 등의 IT 기술의 혁신이 이어지면서 데이터량의 증가나 데이터의 취급방법의 다양화가 진행되어 왔다. 이에 대하여 스토리지도 다양한 종류가 등장하였다. 여기서 부터는 AWS가 제공하는 스토리지 서비스에 대해 알아볼 까 한다.

데이터의 이용목적, 요건에 대한 적절한 스토리지를 선택하는 것도 솔루션 아키텍처로서 중요한 스킬이기에, 각 서비스의 특징과 차이를 제대로 알아 둘 필요가 있다.

스토리지 서비스의 분류와 스토리지 타입

AWS가 제공하고 있는 스토리지 서비스는 아래 5가지 이다. AWS 도큐먼트의 분류에는 AWS Snowball도 스토리지 서비스로 분류되어 있지만, 여기선 상세히 설명하진 않을 것이다. Snowball은 페타바이트를 넘는 초 거대 데이터를 AWS에 이행하거나, AWS에서 밖으로 보낼때에 사용하는 데이터 전송 서비스이다. 웹 서비스가 아니며, 하드웨어 어플라이언스와 데이터 전송용 클라이언트 툴이 제공되고 있다.

• Amazon EBS
• Amazon EFS
• Amazon S3
• Amazon S3 Galcier
• AWS Storage Gateway

이것 외에도 파일 서버의 서비스로 Amazon FSx가 있다. 스토리지 서비스는 일반적으로 3가지 타입으로 나눌 수 있다.

• 블록 스토리지 : 데이터를 논리적인 디스크의 블록 단위로 관리하는 스토리지이다. 데이터 베이스나 가상 서버의 이미지 보관 영역과 같이 빈번히 갱신되거나, 고속의 액세스가 필요할 때에 사용한다. AWS 스토리지 서비스중 EBS가 블록 스토리지 서비스이다.
• 파일 스토리지 : 블록 스토리지 위에 파일 시스템을 구성하여 데이터 파일 단위로 관리하는 스토리지이다. 복수의 클라이언트로 부터 네트워크를 경유하여 파일에 접근하는 등 데이터의 공유를 위해 사용하거나, 과거 데이터를 일괄 저장하거나 하는 용도로 사용된다. AWS 스토리지 서비스 중 Amazon EFS 가 파일 서비스이다.
• 오브젝트 스토리지 : 파일에 임의의 메타 데이터를 추가하여 오브젝트로서 관리하는 스토리지이다. 파일의 내용을 소티리지 내에 직접적으로 조작하는 것은 불가능하며, 작성된 데이터에 대하여 HTTP(S) 를 경유하여 등록, 삭제, 참조 등 조작은 가능하다. 갱신 빈도가 적은 데이터나 대용량의 멀티미디어 컨텐츠를 보관하는 용도로 사용된다. AWS 스토리지 서비스중에는 S3와 S3 Glacier가 오브젝트 스토리지 서비스이다.

구분	블록 스토리지	파일 스토리지	오브젝트 스토리지
관리 단위	블록	파일	오브젝트
데이터 라이프 사이클	추가, 갱신, 삭제	추가, 갱신, 삭제	추가, 삭제
프로토콜	SATA, SCSI, FC	CIFS, NFS	HTTP(S)
메타 데이터	고정 정보	고정 정보	커스터마이즈 가능
유스케이스	데이터베이스, 트랜잭션 로그 등	파일 공유, 데이터 아카이브	멀티미디어 컨텐츠, 데이터 아카이브

오브젝트 스토리지는 클라우드의 진전과 함께 주목되어 온 비교적 최신 스토리지 서비스이다. 애플리케이션으로 부터 이용을 상정한 REST API를 제공하는 서비스가 많으며, 서버리스 아키텍처를 구성하는 요소 중에서도 중요한 역할을 담당하고 있다. AWS의 오브젝트 스토리지 서비스인 S3도 AWS안에선 매우 중요한 역할의 서비스로서 위치하고 있으며, AWS내의 다양한 서비스의 백엔드로 사용되고 있다.

EBS

AWS가 제공하는 블록 스토리지 서비스이다. EBS는 Elastic Block Storage 의 줄임이다. EC2의 OS 영역으로 사용하거나, 추가 볼륨으로 복수의 EBS를 EC2에 할당하는 것도 가능하다. 앞으로 설명할 것 중 RDS의 데이터 보관용으로도 사용하고 있다.

EBS는 기본적으로 EC2에 1:1로 대응하는 서비스 이기 때문에 복수의 EC2인스턴스에 동시에 할당하는 것은 불가능했었다. 후술할 EBS 멀티 할당 기능에 의해 복수의 EC2로 부터 동시에 할당하는 것이 가능하게 되었지만 제약이 많으며 한정적인 용도로만 사용되고 있다. 또한 EBS는 작성시에 AZ를 지정하기 때문에 같은 AZ에 작성된 EC2 인스턴스로부터 만 할당할 수 있다. 다른 AZ의 인스턴스에 할당하고 싶을 경우 EBS의 스냅샷을 저장하여 스냅샷으로 부터 지정 AZ에 EBS 볼륨을 작성한 뒤 할당하는 것도 가능하다.

EBS

EBS의 볼륨 타입

SSD 타입 2종류, HDD 타입 2종류 총 4종류가 있다.

• 범용 SSD (gp2)
• 프로비전 IOP SSD (io1)
• 스루풋 최적화 HDD (st1)
• Cold HDD (sc1)

구시대 마그네틱 이라 불리는 HDD의 스토리지 타입도 있지만, 신규로 작성할 때에는 마그네틱 타입은 사용하지 않으며, 현행 볼륨 타입으로 가장 빠른 것을 선택하도록 하자, 또한 각 타입의 성능을 최대한 발휘하기 위해서는 EBS로의 액세스 최적화가 가능한 EC2 인스턴스의 이용을 추천한다.

범용 SSD (gp2)

범용 이라는 이름에서 나타나 듯 EBS중 가장 일반적인 SSD를 베이스로 한 볼륨 타입이다. EC2 인스턴스를 작성할 때에 기본적으로 사용하는 볼륨 타입이다.

성능의 지표로서 IOPS(1초당 처리 가능한 I/O 액세스 수) 를 사용하며 3IOPS/GB(최저 100IOPS)로 부터 최대 160000IOPS/볼륨 까지 용량에 대한 베이스 라인이 정해져 있다. 이 베이스라인 성능은 EBS 이용시간의 99%를 만족하도록 설계되어 있다. 또한 1TB 미만의 볼륨은 일시적인 IOPS의 향상에 대응할 수 있도록 부스트 기능이 준비되어 있으며 이용에 대하여 일정 기간 3000IOPS 까지 성능을 향상 시킬 수 있다.

베이스라인 성능이나 부스트 기능을 사용하더라도 시스템에서 필요한 IOPS를 만족하지 못할 경우에는 다음의 프로비전 IOPS 타입의 이용을 검토하는 것이 좋다.

또한 2020년 12월에 gp3이라고 하는 새로운 타입이 등장했다.

프로비전 IOPS SSD (io1)

프로비전 IOPS는 EBS중 최고의 고성능 SSD를 베이스로하는 볼륨타입이다. RDS나 EC2 인스턴스에서 데이터베이스 서버를 구성하는 경우 등의 높은 IOPS 성능이 요구될 때 이용된다.

io1은 최대 50IOPS/GB 또는 최대 64000IOPS/볼륨 까지 용량에 대한 베이스라인 성능이 존재한다. 이 베이스 라인의 성능은 EBS 이용 시간에 99.9%를 만족 시키는 설계로 되어 있으며, 또한 스루풋도 볼륨별 최대 1,000MB/s 까지 나오도록 되어 있으며 IOPS 부하가 높은 유스 케이스와 높은 스루풋이 필요한 유스케이스 양쪽을 만족시키기 위한 스토리지 타입니다.

스루풋 최적회 HDD (st1)

스루풋 최적화는 HDD를 베이스로 한 스루풋 용 볼륨 타입이다. 로그 데이터에 대한 처리나, 배치 처리의 인풋용 파일을 보관하는 등의 용도로 대용량 파일을 고속으로 읽기 위한 유스케이스에 적합하다.

스루풋(Mb/s) 을 성능 지표로 사용하고 있으며 1TB당 40MB/s 최대 스루풋은 볼륨당 500MB/s의 성능 베이스라인을 가지고 있다. 이 베이스라인 성능은 EBS의 이용 시간중 99%를 만족하도록 설계되어 있다.

Cold HDD (sc1)

4가지 스토리지 타입중 스토리지로서 성능은 크게 신경쓰지 않으나, 가장 낮은 가격으로 이용할 수 있는 볼륨 타입이다. 이용 빈도가 별로 없으며, 액세스 되더라도 성능을 크게 요구하지 않는 데이터를 순차적으로 접근하도록 유스케이스나, 아키텍처 타입 영역에서 사용하기 위한 용도이다. 1TB당 12MB/s로 볼륨댱 최대 250MB/s의 베이스 성능을 가지고 있다.

비고	범용SSD (gp2)	프로비전 IOPS SSD(io1)	스루풋 최적화 HDD (st1)	Cold HDD (sc1)
유스 케이스	EC2의 부트볼륨, 애플리케이션 리소스	I/O 부하가 높은 데이터베이스 영역	로그 분석, 배치 처리용 대용량 인풋 파일	액세스 빈도가 낮은 데이터 아카이브
볼륨 사이즈	1GB ~ 16TB	4GB ~ 16TB	500GB ~ 16TB	500GB ~ 16TB
최대 IOPS/볼륨	16,000	64,000	500	250
최대 스루풋/볼륨	250MB/s	1,000MB/s	500MB/s	250MB/s
베이스라인 성능	3IOPS/GB (최대 10IOPS)	지정된 IOPS	1TB당 40MB/s	1TB당 12MB/s
부스트 성능	볼륨당 3,000IOPS	지정된 IOPS	1TB당 최대 250MB/s	1TB당 최대 80MB
주 퍼포먼스 속성	IOPS	IOPS	MB/s	MB/s

베이스 라인 성능과 부스트 성능

프로비전 IOPS이외의 스토리지 타입에는 스토리지 용량에 대하여 베이스라인 성능이 있다 설명했다. 이런 스토리지 타입에는 베이스라인 성능과 별개로 처리량을 일시적으로 증가시키는 부스트 성능 이라는 지표가 있다. 부스트 성능은 어디까지나 일시적인 처리량을 증가시키는 것에 사용하는 것으로 상정되어 있다고 이해 하면 되고, 부스트 성능에 별도의 사이징은 하지 않도록 하는 것이 좋다.

EBS의 확장, 변경

EBS에는 용도에 응하여 타입이 나눠져 있다는 것을 이해하고 있을것이다. 한번 작성한 EBS에 대하여 어떠한 변경이 가능한지 알아보도록 하자. 지금부터 소개하는 변경은 마그네틱(구세대) 타입은 제외되며, 기본적으로는 모두 온라인 상태에서 변경 가능하다.

주의점

1. EBS 볼륨에 대하여 변경 작업을 핼할 시에 동일 EBS 볼륨으로의 변경 작업은 6시간정도 걸릴 수 있다.
2. 현행 세대 이외의 EC2 인스턴스 타입에서 사용중인 EBS 볼륨에 대한 변경 작업에는 인스턴스의 정지나 EBS 할당 해제가 필요할 경우가 있다.

용량 확장

모든 타입의 EBS는 1볼륨에 최대 16TB 까지 설정할 수 있따. 디스크 용량이 부족해지면 필요에 응하여 사이즈를 몇번이라도 확장할 수 있다. 온라인에서 사용중의 EBS의 볼륨을 확장 시킨 뒤 EC2 인스턴사 상에서 OS에 알맞는 파일 시스템의 확장 작업 (Linux의 경우 resize2fs나 xfs_grouwfs등) 을 별도 실시하여 OS측에도 인식 하도록 할 필요가 있다.

주의점

1. 확장은 가능하지만 축소는 불가능하다. 일시적인 데이터 용량의 추가 등 요건에 응하여 볼륨의 확장이 아닌 신규 EBS를 작성하여 EC2 인스턴스에 할당한 뒤 불필요해 질 경우 할당을 해제하는 방법도 검토 할 수  있따.

볼륨 타입의 변경

4가지 현생 세대 타입간의 타입 변경은 가능하다. gp2 타입에서 작성했지만, IOPS가 부족하다고 판단할 경우 io1 타입으로 변경할 수 있다는 것이다. 또한 io1 타입에 지정한 IOPS가 부족한 경우에는 추가적으로 프로비저닝을 실시하는 것도 가능하다.

주의점

1. 프로비전 IOPS 타입에서 지정한 IOPS 값에 대해선 영역의 어떤 변경도 가능하다.
2. IOPS의 변경에는 최대 24시간이상 소모되는 경우가 있다. 변경 기간중은 볼륨의 스테이터스가 Modifying이 된다. 스테이터스가 Complete가 되면 완료이다.

EBS의 가용성, 내구성

EBS는 내부적으로 AZ내에 복수의 물리 디스크에 복제가 이루어지며 AWS내에서 물리적인 장애가 발생할 경우에는 이용자가 인식하는 것은 거의 없다. SLA (Service Level Agreement)는 매월마다 이용 가능 시간이 99.99%로 설정 되어 있다.

또한 EBS에는 스냅샷 기능이 있기 때문에, 정깆거인 백업을 취득하는 것으로 필요한 시점의 상태로 되돌아 가는것도 가능하다. 데이터의 리스토어에는 스냅샷으로 부터 신규 EBS볼륨을 작성한 뒤 EC2 인스턴스에 할당하는 것으로 실행 된다.

EBS는 일반적인 하드 디스크에 비교하면 신뢰성이 높지만 그렇다고 장애가 없는 것은 아니다. 스냅샷 등 백업을 하는 운용 설계를 검토하는 것이 좋다.

EBS의 세큐리티

스토리지 자체를 암호화 하는 옵션이 있다. 암호화 옵션을 유효화 하는 것으로 볼륨 자체가 암호화 되는 것 뿐 아니라 암호화 된 볼륨으로 부터 취득한 스냅샷도 암호화 한다. 암호화 처리는 EC2 인스턴스가 가동한 호스트에서 실시하기 때문에, EBS간 데이터 송신시 데이터도 암호화 하는 특징이 있다.

이미 작성된 EBS 볼륨을 암호화 하고 싶은 경우 아래의 순서를 참고하자.

1. EBS 볼륨의 스냅샷을 취득
2. 스냅샷을 암호화
3. 암호화 된 스냅샷으로 부터 신규 EBS 볼륨을 작성
4. EC2 인스턴스에 할당하고 있는 EBS 볼륨과 교체

기존의 부트 볼륨을 암호화 한 경우에는 스냅샷에는 없는 AMI를 취득하여 AMI 복사시에 암호화를 실시하여 복사된 AMI로 부터 EC2 인스턴스를 작성하는 것으로 암호화를 가능캐 할 수 있다.

Amazon EBS 복수 할당

2020년 2월 Amazon EBS Multi Attach 라는 기능이 등장하였다. 제약이 많긴 하나 지금 까지 실현 되지 않았던 복수의 인스턴스가 하나의 EBS를 할당하는 기능이다.

EBS의 멀티 할당 요소

EBS의 복수 할당은 동일한 AZ의 인스턴스로 부터만 할당이 가능하며, 다른 AZ로 부터는 불가능하다. 또한 프로비전 IOPS (io1) 볼륨에 한하여 이용 가능하다. OS가 가진 표준 파일 시스템은 지원하지 않기 때문에 읽기 전용의 배타제약을 이용자 자신이 스스로 검토할 필요가 있다. 그것 이외의 제약도 아직 많기 때문에 사용하는 곳이 한정되어 있지만, 기능으로서 추가되었다 정도는 파악해두는 것이 좋다.

EFS

용량 무제한으로 복수의 EC2 인스턴스로부터 동시에 접근이 가능한 파일 스토리지 서비스이다.  ( EFS는 Elastic File System의 약자) 클러이언트로부터 EFS로의 접속은 일반적으론 NFS (Network File System) 프로토콜을 지원하고 있기 때문에 NFS 클라이언트를 가지고 있다면 특별한 도구를 추가적으로 설치하여 설정하는 등의 작업은 불필요하다.

amazon-efs-utils 도구를 사용하면 EFS의 마운트에 관한 옵션을 포함하고 있으며, 파일 시스템에 문제가 발생할 경우 문제 해결의 관련 로그를 기록할 수 있거나 하기 때문에 EFS에 접속하는 클라이언트로 도입하는 것을 추천한다.

EFS에는 수많은 유스케이스에 대응하기 위해 퍼포먼스 모드나 스루풋 모드 등과 같은 다양한 모드를 준비하고 있다. 잘못된 모드를 선택해 의도한 성능이 제대로 발휘되지 않을 수도 있기 때문에 제대로 된 시스템에 필요한 모드를 선택할 수 있는 것이 중요하다.

EFS의 구성요소

EFS는 아래 3가지 요소로 구성되어 있다.

• 파일 시스템
• 마운트 타겟
• 세큐리티 그룹

파일이 작성되면 자동적으로 3가지 장소 이상의 AZ에 저장되는 분산 파일 시스템을 구성한다. 저장된 파일 시스템에 접근하기 위해선 AZ 별로 서브넷을 지정하여 마운트 타겟을 작성한다. 마운트 타겟을 작성하면 타겟 포인트 ( 접속 FQDN ) 하나와 각 AZ 의 마운트 타겟용 IP 주소가 발행된다. EC2로부터 하나의 FQDN에 접속하지만, 내부적으로는 자동으로 접속처의 EC2 인스턴스와 동일한 AZ의 마운트 타겟의 IP주소가 반환하는 방식으로 레이턴시가 낮아지도록 설계되어 있다.

또한 마운트 타겟에 세큐리티 그룹을 설정할 수 있어, EC2로 부터 EFS에 통신 요건을 정의하여 불필요한 접속을 제한할 수 있다.

EFS의 구성요소

EFS의 퍼포먼스 모드

범용 퍼포먼스 모드와 최대 I/O 퍼포먼스 모드 2가지 퍼포먼스 모드가 있다. 대부분의 경우에는 범용 퍼포먼스 모드를 사용하면 문제가 없다.

하지만 수백 ~ 수천대 가량의 클라이언트로부터 동시에 EFS 에 접속이 필요한 유스케이스 ( 예를 들어 빅데이터 분석 애플리케이션에 의한 병렬 처리에 사용할 데이터를 EFS에 보관해두는 경우 ) 에도 버틸 수 있게 하기 위해 최대 I/O 퍼포먼스 모드가 준비되어 있다. 이 모드를 선택할 경우 스루풋을 최대화 하는 대신에 각 파일 조작에 레이턴시가 범용 퍼포먼스 보다 조금 더 높아진다.

 

어떤 모드를 선택하는 것이 좋은가를 판단하기 위한 지표로서 CloudWatch의 PercentIOLimit 라고 하는 메트릭스를 참고할 수 있다. 범용 퍼포먼스 모드를 선택하여 시스템의 유스케이스와 닮은 액세스 패턴으로 성능 테스트를 실시하여 PercentIOLimit가 어느정도 전이 되는가를 확인할 수 있다. 성능 테스트 실시 중 PercentIOLimit가 장시간 높은 상태 ( 80 ~ 100%)를 유지하는 경우에는 최대 I/O 퍼모먼스 모드로 변경하는 것이 좋다고 할 수 있다.

퍼포먼스 모드는 파일 시스템을 한번 작성하면 변경하지 않기 위해, 런칭하기 전에 충분히 테스트를 실시하여 어떤 모드를 선택할 지 알아봐 두는 것이 좋다.

EFS의 스루풋 모드

퍼포먼스 모드와는 별개로 2가지 스루풋 모드가 준비되어 있다. 부스트 스루풋 모드와 프로비저닝 스루풋 모드이다.

• 부스트 스루풋 모드 : EFS에 저장되어 있는 데이터 내용에 대하여 베이스라인이 되는 스루풋 설정되어 있다. 일시적인 스루풋 상한을 넘어서는 부스트 기능을 가진 모드이다. 베이스 라인의 스루풋은 1GB에 50KB/s 로 저장되어 있는 데이터양에 의해 스루풋과 기간이 설정된다. 최저 부스트 스루풋은 100MB/s이다. 1TB를 넘어서면 매일 12시간 스토리지의 1TB당 100MB/s 까지 부스트 가능한 포인트가 적립되도록 설계되어 있다.
• 프로비저닝 스루풋 모드 : 부스트 스루풋 모드로 설정되어 있는 베이스라인 스루풋을 대폭 상회하는 스루풋이 필요한 경우나, 일시적인 부스트시에 부스트 스루풋으로 설정되어 있는 최대 스루풋 보다 더 높은 성능이 필요할 경우, 임의의 스루풋 값을 지정하는 것이 가능한 스루풋 모드이다. 용량에 의존하지 않고 최대 1GB/s 까지 스루풋을 지정할 수 있다. 그 이상의 스루풋이 필요할 경우에는 제한의 해제 신청이 가능하다. 이 모드는 웹 발신용의 컨텐츠나 애플리케이션의 데이터와 같은 데이터 사이즈는 그렇게 크지 않지만, 액세스가 많거나, 동시에 다수의 인스턴스로 부터 접속이 이뤄지거나 하는 등의 데이터를 EFS에 배최되는 경우에 최적이다.

파일 시스템 사이즈 (GB)	베이스라인 스루풋 (MB/s)	부스트 스루풋 (MB/s)	최대 부스트 기간(분/일)
10	0.5	100	7.2
256	12.5	100	180
512	25.0	100	360
1024	50.0	100	720
1536	75.0	150	720
2048	100.0	200	720
4096	200.0	400	720

어떤 스루풋 모드를 선택하는게 좋을 지 알아 볼 수 있는 지표로서 CloudWatch의 BurstCreditBalance라고 하는 메트릭스를 참고할 수 있다. 크레딧 밸런스를 모두 사용해버리거나, 평소에 감소하는 경향이 있는 경우에는 프로비저닝 스루풋 모드를 선택하도록하자. 스루풋 모드는 EFS 운용중에도 변경 가능하다.

프로비저닝 스루풋에서 지정 가능한 스루풋 값은 증감 모두 선택할 수 있다. 스루풋 모드의 변경, 또는 프로비저닝 스루풋 모드로의 스루풋 값의 삭감은 이전의 작업으로부터 24시간 이상 경과할 경우 검토가 필요하다.

S3

Amazon S3는 매우 우수한 내구성을 가진 용량 무제한의 오브젝트 스토리지 서비스이다. S3 는 (Simple Storage Service의 약자 ) 파일 스토리지와 다른 점으로는 디렉토리 구조를 가지지 않는 플랫한 구성과, 유저가 독자적으로 데이터에 대하여 정보( 메타 데이터 )를 부여할 수 있는 것을 들 수 있다.

S3의 각 오브젝트에는 REST나 SOAP 라고 하는 HTTP를 기반으로 하는 Web API를 사용한 액세스가 가능하다. 이용자가 데이터를 저장하기 위해 이용하는 것만 아니라 EBS 스냅샷의 저장 장소로도 사용되거나 하는 등, AWS 백엔드 서비스로도 사용하고 있으며, AWS 중에서도 매우 중요한 서비스로서의 위치를 가지고 있다. 유연성이 매우 강한 서비스 이기 때문에 아이디어만 있다면 수만가지의 방법으로 사용할 수 있다. 주로 사용되는 상황은 아래와 같다.

• 데이터 백업
• 빅 데이터 분서용 데이터 레이크
• ETL( Extra Transform Load) 의 중간 파일 저장
• Auto Scaling 구성의 EC2 인스턴스나 컨테이너로 부터의 로그 전송
• 정적 컨텐츠의 호스팅
• 간략한 Key-Value 형식의 데이터 베이스

대량/초대용량, 장기간 저장하고 싶음, 없어지면 곤란함 등과 같은 데이터를 취급하고 있을 경우 우선 S3를 사용하는 것이 어떨지 검토하는 것에서 부터 시작할 수 있다.

S3의 구성요소

• 버킷 : 오브젝트를 저장하기 위한 영역이다. 버킷명은 아카운트 명이나 리전에 관련 없이 AWS에서 유니크할 필요가 있다.
• 오브젝트 : S3에 격납된 데이터를 일컫는다. 각 오브젝트는 키 (오브젝트 명)가 부여되며 [버킷명 + 키명 + 버전 ID] 로 유니크한 URL 이 만들어진다. 버킷내에 저장되어 있는 오브젝트 수에 제한은 없지만 하나의 오브젝트 사이즈는 최대 5TB이다.
• 메타 데이터 : 오브젝트를 관리하기 위한 정보이다. 오브젝트의 작성 일시나, 사이즈 등의 시스템으로 정의된 메타 데이터 뿐만 아니라 애플리케이션에서 필요한 정보를 유저가 정의한 메타 데이터로 저장하는 것도 가능하다

S3의 내구성과 정합성

S3에 저장된 데이터는 복수의 AZ 또는 AZ내의 복수의 물리적인 스토리지에 분산된다. 이것에 의해 높은 내구성을 기대할 수 있다. 데이터의 복제 방식에는 S3는 결과정합성방식(Eventual Consistency)을 채용하고 있다. 그렇기 때문에 데이터의 저장후 복제가 완전히 끝날 때 까지 데이터를 참조하거나 할 경우 저장 전의 데이터의 상태가 표시되거나 하는 경우가 있기 때문에 이점을 주의해야 한다.

스토리지 클래스

S3에 높은 내구성이 있지만, 그중에서도 용도에 따라 5가지 랭크 ( 스토리지 클래스 ) 로 나누어 질 수 있다. 또한 다음의 각각은 내구성과 가용성성은 설계상의 성능으로, 가용성에는 SLA (Service Level Agreement) 가 설정되어 있다.

• S3 표준 : 기본 스토리지 클래스이다. 낮은 레이턴시와 높은 스루풋을 견딜 수 있다면 가장 S3의 기능에 충실한 클래스이다.
  • 내구성 : 99.999999999%
  • 가용성 : 99.99%
• S3 표준 - 저빈도 액세스 : S3 표준에 비해 저장 코스트가 저렴한 스토리지 클래스이다. 참조 빈도가 낮은 데이터를 위해 설계된 클래스 이기 때문에, 데이터에 대한 접속은 항상 가능하지만 데이터의 읽는 용량에 대해 과금이 발생한다. 고속의 액세스가 필요하지만 그렇게 빈번하게 액세스 하진 않는.. 등과 같은 데이터를 저장해두는 경우 최적의 랭크이다.
  • 내구성 : 99.999999999%
  • 가용성 : 99.99%
• S3 1존 - IA : 단일 AZ 내에만 데이터를 복제하는 스토리지 클래스이다. 높은 내구성을 발휘하지만 AZ 단위로 장애가 발생한 경우에 데이터의 복원이 불가능할 수도 있다. 그것 이외에는 S3 표준 - 저빈도 액세스와 같은 서비스 사양이다. 내구성은 일레븐 나인이지만, 하나의 AZ 내의 내구성이기 때문에 저장하고 있는 AZ에서 데이터 소실을 상반하는 장애가 발생할 경우 데이터를 잃게 된다.
  • 내구성 : 99.999999999%
  • 가용성 : 99.5%
• S3 - Intelligent - Tiering : 참조 빈도의 높고 낮음을 명확하게 정하는 것이 불가능한 데이터를 다루는 경우 유효한 스토리지 클래스이다. S3 표준과 S3표준 - 저빈도 액세스의 2층 구성으로 이루어져 있으며 30일 이상 참조되지 않을 경우 데이터는 자동적으로 S3 - 표준 - 저빈도 액세스로 이동된다. 다음에 이야기할 [ 라이프 사이클 관리 ] 를 자동화 되는 반면 빈번히 이동이 발생하는 경우에는 코스트가 높아지는 경우도 있다.
  • 내구성 : 99.999999999%
  • 가용성 : 99.9%
• S3 Glacier : 거의 참조 되지 않는 아카이브 목적의 데이터를 저장하는 스토리지 클래스이다. 오브젝트 신규 작성시에 이 클래스를 선택할 순 없다. S3 Glacier이외의 스토리지 클래스를 선택하여, 후술하는 라이프 사이클 관리 기능을 사용하여 이 스토리지 클래스를 지정하는 것으로 이용 가능하다. S3 Glacier 클래스에 저장된 데이터에 액세스하는 경우에는 사전에 액세스 리퀘스트를 해둘 필요가 있으며, 액세스 가능하도록 하는데 수시간이 걸린다. 오브젝트는  S3 Glacier에 저장되지만 계속해서 S3에서 관리하는 오브젝트이며 S3 Glacier를 이용하여 직접 액세스하는 것은 불가능하다. 데이터를 불러오는데에는 몇분부터 표준으론 3 ~ 5 시간이 소모된다. 일괄적으로 불러대는데는 대량의 데이터일 경우 5 ~ 12시간 정도 소모된다.
  • 내구성 : 99.999999999%
  • 가용성 : 99.99%
•  S3 Glacier Deep Archive : S3 Glacier과 같은 사양의 아카이브 용도의 스토리지 클래스이다. S3 Glacier보다 더욱 더 액세스 빈도가 적은 데이터를 상정하여 데이터의 취득에도 더 많은 시간이 소모된다. 데이터의 추출에는 기본 12시간 이내, 전체를 추출할 경우 데이터의 양에 따라 12 ~ 48시간 까지 소모된다. 하지만 GB당 스토리지 표준 가격은 더욱더 저렴해지며, S3 Glacier에 비해 최대 75% 저렴하다
  • 내구성: 99.999999999%
  • 나용성 : 99.99%

라이프 사이클 관리

S3에 저장되어 있는 오브젝트는 해당 이용 빈도에 대하여 라이프 사이클을 정의하는 것이 가능하다. 라이프 사이클 설정에는 다음중에 설정 가능하다.

• 이행 액션 : 데이터의 이용 빈도에 응하여 스토리지 클래스를 변경하는 액션이다. 예를 들면 오브젝트 작성 당시엔 액세스 빈도가 높았지만, 일정 시간이 경과하면 이용 빈도나 중요도가 낮아져 마지막에는 아카이브로 저장해두는 등과 같은 라이프 사이클에 대하여 최적의 스토리지 클래스 이행이 가능하다.
• 유효 기간 액션 : 설정된 기간을 넘어간 오브젝트를 S3로 부터 삭제하는 액션이다. 이용 기간이 정해져 있는 오브젝트나 일시적으로 작성된 오브젝트 등을 정기적으로 정리하는 것이 가능하다. S3는 용량 무제한의 스토리지 서비스 이지만, 저장 용량에 의해 종량과금이 되기 때문에 불필요한 데이터는 정기적으로 삭제하는 것도 코스트 절감의 일부분이다.

버저닝 기능

버저닝 기능을 휴효화 하는 것으로 하나의 오브젝트에 대하여 복수의 버전을 관리하는 것이 가능하다. 버저닝은 버킷 단위로 유효/무효를 지정할 수 있다. 버저닝된 오브젝트는 Diff관리되는 것이 아닌 신, 구 오브젝트의 양쪽이 저장되며, 버전 ID로 구분된다. 그렇기 때문에 두 버전분의 저장 용량이 필요로 하게 된다.

Web 사이트 호스팅 기능

S3에는 정적인 컨텐츠에 한하여, Web 사이트로서 호스팅 하는 환경을 작성할 수 있다. 동적인 컨텐츠의 론칭은 보통 S3의 이용과 같이 S3버킷에 저장하는 것으로 이루어 진다.

Ruby, Python, PHP, Perl 등과 같은 서버사이드의 동적인 컨텐츠에 대하여 S3의 웹사이트 호스팅을 이용할 순 없다. 동적인 컨텐츠의 웹 호스팅이 필요할 경우에는 EC2로 독자의 웹 서버를 작성하는 등의 방법이 있다.

독자 도메인으로 S3 웹 사이트 호스팅 하는 경우의 주의점

S3의 웹사이트 호스팅을 설정할 경우 자동적으로 도메인 (FQDN)이 작성된다. 해당 사이트에 독자 도메인 ( 예를 들어 www.example.com) 에 액세스 하고 싶을 경우에는 Route 53 등의 DNS에 CNAME 정보를 설정한다. 이 경우 버킷명도 www.example.com 으로 작성해야 한다. S3의 앞단에 CloudFront를 배치하는 경우엔 버킷명과 도메인 명을 동일하게 설정할 필요는 없다. 

버킷명과 도메인 명을 일치 시켜야함

S3의 액세스 관리

S3의 액세스 관리는 버킷 폴리시, ACL, IAM 등이 사용된다. 각각의 방법이 어느 단위에 액세스 제한이 가능한 지 표로 살펴볼 수 있다.

구분	버킷 폴리시	ACL	IAM
AWS 아카운트 단위의 제한	○	○	☓
IAM 유저 단위의 제한	△	☓	○
S3 버킷 단위의 제한	○	○	○
S3 오브젝트 단위의 제한	○	○	○
IP 주소, 도메인 단위의 제한	○	☓	○

• 버킷 폴리시 : 버킷 단위의 액세스를 제한 한다. 해당 버킷에 저장된 오브젝트 모두에 적용되기 때문에 버킷의 용도에 상응하여 전체적인 액세스 제한을 하고자 할 때 유용하다.
• ACL : 오브젝트 단위의 공개 / 비공개를 제어하는 경우 사용된다.
• IAM : 유저 단위로 S3의 론칭을 제한하는 경우에 사용된다.

버킷 폴리시의 IAM 유저 제한은 IAM 유저의 명찰과 일치하는 버킷만 이용 가능하도록 조금 특별한 유스케이스를 만족시키기 위한 제한 방법이기 때문에 IAM 유저에 대하여 제한을 행하는 경우는 IAM 폴리시를 이용하는 것이 좋다.

서명된 URL

S3의 액세스 관리로스 버킷 폴리시나 ACL, IAM 등과 같은 제한 방법을 앞서 설명했다. 서명된 URL은 액세스를 제한 하고 싶은 오브젝트에 대하여 기한을 정하여 URL을 발행하는 기능이다. 버킷 이나 오브젝트로의 액세스 제한을 변경하는 것이 아닌 특정 오브젝트에 일시적인 액세스를 허가하고 싶을 경우 많이 유용하다.

또한 기능은 유저 제한이 아니며 서명된 URL을 알고 있다면 기간중엔 누구든 액세스가 가능하다. 이 점을 주의할 필요가 있다.

데이터의 암호화

S3에 저장된 데이터는 암호화 되어 있다. 암호화 방식은 서버측에서의 암호화와 클라이언트 측의 암호화 2종류가 선택 가능하다. 서버측 암호화 에는 데이터가 스토리지에 작성될 때에 암호화 되며 읽어 들일 때에 복호화 된다.

클라이언트 측 암호화는 AWS SDK를 사용하여 S3에 전송되기 직전에 데이터가 암호화 된다. 복호화는 클라이언트 측에서 암호화 된 데이터의 메타 데이터로 어떤 키로 복호화 하는가 판별되며 그것에 응하여 오브젝트가 복호화 된다.

S3의 블록 퍼블릭 액세스 기능과 S3 Access Analyzer

AWS는 세큐리티의 우선순위가 굉장히 높으며, 그를 위해 다양한 기능을 가지고 있다. 하지만 제대로 설정이 되어 있지 않기 때문에 사고가 일어나는 것 또한 사실이다. 그 사건들 중 하나로 의도하지 않은 S3 버킷의 외부 공개에 따른 정보 누수가 있다. 이 대책으로 2018년 11월에 등장한 기능이 S3의 블록 퍼블릭 액세스 기능이다.

이 기능은 신규, 임의의 ACL 또는 버킷 폴리시, 4단계로의 퍼블릭 액세스를 금지하는 설정이 가능하다. 거기다 신규 버킷 작성은 기본적으로 퍼블릭 액세스를 블록하도록 하고 있다. 블록 퍼블릭 액세스 이외에도 S3 Access Analyer 로 S3 버킷의 감시, 보험이 가능하도록 되어 있다. 이렇듯, S3는 꽤나 안전에 대하여 중심을 두는 설계를 행하고 있다. 블록 퍼블릭 액세스 기능을 유효화 하는 것과 함께 어떤식으로 움직이는지 확인해두도록 하자.

S3 그외의 기능

S3에는 지금 까지 소개한 기능 뿐 아니라 더 많은  기능이 있다. 모든 것을 소개할 순 없기 때문에 S3 Select 와 Transfer Acceleration 에 대해 설명해 보자면

• S3 Select : SQL 문을 이용하여 S3 오브젝트의 컨텐츠를 필터링 하여 필요한 데이터만 취득하는 기능이다. 필요한 데이터만 취득할 수 있기 때문에 전송하는 데이터 양을 삭감할 수 있다. 이것으로 인해 코스트와 시간의 단축도 노릴 수 있다.
• S3 Transfer Acceleration : 진원지의 S3로의 데이터 전송을 서포트하는 기능이다. 예를 들어 일본으로 부터 해외 리전의 S3에 전송을 할 경우, 회선의 충분한 영역과 안정성이 없으면 전송에 시간이 걸린다. S3 Transfer Acceleration 은 CloudFront 의 엣지 로케이션을 활용하여 유저에게 최단 거리 엣지 로케이션에 전송하여 다음은 AWS의 대용량이며 안정적인 백본 회선을 이용하여 데이터를 전송할 수 있다.

최고의 서비스 중 하나인 S3에 대하여 매년 다양한 기능이 확장되고 있다. 합리적인 아키텍처 설계를 위해선 이러한 기능들을 반드시 파악해 둘 필요가 있다.

S3 Glacier

S3와 동일한 사양의 99.999999999%의 내구성을 가지면서 더욱더 용량별 비용을 저렴하게 설정 가능한 아카이브 서비스이다. S3 Glacier에 데이터를 저장하면 데이터의 추출에 시간이 걸린다. 또한 S3와 같은 저장하는 데이터에 대하여 추가적으로 메타 데이터를 부여하는 것은 불가능하며 자동으로 부여되는 아카이브 ID로 관리할 수 있다.

이것들로 S3 Glacier는 온프레미스 환경에서의 자기 테이프와 같은 장기간 저장하여 액세스 빈도가 낮고, 추출에 어느정도 시간이 걸려도 상관없는 데이터를 저장하는 유스케이스에 응한다. S3 Glacier 로의 데이터의 저장은 API에 의한 조작이 S3의 라이프 사이클 관리에 의해 행해진다.

애초에  Glacier는 S3와 별개로 독립된 서비스였지만, S3와 조합하여 이용되는 경우가 많아져 Amazon S3 Glacier로 이름을 변경하여 S3의 스토리지 클래스중 하나로 위치하게 되었다.

S3 Glacier의 구성요소

아래 4가지 구성요소로 구성된다. 기본적인 구성은 S3와 동일하기에 S3에 없는 것들만 나열해 보자면

• 볼트 : 아카이브를 저장하기 위한 영역이다. S3의 경우 오브젝트에 상응한다. 볼트명은 리전 또는 아카운트 내에서 유니크 해야 하며 다른 아카운트에서 이용하고 있다고 해도 사용 가능하다.
• 아카이브 : S3 Glacier에 저장된 데이터 자신이다. S3의 오브젝트에 상응한다. 각 아카이브에는 유니크한 아카이브 ID 와 해당 항목에 대한 설명이 부여된다. 아카이브 ID는 138비트의 랜덤 문자열이 자동적으로 부여된다. 이용자가 지정할 순 없다.
• 인벤토리 : 각 볼트에 저장되어 있는 아카이브의 정보 ( 사이즈, 작성일, 업로드시에 지정된 아카이브 설명 등)을 수집한다. 또한 1일 1회의 빈도로 갱신을 하고 있기에, 최신의 정보가 반영되기 전까지 시간 지연이 있다. 리얼 타임으로 상태를 확인하고 싶은 경우 매니지먼트 콘솔에서 확인 하던가 ListVault API로 호출할 수 있다.
• 잡 : 아카이브나 인벤토리에 대하여 검색을 하거나, 데이터를 다운로드 하는 등의 요구에 대하여 처리를 실행하여 처리 상태를 관리한다.

데이터 추출 옵션

S3 Glacier에 아카이브 된 데이터를 관람하기 위해선 데이터의 추출 리퀘스트를 보내야한다. 추출 리퀘스트를 날란 뒤 실제 추출 될 때까지 대기 시간에 대하여, 고속, 표준, 벌크 3종류의 리퀘스트 옵션이 있다.

대기 시간이 짧을 수록 추출이나 리퀘스트에 드는 비용이 비싸진다. 다음날에 봐도 상관 없을 경우엔 [벌크] 옵션을 이용하도록 하자.

S3 Glacier

보통 S3 Glacier에 저장되어 있는 데이터를 참조하기 위해선 대상 아카이브를 읽는 처리를 리퀘스트 한 뒤 일정 시간 기다릴 필요가 있다. S3 Glacier Select는 아카이브 데이터에 대하여 SQL 문을 이용하여 조건에 일치하는 데이터를 검출하는 기능이다.

대상의 아카이브 데이터는 비 압축 CSV 형식이어야만 하는 조건이 이었지만, 특정 데이터만 아카이브로 부터 간단히 추출하는 것이 가능하다.

S3 Glacier Select

데이터의 암호화

S3 Glacier에 데이터를 저장할 때에는 SSL을 사용한 데이터 전송이 이뤄진다. 또한 S3 Glacier에 저장된 데이터는 표준으로 암호화 되어 있다. 독자의 암호화 방식으로 데이터를 암호화 하고 싶은 경우 S3 Glacier에 저장하기 전에 데이터를 암호화 해야 한다.

삭제 금지 기능 ( 볼트 락 )

컨프라이언스 상의 이유로 아카이브된 파일의 변경, 삭제를 불가능 하도록 하는 요건이 있을 경우가 있다. 해당 경우의 해결 방법중 하나로 S3의 버킷 폴리시나 IAM의 권한을 설정하는 것으로 기능에 대한 제한을 하는 방법이 있다. 또 하나 생각할 수 있는 방법으론 S3 Glacier의 삭제 금지 기능(볼트락)을 이용하여 AWS의 기능을 사용하여 삭제 불가능 하도록 하는 방법이 있다.

볼트 락 은  S3 Glacier API를 이용하여 볼트 락 폴리시를 대상이 되는 볼트 ( 아카이브 격납을 위한 컨테이너 ) 에 요구하는 것으로 시작한다. 볼트락 폴리시는 예를 들어 5년 경과할 때 까지 유저가 아카이브를 삭제하는 제한을 거부하는 것과 같은 내용이다. 폴리시가 볼트와 관련 되어 있는 경우 볼트락은 InProgress의 상태가 되며 록 ID 가 반환된다. 유저가 이 록 ID를 사용하여 볼트 락의 개시를 요구하도록 처리가 왼료되며, 그 후 변경, 삭제가 불가능하다. 또한 InProgress 상태로 24시간을 방치할 경우 자동적으로 록 처리는 중단된다.

Storage Gateway

AWS Storage Gateway는 온프레미스에 있는 데이터를 클라우드에 전송하기 위한 입구로 제공하는 서비스이다. Storage Gateway를 사용하여 연동된 데이터의 저장처로는 앞서 설명한 S3나 S3 Glacier와 같은 내구성이 높고 코스트가 낮은 스토리지가 이용된다. 또한 상세는 후술 하겠지만 Storage Gateway의 캐시 스토리지로서 EBS가 사용된다.

이렇듯 Storage Gateway는 서비스로서 독자의 스토리지를 가지고 있는 것은 아니다. 지금 까지 설명해온 스토리지를 조합하여 온프레미스와 AWS 간의 데이터 연동을 용이하게 하기 위한 인터페이스를 제공하는 서비스라고 할 수 있다.

온프레미스와의 하이브리드 환경이며, 참조 빈도가 높은 데이터는 온프레미스의 고속 스토리지에 저장하며 참조 빈도가 낮은 데이터나 백업 데이터는 Storage Gateway를 이용하여 클라우드에 보관하는 등으로 사용법을 나누는 것도 가능하다. 그것을 위하여 이용 목적을 명확히 하는 것으로 대용량의 데이터를 효율 적으로 관리할 수 있다.

Storage Gateway는 VMWare나 hyper-V의 가상 어플라이언스가 이미 존재할 경우에는 간단히 도입할 수 있다. 또한 EC2 인스턴스의 Storage Gateway영 AMI를 준비해두고 있기 때문에 AWS 상에서 게이트웨이를 배치하는 구성도 가능하다.

온프레미스 환경의 배치

AWS 배치

Storage Gwateway 의 타입

Storage Gateway에는 파일 게이트웨이, 볼륨 게이트웨이, 테잎 게이트웨이 3종류의 게이트웨이가 준비되어 있다. 볼륨 게이트 웨이에는 캐쉬 형 볼륨과 관리형 볼륨의 2가지 볼륨 관리 방법이 있다.

• 파일 게이트 웨이
• 볼륨 게이트 웨이
  • 캐쉬형 볼룸
  • 보관형 볼륨
• 테잎 게이트웨이

데이터의 참조 빈도나 실 데이터의 배치 장소의 차이등의 요소에 의해 최적의 게이트 웨이를 선택 하도록 하자.

타입		배치되는 곳	S3의 저장 단위	S3에 저장되는 타이밍	프라이머리 데이터의 저장 장소	파일 캐쉬	클라이언트 인터페이스	S3 API 로부터의 액세스
파일		온프레미스, EC2	파일	비동기, 거의 리얼타임	S3	있음 (일부)	NFS V3, V4.1	가능
볼륨	캐쉬형	온프레미스, EC2	볼륨	비동기, 거의 리얼타임	S3	있음 (일부)	iSCSI	불가능
	보관형	온프레미스	볼륨	비동기, 거의 리얼타임	로컬 디스크	있음(일부)	iSCSI	불가능
테잎		온프레미스, EC2	가상 테잎	비동기, 거의 리얼타임	로컬 디스크	없음	iSCSI	불가능

파일 게이트웨이

S3 의 클라이언트 서버로부터 NFS 마운트하여 사용하는 파일 시스템과 같은 취급이 가능한 타입의 게이트웨이.

작성된 파일은 비동기가 아니나. 거의 리얼타임으로 S3에 업로도 된다. 업로드 된 파일은 1 파일당 S3의 오브젝트로서 취급되며, 저장된 데이터에 S3 API를 이용하여 액세스 하는 것도 가능하다.

 

주의점 으로는 데이터의 쓰기나 읽기 속도가 로컬 디스크보다 느리다는 점이다. 보관 후의 데이터에 대하여 S3의 웹 API로 액세스 하는 등의 유스케이스에 주로 사용되는 타입이다. 혹시 간단한 NFS 서버로의 윳케이스 일 경우 EFS등 별도의 서비스를 검토하는 편이 좋다.

파일 게이트 웨이의 구성

볼륨 게이트 웨이

데이터를 S3에 저장하는 것은 파일 게이트웨이와 동일하지만, 각 파일을 오브젝트로서 관리하는 것이 아닌 S3의 데이터 보존 영역 전체를 하나의 볼륨으로 관리한다. 그렇기 때문에 S3에 저장된 데이터에 S3의 API를 이용하여 액세스하는 것은 불가능하다. 클라이언트 서버로부터 이 타입의 게이트웨이에 접속하는 방법은 NFS가 아니고, iSCI 접속이 된다. 볼륨은 스냅샷을 취득할 수 있기 때문에, EBS를 작성하여 EC2 인스턴스에 물리는 것으로 스냅샷을 취득한 시점 까지의 데이터에 액세스 하는 것이 가능하다.

• 캐쉬형 볼륨 : 빈번히 사용하는 데이터는 Storage Gateway내의 캐쉬 디스크 (온프레미스)에 저장하여 고속으로 액세스 가능하도록하며, 모든 데이터를 저장하는 스토레지 (프라이머리 스토리지)로 S3를 이용하는 타입의 볼륨 게이트웨이이다. 데이터 양이 많아져도 로컬 디스크를 확장할 필요가 없으며, 효율적으로 대용량의 데이터를 관리할 수 있다. 캐쉬상에 존재하지 않는 데이터에 액세스할 경우에는  S3로 부터 취득할 필요가 있기 때문에, 데이터를 빠르게 읽어 들이는 게 중요한 시스템에는 적당하지 않다.
  캐쉬형 볼륨 게이트웨이 타입에는 캐쉬 볼륨과, 업로드 버퍼 볼륨에 스토리지를 사용한다. 온프레미스의 경우엔 가상 Appliance 가 실행되는 환경에 있는 스토리지를 이용하여 AWS에 Storage Gateway를 구성하는 경우에는 EBS를 이용한다. 캐쉬 볼륨은 빈번히 사용하는 데이터에 관하여 고속의 액세스를 허용하기 때문에 업로드 버퍼 볼륨은 S3에 업로드 하는 데이터를 일시적으로 보관하기 위한 것이다.

캐쉬형 볼륨 게이트웨이 구성

• 보관형 볼륨 : 모든 데이터를 보관하는 스토리지 ( 프라이머리 스토리지) 로서 로컬 스토리지를 이용하며 데이터를 정기적으로 스냅샷 형식으로 S3에 전송하는 타입의 볼륨 게이트웨이 이다. S3에 전송된 스냅샷은 EBS로 되살릴 수 있기 때문에 필요에 따라선 EC2 인스턴스에 할당하는 것으로 데이터를 참조할 수도 있다. 모든 데이터가 로컬 스토레지에 저장되기 때문에 데이터에 대한 액세스 속도는 Storage Gateway 도입에 비해 변하는 것이 없다. 온프레미스의 데이터를 정기적으로 클라우드에 백업하는 용도로 주로 사용된다.

보관형 볼륨 게이트웨이 구성

테잎 게이트웨이

테잎 디바이스 대신으로  S3나 S3 Glacier에 데이터를 백업하는 타입의 게이트웨이이다. 물리 테잎 카트리지를 교체하거나 원격지에 offsite저장하는 것과 같은 것을 할 필요가 없다.  서드파티 형의 백업 애플리케이션과 조합하는 것이 가능하기 때문에 이미 백업된 테잎 타입을 이용하고 있는 경우 비교적 간단히 Storage Gatway로 이행할 수 있다.

테잎 게이트웨이 구성

Storage Gateway의 세큐리티

Storage Gateway의 세큐리티 요소에는 다음 3가지가 있다.

• CHAP 인증 : 클라이언트로부터 Storage Gateway에 iSCI로 접속할 때 CHAP 인증을 설정하는 것이 가능하다.  CHAP 인증을 설정하는 것으로 부정의 클라이언트로 부터의 접근을 미연에 방지할 수 있으며, 또한 통신의  도청이라 할 위협에 대한 리스크를 줄일 수 있다.
• 데이터 암호화 : Storage Gateway에는 AWS KMS릴 사용하여 데이터의 암호화가 가능하다. 암호화된 타이밍은 데이터가 저장된 타이밍 이기 때문에 S3에 저장된 타이밍에 암호화 된다. 또한 암호화된 볼륨으로 부터 취득한 스냅샷도 같은 키로 암호화 되어 있다.
• 통신의 암호화 : 온프레미스 환경에서  Storage Gateway를 경유하여 S3에 데이터를 전송할 경우에는 HTTPS가 사용되기 때문에 통신시의 데이터 내용은 암호화 된다.

FSx

스토리지 종류

지금까지 파편적으로 소개했지만 스토리지에는 요옫, 형태 별로 몇가지의 종류가 있다. 대표적으론 블록 스테리지, 파일 스토리지. 오브젝트 스토리지 이다.

블록 스토리지

기록 영역을 볼륨이라고 하는 단위로 분별하여 블록이라는 단위로 호출하는 스토리지이다. 하드디스크는 블록 스토리지의 물리적 실체라 할 수 있다. 하드 디스크의 경우에는 물리적인 단위로 제약되지만. 클라우드의 블록 스토리지는 백엔드의 스토리지를 논리적으로 통합하여 필요한 사이즈를 자유롭게 사용하는 것이 가능하다. 블록 레이어나, 인간이 직접 사용하는 것 보다 OS가 관리하는 것 같은 낮은 레이어의 스토리지 이다,

파일 스토리지

데이터를 파일과 폴더로 나눠진 계층적 구조로 관리한다. 이것은 흔히 말하는 파일 서버와 같은 이미지이다. 유저는 스토리지 상의 데이터를 개별의 파일 단위로 관리한다. Windows나 Linux등의 OS를 이용하여 다루는 것이 파일 스토리지이며, 그것을 네트워크를 통하여 관리하는 것이 NAS (Network Attached Storage)이다.

오브젝트 스토리지

데이터를 오브젝트라는 단위로 관리하는 스토리지이다. 데이터를 파일이라고 하는 단위로 관리하는 파일 스토리지와 닮아 있지만. 오브젝트 스토리지에는 오브젝트를 일괄적으로 관리하는 식별 ID와 그것을 관리하는 메타 데이터로 구성되어 있다. 파일 스토리지와 같은 계층적인 구조가 아닌 플랫한 구조로 관리하고 있기 때문에, 확장성이 매우 뛰어난 메리트가 있으며, 데이터에 액세스하는 것도 일반적인 RESTFul API를 이용하여 행해진다. 다른 2가지의 스토리지와는 별개로 애플리케이션적이 면이 강한 스토리지이다.

FSx

풀 매니지드한 파일 스토리지이다. Windows를 위한 비즈니스 애플리케이션등을 이용하는 Amazon FSx for Windows  파일 서버와, 하이 퍼포먼스 컴퓨팅을 위한 Amazon FSx For Lustre 2종류의 스토리지가 있다,

FSx for Windows 파일 서버

이름대로 Windows용 서비스이며, 풀매니지드 한 Windows의 파일 서버로 사용한다. Windows Server 사에서 동작하기 때문에 Windows에서 이용간으한 유저쿼터, 엔드유저 파일 복원, Microsoft Active Directory (AD) 통합 등의 활용도 넓은 기능을 이용할 수 있다. FSx for Windows는 단일 서브넷의 엔드포이늩가 되는 ENI (Elastic Network Interface)를 배치하여 해당 엔드포인트에는 SMB프로토콜을 이용하여 액세스할 수 있다. ENI에는 세큐리티 그룹을 적용할 수 있기 때문에, 이것을 이용하여 네트워크 적인 제한을 가하는 것도 가능하다.

또한 풀 매니지드 서비스 이기 때문에 Windows Update나 각종 배치 작업과 같은 멘테넌스는 AWS 측에서 행한다. 또한 스토리지 사이즈나 스루풋 등의지정, 변경 등이 가능하다.

FSx for Lustre

풀매니지드 한 분류의 파일 시스템에 S3와 심리스로 통합 간으하다. Lustre는 for Windows보다 특수한 아키텍처를 지니고 있다. Lustre 는 파일 시스템 작성시에 S3 버킷과 연동된다. 그리고 S3상의 파일을 인덱스하여 마치 파일과 같이 보이게 한다. S3로 부터 데이터를 취득하기에 느리지만, 이후엔 캐싱하기 때문에 고속으로 접근이 가능하다. 빠른 속도의 데이터 액세스가 필요한 하이 퍼포먼스 컴퓨팅에 이용되며, 기계학습이나 빅데이터 처리등에 사용된다.

ENI를 이용한 엔드 포인트를 만들땐, 풀매니지드 서비스라는 점은 for Windows와 같다. Lustre는 Linux용 서비스로, 이용시에는 전용 클라이언트 소프트를 인스톨 할 필요가 있다. 이스톨 후에는 보통의 NAS와 같이 마운트 하여 이용할 수 있다.

스토리지 종류와 AWS 서비스의 맵핑

스토리지 종류	서비스 명	개요
오브젝트 스토리지	S3	네트워크 경유로 이용하는 오브젝트 스토리지
	S3 Glacier	S3의 스토리지 클래스의 일부로 아카이브용 스토리지
블록 스토리지	EBS	비휘발성 블록 스토리지
	EC2 인스턴스 스토어	휘발성 블록 스토리지
파일 스토리지	EFS	NAS와 같은 복수 인스턴스로부터 마운트 가능 주로 Linux용
	FSx	for Windows와 for Lustre 2종류가 있음.