[AWS SAA-C03] 7장 EC2 - Instance Storage

이전 6장에서 인스턴스를 stop/terminate 상태가 아닌, hibernate 상태로 하면 이 후 다시 인스턴스를 시작했을 때 부팅 속도를 빠르게 하기위해 RAM 상태를 루트 EBS 볼륨에 저장한다고 했다. 

7장에서는 EBS를 포함하여, 데이터를 저장하는 Instance Storage에 무엇이 있는지 알아보자. 

 

EBS Volume

• EBS (Elastic Block Store) 볼륨은 인스턴스 실행하는 동안 연결할 수 있는 네트워크 드라이브이다.
  • 네트워크 드라이브: LAN, WAN을 통해 여러 컴퓨터에서 공유할 수 있는 저장 공간. USB를 컴퓨터가 연결하는 것과 비슷하게 네트워크 드라이브를 네트워크에 연결하면 여러 사용자가 동시에 접근, 작업할 수 있다. (ex, NAS, google drive)
  • 네트워크 연결: EBS 볼륨은 물리적인 드라이브가 아닌, 네트워크를 통해 연결되기에 약간의 지연이 발생할 수 있다. 
  • 탈부착 가능: 현재 연결된 인스턴스에서 분리해서 다른 인스턴스에 빠르게 연결 가능하다. 
• 데이터 지속성 유지: 인스턴스를 종료해도 EBS 볼륨의 데이터는 유지된다. -> 볼륨 마운트해서 데이터 받아올 수 있다. 
• 단일 인스턴스 연결: 하나의 EBS 볼륨은 한 번에 하나의 인스턴스에만 연결된다. (CCP level에서 제한)
• AZ 제한 : EBS 볼륨은 생성된 AZ에만 연결되어 있기에, 다른 AZ로 이동하기 어렵다. 
  • 하지만, 스냅샷을 사용하여 다른 AZ로 볼륨을 이동할 수 있다. 
• Free tier: 매달 30GB의 무료 EBS storage 제공
• 프로비저닝 용량 : GB와 IOPS를 설정하여 성능 조정할 수 있다. -> 이 후 , 필요에 따라 용량 늘릴 수 있음. 
  • provision : 시스템에 필요한 자원을 '미리' 준비하는 것.
  • IOPS : Input/Output Operations Per Second. 스토리지 장치가 1초 간 처리할 수 있는 입출력 작업의 개수.

EBS 볼륨 예시

위의 그림을 보면, 각 AZ에 EBS가 연결되어 있다. (=다른 AZ 인스턴스에 연결 x)

그리고 하나의 인스턴스가 2개의 볼륨과 연결되어도 된다. (-> 단, 반대로 두 개의 인스턴스가 1개의 볼륨과 연결될 수는 없다.-> 원래는 성능상 하나의 저장소, 볼륨에 2개 이상이 동시에 접근할 수 없는데, 볼륨 중에 고성능인 io1/io2는 1개의 볼륨에 2개 이상의 인스턴스를 연결할 수 있다. -> multi-attach)

 

그리고 EBS 볼륨은 연결되지 않은 상태로도 있을 수 있다. 

 

인스턴스 Terminate 시, EBS 삭제 옵션

EBS 옵션 중, 인스턴스 terminate 시에 EBS 삭제할지 말지 선택할 수 있음.

• EC2 인스턴스 종료 시에, EBS 볼륨을 함께 삭제할지 말지 선택할 수 있다. 
  • default : 루트 EBS 볼륨을 삭제된다. (속성 활성화된 상태)
  • default : 다른 EBS 볼륨은 삭제되지 않는다. (속성 비활성화된 상태 -> 둘 다 활성화 상태가 삭제되는 것임)
• 이 속성은 AWS 콘솔/ AWS CLI 를 통해 제어할 수 있다. 
• Use case : 인스턴스 종료(terminate)되어도 루트 볼륨 유지하고 싶을 때

EBS Volume Types

EBS 볼륨은 크게 6가지로 구분된다. 

• General purpose SSD (gp2/gp3) : 범용 목적이기에 가격, 성능 균형을 잘 맞는 SSD 볼륨이다. 시스템 부팅 볼륨, 가상 데스크톱, 개발/테스트 환경에 많이 사용한다. 용량은 1 GiB - 16 TiB 이다. 
  • gp3 (가장 최신)
    • 기본: IOPS 3000, throughput 125 MiB/s
    • 최대: IOPS 16,000, 쓰루풋 1000 MiB/s까지 독립적으로 증가 가능
  • gp2
    • 작은 gp2 볼륨은 버스트 모드로 최대 3,000 IOPS까지 활용 가능
    • 볼륨 크기와 IOPS는 연결되어 있으며, 최대 IOPS는 16,000
    • 1GB 당 3 IOPS 제공 -> 만약, 5,334GB 볼륨이라면 최대 IOPS 도달한다.)
• Provisioned IOPS (PIOPS) SSD (io1/io2) : 지속적인 IOPS 성능이 요구되는 중요한 애플리케이션에 적합하다. 위의 범용 SSD와 달리 16,000 IOPS 이상의 성능이 필요한 경우에도 사용 가능하다. 데이터베이스 작업(저장소 성능 및 일관성에 민감)에 효과적이다. 또한 EBS multi-attach를 지원한다.  
  • io1 (4 GiB - 16 TiB)
    • 최대 PIOPS: Nitro EC2 인스턴스는 64,000, 다른 인스턴스는 32,000
    • 스토리지 크기와 상관없이 독립적으로 PIOPS 증가 가능
  • io2 Block Express (4 GiB - 64 TiB)
    • 밀리초 이하 지연 시간 (-> 지연 거의 없다.)
    • 최대 PIOPS: 256,000 (IOPS:GiB 비율 1,000:1)
    • + io2가 신상인데 io1이랑 가격 같음 -> io2 쓰자. 

• Hard Disk Drives (HDD) : 앞선 SSD와 달리, 부팅 볼륨으로 사용할 수 없다. 용량은 125 GiB - 16 TiB 이다.
  • 최적화된 처리량 HDD (st1)
    • 빅 데이터, 데이터 웨어하우스, 로그 처리에 적합
    • 최대 처리량 500 MiB/s, 최대 IOPS 500
  • 콜드 HDD (sc1)
    • 거의 사용하지 않는 데이터 보관에 적합
    • 최저 비용이 중요한 경우 사용
    • 최대 처리량 250 MiB/s, 최대 IOPS 250

 

비교를 위해 세부 성능까지 다 정리했지만, 이런 걸 묻는 건 시험에 나오지 않는다. 알아야할 것은 대략적으로 모든 볼륨의 차이점을 이해하는 것이다. (ex. 범용 SSD와 프로비저닝 IOPS SSD의 차이, 어느 상황에 어느 볼륨 타입 고를건지 등)

+ 강의에서, 성능에 관해 이건 언급했음 -> 32000 IOPS 이상을 요할 때는, io1/io2 볼륨의 EC2 Nitro 사용해야 한다.

 

EBS Multi-Attach : io1/io2 family

• EBS 멀티 연결은 동일한 AZ에 있는 여러 EC2 인스턴스에 단일 EBS 볼륨을 연결하는 기능이다. (-> 성능 좋은 io1/io2에서만 가능한 거임.)
• 연결된 각 인스턴스는 볼륨에 대한 읽기 및 쓰기 권한을 모두 가진다.
• 최대 16개의 EC2 인스턴스 연결 가능
• 클러스터 인식 파일 시스템을 반드시 사용해야 함. 
• Use case 
  • Teradata 같은 클러스터링된 Linux 애플리케이션에서 더 고가용성을 달성하기 위해 사용
  • 동시 쓰기 작업을 관리해야 할 때

 

EBS Encryption

RAM 상태를 루트 EBS 볼륨에 저장하면, 볼륨을 암호화해야한다고 했다. 암호화에 대해 더 알아보자

• 암호화 할 수 있는 것들 (그냥,,, 관련된 거면 다 암호화되는 듯)
  • 볼륨 내부의 데이터
  • 인스턴스 - 볼륨 간에 이동되는 데이터 
  • 스냅샷
  • 스냅샷에서 생성된 모든 볼륨
• 암호화/복호화는 모두 투명하게 처리되며, 사용자가 관련하여 특별히 수행해야할 것 없다. 
• 암호화는 latency에 큰 영향을 안준다. 
• EBS 암호화는 KMS(AES-256)의 키를 사용한다. 
• 암호화 되지 않은 스냅샷을 copy하여 암호화할 수 있다. 
• 암호화된 볼륨의 스냅샷은 자동으로 암호화된다.

EBS 볼륨 암호화 순서

1. 볼륨의 EBS 스냅샷 생성
2. 스냅샷 copy 기능을 사용하여 EBS 스냅샷 암호화
3. 암호화된 스냅샷에서 새로운 EBS 볼륨 생성 (이미 볼륨은 암호화 됨.)
4. 이제 암호화된 볼륨을 원래 인스턴스에 연결할 수 있다. 

 

EBS Snapshots

EBS 볼륨은 특정 AZ에 속하기 때문에 다른 AZ에 연결할 수 없다고 했다. 이 때, 다른 AZ에서 쓰기 위해 스냅샷을 사용할 수 있다. 

• 특정 시점의 EBS 볼륨을 백업(스냅샷) 한다. 
• 스냅샷을 위해 볼륨을 분리할 필요는 없지만 권장된다. 
• 다른 AZ, 리전으로 스냅샷을 복사할 수 있다. 

AZ간 스냅샷 복사

스냅샷 기능

• EBS 스냅샷 아카이브 
  • 스냅샷을 75% 저렴한 가격으로 archive tier로 이동한다. 
  • archive 복원은 24~72시간 걸린다. (그래서 싼 듯)
• Recycle Bin for EBS Snapshot
  • 실수로 삭제한 스냅샷을 복구할 수 있도록 삭제된 스냅샷을 일정기간 보관하는 규칙을 설정할 수 있다. (마치 휴지통 처럼)
  • 보관 기간은 1일 ~ 1년까지 가능하다. 
• Fast Snapshot Restore (FSR)
  • 빠르게 스냅샷을 복원할 수 있는 기능이다. 
  • 스냅샷을 처음 사용할 때 지연이 없도록 스냅샷을 완전히 초기화 한다.
  • 비싼 기능이다. 

스냅샷 아카이브, 휴지통

 

AMI

• Amazon Machine Image의 약자
• EC2 인스턴스에서 커스텀된 이미지이다. 
  • 사용자 정의 S/W, 설정, OS, 모니터링 도구 등을 포함할 수 있다. (-> jar로 도커 이미지 만들었듯이, 인스턴스 실행에 필요한 것들을 이미지로 만든다고 이해하면 될 것 같다. )
  • AMI를 사용하면 모든 S/W가 미리 패키징되었기 때문에, 부팅/구성 시간을 단축할 수 있다. (-> 목적에 맞게 세팅된 AMI를 사용하면 커스텀할 거 없이 docker image마냥 가져와서 쓰면 되니까 편할거 같음. 보안 S/W에 맞는 AMI 있으면 편하게 가져다 쓸 수 있을 둣 하다)
• AMI는 특정 리전에서 사용하도록 만들어졌으며, 다른 리전에서 복사해서 사용할 수도 있다. 
• EC2 인스턴스가 실행되는 AMI
  • Public AMI (공개 AMI) : AWS가 제공하는 AMI
  • Your own AMI (사용자 AMI) : 사용자가 직접 생성, 관리하는 AMI
  • AWS Marketplace AMI : 다른 사람이 만든 AMI (마켓에서 판매하기도 가능함)

AMI Process (EC2 인스턴스에서 실행되는 프로세스)

1. EC2 인스턴스를 시작하고, 커스텀도 진행한다. (필요한 설정, S/W 설치하거나, EC2 User Data script 가지고 커스텀 진행)
2. 데이터 무결성을 위해 인스턴스를 정지(stop) 한다. 
3. AMI를 만든다(build). 이 과정에서 EBS 스냅샷도 함께 생성된다.
4. 만든 AMI나 다른 AMI를 사용해서 인스턴스를 실행한다. 

AMI Process

위 그림을 보면 두 개의 인스턴스가 각각 다른 AZ에 있다. 이 때, US-EAST-1A에서 AMI를 커스텀해서 만들었으면 , 다른 AZ인 US-EAST-1B에서는 해당 AMI를 copy해서 쓸 수 있다. 

 

EC2 Instance Store

위에서 본 네트워크 드라이브인 EBS 볼륨도 좋지만, 성능에 한계가 있다. 

따라서 고성능 하드웨어 디스크가 필요한 경우에는 EC2 Instance Store를 사용한다. 

• I/O 성능이 더 좋다. 
• 하지만, 일시적인 저장소이기에 인스턴스가 정지(Stop, terminate) 되면 데이터가 손실된다. 
• 따라서, 버퍼/ 캐시/ 임시 데이터/ 일시적인 콘텐츠 등에 적합하다. (-> 장기 저장할거면 EBS 볼륨 써라!)
• 하드웨어에 장애가 날 경우 데이터 손실 위험이 있다. -> 따라서 백업, 복제 등을 하는게 안전하다. 

Amazon EFS - Elastic File System 

• 여러 AZ에 있는 EC2 인스턴스에 동시에 마운트 가능한 관리형 NFS (Network file System)
• 고가용성 및 확장성 : 여러 AZ에 걸쳐 사용할 수 있기에 고가용성을 제공하고, 스토리지 용량/성능을 필요에 따라 확장할 수 있기에 확장성 제공(auto-scale)
• 사용량 기반 결제 : 사용한 만큼만 비용을 지불하기 때문에, 프로비저닝할 필요 없다.
• 보안 그룹을 사용하여 EFS에 대한 접근을 제어한다.
• 리눅스 기반 AMI와 호환된다. (윈도우 지원x). 표준 파일 API인 POSIX 파일 시스템을 사용하여 리눅스와 유사한 환경을 제공한다. 
• KMS(키 관리 서비스)를 사용하여 암호화한다. 
• Use Case :  데이터 공유, 워드 프레스(블로그, 웹사이트,..) 등

여러 AZ에서 동시에 마운트 가능한 EFS

 

EFS - Performance 

• 동시 NFS 클라이언트 수천개 : 수천개의 클라이언트가 동시에 EFS에 연결 가능하다. 
• 최대 10GB/s 이상의 처리량 (-> 빠르다!)
• autoscale : 최대 페타바이트 규모까지 사용량에 따라 확장된다. 
• Performance Mode (EFS 생성 시 설정)
  • General Purpose (default) : latency에 예민한 작업에 사용
  • MAX I/O : latency는 높지만, throughput이 더 많고, 병렬로 처리해야하는 작업에 사용 (빅데이터, 미디어 처리)
• Throughput Mode
  • Bursting : 스토리지 크기에 따라 처리량이 정해지지만, 버스팅 기능을 사용하여 처리량을 늘릴 수 있다. 
    • ex) 1TB 스토리지의 처리량 = 50MiB/s 일 때 버스팅하면, 최대 100MiB/s 까지 가능
  • Provisioned : 스토리지 크기와 상관 없이 일정한 처리량 유지하도록 설정 
    • ex) 1TB 스토리지에 1GiB/s의 처리량을 지정
  • Elastic : 작업 부하량에 따라 자동으로 처리량 늘리거나 줄인다. (auto-scale) 예측 불가한 작업에 적합하다. 

EFS-Storage Classes

• Storage Tiers (수명 주기 관리) : 파일 사용 빈도에 따라 다른 티어로 이동시킨다. 
  • standard : 자주 사용하는 파일
  • EFS-IA : infrequent access(자주 사용 안하는 파일), 스토리지 비용이 저렴하다.
  • Archive : 거의 사용하지 않는 데이터, 표준 스토리지보다 50% 이상 저렴하다.  
  • -> 스토리지 계층 간에 파일 자동으로 이동하도로 정책을 설정할 수 있다. 
• 가용성 및 내구성
  • Standard : 여러 MZ(multi-AZ)에 데이터를 복제하여 높은 가용성을 제공하기에, 프로덕션 환경에 적합
  • 단일 AZ : 단일 AZ에 데이터를 저장하기에 개발 환경에 적합하다. 기본적으로 백업기능 활성화 되어있으며 EFS-IA와 함께 사용할 수 있다. 표준 스토리지보다 90% 이상 저렴하다. 

EFS 스토리지 계층

 

EBS vs EFS

데이터를 저장하는 건 똑같은데, 세부적인 내용이 너무 다르기에 정리를 해보았다.

	EBS	EFS
인스턴스 연결	인스턴스 1개만 연결 가능 (단, io1/io2는 multi-attach 가능)	여러 AZ에 걸쳐 수백개 이상의 인스턴스 연결 가능
AZ	단일 AZ만 가능하다. -> 스냅샷 복사를 통해 다른 AZ로 이동할 수 있다.	여러 AZ에 걸쳐 마운트 가능하다.
호환 인스턴스	모든 EC2 인스턴스	리눅스 인스턴스만
비용	비교적 저렴	EBS보다는 비쌈
스토리지 계층	없는 듯	지원 -> 접근 빈도에 따라 계층에 다르게 저장해서 비용 절감 가능

 

EBS, EFS

 

세부적인 내용들도 정리했지만, 확실히 EBS, EFS, Instance Store를 비교한 내용은 알아야 한다. 

+ ) 언제 EFS를 사용하는지, 네트워크 파일 시스템 (NFS)에 어떤 옵션을 설정해야하는지 (스토리지 계층, AZ, 성능 Mode 등)