EBS Volume
EBS(Elastic Block Store) Volume이란?
인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브(물리적 드라이브 아님)
=> 인스턴스와 EBS 볼륨이 서로 통신을 하기 위해서는 네트워크가 필요
=> like 네트워크 USB 스틱
EC2는 여러 개의 EBS 볼륨과 연결될 수 있음(반대는 x)
EC2와 필수적으로 연결되어야 하는 것은 아님
인스턴스를 종료한 후에도 데이터를 지속할 수 있음 => EBS 볼륨을 쓰는 목적
인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 데이터를 다시 받을 수 있음
EC2로부터 분리되어 다른 인스턴스로 매우 빠르게 연결될 수 있음
- CCP 레벨 : 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능
- Associate 레벨 : 일부 EBS 다중 연결
EBS 볼륨은 특정 가용 영역에서만 가능
=> ap-northeast-2a에서 생성한 경우 ap-northeast-2b에선 불가능
=> 스냅샷을 이용하면 다른 가용 영역으로도 옮길 수 있음
각각의 region은 2 ~ 6개의 가용 영역을 가지고 있다.
용량을 정해놔야 함
=> 원하는 양의 GB, 단위 초당 전송 수(IOPS) 미리 지정
무료 등급 : 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공
EC2 인스턴스를 생성할 때 콘솔에서 EBS 볼륨을 생성하면 종료 시 삭제라는 속성
=> EBS 행동 제어 가능
- root EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 기본적으로 설정이 되어 있음(조작 가능)
- 다른 EBS 볼륨은 기본적으로 비활성 상태(조작 가능)
EBS 볼륨 생성
인스턴스 > 스토리지에서 인스턴스와 연결되어 있는 볼륨을 볼 수 있음
현재는 볼륨을 추가적으로 생성한 상태가 아니므로 인스턴스를 생성할 때 만든 EBS 볼륨이 있음
EBS 볼륨을 생성할 때 가용 영역은 인스턴스에서 네트워크 탭에 있음
볼륨 생성 후 작업에서 볼륨 연결하면 인스턴스에 바로 연결할 수 있음
연결이 되면 이제 인스턴스의 스토리지에 두 개의 볼륨이 뜨는 것을 확인할 수 있음
볼륨 리스트에서 맨 끝 칼럼에 종료 시 삭제가 있는데 이게 인스턴스를 생성할 때 root EBS 볼륨에는 예(기본값)가 설정되어 있는 것을 볼 수 있음
따라서 인스턴스를 종료하면 종료 시 삭제에 예로 되어 있는 EBS 볼륨은 삭제됨
EBS 스냅샷
EBS 볼륨의 특정 시점에서의 백업
EC2 인스턴스에서 EBS 볼륨을 분리할 필요는 없지만 분리하는게 좋음
EBS 스냅샷을 다른 가용 영역 또는 다른 리전에 복사할 수 있음
=> EBS 볼륨을 한 인스턴스에서 다른 인스턴스로 전송하는 방법
EBS 스냅샷 기능
- EBS 스냅샷 아카이브
- 스냅샷을 최대 75% 더 저렴한 아카이브 티어로 옮길 수 있는 기능
- 아카이브 티어로 옮기면 아카이브를 복원하는데 24 ~ 72시간 정도 소요
- EBS 스냅샷을 위한 휴지통
- EBS 스냅샷을 영구적으로 삭제하는 대신 휴지통에 보관하여 실수로 삭제한 경우 복원 가능
- 보관 기간은 하루에서 1년까지 설정
- 빠른 스냅샷 복원(FSR)
- 스냅샷을 처음 사용할 때 대기 시간이 없도록 스냅샷을 완전히 초기화
- 스냅샷이 매우 클 때 EBS 볼륨을 초기화해야 하거나 매우 빠르기 인스턴스화 하는 경우에 특히 유용
- 비용이 많이 듦
스냅샷 생성 및 기능 실습
스냅샷 생성은 볼륨 > 작업에서 가능
스냅샷 복사도 가능함
스냅샷 복사를 통해서는 재해 복구를 수행해야 할 때 AWS의 다른 리전에 데이터를 백업해둘 수 있음
스냅샷을 갖고 볼륨을 생성하여 다른 가용 영역에 둘 수 있음
볼륨 리스트에서 스냅샷 ID를 보면 스냅샷을 통해 생성된 것임을 알 수 있음
스냅샷 복사와 스냅샷으로 볼륨 생성
- 스냅샷 복사 (Copy Snapshot)
기존 스냅샷을 같은 리전 또는 다른 리전에 복사
스냅샷 자체를 백업하거나, 다른 리전으로 이동할 때 사용
📌 사용 목적:
✅ 리전 간 이동: A 리전에서 B 리전으로 스냅샷을 옮길 때
✅ 백업용: 원본을 그대로 두고 사본을 만들어 안전하게 보관할 때
✅ 다른 계정으로 공유: 복사한 후, 다른 AWS 계정에 공유 가능
📌 특징:
볼륨이 생성되지 않음, 단순히 스냅샷 데이터만 복제됨
다른 리전에 복사할 경우 데이터 전송 비용 발생
암호화된 스냅샷은 복사할 때 동일한 키를 사용하거나 새로운 키로 재암호화 가능
- 스냅샷으로 볼륨 생성 (Create Volume from Snapshot)
📌 설명:
스냅샷을 기반으로 새로운 EBS 볼륨을 생성
생성된 볼륨은 EC2 인스턴스에 마운트하여 사용 가능
📌 사용 목적:
✅ 이전 상태로 복구: EC2 인스턴스의 디스크를 특정 시점으로 복원
✅ 볼륨 크기 조정: 기존 볼륨이 부족할 때, 새 볼륨을 큰 사이즈로 생성 가능
✅ 새로운 인스턴스 배포: 기존 환경을 복제하여 여러 개의 서버를 운영할 때
📌 특징:
새로운 EBS 볼륨이 실제로 생성됨
원본 스냅샷이 사라지지 않고 그대로 유지됨
볼륨 크기를 변경 가능 (기존보다 클게만 가능, 작게 줄이는 것은 불가)
볼륨 생성 후 EC2 인스턴스에 연결해야 사용 가능
두 기능 모두 특정 시점 데이터를 갖고 있지만, "스냅샷 복사"는 백업용이고, "볼륨 생성"은 실제 사용 가능한 디스크를 만드는 차이점이 있다.
EBS 스냅샷을 위한 휴지통
보존 규칙을 생성 후에 스냅샷을 삭제하면 리소스에 삭제한 스냅샷이 보관되어 있음을 확인할 수 있음
복구 버튼을 누르면 다시 스냅샷 리스트에 뜸
현재 스토리지 티어는 표준으로 되어 있으나 스냅샷 아카이브로 바꿀 수 있음
스냅샷에서 작업 > 아카이브 > 아카이브 스냅샷을 통해 EBS 스냅샷 아카이브 가능
EBS 볼륨 유형
GP2, GP3 (SSD)
다양한 워크로드에 대해 가격과 성능의 균형을 맞추는 범용 SSD 볼륨
Io1, Io2 Block Express (SSD)
가장 높은 성능의 SSD 볼륨
미션 크리티컬/저지연/고처리량 작업에 적합
ST1 (HDD)
저비용 대용량 HDD 볼륨으로 자주 엑세스하고 처리량이 많은 작업을 위해 설계
SC1 (HDD)
가장 저렴한 HDD 볼륨 엑세스 빈도가 낮은 작업을 위해 설계
EBS 볼륨은 크기, 처리량, 초당 입출력 작업수(IOP)에 따라 특정됨
인스턴스는 GP2, GP3, Io1, Io2만 부팅 볼륨으로 사용할 수 있음 (os의 루트가 실행되는 위치를 의미)
범용 SSD (General Purpose SSD)
비용 효율적인 스토리지로 낮은 대기시간 제공
시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에 사용할 수 있음
1GB ~ 16TB까지 다양
GP3는 최신 세대 볼륨으로 기본적으로 3000 IOP와 초당 125MB의 처리량 제공
최대 16000 IOP와 초당 1000MB까지 독립적으로(볼륨의 크기와 IOP는 연관없음) 증가시킬 수 있음
GP2는 GP3의 예전 버전
최대 3000 IOP까지 버스트 성능 제공
볼륨의 크기와 IOP는 연관되어 있어(정비례) 최대 16000 IOP
프로비저닝된 IOPS 볼륨 (Provisioned IOPS(PIOPS) SSD)
지속적인 IOPS 성능이 필요한 중요한 비즈니스 어플리케이션이나 16000개 이상의 IOP가 필요한 애플리케이션에 사용
데이터베이스 작업이 스토리지 성능과 일관성에 매우 민감한 경우 프로비저닝된 볼륨이 적합함
EBS 다중 연결 기능 지원
- Io1 볼륨
- 4TB ~ 16TB까지 지원
- 최대 IOP는 Nitro EC2 인스턴스의 경우 약 64000이고 다른 종류의 인스턴스의 경우 32000
- 스토리지 크기와 별도로 프로비저닝된 IOPS를 늘릴 수 있음
- Io1 Block Express 볼륨
- 최대 64TB 데이터 사용 가능
- 서브 밀리초 대기 시간 발생
- 최대 256000 IOP 제공, IOPS 대 기가바이트 비율은 1000:1 => 매우 높은 성능
Hard Disk Drives (HDD)
부팅 볼륨이 될 수 없음
최대 16TB
- ST1
- 처리량 최적화 HDD
- 빅데이터, 데이터 워어하우징, 로그 처리에 적합
- 초당 최대 500MB 처리량과 최대 500 IOPS 제공
- SC1 (Cold HDD)
- 아카이브 데이터용 (자주 엑세스 되지 않는 데이터)
- 가낭 낮은 비용이 발생할 때 사용
- 초당 최대 250MB 처리량과 최대 250 IOPS 제공
데이터 베이스가 필요한 경우 => 범용 SSD, 프로비저닝된 IOPS SSD
높은 처리량과 가장 낮은 비용 => ST1, SC1
EBS 다중 연결
다중 첨부 기능을 사용하면 동일한 EBS 볼륨을 동일한 가용 영역에 있는 여러 개의 EC2 인스턴스에 첨부할 수 있음
Io1, Io2 제품군에서만 사용 가능
각 인스턴스는 고성능 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖게 됨
지정된 가용 영역에서만 사용 가능 => 한 AZ의 EBS 볼륨을 다른 AZ에 첨부 불가능
하나의 볼륨은 한 번에 최대 16개의 EC2 인스턴스에 부탁할 수 있음
이 기능이 작동하려면 클러스터를 인식할 수 있는 파일 시스템을 사용해야 함 (XFS, Xe4는 안됨)
ex.
- 클러스터된 리눅스 애플리케이션의 경우, 애플리케이션 가용성이 높아짐(Teradata)
- 애플리케이션에서 동시 쓰기 작업을 관리하는 경우
AMI
AMI란
Amazon Machine Image의 약자
사용자 지정 EC2 인스턴스를 나타냄
각자의 소프트웨어 구성에 대해 운영 체제를 정의 및 설정하며 모니터링 도구를 설정할 수도 있음
=> AMI를 자체적으로 생성하면 부팅과 구성에 시간이 단축됨
=> EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징 되기 때문
특정 리전에 맞도록 구축하여 원하는 리전에 복사해놓거나 aws 글로벌 인프라를 활용할 수 있음
AMI 종류
- aws가 제공하는 공용 AMI를 사용(ex. 아마존 Linux 2 AMI)
- 직접 생성할 수도 있음
- aws 마켓 플레이스 AMI에서도 EC2 인스턴스 실행이 가능(사용자가 만들어서 판매하는 AMI)
EC2 인스턴스의 AMI 처리
- EC2 인스턴스를 시작하고 사용자 지정으로 바꿈
- 인스턴스를 중지시켜 데이터 무결성 확보
- AMI 구축하는데 EBS 스냅샷도 생성
- 다른 AMI에서 인스턴스를 실행 가능
실습
EC2 인스턴스를 생성하며 사용자 데이터에 httpd까지만 설치하는 코드를 작성한다.
Apachi를 통해 IPv4 퍼블릭 주소로 들어가면 다음과 같이 뜬다.
인스턴스에서 이미지 생성을 하고, 다시 인스턴스를 하나 만들 때, 애플리케이션 및 OS 이미지에서 내 AMI를 클릭하면 내가 소유한 AMI 목록이 뜨고 이를 통해 인스턴스를 만들 수 있다.
사용자 데이터에는 html 파일을 생성만 하는 코드를 둔다.
이 인스턴스에서는 내가 생성해둔 AMI를 통해 이미 httpd가 설치된 상태이므로 더 빠르게 실행된다(화면이 나온다).
EC2 인스턴스 스토어
EBS 볼륨은 네트워크 드라이브로 좋지만 성능에서 제한됨
=> EC2 인스턴스에 연결된 하드웨어 디스크 성능이 향상되어야 함 (EC2 인스턴스는 가상머신이지만 실제로는 하드웨어 서버에 연결되어 있어서 물리적으로 연결된 디스크 공간을 가짐)
=> 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불림 (물리적 서버에 연결된 하드웨어 드라이브)
=> I/O 성능 향상
인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실될 수 있기 때문에 임시 스토리지 라고도 부름
=> 장기적으로 데이터 보관하기에 좋지 않음 (장기 스토리지는 EBS가 적합)
=> 버퍼, 캐시, 스크래치 데이터, 임시 콘텐츠를 활용하는 경우에 활용
EC2 인스턴스의 기본 서버에 장애가 발생할 때는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생
=> 데이터 손실 위험 존재하기 때문에 필요에 따라 데이터를 백업해두거나 복제해둬야 함
Amazon EFS (Elastic File System)
관리형 NFS (Network File System)으로 많은 EC2 인스턴스에 마운트될 수 있음
EFS에 의해 EC2 인스턴스는 서로 다른 가용성 영역에 있을 수 있음
확장성이 뛰어나며 비쌈
데이터 GB 사용량에 따라 비용을 지불하므로 미리 용량을 프로비저닝 할 필요가 없음
=> 자동으로 확장됨
사용 사례 : 콘텐츠 관리, 웹 서빙, 데이터 공유, Wordpress
내부적으로 NFS 프로토콜 사용
EFS에 대한 엑세스를 제어하려면 보안 그룹을 설정해야 함
윈도우가 아닌 리눅스 기반 AMI와만 호환됨
KMS를 사용해서 EFS 드라이브 미사용 암호화를 활성화할 수 있음
리눅스 표준 파일인 POSIX 시스템을 사용함, 표준 파일 API가 있음
EFS 성능 옵션
EFS 스케일
EFS 스케일은 동시 NFS 클라이언트 수천 개와 10GB 이상의 처리량 확보 가능
PB 규모의 네트워크 파일 시스템으로 자동 확장 가능
EFS 성능
네트워크 파일 시스템 생성 시 성능 모드를 설정할 수 있음
- 범용(기본값): 지연 시간에 민감한 사용 사례(웹 서버, CMS)
- MAX I/O: 지연 시간이 길지만 처리량 최대화(빅 데이터 어플리케이션, 미디어 처리)
처리량 모드
- 버스팅: 1TB = 초당 50 ~ 100 MiB
- 프로비저닝: 스토리지 크기에 상관없이 처리량 미리 설정하고 싶은 경우
- 엘라스틱: 워크로드에 따라 처리량을 자동으로 조정
스토리지 클래스
- 스토리지 계층 설정 가능: 머칠 후 파일을 다른 계층으로 자동으로 옮기는 기능
- 스탠다드: 자주 엑세스하는 파일을 위한 계층
- 자주 엑세스 하지 않는 계청(EFS-IA): 파일을 검색할 경우 비용이 발생하지만 저장하면 비용 감소
- 아카이브: 거의 엑세스 하지 않는 데이터용
=> 스토리지 계층 간에 파일을 자동으로 이동하기 위해 수명 주기 정책을 구현하여 며칠 후에 파일을 어느 계층으로 이동해야
하는지 정의할 수 있음
- 가용성과 내구성 측면
- 다중 AZ 설정이 있는 경우, 프로덕션 워크로드에 적합 => 스탠다드
- 개발만 하고 더 저렴한 옵션을 원한다면 => One Zone
- 하나의 AZ에만 있고 백업은 기본적으로 활성화되도록 설정되어 있음
- 엑세스 빈도가 낮은 계층과 호환 (EFS One Zone IA)
- 개발 환경에서는 좋지만 프로덕션 환경에서는 가용 영역이 사용할 수 없게 되면 데이터에 엑세스할 수 없으므로 좋지 않음
EFS 스토리지 클래스를 올바르게 사용하면 최대 90%의 비용을 줄일 수 있음
EBS 볼륨, EFS 파일 시스템 차이
EBS
한 번에 한 인스턴스에만 연결 (다중 연결 기능인 Io1, Io2 볼륨 제외)
AZ에 고정
gp2 유형의 볼륨은 디스크의 크기가 증가해야 IO가 증가함
gp3, Io1 볼륨은 디스크 크기와 무관하게 IO를 증가할 수 있음
AZ 간에 EBS 볼륨을 옮기려면 스냅샷을 이용하면 됨
EBS 스냅샷에 저장되고 이 스냅샷을 다른 AZ에 복원할 수 있음
EBS 볼륨 백업이 IO를 사용하므로 애플리케이션이 많은 트래픽을 처리하고 있는 경우에는 실행하면 성능에 영향이 갈 수 있어 안됨
EC2가 종료되면 기본적으로 EBS 볼륨도 종료되지만 인스턴스를 생성할 때 비활성화 시킬 수 있음
EFS
네트워크 파일 시스템
서로 다른 가용 영역의 수백 개의 인스턴스에 연결될 수 있음
POSIX를 사용하기 때문에 리눅스 인스턴스에서만 사용 가능
EBS 보다 가격대가 높지만 비용 절감을 위해 EFS-IA 기능 이용 가능
인스턴스 스토어는 물리적으로 EC2 인스턴스에 연결
EC2 인스턴스가 사라지면 스토리지도 잃게 됨
