[AWSCloudClubs] EBS Volume, EBS Snapshot, AMI, EC2 Instance Store, EFS

EBS와 EFS를 공부하며 volume, file system, root, mount, directory의 개념도 확실히 다질 수 있었다.

현장실습을 하면서 요즘 가장 많이 치고 있는 명령어가 'mount -o remount, rw /'인데,
그러면서도 이거에 대해 깊게 이해하려고 하지 않았던 내 자신을 반성해본다ㅎ

---

EBS (Elastic Block Store) Volume

• 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브 / 네트워크 usb 스틱
• 인스턴스가 종료된 후에도 데이터를 지속할 수 있다.
  • 인스턴스 재생성 하고 EBS 볼륨을 마운트하면 되는 것.
• CCP 레벨 : 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능
• 특정한 AZ(가용 영역)에 고정되어 있다.
  • snapshot을 이용하면 다른 AZ로 볼륨을 이동할 수도 있긴 하다.
• Delete on Termination(종료 시 삭제) : EC2 인스턴스 종료 시 행동 제어 가능
  • default로 root volume이 삭제되는 것이 활성화 되어 있으나, 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우(데이터 저장 등) 비활성화하면 된다.

cf : 블록 디바이스를 실제로 사용하는 것은 ‘format EBS volume’을 검색할 것

EBS Volume Type

• Size / Throughput(처리량) / IOPS(I/O Ops Per Sec)
• GP2 (General Purpose SSD)
  • Cost effective storage, low-latency
    • System boot volumes, Virtual desktops, Development&test environ., 데이터베이스

GP3에서는 IOP와 Throughput(size of volume)을 독립적으로 설정할 수 있지만 GP2에서는 서로 연결된다.

• PIOPS (Provisioned IOPS SSD)
  • storage performance와 consistency(일관성)에 매우 민감한 경우
    • ex : 데이터베이스 작업
  • io1 유형 볼륨 : 4GiB~16TiB / 스토리지 크기와 별도로 프로비저닝된 IOPS를 늘릴 수 있다.
  • io2 Block Express : 4GiB~64TiB
  • EBS Multi-attach (다중 연결) : 동일한 EBS 볼륨을 동일 AZ 상에 있는 다수의 EC2 인스턴스에 연결
• 각 인스턴스는 고성능 볼륨에 대한 read&write 권한을 모두 갖는다.
• ex : 애플리케이션 availability를 높이기 위해 cluster linux 애플리케이션에서 사용, 애플리케이션이 동시 쓰기 작업을 관리해야할 때
• 반드시 cluster-aware 파일시스템을 써야한다.

한 번에 16개의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다.

• HDD (Hard Disk Drives)
  • Cannot be a boot volume
  • Throughput Optimized HDD (st1)
  • Cold HDD (sc1)
  • 높은 처리량과 가장 낮은 비용이 필요할 때

쳐외워 : 32,000 이상의 IOP를 얻으려면 EC2 Nitro와 Io1, Io2가 필요하다.

EBS Snapshot

• EBS 볼륨의 특정 시점에 대한 백업
• 다른 AZ/region에 복사할 수 있다.
• EBS Snapshot Archive : snapshot을 옮길 수 있는 기능
  • 아카이브 티어로 옮기면 아카이브를 복원하는데 24~72시간이 걸린다.
• EBS Recycle Bin : 삭제로부터 EBS 스냅샷 보호, 1day~1yr 보관
• Fast Snapshot Restore : 스냅샷을 완전 초기화해서 첫 사용에서 지연 시간을 없애는 기능
  • 스냅샷이 아주 크고 EBS 볼륨 / EC2 인스턴스를 빠르게 초기화해야 할 때

EBS Encryption

• 저장데이터 / 인스턴스&볼륨 간 전송 데이터 / snapshot / snapshot으로 생성한 볼륨 암호화
• 암호화 및 복호화는 백그라운드에서 EC2와 EBS가 모두 처리
• KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 갖는다.

1. EBS snapshot을 생성한다.
2. 복사 기능을 통해 EBS snapshot을 암호화한다.
3. snapshot을 이용해 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화된다.
4. 암호화된 볼륨을 인스턴스 원본에 연결한다.

AMI (Amazon Machine Image)

• EC2 인스턴스에 설치하고자 하는 모든 소프트웨어를 AMI가 미리 패키징해주기 때문에 부팅 및 설정에 드는 시간을 줄일 수 있다.

1. Customize EC2
2. Stop the instance (ft. data integrity)
3. Build an AMI (ft. EBS snapshots)

EC2 Instance Store (임시 스토리지)

• 해당하는 물리적 서버(EC2 인스턴스)에 물리적으로 연결된 하드웨어 드라이브를 가리킨다.
• I/O 성능 향상
  • Good for buffer / cache / scratch data / temporary content 등
• EC2 인스턴스(=인스턴스 스토어)를 중지/종료하면 해당 스토리지 또한 손실된다.

장기 스토리지의 경우에는 EBS가 적합하다.

EFS (Elastic File System)

• 관리형 NFS(Network File System) that can be mounted on many EC2
  • 서로 다른 AZ에 있는 EC2 인스턴스에도 적용(마운트) 가능 = 여러 AZ에 걸쳐 수백 개의 인스턴스에 연결하는 것이 목표
• EFS에 대한 엑세스를 제어하려면 security group(보안그룹)을 설정해야한다.

Linux 기반 AMI에만 호환된다.

• KMS를 사용해서 EFS 드라이브에서 미사용 암호화를 활성화할 수 있다. = EFS는 KMS에서 제공하는 키를 사용하여 데이터를 저장할 때 자동으로 암호화할 수 있다.
• Linux 표준 파일 시스템이다.
  • 따라서 posix 시스템을 사용하고 파일을 읽고/쓰고/권한을 설정하는 등 파일 작업을 수행할 때 표준 파일 api를 사용하면 된다.
• Scale : 1000s concurrent NFS client, 10GB+ /s throughput
• Performance Mode : General purpose (for latency-sensitive) / Max I/O (for throughput/parallel sensitive)
• Throughput Mode
  • Bursting mode : 실제 사용 중인 스토리지 용량에 따라 처리량을 확장하여 조금 더 늘릴 수 있는 방법
  • Provisioned mode : 스토리지 크기와 관계없이 처리량을 설정하고 싶을 때
  • Elastic mode : workload에 따라 처리량을 자동으로 조절할 수 있다. 즉, EFS 파일 시스템의 크기와 관계없이 필요한 모든 IO를 제공하고 자동으로 확장할 수 있는 기능. workload를 예측하기 어려울 때 유용하다.
    • General Purpose : low-latency
    • Max I/O : 고도로 parallelized(병렬화)된 workload에 적합. 더 높은 지연시간이 걸리는 대신 더 많은 IO
• Storage Tiers : lifecycle management feature
  • Standard : frequent access
    • Availability & Durability (가용성 & 내구성) 측면에서 볼 때, Multi-AZ 설정이 있는 경우 standard tier의 EFS를 사용하는 것이 좋다.
      • standard tier EFS는 데이터를 여러 AZ에 걸쳐 자동으로 복제하여 데이터를 안전하게 보관하기 때문이다. 즉, 하나의 파일 시스템을 여러 AZ에 복제하여, 사용자가 각기 다른 AZ에 있는 인스턴스에서 동일한 파일 시스템을 접근/마운트할 수 있도록 해주는 것.
  • EFS-IA : Infrequent access, cost to retrieve files
  • Arachive : rarely accessed
  • 수명 주기 정책을 구현하여 스토리지 계층 간에 파일을 자동으로 이동할 수 있다.

---

오답노트

Q. EC2 인스턴스에 호스팅된 애플리케이션에 고성능 로컬 캐시를 포함시키려 합니다. EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황입니다. 이런 경우, 솔루션 아키텍트로서 어떤 스토리지 메커니즘을 추천할 수 있을까요?
A. 인스턴스 스토어 → 최적의 디스크 I/O 성능을 제공하기 때문이다.

Q. 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있습니다. 어떤 방법을 추천할 수 있을까요?
A. 인스턴스 스토어 → IOPS 기준이므로
→ 인스턴스 스토어를 사용하는 EC2 인스턴스에 데이터베이스를 실행할 수는 있으나, EC2 인스턴스가 중단되었을 때 데이터가 소실되는 문제가 발생한다. (재시작에는 아무 문제가 없다.)
→ 솔루션1 : 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가진다.
→ 솔루션2 : 데이터에 대한 백업 메커니즘을 설정한다.