[ADP] 2-2 데이터 처리 기술

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

대규모 클러스터 시스템 플랫폼은 네트워크상에 분산된 서버들을 클러스터링함으로써 대용량 저장 공간과 빠른 처리 성능을 제공함. 분산 데이터 저장 기술은 네트워크상에서 데이터를 저장/조회/관리할 수 있으며, 저장 데이터를 정형화 여부와 데이터 모델에 따라 분산 파일시스템과 클러스터 데이터베이스, Key-Value 저장소 정도로 구분할 수 있음.

1. 분산 파일 시스템

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

가. 구글 파일 시스템

구글 파일 시스템은 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 파일 시스템으로 개발됨.

• 저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정.
• 대부분의 파일은 대용량이라고 가정. 따라서 대용량 파일을 효과적으로 관리할 수 있는 방법이 요구됨.
• 작업 부하는 주로 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산.
• 파일에 대한 쓰기 연산은 주로 순차적으로 데이터를 추가하며, 파일에 대한 갱신은 드물게 이루어짐.
• 여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화할 수 있는 방법이 요구됨.
• 낮은 응답 지연시간보다 높은 처리율이 보다 중요함.

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

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

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

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

나. 하둡 분산 파일 시스템

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

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

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

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

다. 러스터

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

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

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

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

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

구분	GFS	하둡 DFS	러스터
Open Source	지원	지원	지원
Chink based	지원	지원	미지원
Support Replication	지원	지원	미지원
Multiple metadata server supported	미지원	미지원	미지원
Locks used to maintain atomicity	지원	지원	지원
Uses a DB for storing metadata	미지원	미지원	미지원
Adding nodes withou shutting down the system	지원	지원	지원
POSIX support	미지원	미지원	지원
Supports file modification	미지원	미지원	지원

[표 II-2-1] 클러스터 파일 시스템 비교

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

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

• 파티션 사이의 병렬 처리를 통한 빠른 데이터 검색 및 처리 성능을 얻을 수 있음.
• 성능의 선형적인 증가 효과를 볼 수 있음.
• 특정 파티션에서 장애가 발생하더라도 서비스가 중단되지 않는 고가용성을 확보할 수 있음.

데이터베이스 시스템을 구성하는 형태에 따라 1) 단일 서버 내의 파티셔닝과 2) 다중 서버 사이의 파티셔닝으로 구분할 수 있음.

리소스 공유 관점에서는 다시 1) 공유 디스크(Shared Disk)와 2) 무공유(Shared Nothing)로 구분 할 수 있음.

1) 무공유

• 무공유 클러스터에서 각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 이 파일들은 노드 간에 공유하지 않음.
• 각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유권을 갖고 있는 인스턴스가 처리함. 한 노드가 데이터 처리 요청을 받으면, 해당 노드는 처리할 데이터를 갖고 있는 노드에 신호를 보내 데이터 처리를 요청함. 무공유 구조의 장점은 노드 확장에 제한이 없는 것임. 단점은 각 노드에 장애가 발생할 경우를 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성해야 한다는 것임.
• Oracle RAC(Real Application Cluster)를 제외한 대부분의 데이터베이스 클러스터가 무공유 방식을 채택하고 있음.

2) 공유 디스크

• 공유디스크 클러스터에서 데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들과 공유하며, 각 인스턴스는 모든 데이터에 접근할 수 있음. 데이터를 공유하려면 SAN(Storage Area Network)과 같은 공유 디스크가 반드시 있어야 하며, 모든 노드가 데이터를 수정할 수 있기 때문에 노드 간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널이 필요함.
• 공유 디스크 방식의 가장 큰 장점은 높은 수준의 폴트톨러런스 제공임. 클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스가 가능하기 때문. 단점은 클러스터가 커지면 디스크 영역에서 병목 현상이 발생함. Oracle RAC가 공유 디스크 방식을 이용하고 있음.

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

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

• 가용성
  • 클러스터의 한 노드가 어떤 이유로 장애를 일으키면 Oracle RAC는 나머지 노드에서 계속 실행됨. 장애가 발생한 노드에 연결됐던 모든 응용 프로그램은 투명하게 다시 연결되어 클러스터의 나머지 노드에 분산됨.
• 확장성
  • 추가 처리 성능이 필요하면 응용 프로그램이나 데이터베이스를 수정할 필요 없이 새 노드를 클러스터에 쉽게 추가할 수 있음. 클러스터의 모든 노드 간에 균형이 유지되도록 로드가 다시 분산됨. Oracle 10g R2 RAC는 클러스터 내에 최대 100개의 노드를 지원함.
• 비용 절감
  • RAC는 표준화된 소규모(CPU 4개 미만) 저가형 사용 하드웨어의 클러스터에서도 고가의 SMP 시스템만큼 효율적으로 응용 프로그램을 실행함으로써 비용을 절감함.

나. IBM DB2 ICE(Integrated Cluster Environment)

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

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

다. 마이크로소프트 SQL Server

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

• 데이터는 관련된 서버들로 수평적으로 분할됨. 테이블을 논리적으로 분리해 물리적으로는 분산된 각 노드에 생성하고, 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNION ALL을 이용해 논리적인 뷰(VIEW)를 구성하는 방식으로 분산된 환경의 데이터에 대한 싱글 뷰를 제공함. SQL Server에서는 이런 뷰를 DVP(Distributed Partitioned View)라고 함.

• 이런 구성의 가장 큰 문제는 DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 스키마(Global schema)정보가 없기 때문에 질의 수행을 위해 모든 노드를 엑세스해야한다는 점이 있음. 노드의 개수가 작으면 간단하게 구성할 수 있지만, 노드가 많아지거나 노드의 추가/삭제가 발생하는 경우 파티션을 새로 해야 하는 문제도 있음. 또한 페일오버에 대해서는 별도로 구성해야 함. SQL Server에서도 페일오버에 대한 메커니즘을 제공하지만, Active-Active가 아닌 Active-Standby 방법을 상용하고 있음.

라. MySQL

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

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

• 관리 노드 : 클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여함
• 데이터 노드 : 클러스터의 데이터를 저장하는 노드
• MySQL 노드 : 클러스터 데이터에 접근을 지원하는 노드

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

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

3. NoSQL

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

가. 구글 빅테이블

구글을 대용량의 데이터를 저장하기 위해 빅테이블(BigTable)이라는 분산 데이터 관리 저장소를 개발함

• 데이터 모델

  빅테이블은 multi-dimension sorted hash map을 파티션하여 분산 저장하는 저장소임. 테이블 내의 모든 데이터는 row-key의 사전적 순서로 정렬/저장됨. 정렬기준은 “rowkey + columnskey + timestamp”가 됨

• 페일오버

  • 특정 노드에 장애가 발생할 경우 빅테이블의 마스턴느 장애가 발생한 노드에서 서비스되던 tablet을 다른 노드로 재할당 시킴. 재할당 받은 노드는 구글 파일 시스템(GFS)에 저장된 변경 로그 파일,인덱스 파일, 데이터 파일 등을 이용해 데이터 서비스를 위한 초기화 작업을 수행한 후 데이터 서비스를 함. 빅테이블은 공유 디스크 방식
  • 빅테이블은 분산 락 서비스를 제공하는 Chubby를 이용해 Master를 계속 모니터링하다가 장애가 발생하면 가용한 노드에 마스터 역할을 수행하도록 함

• AppEngine

  • AppEngine은 어플리케이션의 데이터 저장소를 제공하며, 내부적으로는 빅테이블을 이용함.
  • 빅테이블에서는 별도의 사용자 정의 인덱스를 제공하지 않는 반면, AppEngine에서는 사용자가 수행하는 쿼리를 분석하여 자동으로 인덱스를 생성해줌.

나. 아마존 SimpleDB

Simple는 아마존의 데이터 서비스 플랫폼임

• SimpleDB는 주로 아마존의 다른 플랫폼 서비스와 같이 사용됨. EC2, S3 등과 같은 아마존의 내부 서비스 간 네티워크 트래픽은 무료이고, 외부와의 In/Out 트래픽에는 요금을 부과하는 아마존 서비스의 가격 정책 때문
• SimpeDB는 하나의 데이터에 대해 여러 개의 복제본을 유지하는 방식으로 가용성을 높임. 이 경우 복제본 간의 consistency를 고려해야 하는데, SimpleDB에서는 “Eventual Consistency” 정책을 취함.
  • Domain : 관계형 데이터베이스의 테이블과 동일한 개념
  • Items : 관계형 데이터베이스의 레코드와 동일한 개념
  • Attibute : 관계형 데이터베이스의 컬럼과 동일한 개념

다. 마이크로소프트 SSDS

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

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

제2절 분산 컴퓨팅 기술

1. MapReduce

MapReduce는 분할정복 방식으로 대용량 데이터를 병렬로 처리할 수 있는 프로그래밍 모델이다.

MapReduce 작업은 특별한 옵션을 주지 않으면 Map Task 하나가 1개의 블록(64MB)을 대상으로 연상을 수행한다.

가. 구글 MapReduce

• 프로그래밍 모델

  MapReduce는 Map과 Reduce 2개의 단계로 나울 수 있으며 Map에서는 Key와 Value의 쌍들을 입력으로 받는다. 하나의 key, value쌍은 사용자가 정의한 Map 함수를 거치면서 다수의 새로운 key, valye쌍들로 변환되어 로컬 파일 시스템에 임시 저장된다.

  저장된 임시 파일들은 프레임워크에 의해 Reduce에게 전송된다. 이 과정에서 자동으로 Shuffling과 group by 정렬을 한 후 Reduce의 입력 레코드로 들어가게 되는데 형식은 key와 value의 리스트다. Reduce 입력 레코드들은 사용자가 정의한 Reduce 함수를 통해 최종 Output으로 산출된다.

• 실행과정

  사용자가 MapReduce 프로그램을 작성해 실행하면 마스터는 사용자의 프로그램에서 지정한 입력 데이터 소스를 가지고 스케줄링을 한다.

  하나의 큰 파일은 여러 개의 작은 파일 split들로 나뉘며, 각 split들이 Map 프로세스들의 할당 단위가 된다. Map Task들이 워커로부터 fork됨과 동시에 실행돼 Ouptu을 로컬 파일 시스템에 저장한다.

  이때 Output 값들은 Paritioner라는 Reduce 번호를 할당해 주는 클래스를 통해 어떤 Reduce에게 보내질지 정해진다.

  Map단계가 끝나면 원격으로 Reduce 워커들이 자기에 할당된 Map의 중간 값들을 네트워크로 가져, 사용자의 Reduce 로직을 실행해 최종 산출물을 얻어 낸다.

• 폴트톨러런스

  각 프로세스에서는 master에게 task 진행 상태를 주기적으로 보낸다. 마스터는 모든 워크들의 task 상태 정보를 가지고 있다가 특정 워커의 task가 더 이상 진행되지 않거나 상태 정보를 일정한 시간 동안(Heartbeat Timeout) 받지 못하면 task에 문제가 있다고 결론을 내린다.

  이후 장애 복구를 해아하는데 MapReduce는 Shared Nothing 아키텍처이기 때문에 메커니즘이 간단하다. 특정 Map이나 Reduce들이 죽은 경우, 해당 Task가 처리해야할 데이터 정보만 다른 워커에 전해 주면 워커는 받은 데이터 정보를 인자로 새로운 Task를 재실행하면 된다.

나. Hadoop MapReduce

구글의 MapReduce는 논문으로만 접할 수 있고 실제 구현은 공개되지 않았다. 아파치 오픈소스 프로젝트인 하둡의 MapReduce는 구글에서 발표한 논문을 바탕으로 자바 언어로 구현한시스템이라고 할 수 있다.

• 아키텍처

  데몬관점에서 하둡은 4개의 구성요소를 가지고 있다. 네임노드와 데이터노드는 분산 파일 시스템의 데몬들이다. JobTracker는 MapReduce 시스템의 마스터이고, TaskTracker는 워커 데몬이다. TaskTracker는 JobTracker에게 3총 ㅔ한번씩 주기적으로 하트비트를 보내 살아 있다는 것을 알린다.

• 하둡의 성능

  MapReduce에서 Sort는 어떠한 작업을 실행하더라도 Map에서 Reduce로 넘어가는 과정에서 항상 발생하는 내부적인 프로세스다. 또한 Sort 작업은 데이터가 커질수록 처리 시간이 선형적으로 증가한다. 클러스터 구성 서버들의 숫자를 늘림으로써 처리 사간을 줄일 수 있는 것은 아니다. 플랫폼 자체적으로 선형 확장성을 갖고 있어야 처리 시간을 줄일 수 있다.

2. 병렬 쿼리 시스템

가. 구글 Sawzall

Sawzall은 MapReduce를 추상화한 스크립트 형태의 병렬 프로그래밍 언어이다. Sawzall은 사용자가 이해하기 쉬운 인터페이스를 제공하여 MapReduce 개발 생산성을 높인다.

나. 아파치 Pig

Pig는 야후에서 개발해 오픈소스 프로젝트화한 데이터 처리를 위한 고차원 언어이다. Hadoop MapReduce 위에서 동작하는 추상화된 병렬 처리 언어이며 현재 아파치 하둡의 서브 프로젝트이다.

다. 아파치 하이브

하이브는 페이스북에서 개발한 데이터 웨어하우징 인프라이다. Pig와 마찬가지로 하둡 플랫폼위에 동작하며, 사용자가 쉽게 사용할 수 있도록 SQL 기반의 쿼리 언어와 JDBC를 지원한다. 또한 하둡에서 가장 많이 사용되는 병렬처리 기능인 Hadoop-STreaming을 쿼리 내부에 삽입해 사용 할 수 있다.

3. SQL on Hadoop

실시간 처리라는 측면에서 하둡의 제약사항을 극복하기 위한 다양한 시도가 있었으며, 이 중에 최근 주목 받고 있는 것이 SQL on hadoop이라하는 실시간 SQL 질의 분석 기술이다. 이 기술은 저장된 대용량 데이터를 대화형식의 SQL 질의를 통해서 처리하고 분석한다.

가. 임팔라 개요

임팔라는 분석과 트랙잭션 처리를 모두 지원하는 것을 목표로 만들어진 SQL 질의 엔진이다. 하둡과 Hbase에 저장된 데이터를 대상으로 SQL 질의를 할 수 있다. 고성능을 낼 수 있도록 자바 대신 C++ 언어를 이용하였으며, 맵리듀스를 사용하지 않고 실행 중에 최적화된 코드를 생성해 데이터를 처리한다.

나. 임팔라 동작 방식

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

다. 임팔라의 SQL 구문

임팔라는 기본적으로 하이브의 SQL을 이용한다.

라. 임팔라의 데이터 모델

임팔라는 하둡 분산 파일 시스템에 데이터를 저장한다. 어떤 저장 포맷을 사용하느냐에 따라 데이터 조회시 처리 성능이 달라진다. 하둡의 기본 파일 저장 포맷인 RCFile을 사용할 경우, 데이터 처리 과정에서 발생하는 디스크 입출력양을 현저하게 줄일 수 있다.

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

클라우드 컴퓨팅은 동적으로 확장할 수 있는 가상화 자원들을 인터넷으로 서비스할 수 있는 기술을 말한다.

서버 가상화는 사용자에게 물리적인 자원은 숨기고 논리적인 자원만을 보여주는 기술을 말한다. 서버 가상화는 하나의 서버에서 여러 개의 애플리케이션, 미들웨어, 운영체제들이 서로 영향을 미치지 않으면서 동시에 사용할 수 있도록 해준다.

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

  하나의 물리적인 서버에서 운영 중인 서로 다른 가상 머신들 사이의 접속은 정상적인 네트워크 접속만을 허용

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

  가상머신에서 수행 중인 애프리케이션의 장애가 다른 가상머신에는 전혀 영향을 미치지 않는다.

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

  하나의 가상머신은 할당된 자원 이상을 가져가는 것을 차단할 수 있다. 이런 기능을 통해 다른 가상머신에 할당된 자원의 부족 현상을 차단할 수 있다.

• 서버 통합

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

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

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

• 테스팅

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

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

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

• 시스템 관리

  마이그레이션 기능을 이용할 경우 운영 중인 가상머신의 중지 없이 가상머신을 다른 물리적인 서버로 이동시킬 수 있다.

가. CPU 가상화

하이퍼바이저(Hypervisor)는 물리적 서버 위에 존재하는 가상화 레이어를 통해 운영체제가 수행하는데 필요한 하드웨어 환경을 가상으로 만들어 준다. 하이퍼바이저를 통해 사용자는 추가 하드웨어 구입 없이 새로운 운영체제의 설치, 애플리케이션의 테스팅 및 업그레이드를 동일한 물리적인 서버에 동시에 수행할 수 있다.

• 하드웨어 환경 에뮬레이션
• 실행환경 격리
• 시스템 자원 할당
• 소프트웨어 스택 보존

하이퍼 바이저가 물리적인 하드웨어 또는 호스트 운영체제와의 관게에서 어디에 위치하는지에 따라 아래와 같이 나눌 수 있다.

• 베어메탈 하이퍼바이저 : 하드웨어와 호스트 운영체제 사이에 위치
  1. 반가상화(Para Virtualization)
  2. 완전가상화(Full Virtualization)
• 호스트 기반 하이퍼바이저 : 호스트 운영체제와 게스트 운영체제 사이에 위치

완전가상화

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

하드웨어 지원 완전가상화

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

반가상화

• 반가상화(Para Virtualization)는 privileged 명령어를 게스트 운영체제에서 hypercall로 하이퍼바이저에 전달하고, 하이퍼바이저는 hypercall에 대해서는 privilege 레벨에 상관없이 하드웨어로 명령을 수행시킨다.
• Hypercall은 게스트 운영체제에서 요청을 하면 하이퍼바이저에서 바로 하드웨어 명령을 실행하는 call을 말한다. 수정된 게스트 운영체제는 CPU나 하드웨어 메모리와 같은 자원에 대한 직접적인 제어권을 가짐으로써 자원의 변화와 같은 동적 가상화 환경에 유연하게 적응할 수 있다.

하드웨어에 대한 드라이버가 어느 계층에 있느냐에 따라 분류

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

호스트 기반 가상화

• 호스트 기반 가상화(Host based virtualization)는 완전한 운영체제가 설치되고 가상화를 담당하는 하이퍼바이저가 호스트 운영체제 위에 탑재되는 방식이다.
• 이 이방식은 다른 가상화 환경에 비해 성능은 물론 자원 고나리 능력 측면에서도 제약 사항이 많은 편이다. 가장 큰 담점은 단일 운영체제의 취약성에 있다.

컨테이너 기반 가상화

• 컨테이너 기반 가상화(Container based virutalization)는 호스트 운영체제 위에 가상의 운영체제를 구성하기 위한 운영 환경 계층을 추가하여 운영체제만을 가상화한 방식이다.
• 운영체제만을 가상화 대상으로 하므로 전체 하드웨어를 대상으로 하는 하이퍼바이저 기반 가상화 방식에 비해 훨씬 적게 가상화한다.
• 컨테이너 기반 가상화는 가상화 수준이 낮기 때문에 다른 방식에 비해 빠른 성능을 보여주지만, 자원간 격리 수준이 낮아 하나의 가상 운영체제에서 실행되는 애플리케이션의 자원 사용에 따라 다른 가상 운영체자가 영향을 받는 단점이 있다.
• 또한 호스트 운영체제의 보안 취약성에 의해 모든 가상 운영체제가 문제가 발생할 수 있으며, 호스트 운영체제를 공유하기 때문에 호스트 운영체제의 문제가 전체 가상 운영체제에도 영향을 미치게 된다.

구분	하이퍼바이저 기반(Full, Para)	컨테이너 기반
하드웨어 독립성	가상머신 내에서 완전 독립	호스트 OS 사용
OS 독립성	호스트 OS와 완전 독립	호스트와 게스트 동일
격리수준	높은 격리 수준	낮은 격리 수준
성능	높은 오버헤드 발생 성능 향상을 위해 HW 가상화 기술 병행	오버헤드 거의 없음 HW 자원의 대부분을 활용
관리	가상머신 별도 관리	공통 SW 중앙 집중식 관리
응용분야	이기종 통합(윈도우와 리눅스 혼합 환경)	단일 OS 환경 자원 통합,대규모 호스팅 업체
대표제품	VMware ESX, MS Virtual Server Xen	Virtuozzo, Sun Solaris Container

나. 메모리 가상화

• 운영체제는 메모리를 관리하기 위해 물리주소와 가상주소를 사용하고 있다. 물리주소는 0부터 시작해서 실제 물맂거인 메모리 크기까지를 나태내고, 가상주소는 하나의 프로세스가 가리킬 수 있는 최대 크기를 의미하며 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을 별도로 두어 가상 메모리 주소와 물리 메모리 주소의 중간 변환 과정을 가로챈다. 이 테이블은 마치 연속된 빈 공간의 메모리가 실제 존재하는 것 처럼 게스트 운영체제에게 매핑해주는 역할을 하며, 동시에 개별적인 모든 가상머신들이 자신만의 메모리 주소 공간을 갖도록 한다.

1. Memory ballooning - VMKernel은 예약된 메모리보다 더 많은 메모리를 사용하는 가상머신의 메모리 영역을 빈 값으로 강제로 채워 가상머신 운영체제가 자체적으로 swapping하도록 한다.
2. Transparent page sharing - 하나의 물리적인 머신에 여러 개의 가상머신이 운영되는 경우 각 가상머신에 할당된 메모리 중 동일한 내용을 담고 있는 페이지는 물리적인 메모리 영역에 하나만 존재시키고 모든 가상머신이 공유하도록 한다.
3. Memory Overcommitment - 2GB 메모리를 가진 물리적 장비에 512MB Minimum reserved를 가질 수 있는 가상머신 5개를 수행할 수 있다. 이것은 앞서 설명한 두 가지 기법을 이용하여 가능하지만, 모든 가상머신이 메모리 사용이 많은 업무를 수행하는 경우라면 심각한 성능저하 현상이 발생할 수 있기 때문에 권장하지 않는다.

다. I/O 가상화

하나의 물리적인 장비에 여러 개의 가상머신이 실행되고 있는 상황에서 가장 문제가 되는 것은 I/O에서의 병목현상이다. 따라서 CPU 자원의 파티셔닝만으로는 가상화 기술을 제대로 활용할 수 없으며 I/O 자원의 공유 및 파티셔닝이 필요하다. 또한 하나의 물리적 머신에서 운영되는 가상머신 간에도 통신이 이루어져야 한다. 이를 위해 가상 디스크 어댑터, 가상 이더넷 어댑터, 공유 어댑터 등과 같은 기술들이 사용된다.

• 가상 이더넷
  • 가상 이더넷은 대표적인 I/O 가상화 기술의 하나로 가상화 기능 중에서 물리적으로 존재하지 않는 자원을 만들어 내는 에뮬레이션 기능을 이용한다. 가상 이더넷을 이용할 경우 각 가상 머신들 사이에 물리적인 네트워크 어댑터 없이도 메모리 버스를 통해 고속 및 고효율 통신이 가능하다.
• 공유 이더넷 어댑터
  • 공유 이더넷 어댑터는 여러 개의 가상머신이 물리적인 네트워크 카드를 공유할 수 있게 하며, 공유된 물리적 카드를 통해서 외부 네트워크와 통신이 가능하다. 특히 가상 머신의 개수보다 물리적 어댑터의 개수가 적은 경우 여러 가상머신들이 물리적 이더넷 어댑터를 공유할 수 있게 해 준다.
• 가상 디스크 어댑터
  • 한 대의 서버가 여러 개의 가상머신을 구성할 경우 가장 문제가 되는 부분이 외장 디스크를 사용할 수 있게 해주는 파이버 채널 어댑터(Fiber Channel Adapter)와 같은 I/O 어댑터의 부족이다.