DO MY BEST

이제 Hadoop의 MapReduce는 어떻게 되어있을까 살펴보자.

MapReduce와 HDFS가 어떤식으로 결합해서 실행되는지 살펴보자. 특히 Hadoop 1.xx 버전에서는 이렇게 실행된다. 앞에 구글 MapReduce에서 master라고 했던 부분은 JobTracker라는 master processor로 Hadoop에서 실행되고, 구글 MapReduce의 Worker는 Hadoop에서 TaskTracker라는 slave processor로 실행된다. 기억을 더듬어 보면 HDFS에서 namenode라고 하는 master가 있어서 얘가 메타데이터(meta data)를 관리했고 datanode가 각각의 slave node에서 실행되면서 local Linux file system에 실제 애플리케이션 데이터를 관리하는 형태로 실행됐었다. 비슷하게 MapReduce가 실행되기 위해서는 Master processor인 JobTracker, 그러니까 job을 제출하는 job submission node에서 JobTracker가 실행돼야하고 각각의 slave node에서 tasktracker보다는 slave process가 실행되어야 한다. 그러니까 namenode, datanode가 hdfs에서 cluster를 구성하는 것이고 JobTracker와 tasktracker가 MapReduce 프레임워크를 구성하고 있다고 보면 된다. namenode와 job submission node를 하나로 묶는 경우도 있고 기계가 남아돌면 분리 하는 경우도 있다. 

Slave node를 물리적인 노드를 의미한다고 생각하면 된다. 각각의 물리노드에 hdfs를 위한 datanode daemon과 MapReduce를 위한 tasktracker를 모두 실행되고 있는 것을 볼 수 있다. 왜 이렇게 실행 되어야 하냐면 만약 둘 중 하나가 빠져있으면 문제가 생긴다. 정확히 말하면 MapReduce를 처리할 때 문제가 생길 수 있는데, 예를 들어서 한 slave node에 tasktracker가 없다고 치고, datanode는 다 돌고 있다고 하자. 그러면 job submission node에 있는 JobTracker가 tasktracker가 없는 노드로는 map task나 reduce task를 보낼 수 없다. Task tracker가 실제로 JobTracker의 명령을 받아서 map 또는 reduce task를 실행하는 주체이기 때문에 tasktracker가 없다고 하는것은 task를 실행할 수 없는 것이기 때문에 Mapeduce 프레임워크 입장에서 봤을때는 해당 slave node가 없는 것과 같은 맥락이다. 

반대로 tasktracker가 있는데 datanode가 안돌고 있다고 하면 어떻게 될까? 그렇게 되면 해당 slave node는 namenode에게 눈에 보이지 않는 것이다. 즉 해당 slave node는 없는 것과 마찬가지이다. 그래서 datanode와 tasktracker는 항상 같은 노드에서 실행이 되어야 한다. 

ps. Hadoop yarn에서도 같은 맥락에서 동작한다.

Hadoop job processing step

MapReduce job processing의 step을 그림으로 살펴보자.

1. Run job : client가 job을 실행해 달라고 JobClient 클래스에 요청을 한다.
2. Get new job ID : 새로운 job ID를 JobTracker에게 요청해서 job ID를 받게된다. 
3. Copy job resources : job에 관련된 resource들을 shared file system에 업로드한다. (Job resource라고 하는 것은 보통은 mapper와 reduce 클래스 다 포함하고 있는 jar 파일 같은 것이다. Jar 파일 같은것들을 hdfs에 올려놓아야 나중에 MapTask나 ReduceTask를 실행할 수 있게 된다. 왜냐하면 MapReduce job을 submission 하면은 실제 Map과 Reduce가 어디서 실행 되냐면은 전적으로 JobTracker가 알아서 한다. 이 얘기는 MapReduce job의 map task와 reduce task가 Hadoop cluster를 구성하는 어느 node에서 실행될지 모른다. 사전에 알면 그 노드에 필요한 파일들을 갖다놓을것이다. 그러나 안된다. 어디서나 접근이 가능한, 모든 노드에서 접근을 할 수 있는 file system이 대표적으로 hdfs이기 때문이다.)
4. Submit job : job을 제출한다.
5. Initialize job : JobTracker가 initialize 한다.
6. retrieve input splits : input split은 MapReduce job이 처리하고싶은 단위이다. 그러니까 64mb씩 쪼개서 각각의 input split에 대해서 어느 tasktracker에 있는지 찾아내야한다. 그래야 각각에 대한 input split에 mapper를 띄울 때 최대한 그 데이터에 가깝게 스케쥴링 할 수 있기 때문이다.
7. Heartbeat : input split을 기반으로 해서 tasktracker에게 작업을 할당하게 되면 주기적으로 heartbeat을 보내게된다. 
8. Retrieve job : tasktracker는 child JVM을 launch시켜서 Map 또는 Reduce task를 실행하게 되는데 그 전에 해야할게 HDFS에 접근해서 job resource(jar 파일 같은거)를 받아와야한다. jar파일 같은게 로컬하게 있어야 map/reduce task를 실행시킬수있다. 
9. Launch : tasktracker가 childJVM을 launch시키고
10. Run : 사용자가 정의하는 map/reduce함수를 적용하는 과정이다.

정리하면, 기본적으로 사용자가 개발한 MapReduce 프로그램 실행파일 jar가 있어야 하고, 그 jar파일이 hdfs에 올라가 있고 처리에 필요한 input data도 hdfs에 있다라고 가정을 하는 것이다. 그런 과정에서 JobTracker는 각각의 input split에 대해서 hdfs의 namenode에게 물어봐서 각각이 어디에 있는지 찾은 다음에 거기 최대한 가깝게 map task를 실행한다. 실제 실행이라고 하는 것은 tasktracker가 childJVM을 통해서 사용자가 정의한 map/reduce 함수를 적용하는 과정이다.

JobTracker

JobTracker를 자세히 살펴보도록 하겠다.

JobTracker가 하는 가장 중요한 일은 기본적으로 cluster에 있는 특정 노드들의 MapReduce task들을 경작(farm out) 하는 것이다. (task는 job을 이루는 구성요소) (MapReduce task는 map task + reduce task를 말한다) input data를 갖고있는 그 노드에 map task를 가져다 주거나 적어도 같은 rack에 있는 노드에서 map task를 실행해서 같은 rack에 있는 데이터 노드를 복사해올 수 있게한다. 이것은 data locality에 해당된다. 

Data locality를 구현하는 주체는 JobTracker이다. 

그런데 JobTracker라고 하는 것은 single point of failure이다. (단일고장점) 만약 JobTracker가 죽게되면 모든 실행중인 MapReduce job은 멈추게(halting) 될 수 밖에 없다.

많은 사람들의 job을 관리해야 하니까 JobTracker가 가지는 overhead는 클 수 밖에 없다. 수많은 task에서 state정보를 메모리에서 계속 관리하고 있기 때문에 너무 자주업데이트 된다. 회사로 예를 들면 부서별로 JobTracker가 따로돌면 관리부담도 줄어들고 좋다. 이런 부담을 도입해서 Hadoop2에서는 yarn이라는 운영체제가 나오면서 apllication master라는 대체개념이 나온다. 

MapReduce job processing

1. Client apllication이 MapReduce job을 JobTracker한테 제출한다. 
2. 그 이후 JobTracker가 최대한 가깝게 스케쥴링을 해야하니까 기본적으로 input data가 있는 위치를 물어보기 위해 namenode랑 컨택한다. (JobTracker는 프로세싱만 하고 데이터관리는 안한다)
3. namenode로 부터 받아서 그 노드들 중에 최대한 input data랑 가깝게 있는 tasktracker node를 찾는데 (가용한 slot이 있는 경우)
4. TaskTracker를 찾으면 TaskTracker node들 한테 일을준다.
5. TaskTracker node들이 기본적으로 모니터링된다. Data node와 namenode처럼 heartbeat을 주고받는다. (분산시스템에서 서로의 생사를 확인할 수 있는 방법은 구글처럼 master가 ping을 하던지, 하둡에서 slave가 주기적으로 heartbeat을 보내주던지 이 두개밖에 없다) 만약에 heartbeat을 받지 않으면 다른 그 작업을 다른 tasktracker한테 스케쥴링 하게 된다.
6. 자기가 실행하고 있는 task가 에러가 나면서 죽으면 JobTracker에게 알려준다. Jobtracker가 fail난 task를 다시 다른곳에 resubmission 한다. 이것은 혹시라도 그 tasktracker가 실행되는 node의 환경이 맞지 않아서 task가 죽은 것일수도 있으니까 다른곳에서도 해보는 것이다.(계속 죽으면 블랙리스트에 넣는다)
7. 전체적인 작업이 끝났다. 이 얘기는 MapReduce작업이 끝났다는 얘기이다.
8. 그러면 client apllication이 JobTracker한테 관련된 정보를 가져올 수 있게되는 형태로 진행된다.

MapReduce의 progress는 기본적으로 JobTracker가 담당한다고 보면 된다.

TaskTracker

TaskTracker라고 하는 것은 기본적으로 map, reduce, shuffling과정이 있었는데 이러한 task들을 jobtracker한테 받아서 실행하는 역할을 수행한다. 그런데 shuffling task라는 것은 reduce task가 remote procedure call을 통해서 map task가 실행됐던 그 node의 데이터를 복사해 가는거니까 조금 다른데 map과 reduce같은 경우에는 slot이 정해져 있다. 각각의 TaskTracker 같은 경우는 slot이 정적으로 설정되어 있다. 동적으로 실행시간이 변하는게 아니다. 각각의 TaskTracker가 받아들일 수 있는 mapper 또는 reduce의 개수가 사전에 구성이 되어있다 라고 이해하면된다. Static configuration의 문제는 뭐냐면 결과적으로 Hadoop cluster가 homogenous하다고 가정하는 것이다. node의 하드웨어 스펙이 비슷하니까 각자 균등하게 분할해서 똑같은 숫자의 Mapper와 똑같은 숫자의 reduce를 처리하면 되겠네 라고 하는 naive한 방식으로 시작한 것이다. hadoop이 탄생할 때 이런 모습이고 목적이었는데, 시간이 지날수록 하드웨어 자원이 발전하니까 각각의 노드의 컴퓨팅 파워가 달라지기 시작하고, 문제가 뭐냐면 hadoop 생태계가 커지면서 MapReduce말고도 다른 형태의 프레임워크가 들어오기 시작했다. 이런것들 때문에 고정적인 slot기반의 자원관리가 좋지 않다. (slot의 단점)

각각의 TaskTracker는 separate JVM process를 낳아서(spawn해서) 실제 일(actual work)을 한다. Separate JVM을 launch하는 이유는 map이나 reduce task가 실행되다가 죽더라도 tasktacker자체는 별로 영향을 미치지 않게 하기 위한 것이다. 

그래서 spawning된 프로세서를 TaskTracker는 꾸준히 모니터링 하면서 output과 exit코드를 캡쳐 해서 jobtracker한테 보고하게 된다. 

프로세서가 끝나게 되면은(성공적으로 끝났던, 중간에 에러나서 죽었던) 이 결과를 기본적으로 jobtracker한테 보고(notification)하고 다음 지침을 받는다. 그리고 중요한 것은 각각의 TaskTracker들은 jobtracker한테 주기적으로 heartbeat message를 보낸다. (TaskTracker가 살아있음을 계속 알림)

각각의 TaskTracker가 주기적으로 heartbeat을 보내면서 현재 가용한 slot의 개수를 알려준다. 그러면 jobtracker는 이 cluster를 구성하는 전체 TaskTracker의 가용한 slot들을 다 알고 있는 것이된다. 그러면 새로운 MapReduce job이 들어와서 task assign을 할 때 그 slot들을 보면서 결정하는 것이다. 고려해야 할 것이 두 가지이다. 

첫 번째는 task를 실행하려면 slot이 있어야 한다. 두 번째는 data locality를 고려해야 한다. jobtracker는 최대한 data에 가깝게 보내고 싶어한다. 그래야 전체적인 cluster 활용율이 올라가기 때문이다. 

Fault Tolerance

구글이 디자인한 MapReduce에서 Fault Tolerance는 어떻게 해결하는가이다.

Hdfs를 기억해보면 datanode가 namenode한테 주기적으로 heartbeat을 보냈다. 구글이 구현한 MapReduce같은 경우에는 master가 주기적으로 ping한다. 분산시스템에서 node의 failure를 detect하는 방법은 주기적인 메시지교환 밖에 없다.

master가 어떤 worker가 죽은것을 알았을 때, 그 map task를 reset해서 다른 worker에서 다시 돌린다. 그러면 complete된 map task는 failure가 일어나면 재실행(re execute) 되는건데, 왜그럴까요? 각각의 mapper가 생산해낸 중간결과물(Intermediate key value)은 어디있죠? 그 mapper가 실행되는 그 node의 로컬디스크에 저장되어있다. 당연히 fail했다는 의미는 로컬디스크에 접근이 안된다. 결과적으로 봤을 때 failure를 detect했을 때, 거기에 할당되는 모든 map task들은 다시 실행된다. 

반면에, reduce task가 끝난 다음에 죽었다. 그러면 얘네들을 굳이 다시 실행할 필요가 없다. 왜냐하면 reduce task의 결과는 항상 global file system, hadoop으로 따지면 hdfs에 저장되기 때문에 그 노드에 저장되는 것이 아니라 안정적으로 접근이 가능하다. (이미 그 노드를 떠난것이다. ) 의문을 가질 수 있는게 Intermediate key/value pair들도 hdfs에 저장해두면 다시 실행할 필요가 없는데, 구글 디자이너들이 생각할 때 intermediate data까지 global file system에 저장하는 것은 아니다고 생각했다. 왜냐하면 intermediate 라는 의미는 어차피 사라질 데이터 이기 때문이다. (reduce가 끝나고 나면 중간결과물이 필요없어진다)

(Resilient) 

실제로 구글에서 80개의 머신이 죽었는데 살아있는 것들 위주로 작업을 재실행 하면서 진행했다. 결과적으로 전체적인 MapReduce 작업을 무사히 끝마칠 수 있었다. 

failure들이 동시다발적으로 일어난다고 해도 MapReduce자체가 관리해주기 때문에 messy detail들에서 자유로울 수 있다. 이것이 가장 큰 장점이다.

Locality

Network bandwidth자체가 무한대 자원이 아니라 항상 부족할 수 있는 자원이다. 그러다보니 이걸 조금 아껴 써야하지 않나고 생각하며 디자인 철학이 생겼다. (일반적인 commodity computer 환경 에서) hdfs는 block단위로 쪼개서 데이터 노드들의 로컬디스크에 각각 다 저장이 되어있다. 그러면 그냥 로컬디스크에 있는 데이터를 읽게 하는 것이 좋겠다 라고 생각하는 것이죠. 그래서 “Moving computations close to the data”라는 개념이 나왔다. 기존의 슈퍼컴은 데이터를 computing 쪽으로 보내는 모델 이었는데 이렇게 하지 말고 데이터를 이미 분산 시켜놓은 다음에 거기에 computation (MapReduce관점에서 mapper)로 보내면 되겠다고 고민했다. 그래서 구글 mapreduce에서 master는 map task를 필요로 하는 input split 데이터를 실제로 소유하고 있는 machine에 allocation하기 위해 최선을 다한다. 만약에 그것을 실패하게 되면 그 노드가 바빠서 더이상 작업을 받아들이지 못할수도 있으니까, 그러면 그나마 input data 가까이에 배치하고 싶어한다.

가깝다는 개념은 hdfs에서도 다루었다. 

Data block과 최대한 가깝게 보낸다고 하는 것은, Node-2를 보면 저기 map task가 원하는 input split(data block)이 같이 있는 것이다. 이것을 data와 computation을 colocation 시킨다라고 표현했다. 이런 경우를 “data local”이라고 표현한다. Data local인 경우가 best case이다. 최적의 상황이다. 왜냐하면 여기서는 network 통신이 일어나지 않기 때문이다.(network bandwidth를 아낄 수 있음) 

만약에 Node-2처럼 이런 환경을 만들어낼 수 없다면, “rack local”도 생각할 수 있다. Node-3의 map task가 원하는 input split이 Node-4에 저장이 되어있다. 이런 경우에는 같은 Rack-1에 있는 다른 노드(node)의 데이터를 copy하는 것이 낫겠다고 생각하게 되는것이죠. 이것이 rack local이다. 그러나 data local, rack lock 둘 다 안되는 Node-5를 보면 다른 rack에서 copy해와서 실행한다.

hdfs의 블록 배치 방법이 mapreduce의 블록배치에도 도움이 되었다. 

Large-Scale Indexing

구글이 mapreduce를 개발해서 여러 분야에 했었는데, 그 중 대표적인 것이 Large-Scale Indexing이다. 검색엔진을 만들어야 하니까 index를 만들어야 했다. 

빅데이터를 다루는데 있어서 분산시스템은 피해갈 수 없는 숙명같은 것이다. 왜냐하면, 단일노드(단일 컴퓨터)에서는 처리할 수 없기 때문에, 클라우드 환경에서 빅데이터 분석(big data analytics)을 할때는 반드시 분산된 시스템에서 할 수밖에 없는 것이고, 그랬을 때 개발자(사용자)입장에서 좀 더 쉬운 API를 통해서 그들이 풀고자 하는 문제에 집중하게 해주고 나머지는 플랫폼(시스템)이 처리해주는 이런 모델로 가고있다고 보면된다.

Google MapReduce Overview 1

Google MapReduce가 실제 어떻게 실행이 되는지 시스템 아키텍쳐 측면에서 살펴보자.

master가 HDFS의 namenode와 비슷하게 MapReduce 실행을 관장하는 master 역할을 하는 것이고, Hadoop에서는 이것을 jobtracker라고 표현한다. 그리고 worker들은 hadoop에서 tasktracker라고 표현한다. 왼쪽 worker들은 Map 단계를 수행하고, 오른쪽 worker들은 Reduce 단계를 수행한다. 그럼 어떤식으로 흘러가는 것일까 보면, (맨 왼쪽 부터 시작) 입력파일들이 주어지게 된다. 입력파일이 주어지게 되면은 입력파일을 input split으로 쪼개게(partitioning) 된다. worker에서는 split 0, 1두개를 실행시킨다. Input split이라고 하는 것은 HDFS에서 block size랑 같다고 했으니까 대개의 경우에는 64mb 데이터 파일을 읽어들어서 처리하게 된다. (위 그림상) input split이 5개 이니까 5개의 mapper가 뜰건데, 그 mapper안에 정의되어 있는 map함수를 적용하는 것이 바로 worker의 역할이다. 그러면 key/value pair를 parsing해서 각각의 pair를 user-defined(user defined) map function으로 보내주는 것이다. wordcount 같은 경우는 intermediate key/value는 “단어,1”이런식으로 내보냈다. 그러면 worker가 mapper를 통해서 하나의 input split을 처리하면서 나오는 그러한 intermediate key/value pair들은 일단 메모리에 버퍼가 된다. 그런데 메모리에 용량이 부족해질 수 있으니까 주기적으로 버퍼된 pair(buffered pair)들이 로컬 디스크에 R개의 region으로 분할(partitioning)되어서 저장이 된다. intermediate key space를 reducer 개수만큼 partitioning 한다고 했는데 현재 여기서는 reducer가 두개가 돈다고 보면 된다. reducer가 두개일 때 잘 보면 로컬에 저장된것도 조각이 두개이다.(partitioning 되어서 저장된것이다) 그러면 예를 들어서 wordcount 예시를 들어보면 bear와 car는 왼쪽 조각에, deer와 river는 오른쪽 조각에있고 각각 다른 reduce단계의 worker로 갈 수 있다고 생각하면된다. map단계에서 모두 끝나고나면 로컬디스크에 파티셔닝 되어있는 데이터가 있을 것이다. 각각의 데이터가 reduce로 전달되는 것일 뿐이다. map단계가 끝나고 나면 파티셔닝된 데이터가 있을것이고 각각의 데이터가 결과적으로 reduce로 전달되는 것일 뿐인데, 어떻게 전달이 되느냐하면, reduce의 worker가 master로 부터 notification을 받는다. 그러면 remote procedure call을 통해서 퍼버링된 데이터를 map worker의 로컬디스크로 부터 가져가는 것이다.

정리하자면 input split 개수만큼 mapper가 실행되고 (이 그림에서 현재 mapper가 5개가 실행돼야하는데 3개만 보여주고있는상황) mapper가 하는일은 input split에 있는 logical record를 하나씩 읽어서 사용자가 정의한 map함수를 적용하고 그 결과로 나오는 intermediate key/value pair를 reduce의 개수만큼 partitioning 해놓은 것이다. (Partitioning 함수는 기본적으로 주어져 있다. ) reducer개수가 하나라는 얘기는 partition 자체를 할 필요가 없다는 얘기이다. Partition data를 로컬디스크에 잘 저장하고 있다가 모든 map단계가 끝나면 reducer가 각각의 maper에게 연락해서 가져간다. 그러면 결과적으로 reduce의 개수만큼 file이 생기게된다.

Google MapReduce Overview 2

하나의 input split을 받아서 map 함수를 거치면 메모리에 버퍼링되는 intermediate key/value pair들이 나온다. 이것들이 결국 partition하고 sorting해서 저장하게 된다. 결국 디스크에 merge 되어있고 세 칸인거 보니깐 reducer가 세 개 돌고있는 것 같다. 그러면 첫 번째 partition은 첫번째 reduce한테 주고  두번째 partition은 두번째 reduce… 이렇게 준다. 이런식으로 다른 mapper들도 세 개로 쪼갠 partition을 가지고 있을 것이고 첫번째 파티션이 한쪽에 모일 것이다. (오른쪽 그림이 첫번째 파티션에 해당되는 데이터를 처리하는 reduce이기 때문) 내부적으로 merge, sort 하면서 reduce단계로 넘어가서 최종 output을 생산해내는 단계로 가게 된다.

Shuffling 단계가 MapReduce실행에 가장 복잡한 단계이다. 또 다르게 말하면 가장 overhead가 큰 단계이다. fetch같은 것들이 많이 일어나니까 network 통신이 많이 일어나기 때문이다. 

파티션에 데이터가 없을 수 있다. 이점은 데이터가 어떻게 구성되느냐에 따라 달라진다.

MapReduce의 programming model

MapReduce의 programming model은 기본적으로 input key/value pair를 받아들여서 output key/value pair를 생성하는 형태로 pipeline처럼 연결된다. Map이 처음 시작할 때도, 처리해야하는 input data를 key/value형태로 받아들이며 Map이 역시나 key/value 형태로 내보내게 된다. 그러면 내보낸 intermediate key/value pair들이 결국 그룹핑(grouping) 되면서 key/value들의 리스트 형태로 Reduce로 넘어간다고 보면 된다. 결국 Reduce도 마찬가지이지만 Map이라고 하는 함수는 사용자가 작성을 해야한다. 

MapReduce에서 input splite이라는 개념을 쓰는데, input splite이 사실상 hdfs의 block size랑 같아야한다. 그 얘기는 하나의 hdfs block에 대해서 하나의 Map 함수가 적용된다. mapper가 그 개수만큼 여러개 적용될 수 있다. mapper들이 사실은 block들이 흩어져 있는 여러 노드에서 동시 다발적으로 실행될 건데, 실행중에 나오는 intermediate key/value pair들은 MapReduce가 그루핑(grouping) 하는 것이다. 모든 Map 단계가 끝나게 되면은 intermediate value들을 associated with the same intermediate key 이니깐 intermediate key를 똑같은것을 공유하는 모든 value들을 묶어주는 것이다.(group together) 앞에서 말했다 싶이 Map단계를 끝나서 나오는 intermediate key/value pair들은 같은 key를 공유하는 value들의 리스트는 반드시 똑같은 reduce한테 다 몽땅 가게 돼있다. reduce가 두개 이상 돌 수 있기 때문에 이런 문제를 고민해야 한다. reduce가 두개 이상 돌 때 하나의 key, intermediate key에 대한 value들의 집합이 쪼개지면 절대 안된다. 왜냐하면 이 key에 대해서 모든 value들을 받아서 aggregation 연산을 해야 정확한 결과가 나오는 것이기때문이다. Reduce함수라고 하는 것은 사용자가 개발해서 intermediate key와 value들의 리스트가 오게된다. 이렇게 되면 key에 해당되는 모든 value들이 딸려온다. 그리고 merge해서 쫌 더 작은 결과값을 생성한다.

MapReduce를 WordCount로 예시를 들어보면

입력데이터가 하나의 노드에서 돌리면 상관이 없는데, 이 데이터의 용량이 수백 기가, 혹은 테라바이트면 하나의 노드 에서는 어려울 수 있다. 그렇게 되면은 hdfs에서 정한 64mb 블록사이즈로 쪼개서 저장한 다음에 MapReduce가 블록 단위로 처리하게 된 것이다.  

• Splitting:

이것을 input split이라고 얘기한다. MapReduce관점에서는 처리하고자 하는 입력데이터의 단위이기 때문에 input split이라는 명령어를 쓰는 것이고 hdfs관점에서는 데이터가 저장되는 단위이기 때문에 block이라는 개념을 쓴다. 엄밀하게 말하면 input split과 block이 꼭 같은 사이즈일 필요는 없다. 예를 들어서 데이터가 저장되어 있는 것은 64mb block 단위로 저장되어 있는데 하나의 input split, 하나의 mapper가 처리하고자 하는 데이터양이 두개 이상의 block을 한꺼번에 처리하고 싶다던가, 이런 것도 가능하다. 그런데 이렇게 했을때는 성능상에 이점이 없기 때문에 input split과 hdfs block사이즈를 맞추게 된다. 왜 이렇게 하는지는 나중에 설명이 나온다. 그러니까 한줄 한줄이 input split이다. MapReduce가 입력 데이터를 처리하는 단위이다. 

• Mapping:

mapper가 세 개가 떴다고 생각하면 된다. Mapper가 세 개가 떴으면 mapper는 자기가 담당하는 input split을 읽어들여서 사용자가 정의한 map함수를 적용한다. 그런데 사용자는 어떤 식으로 구현한거냐면 (splitting 단계에 있는 것을) 한줄씩 읽어서 파싱(parsing)한 다음에 단어별로 뽑아낸다. 단어를 key로 잡으면 이것이 intermediate key가 된다. 그리고 value는 1이다. 정리하자면 input split을 logical record 단위로 한줄씩 읽으며 파싱한 다음에 거기에서 나온 단어(word)를 key로 잡고 1을 value로 내보내면 되겠다고 인지할 수 있다. 결론적으로 이 단계에 있는 9개의 key/value들이 intermediate key/value pair들의 집합이다. 중요한 포인트는 mapper들이 intermediate key/value pair들을 모두 생산해 낼 때 까지는 reduce 단계로 넘어가지 않는다. 나중에 오는 것들 중에서 집계가 덜 된 데이터들도 있을 수 있기 때문에 mapping단계가 끝날 때 까지 기다린다. 그 다음에 shuffling 단계로 들어간다.

• Shuffling:

reduce단계로 넘어가기 위해서 shuffling 단계로 넘어간다. 이 단계에서는 기본적으로 intermediate key를 공유하는 value들을 묶이게 되는 것이다. 다시 말해 동일한 intermediate key를 공유하는 value들이 묶이고 이 value들이 리스트 형태로 넘어가게 된다. 그래서 예를 들어 [1,1]에서 1 + 1 이런식으로 해서 나온 값을 넘겨준다.(aggregation 연산을 수행할 수 있게 된다.) 그래서 Reduce단계에서 같은 키를 갖는 value들은 항상 똑같은 reducer로 간다.

• Reducing:

reduce에서 사용자가 정해놓은 함수가 있을것이다. 같은 key를 공유하는 value들의 리스트가 무더기로 넘어올 때 더하는 식으로 만들었다. 그럼 final result를 이제 글로벌하게 입력파일이 있을 때 전체적으로 저렇게 나온다.

MapReduce의 가장 큰 장점은 이 플로우를 생각해서 maper와 reducer를 개발한다고 치자, input을 어떻게 받을거고 output 내보낼 것이고 reducer단계에서는 어떤식으로 결합할 것이라고 정했다고 생각하면, 입력데이터가 아무리 크다고 하더라도 MapReduce는 소스코드 수정없이 모든 데이터 처리를 성공적으로 수행할 것이다. 결론적으로 인풋의 크기가 전혀 상관이 없다는 얘기이다. 이것이 가능한 이유는 mapper가 실행되는 단계에서는 각 input split별로 동시다발적이면서 독립적으로 실행되는 것이다. 그리고 모든 매핑이 끝난 다음에 셔플링과 리듀싱 단계로 넘어가기 때문이다.

즁요한 것은 intermediate key/value pair를 어떻게 잡을 것이냐 이다. 

메인 프로그램 3개를 작성해서 실행 하면, 입력 데이터가 아무리 크다고 하더라도 MapReduce가 알아서 input split별로 mapper를 띄어주고 사용자가 mapper안에 구현해놓은 map함수를 logical record 하나하나 다 적용해주고 사용자가 원하는대로 intermediate key/value pair를 생성해주고, 이렇게 배포작업이 끝나고 나면 shuffling단계도 알아서 해주면서 intermediate key를 공유하는 단어 배열을 공유하는 애들을 한곳에 몰아서 reduce에 던져준다. 그러면 Reduce 함수에서는 value들의 리스트를 다 더하는 작업을 하고 그 결과는 결과적으로 hdfs에 다시 저장되게 된다.

Map 함수에는 key와 value가 파라메터로 들어오는데 value는 document contents일 것이다 라고 하고 value에 있는 각각의 단어에다가 “1”을 붙여서 내보내면 map단계가 끝난다. 

Reduce함수에는 intermediate key를 공유하는 value들의 집합이 파라메터로 온다. 그러면 각각의 value들을 for문을 돌면서 “1”을 더한다. 

Mapreduce processing 하는 것은 데이터를 처리해서 insight를 얻기 위함이다. 그리고 분산되어 있는 큰 데이터들을 어떻게 하면 빠르게 병렬 처리하고 높은 through put 을 낼 수 있는 것을 고민한 결과이다. 그리고 기본적인 빅데이터 처리 모델이다.

그 전 포스트에서는 하둡(Hadoop)이 빅데이터를 어떻게 저장하는지에 대해 배웠고 이제는 분산파일 시스템에 저장되어있는 데이터를 어떻게하면 효율적으로 병렬처리할 수 있으면서 전체적인 through put을 높일 수 있는 방안에 대해 고민한 MapReduce 프레임워크에 대해서 살펴볼 것이다.

Hadoop project라고 하는 것은 distributed file system이고 very large data set을 analysis 하고 transformation 할 수 있는 MapReduce라고 하는 페러다임을 가지고 있다. 사실은 MapReduce라고 하는 것은 클라우드 프로그램밍 모델인 동시에 runtime system이라고 할 수 있다. 그래서 데이터만 partitioning 하는 것이 아니라 computation도 분할해서 수천개 이상의 호스트들에게 분산해서 실행하는 것이다. 즉 분산돼서 데이터도 저장하고 분산해서 실행하는 것이다.

MapReduce의 큰 특징중 하나는 애플리케이션에 computation(task 어떤 분산시스템에 작업단위를 job이라고 표현했다)들이 되도록 병렬하게 동시다발적으로 실행될 수 있도록 하므로써 전체적인 시스템에 성능을 높인다. 데이터와 최대한 가깝게 처리하고 싶은 것이 MapReduce의 목적이다. 데이터와 가깝다는 것은 data locality 장점을 보는 것이다. 가깝다는 것을 어떻게 표현했냐면, 같은 노드에 있으면 distance가 0였고 다른 노드라고 하더라도 똑같은 rack에 속해있으면 distance가 2다. 그리고 rack마다 달라지면 distance가 4로 늘어난다 이런식으로 표현한다.

하둡에서는 가깝다는 개념, distance라는 개념을 실제 runing time시 bandwidth를 측정하는 것이 어렵기 때문에 그렇게 하지 않고 데이터센터에 네트워크 토폴로지를 반영한 심플한 모델을 사용한다. 그래서 하나의 Hadoop cluster라고 하는 것은 단순히 commodity server(어디서나 구할 수 있는 흔해 빠진 서버) 를 계속 추가해 나가면 hdfs가 저장할 수 있는 storage capacity가 IO bandwidth만 늘어나는게 아니라 MapReduce가 실행할 수 있는 computation capacity 까지도 함께 늘어날 수 있는 scale out 아키텍쳐를 가지고 있다.

MapReduce는 프로그래밍 모델(programming model)

MapReduce라고 하는 것은 프로그래밍 모델이다. 왜 프로그래밍 모델이라고 하냐면 모든 computation을 Map과 Reduce라고 하는 두 개의 함수로만 표현하기 때문에 프로그래밍 할 수 있는 일종의 범위(scope)을 확 줄여놓았다. 이런 관점에서 보면은 프로그래밍 모델이다 라고 말할 수 있다. 또한 이와 관련된 구현 결과물인데 어디에 대한 결과물이냐면, 굉장히 대용량의 데이터를 처리하고 생산해 낼 수 있는, MapReduce의 결과로 다른 데이터가 생성될 수 있다. 이런 목적으로 탄생한 프레임워크가 바로 MapReduce이다. 왜 Map과 Reduce냐면, 개발자는 Map function과 reduce function을 개발해야한다.(코딩해야한다) 이것은 MapReduce 프레임워크는 사용자가 정의해준 Map과 Reduce function을 잘 적용하는 역할을 수행하는 것이지 더 많은 책임을 지는 것은 아니다. Map과 Reduce는 특징이 뭐냐면 입력과 결과가 항상 key, value pair형태로 표현하고 이런 표현으로 통신하게 된다.  

MapReduce를 개발하게된 동기(motivation)을 살펴보자.

MapReduce를 개발하기 이전에는 어떤식으로 구글이 작업했는지에 대한 이야기를 해보자.

구글은 세계 최고의 검색엔진 회사이다. 그래서 구글이 웹 다큐먼트를 크롤링 해와서 상당히 raw data가 많이 쌓이고 이걸 통해서 여러가지 일들을 수행하는 회사인데, 구글이 MapReduce이전에 했던 것들을 보면, 특수목적형 계산 프로그램(special purpose computations)들 수백개를 계속 만들어왔다. 이런것들은 굉장히 큰 규모의 raw data들을 처리하는 것들인데 크롤링된 document라던지 웹 리퀘스트 로그(web request log)라던지 이런것들을 분석/처리해서 다양한 형태의 결과물(derived data)을 뽑아내는데, inverted index(inverted indices)라던지, 아니면 web document를 그레프(그래프 graph) 형태로 표현한다든지, 아니면 호스트당 크롤링된 페이지의 통계를 구한다던지, 아니면 하루에 가장 자주 들어온 query를 찾아낸다던지 이런 여러가지 일을 한다. 

이렇게 수행이 되고 있었는데 문제가 뭐였냐 하면,

구글이 대용량의 raw data를 처리하기 위해서 이런 개발물들(computations)자체가 개념적으로 그렇게 어려운 것이 아니다(conceptually straightforward)이다. 그런데 입력(input) 데이터가 매우 크다 그리고 어느정도 감내할만한 시간내에 끝내게 하려면 수백 수천대 이상의 머신에 분산되어서 computation이 실행 되어야 한다. 어쩔 수 없는 것이다. 데이터가 너무 많다 보니까 이거를 하나의 노드에서 처리한다는 것은 불가능 하기 때문이다. Hdfs때 많이 얘기 했지만, 결국은 분산파일시스템 자체가 데이터가 한 노드에 다 저장되지 못하기 때문에 나온 것이기 때문이다. 마찬가지로 computation 계산과정에서 봐도 데이터가 너무 크면 분산처리 할 수 밖에 없다. 그러니까 구글이 하고자하는 일들이 아주 복잡한 형태는 아니었음에도 불구하고 input data가 너무 커서 computation을 분산시키다 보니까 분산 컴퓨팅(distributed computing)으로 인한 overhead가 너무 컸던 것이다. 어떤 오버헤드(overhead)가 있냐면, hdfs에서도 다루었지만 일단 분산 시키는 순간 failure가 가장 문제가 된다. 노드가 죽거나 한참 열심히 실행하다가 노드가 죽으면 어떡하지? 그리고 특히 프로세싱 측면에서 봤을 때는 로드벨런싱(load balancing)도 굉장히 어려운 문제이다. 무슨 얘기이냐면, 내가 열 개의 노드에 열심히 분산시켜서 실행 하고 있는데 어떤 1~2 노드가 성능이 딸려서 그런건지 늦게 실행이 되면은 전체적인 프로세스에 영향을 받는다. 그런 관점에서 봤을 때 구글도 분산처리를 관리하는데 상당히 힘들었던 것이다. 이것을 좀 더 편리하게 할 수 없을까? 뭔가 추상화 레벨을 높여서 run time system 이런것들을 해주면 좋겠는데 라는 어려움이 있었기 때문에 map reduce라고 하는 프로그래밍 모델인 동시에 관련된 구현결과물(run time system)인 새로운 프레임워크가 구글에서 탄생하게 되었다고 보면된다. 

Map Reduce는 프로그래밍 모델인 동시에 구현결과물(runtime system)인데, large data set을 생성하고 처리하는데 사용되는 것이다.

그래서 MapReduce라고 하는 것은 결과적으로 단순한 형태의 computation을 어떻게 하면 잘 표현할 수 있을까 추상화를 고민하는 것이다. 구글이 하고자하는 대용량의 raw data를 처리하는 많은 작업들(computation)의 특징이 뭐였냐면, conceptually straightfoward 한것이다. 개념상으로는 아주 어려운 문제를 푸는 것임이 아니었음에도 불구하고 단순히 input데이터가 너무 크기때문에 분산처리하는 영역이 있는 것이다. 

그래서 추상화를 하면서 어떻게 하느냐면, 분산처리를 하다보면 messy한 디테일들인 병렬화(parallelization), 고장 감내(fault tolerance), 데이터를 어떻게 분산시킬것인가(data distribution) and 로드벨런스(load balancing) 이런것들을 처리해야 한다. 즉 정리하자면 simple한 computation을 잘 표현할 수 있는 길을 열어주고 parallelization, fault tolerance같이 분산처리 하면서 발생할 수 있는 messy한 문제들을 개발자로 부터 감춰주면 좋겠다.(감춰준다는 의미는 사용자가 직접 하는 것이 아닌 분산처리 문제는 MapReduce가 알아서 해준다는 의미) 사용자가 풀고자 하는 문제를 Map과 Reduce에 맞게 개발하면 된다는 것이 MapReduce의 철학이다.

MapReduce는 Lisp라고 하는 functional language에서 있던 Map과 Reduce라고 하는 개념을 가져온 것이다.

그래서 첫번째 단계에서 map이라는 operation은 사용자가 정의해줘야 하는 것이다.(틀만 있다) 각각의 record에 대해서 map operation을 적용하고, 적용한 결과로 뭐가 나오냐면 intermediate key/value pair가 생성된다. 즉 map과 reduce에서는 항상 input과 output에서 key/value로 통신한다. record라고 하면 데이터베이스에서 튜플이다. mapreduce에서 말하는 데이터는 주로 비정형 데이터이기 때문에 텍스트 문서의 한줄한줄을 logical record라고 생각하면 된다.(거기 어떤 내용이 들어있던 상관없이) 사용자가 정의한 logical record를 읽어서 사용자가 정의한 map function을 적용하면 결과물로써 intermediate key/value pair가 생성된다.

이러면 reduce단계로 넘어가야 하는데 reduce라고 하는 것은 aggregation 연산을 수행하게 되는데 map과 reduce중간에 shuffling이라는 단계가 들어간다. shuffling이라고 하는 것은 map reduce 프레임워크가 알아서 해주는 것인데, 

뭘 헤주냐면, 같은 키를 공유하는 모든 value들을 묶어준다. 다시 말해 intermediate key/value pair중에서 같은 키값을 갖는 value들은 다 왕창 묶어준다는 얘기이다. 제대로된 aggregation 연산이 이루어 진다고 볼 수 있는 예시가 wordcount 문제였다. 같은 키를 공유하는 value들의 리스트를 받아서  어떤형태로든 combine 연산을 수행하면 되는 것이다. shuffling에서 중요한 부분은 뭐냐면 같은 키를 공유하는 value들은 반드시 한꺼번에 묶여서 온다는 것이다. key가 같은데 value 들의 set이 분할될 수는 없다는 것이 철학이다. 만약에 분할이 되면 최종 통계를 낼 때 할 수 가 없다. 그러니까 반드시 같은 중간 키값을 공유하는 모든 value들은 하나의 reducer로 전달되게 된다. reducer가 전체시스템 하나라면 문제가 없겠지만 두 개 이상이 될 경우에는 두 개의 reducer에  분할돼서 같의 집은 key를 갖는 value들합이 쪼개지면 결코 안되는 것이고 이것은 MapReduce프로그램이 guarantee해준다. 

사용자 입장에서는, 구글이 고민했던 messy detail들을 MapReduce가 감춰준다고 했기 때문에 사용자들은 Map Reduce가 제공하는 프로그래밍 모델에 맞게 적절하게 Map과 Reduce함수를 구현해주고 key/value pair를 어떻게 정할건지 내가 원하는 aggregation연산을 수행하려면 어떻게  할건지만 고민하면된다고 보면 된다.

결과적으로

빅데이터를 다룰 때 가장 좋은 방법은 divide and conquer방식 이다. 딥러닝 같은 계산이 많은 것들과 같이 문제의 사이즈가 커지면 할 수 있는 방법이다. 하나의 work를 좀 더 세부적인 work로 쪼갠 다음에 작업을 처리하는 worker( = 프로세스, 노드 등등 작업을 실행하는 주체)들을 동시다발적으로 병렬 실행을 하고 그 결과를 취합을 해서 conbine하는 과정으로 빅데이터 문제 또는 big compute 문제를 다룰 수 있게 된다.

Parallelization Challenges

• How do we assign work units to workers?
  • 작업분배가 문제가 될 수 있는것은, 똑같은 work 유닛이라 하더라도 재수가 없으면 실행시간이 오래걸릴 수 있기 때문에 work 유닛을 잘 결정하는 것이 중요한 문제가 된다.

• What if we have more work units than workers?
  • worker들 보다 작업이 더 많을때, worker들을 사용할 수 있는 자원이 100이라고 해도 work 유닛 자체가 10000이면, 이래나 저래나 worker들이 작업을 다 수행할 때 까지는 병렬적으로 실행을 해야할 때, worker들 간에 어떻게 작업분배를 최적화 할 것인가가 문제이고 이것이 load-balancing 문제이다. Load balancing이라고 하는 것은 어떤 하나의 worker가 너무 많은 작업을 처리하면, 그것 때문에 전체적으로 프로세싱이 느려지기 때문이다. 왜냐하면 모든 worker가 작업이 끝나야 최종적인 결과가 나오는데 한 두명의 worker가 느려지면 그만큼 최종 결과물이 늦게 나오기 때문이다.

• What if workers need to share partial results?
  • worker들이 중간 결과물을 교환해야할 때 어떤 방식으로 교환할건지 문제가 된다.

• How do we aggregate partial results?
  • 중간 결과물을 어떻게 합칠 것인가가 문제가 될 수 있다.

• How do we know all the workers have finished?
  • 모든 worker들이 실행이 끝나야지만 되는건데, 얘네들이 끝난지 어떻게 알 수 있을까가 문제이다. 끝났으면 연락을 하던가 알람을 뜨게 하던가 여러가지 방법이 있을 수 있다.

• What if workers die?
  • worker들이 열심히 일 하다가 죽을 수 있다. 컴퓨터가 꺼진다거나 worker프로세싱이 실행하다가 죽을 수 있거나 이다.

위의 첼린지들로 봤을 때 병렬화(Parallelization)해서 뭔가 작업을 실행하는 것은 간단한 문제가 아니라는 것이다.

• Parallelization problems arise from
  • parallelization 문제들이 무엇때문에 일어나는 것일까를 보면 주로 작업들을 실행하는 worker들이 서로 커뮤니케이션을 할 때 어려울 때 어려움이 발생한다. 예를들어, exchange state 또는 shared resources에 접근해서 뭔가 처리해야할 때 어려운 문제가 발생한다

• Thus, we need a synchronization mechanism
  • 이 문제를 해결하기 위해, 어떤 식으로든 간에 동기화해서 서로 커뮤니케이션을 수행하고 공통된 지원에 접근할 수 있는 메커니즘이 필요하다.

• Concurrency(동시실행) is difficult to reason about
  • concurrency가 논리적으로 어떤방식으로 흘러가는지 추론해내기가 쉽지 않다. 실행되다가 워커들이 죽거나 로드벨런싱이 문제가 될 수 있는 이유때문이다.

• Concurrency(동시실행) is even more difficult to reason about
  • 단순히 10개 정도 되는 worker수준이 아니라 아에 데이터 센터 수준이 되거나 데이터센터 간에 하던가 할 때 병렬화 동시실행(Parallelization Concurrency) 하는것이 속도나 처리량(throughput)이 높아지겠지만 굉장히 어려워질 수 있고, failure가 일어날 수 있다. 그리고 서로 상호 맞물려있는 서비스가 있다면 Concurrency를 보장하기엔 어렵다.
  • 디버깅 자체가 문제일 수도 있다. 로드벨런싱 문제인지 코드 문제인지, 환경이 문제인지 추론해내는 것 자체가 문제일 수 있다.

클라우드가 나오면서 빅데이터를 만들기 쉬워졌고 빅데이터 회사를 창업하기도 쉬워졌다. 클라우드는 빅데이터를 처리하는 능력을 대기업들만 갖는것이 아니라 많은 사람들이 민주적으로 다 가질 수 있게 해줬다.

• 대기업들 에게도 클라우드는 매력적이다.
  • 데이터센터를 짓거나 운영할 때도 큰 돈이들고 신경을 지속적으로 써야 한다. 그런데 클라우드 서비스는 이러한 짐을 들어준다. 그래서 그들이 집중해야할 것들에 오로지 집중할 수 있도록 도와준다.

데이터가 클라우드로 들어오고 클라우드에서 HDFS를 실행해서 NoSQL도 사용하고 MapReduce로 분석등을 한 결과를 visualize를 해준다. 빅데이터 분석 저장 처리에 대한 모든 프로세스들이 사실상 클라우드상에서 처리될 수 있음을 말해준다. 그래서 클라우드와 빅데이터가 상호 유기적으로 연관되어 있음을 알 수 있다.

Container-based Virtualization 또 다른 말로는 Operating system virtualization이라고 하는 요즘 뜨고 있는 기술이다.

위 두개의 가장 큰 차이점은 guest OS가 있느냐 없느냐이다.

이 그림은 하이퍼바이저 기반의 가상화 기술과 container기술의 가상화 기술의 차이점을 잘 표현해주고있다.

왼쪽은 하이퍼바이저 type2를 표현하고있다. 하이퍼바이저 위에 게스트 OS가 있고, OS위에는 라이브러리랑 어플리케이션이 있다.

반면

오른쪽은 하이퍼바이저와 비슷한 container engine위에 게스트 OS가 없고 바로 라이브러리와 실행파일 위에 어플리케이션이 돌아가고있다. 여기서 보면, 컨테이너 기반의 가상화 기술은 기존의 하이퍼바이저와 달리 호스트 운영체제의 커널 기능을 공유한다. 이 의미는 운영체제의 기능을 대부분 호스트 운영체제에 의존 하고있다는 뜻이다. 그렇기 때문에 굳이 게스트OS가 필요가 없는 것이다. 그래서 컨테이너 엔진이 호스트 운영체제를 통해서 모든것을 실행하고 있는 것이다. 그렇게 운영체제를 사용하고 있는 것이다.

위 두개가 달라진 이유는 디자인 철학 자체가 다르다. Container Engine 같은 경우에는 Guest OS가 필요없게 했다. 그러면 가상머신을 구동시키는데 있어서 가상머신도 하나의 물리머신처럼 똑같이 동작을 해야하니 guest 운영체제는 있는게 자연스러운데 어떻게 필요없게 했냐면, container engine아래에 있는 운영체제에 전적으로 의존하고 있다. 커널기능을 사용해서 리눅스에서 사용되는 프로세서이다. 다만 자기들 세상에 갇혀있는 것이다. 단점은 다양한 os로 돌릴 수 있는것이 아니라 리눅스로만 운영 가능하다. 장점은, guest OS가 사라졌기 때문에 이미지가 작다. 그리고 Guest oS 부팅시간이 없기 때문에 부팅시간이 빠르다. 그리고 하나의 물리머신에 구동시킬 수 있는 가상머신들 컨테이너 숫자가 상당히 많이 차이가 난다.

Container based virtualization은 게스트 운영체제가 없으니까 부팅시간도 현저히 차이가 나고 게스트 운영체제가 없으니 이미지화 하더라도 컨테이너방식이 훨씬 가볍다. 경량화되고 빠르기 때문에 컨테이너 기술이 각광을 받고 있다.

그러나 컨테이너 기술에도 단점이 있다.

컨테이너의 어플리케이션들이 커널의 기능을 통해 호스트 운영체제와 공유하고 있는데, 하이퍼바이저같은 경우는 별도의 게스트 운영체제를 띄어주니까 결과적으로 봤을때는 호스트 커널을 공유할 수 있는 것은 리눅스 시스템밖에 없다. 컨테이너 엔진을 실행하면서 Windows 머신을 돌리는 것은 안된다. 그러니까 OS가 무조건 리눅스여야 하기에 운영체제가 제한적이다.

가상머신들 간의 격리성 같은것을 따졌을 때는 기존의 하이퍼바이저 기반의 가상화기술이 더 뛰어난 기술이다. 그러나 경량화 돼서 더 빠르고 컨테이너가 하나의 프로세서 같은 것이기 때문에 자원할당 측면에서 더 용이한 것도 있다.

Everything as a Service

• Utility computing = IaaS
  • 컴퓨팅 자원을 빌릴 수 있는데 왜 굳이 사냐? 라는 개념으로 만들어짐
  • ex) EC2
• PaaS
  • 일반적으로 앱의 개발 및 시작과 관련된 인프라를 만들고 유지보수 하는 복잡함 없이 고객이 어플리케이션을 개발, 실행, 관리할 수 있게 하는 플랫폼 제공 형태
  • 서비스를 개발 할 수 있는 안정적인 환경(platform)과 그 환경을 이용하는 응용프로그램을 개발 할 수 있는 API까지 제공하는 형태
• SaaS
  • 그냥 실행시키면 되는 것
  • ex) Gmail

Virtual machine이 있었기 때문에 앞의 디즈니 사례에서 갑자기 20분안에 필요한 4만 core를 준비할 수 있었다. 물리적인 기계들을 20분만에 사지 못하기 때문이다. 자원을 재빠르게 필요로 하는 어플리케이션에게 충분한 양의 자원을 제공할 수 있는 길을 열었다. 

왼쪽의 컴퓨터는 하드웨어에 운영체제가 하나고 그 위에 어플리케이션이 돌아간다.

그러나

오른쪽은 Virtualized Stack을 보면 Hypervisor위에 여러개의 OS가 있을 수 있다. 결과적으로 봤을 때 하나의 물리적인 자원에서 구동할 수 있는 운영체제의 종류도 다양해진다는 것은 하나의 물리적인 자원을 최대한 잘 공유해서 여러개의 운영체제가 공존할 수 있도록 만든 것이 Hypervisor 기술이다. 

Type 2 hypervisor인 경우, Hypervisor는 App1과 App2와 같은 레벨에서 동작하고 하이퍼바이저 위에서 또다른 게스트 운영체제를 구축할 수 있다.

Type 1 hypervisor인 경우, 하드웨어 위에 바로 하이퍼바이저가 올라가고 그 위에 게스트 OS가 올라가는 것이다. 이것을 다른말로 bare-metal hypervisor(bare metal)이다. 

결론적으로, Type1과 Type2의 가장 큰 차이는 host 운영체제가 있느냐 없느냐의 차이고, Type1같은 경우는 하이퍼바이저가 일정부분 호스트 운영체제를 수행한다고 봐도 된다. 그러면 뭐가 제일 다르냐면 Type1 같은 경우에는 데이터센터에 들어가는 서버에서 많이 사용되는 bare metal hypervisor이다. 왜냐하면 개인용 pc이나 노트북 같은 경우에는 드라이버 같은 경우에는 다양할 수 있다. 그러니까 호스트 운영체제가 담당을 해주고 그 위에 하이퍼바이저를 올리는게 하이퍼바이저 입장에서도 부담이 적다. 디바이스를 접근할 때 호스트 운영체제의 도움을 받으면 되는데 만약에 type1처럼 하면 모든 디바이스를 하이퍼바이저가 어느정도 컨트롤할 수 밖에 없다. 서버같은 경우에는 컴퓨팅 자원이기 때문에 설치되는 디바이스들이 다양하지 않아서 상대적으로 관리하기 편하다. 그래서 type1인 bare metal hypervisor 같은 경우에는 서버급에 많이 사용되는 가상화 기술이다. 보통 사용자들(노트북, 퍼스널 컴퓨터)은 type2를 사용한다.

• type1같은 경우는, 별도의 작업 없이 컴퓨팅, storage만 하기 때문에 hypervisor가 관리해야하는 주변기기 장치가 다양하지 않기 때문에 상대적으로 하드웨어 위에서 컨트롤이 가능하다. 그래서 이 타입은 데이터센터에 들어가는 서버용이다.
• 반면, type2같은 경우는, 퍼스널 컴퓨터나 노트북은 다양한 어플리케이션을 돌린다. 그러기 때문에 호스트 운영체제에 의존하면 된다. 왜냐하면 어차피 호스트 운영체제가 구동되는 상황이면 호스트 운영체제가 모든 자원을 컨트롤 하고 있으니까 이것을 통해서 접근하면 된다. 그래서 이 타입은 범용적인 못적으로 사용한다.

맥북 같은 경우는 Mac os위에 parallelize가 hypervisor위에 올라가고 그 위에 윈도우 같은 것을 구동시킨다.

Hypervisor는 하드웨어로 부터 추상화 개념을 제공하는 소프트웨어이다. 왜냐하면 물리적인 하드웨어를 추상화 시켜서 게스트 운영체제에 다 전달할 수 있기 때문이다.

Hypervisor의 특징은 하이퍼바이저 위에 전혀 새로운 운영체제가 올라갈 수 있는 것이 key point이다.

클라우드는 프로그램과 어플리케이션들을 운영 하는 네트워크로 연결된 컴퓨터들의 집합이다. 로컬 하드디스크에 설치되어있는 것이 아닌 연결된 데이터 서버들에서 구동되는 프로그램과 어플리케이션들이다. 클라우드 컴퓨팅은 어쩌면 가상의 호스팅 솔루션(Virtual Hosting Solution)이다. 

IaaS

• 서버/스토리지/네트워크 등의 H/W 자원을 필요에 따라서 사용할 수 있게 제공하는 형태
• Is what You use

PaaS

• 서비스를 개발할 수있는 안정적인 환경(Platform)과 응용 프로그램을 개발 할 수 있는 API까지 제공하는 형태
• Is what Developers use

SaaS

• 클라우드 환경에서 동작하는 응용프로그램을 서비스 형태로 제공하는 형태
• Is what IT departments use

Utility Computing

• What?
  • 컴퓨터 자원을 metered service(measured service => 계량화 될 수 있는 서비스) 사용한 만큼 돈을 지불하는 것이다. Utility computing은 가상 머신들을 동적으로 구동시킬 수 있다. 이 의미는 뭐냐면, 컴퓨터가 여러대 필요하면 당장 살 수 없으니 컴퓨터를 클라우딩 서비스를 통해 대여하는 것이다.
• Why?
  • 비용(Cost): 초기 투자 비용을 운영 비용으로 변환시킨 것이다.
  • 확장성(Scalability): 클라우드 사업자는 충분한 컴퓨팅 자원을 제공할 수 있다.
  • 탄력성(Elasticity): 수요에 따라서 탄력적으로 사용할 수 있다. 그래서 이러한 장점들 덕분에 수요자와 공급자가 윈윈 할 수 있는 구조이다.
    

초기에는 작업이 없다가 중반으로 갈때는 점점 작업이 많아지는데, 작업이 없을때는 클라우드 자원을 조금 쓰다가 작업이 많이 필요하면 많이쓰면 수요와 공급이 맞아떨어지면서 굉장히 효율적인 자원운용이 된다. 관건은 비용이다.

On-premises capacity의 문제는 처음에 사용하지 않을 때는 capacity가 남아돈다. 어떻게 생각하면 낭비가 되는 것이다. 중반쯤 되면 작업량이 많아지면 on-premises capacity를 넘어가게되고 밀려서 deadline에 가까워진다. 그런데 파란색 선 처럼 클라우드가 요구하는 만큼 자원을 계속 공급해줄 수 있다면 끝나는 시간을 왼쪽으로 땡길 수 있다. 작업을 빨리 끝낼 수 있게 scalable한 작업을 제공한다. 디즈니는 4만개의 cpu core를 20분만에 실행 시킬 수 있었다. 

이러한 elasticity와 scalability를 구현하기 위해서는 물리머신만으로는 될 수 없고 반드시 가상화 기술을 사용해야만 한다.