ADP 필기 2장 데이터 처리 프로세스

[1] ETL

1. ETL

• Extraction: 하나 또는 이상의 원천으로 부터 데이터 획득
• Transformation: 데이터 클렌징, 형식 변환, 표준화, 통합 또는 다수 어플리케이션에 내장되 비즈니스 룰 적용
• Load: 변형 단계 처리가 완료된 데이터를 특정 시스템에 적재
• 데이터의 이동 및 변환 절차와 관련된 업계 표준 용어
• ODS, DW, DM 등에 데이터를 적재하는 작업
• 대용량 처리를 위한 MPP를 지원
• Batch, REAL ETL로 구분

2. ETL 작업 단계

1. interface: 원천으로부터 데이터 획득하기 위한 매커니즘 구현
2. staging: 원천으로부터 데이터를 얻어 테이블에 저장
3. profiling: 데이터 특성을 식별하고 품질 측정
4. cleansing: 규칙을 통해 데이터 보정
5. integration: 데이터 충돌을 해소하고 클렌징 데이터 통합
6. denormalizing: 운영 보고서 및 DW, data mart 적재하기 위해 비정규화

3. ODS

• 데이터에 대한 추가작업을 위해 원천으로부터 데이터를 추출, 통합한 데이터베이스
• ODS 데이터는 향후 DW에 이관
• 실시간, 실시간 근접 트랜잭션 데이터 혹은 원자성을 가진 하위 수준 데이터를 저장하기 위해 설계

4. ODS 구성 단계

1. interface
   • 원천으로부터 데이터 획득하는 다계
   • OLEDB, ODBC, FTP등을 사용
   • 실시간, 실시간 근접 OLAP을 지원하기 위해 실시간 데이터 복제 인터페이스 기술 함께 활용
2. data staging
   • staging table에 저장되는 단계
   • 정규화가 배제되며 테이블 스키마는 원천에 의존적
   • 원천과 staging table은 1:1 or 1:N 관계
   • 적재 시점에 체크섬등의 컨트롤
3. profiling
   • 범위, 도메인, 유일성 등 규칙으로 데이터 품질 점검
   • 스테이징 테이블의 프로파일링 -> 프로파일링 결과 통계처리 -> 데이터 품질 보고서 생성
4. cleansing
   • 프로파일링 단계에서 식별된 오류 데이터들을 수정
   • 보고서, 클렌징 요건등 선행 자료 필요
5. integration
   • 수정 완료한 데이터를 ODS 내에 단일 통합 테이블에 적재
   • 클렌징 테이블, 데이터 충돌 요건 등의 선행자료 필요
6. 익스포트
   • 보안규칙들을 적용한 익스포트 테이블 생성
   • 익스포트 데이터는 OLAP 등의 비정형 질의에 사용됨

5. DW

• ods를 통해 정제 및 통합된 데이터가 분석과 보고서 생성을 위해 적재되는 데이터 저장소
• 주제 중심성: 업무에 맞춰 구조화 되기에 최종 사용자도 이해 가능
• 영속성, 비휘발성: 최초 저장 후 읽기 전용 및 삭제 불가
• 통합성: 모든 데이터들의 통합 공간
• 시계열성: 시간순에 의한 이력 보관

6. DW 테이블 모델링 기법

1. 스타 스키마
   • 조인 스키마, dw 스키마 중 가장 단순
   • 단일 사실 테이블 중심, 다수 차원 테이블로 구성
   • RDMS를 통해 기능 구현 가능
   • 사실 테이블은 제 3정규형 차원 테이블은 제 2정규형
   • 장점: 복잡도가 낮아 이해하기 쉬움, 쿼리 작성이 용이, 조인 테이블 개수가 적음
   • 단점: 차원 테이블 비정규화에 따른 데이터 중복으로 적재시 많은 시간 소요
2. 스노우 플레이크 스키마
   • 스타 스키마의 차원 테이블을 제 3정규형으로 정규화
   • 장점: 정규화로 데이터 중복이 제거되어 적재시 시간 단축
   • 단점: 스키마 구조의 복잡성이 증가하여 조인 테이블 개수 증가, 쿼리 난이도 상승

7. ODS vs DW

1. 데이터 내용
   • ODS: 현재, 비교적 최신 데이터
   • DW: 오래된 그리고 현재의 상세 데이터, 요약 데이터, 2차로 가공된 요약 데이터
2. 양
   • ODS: 소규모
   • DW: 대규모
3. 갱신
   • ODS: 지속적으로 갱신되어 현재의 DB 상태 반영
   • DW: 데이터 축적 보관
4. 기술적 요소
   • ODS: 데이터 베이스 처리의 모든 기능 사용
   • DW: 단순한 적재와 접근 중심

[2] CDC

1. CDC

• Change Data Capture: DB 내 Data 변경을 식별 및 후속처리(=데이터 전송/공유) 자동화
• 실시간, 실시간 근접 데이터 통합을 기반으로 하는 DW등에 사용 (ODS에도 사용)
• 스토리지 하드웨어 계층부터 애플리케이션 계층까지 다양한 계층에서 구현

2. CDC 구현 기법

• Time stamp on Rows: 타임 스탬프 컬럼
• Version Numbers on Rows: 타임 스탬프 보완, 버전 넘버 컬럼
• Status on Rows: Time Stamp 및 version에 대한 보완, 변경 여부를 boolean 관리
• Time/ Version/ Status on Rows: 모두 사용
• Trigger on Table: DB 트리거 활용, 복잡도 증가 및 확장성 감소
• Event Programming: 어플리케이션에 추가개발을 해야 하기에 부담
• Log Scanner on DB: 영향도 및 지연시간 최소화, DB 스키마 구좁 ㅕㄴ경 불필요

3. CDC 구현 방식

• 푸시 방식: 원천의 변경을 식별해 target에 적재
• 풀 방식: target이 원천을 보며 변경시 data 다운로드

[3] EAI

1. EAI 특징

1. 기존의 데이터 연계 방식: Point to point
   • 필요에 따라 데이터 연결 -> 복잡성 증가 및 표준화 불가능
   • N개 연결 대상 노드 -> N(N-1)/2
2. EAI 연계 방식: Hub and spoke
   • 시스템들의 데이터를 중앙 hub가 통합
   • 연결되는 노드들은 spoke가 됨

2. EAI 효과

• 정보시스템 개발 및 유지보수 비용 절감
• 기업 SI의 지속적 발전 기반
• 협력, 파트너, 고 객과 상호 협력
• 비즈니스 기본 토대
• 데이터 표준화 기반

3. EAI 구성 요소

• 어댑터: 시스템과 허브 간의 연결성 확보
• 버스: 어댑터로 연결된 시스템간의 데이터 연동 경로
• 브로커: 연동 규칙 통제
• 트랜스포머: 데이터 형식 변환

4. EAI 구현 유형

• Meditation: 시스템 변경을 식별하여 브로커 역할 수행 -> 자동
• Federation: 외부 정보 시스템으로 요청에 의해 수행 -> 수동

5. EAI vs ESB

1. 기능
   • EAI: 미들웨어를 이용, 비즈니스 로직 중심, 어플리케이션 통합, 연계
   • ESB: 미들웨어를 이용, 서비스 중심, 시스템을 유기적으로 연계
2. 통합 관점
   • EAI: 어플리케이션
   • ESB: 프로세스
3. 로직 연동
   • EAI: 개별 어플리케이션에서 수행
   • ESB: ESB에서 수행
4. 아키텍처
   • EAI: 단일 접점, 중앙집중 허브
   • ESB: 버스 형태, 느슨하고 유연

[4] 대용량 비정형 데이터 처리

대용량 데이터 수집을 위해 쉽게 확장할 수 있는 구조

1. 로그

• 기업에서 발생하는 비정형 데이터
• 아파치 Flum-NG, Chukwa, 페이스북 Scribe

2. 하둡

• 맵 리듀스 시스템과 분산파일 시스템인 HDFS를 핵심 구성 요소로 가지는 플랫폼 기술
• 비공유 분산 아키텍처

3. 하둡의 특징

1. 선형적인 성능과 용량 확장
   • 이론적으로 클러스터 구성의 제한이 없음 (최소는 통상 5대)
   • 비공유 분산 아키텍처 시스템 ~ 서버추가시 성능이 서버 대수에 비례
2. 고장 감내성
   • HDFS 저장 데이터는 3중복제
   • 맵리듀스 중 장애가 생기면 장애 발생 태스크만 다른 서버에서 재실행 가능
3. 핵심 비즈니스 로직에 집중
   • 맵과 리듀스 2개의 함수만 구현

4. 에코시스템

• zookeeper: 모니터링 및 관리, 서버들간 상호 조정 서비스 제공
• oozie: 하둡 작업을 관리하는 워크플로우 및 코디네이터 시스템
• hbase: HDFS 기반의 NoSQL
• pig: 복잡한 MapReduce 프로그래밍을 대체할 언어 제공
• hive: 하둡 기반의 DW, 테이블 단위 저장과 HiveQL 쿼리 지원
• mahout: 하둡 기반 데이터 마이닝 알고리즘 구현 오픈소스 라이브러리
• hcatalog: 하둡 기반의 테이블 및 스토리지 관리
• avro: RPC과 데이터 직렬화를 지원하는 프레임 워크
• chuka: 분산 환경에서 생성되는 데이터를 HDFS안에 안정적으로 저장시키는 플랫폼
• flume: 소스서버에 에이전트가 설치되고, 에이전트로부터 데이터를 전달받는 콜렉터로 구성
• scribe: 페이스북에서 개발된 데이터 수집 플랫폼, Chukwa와 달리 중앙집중서버로 전송
• sqoop: 대용량 데이터 전송 솔루션, RDBMS, HDFS, NoSQL, DW 등 다양한 저장소에 데이터 전송, RDMBS <-> HDFS 가능
• hiho: Sqoop과 같은 대용량 데이터 전송 솔루션, 하둡에서 데이터를 가져오기위한 sql 지정, JDBC 인터페이스 지원
• yarn: 맵리듀스 단점 극복을 위해 분산 애플리케이션을 구현하기 위한 자원관리 프레임워크 지원

5. 대용량 질의 기술

• 하둡을 사용하기 위해선 코딩이 필요함 -> 어려움
• Hive는 SQL을 이용해 하둡 데이터를 처리 분석 하는 기술 지원
• 하둡과 하이브는 대용량 데이터를 배치처리하는데 최적화

6. Sql on 하둡

실제 업무에서는 데이터를 실시간으로 조회하거나 처리해야 하는 요구사항이 많기에 이를 해결하기 위한 기술

• 아파치 드릴: 오픈소스 드레멜, 데이터 저장소의 공간 및 내부처리 용량 절약을 위해 데이터 구조 자동 재정렬
• 스팅거: 하이브의 성능 개선판
• 임팔라: 클러스터에 저장된 데이터를 위한 대규모 SQL 쿼리 엔진
• 호크
• 프레스토: 페이스북 개발 데이터웨어 하우징 엔진

2장 데이터 처리 기술

[1] 분산 파일 시스템

• 분산 데이터 저장 기술 종류
  • 분산 파일 시스템, 클러스터, 데이터베이스, NoSQL
• 분산된 많은 서버들로 구성된 대규모 클러스터 시스템 플랫폼 -> 대용량 저장공간, 빠른 처리 성능, 확장성, 신뢰성, 가용성 등 보장
• 비대칭형 클러스터 파일 시스템: 파일의 메타데이터를 관리하는 전용 서버를 가진 시스템
  • 메타데이터에 접근하는 경로와 실 데이터에 접근하는 경로가 분리되어 있음

2. GFS

• 파일을 고정된 크기의 청크로 나누고 여러개의 복제본을 분산, 저장
• 해시테이블 구조 -> 메모리상 효율적인 메타 데이터 처리 지원
• 가정
  • 저가형 서버의 구성으로 빈번한 고장
  • 대부분의 파일은 대용량
  • 작업 부하: 연속적으로 많은 데이터 / 임의의 영역에서 적은 데이터
  • 파일 쓰기 연산은 순차적, 갱신은 드물게
  • 여러 클라이언트가 동시에 파일을 수정시 동기화 오버헤드 최소화 방법 필요
  • 낮은 응답 지연시간 < 높은 처리율
• 구성요소
  • 클라이언트: 요청 애플리케이션, Posix(=이식가능 운영체제) 지원하지 않음
  • 마스터: 단일 마스터가 모든 메타데이터를 메모리상에서 관리, 청크 생성
  • 청크서버: 청크를 보관하며 클라이언트 요청에 응답

3. HDFS

• GFS의 사상을 구현함

• 하나의 네임노드(마스터)와 다수의 데이터노드(청크서버)

• 블록 or 청크 단위로 나뉘어 데이터 노드에 분산, 복제, 저장 (3중복제)

• 보조 네임노드는 HDFS 상태 모니터링을 보조, 주기적으로 네임노드 파일 이미지를 스냅샷

• 파일은 한번 쓰이면 변경되지 않음

• 순차적 스트리밍 방식으로 파일 저장 및 조회

• 배치 작업에 적합

• 클라이언트, 네임노드, 데이터노드 간의 통신을 위해 RPC 사용(TCP/IP)

• 저장과정

  1. 클라이언트는 저장할 파일을 64/ 128MB 단위의 블록으로 분리

  2. 네임노드는 블록 저장을 위한 데이터 노드 주소 목록을 클라이언트에게 전달 -> 클라이언트가 데이터 노드에 저장
  3. 데이터 노드에 3중 복제
  4. 클라이언트는 네임 노드에게 작업 완료 전달 -> 네임노드는 파일 메타 데이터 저장

• 읽기 과정

  1. 클라이언트는 읽고자 하는 파일에 대한 정보를 네임노드에게 요청
  2. 네임노드는 파일에 대한 모든 블록의 목록과 블록이 저장된 데이터 노드 위치를 클라이언트에게 반환
  3. 클라이언트는 목록을 참조해 데이터 접근

4. 러스터

• 클러스터 파일 시스템
• 클라이언트 파일시스템, 메타데이터서버, 객체저장 서버로 구성
• 계층화된 모듈 구조
• 유닉스 시멘틱 제공, 파일 메타데이터에 대해 라이트백 캐시 지원
• 클라이언트에서 메타 데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달
• 파일의 메타 데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금 사용
• 인텐트 기반 잠금 프로토콜 사용

[2] 데이터베이스 클러스터

• 데이터 오합시 성능과 가용성 향상을 위해 파티셔닝 또는 클러스터링 이용
• 클러스터링: 하나의 데이터 베이스를 여러개의 서버상에 구축하는 것
• 파티셔닝: 데이터베이스를 여러 부분으로 분할하는 것, 각 파티션은 노드로 분할 배치되어 트랜잭션 수행
• 파티셔닝 효과
  • 병렬처리 / 고가용성 / 성능향상(선형적)

1. 클러스터 구분

1. 무공유 디스크
   • 각 노드는 완전히 분리된 데이터의 서브집합에 대한 소유권을 가짐
   • Oracle RAC 제외 대부분 데이터베이스
   • 장점: 노드 확장에 제한이 없음
   • 단점: 장애시 이중화(폴트톨러런스) 필요
2. 공유 디스크
   • 노드들이 모든 데이터에 접근 가능
   • SAN(Storage Area Network) 필요
   • 모든 노드가 데이터 수정이 가능하기에 동기화 채널이 필요
   • 장점: 장애시에도 서비스 가능
   • 단점: 클러스터가 커지면 병목현상 발생

2. DB 클러스터 종류

1. Oracle RAC
   • 공유 클러스터
   • 클러스터의 노드는 모든 테이블에 동등하게 엑세스
   • 데이너튼 공유 스토리지에 저장 -> 노드가 데이터를 소유하지 않음
   • 장점
     • 가용성: 높은 수준의 폴트 톨러런스
     • 확장성: 새 노드를 클러스터에 추가하기 용이 (무공유의 장점)
     • 비용절감: 저가 CPU 사용, But 초기 도입 비용이 비쌈
2. Mysql
   • 비공유 클러스터
   • 메모리 기반 데이터 베이스의 클러스터링 지원
   • 병렬구조로 확장
   • 구성
     • 관리노드: 클러스터 관리, 클러스터 시작 및 재구성에 관여
     • 데이터노드: 데이터 저장
     • Mysql노드: 데이터 접근
   • 제한사항
     • 파티셔닝은 Linear Key 파티셔닝만 지원
     • 총 노드는 255로 제한하며 데이터 노드는 48개 제한
     • 트랜잭션 수행 중 롤백 지원 안함
     • 메모리 부족 문제로 인해 트랜잭션에 과도한 데이터 처리 불가능
     • 운영중에 노드를 추가/ 삭제 불가능
3. 기타
   • IBM DB2 ICE: 무공유 클러스터링
   • 마이크로소프트 SQL server: 연합 데이터베이스 형태, Active-stanby 방법

[3] Nosql

• 데이터의 폭발적인 증가에 대응하기 위해 분산 데이터베이스 기술로 확장성, 가용성, 높은 성능 제공
• 비관계형 데이터베이스 시스템 -> 스키마가 없이 자유롭게 데이터 추가
• SQL계열 쿼리를 사용할 수 있음 (Not only Sql)
• 종류
  • key-value, Document(JASON, XML), Graph, Column
• key와 value 형태로 자료를 저장 -> 빠르게 조회

1. 구글 빅테이블

• 공유디스크 방식
• 모든 노드가 데이터, 인덱스 파일을 공유
• 실시간 서비스 및 주기적인 배치, 데이터 분석처리에 적합
• hash map을 파티션하여 부산 저장하는 저장소
• row-key의 사전적 순서로 정렬
• row는 n개의 colum family를 가질 수 있음
• column family 안에 저장되는 형태는 column-key, value, timestamp
• 동일한 column key여도 time stamp가 다를 수 있음
• 정렬 기준은 row key + column key + time stamp
• 특정 노드에 장애 발생시 마스터가 서비스되던 tablet을 다른 노드로 재할당 -> SPOF는 마스터 노드
• Chubby를 통해 Master를 모니터링
• chubby는 절대 장애가 발생하지 않음
• Map Reduce 컴퓨팅 클러스터와 동일한 클러스터 위에 구성됨

2. HBase

• HDFS 기반, 컬럼기반 데이터 베이스
• 관계형 구조가 아니며 SQL을 지원하지 않음
• 비구조화된 데이터에 적합
• 대규모 데이터 실시간 일기, 쓰기 작업에 사용
• 노드 추가시 선형 확장 가능
• 클러스터를 통한 데이터의 복제 기능 제공
• RDBMS와 달리 수평적 확장성이 있어 큰 테이블에 적합
• 로우키에 대한 인덱싱 지원
• Zookeeper를 이용한 고갸용성

3. 아마존 SimpleDB

• web app에서 사용하는 데이터의 실시간 처리

• 복제본을 유지하여 가용성을 높임

• 트랜잭션 종료 후 즉시 반영이 아닌 지연 동기화(=eventual consistency)

• 한번에 한 domain에 대해 쿼리 수행 -> 1:N일시 여러번 수행

• client는 soap, rest를 통해 simple DB 이용

• RDB와의 관계

  • domain - table

  • item - record
  • attribute - column

4. MS SSDS

• RDB와 달리 관계 데이터를 1개의 컨테이너에 모두 적재함
• 데이터 모델
  • 컨테이너: RDB의 table, 1개의 컨테이너에 여러 종류의 엔티티 저장 가능
  • 엔티티: RDB의 record

[4] MapReduce

• 분산 병렬 컴퓨팅을 위한 소프트웨어
• 분할 정복 방식으로 데이터 병렬 처리
• C++, Java 언어로 적용
• client의 수행 단위는 Job
• Map은 Key-Value 쌍을 입력으로 받음
• 입력은 Map 함수를 거쳐 새로운 key-value로 변환되어 임시 저장
• 임시 파일은 shuffling과 group by 과정을 거쳐 reduce의 입력이 됨
• reduce의 입력도 key-value 쌍
• 사용자는 장애 이슈에 신경쓰지 않고 Map Reduce 함수만으로 대규모 병렬 연산 가능

2. MapReduce 실행 과정

• 사용자가 Map Reduce 함수 작성 -> 실행
• 파일이 split으로 나뉘며 각각 Map에 할당 -> split 만큼 map이 fork 됨
• Map을 거친 split은 로컬 파일 시스템에 저장 -> 중간 파일 데이터 사이즈에 따라 성능 결정
• 저장시 partitioner에 의해 어떤 reduce에 전달 될 것인지 정해짐
  • 만약 할당되지 않으면 key와 hash의 연산을 통해 지정 -> 같은 key = 같은 reduce
• reduce가 이를 처리해 최종 산출물을 얻음
  • 적합한 경우: 분산 grep, 빈도수 계산 작업
  • 부적합 경우: 정렬 작업

3. MapReduce의 폴트 톨러런스

• 각 프로세스는 master에게 task 진행 상태 전달 -> 일정시간 동안 전달되지 않으면 장애
• 장애시 Map/ Reduce task가 수행할 데이터만 전달하면 복구됨
• share nothing 아키텍쳐이기에 간단함

4. 하둡 MapReduce 구성요소

데몬관점 4가지 구성요소

• 네임노드: 마스터 역할 수행
• 데이터 노드: 데이터 입출력 처리 수행
• 잡트래커: job을 관리하는 마스터 ~ 맵리듀스의 마스터
• 테스크 트래커: 작업 수행 데몬

5. 하둡 MapReduce 실행 순서

1. 스플릿: 파일 분할 -> file split 하나 당 map task 생성
2. 맵: split에 대해 map 함수 처리하여 key-value 생성
3. 컴바인: reduce와 동일 프로그램 적용하여 중간 결과의 크기를 줄임
4. 파티션: key 기준으로 데이터를 분할 저장 및 정렬
5. 셔플: reduce 할당 및 로컬 파일 시스템에 저장
6. 정렬: 병합 정렬, key 기준 정렬
7. 리듀스: 정렬 단계 생성 파일을 리듀스 연산

6. 하둡 MapReduce 성능

• Map -> Reduce 과정중 sort 발생(병합, Key)
• sort의 처리 시간은 데이터 크기에 따라 선형 증가
• 서버를 늘린다고 해결되지 않음, 플랫폼 자체가 선형 확장성 필요
  • sort를 성능 지표로 사용

[5] 병렬쿼리시스템

• 코딩하지 않는 MapReduce 서비스 및 알고리즘을 제공

1. 병렬 쿼리 시스템 종류

• 구글 Sawzall
  • MapReduce를 추상화한 최초의 스크립트 병렬쿼리 언어
• 아파치 Pig
  • 의미적으로 SQL과 비슷한 언어이나 더 쉬움
• 아파치 Hive
  • 페이스북 개발
  • Pig와 같이 하둡 위에서 동작하며 SQL 및 JDBC 지원
  • MapReduce의 모든 기능을 지원

2. SQL on 하둡

• 하둡의 실시간 처리 문제를 해결하기 위함 -> 실시간 SQL 질의 분석 기술
• 드릴, 임팔라, 호크, 프레스토, 스팅거

3. 임팔라

• SQL on 하둡 기술 중 가장 먼저 공개
• 분석과 트랜잭션 처리르 모두 지원하는 SQL 결의 엔진
• 고성능을 위해 C++로 개발됨
• 하둡과 Hbase에 저장된 데이터 대상으로 SQL 질의
• 맵리듀스를 사용하지 않고 실행중 최적의 코드 사용하여 데이터 처리
• 하이브와 같이 하둡의 비정형 데이터 처리의 표준 SQL이나 더 빠름
  • 하이브는 SQL on 하둡이 아님

[6] 서버 가상화

1. 서버 가상화 효과

• 가상 머신 사이의 데이터 보호 - 가상머신은 허용된 네트워크로만 통신
• 장애 보호 - 가상 머신끼리 영향 없음
• 공유 자원에 대한 강제 사용 거부 - 할당된 자원 이상 못가져 가게 함
• 서버 통합 - 동일한 물리적 공간, 더 많은 서버 운영
• 자원 할당에 대한 유연성 증가 - 온디맨드 형식으로 자원 재배치 - 서버사이징
• 테스팅 -새로운 테스트 환경 쉽게 구축
• 시스템 관리
  • 로드 밸런싱 - 부하 발생시 다른 물리적 서버로 이동
  • 마이그레이션시 운영중인 서버 중지하지 않고 이동

2. 하이퍼 바이저

• 호스트 컴퓨터에서 다수의 OS를 실행하는 플랫폼
• 러프하게 VM을 칭함

3. 완전 가상화

• Privileged 명령어에 대해 trap을 발생시켜 하이퍼 바이저에서 실행
• 모든 자원을 하이퍼바이저가 관리하기에 모든 OS 설치 가능
• VMware, ESX, MS virtual server, Xen

4. 반가상화

• privileged 명령어를 게스트 OS에서 hypercall로 하이퍼바이저에 전달
• 하이퍼바이저는 privileged 레벨에 상관 없이 하드웨어로 명령 수행

5. 호스트기반 가상화

• 주 Host os 위에서 게스트 os 설치
• vm ware

6. 컨테이너 기반 가상화

• 운영체제만을 가상화
• 하이퍼바이저가 아닌 가상 운영환경