EC2 인스턴스 스토리지

iamyoungbin·2024년 8월 26일

Solutions Architect - Associate

목록 보기

5/9

본 포스트는 AWS Certified Solutions Architect Associate 시험합격! 를 참고하여 작성되었습니다.

EBS (Elastic Block Store)

인스턴스가 실행 중인 동안 연결가능한 네트워크 드라이브

인스턴스가 종료되어도 데이터를 지속해서 저장하고 재생성한 인스턴스를 다시 마운트할 수 있다.
(CCP 레벨에서) 하나의 EBS는 하나의 EC2 인스턴스에만 연결할 수 있다. 하지만, 하나의 인스턴스는 여러 개의 EBS를 가질 수 있다.
EBS 볼륨은 해당 AZ에 한정된다.

간단히 말해 EBS는 USB를 통해 연결하는 드라이브라고 생각하면 된다. 어떤 컴퓨터든지 연결할 수 있지만 물리적으로 연결하는 것이 아닌 네트워크를 통해 연결하는 드라이브이다.

종료 시 삭제 옵션을 이용해 인스턴스 종료와 동시에 드라이브를 제거할 수 있다. 인스턴스 생성 시 함께 생성된 EBS의 경우 기본적으로 해당 옵션이 True이다.

EBS Snapshots

EBS 스냅샷은 EBS 볼륨의 특정 시점에 대한 백업으로 다른 AZ나 리전에도 복사할 수 있다.

EBS Snapshot Archive (EBS 스냅샷 아카이브)
스냅샷을 저장할 수 있는 아카이브로 최대 75%까지 저렴하다. 다만, 아카이브를 복원하는데 24시간에서 최대 72시간이 소요되기 때문에 자주 접근하지 않지만 장기 보존이 필요한 스냅샷을 관리하는데 유용하다.
Recycle Bin for EBS Snapshot (EBS 스냅샷 휴지통)
스냅샷을 삭제하고자 할 때 영구 삭제하는 대신에 휴지통에 넣을 수 있다. 스냅샷이 휴지통을 보관하는 기간을 1일부터 1년 사이로 설정할 수 있다.
FSR : Fast Snapshot Restore (빠른 스냅샷 복원)
스냅샷을 완전 초기화 해 첫 사용에서의 지연 시간을 축소하는 기능.
일반적으로 스냅샷을 통해 EBS 볼륨을 생성하기 위해서는 스냅샷 블록을 읽고 이를 통해 볼륨을 생성하게 된다. 하지만 FSR의 경우 스냅샷 블록을 미리 읽어 초기화하여 초기 사용 시 빠르게 볼륨을 생성할 수 있게 한다. 그만큼 스냅샷 복원에서는 가장 높은 비용이 부과된다.

AMI (Amazon Machine Image)

인스턴스에 설치하고자 하는 모든 운영체제, 설정 파일, 소프트웨어를 미리 패키징 해 부팅 및 설정에 필요한 시간을 줄일 수 있다.

AMI를 특정 지역에 생성한 다음에 다른 지역으로 복사할 수 있다.

AMI 생성 과정

EC2 인스턴스를 생성하고 커스터마이징한다.
인스턴스를 중지해 데이터 무결성을 확보한다.
인스턴스가 실행 중일 때 운영체제가 작업을 수행하면서 메모리 및 디스크에 읽고 쓰기 연산이 계속해서 진행된다. 만약, 인스턴스가 실행 중인 상태에서 AMI를 생성하면 기록 중이던 데이터가 완전이 기록되지 않는 등 데이터 일관성 문제가 발생할 수 있다.
AMI를 생성한다. 또한, 이 과정에서 EBS 스냅샷이 함께 생성된다.

EC2 인스턴스 스토어

EC2에서 주로 사용하는 EBS의 경우 높은 성능을 가지고 있지만 네트워크를 통해 데이터를 전송하기 때문에 성능이 제한될 수 있다. 즉, 네트워크 속도나 대역폭으로 인해 성능이 최적화되지 않을 수 있다.

때로는 EBS보다 더 빠른 디스크 성능이 필요할 때가 있을 수 있다. 예를 들어, 매우 높은 I/O 성능이 요구되는 데이터베이스 작업이나 실시간 데이터 처리 작업에서는 더 높은 성능이 필요할 수 있다.

EC2 인스턴스는 가상 머신이지만, 실제로는 물리적 서버에 위치해 있다. 이 물리적 서버에는 자체 디스크 공간(하드웨어 디스크)이 연결되어 있고, 특정 유형의 EC2 인스턴스는 이 물리적 서버에 직접 연결된 디스크(하드웨어 디스크)를 사용할 수 있다. 이 스토리지를 EC2 인스턴스 스토어라고 부른다.

EC2 인스턴스 스토어는 네트워크를 거치지 않고 물리적 디스크에 직접 접근하기 때문에, I/O 성능이 매우 높다.

높은 성능을 활용할 수 있는 대규모 데이터 처리 작업이나 고성능 데이터베이스 애플리케이션에 유리합니다.

다만 인스턴스 스토어는 데이터의 지속성을 보장하지 않으며, 인스턴스가 중지, 종료되거나 실패하면 데이터가 삭제됩니다.

데이터베이스의 캐시 데이터, 임시 파일, 데이터 처리 작업의 중간 결과 등과 같은 짧은 수명의 데이터를 저장하는 경우에 적합하다.

EC2 볼륨 유형

EBS 볼륨은 필요한 용량 / 처리량 / 초당 입출력 작업 수(IOPS, I/O per Sec)에 따라 결정하자

gp2/gp3 (SSD) : 다양한 워크로드에 가격과 성능의 균형을 맞추는 범용 SSD 볼륨.
io1/io2 Block Express (SSD) : 가장 높은 성능의 SSD 볼륨. 저지연 및 대용량 처리 작업에 적합하다.
st1 (HDD) : 저비용 대용량 HDD 볼륨. 자주 액세스하고 처리량이 많은 작업을 위해 사용.
sc1 (HDD) : 가장 저렴한 HDD 볼륨. 액세스 빈도가 낮은 작업을 위해 사용.

gp2/gp3와 io1/io2 볼륨만 부팅 볼륨으로 사용할 수 있다. 즉, 루트 볼륨을 해당 볼륨으로만 지정할 수 있다.

gp2/gp3 (General Purpose SSD)

말 그대로 범용 워크로드를 위한 SSD 볼륨
비용 효율적인 스토리지로 낮은 대기 시간을 제공하며 시스템 부팅 볼륨, 가상 데스크톱, 개발 및 테스트 환경에 사용할 수 있다.
볼륨의 크기는 1GB ~ 1TiB이며 최대 16,000까지 IOPS를 제공한다.

gp2와 gp3는 어떤 차이점이 있나?

gp2의 경우, 볼륨 크기에 맞춰 초당 입출력 작업 수 및 처리량이 증가한다.
볼륨 크기를 얼마만큼 프로비저닝하느냐에 따라 IOPS가 향상되기 때문에, 요구하는 수준의 초당 입출력 작업 수를 충족하기 위해서 불필요하게 볼륨 사이즈를 키워야 한다는 단점이 있다.
1GB 당 3IOPS를 제공받기 때문에 최대 IOPS인 16,000를 얻기 위해서는 5334GB 만큼의 드라이브 볼륨을 프로비저닝해야한다.

이와 달리, gp3는 볼륨 크기와 상관없이 IOPS와 처리량을 독립적으로 높일 수 있다.

Provisioned IOPS (PIOPS) SSD

고성능의 IOPS 를 가져야 하는 경우(16,000 IOPS 이상이 필요한 경우)에 사용한다.
볼륨의 크기는 4Gib ~ 16Tib이며 최대 IOPS 는 Nitro EC2 인스턴스에서 사용할 때는 64,000이고, 일반적인 인스턴스에서는 32,000이다.

Hard Disk Drive (HDD)

부팅 볼륨이 될 수 없고 볼륨의 크기는 125GB ~ 16TiB이다.

st1은 빅데이터, 데이터 웨어하우징, 로그 처리에 적합하다.
sc1은 자주 액세스되지 않는 데이터를 저장하기 위한 데이터 아카이빙 용도로 주로 사용된다.

EBS 다중 연결

하나의 EBS 볼륨을 같은 가용 영역에 있는 여러 EC2 인스턴스에 연결할 수 있게 하는 기능.
단, io1/io2 볼륨만 사용 가능..

각 인스턴스는 볼륨에 대한 읽기/쓰기 권한을 모두 갖는다.
즉, 동시에 읽고 쓰기가 가능하다.
한 번에 16개까지의 EC2 인스턴스만 같은 볼륨에 연결할 수 있다.
다중 연결을 위해 반드시 클러스터 파일 시스템을 사용해야 한다.

EBS 암호화

EBS 볼륨을 생성하면 다음과 같은 일이 발생한다.

저장 데이터가 볼륨 내부에 암호화된다.
인스턴스와 볼륨간의 전송 데이터가 암호화된다.
스냅샷과 이를 통해 생성된 볼륨이 암호화된다.

KMS에서 암호화 키를 생성해 AES-256 암호화 표준을 갖는다.

Amazon EFS

EFS(Elastic File System)은 관리형 NFS(Network File System)이다.

네트워크를 통해 연결되기 때문에 많은 EC2 인스턴스에 마운트될 수 있다.
심지어 해당 인스턴스들은 서로 다른 AZ에 위치할 수도 있다.
가용성과 확장성이 높다.
비싸다. gp2 볼륨의 3배 가격이고 사용한 만큼 비용을 지불하므로 미리 프로비저닝할 필요가 없다.
내부적으로 NFS 프로토콜을 사용하며 EFS에 대한 접근을 제한하기 위해서는 보안그룹을 설정해야 한다.
윈도우가 아닌 Linux기반 AMI에만 호환된다.
KMS를 사용해서 EFS 드라이브에서 미사용 암호화를 활성화할 수 있다. Linux 표준 파일 시스템(Posix 시스템)을 사용하고 표준 파일 API가 있다.

서로 다른 AZ에 위치한 인스턴스 간에 데이터를 공유할 수 있다는 장점으로 콘텐츠 관리, 웹 서빙, 데이터 공유 등에 주로 사용한다.

EFS 성능 개선

EFS scale

동시 NFS 클라이언트 수천 개와 10GB 이상의 처리량을 확보할 수 있다.
PB 규모의 네트워크 파일 시스템으로 자동 확장할 수 있다.

Performance Mode (성능 모드)

General Purpose (범용) : 지연시간이 민감할 때 사용.
Max I/O : 지연시간이 더 길지만 처리량과 병렬성이 높다. 빅 데이터 애플리케이션이나 미디어 처리 시에 유용하다.

Throughput Mode (처리량 모드)

Bursting : 기본 초당 처리량인 50MiB에 100MiB의 버스팅 처리량을 추가한다.
Provisioned : 스토리지 크기에 상관없이 처리량을 설정하고 싶은 경우에 사용한다. 기본적으로 스토리지 용량이 커질 수록 처리량이 증가하는 반면에, Provisioned를 통해 스토리지 용량과 처리량을 분리할 수 있다.
Elastic : 워크로드에 따라 처리량을 자동으로 조절한다. 워크로드를 예측하기 어려울 때 사용하면 유용하다.

스토리지 계층

성격이 다른 데이터들을 분리하여 관리하기 위해 NFS는 계층 형태로 파일을 관리한다.

Standard : 자주 액세스 하는 파일을 위한 계층
EFS-IA (Inferquent Access) : 자주 액세스 하지 않는 파일을 위한 계층. 액세스 하면 비용이 발생하지만 단순 접근의 경우 비용이 발생하지 않는다.
Archive : 거의 액세스 하지 않는 파일을 위한 계층.