[SAA] EC2 Instance Storage (EBS, AMI, Amazon EFS)

1. EBS(Elastic Block Store)

• EBS Volume
  • 인스턴스가 실행되는 동안 연결할 수 있는 네트워크 드라이브
  • 인스턴스가 종료된 후에도 데이터를 지속적으로 유지할 수 있도록 해줌
  • CCP 레벨에서 한번에 하나의 인스턴스에만 마운트
    • CCP(Certified Cloud Practitioner) Level: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능
    • Associate Level: 일부 EBS 다중 연결
  • 특정 가용 영역(AZ)에만 바인딩
  • EBS = Network USB stick
  • Free tier: 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공
  • 속성
    • 물리적 드라이브가 아닌 네트워크 드라이브
    • 통신을 위한 네트워크가 필요하며 분리하여 다른 인스턴스에 붙일 수 있음
    • 볼륨이기 때문에 미리 용량 및 Provision을 결정해야 함 (size in GBs, and IOPS(단위초당 전송수))
    • 인스턴스에 EBS를 생성한 뒤 연결하지 않아도 됨. 나중에 사용 가능
    • EC2 인스턴스 생성 시에 delete on termante 옵션을 사용하면 같이 사용
  • EBS Snapshot
    • EBS 볼륨의 특정 시점에 대한 백업
    • 다른 AZ 또는 Region으로 백업 가능
    • 기능
      • EBS Snapshot Archive: 스냅샷을 archive tier로 옮겨 75% 싸게 할 수 있고 아카이빙된 스토리지를 복원하는데 24-72시간이 소요
      • Recycle Bin for EBS snapshots: EBS 스냅샷을 삭제하는 경우 영구 삭제 대신 휴지통에 넣는 것. 실수로 삭제해도 보관됨. 휴지통 유지 기간은 1일 - 1년
      • Fast Snapshot Restore (FSR): 스냅샷을 전체 초기화해 첫 사용에서의 지연시간이 없음, 스냅샷이 아주 크고 EBS 볼륨 혹은 EC2 인스턴스를 빠르게 초기화할 때 유용하나 비용이 많이 든다

2. AMI (Amazon Machine Image)

• EC2 인스턴스를 통해 만든 이미지를 통칭 (Customization of an EC2 Instance)
• EC2에 설정하고자 하는 S/W를 pre-package 하기 때문에 속도가 빠름
• AMI 역시 Region Bound 되지만 Region 사이의 복제가 가능
• Public AMI 혹은 사용자 커스텀 AMI 이용 가능
• AMI Process (from an EC2 Instance)
  • EC2 인스턴스를 시작하고 원하는대로 설정
  • 데이터 무결성을 위해 인스턴스 중지
  • AMI 빌드(EBS 스냅샷 생성)
  • 다른 AMI에서 인스턴스 시작

3. EBS Instance Store

• EBS 볼륨은 성능은 좋지만 "제한적인" 네트워크 드라이브이다. 따라서 고성능 하드웨어 디스크가 필요한 경우 EC2 인스턴스 스토어(EC2 Instance Store)를 사용
• 인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지 제공, 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치
• I/O 성능 향상, 그러나 인스턴스 종료 혹은 중지 시 해당 스토리지도 삭제됨
• 버퍼 / cache / scratch data / 일시적인 콘텐츠에 적합
• EC2 인스턴스의 기본 서버에 장애 발생 시 해당 EC2 인스턴스가 연결된 h/w에도 장애가 발생하여 데이터 손실에 대한 위험 존재
• 백업과 복제는 사용자 책임

4. EBS Volumn Types

• EBS 볼륨은 크기, 처리량, IOPS(I/O Ops Per Sec)에 의해 정의
• 종류
  • gp2 / gp3(SSD): 범용 SSD 볼륨, 다양한 작업에 대해 가격과 성능을 균형있게 유지
  • io1 / io2(SSD): 최고 성능의 SSD 볼륨, 미션 크리티컬한 저 지연으로 좋은 성능을 내는 작업에 적합
  • st1 (HDD): 저비용의 HDD 볼륨, 잦은 접근과 처리량이 많은 워크로드에 적합
  • sc1 (HDD): 가장 싼 HDD 볼륨, 접근 빈도가 낮은 워크로드에 적합
• SSD의 특징
  • EC2 인스턴스는 gp2 / gp3 , io1 / io2 만을 부팅 볼륨으로 사용 가능
  • 효율적인 비용, 짧은 지연 시간
  • 시스템 부트 볼륨, 가상 데스크톱, 개발 및 테스트 환경에서 사용 가능
  • 크기 1 GB ~ 16 TB
  • gp3
    • 3,000 IOPS와 125 MiB/s의 처리량 제공
    • IOPS는 최대 16,000, 처리량은 최대 1,000MiB/s까지 독립적으로 이용 가능
  • gp2
    • 짧은 지연시간, 비용 효율적 스토리지, 구버전, 3,000IOPS에 볼륨과 IOPS가 연결되어 있어 볼륨을 증가시킬 때 IOPS가 비례하여 증가
• Provisioned IOPS(PIOPS)
  • IOPS 성능을 유지해야하는 주요 비즈니스 앱이나 16,000IOPS 이상을 요구할 때
  • 일반적으로 DB workload에 사용(스토리지 성능과 일관성에 민감)
  • io1/io2 (4 GiB - 16 TiB)
    • Nitro EC2 인스턴스의 최대 PIOPS는 64,000, 기타 인스턴스의 경우 32,000
    • 스토리지 크기와 독립적으로 PIOPS를 증가시킬 수 있음
    • io2는 io1과 동일한 비용으로 더 높은 내구성 및 GiB 당 더 많은 IOPS를 가짐
  • io2 Block Express (4 GiB - 64 TiB)
    • 지연 시간이 밀리초 미만
    • IOPS:GiB 비율이 1,000:1 일 때, 최대 PIOPS는 256,000
    • EBS 다중 연결을 지원
• Hard Disk Drives (HDD)
  • 부팅 볼륨으로 사용 불가
  • 125 GiB ~ 16 TiB
  • st1 (처리량 최적화)
    • 빅데이터, 데이터 웨엉하우스, 로그처리에 적합
    • 최대 처리량 500 MiB/s, 최대 IOPS 500
  • sc1 (콜드 HDD)
    • 아카이브 데이터용, 접근 빈도가 낮은 데이터에 적합
    • 최저 비용이 중요한 경우
    • 최대 처리량 250 MiB/s, 최대 IOPS 250
• EBS Multi-Attach (io1/io2 family)
  • 동일한 EBS 볼륨을 동일한 가용 영역 내의 여러 EC2 인스턴스에 연결 가능
  • 각 인스턴스는 고성능 볼륨에 대한 읽기 및 쓰기 권한을 가짐
  • 최대 16개의 EC2 인스턴스에 동시 연결 가능
  • 다중 연결 실행 시 클러스터 인식 파일 시스템을 사용해야 함(XFS, EXT4 불가)
  • 사용 예시
    • 클러스터링된 Linux 응용 프로그램(Teradata)에서 더 높은 응용 프로그램 가용성 달성
    • 애프리케이션이 동시 쓰기 작업을 관리해야할 때 사용
• EBS Encryption
  • 암호화된 EBS를 생성하면 암호화가 동시 다발적으로 발생
    • 저장 데이터가 볼륨 내부에 암호화
    • 인스턴스와 볼륨 간의 전송 데이터 또한 암호화
    • 모든 스냅샷 암호화
    • 스냅샷에서 생성된 볼륨 암호화
  • 암호화 및 복호화 매커니즘은 보이지 않게 처리되고, 암호화는 지연 시간에 영향을 미치지 않음
  • KMS에서 암호화 키를 생성하여 AES-256 암호화 표쥰을 사용
  • 암호화되지 않은 스냅샷 복사를 통해 암호화 가능
  • 암호화된 볼륨의 스냅샷은 암호화
  • 암호화되지 않은 EBS 볼륨의 암호화 과정
    • 볼륨의 EBS 스냅샷 생성
    • EBS 스냅샷을 복사하여 암호화
    • 스냅샷로 새 EBS 볼륨 생성(해당 볼륨도 암호화)
    • 암호화된 볼륨을 인스턴스 원본에 연결

5. Amazon EFS(Elastic File System)

• 여러 EC2에 마운트되는 NFS(Network File System)을 관리하는 것

• EFS는 multi AZ에서 EC2 인스턴스들에 작용

• 가용성과 확장성이 높지만 gp2 EBS 볼륨에 비해 3배정도 비쌈

• 사용량만큼 지불하기 때문에 프로비저닝 불필요

• 콘텐츠 관리, 웹서빙, 데이터공유, wordpress 등에 사용

• NFSv4.1 프로토콜 사용

• EFS에 대한 액세스 제어를 위해 보안 그룹 사용

• Linux 기반 AMI 에서만 사용 가능(윈도우 는 불가)

• POSIX File System을 이용하여 표준 File API로 이용

• 파일 시스템이 자동으로 확장되고 사용량에 따라 요금 지불

• 성능

  • EFS Scale
    • 수천개의 NFS 클라이언트에서 EFS에 동시에 액세스할 수 있게 확장
    • 10GB+/s의 처리량
    • 용량을 미리 프로비저닝하지 않아도 네트워크 파일 시스템이 PB 규모로 자동 확장

• 저장 클래스

  • perfomance mode
    • 범용 모드(기본값): 작업당 지연 시간이 가장 짧으며 파일 시스템에 권장되는 성능 모드 (웹 서버, CMS 등)
    • Max I/O: 지연 시간이 늘어나긴 하지만 처리량과 병렬 처리 기능 향상(빅데이터, 미디어 처리 등)
  • 처리량 모드
    • Bursting: 1TB = 50 MiB/s + Burst of up to 100 MiB/s, 파일 시스템과 비례하여 용량이 커지고 버스팅됨
    • Provisioned: 스토리지 크기와 관계없이 처리량 설정 가능
    • Elastic: 작업 부하에 따라 처리량을 자동으로 조정, 읽기에 대해 최대 3GiB/s, 쓰기에 대해 최대 1GiB/s까지 지원, 예측할 수 없는 작업 부하에 사용

• Storage Class Options

  • Storage tier(수명주기 관리 기능 - n일 후 파일 이동)
    • Standard: 액세스가 빈번한 파일
    • infrequent access (EFS-IA): 파일을 검색하는데 비용이 들지만, 저장 비용은 낮음, 수명주기 정책을 사용해야 함
  • Availability and durability(가용성 및 내구성)
    • Standard: EFS를 Multi-AZ에 설정함. 프로덕션에 유용함
    • One Zone: EFS 1개 AZ에 설정, dev 환경에 적합 IA 사용 가능, 요금을 90% 정도 절감 가능

6. EBS vs EFS

• EBS(Elastic Block Storage)

  • 한 인스턴스에만 연결되고 하나의 AZ에 종속, 특정 가용 영역에 한정적임
  • gp2: IO 증가하면 disk size 증가
  • io1: IO만 독립적으로 증가 가능
  • 실제 사용한 양이 아닌 EBS 드라이브 크기에 따라 정해진 사용량을 지불
  • EBS 볼륨을 다른 AZ로 이동 시
    • 스냅샷 -> EBS snapshot을 타 AZ에 복원
    • EBS 백업은 IO를 사용하므로 앱이 큰 트래픽을 사용중에는 실행하지 않는 것이 좋음
    • EC2가 종료되면 root EBS 볼륨도 설정에 따라 종료될 수 있음

• EFS(Elastic File System)

  • 수백개의 인스턴스들을 여러 AZ에 생성 가능
  • 파일 공유
  • 리눅스 인스턴스에서만 사용 가능(POSIX)
  • EBS보다 최소 3배 비싸다, EFS-IA를 통해 절약 가능

• 요약

  • EBS: 1:1로 대응되고 AZ가 한정적임
  • EFS: 다수 인스턴스에 연결해야하는 네트워크 파일 시스템에 적합
  • Instance Store: EC2 인스턴스가 IO를 최대로 쓰게 해주지만 인스턴스가 망가지면 함께 망가지는 임시 드라이브