Amazon EBS

서버를 교체하거나 재시작할 수 있는데 디스크가 인스턴스 생명주기에 묶여 있으면 데이터가 같이 사라집니다. 애플리케이션은 계속 돌아가도 저장소가 분리되지 않으면 복구와 증설 때마다 불안해집니다.

초기 클라우드 VM은 인스턴스와 스토리지가 강하게 묶여 있어 인스턴스를 교체하려면 디스크 데이터를 수동으로 복사하고 새 서버에 다시 붙이는 작업이 필요했습니다. 더 큰 디스크가 필요해도 스토리지만 따로 증설할 수 없어서, 더 큰 인스턴스 타입으로 옮기거나 새 디스크를 만들어 데이터를 마이그레이션해야 했습니다. 인스턴스가 예기치 않게 종료되면 그 위의 데이터도 같이 사라졌고, 백업 역시 스크립트와 수작업에 의존해 복구 시점이 불확실했습니다. 이런 압력 때문에 컴퓨팅과 분리되어 독립적으로 존속하고, 스냅샷으로 안전하게 백업할 수 있는 영구 블록 스토리지 계층인 EBS가 필요해졌습니다.

EBS는 EC2에 붙는 영구 블록 스토리지 볼륨을 제공하고, 성능 특성에 따라 타입을 고를 수 있습니다. 각 볼륨은 같은 가용 영역 안에서 자동 복제되어 구성요소 장애를 견디고, 스냅샷으로 백업하며, 필요하면 다른 인스턴스에 다시 연결해 데이터를 이어받을 수 있습니다.

EBS와 EFS는 둘 다 저장소지만 접근 방식이 다릅니다. EBS는 한 인스턴스에 붙는 디스크이고, EFS는 여러 인스턴스가 동시에 마운트하는 네트워크 파일시스템입니다. 부팅 디스크나 단일 서버용 영구 볼륨이 필요하면 EBS를 보고, 여러 컴퓨팅 리소스가 같은 파일을 함께 읽고 써야 하면 EFS를 보면 됩니다.

가장 기본적인 장면은 EC2 인스턴스의 부팅 볼륨입니다. 운영체제와 애플리케이션 바이너리가 담기는 루트 디스크로, 인스턴스를 교체하더라도 스냅샷에서 새 볼륨을 만들어 바로 이어 붙일 수 있습니다. 또 다른 장면은 직접 운영하는 데이터베이스의 데이터 디스크입니다. RDS를 쓰지 않고 EC2 위에 PostgreSQL이나 MongoDB를 올리는 경우 io2 볼륨으로 IOPS를 확보하고, 스냅샷 스케줄로 야간 백업을 자동화하는 구성이 흔합니다. 여러 서버가 동시에 같은 파일을 공유해야 하는 경우에는 맞지 않습니다.