7-2. 설계 — 데이터 편 (LUN 배치, 스냅샷, DR)
스토리지 설계의 데이터 편. LUN 분리 장단점, 네이밍 컨벤션, 스냅샷 동작 원리와 리스크, DR 동기/비동기 복제 트레이드오프, Active-Active 메트로 클러스터의 Split-Brain 리스크까지. 인프라 위에 데이터를 배치하고 보호하는 설계의 후반부.
7-1편에서 인프라의 뼈대를 잡았다. 네트워크 이중화로 경로를 확보하고, 플랫폼 환경(VM/K8s/베어메탈)에 맞는 프로토콜을 결정하고, Tier로 성능 등급을 나눴다.
이번 편에서는 그 기반 위에 데이터를 올린다. 볼륨을 어떻게 쪼개서 배치할 것인가(④), 이름을 어떻게 붙일 것인가(⑤), 스냅샷으로 어떻게 시점 복구를 준비할 것인가(⑥), 사이트가 날아가면 어떻게 복구할 것인가(⑦). "데이터를 어떻게 배치하고 보호할 것인가"를 결정하는 설계의 후반부다.
LUN/볼륨 레이아웃 — 쪼갤 것인가 합칠 것인가
DB 서버에 스토리지를 줄 때, LUN 하나에 다 넣을 건지 여러 개로 나눌 건지. 이건 성능, 관리 편의, 데이터 보호 관점에서 판단한다.
데이터베이스 워크로드 LUN 분리 예시:
┌──────────────────────────────────────────────────┐
│ DB 서버 │
│ │
│ /data ←── LUN 001 (500GB, Tier 0) │
│ 데이터 파일. 랜덤 IO 집중 │
│ │
│ /log ←── LUN 002 (100GB, Tier 0) │
│ 리두 로그. 순차 쓰기 집중 │
│ 데이터와 분리해야 IO 경합 방지 │
│ │
│ /temp ←── LUN 003 (200GB, Tier 1) │
│ 임시 공간. 중요도 낮음 │
│ │
│ /backup ←── LUN 004 (1TB, Tier 2) │
│ 로컬 백업. 용량 위주 │
└──────────────────────────────────────────────────┘분리의 장점과 단점:
┌──────────────────────────────────────────────────────────┐
│ LUN 분리 vs 통합 비교 │
├────────────────┬─────────────────┬────────────────────────┤
│ │ LUN 분리 (여러개)│ LUN 통합 (큰 1개) │
├────────────────┼─────────────────┼────────────────────────┤
│ IO 경합 │ 용도별 격리 가능│ 데이터+로그+백업이 │
│ │ → 로그가 데이터 │ 한 LUN에서 경쟁 │
│ │ IO에 영향 안줌│ │
├────────────────┼─────────────────┼────────────────────────┤
│ 스냅샷 │ 데이터만 따로 │ 전체를 한꺼번에 │
│ │ 스냅샷 가능 │ → 스냅샷 크기 증가 │
│ │ │ → 복원 시간 증가 │
├────────────────┼─────────────────┼────────────────────────┤
│ 성능 모니터링 │ "데이터가 느린지│ "이 LUN이 느린데 │
│ │ 로그가 느린지" │ 뭐가 원인인지" 구분 │
│ │ 즉시 구분 │ 어려움 │
├────────────────┼─────────────────┼────────────────────────┤
│ 관리 복잡도 │ LUN이 많아짐 │ 단순 │
│ │ Zoning, Masking │ │
│ │ 관리 포인트 증가│ │
├────────────────┼─────────────────┼────────────────────────┤
│ 장애 영향 │ LUN 하나 문제시 │ 하나 문제면 전부 │
│ │ 해당 용도만 영향│ 영향 │
├────────────────┼─────────────────┼────────────────────────┤
│ 권장 │ 미션 크리티컬 DB│ 개발/테스트 환경 │
│ │ 성능 민감 워크로드│ 단순 파일 서버 │
└────────────────┴─────────────────┴────────────────────────┘올플래시 스토리지에서는 물리적 디스크 레벨의 IO 경합이 HDD 시대보다 훨씬 적기 때문에, "무조건 쪼개야 한다"는 건 아니다. 하지만 스냅샷 단위, 모니터링 단위, 장애 영향 범위 관점에서 여전히 분리가 유리한 경우가 많다.
네이밍 컨벤션 — 나중의 나를 위한 투자
볼륨이 10개일 때는 이름이 대충이어도 된다. 300개가 되면 지옥이다.
나쁜 예:
vol1, vol2, test_new, backup_old, db_temp_2, prod_final_v3
→ 6개월 후 이게 뭔지 아무도 모른다. 만든 사람도 모른다.
좋은 예:
{환경}_{서비스}_{용도}_{번호}
볼륨:
prd_erp_data_001 운영 ERP DB 데이터 볼륨 1
prd_erp_log_001 운영 ERP DB 로그 볼륨 1
dev_crm_data_001 개발 CRM 데이터 볼륨 1
호스트 그룹:
hg_prd_erp_db01 운영 ERP DB 서버 1
Zoning Alias:
srv_prd_erp_db01_hba0 서버 (환경_서비스_호스트_포트)
stg_netapp01_0a 스토리지 (장비_포트)
규칙:
┌──────────────────────────────────────────────────────┐
│ · 영문 소문자 + 숫자 + 언더스코어만 │
│ · 환경(prd/stg/dev) → 서비스명 → 용도 → 일련번호 │
│ · 팀 전체 합의 + 문서화. 예외 없음. │
│ · "한번만 대충" → 영원히 대충이 된다 │
└──────────────────────────────────────────────────────┘스냅샷 정책 설계 — 보험이자 리스크
스냅샷은 "특정 시점의 데이터 상태를 보존"하는 기술이다. 실수로 데이터를 삭제했을 때, 랜섬웨어에 감염됐을 때 복구할 수 있는 보험이다.
스냅샷 정책 예시 (서비스 등급별):
┌───────────────────────────────────────────────────────┐
│ 등급 │ 스냅샷 주기 │ 보관 │ 용량예약 │
├────────────┼────────────────┼──────────────┼──────────┤
│ Gold (DB) │ 매 1시간 │ 24시간분 │ 20~30% │
│ │ + 매일 1회 │ + 7일분 │ │
│ │ + 매주 1회 │ + 4주분 │ │
├────────────┼────────────────┼──────────────┼──────────┤
│ Silver │ 매 4시간 │ 24시간분 │ 15~20% │
│ (일반 앱) │ + 매일 1회 │ + 7일분 │ │
├────────────┼────────────────┼──────────────┼──────────┤
│ Bronze │ 매일 1회 │ 7일분 │ 10~15% │
│ (파일서버) │ │ │ │
└────────────┴────────────────┴──────────────┴──────────┘스냅샷의 동작 원리를 이해해야 리스크를 알 수 있다.
스냅샷 동작 (Copy-on-Write):
[원본 데이터] 블록 A 블록 B 블록 C 블록 D
│ │ │ │
[스냅샷 시점] ─┴───────┴───────┴───────┴─── 포인터 저장
이후 블록 B가 수정되면:
1. 기존 블록 B를 스냅샷 영역으로 복사
2. 원본 위치에 새 블록 B' 기록
→ 변경된 블록만 보관. 초기에는 공간을 거의 안 씀.
→ 변경이 많을수록 스냅샷 공간이 커진다.스냅샷의 장점과 단점/리스크:
┌──────────────────────────────────────────────────────────┐
│ 장점 │
│ · 즉시 생성 (수초). 서비스 영향 없음 │
│ · 즉시 복원 가능. 테라바이트 볼륨도 수 분이면 복원 │
│ · 공간 효율적 (변경된 블록만 저장) │
├──────────────────────────────────────────────────────────┤
│ 단점 / 리스크 │
│ · 스냅샷은 백업이 아니다. 원본과 같은 스토리지에 있기 │
│ 때문에, 스토리지 자체가 죽으면 스냅샷도 같이 사라진다. │
│ · 스냅샷이 수십 개 이상 쌓이면 쓰기 성능 저하 │
│ · 스냅샷 공간 부족 → 볼륨 오프라인 가능 (서비스 중단!) │
│ · 일부 벤더: 볼륨 삭제 시 스냅샷도 같이 삭제 │
│ · 물리적 재해(화재, 지진)는 못 막음 → DR 복제 병행 필수 │
└──────────────────────────────────────────────────────────┘DR 구성 — 동기 vs 비동기, 그리고 현실
DR(Disaster Recovery)은 사이트 전체가 날아갔을 때 복구하는 체계다.
동기 복제 (Synchronous):
[사이트A] [사이트B (DR)]
스토리지 ───── 쓰기 ────────────► 스토리지
완료 확인 ◄──────────
양쪽 모두 기록 완료되어야 호스트에 응답.
장점: RPO = 0 (데이터 유실 제로)
단점:
· 쓰기 레이턴시 증가 (원격 왕복 시간 추가, 1~3ms)
· 원격 사이트 장애 시 운영 사이트 쓰기도 멈출 수 있음!
→ 타임아웃 후 자동 비동기 전환 기능 확인 필수
· 대역폭 비용: 쓰기량만큼의 전용 대역폭 필요
· 거리 제한: 보통 100km 이내
비동기 복제 (Asynchronous):
[사이트A] [사이트B (DR)]
스토리지 ───── 쓰기 완료 ──────►
(바로 호스트에 응답)
···나중에···
────── 복제 ────────► 스토리지
장점: 쓰기 성능 영향 없음, 거리 제한 없음
단점:
· RPO > 0 — 마지막 복제 이후 데이터 유실 가능
· 네트워크 부족 시 복제 지연(Lag) 누적 → RPO 초과
· DR 전환 시 미복제 데이터 유실 감수 RPO 요구사항 → 복제 방식 매핑:
┌──────────────┬──────────────────┬──────────┬─────────┐
│ RPO 요구 │ 복제 방식 │ 비용 │ 복잡도 │
├──────────────┼──────────────────┼──────────┼─────────┤
│ RPO = 0 │ 동기 복제 │ 높음 │ 높음 │
│ │ + 메트로 클러스터│ │ │
├──────────────┼──────────────────┼──────────┼─────────┤
│ RPO < 15분 │ 빈번한 비동기 │ 중~높 │ 중간 │
├──────────────┼──────────────────┼──────────┼─────────┤
│ RPO < 1시간 │ 비동기 복제 │ 중간 │ 낮음 │
├──────────────┼──────────────────┼──────────┼─────────┤
│ RPO < 24시간 │ 일 1회 백업 복제 │ 낮음 │ 낮음 │
└──────────────┴──────────────────┴──────────┴─────────┘DR 구성 방식도 장단점이 분명하다.
Active-Passive (가장 흔함):
[사이트A] ════복제════► [사이트B]
운영 중 대기
· 장점: 단순, 데이터 충돌 없음
· 단점: DR 사이트 자원이 평소에 놀고 있음 (비용 낭비)
Active-Active (메트로 클러스터):
[사이트A] ◄══양방향══► [사이트B]
운영 중 운영 중
· 장점: 양쪽 모두 활용, RTO 극소화
· 단점: 매우 복잡, 동기 복제 필수, Split-Brain 리스크
→ Quorum/Tiebreaker 3번째 사이트 필요
3-사이트:
[사이트A] ──동기──► [사이트B]
└──비동기──────► [사이트C (원격)]
· A,B 동시 피해 시에도 C에서 복구 가능
· 단점: 장비×3, 비용 최고, 운영 복잡도 최고DR에서 가장 많이 하는 실수는 "DR 전환 훈련을 안 하는 것"이다. 복제는 잘 되는데, 실제로 DR 사이트에서 서비스를 올려본 적이 없는 경우가 많다. 년 1~2회 DR 전환 훈련을 하지 않으면, 진짜 재해가 왔을 때 "이거 어떻게 전환하더라?"가 된다.
설계 문서 체크리스트
┌──────────────────────────────────────────────────────────┐
│ 스토리지 설계 문서 필수 항목 │
├──────────────────────────────────────────────────────────┤
│ □ 구성도 (물리/논리 토폴로지, 포트 연결 맵) │
│ □ 용량 설계 (RAW→실효, Tier별, 3~5년 성장) │
│ □ 성능 설계 (워크로드 프로파일, IOPS/Latency 목표) │
│ □ 이중화 설계 (듀얼 Fabric/VLAN, 멀티패스, 장애 시나리오)│
│ □ 데이터 보호 (RAID, 스냅샷, 복제/DR, DR 전환 절차서) │
│ □ 네이밍 컨벤션 (볼륨, 호스트 그룹, Zoning Alias) │
│ □ 보안 (RBAC, 암호화, 관리 네트워크 격리) │
│ □ 운영 기준 (모니터링 임계치, 알림, 백업 연동, 변경 관리)│
└──────────────────────────────────────────────────────────┘설계는 "한 번 하고 끝"이 아니다. 운영하면서 변경되는 게 정상이다. 중요한 건 변경될 때마다 설계 문서를 업데이트하는 것이다. 현실과 다른 문서는 문서가 아니라 함정이다. 6개월마다 설계 문서와 실제 구성을 비교하는 감사를 하면, "문서에는 이중화인데 실제로는 아닌" 상황을 방지할 수 있다.
다음 편에서는 구축으로 들어간다. 물리 설치, 초기 설정, 호스트 연결, As-Built 문서화. 설계를 현실로 바꾸는 단계다.
이 글이 어떠셨나요?
관련 포스트
7-1. 설계 — 인프라 편 (이중화, 플랫폼, Tier)
스토리지 설계의 인프라 편. FC/iSCSI 네트워크 이중화와 장애 시나리오, VMware 데이터스토어 선택(VMFS/NFS/vVols)과 장애 리스크, K8s PV/PVC/CSI 설계, Tier 구조와 자동 티어링 리스크까지. 물리적 뼈대를 먼저 세우는 설계의 전반부.
2026. 05. 11. PM 10:00Infrastructure6. 도입 검토 — 요구사항 분석과 벤더 선정
스토리지 도입 시 워크로드 프로파일링 실패 사례, RAW vs 실효 용량과 리덕션 비율의 함정, 벤더 벤치마크 5가지 함정, PoC 진행법, TCO 숨은 비용, 벤더별 약점, CAPEX vs OPEX 비교, 유지보수 계약과 TPM 장단점까지. 장비를 사기 전에 알아야 할 모든 것.
2026. 05. 04. PM 10:00Infrastructure5. RAID와 데이터 보호 — 전통 RAID부터 이레이저 코딩까지
RAID 0/1/5/6/10의 동작 원리부터 대용량 디스크에서 RAID 5가 위험한 이유, 벤더별 독자 RAID 구현, 이레이저 코딩까지. 데이터를 지키는 기술의 본질을 현장 관점에서 정리한다.
2026. 04. 27. PM 10:00뉴스레터 구독
새 글이 올라오면 이메일로 알려드려요.