AWS 스토리지 추가기능

1. AWS Snow Family

• 보안성이 뛰어난 휴대용 장치의 모음
• 두 가지 경우 사용
  • 엣지에서 데이터를 수집하고 처리하기 위해 사용
    • Snowcone, Snowball Edge
  • AWS 안팎으로 데이터를 마이그레이션 할 때
    • Snowcone, Snowball Edge, Snowmobile

 

2. Snow 사용 사례 - 데이터 마이그레이션

• 네트워크를 통해서 많은 데이터를 전송하려면 오랜 시간이 걸림
• 100TB 데이터를 1Gbps로 전송하는 경우 12일이나 걸린다
• 빠르게 AWS에 접속해야할 때가 있는데 이런 경우 전송 가능한 데이터의 양이 적다는 것과 제한된 연결 제한된 대역폭 등 네트워크를 통한 데이터 전송 비용이 발생
  • 대역폭 공유, 연결 불안정성 등 문제가 발생할 수 있음

이런 이유들 때문에 Snow Family가 사용됨

 

2.1. Snow Family

• 오프라인에서 데이터 마이그레이션을 실행하는 장치
• AWS가 우편으로 물리적 장치를 보내주면 거기서 데이터를 끌어오고 다시 AWS로 전송
• 데이터를 네트워크 전송시 일주일이 걸린다면 사용해야함

 

2.2. 다이어그램

• 직접 S3로 전송하는 경우

• Snow Family를 사용하는 경우

 

물리적인 경로를 이용하는 방법이다

 

 

2.3. Snowball Edge(for data transfers)

• TB 혹은 PB 크기의 데이터를 AWS 안팎으로 전송이 가능하다
  • 네트워크를 대신해 옮길 수 있다
• 데이터 전송건마다 비용 청구
• 블록스토리지를 제공하거나 S3 호환 객체 스토리지를 제공
• Snowball Edge Storage Optimized
  • 블록 볼륨으로 사용할 수 있도록 80TB 하드웨어 디스크 용량 혹은 S3 호환 스토리지 제공
• Snowball Edge Compute Optimized
  • 42TB의 HDD 블록 볼륨
• snowball edge를 데이터 전송에 쓰는 경우는 데이터 센터 폐쇄를 위한 대량의 데이터 클라우드 마이그레이션 AWS 데이터 백업 및 복구

 

2.4. AWS Snowcone

• edge보다 훨씬 작다
• 어디서나 컴퓨팅 가능하며 안전하고 가혹한 환경을 견딜 수 있다
• 엣지 컴퓨팅, 스토리지, 데이터 전송에 사용되는데 용량이 작아야 가능
• 8TB 저장가능
• snowball 사용이 불가능할 때 snow con
  • 환경적 제약이 있는 경우
• 배터리와 케이블 직접 준비
• AWS 오프라인으로 다시 전송될 수 있고 네트워크에 연결해서 DataSync 사용해서 데이터 재전송

 

2.5. AWS Snowmobile

실제 트럭이다..

• 트럭이 데이터를 전송
• 1 EB = 1,000 PB = 1,000,000TB
• 각 Snowmobile 용량은 100 PB이다
• 보안성, 온도 조절 GPS까지 상당히 안정적임
• 10PB보다 크면 Snowball보다 좋다

 

2.6. Snow Family 사용하는 방법

• 배송을 위해 콘솔에서 장치 요청
• Snowball 클라이언트나 OpsHub를 서버에 설치
• Snowball을 서버에 연결
• 클라이언트를 사용해서 파일을 복사
• 장치를 다시 돌려준다(적합한 AWS 시설로 옮겨진다 → E 잉크 마커)
• S3 버킷에 해당 데이터를 불러들이고나면 가종 높은 보안조치에 따라 Snowball은 완전히 삭제

 

3. Snow 사용 사례 - 엣지 컴퓨팅

데이터가 엣지 로케이션에서 생성될 때 실시간으로 처리하는 방식

• 인터넷이 없는 곳이나 클라우드에서 밀리 있는 곳을 엣지 로케이션
  • 도로에 있는 트럭, 바다위의 배 등등
  • 데이터는 생성되지만 인터넷과 연결되어 있는 곳
  • 연결이 제한되거나 인터넷 엑세스가 없거나 컴퓨팅파워에 접근 불가
• 이런 장소에서 컴퓨팅이나 데이터 처리가 필요한 경우를 엣지 컴퓨팅
• Snowball Edge나 snowcone을 주문해서 엣지 로케이션에 장착시키면 됨
• 사용 케이스
  • 데이터 전처리
  • 엣지에서 머신러닝 처리
  • 사전 미디어스트림 트랜스코딩
• 데이터를 AWS로 재전송하는 경우 장치를 보내면 된다

데이터가 생성되는 곳의 아주 가까이에서 데이터를 처리하고 AWS로 보냄

 

3.1. 엣지 컴퓨팅

• 스노우콘
  • 2 CPUS, 4GB메모리, 유무선 엑세스 Wi-Fi
  • USB-C 혹은 선택적 배터리로 작동
• 스노우볼 엣지
  • 52 vCPU, 200GB RAM
  • 선택적 GPU (영상 혹은 머신러닝)
  • 42TB
• 스노우볼 엣지 - 저장공간 최적화
  • 40 vCPU, 80GB RAM
  • 객체 스토리지 클러스터링
• 모든 장치들은 내부 EC2 인스턴스나 람다함수를 실행 가능
  • AWS IoT GreenGrass
• 장기 배포 옵션도 있어 1~3년 빌리면 가격 할인을 받을 수 있다

 

4. OpsHub

• 원래 이런 장치를 사용할 떄 CLI를 통해 처리했고 방식도 어려웠음
• 소프트웨어로써 클라우드없이 컴퓨터에 다운로드하여 사용
• GUI를 통해 스노우 장치와 연결해 구성 및 사용 가능
  • 단일 장치와 클러스터 장치를 잠금 해제하고 구성 가능
  • 파일 전송이 가능해지고 스노우 장치에서 EC2 인스턴스 시작 및 관리
  • 장치 메트릭 모니터링과 AWS 호환 서비스 가능
    • Ec2 인스턴스, 네트워크 파일 시스템

 

5. Solution Architecture: Snowball into Glacier

• 스노우볼은 Glacier에 데이터를 직접 끌어올 순 없다
• 데이터를 가져온 후 S3 수명 주기 정책을 통해 Glacier 객체로 전환 가능

 

6. Amazon FSx

• 타사의 고성능 파일 시스템을 실행 시킨다
• RDS에서 AWS에 MySQL이나 Postgres를 실행하는 것과 유사
• 아래 4가지는 알아야함

 

6.1. Amazon FSx for Windows (File Server)

• 완전 관리형 windows 파일 서버 공유 드라이브
• SMB 프로토콜과 Windows NTFS를 지원
• Microsoft Active Directory 통합을 지원하므로 사용자 보안 추가, ACL로 사용자 할당량 추가해 엑세스 제어 가능
• 특징
  • Linux EC2 인스턴스에도 마운트할 수 있다
  • 온프레미스로 실행중인 파일 서버와 윈도우의 분산파일시스템인 DFS 기능을 이용해 파일 시스템을 그룹화 가능
• 초당 수십 GB, 수백만 IOPS, 수백 PB의 데이터까지 확장 가능
• 스토리지 옵션
  • SSD 지연시간이 짧아야하는 워크로드를 저장 (DB 미디어 처리 데이터 분석)
  • HDD 넓은 스펙트럼의 워크로드
• 프라이빗 연결로 온프레미스 인프라에서 엑세스 가능
• 고가용성 다중 AZ에 대해 구성 가능
• 재해복구목적으로 S3에 매일 백업된다

 

6.2. Amazon FSx for Lustre

• 분산 파일 시스템 Lustre로 대형 연산에서 사용
  • Linux + cluster → 머신러닝 같이 고성능 연산에 사용됨
• 동영상 처리, 금융 모델링 전자 설계 자동화 → 확장성이 상당히 높다
• 초당 수백 GB의 데이터, 수백만 IOPS, 지연시간이 밀리초단위
• 스토리지 옵션
  • SSD or HDD
• FSx로 S3를 파일 시스템처럼 읽어들일 수 있다
• VPN과 직접 연결을 통해 온프레미스 서버에서 사용 가능

 

6.2.1. FSx Lustre - File System Deployment Options

• 스크래치 파일 시스템
  • 임시 스토리지로 데이터가 복제되지 않는다
  • 서버가 오작동하면 파일이 모두 유실
  • 최적화로 초과 버스트를 사용 가능(6배 빨라질 수 있다)
  • 단기 처리 데이터에 쓰이며 데이터 복제가 없어 비용 최적화 가능
• Persistent File System
  • 장기 스토리지로 동일한 가용영역에 데이터가 복제
  • 동일한 AZ내에서만 복제되어 장애에 대응
  • 민감한 데이터의 장기 처리 및 스토리지

 

6.3. Amazon FSx for NetApp ONTAP

• AWS의 관리형 NetApp ONTAP 파일 시스템
• NFS, SMB, iSCSI 프로토콜과 호환 가능
• 온프레미스 시스템의 ONTAP이나 NAS에서 실행 중인 워크로드를 AWS로 옮길 수 있다
• 여러 운영체제에서 사용 가능 → 호환 가능한 폭이 넓다
• 스토리지는 오토 스케일링되며 복제와 스냅샷 기능도 지원함
• 압축, 중복 제거도 가능
• 지정 시간 복제 기능이 있어 새 워크로드를 테스트할 떄 상당히 유용
  • 신속한 복제 스테이징 파일 시스템

 

7. Amazon FSx for OpenZFS

• AWS 관리형 OpenZFS 파일 시스템
• 여러 버전에 NFS 프로토콜과 호환
• ZFS에서 실행되는 워크로드를 내부적으로 AWS로 옮길 때 사용

올바른 파일 시스템을 고르는 문제가 나온다

즉 4가지 서비스간의 차이를 아는게 중요

 

8. 하이브리드 클라우드를 위한 스토리지

• 일부 인프라는 AWS 클라우드에 있고 나머지는 온프레미스에 두는 방식을 하이브리드
  • 마이그레이션이 오래 걸리거나 보안 또는 준수 요건이 있는 경우
  • IT 전략
• 아마존 S3는 독점 스토리지 기술로 EFS와는 다름
• S3 데이터를 온프레미스에 두려면 Storage Gateway가 역할을 한다

 

8.1. AWS Storage Cloud Native Options

 

 

9. AWS Storage Gateway

• 온프레미스 데이터와 클라우드 데이터간의 다리 역할
• 유즈케이스
  • 재해 복구
  • 백업과 복구
  • 파일 엑세스 지연시간을 줄이기 위해 온프레미스 캐시로 사용

• S3 File Gateway
• FSx File Gateway
• Volume Gateway
• Tape Gateway

 

9.1. S3 File Gateway

• 온프레미상의 애플리케이션 서버와 연결
• 애플리케이션 서버 입장에서는 NFS or SMB를 사용한 일반적인 파일 공유 엑세스처럼 보인다
  • 실제로는 S3 파일 게이트웨이를 사용한
• 이후 버킷 수명주기 정책을 통해 Glacier로 옮길 수 있다
• S3 파일 게이트웨이로 구성한 모든 버킷은 NFS 및 SMB 프로토콜을 이용해 엑세스 가능
• 사용된 데이터는 신속한 엑세스를 위해 파일 게이트웨이에 캐시로 저장
• 버킷에 엑세스하려면 파일 게이트웨이마다 IAM 역할을 생성해야함
• SMB 프로토콜을 사용하는 경우 Active Directory와 통합 필요
  • S3 파일 게이트웨이에 사용자가 엑세스할 때 인증을 거치며 S3 버킷에 엑세스할 때도 인증

 

9.2. Amazon FSx File Gateway

• mazon FSx for Windows 파일 서버에 대한 네이티브 액세스 제공
  • 게이트웨이 없이도 접근 가능
• 게이트웨이를 생성하면 로컬 캐시 확보 가능 (지연시간 단축)
• Windows 네이티브인 SMB, NTFS, Active Directory와 호환 가능(파일 게이트웨이)
• 그룹 파일 공유나 온프레미스를 연결할 홈 디렉터리로 사용 가능

 

9.3. Volume Gateway

• 블록 스토리지로 S3가 백업하는 iSCSI 프로토콜을 사용
• 볼륨이 EBS 스냅샷으로 저장되어 필요에 따라 온프레미스 볼륨 복구 가능
• 캐시 볼륨 → 최신 데이터데 대한 낮은 지연시간
• 저장 볼륨(Stored volumes) → 전체 데이터 세트가 온프레미스에 있으며 주기적으로 S3 백업
• 온프레미스 서버에 볼륨을 백업하는 것에 의미가 있다

 

9.4. Tape Gateway

• 물리적으로 테이프를 사용하는 회사에 백업을 테이프 대신 클라우드를 활용할 수 있게 함
• 가상 테이프 라이브러리(VTL)는 S3와 Glacier를 이용
• 테이프 기반 프로세스의 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업

 

10. 중요한점

게이트웨이는 온프레미스 데이터 센터, 즉 클라이언트쪽에 설치되어 있어야 한다

클라이언트 회사 데이터 센터 내에서 운영해야한다

 

10.1. Storage Gateway – Hardware appliance

게이트웨이를 실행할 가상 서버가 없는 경우 AWS의 하드웨어를 사용할 수 있다

• 온프레미스 서버가 없는 경우 amazon.com에서 주문 가능
• 미니 서버가 될 하드웨어 어플라이언스를 인프라에 설치한 후 게이트웨이를 구성하면 된다
  • 물리적인 설치가 필요하며 컴퓨터 자원이 필요함
• 소규모 데이터 센터의 일일 NFS 백업처럼 가상화가 없는 경우 유용

 

11. AWS Storage Gateway 정리

프로토콜과 옵션을 잘 이해하면 됨

 

12. AWS Transfer Family

• 전송 제품군으로 S3 또는 EFS 안팎으로 FTP만을 사용해 데이터 전송을 위한 완전 관리형 서비스
• AWS Transfer for FTP (File Transfer Protocol (FTP)) - 파일 전송 프로토콜
• AWS Transfer for FTPS (File Transfer Protocol over SSL (FTPS)) - 암호화된 파일 전송 프로토콜
• AWS Transfer for SFTP (Secure File Transfer Protocol (SFTP)) - 보안 파일 전송 프로토콜
  • 둘다 전송 중 암호화
• FTP를 사용해 S3 또는 EFS에 업로드 가능
• 가용성 안정성 확장성이 높다
• 시간당 요금 + 데이터의 GB 요금
• 사용자 자격 증명을 저장 관리 가능 , 외부 인증 시스템과 통합 가능(LDAP)
• S3나 EFS의 FTP 인터페이스를 갖추기 위함

 

13. AWS DataSync

• 데이터를 동기화하여 대용량의 데이터를 한곳에서 다른 곳으로 이동
  • 온프레미스 / AWS의 다른 클라우드로 데이터 옮길 수 있다
  • 서버를 NFS, SMBㄷ등 프로토콜로 연결 + 옮길 위치인 온프레미스나 연결할 다른 클라우드에 에이전트가 있어야한다
• 한 AWS에서 다른 AWS 서비스로 이동할 때는 에이전트가 필요 없다
  • 모든 S3의 Glacier를 포함하여 모든 스토리지 클래스에 동기화 가능
  • EFS로 네트워크 파일 시스템에 저장 가능
  • Amazon FSx
• 복제 작업은 계속 이루어지지 않고 일정 시간마다 스케줄
  • 일정에 맞춰 데이터 동기화된다
• 파일권한과 메타 데이터 저장 기능이 있으며 보안과 연관됨
  • NFS POSIX, SMB 권한을 준수
• 파일을 다른 곳으로 옮길 때 파일의 메타 데이터 보존 가능
• DataSync 에이전트는 하나의 태스크가 초당 10Gb까지 사용 가능하며 대역폭에 제한 가능

 

13.1. AWS DataSync NFS/SMB를 사용하는 경우

13.1.1. 온프레미스 파일을 AWS로 동기화

AWS DataSync는 어디로든 갈 수 있다 → 네트워크 장치가 부족한 경우 snowcone이 사용됨

 

 

13.1.2. 서로다른 AWS 서비스간 동기화

 

14. Storage Comparison

• S3 - 객체 스토리지로 대부분 AWS 서비스와 연결 가능
• S3 Glacier: 객체를 아카이브 할 경우 사용
• EBS 볼륨: 한개의 인스턴스에 한 개의 스토리지 연결 IO1 IO2에 다중 연결 지원
• 인스턴스 스토리지: IOPS가 높다 고성능 물리 스토리지
• EFS: 네트워크 파일 시스템으로 다중 AZ간 마운트하면서 POSIX 파일 시스템 사용
• FSx for Windows: 윈도우 서버 파일 시스템이 필요한 경우
• FSx for Lustre: 고성능 연산 Linux 파일시스템 Lustre와 호환
• FSx for NetApp ONTAP: 높은 운영체제 호환성과 네트워크 파일 시스템
• FSx for OpenZFS: 관리형 ZFS 파일 시스템이 필요한 경우
• Storage Gateway: 온프레미스와 AWS 스토리지 간 연결 S3 및 FSx 파일 게이트웨이, 볼륨 게이트웨이, 테이프 게이트웨이
• Transfer Family: FTP, FTPS, SFTP 프로토콜 인터페이스를 필요로 하는 경우
• DataSync: 온프레미스에서 AWS 혹은 AWS에서 AWS로 데이터 동기화 스케줄이 필요한 경우
• Snowcone / Snowball / Snowmobile : 물리적으로 데이터를 옮겨야할 경우