AWS EC2 인스턴스 스토리지

EBS Volume

• elastic block store
• 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브
  • 레이턴시가 발생할 수 있음
• ebs볼륨을 사용하면 인스턴스가 중단되도 사용 가능
  • 인스턴스와 분리, 연결이 가능, 따라서 인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 다시 사용이 가능함
• CCP 레벨 → 하나의 EBS엔 하나의 EC2 인스턴스만 연결 가능
• 어소시에이트 레벨 → 일부 EBS 다중 연결
• EBS 볼륨을 생성하는 경우 특정 가용 영역에서만 가능
  • 특정 가용영역에 만들면 특정 가용 영역에 한정됨
  • 다른 가용영역에선 연결 불가, 스냅샷을 사용하면 볼륨을 옮길 수 있다
• 네트워크 USB라고 생각하면 쉽다
  • usb를 꺼내 다른 컴퓨터에 꽂는 것처럼 동작하지만 실제 물리적인 연결은 없다
  • 네트워크를 통해 자동으로 연결
• 볼륨이기 때문에 용량을 미리 결정해야함 / 이후 확장 가능
• EC2를 통해 생성하는 경우 종료시 삭제 속성이 있다( 출제 가능성 )
  • 기본적으로 루트 볼륨에 적용되어 있다 - Delete on Termination

EBS 볼륨 실습

AZ와 Delete on Termination 주의

EBS 스냅샷

• EBS 볼륨의 특정 시점에 대한 백업
• 스냅샷을 위해 EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만 권장사항임
• 다른 AZ나 리전으로 복사할 수 있다.

EBS 스냅샷 특징

• EBS 스냅샷 아카이브
  • 75%까지 저렴한 아카이브 티어로 스냅샷을 옮긼 수 있는 기능
  • 스냅샷을 아카이브로 옮기면 24시간에서 72시간까지 걸린다
• EBS 스냅샷 휴지통
  • 영구 삭제하는 대신 휴지통에 넣음
  • 실수하는 경우 휴지통에서 복원 가능
  • 1일~1년까지 허용
• 빠른 스냅샷 복원
  • 처음 초기화 할떄 지연시간을 없애는 방법
  • 스냅샷이 아주 크거나 EBS 볼륨또는 인스턴스를 빠르게 복구,초기화해야할 경우
  • 비용이 많이 든다

EBS 스냅샷 실습

copy snapshot → 다른 리전에 백업을 만들어두면 됨

Recycle Bin → EBS 스냅샷과 AMI들이 실수로 삭제되지 않도록 도와줌

• 규칙을 생성할 수 있다 ( 얼마나 보관하고 있을건지 )

AMI

• 아마존 머신 이미지
• EC2 인스턴스를 통해 만든 이미지 → AMI로 AWS 구축 가능
• AMI를 따로 구성하면 부팅 및 설정에 드는 시간을 많이 줄일 수 있다
  • EC2 인스턴스에 설치하고자하는 모든 소프트웨어를 AMI가 미리 패키징해준다
• AMI를 직접 구성하고 복사해 다른 리전으로 복사 가능
  • 몇몇 AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있다.
  • 다른 AWS 리전에서 AMI를 사용해 EC2 인스턴스를 실행하는 것은 불가
  • 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 사용하는 건 가능
  • 라이선스나 권한, 유형에 따라 복사하지 못할 수도 있다.
• 아마존 리눅스2 AMI로 아마존에서 제공하는 Public AMI를 사용했는데 자체적으로 만들어 실행 가능
• 마켓플레이스 AMI를 활용할 수 있는데 다른 사람이 만든걸 구매해서 사용하는 방식
  • 기업에서 자신들의 소프트웨어를 사서 넣고 AMI로 배포

AMI Process

• EC2를 실행하고 원하는 대로 설정
• 인스턴스를 중지해 데이터 무결성 확보
• 이 인스턴스를 바탕으로 AMI를 구축 → 이 과정에서 EBS 스냅샷 생성
• 다른 AMI로 인스턴스를 실행할 수 있다

AMI 실습

하나의 AZ에서 인스턴스를 실행시켜 커스텀 AMI를 만든 뒤 다른 AZ에서 커스텀 AMI로 만든 인스턴스를 실행시킬 예정

AMI를 통해 인스턴스를 새로 만들면 이미 EC2 인스턴스에 필요한 소프트웨어가 설치되어 있기 때문에 부팅시간이 훨씬 단축되면서 훨씬 빠르게 사용 가능

EC2 Instance Store

• EBS 볼륨은 좋다고 할 수 있지만 그럼에도 제한된 성능을 가지고 있는 네트워크 드라이브
• 더 높은 성능을 내야할 때가 있는데, 이때 EC2 인스턴스에 연결되어있는 하드웨어 디스크 성능 향상이 필요
  • 가상머신이지만 당연히 하드웨어와 연결되어 있다 → 물리적 디스크 공간을 갖는다고 이해
  • 물리적 서버에 연결된 하드웨어 드라이브를 가리킴
• 더 나온 I/O 성능 → 매우 향상된 디스크 성능이 필요할때 사용하며 버퍼나 캐시, 스크래치 데이터, 임시 콘텐츠를 사용하려는 경우 좋음
  • 장기적인 스토어에는 EBS
• 인스턴스 스토어를 가진 인스턴슬르 중지하거나 종료하면 스토리지가 사라짐
  • 임시 스토리지라고도 함
• 인스턴스 기본 서버의 문제가 생기면 연결된 하드웨어에도 데이터 손실위험이 생김 따라서 인스턴스 스토어는 장기적으로 데이터를 보관할 수 없다.
• 필요에 따라 데이터 백업과 복재가 필요함
  • 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있다. 또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정
• 매우 높은 IOPS를 갖는다 IO Per Second
  • 310,000 IOPS

EBS 볼륨 유형

1. gp2/gp3 범용 SSD → 다양한 워크로드에 대해 가격과 성능의 밸런스가 잘 맞는다
2. io1 / io2 최고 성능 SSD → 미션 크리티컬이며 지연시간이 낮고 대용량 워크로드
3. st1 저비용의 HDD → 잦은 접근과 처리량이 많은 볼륨
4. sc1 최저비용의 HDD → 접근 빈도그 낮은 워크로드를 위해 설계

이를 통해 EBS 볼륨은 크기, 처리량, IOPS가 가격과 성능을 결정하는 핵심적인 특징이라고 할 수 있음

gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용될 수 있다 → 루트 os가 실행될 수 있는건 SSD 뿐

시험에 있어서는 범용 gp2와 IOPS 프로비저닝이 중요한 내용으로 출제

EBS 볼륨 유형 유스케이스 - 왜 사용하는지만 이해하면 된다

자세한 성능은 크게 중요하지 않지만 IOPS는 알아두면 좋다

범용 SSD

• 짧은 지연시간과 효율적인 비용의 스토리지
• 시스템 부팅 볼륨에서 가상 데스크톱, 개발, 테스트 환경까지 사용 가능
• 1GB ~ 16TB
• gp3는 최신 세대 볼륨
  • 3,000 IOPS, 125 MB 처리량
  • 최대 16,000 1,000까지 독립적으로 증가시킬 수 있다
• gp2
  • 볼륨이 더 작고 최대 3,000 IOPS
  • 볼륨과 IOPS가 연결되어 볼륨의 GB 수를 늘릴 때 IOPS증가

정리해보면 gp3는 IOPS와 처리량을 독자적으로 설정하는 반면 gp2는 연결됨

프로비저닝된 IOPS SSD

• IOPS 성능을 유지할 필요가 있는 비즈니스 애플리케이션
• 16,000이상 IOPS가 필요한 경우 사용됨
• 데이터베이스 워크로드에 적합 → 스토리지 성능과 일관성에 매우 민감
  • gp2 gp3 → io1 / io2
• io1 / io2
  • 4GB - 16 TB이며 nitro 인스턴스에서 최대 64,000 IOPS 가능, 아닌 경우 32,000
  • gp3처럼 볼륨과 IOPS 독자적인 증가 가능
  • io2는 여기서 동일한 비용으로 내구성과 기기당 IOPS 수가 더 높다
    • 최대 256,000 IOPS

하드디스크 드라이브

• 부팅 볼륨으로 사용 불가
• 최대 16TB
• st1 → 처리량 최적화 HDD
  • 빅데이터나 데이터 웨어하우징 로그 처리에 적합
  • 최대 IOPS 500, 500MB 처리량
• sc1 → 아카이브용 HDD
  • 최저 비용 데이터 저장
  • 최대 처리량 250 iops 또한 250

EBS 다중 연결

• 하나의 EBS 볼륨을 같은 AZ에 있는 여러 인스턴스에 연결
• EBS 볼륨 중에서 io1과 io2 제품군에서만 사용 가능
• 각각의 인스턴스는 높은 성능의 볼륨에 모든 읽기 쓰기 권한을 가진다
  • 동시에 읽고 쓰기 가능
• 애플리케이션 가용성 높이기 위해 TeraData처럼 클러스터링된 Linux 애플리케이션에서 사용
• 애플리케이션이 동시에 읽기 쓰기가 필요한 경우
• 같은 AZ끼리만 연결 가능
• 한번에 16개의 EC2 인스턴스만 같은 볼륨에 연결 가능 → 숫자 16을 기억할 것
• 다중연결을 하려면 클러스터 인식 파일 시스템을 사용
  • XFS, EX4와는 다르다

EBS 볼륨 암호화

• EBS 볼륨을 생성하면 즉시 다음과 같은 일이 벌어짐
  • 저장 데이터가 볼륨 내부에 암호화
  • 인스턴스와 볼륨간 전송 데이터 암호화
  • 모든 스냅샷 암호화
  • 스냅샷으로 생성한 볼륨 암호화
• 암호화가 동시다발적으로 발생
• 내부적으로 처리 → 백그라운드 내에서 ec2와 EBS가 처리
• 지연시간 영향이 거의 없음
• KMS 암호화 키 생성해 AES-256 방식을 사용

EBS 볼륨 암호화, 복호화

→ 암호화 되지 않은 EBS볼륨 암호화하기

• 볼륨의 EBS 스냅샷 생성
• 복사 기능을 통해 원본 EBS 스냅샷 암호화
• 위의 스냅샷을 이용해 EBS 볼륨을 암호화하여 새로 생성
• 암호화된 볼륨을 인스턴스 원본에 연결

EFS

언제 사용하는지 어떤 요구사항을 만족하기 위해 어떤 옵션을 사용해야하는지를 알아둘 것

• Elastic File system이란 이름으로 Network file system이다. 여러 EC2 instance에 마운트 가능
• ec2 인스턴스들은 여러 AZ에 있을 수 있다
• 가용성 확장성이 높다
  • 다만 가격이 비쌈
  • 콘텐츠관리, 웹서비스, 데이터 공유, 워드프레스에 사용
• NFS 프로토콜과 엑세스 제어를 위해 보안그룹을 설정해야함
• KMS를 활용해 저장 데이터 암호화
• 중요한점은 Linux 기반 AMI와 호환된다는 점이다 리눅스 표준 파일 시스템 → POSIX
• 미리 용량을 계획하지 않아도 자동으로 확장되고 사용한 만큼 지불한다

EFS의 성능

• 수천 개의 NFS에서 EFS에 동시 엑세스할 수 있게 확장됨
• 10GB 처리량
• 용량을 미리 프로비저닝하지 않아도 네트워크 파일 시스템이 Petabyte 단위로 자동확장

성능 모드

• 범용모드 → 지연시간에 민감한 사용 사례들 - 웹서버, CMS
• 최대 I/O → 지연시간, 처리량, 병렬 처리 성능 향상됨 → 빅데이터, 미디어 처리 작업

처리량 모드

• 버스팅모드 - 크기에 따라 처리량이 늘어나는데 기본값으로 50에서 최대 100 MB까지 처리량 버스트 가능
• 프로비저닝 모드 - 프로비저닝은 크기에 상관없이 처리량 설정 가능

스토리지 클래스

• 스토리지 티어
  • 일정 기간 후 파일을 다른 계층으로 옮김
    • 스탠다드계층 → 엑세스가 빈번하지만 파일을 오래 저장하지 않는 경우 적합
    • EFS-IA → 엑세스는 빈번하지 않지만 파일을 오래 저장하는 경우 적합
  • 스탠다드 계층에 자주 엑세스하지만 파일을 오래 저장하지 않는 경우 적합하다. EFS-IA에는 그 반대경우가 적합하며 라이프 사이클 설정을 통해 스탠다드 계층에서 EFS-IA로 옮겨 엑세스 비용을 엄청 아낄 수 있다
• 가용성과 내구성 옵션
  • 스탠다드 - EFS를 다중 AZ로 설정, 프로덕션에 적합하며 다른 파일 시스템에 영향 없음
  • One Zone : 개발할 때 좋은 옵션으로 기본적으로 백업이 설정되고 EFS-IA 스토리지 계층과 호환됨 (EFS One Zone - IA )
• 전반적으로 90% 비용을 아낄 수 있다

EFS 실습

위 설정들과 VPC 설정이 중요하다 → EFS를 위한 리전별 AZ 보안그룹 설정들을 해야함

여러 곳의 AZ에 인스턴스를 만들고 EFS로 연결하여 파일이 공유되는 것을 확인

EBS vs EFS

EBS볼륨은..

• 한 번에 하나의 인스턴스만 연결 가능하다
• 가용영역에 바인딩되어 다른 가용 영역에서 활용할 수 없다 (EBS 볼륨은 실제 가용영역에 있다고 생각하면 된다)
• gp2 → 볼륨의 수가 늘어날때마다 IOPS도 증가
• io1 → IOPS와 볼륨을 독립적으로 증가 → 중요한 DB를 실행할 때 좋음
• 다른 가용영역으로 옮기고자 한다면 우선 스냅샷이 필요
  • 이후 다른 AZ에서 복원
• EBS 백업이나 스냅샷을 하는 경우 볼륨내 모든 IO를 사용하기 때문에 인스턴스와 연결이 되지 않아야한다 → 성능이나 비용문제 발생가능
• ec2가 종료된다면 루트 볼륨도 기본적으로 종료 → 옵션으로 변경 가능

EFS

• 여러 개의 가용 영역에 걸쳐 많은 인스턴스들과 연결 가능
• EFS Mount Target을 사용해 특정 AZ에서 인스턴스들과 EFS 드라이브를 연결
• 워드프레스같은 웹 사이트 파일을 공유할 때 EFS를 사용
• Linux Posix기반 Windows 활용 불가
• EBS보다 비쌈
• 스토리지 티어로 EFS-IA를 사용, 라이프사이클을 사용하면 비용을 줄일 수 있음
• 온디맨드로 사용한 만큼 청구된다 ↔ EBS는 정해진 사용량을 지불

마지막으로 EFS vs EBS vs Instance store

EFS는 다수의 인스턴스에 걸쳐 연결해야하는 네트워크 파일 시스템에 적합

EBS는 네트워크 볼륨을 하나의 인스턴스에만 연결 / 특정 AZ 한정

인스턴스 스토어는 인스턴스에서 IO를 최대로 사용하게끔 해주지만 인스턴스가 고장나면 데이터 날라간다

오답

노스버지니아 리전 us-east-1에서 AMI를 사용하면 어떤 AWS 리전에 있는 EC2 인스턴스라도 실행할 수 있습니다 (  X )

• 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 사용하는 건 가능
• 몇몇 AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있다.
• 라이선스나 권한, 유형에 따라 복사하지 못할 수도 있다.

EBS 다중 연결이란 무엇일까요?

동일한 EBS 볼륨을 동일한 AZ내 여러 인스턴스에 연결

EBS 볼륨은 특정AZ로 묶여있다.

다른 AZ에서 사용하려고하면 EFS를 써야됨