이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
AWS Snow Family
엣지에서 데이터를 수집 및 처리하거나, AWS 내부 및 외부로 데이터를 마이그레이션하는데 사용되는 안전한 휴대용 장치(실제 물리적 장치를 받음, 데이터 넣어서 AWS로 보내는 방식)
데이터 마이그레이션을 위한 'Snowcone', 'Snowball Edge', 'Snowmobile'
엣지 컴퓨팅을 위한 'Snowcone', 'Snowball Edge'
데이터 마이그레이션
목적 : 네트워크를 통해 많은 데이터를 전송하려면 시간이 많이 걸림
연결성과 대역폭이 제한되고, 비용이 발생하거나, 대역폭을 차지할 수 있음
종류
1. Snowball Edge
- 커다란 박스 TB/PB 단위 데이터를 옮길 때 사용
- 스토리지 최적화 80TB HDD or 210TB NVMe, 블록 볼륨이나 S3 호환 객체 스토리지에 적합
- 컴퓨트 최적화 42TB HDD or 28TB NVMe
- 사례 : 대규모 데이터 클라우드 마이그레이션, 데이터센터 폐기, 재해 복구
2. Snowcone
- 2.1kg으로 가볍고 견고함
- 8TB HDD, 14TB SSD
- 공간이 제한된 환경에서 스노우콘 사용.. 배터리, 케이블 직접 준비
- 오프라인으로 배송하거나, 인터넷이 가능한 데이터 센터에 이 장치를 연결한 다음 AWS DataSync 로 전송
3. Snowmobile
- 실제로 데이터를 전송할 트럭
- EB(엑사바이트) 규모의 데이터를 옮길 수 있음, 한 대에 100PB
- 높은 보안 : 온도컨트롤러, GPS, 24시간 비디오 감시
- 10PB이상의 데이터를 전송할 때 스노우볼보다 더 나은 사용 사례
사용법
1. Snowball 디바이스를 주문하여 배송받음
2. Snowball 클라이언트를 설치하거나, AWS OpsHub를 서버에서 사용
3. 스노우볼을 서버와 연결하고 클라이언트에서 파일 복사를 시작
4. 장치를 반송.. 데이터가 올바른 AWS 시설로 바로 이동
5. 데이터는 S3 버킷으로 옮겨지고, 스노우볼은 완전히 삭제
엣지 컴퓨팅
* 엣지 컴퓨팅 : 엣지 로케이션에서 데이터가 생성되는 동안 데이터를 처리하는 것
ㄴ * 엣지 로케이션 : 실제로 인터넷이 없거나 클라우드에서 멀리 떨어진 곳
ㄴ 배 위나 광산 등이 해당되며, 데이터 전송은 안되고 생산만 되는 곳
- Snowball Edge나 Snowcone 주문
- 사례 : 데이터를 전처리하고, 엣지에서 머신러닝을 하는 것... 클라우드로 돌아가지 않아도, 주요 스트림을 미리 트랜스코딩하고, 필요에 따라 다시 AWS로 전송할 수도 있음
종류
- Snowcone : 2 CPU, 4GB 메모리, USB-C파워, 베터리
- Snowball Edge : 104 vCPU, 416GB 램, GPU 추가 가능, 28TB NVMe or 42TB HDD 사용 가능
- 최대 16개의 노드까지 클러스터링하여 스토리지 확장 가능
- 모든 장치는 EC2 인스턴스와 람다 기능을 실행할 수 있음 (AWS IoT Greengrass 사용)
- 1년/3년으로 장기 배치 옵션이 있음
OpsHub
- 모든 스노우 패밀리에는 OpsHub가 포함되어 있음
- 과거에는 CLI가 필요했음
- 컴퓨터에 AWS OpsHub를 깔고 스노우 장치에 연결하면 사용할 수 있는 GUI를 제공
`Snowball에서 Glacier까지
- Snowball에서 바로 Glacier로 데이터를 보낼 순 없음
- S3를 사용해서 수명 주기 정책을 생성해서 Glacier로 객체를 전송해야함
Amazon FSx
- 완전관리형 서비스로 타사 고성능 파일 시스템을 실행시킴
- RDS에서 AWS MySQL이나 Postgres를 실행하는 것과 같은 개념(RDS가 FSx와 대응됨)
- ex) FSx에서 윈도우 파일 서버(이외에도 Lustre, NetApp ONTAP, OpenZFS 등)
`사례
1. 윈도우 파일 서버
- SMB 프로토콜, NTFS를 지원
- MS 액티브 디렉토리와 통합됨... ACL, 사용자 보안 추가 가능
- 윈도우 OS 뿐만아니라 리눅스에서도 마운트 가능함
- 온프레미스에 MS 파일 서버가 있는 경우, 분산파일시스템(DFS) 기능을 사용해서 파일 시스템을 그룹화 할 수 있음... 온프레미스와 FSx 파일서버가 결합되는 것
- 초당 수십 GB, 수백만 IOPS, 수백 PB의 데이터까지 확장 가능
- SSD로 지연시간이 짧아야하는 DB, 미디어 처리, 데이터 분석 등 가능
- HDD로 스펙트럼 워크로드 사용가능.. 홈디렉토리 or CMX
- 프라이빗 연결로 온프레미스에서 연결 가능함(VPN이나 다이렉트 커넥트)
- 다중 AZ로 구성 가능
- S3에 매일 백업 가능
2. Lustre
- Lustre는 원래 분산 파일 시스템으로 대형 연산에 사용.. ML, HPC 등
- 리눅스와 클러스터 합성어
- 사례 : 동영상 처리, 금융 모델링, 전자 설계 자동화
- 확장성 높음 100GB/s, 수백만 IOPS로 확장되고 ms보다 짧은 지연 시간
`- S3와 무결절성 통합 가능.. FSx로 S3를 읽을 수 있고, FSx의 연산 출력 값을 S3에 쓸 수 있음
- VPN과 직접연결을 통해 온프레미스 서버에서 사용 가능
스크래치 파일 시스템
- 임시 스토리지로 데이터가 복제되지 않음.. 기저 서버 오작동시 파일 유실됨
- 최적화로 높은 버스트 사용 가능.. 영구 파일 시스템 6배(200MB/s per TiB)
- 단기처리 데이터에 사용.. 비용 최적화 가능
영구 파일 시스템
- 장기 스토리지
- 동일 AZ에 복제됨.. 장애나도 대체됨
- 민감데이터의 장기처리 및 스토리지에 사용됨
3. NetApp ONTAP
- NFS, SMB, iSCSI 프로토콜과 호환됨
- 온프레미스나 나스에서 실행중인 워크로드를 AWS로 옮길 수 있음
- 리눅스, 윈도우, 맥 등 다양한 OS 호환 가능
- 스토리지는 오토스케일링, 복제 스냅샷 가능
- 적은 비용으로 데이터 압축, 데이터 복제 제거 등 가능
`- 지정 시간 복제 기능(새 워크로드 등 테스트할 때 유용).. 신속히 복제되고 스테이징 파일 시스템 생성 가능
4. OpenZFS
- 여러버전의 NFS와 호환됨
- ZFS에서 돌아가는 워크로드를 AWS로 옮길 때 사용
- 다양한 OS에서 사용 가능
- 성능 우수.. 백만 IOPS, 지연시간 0.5ms 이하
- 스냅샷, 압축 지원, 저비용... 단, 데이터 중복제거는 없음
- 지정 시간 복제 기능 있음
스토리지 Gateway
하이브리드 클라우드
- AWS는 하이브리드 클라우드를 권장함(일부는 AWS, 나머지는 온프레미스에 두는 방식)
- 클라우드 마이그레이션이 오래걸리거나, 보안 또는 규정 요건이 있는 경우
- 엘라스틱 워크로드만 클라우드를 사용하는 방법
- S3는 독자적인 기술로, NFS를 준수하는 EFS와는 다름... S3 데이터를 온프레미스에 둘때 스토리지 게이트웨이가 사용됨
AWS 스토리지 클라우드 네이티브 옵션
1. 블록 스토리지 : EBS, EC2 인스턴스 스토어
2. 파일 시스템 : EFS, FSx
3. 객체 수준 스토리지 : S3, Glacier
스토리지 게이트웨이란
- 온프레미스 - 클라우드 사이 가교 역할
- 사례 : 재해복구 목적 백업, 스토리지 확장 / 클라우드에는 콜드데이터, 온프레미스에는 웜데이터를 두고 티어 스토리지
- 파일 엑세스 시간을 줄이기 위해, AWS 스토리지 게이트웨이를 온프레미스 캐시로 사용
종류
1. S3 파일 게이트웨이
- Glacier 빼고 나머지에 대해서 사용 가능..
- 온프레미스에서 S3 데이터를 사용할 때, 표준 파일 시스템을 사용하려할 때 사용 (NFS, SMB)
- 객체를 아카이브 할 때는 수명 주기 정책으로 Glacier에 넣으면됨
- 데이터는 신속한 액세스를 위해서 파일 게이트웨이에 캐시로 저장됨(최근에 사용한 파일만)
- 각 파일 게이트웨이마다 IAM 역할을 생성해야 버킷에 접근가능
- 윈도우에서 SMB 프로토콜 쓸 때, 사용자 인증을 위해 액티브 디렉토리와 통합해야함
2. FSx 파일 게이트웨이
- FSx 윈도우 파일 서버에 대해서 네이티브 액세스 가능
- 온프레미스 처럼 접근 가능하지만, 자주 액세스하는 데이터의 로컬 캐시를 확보하기 위해 사용
- SMB, NTFS, 액티브 디렉토리 가능
- 그룹 파일 공유나, 온프레미스를 연결할 홈 디렉토리로 사용 가능
3. 볼륨 게이트웨이
- 블록 스토리지로 iSCSI 프로토콜 사용
- 볼륨이 EBS 스냅샷으로 저장되어, 필요시 온프레미스 볼륨 복구 가능
- 종류
- 캐시 볼륨 : 최근 데이터 액세스시 지연 시간 낮음
- 저장 볼륨 : 데이터 세트 전체가 온프레미스에 있으며 주기적으로 S3에 백업
4. 테이프 게이트웨이
- 물리적으로 테이프 백업 시스템이 있는 회사가 백업을 테이프 대신에 클라우드를 이용 가능
- VTL(가상 테이프 라이브러리)는 S3와 Glacier 사용
- iSCSI 프로토콜 사용
*게이트웨이는 회사 서버에 설치되어 운영해야함
단, 온프레미스에 서버가 없는 경우 '스토리지 게이트웨이 하드웨어 어플라이언스'를 사용할 수 있다
ㄴ 미니 서버가 될 하드웨어를 amazon.com에서 주문해야함
ㄴ 사례 : 소규모 데이터센터나 일일 NFS 백업처럼, 적은 데이터에 가상화가 없을 때 유용함
AWS 전송 제품군
- S3나 EFS의 데이터를 S3 API나 EFS없이, FTP 프로토콜로 옮길려할 때 사용
- 완전관리형, 고가용성, 확장성
- 요금 : 시간당 프로비저닝된 엔드포인트 비용+안팎으로 전송된 데이터의 GB당 요금
- 유저의 자격증명을 저장하거나 관리할 수 있음
- MS Active Directory, LDAP, Okta, Cognito와 같은 기존 인증 시스템과 통합 가능
- 사례 : 파일 공유, 공개 데이터셋, CRM, ERP 등
- FTP client - Route53(옵션) - 전송 제품군 서비스 - S3, EFS(IAM Role로 접근)
지원 프로토콜
- FTP, 파일 전송 프로토콜
- FTPS, SSL을 통한 파일 전송 프로토콜
- SFTP
`DataSync
- 데이터를 동기화하며, 대용량의 데이터를 한 곳에서 다른 곳으로 옮길 수 있음
ㄴ 온프레미스나 다른 클라우드에서 AWS 서비스로 옮길 수 있음 (단, 옮길 위치에 에이전트가 있어야함)
ㄴ AWS에서 AWS서비스로 옮기기 (에이전트 없어도됨)
- 동기화 가능한 곳
1. 모든 S3, Glacier를 포함하여 모든 스토리지 클래스
2. EFS 네트워크 파일 시스템
3. FSx
- 일정을 지정하여 DataSync가 매 시간, 매일, 매주 복제 가능...(지연은 있음)
`- 파일 권한과 메타데이터는 보존됨, 보안과 연결 (NFS POSIX, SMB 권한 준수)
- 하나의 에이전트 태스크가 초당 10GBps까지 사용 가능, 대역폭에 제한을 걸 수도 있음
`- 만약 DataSync로 옮기려할 때 네트워크 용량이 따라주지 못한다면?? -> Snowcone 장치 사용(DataSync 사전 설치되어 있음)
`스토리지 옵션 비교
S3 : 객체 스토리지
S3 Glacier : 객체 아카이브
EBS 볼륨 : 한번에 한 개의 EC2 인스턴스에 연결할 때(io 1,2는 다중연결지원)
인스턴스 스토리지 : EC2 인스턴스와 물리적으로 연결됨 (높은 IOPS)
EFS : 다중 가용 영역 간 마운트해야하면서 POSIX 파일 시스템을 쓸 때
FSx for Windows : 윈도우 서버 파일 시스템을 필요로 할 때
FSx for Lustre : 고성능 연산 리눅스 파일 시스템
FSx for NetApp ONTAP : 높은 OS 호환성, 네트워크 파일시스템
FSx for OpenZFS : 관리형 ZFS 파일 시스템
Storage Gateway :
S3 & FSx 파일 게이트 웨이 : 온프레미스와 S3 or FSx에 파일을 동기화
볼륨 게이트웨이(캐시&저장) : 온프레미스 서버에 볼륨을 마운트, 클라우드 백업
테이프 게이트웨이 : 테이프 형식으로 백업
전송 제품군 : S3나 EFS에 전송할 때 FTP, FTPS, SFTP 인터페이스를 필요로 하는 경우
DataSync : 일정에 따라 데이터 동기화
Snow 제품군 : 데이터를 옮기는데 쓸 네트워크 용량이 없으나, 물리적으로 대용량 데이터 옮길 때
Database : 데이터 저장이 가능하고 인덱스와 쿼리 작업을 필요로하는 특수한 워크로드 존재
