[AWS] AWS 기술 정리 3편 EC2 Instance Storage(EBS, EFS) - (AWS SAA, Udemy 강의 정리)

https://aws.amazon.com/ko/certification

 

 이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate

 

EBS

EBS 볼륨

Elastic Block Store : 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브

인스턴스가 종료되어도, 데이터 지속 가능

EBS 생성시 특정 AZ에서만 사용 가능 (단, 스냅샷을 이용하면 다른 AZ에 볼륨 옮길 수 있음)

EBS... 네트워크 USB 스틱 같은것

프리티어에서는 매달 30GB까지 EBS를 쓸 수 있음(범용 SSD or 마그네틱 유형)

 

*CCP 레벨 : 하나의 EBS는 하나의 EC2 인스턴스에 마운트 가능

*어소시에이트 레벨 : 일부 EBS 다중 연결

 

- 인스턴스와 EBS 볼륨이 서로 통신하려면, 네트워크가 필요하고 지연이 생길 수 있음

- 쉽게 땔 수 있어서, 페일오버 상황에서 유리함

- 미리 크기를 정해둬야함.. 원하는 용량의 GB와 IOPS(초당 전송 수)

 

`종료 시 삭제(Delete on Termination attribute) - 자유롭게 가능

 - EC2 생성시, 기본적으로 루트 EBS 볼륨은 종료시 삭제 활성화 - 유지하고 싶으면 비활성화 해야됨

 - 다른 EBS 볼륨은 기본적으로 종료 시 삭제 비활성화

 

 

EBS 스냅샷

EBS 볼륨의 특정 시점에 대한 백업

EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만, 권장사항

EBS 스냅샷은 다른 AZ나 다른 리전에도 복사(복원) 가능 : 재해 복구 전략이 필요한 경우 유용함

 

EBS 스냅샷 아카이브

- 최대 75%까지 저렴한 아카이브 티어, 스냅샷을 옮길 수 있는 기능

- 다른 스토리지 계층으로 이동 가능. 다른 가격 수준으로...

- 아카이브를 복원하는데 24~72h 걸림(즉시 복원이 안됨)

 

EBS 스냅샷 휴지통

- 영구 삭제하는 대신, 휴지통에 넣으면 실수로 삭제하는걸 방지

- 1일 ~ 1년사이로 보관 가능

 

빠른 스냅샷 복원(FSR)

- 스냅샷을 완전 초기화해 첫 사용에서 지연시간을 완전히 없앰

- 스냅샷이 아주 크거나, EBS볼륨이나 EC2 인스턴스를 빠르게 초기화해야할 때 유용

- 단, 비쌈

 

 

EBS 볼륨 타입

(각 종류의 세부수치 보다는, 큰 틀에서 차이점 이해...) 

- 1. gp2, gp3 (SSD) : General Purpose, 범용 SSD 볼륨으로 다양한 워크로드에 대해 가격/성능의 균형 맞춤

`비용 효율적인 스토리지, 낮은 대기 시간 제공

`  - gp2 : 구세대 볼륨

    - 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에서 사용

    - 1GB ~ 16TB

    - 작은 gp2 볼륨은 최대 3000 IOPS 버스트 성능

    - 볼륨 크기와 IOPS는 연관되어 있어 16000 IOPS까지 증가가능(5334GB 일 때..)

   - gp3 : 최신 세대 볼륨

    - 기본적으로 3000 IOPS, 125MB/s 처리량

    - 최대 16000 IOPS, 1000MB/s 처리량까지 독립적으로 증가 가능

 

- 2. io 1, io 2 Block Express (SSD) : Provisioned IOPS(PIOPS), 가장 높은 성능의 SSD 볼륨.. 미션 크리티컬, 저지연, 고처리량 작업

- 16000 IOPS 이상이 필요할 때 사용

- 데이터베이스 워크로드가 스토리지 성능과 일관성에 매우 민감한 경우 적합

- EBS 다중 연결 기능 지원

  - io 1

   - 4GB ~ 16TB까지 지원

`  - 최대 PIOPS : 64000(Nitro EC2 인스턴스), 32000(다른 인스턴스)

   - 스토리지 크기와 별도로 프로비저닝된 IOPS를 늘릴 수 있음

  - io 2 Block Express

   - 4GB ~ 64TB까지 지원

   - 밀리초 단위 레이턴시

   - 최대 PIOPS : 256000... IOPS:GB == 1000:1

  

- 3. st 1 (HDD) : 처리량 최적화 HDD, 자주 액세스하고 처리량이 많은 작업

  - 빅데이터, 데이터 웨어하우징, 로그 처리

  - 최대 500MB 처리량, IOPS 500

 

- 4. sc 1 (HDD) : Cold HDD,가장 저렴함.. 액세스 빈도가 낮은 작업

   - 가능한 가장 낮은 비용이 필요할 때 사용

   - 최대 250MB 처리량, IOPS 250

 

크기, 처리량, 초당 입출력 작업 수(IOPS) 로 나뉨

오직 SSD만 부팅 볼륨(OS root가 실행)으로 사용될 수 있다. 

 

 

EBS 다중 연결 기능

하나의 EBS 볼륨을 같은 AZ에 있는 여러 EC2 인스턴스에 연결하게 해줌(무조건 같은 AZ안에서만 가능)

io 1,2 제품군에서만 사용할 수 있음

각 인스턴스는 고성능 볼륨에 대한 읽/쓰기 권한을 전부 가짐

- 사례 : 애플리케이션 가용성을 높이기 위해 Teradata처럼 클러스터링된 Linux 어플리케이션, 애플리케이션이 동시 쓰기 작업을 관리해야할 때 사용

`최대 16개의 EC2 인스턴스만 연결 가능

무조건 클러스터 인식 파일시스템을 써야함(XFS, EX4 등은 쓸 수 없음)

 

 

EBS 암호화

저장 데이터가 볼륨 내부에서 암호화

인스턴스와 볼륨 간의 전송 데이터 역시 암호화

모든 스냅샷과 스냅샷으로 생성된 볼륨도 암호화

 

이때 암호화와 복호화 메커니즘은 보이지 않고, 모두 백그라운드에서 처리됨

`지연 시간에는 영향이 거의 없고, KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 가짐

스냅샷을 복사해 암호화를 푼 걸 다시 암호화 활성화를 하는 것

 

EBS 암/복호화 방법

- EBS 볼륨의 스냅샷 생성 -> 복사 기능을 통해 EBS 스냅샷 암호화 -> 스냅샷으로 새 EBS 볼륨 생성시 해당 볼륨도 암호화 -> 암호화된 볼륨을 인스턴스 원본에 연결

 

암호화되지 않은 EBS 볼륨은 스냅샷도 암호화되지 않음... 그래서 스냅샷을 복사할 때 암호화시켜서 동일 리전에 만들고, 그걸로 다시 볼륨을 만들면 암호화된 볼륨이 됨

좀 더 빠르게 하려면, 비암호화된 스냅샷을 바로 볼륨으로 만들 때, 암호화 옵션을 선택해도 됨

 

 

AMI

Amazon Machine Image : EC2 인스턴스를 통해 만든 이미지를 통칭

- 커스터마이징 가능 : 원하는 SW, 설정 파일 추가, 별도의 OS, 모니터링 툴 등 설치가능

- 부팅 및 설정에 드는 시간 줄일 수 있음 : AMI가 미리 패키징해줌

- AMI를 특정 지역에 구축하고, 다른 지역으로 복사할 수도 있음

- 리전에 국한되어 다른 리전에서 바로 실행할 수는 없지만, AMI를 다른 리전으로 복사해서 생성하는 것은 가능

 

EC2 인스턴스 여러 방법 런치 가능

- Public AMI : AWS가 제공하는 것... ex) Amazon Linux 2

- own AMI : 직접 만들고 유지보수 해야함... 자동 관리 도구 있긴함

- Marketplace AMI : 다른 사람이 구축한 이미지.. 구매해야함, 보통 기업에서 자사 SW 넣고 파는 형태

 

EC2에서 AMI Process

EC2 인스턴스를 원하는대로 설정 -> 인스턴스를 중단해 데이터 무결성 확보 -> 이걸 빌드(구축)해서 AMI를 만듬.. 이 과정에서 EBS 스냅샷이 생성됨 -> 다른 인스턴스에서 AMI 사용

 

User Script를 쓰면, 인스턴스가 Running 되어도 초기 세팅을 하는데 시간이 소요되는데, AMI를 이용하면 부팅(부팅과 동시에 세팅)이 더 빠르게 됨

 

 

EC2 인스턴스 스토어

EBS는 네트워크 드라이브로 좋지만 성능에 한계가 있다.

더 좋은 하드웨어 디스크를 원한다면, EC2 Instance Store를 이용해야함

EC2 인스턴스 스토어 : EC2에 물리적으로 연결된 하드웨어 드라이브

 

- I/O 성능 향상

- EC2 인스턴스를 종료하면, 스토리지가 손실됨.. 그래서 임시 스토리지라고 부름(장기적으로 데이터 보관X)

- 버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠에는 좋은 보관 장소

- EC2 인스턴스가 장애 발생시 같이 장애가 발생하는 단점.. 데이터를 백업하거나 복제해둬야함

 

장기 저장 스토리지로는 EBS가 어울림

하지만 IOPS 64,000 넘어가면 무조건 이거 써야함... 이때 데이터 손실 방지책으로 아래 방법이 있음

1. 인스턴스 스토어가 있는 다른 EC2에서 복제 매커니즘 설정으로 대기 복사본 갖기

2. 백업 매커니즘 설정하기

 

 

EFS

Amazon EFS - Elastic File System

EFS는 관리형 NFS(네트워크 파일 시스템).. 많은 EC2 인스턴스에 마운트 될 수 있음

이때, EC2 인스턴스는 서로 다른 AZ에 있어도 됨

고가용성, 확장성 뛰어남, 비쌈(gp2에 3배 가격), 사용량에 따라 비용 지불(미리 용량을 프로비저닝할 필요 X)

 

- 사례 : 콘텐츠 관리, 웹 서빙, 데이터 공유, 워드프레스

- 내부적으로 NFSv4.1 프로토콜을 쓰고, EFS에 대한 액세스를 제어하려면 SG로 함(EC2에서 마운트할 때 자동으로 SG 연결 옵션 있음)

- 단, 리눅스 기반 AMI만 호환됨(윈도우 안됨)

- KMS를 사용해서 EFS 드라이브에서 암호화 활성화 가능

- 리눅스 표준 파일 시스템인 POSIX 사용, 표준 파일 API가 있음

- 용량을 미리 계획할 필요가 없다는 장점.. 자동으로 확장되고 사용량에 따라 비용 지불

 

EFS - 성능 & 스토리지 클래스

- EFS Scale : 동시 NFS 클라이언트 수천 개와 10GB 이상의 처리량 확보

- PB 규모 NFS 자동확장됨

 

- 성능 모드 (EFS 생성시 설정)

  - General Purpose(권장) - 지연 시간에 민감한 사용 사례 : ex) 웹서버, CMS(콘텐츠관리 시스템) 등

  - MAX I.O : 지연시간은 더 길지만, 처리량 최대화.. 병렬성 높음 ex) 빅데이터, 미디어 처리

 

`- 처리량 모드

  - Bursting : 1TB = 50MB/s + 100MB/s, 사용중인 스토리지 용량에 따라 처리량을 확장

  - Provisioned : 스토리지 크기와 상관없이 처리량을 설정하고 싶을 때, 처리량을 미리 알고 있을 때

  - Elastic(권장) : 워크로드에 따라 처리량 자동 조정, 워크로드를 예측하기 어려울 때 유용, 쓴만큼만 냄

 

Storage Classes

- 스토리지 계층(tier)

  - Standard : 자주 액세스하는 파일을 위한 티어

  - IA(Infrequent Access) : 자주 액세스하지 않는 용도, 파일을 검색할 때 비용이 들지만, 저장하면 비용이 감소

  - Archive : 거의 액세스하지 않는 데이터, 1년에 몇번 액세스할 때...

  

  수명 주기(Lifecycle) 설정해서 며칠 후에 어느 계층으로 이동시킬지 정의 가능

 

- 가용성과 내구성

  - Standard(Regional) : 다중 AZ 설정이 있을 때

  - One Zone : 개발만하고 하나의 AZ에 저렴하게 사용, 백업은 기본적으로 활성화, 액세스 빈도가 낮은 스토리지 계층과 호환됨(IA)

 

올바른 EFS를 쓰면 최대 90% 비용 절감 가능

 

 

`EBS vs EFS

EBS 

- 하나의 인스턴스에만 연결(단, io1,2 유형의 다중 연결 기능(동일 AZ)은 예외)

- AZ level에 갇혀있음

- gp2 : 디스크 크기 증가하면 IO 증가

- gp3& io 1 : 독립적으로 IO 증가 가능

- AZ 간에 마이그래이션 하려면, 스냅샷 찍어서 EBS 스냅샷으로 옮기고, 다른 AZ에서 복원해야함

- EBS 볼륨 백업은 많은 IO 사용하기 때문에, 애플리케이션이 많은 트래픽 처리하는 동안에는 성능에 영향을 줄 수 있어 지양해야함

- EC2가 종료되면 기본적으로 루트 볼륨 종료되지만, 옵션을 바꿔 비활성화 가능

 

EFS

- 네트워크 파일 시스템으로 여러 AZ에 걸쳐 수백 개의 인스턴스에 연결하는 것이 목표

- 여러 인스턴스가 하나의 FS 공유 가능

- 워드프레스와 같은 웹사이트 파일을 공유할 때 사용

- 리눅스 인스턴스만 가능.. POSIX 시스템 사용

- EFS는 EBS보다 비싸지만, 스토리지 계층을 활용하여 비용절감 가능

 

+ 인스턴스 스토어

EC2 인스턴스에 물리적 연결 : EC2 인스턴스 종료시 같이 종료