인스턴스 스토어 vs EBS 비교
1. 비교표
항목 | 인스턴스 스토어 (Instance Store) | EBS (Elastic Block Store) |
연결 방식 | 물리적 호스트에 직접 부착 (Local) | 네트워크를 통한 연결 (Network-attached) |
지속성 | 휘발성 (Ephemeral) | 비휘발성 (Persistent) |
성능 | 매우 높음 (낮은 지연 시간, 높은 IOPS) | 높음 (인스턴스 타입 및 볼륨 설정에 의존) |
비용 | 인스턴스 요금에 포함 (무료 느낌) | 사용한 용량 및 성능만큼 별도 과금 |
중지(Stop) 시 | 데이터 영구 삭제 | 데이터 보존 |
주요 용도 | 캐시, 버퍼, 임시 데이터, 복제된 DB | 루트 볼륨, 장기 보관 DB, 일반 업무 |
2. 왜 인스턴스 스토어는 데이터가 사라지나요?
인스턴스 스토어는 EC2가 돌아가는 물리적인 서버 하드웨어에 박혀 있는 디스크입니다. 따라서 다음과 같은 상황에서 데이터가 삭제됩니다.
인스턴스를 중지(Stop) 하거나 종료(Terminate) 할 때.
물리적 호스트 하드웨어에 장애가 발생했을 때.
참고: 단순히 OS 내에서 '재부팅(Reboot)' 하는 것으로는 데이터가 사라지지 않습니다.
데이터 유실 방지 및 가용성 확보 전략
"인스턴스 스토어는 빠르지만 위험하다"는 특성을 이해했다면, 다음과 같은 설계로 리스크를 관리해야 합니다.
1. 어플리케이션 계층의 복제 (RAID 및 분산 처리)
소프트웨어 RAID: 인스턴스 스토어 여러 개를 RAID 1(미러링)이나 RAID 10으로 묶어 단일 디스크 장애에 대비하세요.
분산 아키텍처: NoSQL(MongoDB, Cassandra)이나 Kafka처럼 데이터 자체를 여러 노드에 복제하는 솔루션을 사용하면, 노드 하나가 죽어도 데이터 유실을 막을 수 있습니다.
2. S3/EBS로의 주기적 동기화
Checkpointing: 중요한 결과물이나 로그는 주기적으로 Amazon S3나 별도의 EBS 볼륨으로 복사하는 스크립트를 실행하세요.
로그 배송: CloudWatch Logs나 데이터 스트리밍(Kinesis)을 통해 실시간으로 로그를 외부로 빼두는 것이 표준입니다.
3. EBS 전용 백업 전략
EBS라고 무조건 안전한 것은 아닙니다. 실수로 지우거나 볼륨 자체가 손상될 확률(0.1~0.2%)이 존재합니다.
EBS Snapshots: Data Lifecycle Manager(DLM)를 설정하여 매일/매시간 자동으로 스냅샷을 찍으세요.
Multi-AZ 배포: 하나의 가용 영역(AZ) 전체가 장애가 날 수 있으므로, 핵심 데이터는 다른 AZ의 인스턴스나 RDS로 복제해두어야 합니다.
댓글
댓글 0개
이 문서에는 댓글을 달 수 없습니다.