04. EC2 인스턴스 스토리지

1. EC2 인스턴스 스토리지

1장. EBS 개요

01) EBS Volume 이란?

• Elastic (탄력적인) : 볼륨의 크기를 사용자의 필요에 맞게 조절할 수 있다는 뜻
• Block Store (블록 저장소) : 데이터를 블록 단위로 저장하는 방식
• Volume (볼륨) : 데이터를 저장하는 데, 사용되는 저장공간의 단위
  • 인스턴스가 실행되는 동안 연결할 수 있는 네트워크 드라이브이다.
  • 인스턴스가 종료된 후에도 데이터를 지속적으로 유지할 수 있도록 해준다.
  • 이전 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있다.
  • 이 드라이브는 EC2 인스턴스에 연결되어 지속적인 스토리지를 제공한다.
  • EBS 볼륨은 클라우드 컴퓨터의 USB 드라이브라고 생각하면 된다.
  • CCP 레벨에서 한 번에 하나의 인스턴스에만 마운트될 수 있다.
    CCP 레벨: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능
    Associate 레벨: 일부 EBS 다중 연결
  • EBS 볼륨을 생성할 때, 특정 가용 영역에 바인딩된다.
  • "네트워크 USB 스틱"으로 생각해볼 수 있다!
  • Free tier: 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공한다.

 

02) EBS Volume의 특징

(1) 네트워크 드라이브 입니다. ( 물리적 드라이브는 아님! )

• 인스턴스와 EBS 볼륨이 서로 통신하기 위해서 네트워크를 사용합니다. 그렇기 때문에 약간의 지연이 발생할 수 있음.
• EC2 인스턴스에서 분리하여 다른 인스턴스에 빠르게 연결할 수 있음.

(2) 특정한 가용 영역(Availability Zone)에 잠겨 있습니다.

• 같은 가용영역만 연결 가능! (us-east-1a의 EBS 볼륨은 us-east-1b에 연결할 수 없음.)
• 다른 가용 영역으로 이동하려면 먼저 스냅샷을 만들어야 함.

(3) 용량을 미리 결정해야 합니다. (size in GBs, and IOPS[단위 초당 전송 수] )

• 할당 용량에 대해 청구됨.
• 시간이 지남에 따라 드라이브 용량을 증가시킬 수 있음.

 

03) EBS Volume 예시

• 하나의 인스턴스에 두 개의 EBS 볼륨을 연결하는 건 가능.
• 여러 인스턴스에 하나의 EBS 볼륨을 연결하는 건 불가능!

 

04) EBS – EC2 인스턴스 삭제 시, EBS 볼륨 삭제 여부 설정

(1) EC2 인스턴스가 종료될 때, EBS 볼륨의 동작을 제어한다.

• 기본적으로 루트 EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정되어 있음.
• 추가된 다른 EBS 볼륨은 삭제되지 않음.

(2) AWS 콘솔 / AWS CLI에서 제어 가능

• 사용 사례: 인스턴스가 종료될 때 루트 볼륨을 보존.

---

2장. EBS Snapshots

01) EBS 스냅샷이란?

• EBS 볼륨의 특정 시점에 대한 백업(스냅샷)을 생성할 수 있다.
• 스냅샷을 만들기 위해 볼륨을 분리할 필요는 없지만 권장된다.
• 스냅샷은 다른 AZ 또는 리전을 거쳐 복사할 수 있다.
  

  

 

2) EBS Sanpshots의 기능
(1) EBS Snapshot 아카이브

• 최대 75%까지 저렴한 "archive tier"로 스냅샷을 옮길 수 있는 기능.
  아카이브를 복원하는 데 24시간에서 최대 72시간이 걸린다. 즉시 복원되는 것이 아님.

 

(2) EBS Snapshots 복원

• EBS 스냅샷을 삭제하면 휴지통에 보관됩니다.
• 실제로 삭제하는 경우를 대비해, 이미 삭제된 스냅샷을 보관하고 필요 시 복원할 수 있도록 규칙을 설정할 수 있음.
• 삭제 후 유지할 스냅샷 보존 기간은 1일부터 1년까지 지정 가능.

 

(3) 빠른 Snapshot 복원 (FSR)

• 첫 사용 시 지연 시간을 없애기 위해 스냅샷의 전체 초기화를 강제로 실행하는 기능 ($$$)

---

3장. AMI (Amazon Machine Image) - 인스턴스 이미지 복사

01) AMI의 의미

• Amazon : AWS 클라우드의
• Machine : 가상 서버 인스턴스(가상 머신)
• Image : 전체 서버의 이미지

=> AMI는 사용자 전용 EC2 인스턴스 (커스텀 버전) 입니다.
(소프트웨어, 구성, 운영 체제, 모니터링 등을 직접 추가할 수 있음.)

 

02) AMI의 개요

• 사용자가 원하는 소프트웨어를 미리 구성해 놓은 이미지 입니다.
• 모든 소프트웨어가 미리 패키지되어 있으므로 부팅 및 구성 시간이 더욱 빠름.
• AMI는 해당 지역에서만 생성이 가능함. (여러 지역에 걸쳐 복사할 수 있습니다)

 

03) AMI의 종류

• 공용 AMI: AWS에서 제공하는 AMI
• 사용자 AMI: 직접 만들고 유지 관리하는 AMI
• AWS Marketplace AMI: 다른 사람이 구축한 AMI (혹은 판매하는 AMI)

 

04) AMI의 Process (from an EC2 instance)

• EC2 인스턴스를 시작하고 이를 사용자 지정으로 설정합니다.
• 데이터 무결성을 위해 인스턴스를 중지한다.
• AMI를 빌드한다. (이 과정에서 EBS 스냅샷도 생성된다.)
• 다른 AMI에서 인스턴스를 시작한다.

---

4장. ECS 인스턴스 스토어

01) ECS 인스턴스 스토어란?

• EBS 볼륨의 성능은 "제한적인" 이다.
• 기존의 볼륨보다 더 높은 성능을 요구할 수 가 있다.
• EC2 인스턴스에 연결된 하드웨어 디스크 성능은 향상되어야 한다.
  => 따라서 고성능 하드웨어 디스크가 필요한 경우 특정 유형의 EC2 인스턴스를 사용하는데,
• 이 인스턴스를 EC2 인스턴스 스토어(EC2 Instance Store)를 사용할 수 있다.

 

02) ECS 인스턴스 스토어의 역할

• 인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공한다.
• 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치한다.

 

03) EC2 인스턴스 스토어의 목적

• I/O 성능 향상
  (인스턴스를 최대 절전 모드 혹은 종료하면 인스턴스 스토어의 모든 스토리지 블록이 리셋. => 임시 스토리지라고도 불림 )
• 버퍼 / 캐시 / 스크래치 데이터 / 일시적인 콘텐츠에 적합함.
• EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 존재함.
• 백업과 복제는 사용자의 책임!

---

5장. EBS Volume의 유형

01) EBS 볼륨의 6가지 유형

• gp2 / gp3 (SSD): 범용 SSD 볼륨. 다양한 작업에 대해 가격과 성능을 균형있게 유지함.
• io1 / io2 (SSD): 최고 성능의 SSD 볼륨. 미션 크리티컬한 저지연 또는 고처리량 작업에 사용함.
• st1 (HDD): 저비용 HDD 볼륨. 자주 액세스되는 처리량 중심 작업을 위해 설계됨.
• sc1 (HDD): 최저 비용 HDD 볼륨. 접근 빈도가 낮은 워크로드를 위해 설계됨.

 

02) EBS 볼륨의 정의

• EBS 볼륨은 크기, 처리량, IOPS(I/O Ops Per Sec)에 의해 정의된다.
• gp2/gp3 및 io1/io2만 부팅 볼륨으로 사용할 수 있습니다! (중요)

 

03) 범용 SSD

• 효율적인 비용, 짧은 지연 시간
• 시스템 부트 볼륨, 가상 데스크톱, 개발 및 테스트 환경에서 사용 가능.
• 크기: 1 GiB - 16 TiB

(1) gp3

• 기본적으로 3,000 IOPS와 125 MiB/s의 처리량을 제공.
• IOPS는 최대 16,000까지, 처리량은 최대 1000 MiB/s까지 독립적으로 증가 가능.

(2) gp2

• 작은 gp2 볼륨으로 IOPS를 3,000까지 버스트할 수 있음
• 볼륨과 IOPS의 크기가 연결되어 있으며 최대 IOPS는 16,000
• GB당 3 IOPS, 즉 5,334GB에서 최대 IOPS를 제공

04) IOPS (PIOPS) SSD

• IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션
• 혹은 16,000 IOPS 이상이 필요한 애플리케이션에 적합함.
• 데이터베이스 워크로드에 적합 (스토리지 성능과 일관성에 민감)

(1) io1/io2 (4 GiB - 16 TiB):

• Nitro EC2 인스턴스의 최대 PIOPS는 64,000, 기타 인스턴스의 경우 32,000.
• 스토리지 크기와 독립적으로 PIOPS를 증가시킬 수 있음.
• io2는 io1과 동일한 비용으로 더 높은 내구성 및 GiB 당 더 많은 IOPS를 가짐.

(2) io2 Block Express (4 GiB - 64 TiB):

• 지연 시간이 밀리초 미만.
• IOPS: GiB 비율이 1,000:1 일 때, 최대 PIOPS는 256,000.

(3) EBS 다중 연결을 지원.

 

05) 하드디스크 드라이브 (HDD)

• 부팅 볼륨으로 사용할 수 없음.
• 125 GiB - 16 TiB

(1) 처리량 최적화 HDD (st1):

• 빅 데이터, 데이터 웨어하우스, 로그 처리에 적합.
• 최대 처리량 500 MiB/s, 최대 IOPS 500.

(2) 콜드 HDD (sc1):

• 아카이브 데이터용. 접근 빈도가 낮은 데이터에 적합함.
• 최저 비용이 중요한 경우
• 최대 처리량 250 MiB/s, 최대 IOPS 250

 

✅ EBS - Volume Types Summary

---

6장. EBS 다중 볼륨

01 ) EBS 다중 연결 - io1 / io2 family

• 동일한 EBS 볼륨을 동일한 가용 영역 내의 여러 EC2 인스턴스에 연결 가능.
• 각 인스턴스는 고성능 볼륨에 대한 읽기 및 쓰기 권한을 전부 가짐.

- 사용 사례

• 클러스터링된 Linux 응용 프로그램 (예: Teradata)에서 더 높은 응용 프로그램 가용성 달성
• 애플리케이션이 동시 쓰기 작업을 관리해야할 때 사용.
  - 최대 16**개의 EC2 인스턴스 동시 연결 가능.
  - 다중 연결을 실행하기 위해서는 **클러스터 인식 파일 시스템을 사용해야 함 (XFS, EXT4 등은 불가능)

---

7장. Amazon EFS

01) Amazon EFS – Elastic File System (공유 파일 시스템)

• 여러 EC2 인스턴스에 마운트할 수 있는 관리형 네트워크 파일 시스템
• 서로 다른 가용 영역에 있는 EC2 인스턴스에도 가능.
• 고가용성 및 확장성이 뛰어나며, 비용이 비쌈. (gp2의 3배), 사용량에 따라 비용이 청구되므로 미리 용량을 프로비저닝하지 않아도 됨.
  

  

• 사용 사례: 콘텐츠 관리, 웹 서빙, 데이터 공유, Wordpress
• NFSv4.1 프로토콜 사용
• EFS에 대한 액세스를 제어하기 위해 보안 그룹 사용.
• Linux 기반 AMI와 호환됨. (Windows는 불가능)
• KMS를 사용하여 EFS 드라이브에 저장 데이터 암호화를 활성화할 수 있음.
• Linux의 표준 파일 시스템: 표준 파일 API를 갖는 POSIX 파일 시스템
• File system scales automatically, pay-per-use, no capacity planning!

02) EFS의 역량
(1) EFS 크기

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

(2) EFS 성능
- 범용 모드 (**기본값**): 작업당 지연 시간이 가장 짧으며 파일 시스템에 권장되는 성능 모드 (웹 서버, CMS 등)
- Max I/O: 지연 시간이 늘어나긴 하지만 처리량과 병렬 처리 기능 향상 (빅데이터, 미디어 처리 등)

(3) EFS**의** 처리량 모드
- Bursting: 1TB = 50MiB/s + burst of up to 100 MiB/s
- Provisioned: 스토리지 크기와 관계없이 처리량을 설정할 수 있음. (ex. 1 GiB for 1 TB storage)
- Elastic: 작업 부하에 따라 처리량을 자동으로 조정함.

• 읽기에 대해 최대 3GiB/s, 쓰기에 대해 최대 1GiB/s까지 지원.
• 예측할 수 없는 작업 부하에 사용됨.

 

03) 스토리지 클래스
(1) 스토리지 티어 (**수명주기** 관리 기능 - n**일** 후 파일 이동**)**

• Standard: 액세스가 빈번한 파일은 보통 Standard 계층에 저장
• Infrequent access (EFS-IA): 파일을 검색하는데 비용이 들지만, 저장 비용은 낮음. EFS-IA를 활성화하려면 수명 주기 정책을 사용해야 함.
  

  

(2) 가용성 및 내구성

• 표준: Multi-AZ, 제품에 적합
• One Zone: One AZ, great for dev, 기본적으로 백업이 활성화되어 있음. IA와 호환됨 (EFS One Zone-IA)

(3) 비용을 90% 이상 절감할 수 있음

---

8장. EBS vs EFS 비교하기

01) EBS - Elastic Block Storage

(1) EBS 볼륨:

• 한 번에 하나의 인스턴스에만 연결 가능.
• 특정 가용 영역에 한정됨.
• gp2: 디스크 크기가 늘어나면 IO도 함께 증가함.
• io1: IO를 볼륨 크기와 관계 없이 독립적으로 증가시킬 수 있음.

(2) EBS**를** 다른 가용 영역으로 옮기려면

• 스냅샷 만들기
• 다른 AZ에서 스냅샷 복원
• 해당 AZ에 EBS 볼륨 생성
• EBS 백업은 IO를 사용하므로 애플리케이션이 많은 트래픽을 처리하는 동안 실행하지 않는 것이 좋음
  - 인스턴스의 루트 EBS 볼륨은 EC2 인스턴스가 종료되면 기본적으로 종료됨. (이를 비활성화할 수 있음)
  - EBS는 실제 사용한 양이 아닌 EBS 드라이브의 크기에 따라 정해진 사용량을 지불함.

 

02) EFS - Elastic File System

• 여러 가용 영역에서 수백 개의 인스턴스를 마운트할 수 있음.
• EFS는 WordPress 같은 웹 사이트 파일을 공유할 때에도 쓰임.
• Linux 인스턴스 전용 (POSIX)
• EFS는 EBS보다 높은 가격대를 가짐.
• EFS는 사용한 만큼만 비용이 청구됨.
• 비용 절감을 위해 EFS-IA를 활용할 수 있음.

 

※ Remember: EBS vs EFS vs Instance Store

• EBS: 네트워크 볼륨을 한 번에 하나의 인스턴스에 연결할 수 있고 특정 AZ 내로 한정.
• EFS: 다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합.
• Instance store: EC2 인스턴스에 IO를 최대로 사용하게끔 해주지만, 인스턴스가 망가지면 함께 망가지는 임시 드라이브.