19. 클라우드 시대의 스토리지와 엔지니어의 생존 전략

  전통 스토리지 vs SDS:
  
  전통:
  [벤더 전용 HW + 벤더 전용 OS]
  → NetApp FAS/AFF, Dell PowerStore, Pure FlashArray
  → 벤더가 HW+SW를 함께 튜닝. 안정성 검증 완료.
  → 장비를 사면 벤더가 책임진다.
  
  SDS:
  [범용 x86 서버 + JBOD/로컬 디스크] + [스토리지 소프트웨어]
  → Ceph, MinIO, vSAN, StarWind, LINSTOR
  → HW와 SW가 분리. HW는 자유롭게 선택.
  → HW 장애는 서버 벤더, SW 장애는 SDS 벤더. 책임이 분리.

  SDS가 스토리지를 만드는 방법:
  
  [전통 스토리지]
  전용 컨트롤러 ── 전용 디스크 쉘프 ── RAID로 보호
  → 하나의 장비 안에서 완결
  
  [SDS — 분산 스토리지 방식 (Ceph, MinIO)]
  ┌─────────┐  ┌─────────┐  ┌─────────┐
  │ 노드 1  │  │ 노드 2  │  │ 노드 3  │
  │ x86 서버│  │ x86 서버│  │ x86 서버│
  │ 로컬SSD │  │ 로컬SSD │  │ 로컬SSD │
  └────┬────┘  └────┬────┘  └────┬────┘
       │            │            │
       └──── 네트워크로 연결 ────┘
       
  데이터를 여러 노드에 분산 저장 (복제 또는 Erasure Coding)
  노드 1개가 죽어도 다른 노드에서 데이터 제공
  → RAID 대신 "분산 복제"로 데이터를 보호
  
  [SDS — HCI 방식 (vSAN)]
  ┌─────────────────────┐
  │ ESXi 호스트 1       │
  │ [VM들] + [로컬 SSD] │──┐
  └─────────────────────┘  │
  ┌─────────────────────┐  │
  │ ESXi 호스트 2       │  ├── vSAN으로 풀링
  │ [VM들] + [로컬 SSD] │──┤
  └─────────────────────┘  │
  ┌─────────────────────┐  │
  │ ESXi 호스트 3       │  │
  │ [VM들] + [로컬 SSD] │──┘
  └─────────────────────┘
  
  컴퓨팅과 스토리지가 같은 서버에 있다 = HCI
  별도 SAN/NAS 장비가 필요 없다
  → 하지만 서버가 죽으면 컴퓨팅과 스토리지가 동시에 영향

  주요 SDS 비교:
  
  ┌──────────────┬──────────────────────────────────────────┐
  │ vSAN         │ VMware 전용 HCI.                         │
  │              │ ESXi 호스트의 로컬 디스크를 풀링해서     │
  │              │ 분산 데이터스토어를 만든다.               │
  │              │                                          │
  │              │ 장점: VMware 깊은 통합. 별도 SAN 불필요. │
  │              │       관리 포인트 감소 (서버=스토리지).  │
  │              │ 단점: VMware 필수. 라이선스 비쌈.        │
  │              │       Broadcom 인수 후 라이선스 불확실성.│
  │              │       서버 장애 시 컴퓨팅+스토리지 동시  │
  │              │       영향. 대규모 확장 시 네트워크 부하.│
  │              │       미션 크리티컬 DB에는 전통 올플래시  │
  │              │       대비 성능/안정성이 부족할 수 있다.  │
  ├──────────────┼──────────────────────────────────────────┤
  │ Ceph         │ 블록(RBD) + 파일(CephFS) + 오브젝트(RGW)│
  │              │ 통합 오픈소스 분산 스토리지.              │
  │              │ CRUSH 알고리즘으로 중앙 메타서버 없이    │
  │              │ 데이터 배치를 결정한다 (3편 참고).       │
  │              │                                          │
  │              │ 장점: 무료(오픈소스). 스케일아웃.        │
  │              │       K8s/OpenStack 에코시스템에서 표준급.│
  │              │ 단점: 운영 난이도 높다. 파라미터 수백 개.│
  │              │       리밸런싱 시 성능 급락 가능.        │
  │              │       소규모(노드 3~5대)에서 비효율.     │
  │              │       전문 인력 확보가 어렵다.           │
  │              │       장애 시 벤더 서포트가 불확실       │
  │              │       (Red Hat Ceph Storage 유료 버전은  │
  │              │        서포트 있음).                     │
  ├──────────────┼──────────────────────────────────────────┤
  │ MinIO        │ S3 호환 오브젝트 스토리지 (3편 참고).   │
  │              │ 장점: 경량. K8s 친화. 설치 간단.        │
  │              │ 단점: 블록/파일 미지원. 대규모 메타데이터│
  │              │       한계. 엔터프라이즈 기능은 유료.    │
  └──────────────┴──────────────────────────────────────────┘

  ┌──────────────────────────────────────────────────────┐
  │ 실패 패턴 1: "Ceph가 무료니까 도입하자"              │
  │   → 소프트웨어는 무료지만 운영 인력 비용은 무료가    │
  │     아니다. Ceph 전문가 인건비 > 벤더 유지보수비.    │
  │   → 3개월 운영하다가 "이거 누가 관리하지?" 상태.     │
  │                                                      │
  │ 실패 패턴 2: "vSAN으로 SAN 장비를 없애자"            │
  │   → VDI, 일반 VM에는 잘 됨. 그런데 Oracle RAC를     │
  │     vSAN 위에 올렸더니 성능이 안 나옴.               │
  │   → SDS가 "모든 워크로드를 커버한다"는 아니다.       │
  │                                                      │
  │ 실패 패턴 3: 하드웨어를 너무 싸게 샀다               │
  │   → SDS라서 범용 서버를 쓸 수 있지만, "아무 서버"를  │
  │     쓰면 안 된다. 디스크 컨트롤러, 네트워크 카드,    │
  │     NVMe 슬롯 수 등 SDS가 요구하는 HW 스펙이 있다.  │
  │   → HW 호환성 테스트를 안 하면 간헐적 장애.          │
  │                                                      │
  │ 교훈: SDS는 "싸게 할 수 있다"가 아니라               │
  │       "다르게 할 수 있다"로 접근해야 한다.            │
  └──────────────────────────────────────────────────────┘

  하이브리드 패턴 3가지:
  
  ┌──────────────────────────────────────────────────────────┐
  │ 패턴 1: 클라우드 티어링                                   │
  │                                                          │
  │ [온프레미스 올플래시] ──Cold 데이터──► [클라우드 S3]      │
  │                                                          │
  │ 자주 안 쓰는 데이터를 자동으로 클라우드로 이동.          │
  │ NetApp FabricPool, Dell CloudIQ 티어링.                  │
  │                                                          │
  │ 동작: 스토리지가 접근 빈도를 추적 → 일정 기간 안 쓰인   │
  │ 블록을 S3로 이동 → 다시 접근하면 자동으로 로컬로 복귀   │
  │                                                          │
  │ 장점: 온프레미스 용량 절약. 투명하게 동작 (호스트 모름). │
  │ 단점: Cold→Hot 복귀 시 첫 읽기 레이턴시 급증 (수백ms).  │
  │       클라우드 API 호출 비용. 네트워크 대역폭 필요.      │
  │       클라우드 장애 시 Cold 데이터 접근 불가.            │
  │                                                          │
  │ 적합: 대용량이지만 활성 데이터가 전체의 20~30%인 환경.   │
  ├──────────────────────────────────────────────────────────┤
  │ 패턴 2: 클라우드 백업/DR                                  │
  │                                                          │
  │ [온프레미스] ──백업/스냅샷──► [S3/Glacier/Azure Blob]    │
  │                                                          │
  │ 3-2-1 원칙의 "1 오프사이트"를 클라우드로 구현.           │
  │ NetApp SnapMirror to Cloud, Pure CloudSnap,              │
  │ Veeam Cloud Tier 등.                                     │
  │                                                          │
  │ 장점: 오프사이트 인프라(DR 사이트) 불필요. 비용 효율.    │
  │ 단점: 대량 복원 시 Egress 비용 + 시간.                   │
  │       50TB를 S3에서 다운로드하면? → 수일 + 수백만원.     │
  │       네트워크가 병목이면 RTO를 충족하기 어렵다.          │
  │                                                          │
  │ 적합: 오프사이트 백업. RPO > 1시간. 복원 빈도가 낮은 환경.│
  ├──────────────────────────────────────────────────────────┤
  │ 패턴 3: 클라우드 네이티브 + 온프레미스 병행               │
  │                                                          │
  │ 신규 서비스: 클라우드 (AWS EBS/S3)                       │
  │ 기존 미션 크리티컬: 온프레미스 유지                       │
  │                                                          │
  │ 장점: 워크로드별 최적 환경. 신규는 빠르게 프로비저닝.    │
  │ 단점: 두 환경 모두 운영. 기술 스택 이중화. 비용 관리 복잡.│
  │       온프레미스 ↔ 클라우드 간 데이터 이동이 필요하면    │
  │       네트워크/비용 부담.                                │
  └──────────────────────────────────────────────────────────┘

  AWS 블록 스토리지 (EBS) — 온프레미스 SAN과 비교:
  
  ┌──────────────────────────────────────────────────────────┐
  │ EBS gp3 (범용 SSD)                                       │
  │   기본: 3,000 IOPS, 125 MB/s. 추가 과금으로 올릴 수 있음.│
  │   최대: 16,000 IOPS, 1,000 MB/s.                        │
  │   온프레미스 대응: Tier 1~2 올플래시.                    │
  │                                                          │
  │ EBS io2 Block Express (고성능 SSD)                       │
  │   최대: 256,000 IOPS, 4,000 MB/s.                       │
  │   볼륨당 64TB. 99.999% 내구성.                          │
  │   온프레미스 대응: Tier 0 NVMe 올플래시.                 │
  │   단점: 비쌈. IOPS당 과금이라 고성능 = 고비용.           │
  │                                                          │
  │ gp3 vs io2 선택 기준:                                    │
  │ ┌──────────────────────────────────────────────────┐     │
  │ │ · 일반 앱/DB: gp3이면 충분. 3,000 IOPS + 필요시 │     │
  │ │   추가. 비용 효율적.                              │     │
  │ │ · 고성능 OLTP: io2. IOPS/Throughput 보장 필요.   │     │
  │ │ · 테스트/개발: gp3 기본값으로 충분.              │     │
  │ │ · "항상 io2 쓰면 되지 않나?" → 비용이 5~10배.   │     │
  │ └──────────────────────────────────────────────────┘     │
  │                                                          │
  │ EBS vs 온프레미스 SAN의 본질적 차이:                     │
  │ · EBS는 단일 AZ. 다른 AZ로 볼륨을 옮기려면 스냅샷 경유. │
  │ · 온프레미스 SAN은 이중화/페일오버가 장비 안에 내장.     │
  │ · EBS 스냅샷은 S3에 저장(리전 내). 오프사이트 복제는     │
  │   크로스 리전 스냅샷 복사로 해야 하고 비용이 추가.       │
  └──────────────────────────────────────────────────────────┘

  오브젝트 스토리지 — S3 티어별 비교:
  
  ┌────────────────┬──────────┬──────────┬──────────────────┐
  │ S3 티어        │ 저장 비용│ 읽기 비용│ 적합한 용도       │
  ├────────────────┼──────────┼──────────┼──────────────────┤
  │ Standard       │ 높음     │ 낮음     │ 자주 접근하는 데이터│
  ├────────────────┼──────────┼──────────┼──────────────────┤
  │ IA (Infrequent │ 중간     │ 중간     │ 월 1회 정도 접근  │
  │ Access)        │          │          │                  │
  ├────────────────┼──────────┼──────────┼──────────────────┤
  │ Glacier        │ 낮음     │ 높음     │ 아카이브 (연 1~2회│
  │ Flexible       │          │ +시간    │ 접근)             │
  │ Retrieval      │          │ 수시간   │                  │
  ├────────────────┼──────────┼──────────┼──────────────────┤
  │ Glacier Deep   │ 최저     │ 최고     │ 컴플라이언스 장기 │
  │ Archive        │          │ +12~48시간│ 보관 (거의 안 읽음)│
  └────────────────┴──────────┴──────────┴──────────────────┘
  
  티어를 잘못 선택하면?
  · 자주 읽는 데이터를 Glacier에 넣으면 → 읽기 비용 폭발.
  · 안 읽는 데이터를 Standard에 넣으면 → 저장 비용 낭비.
  · S3 Intelligent-Tiering을 쓰면 자동으로 최적화하지만,
    모니터링 비용이 추가된다. 데이터 양이 적으면 오히려 비쌈.

  클라우드 스토리지 비용 계산 예시:
  
  온프레미스 100TB vs 클라우드 100TB (5년 기준, 대략적 비교):
  
  [온프레미스]
  · 올플래시 장비 도입: ~3억원
  · 유지보수 5년: ~1.5억원
  · 전력/랙: ~0.3억원
  · 합계: ~4.8억원 (TB당 월 ~80만원)
  
  [클라우드 — AWS S3 Standard]
  · 100TB × $0.023/GB/월 = ~$2,300/월 ≈ 300만원/월
  · 5년: ~1.8억원
  · + Egress 비용, API 호출 비용
  → 저장만 하면 클라우드가 싸다.
  
  [클라우드 — AWS EBS gp3]
  · 100TB × $0.08/GB/월 = ~$8,000/월 ≈ 1,000만원/월
  · 5년: ~6억원
  · + 스냅샷 비용, IOPS 추가 비용
  → 블록 스토리지는 클라우드가 더 비쌀 수 있다!
  
  ┌──────────────────────────────────────────────────────┐
  │ 결론: "클라우드가 싸다"는 워크로드에 따라 다르다.     │
  │                                                      │
  │ 클라우드가 유리: 소규모, 가변적, 단기, 오브젝트 위주 │
  │ 온프레미스 유리: 대용량, 일정한 사용량, 블록 위주,   │
  │                  장기 보관, 데이터 주권 이슈           │
  │                                                      │
  │ 숫자를 직접 계산해봐야 한다.                          │
  │ 벤더의 "클라우드로 가면 비용 절감" 마케팅만 믿으면    │
  │ 안 된다. Egress, 스냅샷, IOPS 추가 비용을 다 넣고     │
  │ 5년 TCO로 비교해야 한다.                              │
  └──────────────────────────────────────────────────────┘

  SCSI vs NVMe 프로토콜 비교:
  
  ┌──────────────┬──────────────────┬──────────────────────┐
  │              │ SCSI (FC/iSCSI)  │ NVMe                 │
  ├──────────────┼──────────────────┼──────────────────────┤
  │ 설계 시기    │ 1986년 (HDD 시대)│ 2011년 (SSD 시대)    │
  ├──────────────┼──────────────────┼──────────────────────┤
  │ 큐 수        │ 1개              │ 65,535개             │
  ├──────────────┼──────────────────┼──────────────────────┤
  │ 큐당 깊이    │ 254              │ 65,536               │
  ├──────────────┼──────────────────┼──────────────────────┤
  │ 레이턴시     │ 높음 (프로토콜   │ 낮음 (SSD에 최적화)  │
  │              │ 오버헤드 큼)     │                      │
  ├──────────────┼──────────────────┼──────────────────────┤
  │ CPU 사용     │ 높음             │ 낮음 (효율적)        │
  └──────────────┴──────────────────┴──────────────────────┘
  
  NVMe-oF(NVMe over Fabrics)란:
  
  로컬 NVMe의 성능을 네트워크로 확장하는 것.
  
  [로컬 NVMe]
  서버 ──PCIe──► NVMe SSD (직접 연결)
  → 가장 빠르지만 스토리지 공유 불가
  
  [NVMe-oF]
  서버 ──네트워크──► NVMe 스토리지 (원격 연결)
  → 원격이지만 SCSI보다 훨씬 빠름
  
  NVMe-oF 전송 방식:
  ┌──────────────┬──────────────────────────────────────────┐
  │ FC-NVMe      │ 기존 FC Fabric 위에서 NVMe 프로토콜.    │
  │              │ 장점: 기존 FC 인프라 활용 가능.          │
  │              │ 단점: FC Switch 펌웨어 업데이트 필요.    │
  │              │       호스트 HBA도 NVMe 지원 필요.      │
  ├──────────────┼──────────────────────────────────────────┤
  │ NVMe/TCP     │ 일반 이더넷(TCP/IP) 위에서 NVMe.        │
  │              │ 장점: 기존 이더넷 인프라 사용 가능.      │
  │              │       iSCSI 대체로 유력.                 │
  │              │       FC Switch 불필요 → 비용 절감.     │
  │              │ 단점: TCP 오버헤드가 있어서 FC-NVMe보다  │
  │              │       레이턴시가 약간 높다.              │
  │              │       25GbE+ 네트워크 권장.              │
  ├──────────────┼──────────────────────────────────────────┤
  │ NVMe/RoCE    │ RDMA over Converged Ethernet.            │
  │              │ 장점: TCP보다 레이턴시 낮음.             │
  │              │ 단점: Lossless 네트워크(DCB/PFC) 필요.  │
  │              │       네트워크 설계가 복잡.              │
  └──────────────┴──────────────────────────────────────────┘
  
  벤더별 NVMe-oF 지원:
  · NetApp: AFF A-Series에서 FC-NVMe, NVMe/TCP 지원
  · Dell: PowerStore에서 NVMe/FC 지원
  · Pure: FlashArray에서 NVMe-oF 지원 (NVMe/RoCE, FC-NVMe)
  
  현실: NVMe/TCP가 iSCSI의 후계자로 가장 유력하다.
  기존 이더넷 위에서 돌아가면서 SCSI보다 성능이 좋으니까.
  다만 아직 "모든 환경에서 바로 전환"하기엔 호스트/스토리지/
  네트워크 전체가 NVMe-oF를 지원해야 해서 전환이 점진적이다.

  ┌──────────────────────────────────────────────────────────┐
  │ CXL (Compute Express Link)                               │
  │   CPU와 메모리/스토리지 사이의 새로운 인터커넥트.        │
  │   대용량 메모리 풀을 여러 서버가 공유하는 구조 가능.     │
  │   메모리와 스토리지의 경계가 흐려진다.                   │
  │   현실: 스펙은 나왔지만 엔터프라이즈 적용은 2~3년 뒤.   │
  │   스토리지 엔지니어에게: "초저지연 티어"가 하나 더       │
  │   생길 수 있다는 정도로 인지해두면 됨.                   │
  ├──────────────────────────────────────────────────────────┤
  │ QLC / PLC NAND                                           │
  │   QLC(4비트/셀), PLC(5비트/셀). 용량↑ 내구성↓ 성능↓.   │
  │   HDD를 대체하는 포지션. TLC를 대체하는 게 아니다.       │
  │   7-1편 Tier 2에 해당. 읽기 중심 대용량 워크로드에 적합. │
  │   쓰기 집중 워크로드에는 여전히 TLC/SLC 캐시가 필요.    │
  ├──────────────────────────────────────────────────────────┤
  │ AIOps                                                    │
  │   AI/ML로 이상 탐지, 용량 예측, 성능 최적화 추천.        │
  │   벤더별: NetApp Active IQ, Pure1 ML, HPE InfoSight.     │
  │   현실: "자동 최적화"까지는 아직 멀고,                   │
  │   "이상 감지 → 알림 → 사람이 판단"이 현재 수준.         │
  │   유용하지만 사람을 대체하지는 못한다.                   │
  │   "AI가 추천한 걸 검증 없이 적용"하면 사고 날 수 있다.  │
  └──────────────────────────────────────────────────────────┘

  "스토리지만 아는 엔지니어"에서
  "인프라 전체를 보는 엔지니어"로.
  
  ┌──────────────────────────────────────────────────────┐
  │ 과거: 스토리지만 잘 하면 됐다.                        │
  │   FC Zoning 치고, 볼륨 만들고, 장애 대응하고.        │
  │                                                      │
  │ 현재: 스토리지 + α가 필요하다.                       │
  │   · 가상화 (VMware, K8s) — 7-1편에서 다룬 이유      │
  │   · 네트워크 (FC, iSCSI, NFS) — 4편 깊이 필요       │
  │   · 자동화 (Ansible, Terraform) — 18편               │
  │   · 클라우드 (AWS/Azure 스토리지 서비스) — 이번 편   │
  │   · 보안 (랜섬웨어 대응) — 14편                      │
  │                                                      │
  │ 왜? 인프라가 융합되고 있으니까.                       │
  │ · K8s 환경에서 CSI 드라이버를 설정하려면 K8s를 알아야│
  │ · 하이브리드 클라우드에서 FabricPool을 쓰려면         │
  │   클라우드 비용 구조를 알아야                         │
  │ · 랜섬웨어 대응을 하려면 네트워크 격리를 알아야       │
  │ · 이 모든 걸 수작업으로 하려면 자동화를 알아야        │
  │                                                      │
  │ 스토리지 지식이 기반이다. 그 위에 확장하는 거다.      │
  │ "IOPS가 뭔지 모르는데 EBS io2를 최적화"하는 건       │
  │ 불가능하다.                                          │
  └──────────────────────────────────────────────────────┘

  학습 로드맵:
  
  [기반] 이 시리즈 (1~19편)
    │
    ├── [깊이] 벤더 공식 교육/자격증
    │   NetApp NCDA/NCSIE, Dell DCS-IE,
    │   Pure Certified, 벤더 무료 온라인 교육
    │
    ├── [확장] 인접 기술
    │   Linux: RHCSA → RHCE
    │   가상화: VCP (VMware)
    │   K8s: CKA
    │   클라우드: AWS SAA / Azure Administrator
    │
    ├── [자동화]
    │   Python (API 호출, 스크립트)
    │   Ansible / Terraform (18편)
    │
    └── [소프트 스킬]
        문서화 (18편), RCA 작성 (15편),
        벤더/서버팀/경영진 커뮤니케이션
  
  전부 다 할 필요는 없다. 자기 환경에 맞는 걸 선택한다.
  NetApp 환경이면 NCDA + Ansible이 우선이고,
  클라우드 전환 중이면 AWS SAA + Terraform이 우선이다.

  시리즈 전체 구조:
  
  [기초] 1~5편
   스토리지가 뭔지, 어떤 종류가 있고, 프로토콜은 뭐고,
   데이터를 어떻게 보호하는지.
  
  [라이프사이클] 6~17편
   도입 → 설계 → 구축 → 인수시험 → 운영 → 효율화 →
   백업 → 보안 → 장애 → 유지보수 → 마이그레이션/폐기.
   그리고 신규 장비로 다시 설계부터 시작.
  
  [미래] 18~19편
   자동화와 문서화로 운영을 효율화하고,
   클라우드/SDS/NVMe-oF로 기술이 어디로 가는지.