[AWS/Cloud] 강의 노트 : EC2 인스턴스 스토리지

---

 

• •  

EBS

• Elastic Block Store의 줄임말
• 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브
• EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있다
• 한 번에 하나의 인스턴스에만 마운트할 수 있다
• 특정 가용 영역에서만 가능

 

EBS 볼륨

• 네트워크 USB 스틱이라고 생각하자
  • USB 스틱처럼 한 컴퓨터에서 꺼내 다른 컴퓨터에 꽂아 사용
  • 실제 물리적 연결은 없음. 네트워크를 통해 연결
    • 네트워크 연결을 통한 지연이 발생할 수 있음
  • 하나의 가용 영역에 한정됨
  • cf. 스냅샷을 이용하면 다른 가용 영역으로도 볼륨을 옮길 수 있다
  • 사용량 프로비저닝 필요
• EC2 인스턴스를 통해 EBS 볼륨을 생성할 경우 ⇒ 종료 시 삭제 속성이 있다
• 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 → 즉 데이터를 저장하고자 하는 등의 경우, 루트 볼륨의 종료 시 삭제 속성을 비활성화

---

EBS 스냅샷

• EBS 볼륨의 특정 시점에 대한 백업
• 다른 가용 영역이나 다른 리전에도 복사할 수 있다

스냅샷의 기능

• 스냅샷 아카이브 : 아카이브 티어로 스냅샷을 옮길 수 있는 기능
  • 아카이브로 옮기면 아카이브를 복원하는데 24시간에서 72시간이 걸린다
• EBS 스냅샷 휴지통 : 스냅샷을 삭제할 때 영구 삭제하는 대신 휴지통에 넣을 수 있다 → 실수로 넣었을 때 복원 가능
• 빠른 스냅샷 복원(FSR) : 스냅샷을 완전 초기화, 지연 시간을 없애는 기능, 많은 비용 발생
  • Fast Snapshot Restore

---

AMI (Amazon Machine Image)

• EC2 인스턴스를 통해 만든 이미지
• AMI에 원하는 소프트웨어 or 설정 파일을 추가, 별도의 운영 체제를 설치, 모니터링 툴 추가 가능
• AMI를 따로 구성하면 부팅 및 설정에 드는 시간을 줄일 수 있다
  • EC2 인스턴스에 설치하고자 하는 모든 소프트웨어를 AMI가 미리 패키징
  • AMI를 특정 지역에 구축한 다음, 다른 지역으로 복사 → AWS 글로벌 인프라를 활용
• EC2 인스턴스 launch 방식
  • 퍼블릭 AMI
  • 직접 구축한 AMI
  • 다른 사람이 구축한 AMI를 AWS 마켓플레이스를 통해 구매해서 사용

 

AMI 처리 과정

1. EC2 인스턴스를 원하는 대로 설정
2. 인스턴스를 중지해 데이터 무결성을 확보
3. 인스턴스를 바탕으로 AMI를 구축
   • 이 과정에서 EBS 스냅샷 생성 → 다른 AMI에서 인스턴스를 실행 가능

---

인스턴스 스토어

• EC2는 가상 머신이지만, 실제로는 하드웨어 서버에 연결되어 있다
• 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불림 → 물리적 서버에 연결된 하드웨어 드라이버를 가리킴
• 특징
  • I/O 성능의 향상
  • 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실됨 → 임시 스토리지
  • ⇒ 장기적으로 데이터를 보관하는 장소 x (cf. 장기 스토리지의 경우 EBS가 적합)
  • 버퍼나 캐시, 스크래치 데이터나 임시 콘텐츠를 사용할 때 사용
  • EC2 인스턴스의 기본 서버에 장애가 발생할 때 데이터 손실에 대한 위험이 존재
  • → 필요에 따라 데이터를 백업이나 복제해두어야 한다

---

EBS 볼륨 유형

• 총 6개의 유형이 있다
  • gp2 / gp3 (SSD) : 범용 볼륨
  • io1 / io2 (SSD) : 최고 성능을 가진 볼륨, 업무가 크리티컬하고, 지연 시간을 낮게 유지해야하는 대용량의 워크로드에 사용
  • st 1 (HDD) : 저비용, 잦은 접근과 처리량이 많은 워크로드에 사용
  • sc 1 (HDD) : 가장 비용이 적게 드는 볼륨, 접근 빈도가 낮은 워크로드를 위해 설계
• EBS 볼륨은 크기, 처리량 IOPS(초당 작업 수) 를 기준으로 구분
• gp2, gp3, io1, io2만이 부팅 볼륨으로 사용될 수 있다

 

GP 2/3 (General Purpose SSE)

• 짧은 지연시간, 효율적인 비용의 스토리지
• 1GB - 16TB까지 지원
• 기억하기
  • 비용 효과적인 스토리지
  • gp3에서는 IOPS와 처리량을 독자적으로 설정 가능
  • gp2에서는 IOPS와 처리량이 연결되어 있음

 

Provisioned IOPS

• IOPS 성능을 유지해야 하는 비즈니스 애플리케이션이나 16,000 IOPS 이상을 요구하는 애플리케이션에 적합
• 일반적인 DB 워크로드에 알맞다
• 스토리지 성능과 일관성에 아주 민감할 때 io1 또는 io2 볼륨으로 변경하는 것을 권장
• 4GB - 16TB까지 지원
• 32,000 IOPS 이상을 요구할 때

 

st1, sc1

• st1
  • 처리량 최적화 HDD
  • 빅데이터나 데이터 웨어하우징 로그 처리에 적합
• sc1
  • 아카이브 데이터용
  • 접근 빈도가 낮은 데이터 저장에 사용
  • 최저 비용으로 데이터 저장

cf. 대략적으로 모든 볼륨의 차이를 이해할 필요

---

EBS 다중 연결

• 하나의 EBS 볼륨을 같은 가용 영역에 있는 여러 EC2 인스턴스에 연결할 수 있게 해준다
• EBS 볼륨 중 io1, io2 제품 군에서만 사용 가능한 기능
• 각 인스턴스는 고성능 볼륨에 대한 읽기 및 쓰기 권한을 전부 갖는다 → 동시에 읽고 쓰기 가능
• 제한사항
  • 해당 가용 영역 내에서만 사용 가능
  • 한 번에 16개의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다
• 다중 연결을 실행하려면 반드시 클러스터 인식 파일 시스템을 사용해야 한다

---

EBS 암호화

• EBS 암호화 사용시 → 암호화가 동시다발적으로 일어남
  • 저장 데이터가 볼륨 내부에 암호화
  • 인스턴스와 볼륨 간의 전송 데이터가 암호화
  • 스냅샷, 스냅샷으로 생성한 볼륨 모두 암호화
• 암호화 및 복호화 매커니즘은 보이지 않게 처리됨 (백그라운드에서 EC2와 EBS가 모두 처리)
• 암호화는 지연시간에 영향이 거의 없고, KMS에서 암호화 키를 생성 → AES-256 암호화 표준을 갖는다

 

EBS 볼륨의 암호화 및 복호화 풀기

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

 

Amazon EFS - Elastic File System

• EFS : 관리형 NFS, 네트워크 파일 시스템
  • 여러 EC2 인스턴스에 마운트 될 수 있다
  • EC2 인스턴스들은 여러 가용 영역에 있을 수 있다
• 가용성, 확장성, 높은 가격 (gp2 EBS 볼륨의 3배 정도)
• 사용량만큼 지불 → 미리 용량을 프로비저닝하지 않아도 됨
• 내부적으로는 NFS 프로토콜을 사용
• EFS에 대한 액세스 제어를 위해 보안 그룹을 설정해야 함
• Linux 기반 AMI와 호환 (window x)
• KMS → EFS 드라이브에 저장 데이터 암호화를 활성화
• 리눅스 파일 저장 표준인 POSIX 시스템을 사용하고 표준 파일 API를 갖는다
• 미리 용량을 계획하지 않아도 된다
  • 파일 시스템이 자동으로 확장, 사용량에 따라 요금을 지불

 

EFS의 성능

• 수천 개의 NFS 클라이언트에서 EFS에 동시 액세스할 수 있게 확장, 초당 10GB의 처리량
• 용량을 미리 프로비저닝 하지 않아도 네트워크 파일 시스템이 PB 규모로 자동 확장
• 다양한 성능 모드를 설정할 수 있음
  1. 범용 모드 : 기본 설정으로 지연 시간에 민감한 웹 서버, CMS와 같은 사용 사례에서 사용
  2. 최대 I/O : I/O를 최대화하고 싶을 때
     • 지연 시간, 처리량, 병렬 처리 성능 향상
     • 빅데이터, 미디어 처리 작업이 있을 때 유용
  3. 처리량 모드 : 버스팅 모드가 기본값 (1TB 파일 시스템의 데이터 전송 속도가 초당 50MiB, 초당 100MiB까지 버스트 가능
     • 버스팅 모드에서는 사용 공간이 많을 수록 버스팅 용량과 처리량이 늘어남
     • 프로비저닝 모드에서는 스토리지 크기에 상관없이 처리량을 설정 가능

 

EFS - 스토리지 클래스

• 스토리지 계층을 설정할 수 있다
  • 일정 기간 후에 파일을 다른 계층으로 옮기는 기능
  1. 스탠다드 : 액세스가 빈번한 파일을 보통 저장
  2. EFS-IA 계층
     • 파일을 검색할 때 검색에 대한 비용이 발생
     • 저장 비용은 낮음
     • EFS-IA를 활성화하기 위해 수명 주기 정책을 사용해야 함 (cf. EFS-IA; Infrequent Access)
  cf. 스탠다드 계층에 60일 이상 액세스 하지 않은 파일이 있다고 가정할 때
• 설정한 수명 주기 정책에 따라 EFS-IA 계층으로 옮겨짐 → 비용이 낮아짐
• 가용성과 내구성 측면, 2가지 옵션
  1. 스탠다드 : EFS를 다중 AZ에 설정, 프로덕션 사용 사례에 적합
     • 한 가용 영역이 중단되더라도 EFS 파일 시스템에 영향을 주지 않기 때문
  2. One Zone EFS 파일 시스템으로 개발하는 것도 가능
     • 하나의 AZ이므로 기본적으로 백업이 활성화된다
     • EFS-IA 스토리지 계층과 호환 가능 → EFS One Zone-IA라고 부른다
     • 요금이 훨씬 큰 폭으로 할인 됨

cf. 언제 EFS를 사용하는지

유효성 검사와 요구 사항 준수를 위해 EFS 네트워크 파일 시스템에 설정해야 하는 옵션

---

EBS vs EFS

EBS 볼륨

• 한 번에 하나의 인스턴스에만 연결이 가능
• 특정 가용 영역에 한정
• gp2 : 디스크 크기가 늘어나면 IO도 함께 증가
• io1 : IO를 볼륨 크기와 관계없이 독립적으로 증가 가능 → 중요 DB를 실행할 때
• EBS 볼륨을 다른 가용 영역으로 옮기려면 가장 먼저 스냅샷을 찍어야 함
  • 다른 AZ에서 스냅샷을 복원시켜 사용
  • EBS 볼륨 내의 IO를 전부 사용하게 되므로 인스턴스가 EBS를 사용 중이 아닐 때에만 실행해야 한다
• EC2 인스턴스가 종료되면 인스턴스 내의 루트 EBS 볼륨도 기본적으로 종료됨 (비활성화 가능)

 

EFS

• 여러 개의 가용 영역에 걸쳐 무수히 많은 인스턴스에 연결될 수 있다
• EFS Mount Target을 사용해 특정 AZ에서 EC2 인스턴스들과 EFS 드라이브를 연결해 줄 수 있다
• 리눅스 인스턴스에서만 가능, POSIX 파일 시스템이라 윈도우에서 구동되지 않음
• EFS는 EBS보다 훨씬 비싸다 (거의 3배)
• 비용을 절약하고 싶다면 스토리지 티어로 EFS-IA를 사용, 제품 수명 정책을 사용해 비용 절감
• EFS는 사용한 만큼만 비용이 청구됨 (EBS는 실제 사용량이 아닌 드라이브의 크기에 따라 정해진 사용량을 지불하는 방식)
• 다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합

 

EFS vs EBS vs Instance Store

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