5.6 스토리지 설계 - DAS, NAS, SAN과 용량·성능 산정
DAS·NAS·SAN과 RAID, 오브젝트 스토리지의 특징, 동시 편집 스트림 수와 비트레이트로 필요한 처리량을 계산하는 방법, 원본·프록시·아카이브 계층 구성 원칙을 설명합니다.
#스토리지는 MAM 성패를 가르는 요소
영상 파일은 용량도 크고, 한 번 읽으면 오래 연속으로 읽습니다. 여러 사람이 동시에 편집하고 변환 서버도 동시에 읽으면 스토리지 성능이 부족해져 화면이 끊기고 작업이 멈춥니다. 반대로 과하게 설계하면 비용이 큽니다. 그래서 필요한 성능을 숫자로 계산하는 것부터 시작합니다.
#접속 방식: DAS, NAS, SAN
| 방식 | 구조 | 특징 | 방송 환경에서의 위치 |
|---|---|---|---|
| DAS (Direct Attached Storage) | 서버/PC에 직접 연결 | 단순, 빠름. 공유 불가 | 단독 작업 장비, 캡처 장비 |
| NAS (Network Attached Storage) | 네트워크로 파일 공유(SMB/NFS) | 설치·관리 쉬움. 파일 서버가 병목 | 일반 공유, 프록시, 소규모 편집 |
| SAN (Storage Area Network) | 블록 단위로 전용 네트워크(Fibre Channel 등)로 연결, 전용 공유 파일 시스템 | 고성능·저지연, 여러 편집기가 동시 접근. 비싸고 복잡 | 대규모 편집·제작 스토리지 |
| Scale-out NAS | 노드를 늘려 용량과 성능을 함께 확장 | NAS의 편리함 + 높은 성능 | SAN의 대안으로 확산 |
#RAID
RAID는 여러 디스크를 묶어 성능과 안정성을 얻는 방식입니다.
| RAID | 구성 | 용량 효율 | 장애 허용 | 특징 |
|---|---|---|---|---|
| 0 | 스트라이핑 | 100% | 없음 | 빠르지만 하나만 고장 나도 전체 유실 |
| 1 | 미러링 | 50% | 디스크 1개 | 단순, 읽기 빠름 |
| 5 | 패리티 1개 | (N-1)/N | 디스크 1개 | 쓰기 성능 저하, 재구축 중 위험 |
| 6 | 패리티 2개 | (N-2)/N | 디스크 2개 | 대용량 디스크에서 권장 |
| 10 | 미러 + 스트라이핑 | 50% | 구성에 따라 | 성능과 안정성의 균형 |
대용량 디스크가 보편화되면서 RAID 재구축 시간이 길어졌고, 그동안 추가 장애가 나면 데이터를 잃습니다. 그래서 대용량 스토리지에서는 RAID 6 계열이나 소프트웨어 정의 방식을 쓰고, 중요한 것은 RAID를 백업으로 착각하지 않는 것입니다. RAID는 디스크 고장에 대한 보호일 뿐 삭제, 오작동, 화재, 랜섬웨어는 막지 못합니다. 별도의 복제(아카이브, 외부 사본)가 필요합니다.
#처리량 계산
필요한 성능은 동시에 읽고 쓰는 스트림 수 × 비트레이트로 계산합니다. 예를 들어 다음 환경을 가정합니다.
- 동시에 편집하는 편집자 20명, 각자 1개 스트림(DNxHD 145Mbps, 1080i)
- 안전 여유 1.3배
계산식:
총 처리량 = 동시 스트림 수 × 비트레이트
= 20 × 145 Mbps = 2.9 Gbps = 약 362 MB/s
여유 1.3배 적용 = 약 471 MB/s
editors, mbps = 20, 145
per = mbps / 8 # MB/s per stream
print(f"{editors} 스트림 × {mbps}Mbps = {editors*mbps/1000:.2f} Gbps = {editors*per:.0f} MB/s")
print(f"여유 1.3배: {editors*per*1.3:.0f} MB/s")
20 스트림 × 145Mbps = 2.90 Gbps = 362 MB/s
여유 1.3배: 471 MB/s
여기서 반드시 고려할 점이 있습니다.
- 편집은 한 번에 한 스트림이 아닙니다. 멀티 트랙 편집은 영상 여러 개를 동시에 읽습니다(예: 4트랙 = 4배).
- 쓰기도 있습니다. 인제스트·렌더링은 쓰기 트래픽이 큽니다.
- 무작위 접근(탐색, 컷 편집)은 순차 처리량보다 IOPS와 지연 시간이 중요합니다.
- 네트워크 대역폭: 2.9Gbps는 1GbE로 불가능하고, 10GbE에서 서버당 한 개 링크로 충분해 보여도 스토리지 서버 측 총합을 봐야 합니다.
- 변환·분석 서버의 읽기(프록시 생성, QC)가 편집과 동시에 일어납니다.
#용량 계산
필요 용량 = 보관 시간 × 시간당 용량
145Mbps = 시간당 65.2GB → 3,000시간 = 약 195.8TB
- 연간 증가량을 추정하고, 포맷별(원본, 프록시, 썸네일)로 나눠 계산합니다. 프록시는 원본의 1~5% 수준입니다(2장).
- RAID 오버헤드, 파일 시스템 오버헤드(약 10~20%), 여유 공간(80% 이하 사용 권장)을 반영합니다.
- 아카이브 정책(온라인에 몇 개월 두고 이후 이동하는가)이 온라인 용량을 결정합니다.
#계층 구성
모든 파일을 가장 빠른 스토리지에 둘 필요는 없습니다. 접근 빈도와 요구 성능에 따라 계층을 나눕니다.
| 계층 | 용도 | 매체 | 접근 |
|---|---|---|---|
| 온라인(Tier 1) | 편집·송출 중인 소재 | SSD/고성능 HDD (SAN/Scale-out NAS) | 즉시 |
| 프록시 | 웹 미리보기 | 일반 NAS | 즉시 |
| 니어라인(Tier 2) | 최근 방송분, 곧 쓸 소재 | 대용량 HDD, 오브젝트 스토리지 | 수 초~수 분 |
| 오프라인(Tier 3) | 장기 보관 | LTO 테이프, 광디스크, 클라우드 아카이브 | 수 분~수 시간 |
이 계층 간 이동을 자동으로 처리하는 소프트웨어가 HSM(계층형 스토리지 관리)입니다(6장에서 자세히 다룹니다).
#접근 경로 분리
원본과 프록시의 네트워크 경로와 스토리지를 분리하세요. 웹에서 많은 사용자가 프록시를 재생해도 편집용 원본 스토리지의 성능에 영향을 주지 않아야 합니다.
#오브젝트 스토리지
파일 시스템 대신 오브젝트(데이터 + 메타데이터 + 고유 ID) 단위로 저장하는 방식입니다. S3 호환 API가 사실상 표준입니다.
| 장점 | 단점 |
|---|---|
| 용량 확장이 쉽고 단가가 낮음 | 폴더 구조 기반 작업(편집기)에 부적합 |
| 지리적 복제, 버전 관리 | 지연 시간이 큼, 파일 일부 수정 불가(통째로 교체) |
| API로 접근, MAM과 연동 쉬움 | 일부 구간만 읽는 접근(Range 읽기)을 지원해야 구간 추출 가능 |
니어라인과 아카이브 계층에 적합하며, 편집 작업은 온라인 계층에서 하고 완료된 소재를 오브젝트 스토리지로 내보내는 구성이 일반적입니다.
#설계 체크리스트
| 질문 | 확인 |
|---|---|
| 동시 스트림 수와 비트레이트는? | 처리량 계산 |
| 편집기가 요구하는 파일 시스템/인증 스토리지가 있는가? | 제조사 요구사항 |
| 읽기와 쓰기 비율, 무작위 접근 비율은? | IOPS·지연 요구 |
| 원본과 프록시의 경로는 분리되는가? | 성능 간섭 방지 |
| 연간 증가량과 보관 정책은? | 용량·계층 |
| 장애 시 복구 목표(RPO/RTO)는? | 복제·백업 구성 |
| 확장 방법(성능 증설, 용량 증설)은? | 미래 성장 |
#정리
- 스토리지는 동시 스트림 수 × 비트레이트로 필요한 처리량을 계산하고, 용량은 시간당 용량 × 보관 시간으로 계산합니다.
- DAS/NAS/SAN/Scale-out NAS는 공유 여부, 성능, 비용이 다르며 편집기 요구사항을 확인해야 합니다.
- RAID는 디스크 장애 보호일 뿐 백업이 아니며, 원본·프록시 경로 분리와 계층 구성(온라인·니어라인·오프라인)이 핵심입니다.