[AWS] EC2 Hibernate 모드, EBS

EC2 Hibernate (절전 모드)

기존에 쓰던 것들
- Stop: disk의 데이터(EBS)가 다시 시작할 때까지 유지됨
- Terminate: 지우도록 설정한 EBS volumes들은 다 삭제됨. 남기도록 설정한거만 남음
다시 시작할 경우
- OS 부팅 & EC2 User Data Script도 돌아감
- OS 부팅 끝 (boot up) -> 애플리케이션 실행 -> 캐시 구성 시작 => 시간이 걸림


Hibernate
- RAM에 있던 in-memory state는 보존 (EBS volume에 덤프되고, EC2에서는 RAM이 사라지는 원리. 다시 시작하면 EBS volume에 있던 RAM을 다시 인스턴스에 올림)
- OS가 완전히 중지되는 게 아니라서 인스턴스 부팅이 빨라짐
- RAM에 기록되었던 in-memory state는 root 경로의 EBS volume에 기록되기 때문에, root EBS volume을 암호화 해야하고, volume 용량도 RAM을 저장하기 충분해야함!!!
use case:

- long-running 프로세스
- RAM state 저장하고 싶을 때
- 빠르게 재부팅하고 싶을 때
- 초기화할때 시간을 많이 잡아먹는 (그래서 중단하고싶지않은) 서비스

 

EC2 Hibernate 알면좋은것들
- C, M, R, T 등 여러 Instance families 지원
- 인스턴스 RAM 크기가 최대 150GB
- bare metal 인스턴스 지원X
- AMI (시작 사양): 리눅스, 윈도우 등 지원
- Root Volume은 무조건 EBS여야 함. 암호화 필요. 덤프된 RAM을 보관할만큼 충분한 용량 필요
- On-Demand, Reserved, Spot 인스턴스에서 사용 가능
- 최대 60일

 

실습!!
- instance 만들 때 advanced 탭에서 Stop - Hibernate behavior를 enable해야됨
- hibernate 하려면 RAM을 저장할 root volume의 공간 충분해야하고 암호화되어있어야 하니까 configure storage의 advanced 누르고, volume에서 encrypted를 yes로 두고 KMS 키 설정

 

EBS (Elastic Block Store) Volume
: 인스턴스가 실행중인 동안 연결가능한 Network drive => 여기저기 연결되지만 실제 물리적 연결은 없는 네트워크 USB정도로 생각하면 됨!
- EBS volume을 쓰면 인스턴스 terminate한 뒤에도 데이터 남아있게 됨
- 한 번에 한 인스턴스에만 붙을 수 있음! (Certified Cloud Practitioner 레벨에서...Associate Level(Architect 등)에서는 몇몇 EBS에 대해 "multi-attach" 기능이 있음) 하지만 한 인스턴스는 여러 EBS volume 붙일 수 있음
- AZ 안에서만 바운딩 됨 (한 AZ에서 생성된 경우 다른 AZ의 인스턴스로는 연결 불가)
- 무료티어로는 매달 30GB를 general SSD나 magnetic 유형으로 매달 제공
- EBS Volume은 "네트워크" 드라이브이기 때문에, 인스턴스와 EBS volume이 서로 통신하기 위해서 네트워크 사용 -> 컴퓨터가 다른 서버에 도달하기까지 latency 있음
- 네트워크 드라이브니까 EC2 인스턴스에서 분리, 다른 인스턴스로 빠르게 연결 가능
- 한 AZ안에서만 쓸 수 있지만, snapshot을 하면 다른 AZ로 이동 가능
- provisioned capacity (GB, IOPS(초당 I/O전송수)) 용량을 미리 결정해야함 -> 그거에 따라 billing 결정, 이후 설정 바꿀 수 있음

 

EBS - ⭐️Delete on Termination 속성⭐️
: 인스턴스 처음 만들 때 Delete on Termination(종료 시 삭제) 체크할 수 있음. 디폴트는 Root volume에 체크돼있고, 다른 EBS volume들은 체크 안돼있음
- 이 옵션을 통해, EC2 인스턴스 terminate할 때 EBS behavior 제어할 수 있음
use case⭐️:
- 인스턴스가 종료될 때 root volume을 유지하고자 하는 경우, 인스턴스 만들 때 이 속성에서 체크박스 해제하면 됨

 

EBS snapshot
: EBS volume의 특정 시점에 대한 백업
- snapshot 할 때 EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만 권장됨
- EBS 스냅샷을 다른 AZ나 리전에 복사 가능 -> AWS의 다른 리전에 데이터 백업 시 완전 유용!!

EBS snapshot 기능
- EBS Snapshot Archive: snapshot을 75% 저렴한 Archive Tier로 옮김. 복원하는데 24~72시간 걸림
- Recycle bin for EBS snapshots: 잘못 지웠을 경우 retention(복원) 가능하도록 룰 설정. 휴지통에 보관되는 기간은 1일~1년으로 설정 가능)
- Fast Snapshot Restore (FSR): snapshot을 완전 초기화해, 첫 사용 시 latency를 없앰. snapshot이 아주 크고 EBS volume 또는 EC2 인스턴스를 빠르게 초기화해야 할 경우 유용. 비용 많이 듦

 

AMI (Amazon Machine Image)
: EC2 인스턴스를 통해 만든 이미지 통칭
- AMI로 AWS를 구축할 수도 있고, 원하는대로 변경도 가능 -> 부팅 및 configuration에 드는 시간 줄일 수 있음 (EC2 인스턴스에 설치하고자 하는 모든 SW를 AMI가 미리 패키징해주니까)
  ex) 원하는 SW, configuration, OS, 모니터링 툴 등 추가 가능
- AMI는 지역 단위로 구축됨 (근데 다른 지역으로 복사 가능)

- EC2 인스턴스 구축가능한 AMI 종류
  1. Public AMI (AWS가 제공) ex) Amazon Linux2 AMI
  2. 내가 만든 AMI: 내가 만들어서 유지,관리 가능
  3. AWS 마켓플레이스 AMI: 다른 사람이 구축한 이미지 (사서) 사용

 

AMI가 EC2 인스턴스에서 처리되는 과정
1. EC2 인스턴스를 원하는대로 설정
2. 인스턴스를 중지, 데이터 integrity 확보 (데이터 바뀌지 않게)
3. 이 인스턴스 바탕으로 AMI 구축 (이 과정에서 EBS 스냅샷이 생성됨)
4. 이 AMI에서 다른 리전 실행하면 그안에 복사된 새 인스턴스가 들어있을 것

 

EC2 Instance Store
: 인스턴스는 가상이지만 물리적 서버에 연결되어 있고, 이와 같은 서버에는 해당 서버에 물리적으로 연결된 디스크 공간이 있음. 그래서 EC2 Instance Store는 이 물리적 서버에 연결된 HW 드라이브를 가리킴
- EC2 volume은 성능이 제한됨 -> 더 high-performance HW 디스크 원한다면 EC2 Instance Store를 사용하자
- I/O performance 더 좋음 (물리적으로 연결돼있으니까 throughput 좋음)
- 인스턴스 중지하면 Instance store도 storage 잃음 -> ephemeral (임시) storage라고 불림
- 버퍼, 캐시, scratch data, temporary content에 적합, 장기 보관에는 부적합 (장기는 EBS에!!)
- HW fail시 데이터 손실 위험 -> 필요에 따라 데이터 백업, 복제해놓자

 

EBS volume 유형 6개
- gp2/gp3: general SSD volume. 다양한 워크로드에 대해 가격과 성능 밸런스 굿
- io1/io2: high-performance SSD volume. mission critical(중요한 데이터), low-latency, high-throughput workloads
- st1: low cost HDD volume. 잦은 접근, throughput-intensive workload에 적합
- sc1: 가장 저비용 HDD voluem. 접근빈도 낮은 workload에 적합

EBS volume 기준: size/Throughput/IOPS (I/O Ops per Sec)

- 인스턴스에 대해, gp2/gp3, io1/io2만이 boot volumes (root OS가 실행되는곳)로 쓰일 수 있음!!

 

⭐️General Purpose SSD⭐️ (gp2/gp3)
- latency 낮고, cost도 좋은 storage
- System boot volumes, 가상 데스크톱, 개발, 테스트 환경에서 사용 가능
- 크기: 1GB~16TB

- gp3:
  1. 기본 성능으로 3000 IOPS, 125MiB/s throughput
  2. IOPS는 최대 16000, throughput은 최대 1000MiB/s까지 서로 독립적으로 올릴 수 있음(둘이 연결돼있지 않음)

- gp2:
  1. 작은 gp2 volume은 IOPS 최대 3000
  2. volume과 IOPS가 연결돼있음 -> volume 늘리면 최대 IOPS가 16000
  3. 3 IOPS per GB라서, 예를들어 volume이 5334 GB면 최대 IOPS 넘어가버림

 

Provisioned IOPS (PIOPS) SSD
- IOPS 성능을 유지할 필요가 있는 중요한 애플리케이션
- 16000 IOPS 이상을 요구하는 애플리케이션
- 일반적으로 DB workload에 적합 (storage performance와 consistency 중요하니까)

- io1/io2 (4TiB ~ 16TiB)
  1. Nitro EC2 인스턴스에서는 최대 64000 IOPS까지 가능, Nitro 아니면 32000 IOPS까지 지원
  2. PIOPS를 storage 크기와 관계없이 키울 수 있음
  3. io2 장점: io1과 같은 비용을 내구성과 GiB당 IOPS 수가 더 높음

- io2 Block Express (4 GiB ~ 64 TiB)
  1. sub-millisecond latency (더 고성능)
  2. IOPS:GB 비율이 1000:1이라고 하면, io2 Block Express는 최대 256,000 IOPS
- EBS multi-attach 지원

 

Hard Disk Drives (HDD) (st1/sc1가 해당)
- boot volume일 수 없음
- 125 MiB~16 TiB
- 두 가지 종류의 volume 제공:

  1. Throughput Optimized HDD (st1)
    -> 빅데이터, 데이터 warehouses, log processing에 적합
    -> 최대 throughput 초당 500MB, 최대 IOPS 500
  2. Cold HDD (sc1)
  -> 접근 빈도 낮은 데이터에 적합
  -> 가격 낮음
  -> 최대 throughput 250 MB/s, 최대 IOPS 250
=> 세세하게 다 외울 필요 없고 차이를 짚고 넘어가자