AWS - 인스턴스 스토리지

박상훈·2022년 11월 6일

EBS(Elastic Block Store)


인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브(물리적 드라이브가 아님)
인스턴스가 종료되도 데이터를 지속할 수 있음
인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하여 데이터를 다시 받는 구조
하나의 EBS 는 하나의 EC2 인스턴스에만 마운트 가능
EC2 인스턴스와 EBS 의 마운트는 특정 가용 영역에 제한됨
다른 가용 영역에 마운트하기 위한 방법으로 Snapshot 을 사용할 수 있음
EC2 인스턴스를 제거하면 default 로 생성된 EBS 도 같이 제거되며
사용자가 추가한 EBS 에 대해서만 제거되지 않고 유지된다
Delete on termination 설정을 변경하여 제거 유무 변경 가능

EBS 실습

1.EC2 Dashboard -> Elastic block store -> Volums -> Create Volume
2.설정 값 세팅 및 적용할 인스턴스의 AZ 확인하여 같은 AZ(가용 영역) 적용
3.볼륨 생성
4.생성한 볼륨 클릭 -> Actions -> Volume Attach 클릭
5.동일한 AZ 의 인스턴스 선택 및 적용
6.EC2 Dashboard -> Instance -> Storage 클릭 및 적용 확인

Snapshot

가용 영역(AZ) 또는 리전에 걸친 스냅샷 복사, 복원 목적

Snapshot 실습

1.EC2 Dashboard -> Elastic block store -> Volumes -> 볼륨 클릭
2.Actions -> Create snapshot 클릭 -> 값 설정 및 생성
3.Snapshots -> 생성된 snapshot 확인

기존 가용 영역에서 사용 중이던 EBS 의 snapshot 생성
해당 snapshot 을 copy 하여 다른 리전에 snapshot 생성
다른 리전에 copy 된 snapshot 클릭 -> Actions -> Create volume from snapshot 클릭 -> 새로운 volume 에 대한 값 설정 및 생성

AMI(Amazon Machine Image)


각자의 소프트웨어 구성에 대해 운영체제 정의 및 설정과 모니터링 도구를 설정
EC2 인스턴스에 설치하고자 하는 모든 설정이 AMI 가 사전에 모두 패키징하여
구성 및 부팅 시간을 단축할 수 있음

AMI 실습

1.EC2 Dashboard -> Instance -> Instance 생성, 실행, 무결성 체크
2.생성한 Insctance 클릭 -> Actions -> image and Templates 클릭
3.AMI 를 사용하지만 인스턴스를 생성하기 위한 조건을 다시 한번 체크하거나 입력
4.Advanced Details -> user data 설정 후 인스턴스 생성
5.정상적으로 AMI 를 이용한 인스턴스가 생성되고 정상 작동되는지 확인

실습 상세 과정

1.처음 생성한 인스턴스 user data 에는 httpd(웹서버)를 설치하는 명령어 입력
2.AMI를 이용한 두 번째 인스턴스 user data 에는 echo 명령어로 html 파일을 생성
3.웹서버가 이미지에 이미 구축되어 있어 html 파일만 생성해도 사용 가능함

EC2 인스턴스 스토어


I/O 성능 향상을 위한 경우
인스턴스 스토어를 중지/종료한 경우 해당 스토리지는 손실됨
버퍼, 캐시, 스크레치 데이터, 임시 콘텐츠를 사용하는 경우에 사용
장기 스토리지의 경우 인스턴스 스토어는 적합하지 않고 EBS를 사용
장애 발생을 대비해 백업 or 복제를 미리 구성

EBS 볼륨 타입


EBS 정의 기준: 크기, 처리량, IOPS
EC2 인스턴스의 부팅 볼륨으로 사용 가능 모델: gp2, gp3, io1, io2

  • io1/io2
    • 4Gib ~ 16Tib
    • 최고 성능 SSD, 미션 크리티컬, 지연 시간 낮음, 대용량 워크로드에 사용
  • gp2/gp3
    • 범용 SSD, 다양한 워크로드에 대해 가격과 성능의 절충안
    • 처리량 125MB ~ 1000MB, IOPS 3000 ~ 16000
    • gp3 는 IOPS 와 처리량을 독자적으로 설정 가능
    • gp2 는 IOPS per GB 증가될 때 IOPS 가 연결되어 증가되는 형태
  • st1
    • 125Mib ~ 16Tib
    • 저비용의 HDD, 잦은 접근, 처리량 많은 워크로드
    • 빅 데이터, 데이터 웨어하우징 로그 처리에 적합
    • 최대 처리량 500MB, 최대 IOPS 500
  • sc1
    • 125Mib ~ 16Tib
    • 가장 적은 비용의 HDD, 접근 빈도가 낮은 워크로드
    • 최대 처리량 250MB, 최대 IOPS 250

Provisioning IOPS

IOPS 성능을 유지할 필요가 있으며 16,000 IOPS 이상을 요구하는 애플리케이션에 적합
일반적으로 데이터베이스 워크로드에 적합
위 와 같은 조건 필요시 gp -> io 로 변경, io 는 최신 세대를 고르는 것을 권장함
io 를 사용하며 Nitro EC2 인스턴스를 사용하면 최대 64,000 IOPS 까지 가능

EBS 다중 연결

EBS 타입이 io1/io2, 같은 가용 영역, 클러스터 인식 파일 시스템 필수 사용

EBS 암호화

EBS 볼륨 생성시 저장 데이터는 볼륨 내부에 암호화됨
인스턴스와 볼륨간의 데이터는 암호화되어 전송됨
암호화된 볼륨으로 생성한 스냅샷, 해당 스냅샷으로 생성한 볼륨 또한 자동 암호화
암호화, 복호화 메커니즘은 보이지 않으며 백그라운드에서 처리됨
암호화는 지연 시간에 전혀 지장을 주지 않음
KMS 암호화(AES-256) 키를 생성하여 암/복호화에 사용

EFS(Elastic File System)


관리된 NFS(Network File System)
여러 EC2 인스턴스에서 마운트할 수 있음
다양한 가용 영역의 EC2 인스턴스에 대한 마운트 허용
높은 가용성과 확정성이 뛰어남
gp2 타입의 EBS 볼륨 비용에 대해 3배 정도 더 비쌈
사용할 때 마다 비용을 지불하는 구조로 사전 프로비저닝 용량이 없음
컨텐츠 관리, 웹 서비스 제공, 데이터 공유, WordPress 등에 사용
내부적으로 NFSv4 프로토콜 사용
EFS 접근을 제어하기 위해 보안 그룹 설정 필요
Windows 가 아닌 Linux 기반의 AMI 에만 호환이 가능
용량을 미리 설정하지 않고 사용하는 1GB 마다 비용을 지불하는 방식

EFS 성능

  • EFS Scale
    • 수천명의 NFS 클라이언트의 동시 처리
    • 10GB/s 이상의 용량
    • 자동으로 Petabyte-scale 로 커짐
  • Performance Mode(EFS 설정 모드)
    • General purpose(default)
      • Web Server, CMS, 등 사용
    • Max I/O
      • 지연시간, 용량 증가
      • 병렬 처리
      • 빅 데이터, 미디어 프로세싱에 사용
  • Throughput mode(처리량)
    • Burstring
      • 1TB = 50MiB/s 속도의 데이터 전송 ~100MiB/s 까지 가능
      • 프로비저닝 설정 가능
      • 많은 공간 사용시 처리량 용량이 커지는 조건이 아님
      • 스토리지 크기와 무관하게 용량 프로비저닝 가능

EFS Storage Classes

  • Storage Tiers(스토리지 계층)
    • 일정 시간 뒤 파일을 다른 계층으로 이동
    • Standard 계층
      • 자주 접속하는 파일에 적용
    • Infrequent Access(EFS-IA) 계층
      • 파일을 찾을 때 비용을 지불
      • 파일을 저장할 때 비용이 낮음
      • 수명 주기 정책 필요
  • Availability and Durability(가용성과 내구성)
    • Regional(다중 AZ)
      • 특정 가용 영역이 다운돼도 EFS 파일 시스템에 영향이 없음
    • One Zone
      • 가용 영역이 하나
      • 기본값으로 백업 활성화
      • EFS-IA 호환 가능, EFS One Zone-IA 라고 부름
      • 90% 까지의 큰 할인폭

60일 사용하지 않은 파일에 대한 정책이 있다는 가정하에
Standard 계층에 있는 파일이 60일 이상 사용되지 않으면
EFS-IA 계층으로 이동되며 비용도 적어짐

EFS 실습

1.EFS Dashboard -> Create file system 클릭
2.옵션 default -> Customize 클릭
3.위에서 설명한 EFS Storage classes 에 대한 옵션들 default
4.Next 클릭
5.Network -> Security Groups -> 기존 보안 그룹 제거
6.새로운 Security Groups 생성하여 모든 AZ에 적용
7.File system policy - optional 그대로 Next
8.설정 값 확인하고 Create 버튼 클릭
9.EC2 Dashboard -> Instance -> Launch Instances 클릭
10.Key Pair -> Proceed without a key pair 선택
11.Configure Storage -> 0 x File systems -> Edit 클릭
12.Network Settings -> edit 클릭
13.Subnet -> AZ 선택
14.다시 Storage -> Add shared file system 클릭
15.생성한 EFS가 설정 값에 있는지 확인, Mount point 확인
16.인스턴스 생성
17.9 ~ 16번 반복해서 두 번째 인스턴스 생성
18.생성한 EC2 인스턴스 1, 2 -> aws ssh connect
19.EC2 인스턴스 1번에서 Mount point 경로에 echo 명령어 사용
20.파일 생성 되었는지 확인
21.EC2 인스턴스 2번에서 Mount point 경로 접근
22.EC2 인스턴스 1번이 생성한 파일 있는지 확인

EBS vs EFS


  • EBS
    • 하나의 인스턴스에 연결 가능하며 특정 AZ에 종속됨
    • gp2는 디스크 크기가 늘어나면 I/O 증가
    • io는 개별적으로 늘리는게 가능
    • EBS를 다른 가용 영역에서 사용하기 위한 스냅샷 사용
    • 스냅샷/백업은 EC2인스턴스가 EBS를 사용하지 않을 때 실행
    • EC2 인스턴스 종료시 루트 EBS볼륨도 종료, 비활성화 가능
    • 사용하는 드라이브의 크기에 따라 금액이 정해짐
  • EFS
    • 여러 개의 가용 영역의 많은 인스턴스 연결 가능
    • EFS 는 AZ 외부에 있음
    • EFS Mount Target을 사용하여 각 AZ EC2 인스턴스와 연결
    • EBS 보다 많은 비용을 지불해야 사용 가능(세배)
    • 스토리지 티어(EFS-IA), 제품 수명 정책 사용으로 비용 절감
    • 사용하는 만큼의 비용 청구
    • 다수의 인스턴에 연결해야 하는 네트워크 파일 시스템에 적합
  • 인스턴스 스토어
    • EC2 인스턴스에 IO를 최대로 사용
    • 인스턴스에 문제는 스토어에 직결됨, 임시 드라이브

틀린 문제

EC2 인스턴스 스토어 사용: 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행할 때 추천 방법?

profile
엔지니어

0개의 댓글