#1 Datacenter Introduction (Overview)

Datacenter

엄청나게 큰 건물에 엄청나게 많은 수의 컴퓨터가 들어있는것

개인적, 공용적 (가상화 가능) 목적

규모의 경제

 

실제로는 어떤 느낌인가

1만 ~ 10만대 이상의 서버 집적

20~50 MW, 최근엔 100MW 급의 DC 건설

 

어느 회사나 일정 규모 이상이 되면 전산실이 생긴다.

이것의 scale-out version

 

내부 자원들의 소통, 외부와의 연결

 

땅이 넓은 곳으로 가면 단층으로 짓는 경우가 많다.

서버의 무게 때문에 복층으로 짓기 어렵고, 넓은 부지에 단층으로 주로 건설

 

HW, SW, 냉각 설비등의 인프라를 종합설계, 지구상의 가장 큰 computation 자원 설계

자원이 있으면 전기가 필요, 전기가 공급되면 열이 발생, 열이 발생하니 냉각 필요

일정 온도 이상 올라가면 컴퓨터가 제대로 작동하지 않음

수력 발전소 근처는 냉각과 전기 공급이 모두 용이하니 근처에 건설하는 경우가 있다.

설계는 장소에 따라 달라질 수 있다. (전시 효과, 미관, 효율 등등)

 

왜, 어떻게 시작되었을까?

- 많은 회사들이 본인들의 전산 자원을 활용하기 위해

- 주로 스타트업이 서비스의 빠른 구축을 위해 클라우드 데이터센터를 활용하여 deploy할 때가 많다.

 

시작은 모두 private이었다.

본인들이 쓰기 위해 DC 설계

 

아마존 세미나 : 쇼핑몰 request 처리양과 클라우드 사업의 request 처리양이 비슷한 수준까지 도달한 발표

-> 클라우드 사업은 통한다. (남는 자원을 활용한 장사)

 

workload의 fluctuation이 심하기 때문에 자원은 worst case를 고려하여 마련했으나, request가 몰리지 않을 때에는 잉여 자원이 된다. 자연스럽게 잉여 자원을 활용해서 돈을 벌기 위해 public 서비스로 연결된 것

 

그럼 자원을 모아놓은 이유는?

큰 고객을 받기 위한 자원의 절대양이 많은 것도 있지만, 한꺼번에 모아서 관리하면 편해지는 점이 있다.

recommendation, promotion, 분석, 재고 관리 등등

자원을 한 곳에 모아놓고 필요한 부서에 필요한 정보를 보내는 것이 flexible한 대처가 가능하고 효율적이다.

 

HW Overview

각각의 서버, 서버를 연결하는 네트워크 카드, Just Bunch of Disk, Just Bunch of Flash Memory

 

HW Heterogenity

다 똑같이 만들어서 여러대 연결만 했으면 간단했겠지만,

각 서버는 용도에 따라 HW의 요구사항이 다르다.

Web 담당은 빠른 연산이 요구 -> 고스펙의 CPU가 필요, 디스크 양은 적어도 되지만

DB 담당은 많은 양의 디스크를 요구한다.

 

서버들을 모아놓은 것을 Rack (기다란 캐비닛 모양)

Rack을 여러대 모아서 관리하는 것을 Cluster, 또는 Pod라고 한다

 

DC Storage Hierarchy

특이사항) Rack Switch를 거친 다른 DRAM Access가 본인 Disk에 접근하는 것보다 빠르기도 하다.

서로 다른 latency를 어떻게 관리할 것인가가 문제로 떠오르기도 한다.

 

숫자는 감만 잡아라

L1 cache reference ~1ns

L2 cache reference ~10ns

Main Memory reference ~100ns

Network ~1us

데이터 센터 내에서 왔다갔다 하는 데 ~1ms

외부에서 데이터센터 소통 ~10ms

---

SW

cluster resource manager (openstack)

data services management (HDFS)

application-lvl services

 

MapReduce -> 한 작업을 여러 컴퓨터에 나눠서 분산 처리

Social Networking -> 전체 서비스를 여러 티어로 분할, 

Search

 

Tiered Application (옛날 방식)

각 분야의 전문가들이 특정 단계를 핀포인트하여 optimize, tuning

특정 부분이 죽더라도 그 부분만 수정하면 되도록

 

요즘 트렌드는 micro-service

서비스를 굉장히 작게 세분화, 모듈화하여 그것들을 묶어서 서비스하도록

이러면 작은 모듈별로 업데이트가 가능하여 빠르게 변화하는 시장에 대응 가능

작게 쪼개지면 pin-point로 scale-up, out이 가능

단점은? 실제로 쪼개야 한다는 것.

뭐든 많이 쪼개면 복잡하다. Interface 설계는 전체적인 업무에 대한 이해가 필요해지니 어려워진다.

각 component간의 communication을 어떻게 효율적으로 할 것인지도 issue

 

---

데이터 센터를 사용하기에 적합한 app은 어떤 것인가? Huge한 것들

 

데이터양 많고, 유저 많고, 할당 자원양 많고 -> high level of parallelism required

workload가 많이 fluctuate하는 것

reliable한 운영이 필요한 applicaiton

 

Cluster Management -> 이후에 자세히 다룰 것

서버 단위에서 설정 자동화  (puppet, chef, ansible)

SW 배치될 때 어떻게 연계되어서 돌아갈 것인가

 

DC를 잘 지었는가를 어떻게 평가할 것인가?

- throughput : 단위 시간내에 얼마나 많은 request를 처리할 수 있는가

- QoS : 많은 요청들이 일정 시간 내에 처리되는가? (Service Level Agreement)

 

ideal 하게는 같은 반응 시간 내에 나와야 할 것 같지만 실제로는 여러 factor가 작용한다.

- interference : background task 등 다른 application과 공유해서 자원을 사용하기에 간섭 현상 발생

- 자원 heterogeneity로 인한 차이

- power 문제로 인한 차이

- input load : 자원이 몰려서 사용될 때는 어쩔 수 없이 delay가 커진다.

-> request의 minimum과 maximum 차이가 클 때, 대응을 할 수 없는 가능성이 크다.

환경 문제, 정치, 사회적 현상 등으로 인한 variability

 

이를 줄이기 위해서는?

당장 급하지 않은 background task의 자원을 더 적게 분배해서 느리게 처리한다거나,

ssd garbage collection 같은 background task는 다른 작업에 큰 영향을 주기 때문에 잘 처리할 필요가 있다.

오래 걸리는 작업을 잘게 나누어 각 작업에 영향이 적도록 조금씩 처리하는 것

 

또다른 DC 평가 기준 - 비용 부문

구축할 때 비용 capex

운용할 때의 비용 opex

이걸 다 합친게 total cost

 

opex 중에서 가장 큰 비중을 차지하는 것은 전기비용

PUE는 그러한 전기를 얼마나 효율적으로 쓰는가를 평가하는 척도이다.

 

PUE = 전체 facility power (IT + 냉각 + 배전 등 전체 전기) / IT에 사용된 전기 power

이상적으로 cooling 등 overhead가 전혀 없다면 1.0이 뜰것이다.

실제로는 cooling이 존재하므로 1보다는 큰 값이 된다.

예전에는 2.0 정도로 운영되었으며, 1.07~1.12는 굉장히 잘한 경우이며, 주로 있는 DC는 1.5~1.6 정도로 운영된다.

모든 것을 control할 수 있으면 1.3 정도로도 낮출 수 있다.

 

다시 total cost로 돌아가서

실제 땅값도 무시할 수는 없음. (대부분 수도권 건설)

인건비, 전기, 인터넷 등 monthly로 나가는 비용들 관리해서 total cost ownership을 줄이는 것

 

enterprise vs internet-scale

enterprise -> 서버 100대당 사람 1명이 관리

google 급 -> 서버 1만대당 사람 1명이 관리

 

---

Reliability & Availability -> 해당 lecture 가서 자세하게 설명