- 온프레미스의 RAID는 “서버나 스토리지 장비 안에서 여러 디스크를 묶어 성능/가용성을 만드는 방식”
- 클라우드에서는 그 역할을 “클라우드 스토리지 서비스 자체”가 대신함
즉, 사용자가 RAID 1, 5, 10을 직접 만지기보다 디스크 서비스가 내부적으로 복제/분산/장애대응을 제공하는 구조가 일반적
RAID(Redundant Array of Independent Disks)는 여러 개의 물리 디스크를 하나의 논리 디스크처럼 묶어 성능 향상, 용량 확장, 장애 대비를 동시에 달성하기 위한 기술이다. RAID는 구성 방식에 따라 다양한 레벨로 나뉘며, 각각의 레벨은 데이터 보호 방식과 성능 특성이 다르다.
온프레미스에서 RAID는 보통 3가지를 위해 씁니다.
예를 들어 RAID 1은 미러링, RAID 5는 패리티, RAID 10은 미러+스트라이핑이죠.
| RAID 레벨 | 동작 방식 | 장점 | 단점 | 비유 |
|---|---|---|---|---|
| RAID 1 (미러링) | 동일한 데이터를 여러 디스크에 복제 저장 | - 높은 데이터 안정성 - 디스크 1개 장애 허용 - 읽기 성능 향상 | - 저장 효율 50% - 비용 증가 | 같은 파일을 USB 두 개에 동시에 저장 |
| RAID 5 (패리티) | 데이터를 여러 디스크에 분산 저장 + 패리티 생성 | - 디스크 1개 장애 복구 가능 - 저장 효율 우수 - 읽기 성능 좋음 | - 쓰기 성능 저하 (패리티 계산) - 장애 시 성능 급감 | 여러 명이 데이터 나눠 들고, 한 명이 복구용 힌트 보관 |
| RAID 10 (미러+스트라이핑) | 미러링 후 데이터를 분산 저장 (RAID 1 + RAID 0) | - 매우 높은 성능 - 높은 안정성 - 빠른 복구 | - 저장 효율 50% - 비용 높음 | 데이터를 두 벌로 복사 후, 여러 사람에게 나눠 빠르게 처리 |
클라우드 VM에 디스크를 붙여 쓰면, 사용자 입장에서는 그냥 하나의 블록 디스크처럼 보입니다.
하지만 실제 아래쪽 구현에서는 클라우드 사업자가 디스크 복제, 장애 복구, 내구성 관리를 하고 있습니다.
클라우드에서는 “이 디스크가 RAID 5냐 RAID 10이냐”를 보통 묻지 않고 대신 아래 사항을 고려합니다.
클라우드에서 “디스크 고장 대비”는 이미 서비스 내부에서 처리하는 경우가 많습니다. 예를 들어 AWS EBS는 볼륨이 생성되면 동일 AZ 내 여러 서버에 자동 복제되어 단일 부품 장애로 인한 데이터 손실을 막는다고 명시합니다. Azure Managed Disk도 LRS/ZRS 같은 중복 옵션으로 복제를 제공합니다. GCP Persistent Disk도 zonal 또는 regional 복제 구성을 제공합니다.
| 구분 | Azure Managed Disk | AWS EBS | GCP Persistent Disk |
|---|---|---|---|
| 기본 단위 | Managed Disk | EBS Volume | Persistent Disk |
| 기본 내구성 제공 방식 | LRS (3중 복제) | AZ 내 자동 복제 | Zonal Disk (자동 복제) |
| AZ 단위 보호 | ZRS (다중 AZ 동기 복제) | X (기본은 AZ 내부만) | Regional Disk (2개 AZ 복제) |
| 사용자가 RAID 구성 필요성 | 거의 없음 | 거의 없음 | 거의 없음 |
| RAID 1 (미러링) 대응 개념 | LRS / ZRS | EBS 자체 복제 | Zonal / Regional Disk |
| RAID 0 (성능 확장) | 여러 Disk striping 가능 | 여러 EBS RAID 0 가능 | 여러 Disk striping 가능 |
| RAID 5/6 (패리티) | 내부적으로 숨김 (사용자 미노출) | 내부 구현 (미노출) | 내부 구현 (미노출) |
| 성능 확장 방식 | Disk 여러 개 + Striping | EBS 여러 개 + RAID 0 | 여러 Disk + Striping |
| 장애 도메인 | 디스크 → 스토리지 스탬프 → AZ | 디스크 → AZ | 디스크 → AZ |
| 온프레 RAID 대체 방식 | RAID 대신 redundancy 옵션 선택 | RAID 대신 서비스 내구성 사용 | RAID 대신 디스크 타입 선택 |
Azure Managed Disk는 대표적으로 LRS와 ZRS 같은 중복 옵션이 있습니다.
즉, 온프레미스에서 RAID 1처럼 “복제해서 안전하게”라는 목적을, Azure에서는 디스크 redundancy 옵션으로 선택하는 느낌입니다. 다만 이것은 RAID 레벨을 직접 고르는 게 아니라, 서비스 레벨 중복성 정책을 고르는 것입니다.
AWS EBS는 볼륨이 동일 Availability Zone 내 여러 서버에 자동 복제됩니다.
그래서 단일 디스크 고장 대비를 위해 사용자가 RAID 1을 꼭 만들 필요는 없습니다.
다만 AWS도 여러 EBS 볼륨을 OS에서 묶어 소프트웨어 RAID 0/1/5/6/10처럼 구성하는 것은 가능합니다.
AWS에서는 아래와 같이 제공합니다.
GCP Persistent Disk는 zonal disk 또는 regional disk로 쓸 수 있습니다.
regional disk는 같은 리전의 두 개 존에 동기 복제됩니다.
즉 이것도 RAID를 직접 보여주기보다 디스크 자체를 지역/존 단위로 복제된 관리형 서비스로 제공하는 구조입니다.
"RAID와 클라우드 중복성은 같은 게 아닙니다."
온프레미스 RAID는 주로 장비/컨트롤러/디스크 단위 보호입니다.
반면 클라우드 중복성은 아래와 같은 더 큰 장애 도메인을 다룹니다.
예를 들어 Azure ZRS는 여러 AZ에 동기 복제하고, GCP regional disk도 두 존에 동기 복제합니다. 이것은 RAID 1보다 더 “인프라 단위”의 보호 개념에 가깝습니다.
그래서 실무적으로는 이렇게 생각하면 편합니다.
목적은 일부 겹치지만 계층이 다른것을 인지해야합니다.
여전히 2가지 경우에는 RAID 개념이 남습니다.
예를 들어 VM 하나에 여러 Managed Disk / EBS / Persistent Disk를 붙여서
OS에서 striping(RAID 0)처럼 묶어 더 높은 IOPS/처리량을 노릴 수 있습니다.
이건 특히 대형 DB, 고성능 로그 처리, 초고성능 파일시스템에서 여전히 씁니다. AWS는 공식적으로 EBS RAID 구성을 안내합니다.
예를 들어 어떤 소프트웨어가 여러 디스크를 하나의 데이터 볼륨으로 묶도록 설계되어 있으면, 클라우드에서도 VM 내부에서 mdadm, LVM, Storage Spaces 같은 방식으로 RAID/볼륨 구성을 할 수 있습니다.
다만 이 경우에도 “디스크 고장 보호” 목적의 RAID”보다 “성능/볼륨 구성” 목적이 더 많습니다. 기본 복제는 이미 클라우드 디스크 서비스가 어느 정도 해주기 때문입니다.
대략 이렇게 대응해서 이해하면 됩니다.
RAID 1의 미러링 감각
→ 클라우드의 디스크 복제(LRS/ZRS/regional disk 등)
RAID 0의 스트라이핑 감각
→ 여러 클라우드 디스크를 OS에서 묶어 성능 합산
RAID 5/6의 패리티 감각
→ 사용자에게 직접 노출되기보다는, 서비스 내부 분산 저장/복제 방식으로 숨겨짐
→ 사용자는 보통 패리티를 직접 설정하지 않음
온프레미스에서 “RAID를 어떻게 짤까?”를 고민했다면, 클라우드에서는 보통 이 순서로 바뀝니다.
기본 디스크 자체 중복성은 무엇인가?
Azure LRS/ZRS, GCP zonal/regional, AWS EBS AZ 내 복제 등
성능이 부족하면 여러 디스크를 묶을 필요가 있는가?
이때만 OS 레벨 RAID 0/LVM striping 등을 고려. AWS는 EBS RAID 구성을 공식 안내합니다.
디스크 보호와 DR은 별개인가?
네, 별개입니다. 디스크 복제는 “스토리지 가용성”이고, 백업/스냅샷/리전 간 복제는 “복구 전략”입니다. Azure와 GCP 문서도 복제 디스크와 별개로 백업/복구를 권장합니다.
온프레미스 RAID는 클라우드에서 사라진 게 아니라 대부분 “클라우드 디스크 서비스 내부 기능”으로 흡수되었고, 사용자는 RAID 레벨 대신 redundancy 옵션과 성능 티어를 선택하는 방식으로 바뀌었다고 보면 됩니다.