HCI, 서버·스토리지·네트워크를 한 어플라이언스에 눌러 담는 법
하이퍼컨버지드 인프라(HCI)의 SDS·Scale-Out 구조, NAS/SAN 대비 절충점, VM I/O 경로, 도입 트레이드오프를 정리한다
2026-08-13 · 최초 발행 2025-12-03
과거의 정석은 파일 서비스는 NAS로, 고성능 블록 워크로드는 SAN으로 나누는 것이었다. 문제는 두 체계를 같이 운영하면 관리 창구가 둘로 늘고, 각자 스케일업 한계와 패브릭 복잡도라는 짐을 따로 짊어져야 한다는 점이다. 하이퍼컨버지드 인프라(HCI, Hyper-Converged Infrastructure)는 이 두 세계를 표준 x86 서버 위에 소프트웨어로 얹어 하나의 어플라이언스로 합쳐버리는 접근이다.
NAS와 SAN 사이, 세 번째 선택지
HCI는 표준 x86 하드웨어 위에 가상화(또는 컨테이너), 소프트웨어 정의 스토리지(SDS), 가상 네트워킹을 통합한 아키텍처다. 노드 기반 클러스터로 구성되고 단일 관리면과 정책 기반 자동화를 제공한다는 게 핵심이다. 대부분 벤더가 검증한 HW+SW 스택을 패키징해서 내놓기 때문에 성능·장애 대응·라이프사이클 관리가 일관되고, 펌웨어·드라이버·하이퍼바이저·SDS 업데이트도 통합해서 나온다.
내부적으로는 분산 블록·오브젝트 저장소로 동작하면서 외부로는 NFS/SMB/iSCSI 같은 표준 프로토콜 게이트웨이를 노출한다. 그 결과 파일 공유의 편의성과 블록 스토리지의 일관성·성능을 함께 얻는, NAS-SAN 절충안이 된다. 여기에 노드를 추가하면 용량·IOPS·대역폭이 선형으로 늘고(Scale-Out), 노드를 제거할 때는 데이터를 다른 노드로 옮긴(이베큐에이션) 뒤 서비스 중단 없이 축소한다(Scale-In). 이 과정을 리밸런싱·쿼럼·장애 도메인 인식 기반의 자가 치유 메커니즘이 받쳐준다.
어플라이언스 하나에 무엇이 들어있나
SDS 계층은 로그 구조 쓰기, 캐시/캐패시티 티어 분리, 메타데이터 분리 설계를 쓰고, 워크로드에 맞춰 중복제거·압축·암호화·스냅샷·클론 정책을 건다. 내구성은 복제(RF2/RF3 같은 방식)나 이레이저 코딩(EC)으로 확보하는데, 어느 쪽을 쓰느냐가 내구성과 오버헤드의 트레이드오프를 가른다.
Scale-Out/Scale-In 메커니즘은 노드·디스크를 추가하면 자동으로 디스커버리하고 리밸런싱하되 재구성 중에도 서비스는 계속 돈다. 제거할 때는 용량·내구성 제약을 먼저 검증하고 데이터 이주가 끝난 뒤 디커미션한다. 소규모 클러스터에서는 EC 대신 복제가 권장되는 이유도 여기 있다 — 이레이저 코딩은 어느 정도 노드 수와 네트워크 여유가 있어야 이득이 난다.
네트워킹은 East-West 트래픽 최적화가 핵심이라 25/100GbE, MTU 9000, DCB/RDMA 옵션으로 레이턴시를 줄인다. 데이터 보호는 동기·비동기 복제, 스냅샷 스케줄, 원격 사이트 DR, 정책 기반 QoS·암호화로 구성된다. 운영 측면에서는 정책 기반 프로비저닝과 Ansible·Terraform·CSI 같은 API·플러그인 연동이 기본이고, 헬스 체크·용량 예측·슬로우 디스크 탐지·지능형 리밸런싱이 원클릭 패치·롤링 업그레이드와 맞물려 가용성을 유지한다. 하드웨어 쪽은 NVMe SSD 캐시, 고집적 HDD/QLC 용량 티어, NVDIMM/PMem으로 쓰기를 가속하고 필요하면 GPU/DPU를 선택적으로 얹어 CPU:메모리:디스크 비율을 워크로드에 맞춰 조정한다.
NAS vs SAN vs HCI 어플라이언스
| 특성 | NAS | SAN | HCI Appliance |
|---|---|---|---|
| 성능 | 파일 I/O 중심, 메타데이터 병목 가능 | 블록 I/O 고성능, 저지연 | 캐시+분산 병렬 I/O, 워크로드에 따라 선형 확장 |
| 확장성 | 스케일업 위주, 헤드 노드 한계 | 포트/컨트롤러 스케일업 | 노드 단위 스케일아웃, Scale-In 지원 |
| 일관성 | 파일락 기반, 애플리케이션 영향 | 강한 일관성(블록) | 정책 기반 강/최종 일관성 선택 |
| 안정성 | 듀얼 컨트롤러 중심 | 이중화 컨트롤러/패브릭 | N노드 쿼럼·자체 치유, 장애 도메인 인식 |
| 운영 편의 | 프로토콜 단순, 기능 제한 | 구성 복잡, 패브릭 의존 | 단일 관리면, 자동화·LCM 강화 |
쓰기 요청 하나가 지나가는 길
여기서 눈여겨볼 지점은 쿼럼이 임계값 아래로 떨어지면 데이터를 쓰는 대신 I/O를 아예 멈추고 관리자에게 경보를 올린다는 것이다. 조용히 데이터를 잃는 대신 멈추는 쪽을 택한 설계다.
어디에 쓰이나
프라이빗 클라우드·가상화 플랫폼에서는 vSphere·KVM 기반 VM 인프라를 통합하면서 정책 기반 스토리지로 SLA를 분리하고 멀티테넌시 격리와 자원 예약을 구현한다. ROBO(지사·소규모 사무소)나 엣지에서는 2~3노드짜리 소형 클러스터로 지점 서버·스토리지를 통합하고 중앙에서 원격으로 라이프사이클을 관리한다. VDI/DaaS에서는 NVMe 캐시와 중복제거로 부팅 폭풍을 완화하고 프로필·경량 영구 디스크를 정책화한다. 컨테이너 스토리지에서는 CSI로 동적 볼륨을 프로비저닝하고 스냅샷·클론으로 CI/CD를 가속하는데, StatefulSet이나 데이터베이스 운영에 특히 맞는다. 백업·DR·멀티사이트에서는 비동기 복제로 원격을 보호하고 스냅샷 기반으로 빠르게 복구하며, 스트레치드 클러스터로 사이트 레벨 가용성을 확보한다.
도입 후 달라지는 것들
랙·배선·구성이 일체형으로 나오다 보니 구축 기간이 주 단위에서 일·시간 단위로 줄어든다. TCO는 서버·스토리지 통합과 고밀도 자원 활용 덕에 환경에 따라 2040% 절감 범위를 기대할 수 있고, 중복제거·압축으로 유효 용량이 3070% 늘어난다. NVMe 캐시와 병렬 I/O로 지연이 줄고 워크로드가 늘어도 선형으로 확장되며, 다중 노드 쿼럼과 자체 치유로 99.9x% 수준의 서비스 연속성을 노릴 수 있다. 단일 콘솔·정책 기반 관리로 운영 작업량이 줄고, 롤링 업그레이드로 서비스 중단도 최소화된다.
내구성·네트워크·장애 도메인에서 따져야 할 것들
내구성 정책은 소규모 클러스터라면 RF2/3을, EC는 노드 수와 네트워크 여유가 있을 때 고려한다. 복제는 용량 오버헤드가, EC는 CPU·네트워크 오버헤드가 든다는 트레이드오프를 먼저 계산해야 한다. 네트워크 설계는 스토리지 전용 VLAN, MTU 9000, 25/100GbE를 권장하고 필요하면 혼잡 제어(DCB)나 RDMA를 적용하며, 동서 트래픽을 가시화하고 대역폭 QoS를 걸어둔다.
장애 도메인·쿼럼 측면에서는 랙 인식 배치와 위트니스·타이브레이커 구성이 필요하고, 계획·비계획 장애 시 리밸런싱 윈도를 통제해야 한다. 데이터 보호·보안에서는 스냅샷 불변성, 격리 복제, 전송·휴지 암호화를 기본으로 깔고 랜섬웨어에 대비해 최소 권한·MFA·감사를 켜둔다. NAS/SAN과 연계할 때는 NFS/SMB/iSCSI 게이트웨이로 레거시 앱을 붙일 수 있지만 추가 홉만큼 지연이 늘어난다는 점을 고려해, 고성능 블록 워크로드는 직접 마운트로 분리하는 편이 낫다. 용량 계획은 캐시:용량 비율과 워킹셋 크기를 기준으로 설계하고, 노드형 라이선스·기능 번들을 비교하며 벤더 종속 리스크를 평가한다. Ceph 같은 오픈소스 스택과 상용 스택의 비용·운영성 비교도 이 단계에서 함께 따진다.