가상화와 클라우드 서비스 모델

1. 가상화의 목적

가상화는 하나의 물리 자원을 논리적으로 분리하거나 여러 물리 자원을 하나처럼 제공하는 기술이다.

물리 서버
CPU·메모리·디스크·NIC
         │
   Hypervisor
  ┌──────┼──────┐
  ▼      ▼      ▼
 VM1    VM2    VM3
 OS A   OS B   OS C

장점:

• 자원 이용률 향상
• 환경 격리
• 서버 통합
• 빠른 복제·이동·복구
• 서로 다른 운영체제 실행

비용:

• 가상화 오버헤드
• 관리 계층 증가
• 호스트 장애 영향
• 자원 과다할당과 경합
• 라이선스·운영 복잡성

2. 하이퍼바이저

Type 1
Hardware → Hypervisor → Guest OS

Type 2
Hardware → Host OS → Hypervisor App → Guest OS

실제 제품 구성은 다양하며, 호스트 OS의 존재 여부가 주요 구분 기준이다.

3. VM의 구성

VM에는 가상 CPU, 메모리, 디스크, 네트워크 장치와 게스트 OS가 있다.

VM
├─ vCPU
├─ vMemory
├─ Virtual Disk
├─ Virtual NIC
└─ Guest OS + Application

스냅샷은 특정 시점 상태를 빠르게 보존하지만 장기 백업을 자동 대체하지 않는다. 스냅샷 체인이 길어지면 성능·복구 복잡성이 커질 수 있다.

4. 클라우드 컴퓨팅의 핵심 특성

일반적인 핵심 특성:

• 필요할 때 셀프서비스로 자원 요청
• 네트워크를 통한 접근
• 공유 자원 풀
• 빠른 탄력적 확장·축소
• 사용량 측정과 과금·관리
• API·자동화를 통한 프로비저닝

수요 증가
   ↓
자동확장: 인스턴스 2 → 6
   ↓
수요 감소
   ↓
자동축소: 인스턴스 6 → 2

단순히 외부 데이터센터에 서버를 두는 것만으로 모든 클라우드 특성을 충족하는 것은 아니다.

5. 서비스 모델

             On-Prem   IaaS   PaaS   SaaS
Application   사용자   사용자 사용자 제공자
Data          사용자   사용자 사용자 공동관리
Runtime       사용자   사용자 제공자 제공자
Middleware    사용자   사용자 제공자 제공자
OS            사용자   사용자 제공자 제공자
Virtualization사용자   제공자 제공자 제공자
Hardware      사용자   제공자 제공자 제공자

서비스 모델이 올라갈수록 사용자의 운영 부담은 줄지만 제어 범위와 이식성, 공급자 의존을 고려해야 한다.

6. 배치모델

• Public Cloud: 다수 고객이 공급자 클라우드를 공유
• Private Cloud: 한 조직을 중심으로 제공
• Hybrid Cloud: 둘 이상의 환경을 연계
• Multi-Cloud: 여러 클라우드 공급자를 사용

Hybrid와 Multi-Cloud는 같은 개념이 아니다. 여러 공급자를 쓴다고 자동으로 통합·이식성이 확보되지는 않는다.

7. 공유책임 모델

클라우드 제공자:
물리시설·장비·기초 서비스 보호

고객:
계정·권한·데이터·응용 설정·보안 구성

서비스 모델에 따라 경계 이동

SaaS에서도 사용자의 계정 관리, 데이터 분류, 공유 설정, 단말 보안 책임이 남는다.

8. 가용영역과 지역

Region
├─ Availability Zone A
│   ├─ Data Center
│   └─ Data Center
└─ Availability Zone B
    ├─ Data Center
    └─ Data Center

동일 지역의 여러 가용영역에 분산하면 단일 시설 장애를 줄일 수 있다. 지역 간 DR은 더 큰 재해에 대응하지만 지연, 데이터 복제, 비용, 법적 위치를 고려해야 한다.

9. 탄력성·확장성·가용성

• 확장성: 부하 증가를 처리하도록 자원을 늘릴 수 있는 능력
• 탄력성: 수요에 따라 자원을 빠르게 늘리고 줄이는 능력
• 가용성: 필요한 시점에 서비스를 제공하는 능력

수직확장은 한 서버의 CPU·메모리를 늘리고, 수평확장은 서버 수를 늘린다.

Scale Up  : VM 4CPU → 16CPU
Scale Out : VM 2대 → 8대

상태를 서버 로컬에 강하게 보관하면 수평확장과 장애 전환이 어려워질 수 있다.

10. 비용 관리

비용 요소:

• 컴퓨팅 실행시간
• 저장 용량·요청
• 네트워크 전송
• 관리형 서비스 사용량
• 로그·모니터링
• 유휴 자원
• 예약·약정·라이선스
• 다중 지역 복제

태그·계정·프로젝트별 비용 수집
    ↓
예산·경보
    ↓
유휴·과대 자원 탐지
    ↓
크기 조정·스케줄·수명주기
    ↓
효과 검증

비용 절감만을 위해 가용성·보안·성능을 훼손하면 전체 위험과 TCO가 증가할 수 있다.

11. 클라우드 보안 기본

• 루트·관리자 계정 보호와 MFA
• 최소권한 IAM
• 공개 저장소·방화벽 설정 점검
• 데이터 암호화와 키 관리
• 비밀정보 분리
• 로그·감사 활성화
• 백업·지역 복구
• 이미지·의존성 취약점 관리
• 네트워크 분리와 egress 통제

가장 흔한 위험 중 하나는 서비스 자체의 결함보다 고객의 잘못된 설정일 수 있다.

12. 가상화 방식과 성능 경계

• Full virtualization: 게스트 OS 수정 없이 가상 하드웨어 제공
• Paravirtualization: 게스트가 hypercall 등으로 가상화 인식
• Hardware-assisted: CPU 가상화 확장을 활용
• Container: 호스트 커널을 공유하며 프로세스 격리

vCPU overcommit은 평균 사용률을 높이지만 동시 피크에서 ready time·steal이 증가한다. NUMA 경계를 넘는 메모리 접근과 noisy neighbor도 성능 변동 원인이 된다.

13. 클라우드 핵심 특성 판독

NIST의 대표 특성은 on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service다. 단순히 VM을 외부 데이터센터에 두었다고 모든 특성을 충족하는 것은 아니다.

IaaS: 사용자가 OS 이상 관리
PaaS: 사용자가 응용·데이터 중심 관리
SaaS: 사용자는 설정·사용·데이터 책임 중심

공유 책임은 서비스·제공자마다 달라지며 “클라우드 사업자가 보안을 모두 담당한다”는 설명은 틀리다.

14. 장애 도메인과 가용성

같은 region의 여러 AZ에 분산해도 region 전체 장애·공통 IAM·DNS·배포 오류에는 취약할 수 있다. 멀티리전은 RTO·RPO를 줄일 수 있지만 데이터 일관성, 비용, 운영 복잡성이 증가한다.

단일 AZ 장애 허용: 최소 2개 이상 AZ + 독립 경로·상태 복제

autoscaling은 평균 CPU만이 아니라 queue length, request rate, custom metric, scale-out warm-up과 scale-in 안정화 시간을 고려한다.

15. 비용 계산과 FinOps

월 비용 = 컴퓨트 시간 + 저장용량/IOPS + 네트워크 egress
        + 관리형 서비스 + 로그·백업 + 지원 비용

예약·약정 할인은 예측 가능한 기저 부하에 유리하지만 과도한 약정은 낭비다. 태그·계정·프로젝트별 할당, unit cost(예: 주문 1건당 비용), budget alert와 rightsizing으로 관리한다.

16. 설계 선택 체크리스트

1. 서비스 모델별 책임 경계를 확인한다.
2. 상태·데이터·비밀의 위치와 복구 방법을 표시한다.
3. AZ·region·공급자 장애의 독립성을 검증한다.
4. 성능·비용·잠금 효과를 함께 비교한다.
5. 관리 plane과 data plane 장애를 분리한다.

확인 문제

1. NIST 클라우드 특성 중 rapid elasticity는?
2. PaaS에서 사용자가 주로 관리하는 것은?
3. vCPU overcommit의 피크 위험은?
4. 멀티 AZ가 region 장애까지 자동 해결하는가?
5. unit cost의 예시는?