2장 데이처 처리 기술 (1)

학습목표

분산 데이터 저장 기술에 대한 이해

분산 컴퓨팅 기술에 대한 이해

클라우드 인프라 기술에 대한 이해

장 소개

 데이터 처리 기술을 3가지 측면에서 알아본다. 1절에서는 분산 파일 시스템, 공유 스토리지, 데이터베이스와 같은 저장 기술의 종류와 각 기능을 이해한다. 2절에서는 구글과 같은 인터넷 포털에서 사용하는 맵리듀스와 같은 저장 기술의 종류와 각 기능을 이해한다. 2절에서는 구글과 같은 인터넷 포털에서 사용하는 맵리듀스와 같은 분산 병렬 처리 기술에 대해서 설명한다. 3절은 XEN, VMWare와 같은 서버 가상화를 중심으로 클라우드 인프라 기술들에 대해서 설명한다.

목차

제1절 분산 데이터 저장 기술

제2절 분산 컴퓨팅 기술

제3절 클라우드 인프라 기술

제1절 분산 데이터 저장 기술

최근의 데이터를 처리할 수 있는 대규모의 클러스터 시스템 플랫폼을 필요로 한다. 대규모 클러스터 시스템 플랫폼은 네트워크상에 분산된 서버들을 클러스터링함으로써 대용량 저장 공간과 빠른 처리 성능을 제공한다. 분산 데이터 저장 기술은 네트워크 상에서 데이터를 저장 조회 관리 할 수 있으며, 저장 데이터의 정형화 여부와 데이터 모델에 따라 분산 파일시스템과 클러스터 데이터베이스, Ket-Value 저장소 정도로 구분 할 수 있다. 분산 파일 시스템과 Key-Value 저장소는 구글이나 아마존 같은 업체에서 대용량 데이터를 저장하기 위해 GFS나 BigTable, SimpleDB 등을 개발해 사용하면서 유명해졌다. 기존의 아키텍처는 고가의 마스터 서버에서 많은 역할을 수행하는 중앙 집중 방식이었다. 이는 장애 발생 자체를 차단하기 위해 노력한 구조인 반면, GFS 나 BigTable 같은 플랫폼은 저가의 PC급 서버들로 클러스터를 구성해 마스터서버의 역할을 축소했으며, 장애가 항상 발생할 수 있음을 염두에 두고 디자인 됐다. 이러한 아키텍처는 대용량 데이터와 대규모 확장성, 소유 총비용(TCO) 절감을 특징으로 한 오늘날의 클라우드 컴퓨팅 기술로적합하며, 여러 업체에서 사용중이거나 적용을 고려하고 있다. 한편 전통적인 DBMS 진영에서도 데이터의 볼륨이 커짐에 따라 분산 기술이 필요하게 됐다. 그렇지 않을 경우 데이터 검색에 많은 시간이 걸리는 등 성능상의 문제가 발생할 수 있다. 이처럼 성능 저하를 막는 동시에 데이터의 가용성을 높이기 위한 솔루션으로서 데이터베이스 자체의 파티셔닝 또는 클러스터링을 이용한 데이터 통합 기술도 있다.

 이번 절에서는 분산 데이터 저장기술을 앞서 언급한 몇가지로 분류해서 살펴보고자 한다.

1. 분산 파일 시스템

웹 2.0의 등장으로 날로 증가하는 블로그, UCC, IPTV 등과 같은 사용자 중심의 인터넷 서비스와 모든 디지털 기기를 이용하여 언제 어디서나 웹을 통해 서비스를 받을 수 있는 유비쿼터스 컴퓨팅 환경은 대규모 클러스터 시스템 플랫폼의 필요성을 부각시켰다. 대규모 클러스터 시스템 플랫폼은 네트워크상에 분산된 많은 서버들을 클러스터로 구성함으로써 대용량의 저장 공간과 빠른 처리 성능을 제공할 수 있어야 한다. 또한 시스템 확장이 쉽고, 서버 고장과 같은 시스템 장애가 발생하더라도 계속해서 안전하게 서비스를 제공할 수 있는 신뢰성과 가용성을 보장하여야 한다. 하지만 NFS(Network File System)와 같은 기존의 단순한 클라이언트/서버 수준의 분산 파일 시스템으로는 시스템 성능과 확장에 한계가 따른다. 비대칭형 클러스터 파일 시스템은 성능과 확장성, 가용성 면에서 적합한 분산 파일 시스템 구조로, 최근에 연구와 개발이 활발히 진행되고 있다. 비대칭형 클러스터 파일 시스템에서는 파일 메타데이터를 관리하는 전용 서버를 별도로 둠으로써 메타데이터에 접근하는 경로와 데이터에 접근하는 경로를 분리해, 이를 통하여 파일 입출력 성능을 높이면서 독립적인 확장과 안전한 파일 서비스를 제공한다. 하지만 메타데이터 서버에 부하가 집중될 수 있으며 single-of-failure지점이 될 수 있는 문제점도 내포하고 있다. 클러스터 파일 시스템은 구글에서 GFS(Google File System)에 대한 논문을 발표하면서 포털이나 검색 서비스 업체에서 많은 관심을 보이기 시작했으며, 최근에는 야후에서 적극적으로 지원하여 개발된 아파치의 하둡 파일 시스템 까지 등장하였다.

가. 구글 파일 시스템

 구글 파일 시스템은 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 파일 시스템으로 개발되었다. GFS는 다음과 같은 가정을 토대로 설계되었다.

저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정한다.

대부분의 파일은 대용량이라고 가정한다. 따라서 대용량 파일을 효과적으로 관리할 수 있는 방법이 요구된다.

작업 부하는 주로 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산이다.

파일에 대한 쓰기 연산은 주로 순차적으로 데이터를 추가하며, 파일에 대한 갱신은 드물게 이루어진다. 

여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화 할수 있는 방법이 요구된다.

낮은 응답 지연시간보다 높은 처리율이 보다 중요하다.

GFS의 클라이언트는 POSIX(Portable Operating System Interface) 인터페이스를 지원하지 않으며, 파일 시스템 인터페이스와 유사한 자체 인터페이스를 지원한다. 또한 여러 클라이언트에서 원자적인 데이터 추가(atomic append) 연산을 지원하기 위한 인터페이스를 지원한다.

GFS에서 파일은 고정된 크기의 chunk들로 나누어 chunk 서버들에 분산 저장된다. 그리고 각 chunk에 대한 여러 개의 복제본도 chunk 서버에 분산 저장된다. 따라서 클라이언트는 파일에 접근하기 위하여 마스터로부터 해당 파일에 chunk가 저장된 chunk 서버의 위치와 핸들을 먼저 받아 온다.

 이어서 직접 chunk 서버로 파일 데이터를 요청한다. GFS의 마스터는 단일 마스터 구조로 파일 시스템 이름 공간과 파일의 chunk 서버로 파일 데이터를 요청한다. GFS의 마스터는 단일 마스터 구조로 파일 시스템이름 공간과 파일의 CHUNK 매핑 정보, 각 CHUNK가 저장된 CHUNK 서버들의 취지 정보 등 모든 메타데이터를 메모리상에서 관리한다. GFS에서는 기본 chunk의 크기를 64MB로 지정함으로써 파일 메타데이터의 크기를 줄인다. 또한 기존의 트리 구조가 해시 테이블 구조 등을 사용함으로써 메모리상에서 보다 효율적인 메타데이터 처리를 지원한다. 마스터에서는 주기적으로 하트비트 메시지를 이용하여 chunk서버에 저장된 chunk들의 상태를 체크해 상태에 따라 chunk를 재복제하거나 재분산하는 것과 같은 회복 동작을 수행한다.

 마스터에 대한 장애 처리와 회복을 위해 파일시스템 이름 공간과 파일의 chunk 매핑 변경 연산을 로깅하고 마스터의 상태를 여러 섀도 마스터에 복제한다.

 Chunk 서버는 로컬 디스크에 chunk를 저장 관리하면서 클라이언트로부터의 chunk 입출력 요청을 처리한다. chunk는 마스터에 의해 생성 삭제될 수 있으며, 유일한 식별자에 의해 구별된다. 마스터는 하나의 chunk 서버를 primary로 지정하여 복제본의 갱신 연산을 일관되게 처리할 수 있도록 보장한다.

나. 하둡 분산 파일 시스템

하둡은 아파치의 검색엔진 프로젝트인 루씬의 서브프로젝트로 진행되었지만, 2008년 1월에 아파치의 최상위(Top Level) 프로젝트로 승격되었다. 하둡은 하둡 분산 파일 시스템(HDFS)과 MapReduce 구현 등을 포함한다. HDFS는 처음에 아파치 너치(Apache Nutch) 웹 검색 엔진의 파일 시스템으로 개발 되었으며, 구글 파일 시스템과 아키텍처와 사상을 그대로 구현한 클로닝 프로젝트라고 할 수 있다.

HDFS는 하나의 네임노드와 다수의 데이터노드로 구성된다. 네임노드는 파일 시스템의 이름공간을 관리하면서 클라이언트로부터의 파일 접근 요청을 처리한다. HDFS에서 파일 데이터는 블록 단위로 나뉘어 여러 데이터노드에 분산 저장된다. 그리고 블록들은 가용성을 보장하기 위하여 다시 복제 저장된다.

따라서 데이터노드는 클라이언트로부터의 데이터 입출력 요청을 처리한다. HDFS에서 파일은 한 번 쓰이면 변경되지 않는다고 가정한다. 따라서 HDFS는 데이터에 대한 스트리밍 접근을 요청하며, 배치 작업에 적합한 응용을 대상으로 한다.

네임노드는 데이터노드들로부터 하트비트를 주기적으로 받으면서 데이터노드들의 상태를 체크한다. 또한 하트비트를 주기적으로 받으면서 데이터노드들의 상태를 체크한다. 또한 하트비트 메시지에 포함된 블록 정보를 가지고 블록의 상태를 체크할 수 있다.

HDFS는 클라이언트, 네임노드, 데이터노드 간의 통신을 위하여 TCP/IP 네트워크상에서 RPC(Remote Procedure Call)을 사용한다.

.

다. 러스터

러스터는 클러스터 파일 시스템(Cluster File Systems Inc.)에서 개발한 객체 기반 클러스터 파일 시스템이다. 러스터는 클라이언트 파일 시스템, 메타데이터 서버, 객체 저장 서버들로 구성되며, 이들은 고속 네트워크로 연결된다. 러스터에서는 계층화된 모듈 구조로 TCP/IP, 인피니밴드, 미리넷 과 같은 네트워크를 지원한다. 클라이언트 파일 시스템은 리눅스 VFS(Virtual File System)에서 설치할 수 있는 파일 시스템으로, 메타데이터 서버와 객체 저장 서버들과 통신하면서 클라이언트 응용에 파일 시스템 인터페이스를 제공한다. 메타데이터 서버는 파일 시스템의 이름 공관과 파일에 대한 메타데이터를 관리하며, 객체 저장 서버는 파일 데이터를 저장하고 클라이언트로부터의 객체 입출력 요청을 처리한다. 객체는 객체 저장 서버들에 스트라이핑되어 분산 저장된다.

러스터는 유닉스 시맨틱을 제공하면서 파일 메타데이터에 대해서는 라이트백 캐시를 지원한다. 이를 위해 클라이언트에서 메타데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달한다. 그러면 메타데이터 서버는 전달된 갱신 레코드를 재수행하여 변경된 메타데이터를 반영한다 더불어 메타데이터 서버에서는 메타데이터를 동시에 접근하는 부하에 따라 클라이언트 캐시에서 라이트백 캐시를 지원하거나 메타데이터 서버에서 메타데이터를 처리하는 방식을 적용한다.

러스터는 메타데이터 서버에서 처리하도록 하는 방식을 사용해 메타데이터에 대한 동시 접근이 적으면 클라이언트 캐시를 이용한 라이트백 캐시를 사용하고, 메타데이터에 대한 동시 접근이 많으면 클라이언트 캐시를 이용한 클라이언트 캐시를 사용함으로써 발생할 수 있는 오버헤드를 줄인다.

러스터는 파일 메타데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금을 사용한다. 메타데이터에 접근하기 위해서는 메타데이터의 서버의 잠금 서버로부터 잠금을 획득해야 한다. 파일 데이터를 접근하기 위해서는 해당 데이터가 저장된 객체 저장 서버의 잠금 서버로부터 잠금을 획들해야 한다.

또한 러스터에서는 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 최소화하기 위하여 메타데이터에 대한 잠금 요청 시에 메타데이터 접근 의도를 같이 전달하는 인텐트 기반 잠금 프로토콜을 사용한다. 따라서 메타데이터 서버는 메타데이터 접근 의도에 다라 해당 동작을 수행하고, 잠금을 승인하느 처리를 함께 수행함으로써 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 줄일 수 있다.

2. 데이터베이스 클러스터

데이터를 통합할 때, 성능 향상과 가용성을 높이기 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링을 이용한다. 데이터베이스 파티셔닝을 구현하면 얻을 수 있는 혜택은 다음과 같다.

파티션 사이의 병렬 처리를 통한 빠른 데이터 검색 및 처리 성능을 얻을 수 있다.

성능의 선형적인 증가 효과를 볼 수 있다.

특정 파티션에서 장애가 발생하더라도 서비스가 중단되지 않는 고가용성을 확보할 수 있다.

데이터베이스 파티셔닝은 데이터베이스 시스템을 구성하는 형태에 따라 단일 서버 내의 파티셔닝과 다중 서버 사이의 파티셔닝으로 구분할 수 있다. 리소스 공유 관점에서는 다시 공유 리스크와 무공유로 구분할 수 있다.

무공유

무공유 클러스터에서 각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬디스크에 저장하며, 이 파일들은 노드 간에 공유하지 않는다.

각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유권을 갖고 있는 인스턴스가 처리한다. 한 노드가 데이터 처리 요청을 받으면, 해당 노드는 처리할 데이터를 갖고 있는 노드에 신호를 보내 데이터 처리를 요청한다. 무공유 구조의 장점은 노드 확장에 제한이 없다는 것이다. 단점은 각 노드에 장애가 발생할 경우를 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성해야 한다는 것이다.

 Oracle RAC(Real Application Cluster)를 제외한 대부분의 데이터베이스 클러스터가 무공유 방식을 채택하고 있다.

공유 디스크

공유 디스크 클러스터에서 데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들과 공유하며, 각 인스턴스는 모든 데이터에 접근할 수 있다. 데이터를 공유하려면 SAN(Storage Area Network)과 같은 공유 디스크가 반드시 있어야 하며, 모든 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널이 필요하다.

공유 디스크 방식의 가장 큰 장점은 높은 수준의 폴트톨러런스 제공이다. 클러스터를 구성하는 노드 중 하나의 노드만 살아있어도 서비스가 가능하기 때문이다. 단점은 클러스터가 커지면 디스크 영역에서 병목현상이 문발생하는 문제다. Oracle RAC가 공유 디스크 방식을 이융하고 있다.

가. Oracle RAC 데이터베이스 서버

Oracle RAC 데이터베이스 서버는 클러스터의 모든 노드에서 실행되며, 데이터는 공유 스토리지에 저장된다. 클러스터의 모든 노드는 데이터베이스의 모든 테이블에 동등하게 액세스하며, 특정 노드가 데이터를 '소유'하는 개념이 없다. 따라서 데이터를 파티셔닝할 필요가 없지만, 성능 향상을 위해 빈번하게 파티셔닝 된다. 응용 프로그램은 클러스터의 특정 노드가 아니라 RAC는 클러스터의 모든 노드에 로드를 고르게 분산한다.

가용성

클러스터의 한 노드가 어떤 이유로 장애를 일으키면 Oracle RAC는 나머지 노드에서 계속 실행된다. 장애가 발생한 노드에 연결됐던 모든 응용 프로그램은 투명하게 다시 연결되어 클러스터의 나머지 노드에 분산된다.

확장성

추가 처리 성능이 필요하면 응용 프로그램이나 데이터베이스를 수정할 필요 없이 새 노드를 클러스터에 쉽게 추가할 수 있다. 클러스터의 모든 노드 간에 균형이 유지되도록 로드가 다시 분산 된다. Oracle 10gR2 RAC는 클러스터에 최대 100개의 노드를 지원한다.

비용절감

RAC는 표준화된 소규모(CPU 4개 미만) 저가형 상용 하드웨어의 클러스터에서도 고가의 SMP 시스템만큼 효율적으로 응용 프로그램을 실행함으로써 하드웨어 비용을 절감한다. 예를 들어 4CPU의 16노드 클러스터를 사용하면 동급 성능의 64CPU SMP 시스템에 비해 비용을 크게 절감할 수 있다. 

Oracle RAC는 여러 장점을 갖고 있지만 일반적으로 4노드 이상 잘 구성하지 않는다. 도입 비용 때문에 확장성이 중요한 데이터보다는 고가용성을 요구하는 데이터에 많이 사용한다.

나. IBM DB2 ICE(Integrated Cluster Environment)

DB2는 CPU 메모리 디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링을 지원한다. 애플리케이션은 여러 파티션에 분산된 데이터베이스를 하나의 데이터베이스로 보게 되고, 데이터가 어느 파티션에 존재하고 있는지 알 필요가 없다. 따라서 데이터와 사용자가 증가하면 애플리케이션의 수정 없이 기존 시스템에 노드를 추가하고 데이터를 재분배함으로써 시스템의 성능과 용량을 일정하게 유지할 수 있다.

하지만 각 노드로 분산되는 파티셔닝을 어떻게 구성하느냐에 따라 성능의 차이가 많이 발생할 수 있으며 하나의 노드에 장애가 발생할 경우 해당 노드에서 서비스하는 데이터에 대한 별도의 페일오버메커니즘이 필요하게 된다. 따라서 DB2를 이용하여 클러스터를 구성할 때에도 가용성을 보장하기 위해 공유 디스크 방식을 이용한다. 공유 디스크에 저장된 데이터 파일에 대해 특정 시점에서는 특정 노드에의해 서비스 되지만 장애 상황이 발생하게 되면 다른 노드가 해당 데이터에 대한 서비스를 처리하는 방식으로 가용성을 보장한다.

다. 마이크로소프트 SQL Server

 SQL Server는 연합(Federated) 데이터베이스 형태로 여러 노드로 확장할 수 있는 기능을 제공한다. 연합 데이터베이스는 디스크 등을 공유하지 않는 독립된 서버에서 실행되는 서로 다른 데이터베이스들 간의 논리적인 결합이며, 네트워크를 이용하여 연결된다.

데이터는 관련된 서버들로 수평적으로 분할 된다. 테이블을 논리적으로 분리해 물리적으로는 분산된 각 노드에 생성하고, 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNION ALL을 이용해 논리적인 뷰(VIEW)를 구성하는 방식으로 분산된 환경의 데이터에 대한 싱글뷰를 제공한다. SQL Server에서는 이런 뷰를 DVP(Distributed Partitioned View)라고 한다. 이런 구성의 가장 큰 문제는 DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 시스카 정보가  없기 때문에 질의 수행을 위해 모든 노드를 액세스해야 한다는 점이다. 노드의 개수가 작으면 간단하게 구성할 수 있지만, 노드가 많아지거나 노드의 추가/삭제가 발새애하는 경우 파티션을 새로해야 하는 문제도 따른다. 또한 페일오버에 대해서는 별도로 구성해야 한다. SQL Server에서도 다음과 같은 페일오버 메커니즘을 제공하지만, Active-Active가 아닌 Active-Standby 방법을 사용하고 있다.

라. MySQL

MySQL 클러스터는 무공유 구조에서 메모리 기반 데이터베이스의 클러스터링을 지원하며, 특정한 하드웨어 및 소프트웨어를 요구하지 않고 병렬 서버구조로 확장이 가능하다.

MySQL 클러스터는 관리 노드 (Management Node), 데이터 노드(NDB Node), MySQL 노드로 구성되며 다음과 같은 역할을 수행한다.

관리 노드 : 클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여한다.

데이터 노드 : 클러스터의 데이터를 저장하는 노드

MySQL 노드 : 클러스터 데이터에 접근을 지원하는 노드

MySQL 클러스터는 데이터의 가용성을 높이기 위해 데이터를 다른 노드에 복제시키며, 특정 노드에 장애가 발생하더라도 지속적인 데이터 서비스가 가능하다. 장애가 났던 노드가 복구되어 클러스터에 투입된 경우에도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동으로 수행된다. 데이터는 동기화 방식으로 복제되며, 이런 작업을 위해 일반적으로 데이터 노드 간에는 별도의 네트워크를 구성한다.

MySQL의 최근 버전(5.1.6 이상)에서는 디스크 기반의 클러스터링을 제공한다. 디스크 기반 클러스터링에서는 인덱스가 생성된 칼럼은 기존과 동일하게 메모리에 유지되지만, 인덱스를 생성하지 않은 칼럼은 디스크에 저장된다. 따라서 디스크에 저장된 데이터는 모두 인덱스가 없는 데이터다. 이 경우 디스크에 저장된 데이터와 JOIN 연산을 수행할 경우 성능이 좋지 않기 때문에 애플리케이션 개발 시 주의해야 한다. 또한 디스크 기반이라 하더라도 인덱스로 구성된 칼럼은 메모리에 있기 때문에 데이터의 크기와 메모리 크기를 고려하여 인덱스 생성과 클러스터의 참여하는 장비의 메모리를 산정해야 한다. 다음은 MySQL 클러스터 구성을 할 경우 제한 사항이다.

-파티셔닝은 LINEAR KEY 파티셔닝만 사용 가능하다.

-클러스터에 참여하는 노드 (SQL 노드, 데이터 노드, 매니저를 포함) 수는 255로 제한한다. 데이터 노드는 최대 48개까지만 가능하다.

-트랜잭션 수행 중에 롤백을 지원하지 않으므로 작업 수행 중에 문제가 발생하였다면, 전체 트랜잭션 이전으로 롤백해야 한다.

-하나의 트랜잭션에 많은 데이터를 처리하는 경우 메모리 부족 문제가 발생할 수 있으며, 여러 개의 트랜잭션으로 분리해 처리하는 것이 좋다.

-칼럼명 길이는 31자, 데이터베이스와 테이블명 길이는 122자까지로 제한된다. 데이터베이스 테이블, 시스템 테이블, 블롭 인덱스를 포함한 메타데이터(속성정보)는 2만 320개까지만 가능하다.

- 모든 클러스터의 기종은 동일해야 한다. 기종에 따른 비트 저장방식이 다르면 문제가 발생할 수 있다.

- 운영 중에 노드를 추가/삭제할 수 있다.

- 디스크 기반 클러스터인 경우 tabledspace의 개수는 2^32, tablespace당 데이터 파일의 개수는 2^16, 데이터 파일의 크기는 32GB까지 가능하다.

3. NoSQL

NoSQL은 Key와 Value의 형태로 자료를 저장하고, 빠르게 조회할 수 있는 자료 구조를 제공하는 저장소다. 전통적인 RDBMS의 장점이라고 할 수 있는 복잡한 Join 연산 기능은 지원하지 않지만 대용량 데이터와 대규모 확장성을 제공한다.

가. 구글 빅테이블

구글은 대용량의 데이터를 저장하기 위해 빅테이블(BigTable)이라는 분산 데이터 관리 저장소를 개발하였다. 빅테이블은 데이터 서비스가 아닌 구글 내부에서 사용하는 데이터 저장소다. 구글은 AppEngine 이라는 플랫폼 서비스를 2008년 오픈했다. AppEngine에서 사용하는 데이터 저장소가 빅테이블이다.

데이터 모델

빅테이블은 multi-dimension sorted hash map을 파티션하여 분산 저장하는 저장소다. 테이블 내의 모든 데이터는 row-key의 사전적 순서로 정렬 저장된다. row는 n개의 column-family를 가질 수 있으며 column-family에는 column-key, value, timestamp의 형태로 데이터를 저장한다. 하나의 row-key, column-family 내에 저장된 데이터는 column-key의 사전적 순서로 정렬돼 있다. 동일한 column-key에 대해 타임스탬프(timestamp)가 다른 여러 버전의 값이 존재할 수 있다. 따라서 BigTable에 저장되는 하나의 데이터(map)의 키 값 또는 정렬 기준은 "rowkey + columnkey + timestamp"가 된다.

테이블의 파티션은 row-key를 이용하며, 분리된 파티션은 분산된 노드에서 서비스하도록 한다. 분리된 파티션을 Tablet이라 하며, 한 Tablet의 크기는 보통 100~200MB다.

페일오버

특정 노드에 장애가 발생할 경우 빅테이블의 마스터는 장애가 발생한 노드에서 서비스되던 Tablet을 다른 노드로 재할당시킨다. 재할당 받은 노드는 구글 파일 시스템(GFS)에 저장된 변경 로그 파일, 인덱스 파일, 데이터 파일 등을 이용해 데이터 서비스를 위한 초기화 작업을 수행한 후 데이터 서비스를 한다. 빅테이블은 데이터베이스 클러스터 분류로 나누자면 공유 디스크 방식이다. 공유 저장소로 구글에서 개발된 분산 파일 시스템을 이용하고 있어 모든 노드가 데이터, 인덱스 파일을 공유하고 있다. 빅테이블의 SPOF는 마스터다. 빅테이블은 분산 락 서비스를 제공하는 Chubby를 이용해 Master를 계속 모니터링하다가 마스터에 장애가 발생하면 가용한 노드에 마스터 역할을 수행하도록 한다. Chubby는 자체적으로 폴트톨러런스 지원 구조이기 때문에 절대로 장애가 발생하지 않는다.

빅테이블은 데이터 저장소를 위해 별도의 클러스터를 구성하기보다는 파일시스템, Map & Reduce 컴퓨팅 클러스터와 동일한 클러스터 위에 구성된다. 실시간 서비스뿐만 아니라 대용량 데이터의 분석 처리에 적합하도록 구성됐다.

AppEngine

AppEngine은 내에서 운영되 애플리케이션의 데이터 저장소를 제공하며, 내부적으로는 빅테이블을 이용한다. 사용자에게 직접 빅테이블의 API를 공개하지 않고 추상 계층을 두고 있는데, API에 대한 추상화뿐만아니라 데이터 모델에 대해서도 추상화되어 있다.

사용자 테이블을 생성할 경우 빅테이블의 테이블로 생성되는 것이 아니라 빅테이블의 특정 테이블의 한 영역만을 차지하게 된다. 빅테이블에서는 별도의 사용자 정의 인덱스를 제공하지 않는 반면, AppEngine에서는 사용자가 수행하는 쿼리를 분석하여 자동으로 인덱스를 생성해준다. AppEngine에서 생성한 인덱스도 빅테이블 또는 테이블 내의 컬럼으로 저장된다. 

빅테이블은 Personalized Search, Google Analytics, Crawl, News recommend 등 2006년 기준으로 60개 이상의 프로젝트에서 사용되고 있다. 이들 시스템의 공통된 특징은 수백 테라바이트에서 수 페타바이트 규모의 데이터를 다루고 있으며, 실시간으로 데이터를 저장하거나 조회하고 주기적인 배치 작업을 통해 데이터를 분석하고, 분석된 결과를 다시 실시간으로 데이터를 저장하고나 조회하고, 주기적인 배치 작업을 통해 데이터를 분석하고, 분석된 결과를 다시 실시간으로 서비스하는 패턴을 갖고 있다. 다음 표에서 보는 것 처럼 2006년 기준으로 구글은 실제 업무에 사용하는 388개의 빅테이블 클러스터를 운영하고 있다.

나. 아마존 SimpleDB

SimpleDB는 아마존의 데이터 서비스 플랫폼이다. SimpleDB는 아마존의 데이터 서비스 플랫폼이다. SimpleDB는 웹 애플리케이션에서 사용하는 데이터의 실시간 처리를 지원한다.

SimpleDB는 주로 아마존의 다른 플랫폼 서비스와 같이 사용된다. EC2, S3등과 같은 아마존의 내부 서비스 간 네트워크 트래픽은 무료이고, 외부와의 In/Out 트래픽에는 요금을 부과하는 아마존 서비스의 가격 정책 때문이다. 사용자는 EC2에서 수행되는 웹 서버로 접근하고, 웹 서버에서 SimpleDB의 데이터를 조회해 적절하게 가공한 후 사용자에게 제공하는 형태로 구성된다. 비용을 염두에 두지 않은 경우라면 외부에서 직접 SimpleDB에 접근해 사용하는 것도 가능하다.

SimpleDB는 하나의 데이터에 대해 여러 개의 복제본을 유지하는 방식으로 가용성을 높인다. 이 경우 복제간의 consistency를 고려해야 하는데, SimpleDB에서는 'Eventual Consistency' 정책을 취한다. Eventual Consistency는 트랜잭션 종료 후 데이터는 모든 노드에 즉시 반영되지 않고 초 단위로 지연되어 동기화된다.

SimpleDB는 관계형 데이터 모델과 표준 SQL을 지원하지 않으며, 전용 쿼리 언어를 이용하여 데이터를 조회한다. SimpleDB의 데이터 모델은 Domain, Item, Attribute, Value로 구성되며 스키마가 없는 구조다.

도메인

관계형 데이터베이스의 테이블과 동일한 개념으로 하나의 도메인에는 최대 10GB의 데이터를 저장할 수 있으며, 사용자는 100개의 도메인을 가질 수 있다. 사용자는 최대 1,000GB의 데이터를 SimpleDB에 저장할 수 있다.

Items

관계형 데이터 베이스의 레코드와 동일한 개념인 item은 독립적인 개체를 나타내며, 하나 이상의 Attribute를 가진다. 한 item은 최대 256개의 Attribute를 가질 수 있다.

Attribute

관계형 데이터베이스의 컬럼과 동일한 개념이지만 사용하기 전에 미리 정의할 필요가 없다. Name, Value 쌍으로 데이터를 저장하고, 저장되는 데이터의 Name이 attribute의 이름이 된다. item의 특징 Attributee(Cell)에는 여러 개의 값을 저장할 수 있다.

여러 도메인에 걸친 쿼리는 허용되지 않으며, 한 번에 하나의 도메인에 대해서만 쿼리를 수행해야 한다. 이 경우 1+N(mast-slave) 관계의 데이터 모델을 갖는 두 개의 도메인으로부터 데이터를 조회할 경우 쿼리가 여러 번 수행돼야 하는 단점이 있다. 이것은 SimpleDB만의 문제가 아니라 대부분의 데이터 서비스에서 갖는 문제다.

클라이언트 SOAP 또는 REST 프로토콜을 이용하여 SimpleDB를 이용할 수 있으며, 다음과 같은 API를 제공한다.

CreateDomain : 도메인을 생성한다.

DeleteDomain : 도메인을 삭제한다.

ListDomains : 모든 도메인의 목록을 가져온다.

PutAttributes : Item을 생성하고 Attribute에 값을 추가한다.

DeleteAttributes : Attribute 값을 삭제한다.

GetAttributes : Attribute의 값을 조회한다.

Query : 쿼리를 이용하여 조건에 맞는 여러 개의 item을 조회한다. 한 번의 쿼리는 최대 5초 이내에 수행되어야 하며, 쿼리 결과로 받을 수 있는 최대 item 수는 256 개다.

다. 마이크로소프트 SSDS

SSDS(SQL Server Data Service)는 마이크로소프트에서 2008년 4월에 베타 서비스를 실시한 데이터 서비스다. 다른 데이터 서비스와 동일하게 SSDS 역시 고가용성을 보장한다.

SSDS의 데이터 모델은 컨테이너, 엔티티로 구성돼 있다. 컨테이너는 테이블과 유사한 개념이지만 하나의 컨테이너에 여러 종류의 엔티티를 저장할 수 있다. 예를 들어 Order entity와 OrderDetali entity를 하나의 컨테이너에 저장할 수 있다. 엔티티는 레코드와 유사한 개념으로, 하나의 엔티티는 여러 개의 property를 가질 수 있으며, property는 name-value 쌍으로 저장된다.

SSDS를 이용하여 애플리케이션을 개발하면 관련된 정보를 하나의 컨테이너에 저장한다. 관계형 데이터베이스에서는 엔티티를 구분하고 엔티티별로 테이블을 생성하는 것이 일반적이다. 예를 들어 CustomerA의 주문 정보 (Order)와 주문 상세정보를 저장하기 위해 Order 테이블과 OrderDetail 테이블을 생성한다. 하지만 SSDS에서는 CustomerA라는 Container을 만들고 Order와 OrderDetail entity를 생성한 컨테이너에 모두 저장한다. 즉, CustomerID가 파티셔닝 키가 되고 파티셔닝 대상은 컨테이너가 된다.

이런 방식으로 컨테이너를 구성하면, 많은 컨테이너가 생성되는데 이들 컨테이너는 여러 노드에 분산 관리 된다.쿼리는 하나의 컨테이너만을 대상으로 한다. 

컨테이너의 생성/삭제, 엔티티의 생성/삭제 조회, 쿼리 등의 API를 제공하고 SOAP/REST 기반의 프로토콜을 지원한다.

제2절 분산 컴퓨팅 기술

최근의 컴퓨팅 환경은 저가형 서버들을 클러스터링하고, 그것으로부터 다양한 리소스(CPU, 메모리, 하드디스크, 파일, 프로세스)들을 끌어 모아 표준화한 대규모 고성능 컴퓨팅 플랫폼을 구축하는 일에 많은 노력을 기울이고 있다(HPC, Grid, Cluster Computing). 이러한 컴퓨팅 환경은 대용량 데이터를 다루고 있는 다양한 응용 분야에서도 중요한 역할을 수행하게 되는데, 계산중심의 수학 과학 분야뿐만 아니라 데이터 중심의 텍스트 마이닝과 로그 모델링 같은 정보분석 분야에서도 그 활용도가 높다. 실제 구글의 MapReduce 프로그래밍 방식은 대용량 데이터를 다루는 인터넷 분야에 상당한 영향을 끼치고 있다. 야후는 오픈소스 하둡을 검색 전반에 걸쳐 활용하고 있으며, 아마존은 EC2와 S3를 선보임으로써 차세대 분산 컴퓨팅 기술을 선도하고 있다. 또한 Parallel DBMS 분야에서도 분산된 지역 DB로부터 다차원 데이터를 분석 처리하기 위하여 MapReduce 방식을 적극 도입하고 있다.

본 장에서는 MapReduce에 대한 정의와 역할을 간략하게 다루고, 다양한 MapReduce 구현 사례를 소개하고자 한다.

1. MapReduce

MapReduce는 분할정복 방식으로 대용량 데이터를 병렬로 처리할 수 있는 프로그래밍 모델이다. 구글에서 MapReduce 방식의 분산 컴퓨팅 플랫폼을 구현해 성공적으로 적용함으로써 더욱 유명해졌으며, 오픈 소스인 Hadoop MapReduce 프레임워크가 동일한 기능을 지원한다.

MapReduce 작업은 특별한 옵션을 주지 않으면 Map Task 하나가 1개의 블록(64MB)을 대상으로 연산을 수행한다. 예를 들어 320MB의 파일을 대상으로 작업을 돌리면 5개의 Map Task가 생성되며, Map 과정에서 생산된 중간 결과물들을 Reduce Task들(사용자가 개수 지정)이 받아와서 정렬 및 필터링 작업을 거쳐서 최종 결과물을 만들어 낸다.

가. 구글 MapReduce

구글은 대용량 데이터를 처리하는 수백 가지의 연산 방식들을 개발해 사용하였다. 대부분의 연산 방식들은 직관적이었지만 처리해야 할 데이터가 매우 컸기 때문에 수백 대 혹은 수천 대의 서버들에 분산 처리해야만 원하는 시간 안에 작업을 마칠 수 있었다. 이러한 분산 환경에서는 개발자가 연산의 병렬화, 데이터 분산, 장애 복구 등의 작업들을 직접 처리해야 하기 때문에 그만큼 코드의 복잡성이 증가하여 많은 개발 시간이 소요된다. 개발자에게는 이러한 병렬화, 장애 복구 등의 복잡성을 추상화시켜서 오직 핵심 기능 수현에만 집중할 수 있도록 해주기 위해서 MapReduce를 만들게 되었다.

프로그래밍 모델

MapReduce는 Map과 Reduce 2개의 단계로 나눌 수 있으며 Map에서는 Key와 Value의 쌍들을 입력으로 받는다. 하나의 Key, Value쌍은 사용자가 정의한 Map 함수를 거치면서 다수의 새로운 Key, Value쌍들로 변환되어 로컬 파일 시스템에 임시 저장된다. 저장된 임시 파일들은 프레임워크에 의해 Reduce에게 전송된다. 이 과정에서 자동으로 Shuffling과 group by 정렬을 한 후 Reduce의 입력 레코드로 들어가게 되는데 형식은 Key와 Value의 리스트다. Reduce의 입력 레코드들은 사용자가 정의한 Reduce 함수를 통해 최종 Output으로 산출된다. 사용자 관점에서는 이전에 언급했던 장애 복구와 같은 세세한 이슈들은 신경 쓸 필요 없이 Map과 Reduce 두 함수만 작성하는 것만으로 대규모 병렬 연산 작업을 수행할 수 있다.

실행과정

사용자가 MapReduce 프로그램을 작성해 실행하면 마스터는 사용자의 프로그램에서 지정한 입력 데이터 소스를 가지고 스케줄링을 한다. 가령 하나의 큰 파일은 여러 개의 파일 split으로 나뉘며, 각 split들이 Map 프로세스들의 할당 단위가 된다. 보통 split 단위는 블록 사이즈인 64MB 또는 128MB가 되며 split 수만큼 Map Task들이 워커로부터 fork됨가 동시에 실행돼 Output을 로컬 파일 시스템에 저장한다. 이때 Output 값들은 Partitioner라는 Reduce 번호를 할당해 주는 클래스를 통해 어떤 Reduce에게 보내질지 정해진다. 특별히 지정하지 않으면 Key의 해시 값을reduce의 개수로 Modular 계산한 값이 부여되어 동일한 Key들은 같은 Reduce로 배정된다. Map 단계가 끝나면 원격의 Reduce 워커들이 자기에 할당된 Map의 중간 값들을 네트워크로 가져, 사용자의 Reduce 로직을 실행해 최종 산출물을 얻어 낸다. 보통 Reduce의 개수는 Map의 개수보다 적으며, 실행 흐름에서 알 수 있듯이 Map의 중간 데이터 사이즈에 따라 성능이 좌우된다. 분산 Grep이나 빈도 수 계산 등의 작업은 Map 단계를 거치면서 데이터 사이즈가 크게 줄어들고, 줄어든 크기만큼 Reduce 오버헤드도 줄어듦에 따라 성능상 이점이 많다. 하지만 정렬 같은 작업은 입력 데이터의 사이즈가 줄지 않고 그대로 Reduce로 전해지므로 오버헤드에 따른 수행 성능이 저하된다. 즉 정렬 같은 종류의 작업에는 MapReduce 모델이 적합하지 않다.

폴트톨러런스

각 프로세스에서는 Master에게 Task 진행 상태를 주기적으로 보낸다. 마스터는 모든 워커들의 Task 상태 정보를 가지고 있다가 특정 워커의 태스크가 더 이상 진행되지 않거나 상태 정보를 일정한 시간 동안(Heartbeat Timeout) 받지 못하면 Task에 문제가 있다고 결론을 내린다. 이후 장애복구를 해야 하는데 MapReduce는 Shared Nothing 아키텍처이기 때문에 메커니즘이 간단하다. 특정 Map이나 Reduce Task들이 죽은 경우, 해당 Task가 처리해야 할 데이터 정보만 다른 워커에게 전해주면 워커는 받은 데이터 정보를 인자로 새로운 Task를 재실행하면 된다.

나. Hadoop MapReduce

 구글의 MapReduce는 논문으로만 접할 수 있고 실제 구현은 공개되지 않았다. 아파치 오픈소스 프로젝트인 하둡의 MapReduce는 구글에서 발표한 논문을 바탕으로 자바 언어로 구현한 시스템이라고 할 수 있다. 앞서 언급한 분산파일 시스템인 HDFS와 이번에 소개할 Haddop MapReduce가 하둡의 핵심 구성요소다. 하둡은 아파치 검색엔진 프로젝트인 루씬(Lucene)의 서브 프로젝트로 시작되었다. 야후에서는 전담 팀을 구성해서 하둡을 지원하기 시작했고, 각종 개발자 커뮤니티에서 활발하게 참여하면서 크게 개선됐다. 전 세계적으로 다양한 산업 영역에서 수많은 업체가 실제 서비스에 활용할 정도로 성능과 안정성이 검증된 상태다.

아키텍처

데몬 관점에서 하둡은 4개의 구성요소를 가지고 있다. 네임노드(NameNode)와 데이터노드(DataNode)는 분산 파일 시스템의 데몬들이다. JobTracker는 Mapreduce 시스템의 마스터이고, TaskTracker는 워커데몬이다. TaskTracker는 JobTracker에게 3초에 한번씩 주기적으로 하트비트(Heatbeat)를 보내 살아 있다는 것을 알린다. 클라이언트에서 하둡 작업을 실행하면, 프로그램 바이너리와 입출력 디렉터리와 같은 환경 정보들이 JobTracker에게 전송된다. Jobtracker에서는 작업을 다수의 Task로 쪼갠 후 그 Task들을 어떤 TaskTracker에게 전송된다. Jobtracker에서는 작업을 다수의 Task로 쪼갠 후 그 Task들을 어떤 TaskTracker에게 보내면 데이터 지역성을 보장할지도 감안해 내부적으로 스케쥴링해 큐(Queue)에 저장한다. TaskTracker에서 Heartbeat를 보내면 JobTracker는 먼저 해당 TaskTracker에게 할당된 Task가 있는지 큐에서 살펴본다. 이때 Task가 있으면 하트비트의 Reponse 메시지에 Task 정보를 실어서 TaskTracker에게 보낸다. TaskTracker는 Response 메시지의 내용을 분석해 프로세스를 fork해 자기에게 할당된 Task를 처리한다.

하둡의 성능

MapReduce에서 Sort는 어떠한 작업을 실행하더라도 Map에서 Reduce로 넘어가는 과정에서 항상 발생하는 내부적인 프로세스다. 또한 Sort작업은 데이터가 커질수록 처리 시간이 선형적으로 증가한다. 클러스터 구성 서버들의 숫자를 늘림으로써 처리 시간을 줄일 수 있는 것은 아니다. 플랫폼 자체적으로 선형 확장성을 갖고 있어야 처리 시간을 줄일 수 있다. 이런 의미에서 Sort는 하둡 같은 분산컴퓨팅 플랫폼의 성능과 확장성을 동시에 측정할 수 있는 좋은 실험이라고 할 수 있다. Hadoop MapReduce 개발초기인 2006년 이후 최근까지 6배 정도의 성능 향상이 있었다. 2008년에는 Jim Grey Sort Benchmark에서 900대의 클러스터로 1TB의 데이터를 209초로 끝냄으로써 종전 기록(297초)을 88초 정도 앞당겨 우승했다. 2009년에는 4,000대의 클러스터를 구성해서 1TB, 1PB의 데이터를 각각 62초, 16.25시간 만에 끝내서 역시 우승을 차지했다. 다음은 2009년 Sort 테스트에 대한 요약 정보다.

하둡 사용 현황

야후는 하둡 프로젝트의 주요 후원자이자 가장 활발하게 하둡을 사용하고 있다.

야후는 2만대의 서버에 하둡을 설치해 사용하고 있고, 가장 큰 단일 클러스터는 약 4,000대 규모다. 여러 분야의 연구 개발 및 서비스용으로 사용하고 있다. 대표적으로 WebMap이라는 그래프 기반 검색엔진이있다. WebMap은 알려진 웹 페이지들의 모든 edge 및 링크 정보를 계산해 그 결과를 다양한 검색 애플리케이션에서 사용할 수 있도록 해주는 거대한 그래프라고 할 수 있다. WebMap에서는 주기적으로 100개 이상의 MapReduce 작업들을 체인 형태로 묶어 실행시키는데, 출력 결과만 압축해서 300TB 이상이 나올 정도로 대용량 데이터를 다루고 있다.

국내에서는 NHN과 다음 등 인터넷 포털과 삼성SDS, SK 등의 IT 서비스 회사들에서 대용량 데이터 분석 등 다양한 목적으로 하둡을 사용하고 있다. 

2. 병렬 쿼리 시스템

구글이나 하둡의 MapReduce는 개발자들에게 구현하려는 알고리즘에만 포커싱할 수 있도록 간단한 프로그래밍 모델을 제공하였다. 비록 간단한 프로그래밍 모델이지만 일부 사용자들에게는 새로운 개념이기 때문에 여전히 쉽지 않다. 또한 직접 코딩하지 않고도 쉽고 빠르게 서비스나 알고리즘을 구현하고 적용해 볼 수 있는 환경에 대한 필요성이 대두되었다. 이러한 요구사항을 반영해서 스크립트나 사용자에게 친숙한 쿼리 인터페이스를 통해 병렬 처리할 수 있는 시스템이 개발됐다. 구글의 Sawzall, 야후의 Pig 등은 이러한 MapReduce 시스템을 사용자가 쉽게 사용할 수 있도록 새로운 쿼리 언어로 추상화한 시스템들이다.

가. 구글 Sawzall

sAWZALL은 MapReduce를 추상화한 스크립트 형태의 병렬 프로그래밍 언어다. Sawzall은 사용자가 이해하기 쉬운 인터페이스를 제공하여 MapReduce 개발 생산성을 높였다. 이로써 MapReduce에 대한 이해가 없는 사용자들도 더욱 쉽게 병렬 프로그래밍을 할 수 있게 되었다. 사용현황을 보면 2005년에 1,500개의 제온 CPU로 구성된 클러스터에서 3만 2,850개의 Sawzall 작업들이 실행되었고, 하나의 작업은 보통 220대의 머신 위에서 동작하였다. 개발 후 1년 정도가 지난 시점이었지만 활발하게 사용되고 있다. 현재 구글 전체적으로 MapReduce 작업의 약 30%가 Sawzall 작업이다. Sawzall은 MapReduce를 추상화한 최초의 병렬 쿼리 언어이고, 이후에 나온 오픈소스 프로젝트인 Pig나 하이브(Hive)도 개발 배경과 기본적인 개념은 Sawzall과 유사하다.

나. 아파치 Pig

Pig는 야후에서 개발해 오픈소스 프로젝트화한 데이터 처리를 위한 고차원 언어다. Hadoop MapReduce위에서 동작하는 추상화된 병렬 처리 언어이며 현재 아파치 하둡의 서브 프로젝트다. 2007년 개발을 시작한 이후 최근까지 2~10배 정도 성능이 개선되었으며, 네이티브 MapReduce와 비교한 성능은 90% 수준이다. 야후에서는 전체 MapReduce 작업의 약 30%를 Pig를 사용한다.

개발 동기

MapReduce는 Map과 Reduce 두 단계로 이루어진 단순한 병렬 모델이다. 실제 대부분의 업무는 한 번의 MapReduce 작업으로 끝나는 것이 아니다. Map의 Output이 또 다른 Map의 Input으로 들어가야 하고, Reduce의 Output이 다른 Map의 Input으로 들어가야 하는 Chaining이 되어야 하고, MapReduce 자체적으로는 지원하기가 어려웠다.

그리고 MapReduce 작업 자체가 단순한 모델이라서 개발자들이 유사한 알고리즘들을 중복 개발하는 경우가 많다. 하지만 코드의 특성상 의미 파악이 어려울 수 있어서 공유는 잘 되지 않는 실정이었다. 이러한 요구 사항을 해결하기 위해 의미적으로는 SQL과 비슷하지만 새로운 언어인 Pig를 정의하게 되었다.

사용예제

18~25세 연령대의 사용자가 가장 많이 방문하는 사이트 5개를 찾고자 할 경우 그림과 같은 과정을 거친다.

MapReduce는 기본적으로 무공유 구조이기 때문에 일반 RDB로는 쉽게 해결할 수 있는 Join 연산이 매우 복잡해진다. 위 문제를 해결하기 위해 개발자는 약 400라인에 가까운 코드를 아래처럼 프로그래밍 해야  한다.

위의 예제를 Pig로 처리하며, 아래 10라인으로 간단하게 해결할 수 있다.

코드의 길이는 1/20이하로 개발 시간도 1/10이하로 감소하며, 프로그래밍 코드도 더 이해하기 쉽고 직관적이어서 공유하기도 편하다.

사용현황

야후 내부의 검색 인프라, 광고 연관성 분석, 사용자 의도 분석, 검색엔진 쿼리 분석, Hoffman's PLSI 등 다양한 분야에서 사용되고 있다.

다. 아파치 하이브

하이브는 페이스북에서 개발한 데이터 웨어하우징 인프라다. Pig와 마찬가지로 하둡 플랫폼 위에서 동작하며, 사용자가 쉽게 사용할 수 있도록 SQL, 기반의 쿼리 언어와 JDBC를 지원한다. 또한 하둡에서 많이 사용되는 병렬처리 기능인 Hadoop-Streaming을 쿼리 내부에 삽입해 사용할 수 있다. 사용자에게 사용 편의성과 성능을 동시에 지원하려 노력한 시도로 보인다. 현재 아파치 내 하둡 서브 프로젝트로 등록돼 개발되고 있다.

개발 배경

페이스북은 사용 DBMS 기반의 데이터 웨어하우스 시스템을 운영하고 있었다. 운영 초기에 데이터는 10GB 정도였지만 시간이 지나면서 수백TB 규모로 늘어났고, 라이선스 등 관리 및 운영비용의 절감의 필요성이 대두되었다. 이에따라 상용 DBMS에서 하둡으로 교체를 결정했으며 교체과정에서 필요한 기능들, 사용자를 위한 커맨드 라인 인터페이스(CLI), 코딩 없이 애드훅(Ad-hoc) 질의를 할 수 있는 기능, 스키마 정보들의 관리 기능들을 하나씩 구현하면서 지금의 하이브라는 시스템이 만들어졌다.

PB이상의 압축된 데이터를 관리하고 있다. 일일 데이터 처리량은 수십 PB정도이며 동시에 수천 건 이상의 애드훅 분석 쿼리 작업을 수행하고 있다. 

하이브 아키텍처

하이브의 구성요소 중에서 MetaStore는 Raw File들의 콘텐츠를 일종의 테이블의 컬럼처럼 구조화된 (Structured) 형태로 관리할 수 있게 해주는 스키마 저장소다. 별도의 DBMS를 설정하지 않으면 Embedded Derby를 기본 데이터 베이스로 사용한다. 앞 단에는 커맨드 라인 인터페이스(CLI)가 있는데 사용자는 이 CLI를 통해 Join이나 Group by 같은 SQL 쿼리를 한다. 그러면 파서(Parser)에서 쿼리를 받아 구문 분석을 하고, MetaStore에서 테이블과 파티션 정보를 참조해 Execution Plan을 만들어 낸다. 만들어진 이 Plan을 Execution Engine에 보낸다. Execution Engine은 하둡의 JobTracker와 네임노드와 통신을 담당하는 창구 역할을 하면서 MapReduce 작업을 실행하고 파일을 관리한다.아래 그림 오른쪽 하단의 SerDe라는 것은 Serializer와 Deserializer의 줄임말이며, 테이블의 로우나 컬럼의 구분자 등 저장 포맷을 정의해주는 컴포넌트다. 하둡의 InputFormat과 OutputFormat에 해당한다고 볼 수 있다.

하이브에서는 아래와 같은 언어 모델을 제공한다.

DDL(Data Definition Language)

 - 테이블 생성(Create Table), 삭제(Drop Table), 변경(Rename Table) 명령

 - 테이블 스키마 변경(Alter Table, Add Column)

 - 테이블 조회(Show Table), 스키마 조회(Describe Table)

DML(Data Manipulation Language)

 - 로컬에서 DFS로 데이터 업로드(LOAD DATA)

 - 쿼리 결과를 테이블이나 로컬 파일시스템, DFS에 저장

Query

 - Select, Group by, Sort by, Joins, Union, Sub Queries, Sampling, Transform

3. SQL on Hadoop

앞서 설명한 하둡과 하이브는 대용량 데이터를 배치 처리하는 데 최적화 되어 있지만, 실제 업무에서는 배치 처리뿐만 아니라, 데이터를 실시간으로 조회하거나 처리해야 하는 일들이 많다. 실시간 처리라는 측면에서 하둡의 제약사항을 극복하기 위한 다양한 시도가 있었으며, 이 중에 최근 주목 받고 있는 것이 SQL on hadoop이라는 실시간 SQL 질의 분석 기술이다. 이 기술은 하둡상에 저장된 대용량 데이터를 대화형식의 SQL 질의를 통해서 처리하고 분석하며, 가장 많이 회자되고 있는 기술인 임팔라를 살펴보고자 한다.

가. 임팔라 개요

SQL on Hadoop 기술 중 먼저 대중에게 공개된 기술이 임팔라다. 임팔라를 제작한 클라우데라(Cloudera)는 드레멜(Dremel)의 논문 'Interactive Analysis of Web-Scale Datasets'를 읽은 후 하둡 상에서 실시간, 애드혹 질의가 가능할 것 같다는 기술적 영감을 얻어서 개발을 시작했다. 이후 2012년 10월에 시험(Proof of Concept) 버전을 공개했으며, 2013년 5월에 정식 버전(1.0)을 배포했다. 임팔라는 분석과 트랜잭션 처리를 모두 지원하는 것을 목표로 만들어진 SQL 질의 엔진이다. 하둡과 Hbase에 저장된 데이터를 대상으로 SQL 질의를 할 수 있다 고성능을 낼 수 있도록 자바 대신 C++ 언어를 이용하였으며, 맵리듀스를 사용하지 않고 실행 중에 최적화된 코드를 생성해 데이터를 처리한다.

나. 임팔라 동작 방식

모든 노드에 임팔라 데몬이 구동되며, 사용자는 이 데몬들이 구동된 임의의 노드에 JDBC나 ODBC 또는 임팔라셸을 이용하여 질의를 요청할 수 있다. 그러면 사용자의 질의는 데이터의 지역성을 고려해서 노드 전체로 분산되어서 수행된다. 하둡에서 잡트랙커(JobTracker)가 데이터 지역성을 고려해서 태스크를 태스크트랙커트랙커(TaskTracker)에게 할당하는 것과 유사한 방식이다. 사용자의 질의 요청을 받은 코디네이터 데몬은 분산되어 수행된 각 임팔라 노드들의 부분 결과들을 취합하여 결과 값을 만들어서 사용자에게 제공한다. 

실제 운영 환경에서는 라운드로빈 방식으로 사용자 질의를 분산시켜서 전 노드들이 질의에 대해 코디네이터역할을 고르게 수행할 수 있도록 해야 한다.

다. 임팔라의 SQL 구문

임파라는 기본적으로 하이브의 SQL을 이용한다. 하지만 임팔라가 모든 하이브 SQL문을 지원하는 것은 아니기 때문에 어떤 구문이 지원되는지 확인할 필요가 있다. 현재 버전의 임팔라에서 지원하는 주요 SQL구문과 기능은 다음과 같다.

라. 임팔라의 데이터 모델

임팔라는 하둡 분산 파일 시스템에 데이터를 저장한다. 어떤 저장 포맷을 사용하느냐에 따라 데이터 조회시 처리 성능이 달라진다. 하둡의 기본 파일 포맷인 텍스트나 시퀀스 파일은 로우 단위의 데이터 저장 방식을 사용한다. 컬럼 단위의 파일 저장 포맷인 RCFile을 사용할 경우, 데이터 처리 과정에서 발생하는 디스크 입출력 양을 현저하게 줄일 수 있다. 로우 단위로 저장 시, 테이블에서 하나의 컬럼을 읽든 전체 테이블을 읽든 전체 테이블을 읽든 동일한 디스크 입출력이 발생한다. 반면 컬럼 단위의 저장 포맷을 사용하면,  읽고자 하는 컬럼 만큼의 디스크 입출력이 발생하기 때문에 처리 성능을 개선할 수 있다. 물론 전체 컬럼들을 모두 조회하는 질의는 저장 포맷에 의해 성능이 영향을 받지 않는다.

테스트 결과를 따르면, 컬럼 파일 포맷을 사용했을 때 처리 시간이 덜 걸린다. 적은 수의 컬럼을 읽을 수록 훨씬 빠른 처리 성능을 보여주고 있다. 반면 기존 방식인 로우 파일 포맷을 사용해 레코드를 읽을 때는 하나의 컬럼에 접근해도 항상 전체를 읽는 것과 같은 처리 시간을 보여주고 있다. 컬럼 파일 포맷을 사용하는 것이 효율적임이 증명된 셈이다. 다만 하둡에 저장된 파일이 처음부터 컬럼 파일 포맷을 사용하지 않았을 경우, 파일 포맷 변경 작업을 해주어야 한다.

제3절 클라우드 인프라 기술

클라우드 컴퓨팅은 동적으로 확장할 수 있는 가상화 자원들을 인터넷으로 서비스 할 수 있는 기술을 말한다. 이러한 클라우드 서비스들은 SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastrcure as a Service) 등 크게 3가지 유형으로 나뉜다. VMware나 Xen과 같은 서버 가상화 기술은 데이터센터나 기업들에게 인프라스트럭처를 위한 클라우드 서비스의 가능성을 보여주고 있다. 아마존은 S3(Simple Storage Service)와 EC2(Elastice Cloud Computing) 환경을 제공함으로써 플랫폼을 위한 클라우드 서비스를 최초로 실현해왔다. 또한 구글은 AppEngine, Apps, Gears, Gadgets 등을 제공함으로써 명실공히 웹 기반의 다양한 소프트웨어들이 클라우드 서비스로서 어떻게 구체화될 수 있는지를 보여주고 있다.

클라우드 컴퓨팅에서 인프라 기술은 근간이 되는 기술이며, 인프라 기술들 중에서도 가장 기반이 되는 기술이라고 할 수 있는 서버 가상화 기술은 물리적인 서버와 운영체제 사이에 적절한 계층을 추가해 서버를 사용하는 사용자에게 물리적인 자원은 숨기고 논리적인 자원만을 보여주는 기술을 말한다. 서버 가상화는 하나의 서버에서 여러 개의 애플리케이션, 미들웨어, 운영체제들이 서로 영향을 미치지 않으면서 동시에 사용할 수 있도록 해준다.. 서버 가상화를 가능하게 하는 기술은 아주 다양하며 메인프레임, 유닉스 서버, x86 서버 등에 따라 서로 다른 기술이나 분류체계가 사용된다. 클라우드 컴퓨팅 환경에서 많이 사용되는 서버가 x86계열이기 때문에 여기서는 x86 서버 가상화 기술만을 다룬다. x86 계열 서버 군의 가장 큰 특징은 하드웨어, CPU, 운영체제의 공급 업체가 모두 다르다는 것이다. 이런 환경 때문에 가상화 기술도 업체에 따라 제공되는 수준이 아주 다양하다. 인텔, AMD 등과 같은 CPU 제공업체는 하드웨어 차원의 CPU 가상화를 주로 다루며, VMware나 마이크로소프트, 오픈소스 커뮤니티에서는 소프트웨어 기반의 가상화 제품을 내놓고 있다. 따라서 x86 서버의 가상화 기술은 하나의 업체만으로 설명할 수 없으며, 다른 업체와에 대한 관계를 나타내는 것이다. 그림에서 Hypervisor 계층에 있는 세부 분류는 최근 솔루션 제공업체에 의해 그 경계가 점점 사라지고 있다. 

서버 가상화 기술을 이용할 경우 얻을 수 있는 효과는 다음과 같다. 

가상머신 사이의 데이터 보호

하나의 물리적 서버에서 운영중인 서로 다른 가상 머신들 사이의 접속은 정상적인 네트워크 접속만을 허용한다. 가상머신 사이에는 보안적으로 서로 분리돼 데이터를 보호 받을 수 있다. 

예측하지 못한 장애로부터 보호

가상머신에서 수행중인 애플리케이션의 장애가 다른 가상머신에는 전혀 영향을 미치지 않는다. 애플리케이션, 운영체제의 장애로부터 보호 받을 수 있다.

공유 자원에 대한 강제 사용의 거부

하나의 가상머신은 할당된 자원 이상을 가져가는 것을 차단할 수 있다. 이런 기능을 통해 다른 가상머신에 할당된 자원의 부족 현상을 차단할 수 있다. 예를 들어, 하나의 가상머신의 I/O 병목 현상이 발생해도 다른 가상머신에서 I/O 병목 현상이 발생하지 않는다.

서버 통합

서버 가상화를 통해 얻을 수 있는 가장 일반적인 효과이다. 서비스, 데이터, 사용자 등의 증가로 더 많은 컴퓨팅 자원이 필요해졌지만 데이터 센터의 공간, 전원, 냉각장치는 제한적이다. 이런 문제를 해결하기 위해 기존 서버의 용량을 증설하고 가상머신을 추가함으로써 동일한 데이터센터의 물리적 자원(공간, 전원 등)을 이용하면서 더 많은 서버를 운영할 수 있다.

자원 할당에 대한 증가된 유연성

수시로 변화하는 각 가상머신의 자원 요구량에 맞추어 전체 시스템 자원을 재배치함으로써 자원 활용도를 극대와 할 수 있다.

테스팅

다양한 운영체제나 운영환경에서 테스트가 필요한 경우, 새로운 서버를 추가하지 않아도 테스트 환경을 구성할 수 있다. 부하 테스트가 필요한 경우에도 일시적으로 자원을 줄이는 방법으로 부하 상황을 만들 수 있으며, 다수의 부하 생성 역할을 수행하는 노드도 쉽게 추가할 수 있다.

정확하고 안전한 서버 사이징

필요한 자원만큼만 가상머신을 할당할 수 있으며, 사이징 예측이 불확실한 서버를 구성할 때에도 일단 확보된 리소스를 이용하여 할당한 후 쉽게 추가로 할당할 수 있다.

시스템 관리

마이그레이션 기능을 이용할 경우 운영 중인 가상머신의 중지 없이 가상머신을 다른 물리적인 서버로 이동시킬 수 있다. 이런 기능을 이용하여 다음과 같은 업무를 쉽게 수행할 수 있다.

 - 하드웨어 장애: 서버에 물리적으로 구성된 여러 디스크 중 1개의 디스크에 장애가 발생했을 때, 장애 발생 장비에서 운영되던 가상머신을 서비스 중지 없이 다른 장비로 이동한 후 장애가 발생한 장비의 디스크를 교체한 후 다시 서비스에 투입할 수 있다.

 - 로드 밸런싱: 특정 가상 서버나 가상 서버가 수행중인 물리적인 서버에 부하가 집중되는 경우 여유있는 서버로 가상머신을 이동시킨다.

 - 업그레이드 : 장비의 CPU 추가나 메모리 추가, 디스크 증설 등과 같은 작업이 필요한 경우 다른 장비로 가상머신을 이동시킨 후 업그레이드 작업을 수행할 수 있다.

가. CPU 가상화

하이퍼바이저(Hypervisor)는 물리적 서버 위에 존재하는 가상화 레이어를 통해 운영체제가 수행하는데 필요한 하드웨어 환경을 가상으로 만들어 준다. 엄격하게 구분할 경우에는 차이가 있지만, 일반적으로 가상머신(Virtual machine)을 하이퍼바이저라고 할 수 있다. 하이퍼바이저가 서버 가상화 기술의 핵심으로 x86계열 서버 가상화에서는 소프트웨어 기반으로 하이퍼바이저를 구성한다. 하이퍼바이저를 통해 사용자는 추가 하드웨어 구입 없이 새로운 운영체제의 설치, 애플리케이션의 테스팅 및 업그레이드를 동일한 물리적 서버에서 동시에 수행할 수 있다.

하이퍼바이저는 VMM(Virtual Machine Monitor) 이라고도 하며, 다음과 같은 기능을 수행한다.

하드웨어 환경 에뮬레이션

실행환경 격리

시스템 자원 할당

소프트웨어 스택 보존

하이퍼바이저와 관련된 기술을 분류하는 방법은 여러 가지가 있다. 

플랫폼 별로 : 

x86 계열에는 VMware, MS Virual Server, Xen 등이 있다.

유닉스 계열 IBM의 POWER Hypervisor 등이 있다.

메인프레임 계열로는 z/VM과 하드웨어 펌웨어로 분류되는 PR/SM 등이 있다. 이 문서에서는 일반적으로 많이 통용되는 방식인 가상화를 제공하는 하이퍼바이저의 위치아 기능에 따라 분류한다. 가상화를 제공하는 하이퍼바이저가 물리적인 하드웨어 또는 호스트 운영체제와의 관계에서 어디에서 위치하는지에 따라 베어메탈(Bare-metal) 하이퍼바이저와 호스트 기반(Hosted) 하이퍼바이저로 나뉠 수 있다.

베어메탈 하이퍼바이저는 하드웨어와 호스트 운영체제 사이에 위치하며, 호스트 기반 하이퍼바이저는 호스트 운영체제와 게스트 운영체제 사이에 위치한다.

베어메탈 하이퍼바이저는 다시 반가상화(Para Virtualization)과 완전가상화(Full Virtualization)로 구분할 수 있다. 다음 그림은 하이퍼바이저 가상화 기술에 대한 분류를 나타낸다.

최근에는 하이퍼바이저를 제공하는 소프트웨어 벤더들이 다양한 가상화 기법을 도입하고 있으며, CPU 제조업체에서도 하드웨어에서 가상화 기술을 지원하는 등 새로운 가상화 방법이 계속 나오고 있기 때문에 서버 가상화 기술을 정확하게 분류하기는 힘들다.

X86 계열 운영체제는 자신의 모든 하드웨어에 대한 제어 소유권을 갖고 있다는 가정 아래 하드웨어에 직접 명령을 수행하는 방식으로 디자인돼 있다. x86 아키텍처는 하드웨어에 대한 접근 권한을 관리하기 위해 Ring 0, 1, 2, 3, 등 4개의 레벨로 구성돼 있다. 일반적으로 사용자 애플리케이션은 Ring 3 레벨로 수행되며, 운영체제의 경우 메모리나 하드웨어에 직접 접근해야 하기 때문에 Ring 0 레벨에서 수행된다.

가상 머신 내에서도 운영체제가 필요하고 이 운영체제는 Ring 0의 권한을 필요로 하게 된다. 가상머신의 운영체제가 응용 애플리케이션 권한(Ring 3)으로 수행될 경우 x86 아키텍처에서는 복잡한 문제가 발생한다. Ring 3에서 수행된 가상머신 운영체제에서 Ring 0 수준의 명령을 호출하면 가상화를 지원하는 계층에서 이를 Ring 0 수준의 명령어로 다시 변환해 실행해야 하며, 이를 위해 가상화 지원 계층은 반드시 Ring 0 레벨 (Intel VT-x, AMD-V에서는 Ring -1)로 수행되어야 한다. x86 아키텍처에서 가상화 기술의 핵심은 가상머신이 요청하는 privileged 명령어를 어떻게, 어떤 계층에서 처리 하느냐이다. 가상화의 용어 중 완전 가상화(Full Virtaulization), 반가상화(Para Virtualization)라는 용어도 privileged 명령어를 어떻게 처리하느냐를 기준으로 분류한 것이다.

완전가상화

완전가상화는 CPU뿐만 아니라 메모리, 네트워크 장치 등 모든 자원을 하이퍼바이저가 직접 제어 관리하기 때문에 어떤 운영체제라도 수정하지 않고 설치가 가능한 장점이 있다. 하지만 하이퍼바이저가 자원을 직접 제어하기 때문에 성능에 영향을 미친다. 또한 자원들이 하이퍼바이저에 너무 밀접하게 연관돼있어 운영중인 게스트 운영체제에 할당된 CPU나 메모리 등의 자원에 대한 동적변경 작업이 단일 서버 내에서는 어렵다. 자원에 대한 동적변경을 하기 위해서는 VMware의 VMotion과 같은 솔루션의 도움을 받아야 한다.

완전가상화는 하이퍼바이저보다 우선순위가 낮은 가상머신에서는 실행되지 않는 privileged 명렁어에 대해서 trap을 발생시켜 하이퍼바이저에서 실행하는 방식으로, MS 윈도우와 같은 Guest OS가 하이퍼바이저 상에서 변경되지 않은 상태로 실행될 수 있는 장점이 있으나 Para Virtualization에 비해 속도가 느리다. VMware ESX server, MS Virtual Server 등의 제품이 완전가상화 기반 솔루션이다.

초기 Xen 에서는 완전가상화를 지원하지 않았지만, 최근 Intel VT, AMD- V 환경에서 완전가상화를 지원하고 있다.

하드웨어 지원 완전가상화

최근에는 완전가상화 방식에서 Intel VT-x, AMD-V CPU의 하드웨어에서 제공하는 가상화 기능을 이용하고 있다. 가상머신에서 메모리와 CPU 등의 하드웨어에 명령을 내릴 수 있는 반가상화 수준의성능을 발휘하도록 개선하고 있는 것이다.

CPU에 Ring-1 계층이 추가되었으며, 하이퍼바이저는 Ring-1 에서 수행되고 가상머신의 운영체제(Guest OS)는 Ring 0 에서 수행되어 privileged 명령어에 대해 추가로 변환 과정이 필요 없다. 하이퍼바이저를 거쳐 바로 하드웨어로 명령이 전달돼 빠른 성능을 보장한다. 윈도우 2008 서버의 Hyper-V는 반드시 가상화 지원 CPU만을 사용해야 한다.

인텔에서는 하드웨어 지원 가상화를 사용할 때 다음과 같은 점을 주의해야한다고 밝히고 있다.

하드웨어 지원 가상화를 사용하는 경우 CPU 사용률이 높아진다. 따라서 서버 통합을 목적으로 하는 경우 비효율적 일수도 있다.

인텔에서는 반가상화와 하드웨어 지원 완전가상화를 모두 사용하는 하이브리드 가상화를 제시하고 있다. Xen을 이용한 하이브리드 가상화의 경우, 반가상화용으로 수정된 운영체제에 하드웨어 지원 완전 가상화 모듈을 탑재해 명령어의 종류애 따라 반가상화 또는 완전가상화를 선택 사용하도록 한다.

반가상화

반가상화는 privileged 명령어를 게스트 운영제에서 hypercall로 하이퍼바이저에 전달하고, 하이퍼바이저는 hypercall에 대해서는 privilege 레벨에 상관없이 하드웨어로 명령을 수행시킨다. Hypercall은 게스트 운영체제에서 요청을 하면 하이퍼바이저에서 바로 하드웨어 명령을 실행하는 call을 말한다. 게스트 운영체제가 hypercall을 요청하기 위해서는 게스트 운영체제의 일부분이 수정 되어야 하며, Xen 기반의 리눅스 운영체제의 경우 20%정도 커널이 수정되었다고 한다. 수정된 게스트 운영체제는 CPU나 메모리와 같은 자원에 대한 직접적인 제어권을 가짐으로써 자원의 변화와 같은 동적 가상화 환경에 유연하게 적응할 수 있다. 따라서 반가상화 기반에는 CPU와 메모리 자원의 동적 변경이 서비스의 중단 없이 이루어 질 수 있으며, 완전가상화에 비해 성능이 뛰어나다. 반가상화는 privileged 명령어를 직접 호출(hypercall)하므로 속도는 빠르나 커널을 변경해야 하고, 완전가상화는 모듈과의 통신을 통해 처리하므로 속도는 느리나 커널 변경이 없다. VMware와 같은 상용 솔루션은 완전가상화와 반가상화의 장단점을 보완해 아키텍처, 기능, 성능 등에서 뚜렷한 차이가 없다.

기존 VMware에서는 반가상화를 지원하지 않았지만 VMI(Virtual Machine Interface)라는 표준 인터페이스를 제시하고, 이 인터페이스를 준수하는 모든 게스트 운영체제를 지원하는 방식으로 반가상화를 지원하고 있다. VMI는 아직 정식 표준으로 채택되지 않았지만 리눅스 진영에서도 도입하려는 움직임이 나타나고 있다.

Monolithic vs. Microkernel

하드웨어에 대한 드라이버가 어느 계층에 있느냐에 따라 Monolithic 방식과 Microkernel 방식으로 구분할 수 있다. 가상머신이 I/O를 위해 하드웨어에 접근할 때 사용하는 드라이버를 하이퍼바이저 계층에서 모두 갖고 있는 방식을 Monolithic이라고 한다. 각 가상머신에서 드라이버를 갖는 방식을 Microkernel이라고 한다. VMware의 경우 하이퍼바이저가 드라이버를 갖고 있으며 모든 I/O 요청은 하이퍼바이저가 수행함을 보여준다. Xen에서 하이퍼바이저는 드라이버가 없으며 호스트 운영체제가 드라이버를 가지고 있고 각 게스트 운영체제는 가상 드라이버를 가지고 있어 I/O 요청을 위해서는 호스트 운영체제를 거쳐야 한다. 게스트와 호스트 운영체제는 서로 격리되어 있기 때문에 하이퍼바이저(또는 VMBus)를 이용해 요청을 주고 받는다.

Monolithic 방식은 성능은 조금 향상될 수 있지만 하이퍼바이저에서 모든 드라이버를 가지고 있어야 하기 때문에 하드웨어가 추가되거나 드라이버가 업데이트 되는 경우 하이퍼바이저가 수정되어야 하고 더 많은 코드를 가지고 있기 때문에 장애가 발생할 가능성도 높다. Microkernel 방식의 경우 속도는 조금 느려지지만 하이퍼바이저 계층이 간단하여 드라이버 업데이트나 하드웨어 추가에 따른 하이퍼바이저 변경이 필요 없으며 장애 발생 확률이 훨씬 낮다.

호스트 기반 가상화

호스트 기반 가상화는 완전한 운영체제가 설치되고 가상화를 담당하는 하이퍼바이저가 호스트 운영체제 위에 탑재되는 방식이다. 이 방식은 다른 가상화 환경에 비해 성능은 물론 자원 관리 능력 측면에서도 제약 사항이 많은 편이다. 가장 큰 단점은 단일 운영체제의 취약성에 있다. 예를 들어 호스트 운영체제 레벨에서 보안 이슈가 발생할 경우 전체 게스트 운영체제의 신리성에도 문제가 발생할 수 있다. 호스트 기반가상화의 대표사례로는 VMware Workstation, Microsoft Virtual PC 등이 있다.

주로 테스트 환경에서 많이 사용되었으며 최근에는 많이 사용하지 않는다. 하지만 기존 레거시 애플리케이션 중 아주 오래된 하드웨어와 그 하드웨어를 지원하는 특정 운영체제에서만 수행되어야 하는 애플리케이션을 가상화 기반에서 운영하는 경우에 사용할 수 있다.

컨테이너 기반 가상화

컨테이너 기반 가상화는 호스트 운영체제 위에 가상의 운영체제를 구성하기 위한 운영 환경 계층을 추가하여 운영체제만을 가상화한 방식이다. 운영체제만을 가상화 대상으로 하므로 전체 하드웨어를 대상으로 하는 하이퍼바이저 기반 가상화 방식에 비해 훨씬 적게 가상화한다. 결과적으로 한 대의 서버에서 더 많은 컨테이너를 실행할 수 있다. 컨테이너 기반 가상화 방식에서 가상화를 지원하는 계층을 하이퍼바이저라고 하지 않으며, 가상 운영환경이라고 부른다.

컨테이너 기반 가상화는 가상화 수준이 낮기 때문에 다른 방식에 비해 빠른 성능을 보여주지만, 자원간 격리 수준이 낮아 하나의 가상 운영체제에서 실행되는 애플리케이션의 자원 사용에 따라 다른 가상 운영체제가 영향을 받는 단점이 있다.

또한 호스트 운영체제의 보안 취약성에 의해 모든 가상 운영체제에 문제가 발생할 수 있으며, 호스트 운영체제를 공유하기 때문에 호스트 운영체제의 문제가 전체 가상 운영체제에도 영향을 미치게 된다.

컨테이너 기반 가상화는 오픈소스 진영의 OpenVZ를 상용화한 Virtuozzo, Solaris Containers, Linux-Vserver 등 여러 솔루션이 있다.

나. 메모리 가상화

본 문서에서 설명하는 메모리 가상화는 VMware의 기법이다

운영체제는 메모리를 관리하기 위해 물리주소와 가상주소, 이 두가지를 사용하고 있다. 물리주소는 0부터 시작해서 실제 물리적인 메모리 크기까지를 나타내고, 가상주소는 하나의 프로세스가 가리키리 수 있는 최대 크기를 의미하며 32비트 운영체제에서는 4GB까지 가능하다. 32비트 운영체제에서 수행되는 각각의 사용자 프로세스는 4GB까지 사용가능하며, 프로그램에서의 주소는 물리적인 메모리의 주소 값이 아닌 가상주소 값이다. 따라서 가상주소 값의 위치(VPN, Virtual Page Number)를 실제 물리적인 주소 값 위치(MPN, Machine Page Number)로 매핑 과정이 필요하며, page table을 이용한다.

매핑 연산을 하드웨어적으로 도와주는 것을 TLB(Translation lookaside buffer)라고 한다.

VMware의 하이퍼바이저의 핵심 모듈을 VMKernel이라고 한다. VMkernel은 Service Console, 디바이스 드라이버들의 메모리 영역을 제외한 나머지 전체 메모리 영역을 모두 관리하면서 가상머신에 메모리를 할당 한다. 생성되는 가상머신은 자신에게 할당된 메모리들을 연속된 공간의 실제 물리적인 메모리로 인식하게 된다.

VMware는 하이퍼바이저 내에 Shadow Page Table을 별도로 두어 가상 메모리 주소와 물리 메모리 주소의 중간 변환 과정을 가로챈ㄷ나. 이 테이블은 마치 연속된 빈 공간의 메모리가 실제 존재하는 것처럼 게스트 운영체제에게 매핑해주는 역할을 하며, 동시에 개별적인 모든 가상머신들이 자신만의 메모리 주소 공간을 갖도록 한다.