Elastic Block Store, 가상 저장 장치.
AWS에서 EBS라는 이름으로 개별적인 저장 장치를 블록 레고처럼 떼어 놓았다.
오로지 블록화된 저장 공간으로 데이터에 자주, 빠르게 액세스할 때 필요하다. 스냅샷 기능도 지원한다.
저장 장치 상태는 그대로두고 현재 사양이 지나치게 높거나 낮은 경우 다른 사양의 인스턴스로 변경하고 싶을 때가 있다.
ex) c6g.large
=> t3.small
로 변경하고싶다.
인스턴스 유형 변경시 인스턴스를 '중지'해야 하는데, 그냥 종료해버리면 그간 쌓아둔 데이터가 모두 날아가게된다. 이 때 요긴하게 쓸 수 있는 것이 EBS다.
ex) DB에 이미지 파일 경로가 저장되어있고 요청이 있을 때마다 이미지 파일을 Delivery 하는 이미지 캐시 EC2 서버 그룹
👉🏻 각각의 EC2 에 파일 복제본을 여럿 가지는 것보다 성능이 뛰어난 EBS 볼륨 하나를 공유하는 것이 비용, 성능, 관리 면에서 모두 유리하다.
무적권 Provisioned IOPS SSD Volume 을 써야한다.
어느 솔루션이나 그렇듯, 공유 EBS도 동기화 이슈를 해결해야한다.
서로 다른 2개의 인스턴스가 동일한 파일을 동시에 '쓰기'한다고 생각해보자. 벌써 아찔하다.
다중 연결을 사용하는 볼륨에서 데이터 일관성을 유지하려면 애플리케이션이 인스턴스 간에 쓰기 순서를 지정해야 합니다.
Input/Ouput Operations Per Second. The oprations are measured in KB
Volume Type | Maximum I/O Size |
---|---|
SSD | 256 KB |
HDD | 1024 KB |
따라서 300 IOPS => 초당 256 KB * 300 => 76,800 KB
따라서 SSD 기준, 100GB 따리의 EBS 가 300 IOPS 를 갖는다면 최대 약 7Gbps 가능.
Amazon Machine Image
AWS에서 인스턴스 생성시 반드시 특정 AMI 이미지를 선택해야한다.
AMI 이미지에 따라 운영체제, 아키텍쳐, EBS , 추가 소프트웨어 등이 달라진다.
node.js 설치하고, 글로벌 패키지 설치하고, 환경변수 조정하고, 라이브러리 config 하고.. 이 일련의 configuration 과정을 단 한번만으로 복사 붙여넣기 하듯 재사용 할 수 있게하는 것
"원본과 복제본이 완벽히 동일하다"
비슷한 솔루션 후보로 다음과 같은 것들이 있다.
=> 꿀떡이다. 모든 Configuration 값 및 데이터는 그대로 불러오고, Storage 용량이나 인스턴스 유형만 바꿀 수 있다.
⚠️ 단, 사용 아키텍쳐는 일치해야한다. (ex . x86_64 <-> arm64 호환 불가능)
⚠️ AMI 이미지 생성 도중에 원본이 일시적으로 다운된다.
얼핏보면 유사해보이지만 다르다.
구분 | EBS snapshot | AMI image |
---|---|---|
저장 대상 | 스토리지 저장공간 상태 | 인스턴스의 전체 상태 |
비용 | 변경된 부분에 대해서만 (Changed Data Capture) | 이미지 생성마다 |
용도 | - 스토리지 백업 - 여러 인스턴스간 스토리지 공유 | - 인스턴스 Scale-out - 인스턴스 Templating |