[AWS] EC2 EBS와 Instance Storage, Root/Local/Ephemeral

개요

---

EC2 관련 작업을 도맡으면서 서버 운영을 위해서는 Storage 개념을 잘 이해하고 있어야 한다는 점을 알게되었다. 운영 관점에서 고려해보니 루트 볼륨, 이퍼머럴 스토리지, 부팅 디스크 등등 여러 용어도 확실히 알아야 겠다 싶어서 이번 포스팅을 통해 정리해보려 한다. 

 

1. EC2 Storage: EBS와 Instance Store

---

EC2에 연결할 수 있는 스토리지는 크게 다음과 같다. 이 포스팅에서는 EBS, Instance Store를 중점적으로 알아본다.

  EC2 스토리지
  ├── * EBS (Elastic Block Store)
  │   ├── 루트 볼륨 (부팅용)
  │   └── 추가 볼륨 (데이터용)
  │
  ├── * Instance Store (Ephemeral / Local Storage)
  │
  └── EFS (Elastic File System)

 

EBS와 Instance Store를 직관적으로 이해할 수 있는 이미지는 다음과 같다.

• EBS는 EC2와 네트워크로 연결되고, Instance Store는 물리 서버에 같이 설치된다. 

 

2. EBS(Elastic Block Store)

---

2.1 Block Store

 

블록 단위로 데이터를 저장하는 스토리지 방식으로, SAN(Storage Area Network)나 클라우드 기반 스토리지 환경에서 사용되는 기술이다. 

• 데이터를 일정한 크기의 블록으로 나누고, 각 블록에는 고유 주소가 부여된다.
• 이 식별자를 통해서 데이터를 매우 빠르게 검색할 수 있다.
• 빠른 성능에 최적화되어있기에 다른 스토리지에 비해 비쌈!

* Block Storage 이외에는 File Storage(EFS), Object Storage(S3) 등이 있다. (이미지 참고)

 

 

2.2 Elastic Block Store

EC2에 연결하여 사용하는 블록 스토리지로, EC2 Instance와 독립적으로 데이터 유지가 가능하다.

• EC2 Instance와 네트워크로 연결되어, 독립적으로 구성되므로 인스턴스 종료 후에도 데이터가 보존된다.
• 하나의 EC2 Instance에 여러 용도의 EBS를 붙일 수 있다.
  • 단, 속도를 위해 동일한 가용영역 내의 EC2만 연결이 가능하다.
  • 거꾸로, 하나의 EBS를 여러 EC2에 장착 가능하다. (EBS Multi Attach)

 

2.3 루트 볼륨/부팅 디스크

EC2 Instance를 생성하면 EBS가 루트 볼륨으로 설정된다. 

루트 볼륨의 역할

부팅 순서를 보면 루트 볼륨의 중요도를 알 수 있다! 루트 볼륨(root device)은 EC2 인스턴스와 같은 서버가 부팅할 때 사용하는 스토리지로, 운영체제와 기본 파일 시스템(/)을 포함한다.이 스토리지를 통해 커널이 메모리에 올라가고, 일반적으로 서버에서 하려는 작업들이 가동 가능한 시스템을 구축하게 된다. 

 

루트 볼륨: Instance Store(Ephemeral) Vs. EBS

EC2 Instance의 루트 볼륨은 EBS, Instance Store 모두 가능하지만 일반적으로는 EBS를 사용한다. (관련 문서)

 

⚫️  Amazon EBS-backed AMI

 

EBS를 Root Volume으로 사용하는 AMI다. 현재 AWS에서 생성되는 대부분의 EC2 인스턴스는 EBS-backed AMI를 사용한다. 공식문서에도 나와있듯, AWS에서는 EBS를 루트 볼륨으로 사용할 것을 권장한다.

 

이유는 뭘까?

• 인스턴스 서버는 언제든 실패할 수 있는데, EBS의 경우 인스턴스의 중단과 상관없이 데이터가 유지된다.
  • 가령 스케일링, 운영 중 설정 변경, 하드웨어 장애 등으로 인해 인스턴스의 중단이나 재생성은 피할 수 없는 이벤트인데, EBS를 루트 볼륨으로 사용하면 인스턴스의 중단 여부와 관계없이 루트 볼륨의 데이터는 그대로 유지된다.
• point-in-time스냅샷을 여러 AZ에 복제된 형태로 저장하기 때문에, 필요 시 완전한 볼륨 복구가 가능하다. (안정성 측면!) (관련 문서)
  
  • point-in-time snapshot: 특정 시점(point)의 볼륨 상태를 그대로 보존한 복사본을 의미한다. 단순한 파일 복사가 아니라 파일 시스템, 블록 레벨 데이터, 메타데이터를 포함한 볼륨 전체 상태 등의 특정 시점 기준으로 freeze해서 저장한다. 그래서 스냅샷으로부터 새 볼륨을 만들면 그 시점에 존재하던 특정 디스크 상태 그대로 복원된다.  
  • 주의할 점 ⚠️ : 이러한 스냅샷은 자동으로 백업되지 않기 때문에 정기적으로 EBS 스냅샷을 생성하거나, Amazon Data Lifecycle Manager, Backup 기능을 사용하여 자동 생성을 구축하는 등의 조치를 사용자가 취해야 한다.

 

⚫️  Amazon S3-backed AMI

Instance Store를 Root Volume으로 사용하는 AMI다. AMI 자체는 S3에 저장되고, 실제 루트 볼륨은 인스턴스 내부의 로컬 스토리지(Instance Store) 에 생성되는 구조다.>

 

과거에 사용되다가 deprecated 되어가는 이유는 뭘까?

• Instance Store는 인스턴스의 생명 주기와 완전히 결합된 스토리지다. 즉, 인스턴스 장애가 OS 및 서버 상태 전체 유실로 이어진다.
• 스토리지 계층에서의 장애 복구 모델이 없다.

그렇다면 언제 사용할까?

• 성능이 생존보다 중요한 상황
• 기본 설정이 모두 코드로 관리되는 경우 (AMI나 user-data Script를 통해 부팅 시 설치)
• 데이터는 외부(S3, DB, Redis 등)에 존재

 

2.5 EBS 볼륨 유형 타입

EBS 볼륨 타입은 일반 컴퓨터에서 SSD를 쓸지, HDD를 쓸지 고르는 것과 비슷한데, AWS는 용도별로 세분화해서 제공한다.

• SSD: gp3, gp2, io2, io1
  • gp: 웹서버, 개발환경, 소규모 DB에 사용하고 가격 대비 성능 균형이 좋아서 보편적으로 사용
  • io: 대규모 DB가 필요할 때 사용하고 IOPS를 직접 지정 가능
• HDD: st1, sc1

 

3. Instance Store

---

3.1 Instance Store

Instance Store는 EBS처럼 붙였다 떼었다 하는 것이 아니라, EC2 인스턴스가 실행되는 물리 호스트에 직접 연결된 스토리지다. Amazon에서는 인스턴스 유형으로 EC2에 Instance Store가 포함되었는지, 아닌지 구분한다. 

 

EBS가 인스턴스와 논리적으로 분리된 블록 스토리지라면, Instance Store는 인스턴스 타입 자체에 물리적으로 포함된 스토리지라는 점에서 근본적인 차이가 있다.

 

이 때문에 Instance Store는 다음과 같은 특성을 가진다.

• 인스턴스 생성 시 함께 제공됨
• "attach / detach 개념이 없음
• 다른 인스턴스에 재사용 불가
• 인스턴스 생명주기와 완전히 결합됨

AWS 공식 문서에서도 Instance Store를 다음과 같이 정의한다.(유저 가이드 문서)

Instance store provides temporary block-level storage for your instance.
This storage is physically attached to the host computer for an EC2 instance.

 

즉, Instance Store는 ‘임시(temporary)’ 스토리지이며, 인스턴스가 종료되거나 물리 호스트에 문제가 발생하면 데이터는 복구할 수 없다. 

 

3.2 Instance Store와 NVMe

Instance Store의 높은 성능은 NVMe(Non-Volatile Memory Express) 인터페이스 덕분이다.

NVMe란?

NVMe는 SSD를 빠르게 사용하기 위해 설계된 스토리지 프로토콜이다. 기존 SATA 인터페이스는 HDD 시절에 만들어진 규격이라 SSD의 성능을 온전히 발휘하지 못했는데, NVMe는 PCIe 레인을 통해 CPU와 거의 직통으로 연결되어 훨씬 빠른 I/O를 제공한다.

SATA SSD:  CPU ──(SATA 컨트롤러)──→ SSD
NVMe SSD:  CPU ──(PCIe 직통)──────→ SSD

 

쉽게 말해, 같은 SSD라도 어떤 인터페이스로 연결하느냐에 따라 속도가 달라진다. NVMe는 SSD를 더 빠르게 전송하는 인터페이스!

Instance Store가 빠른 이유

Instance Store는 EC2가 실행되는 물리 호스트에 장착된 NVMe SSD에 직접 연결된다. 네트워크를 경유하지 않고 PCIe로 바로 붙어있기 때문에 낮은 지연시간과 높은 IOPS를 제공한다. (관련 문서)

Instance Store:  EC2 ──(PCIe)──→ 물리 NVMe SSD (로컬)

그럼 EBS는?

Nitro 기반 EC2에서는 EBS도 NVMe 디바이스로 노출된다. 다만 실제로는 네트워크를 경유하는 원격 스토리지이고, OS에게 NVMe처럼 보이도록 에뮬레이션하는 것이다. NVMe 드라이버가 더 효율적이기 때문에 이런 방식을 사용한다. (관련 문서)

EBS (Nitro):     EC2 ──(가상 NVMe)──→ 네트워크 ──→ EBS 볼륨 (원격)

 

실제로 Nitro 인스턴스에서 lsblk를 치면 EBS 볼륨도 nvme로 표시된다.

$ lsblk
nvme0n1      259:0    0   8G  0 disk         # EBS 루트 볼륨
└─nvme0n1p1  259:1    0   8G  0 part /
nvme1n1      259:2    0 100G  0 disk /data   # EBS 추가 볼륨
nvme2n1      259:3    0 900G  0 disk /local  # Instance Store (진짜 로컬 NVMe)

 

* Instance Store는 상황에 따라 다른 이름으로 불리기도 한다.

• Local Storage: 네트워크가 아닌 물리적 서버로 붙어있는 것
• Ephemeral Storage: 인스턴스가 종료될 때 사라지는 임시 스토리지 (↔ EBS는 인스턴스가 다운되어도 영구 저장됨.)

 

3.4 Instance Storage 특성

로컬 스토리지는 날아가도 되지만 속도가 중요한 데이터에 사용한다. (로컬 캐시와 같은...) 아래와 같은 활용 케이스가 대표적이다.

• Kafka Broker
  • >메시지 쓰기/읽기가 초당 수십만건: 속도 필요
  • 카프카는 여러 복제본(3대)를 유지하기 때문에 1대가 죽어도 데이터는 그대로!
• Spark/EMR
  • 여러 Stage 간 데이터를 주고 받을 때, Shuffle 데이터를 Instance Store에 저장
  • 대략 이런 구조임:   [Stage 1] → shuffle 데이터 → [Stage 2] → shuffle 데이터 → [Stage 3]
• 캐싱! Redis
• 로그 버퍼 (S3 전송 전 임시 저장)
  • 실제 장애 상황에서 i3en.24xlarge 인스턴스를 여러 대 띄우고, Tantivy 라이브러리로 특정 필드가 존재하는 파일을 다운로드하는 케이스를 본 적 있다.
  • S3로 보내기 전에 잠깐 모아두는 용도이고 주기적으로 S3로 Flush하는 방식
• ML 임시 데이터
  • S3 원본 데이터를 로컬에 복사해서 학습 중 빠른 I/O를 확보

 

3.5 Instance Store와 인스턴스 유형

Amazon EC2에서는 모든 인스턴스 유형이 Instance Store를 제공하지 않는다. AWS는 인스턴스 유형 자체로 Instance Store 포함 여부를 구분한다. 대표적으로 d suffix가 붙은 인스턴스 유형은 Instance Store를 포함한다. 여기서 d는 dense storage를 의미하며, 로컬 NVMe SSD 기반의 Instance Store가 포함된 인스턴스를 나타낸다.

• m5d, c5d, r5d
• c6gd, r6gd 등

또한 다음과 같은 suffix들도 Instance Store와 관련이 있다.

• i : I/O 최적화 (예: i3, i4i)
• h : HDD 기반 대용량 스토리지 (예: h1)

 

🔖 실제 운영에서 알게된 Local Storage 관련 지식(Local Storage 제약 정책)

업무하면서 알게된 것. kubelet의 Disk Pressure는 특정 컨테이너의 Instance Local Storage 점유로 인해서 발생할 수 있다.

이러한 특정 파드의 노드 로컬 스토리지 점유를 막기 위해서 아래와 같은 정책을 적용할 수 있다.

resources:
  limits:
    ephemeral-storage: 10Gi
  requests:
    ephemeral-storage: "0"

해당 정책으로 죽은 Pod는 ContainerStatusUnknown 또는 Failed 상태를 보인다. (Pod ephemeral local storage usage exceeds the total limit of containers 와 같은 메시지도 참고할 수 있다.)

 

마무리!

---

EC2 운영을 하려면 스토리지 선택 기준과 각 볼륨의 역할을 알아두는 게 중요한 것 같다.

• EBS vs Instance Store: 네트워크로 연결되는 영구 스토리지 vs 물리 서버에 붙은 휘발성 로컬 스토리지
• 루트 볼륨 vs 추가 볼륨: 부팅 디스크 vs 데이터 저장용 볼륨
  • 부팅 디스크 역할! EC2가 시작될 때 OS를 로드하는 루트 볼륨
• Ephemeral / Local Storage: Instance Store를 부르는 다른 이름들로, 빠르지만 인스턴스 종료 시 사라지는 스토리지
  • 로컬 스토리지의 역할: 캐시, 임시 데이터, shuffle 데이터 등 빠른 I/O가 필요한 용도
• NVMe: EBS와 Instance Store 모두에서 사용하는 스토리지 인터페이스 표준

 

또, 스토리지 용도를 잘 알고 사용하는 것

• 영구 저장이 필요한 데이터를 Instance Store에 두거나
• 반대로 빠른 I/O가 필요한 워크로드를 EBS에만 의존하거나
• 루트 볼륨과 데이터 볼륨의 역할을 명확히 나누지 않은 경우