#8 Datacenter Management

굉장히 많은 요소들이 데이터센터에 들어가는데 우리는 주로 HW를 다뤄왔다.

 

오늘은 resource manager를 볼 것이다.

 

Point of Deployment를 꾸민다고 할 때 HW적 요소의 준비가 끝났다고 가정해보자. 이제 configuration을 해야하는데 일일이 수작업으로 하기에는 수가 너무 많다.

 

때문에 원격 관리 단말에서 접근할 수 있도록 하면서 관리자가 작성한 스크립트에 의해 자동으로 configuration을 생성해주는 프로그램들이 필요하다.

 

많이 보는 것은 ansible, docker 등

 

configuration까지 끝났으면 application이 깔려야한다. (application deployment)

application deployment를 하는 것은 application의 lifecycle까지 관리한다.

openstack, kubernetes가 이러한 기능을 담당한다.

 

application을 깔고 사용하듯 application을 가동하는 단계가 필요하다.

컴퓨터 안에 여러 어플이 있으면 각각의 이름이 필요, 이름이 있으면 필요한 어플을 탐색하는 과정이 요구된다.

DNS로 접근하는 방식 등

 

 

오늘의 focus는 application deployment이다.

application이 돌아가기 위해 요구하는 사항들 (how many and which resources app requires) 체크

resource assignment를 위해 resource management까지 연계가 되는 것이다.

 

가장 기본적인 방법?

physical machine이 주어지면 이를 여러 virtual machine으로 가상화한다.

예전에는 CPU 코어 숫자가 작아 physical machine 수를 직접적으로 늘리는 것보다는 가상화를 시키는 것이 비용적인 측면에서 효율적이었을 것이다.

 

1. 코어가 아무리 많아도 유저 각각은 기기를 혼자서만 쓰고 싶어한다.

2. application의 크기는 정말 diverse하다. 이러한 diversity에 일일이 맞춘 HW를 모두 마련하기란 불가능하다. (flexibility)

 

각자의 requirement에 맞춰서 자원을 나눠주기 위해 자원을 carving하는 것이 시작이다.

 

---

자원 분배 옵션

컴퓨터 100대를 운영할 때 어플 10개가 존재한다.

 

1. 공평하게 10대씩 분배한다.

2. 필요한 요구치를 최대한 맞춰서 분배한다. -> 문제는 요구량이 자원보다 많으면?

비례배분해서 주거나, 시간별로 돌아가면서 배분하거나, 일부는 포기시키거나

 

다른 방식으로는 각 어플의 중요도를 따져보는 방법이 있다.

 

물리적으로 자원을 partition하여 각 어플에 귀속시키는 방법이 private assignment (static)

시간대별로 time slice 내어서 자원을 완전히 귀속시키지 않는 방법이 shared assignment (dynamic)

모든 상황에 요구치의 자원이 사용되는 것은 아니기 때문

 

서버는 shared된 방식으로, storage는 partition 방식으로, network는 어느정도 비례배분적 성격으로 (packet 수에 따른 dynamic 배분)

 

 

 

private resource assignment의 장점

1?. 각 어플이 얼마나 자원을 잡아먹을지를 산정할 수 있다면 간단 -> 어떻게 산정할 건데?

악의의 사용자가 과도한 자원을 요구한다면?

프로파일링을 해보고 트래픽을 본다? -> 자원 할당이 여러번 생긴다.

과거 이력을 보고? 과거에 있지 않았던 트래픽이 생길 수 있다 (선거, 지진 등)

다른 업체에서 비슷한 어플을 돌린 이력이 있다면 이를 활용할 수 있을것이다.

 

실질적으로 모니터링 외에는 방법이 마땅치 않다.

대부분의 시간에서 필요한 양은 private으로 할당하고 peak 발생시에는 shared로 추가로 할당한다.

마냥 간단하지만은 않다.

 

2. Performance Isolation (이게 핵심)

특정 어플리케이션은 간섭되면 큰일난다. (은행 등)

시스템이 안전하다는 것을 보증할만한 것이 필요하다.

mission critical 한 것들은 assign이 반드시 되어야 하므로 private assignment를 요구한다.

 

3. HW specialization

강좌 초기에 설명을 했는데, 데이터센터라 해도 다 같은 서버를 쓰는 것이 아니다.

필요한 일에 가장 적합한 서버를 골라 작업에 배정한다면 효율적으로 일을 처리할 수 있다.

 

private resource assignment의 단점

1. 어떻게 자원을 배정할 것인지가 가장 주요한 challenge가 된다.

2. 1의 특성 때문에 일정 자원 이상을 배정하면 inefficiency와 low utilization이 항상 발생하게 된다.

 

외부의 requirement에 따라 반응하는 경우에는 더더욱 예측이 어렵다.

때문에 tool을 두어 private과 shared 기법을 적당히 섞어 쓰는 방법을 채택한다.

 

work load는 1개, 유저도 1개, private으로 배정 받은 자원이 있다. shared로 예비 자원도 있다.

load balancing을 어떻게 하는 것이 좋은가?

1. private으로 배정받은 자원에 균등 분배한다. (round robin)

문제는?

- 잘못 분배하면 세션 정보의 migration에 따른 비효율성이 발생한다.

- 개별 job의 length가 달라질 때, 한 곳으로 긴 job이 몰리면 inefficiency가 발생한다.

 

2. post assignment

private으로 수용할 수 있는 job이 꽉 찼을 때 shared로 추가 요청해서 배분한다.

-> monitoring과 기준치가 요구된다.

 

3. 프로파일링에 의거한 workload preview

 

이 중 어떤 것으로 load balancing할지는 응답 latency 규정에 따라 결정할 수 있다.

특정 작업을 수행함에 있어 latency가 길어진다면 현 load balancing으로는 충분하지 않다는 것이다.

자원이 부족하다는 전조는 어딘가에서 나타난다.

 

왜 request 처리 시간으로 기준을 잡는가? 그냥 CPU 사용량으로 따지면 안되나?

CPU 사용량, 네트워크 차지 비중 등 자원 사용량만을 기준을 삼기엔 모자란 것이 있다.

 

자원 사용율은 절대로 일정하지 않다.

같은 work 내에서도 실시간으로 fluctuate하며, 우리가 바깥에서 관측하는 것은 average 값이다.

단시간 내에 자원 사용이 몰리면 평균적으로는 문제가 없어보이지만 해당 시간에 들어온 task는 모두 latency가 길어진다.

 

---

tail latency를 줄이기 위한 방법

1. reduce head of line blocking

convoy effect라는 것이 있다 (호위 효과)

앞선 request가 길어서 뒤 job들이 처리되지 못하는 상황

해결은?

- supply를 늘려서 후속 job이 처리될 수 있도록 한다.

- queue를 다중화하여 오래 걸리는 것들과 간단한 것들을 분류한다.

 

2. coordinate background activities

background jobs가 언제 튀어나올지 몰라 latency가 어느 시점에 증가할지 예측할 수 없었다. 이를 예측 가능하도록 만들어준다. (arrange)

 

3. hedged request to replica

여러 서버에 동시에 같은 request를 던진다.

각 서버마다 workload, 서버의 이상(cache disabled)으로 처리 속도가 달라질 수 있다.

물론 latency를 안정화시키면서 줄일 수는 있지만 비용은 배가 될 것이다.

 

4. canary request

탄광에서 카나리아가 경고를 하듯이 임의의 request를 시험삼아 던져봐서 latency를 측정하고 만약 나쁘다면 해당 서버로는 request를 보내지 않는다.

 

---

shared assignment -> dynamic하게 실시간으로 workload를 측정하면서 부족하면 request해서 서버를 할당

각 어플리케이션마다 중요한 자원의 종류가 다르다.

각 type이 준비되어 있고 필요한 type을 요청해서 받는다.

 

cluster manager design

centralized -> logically single manager가 모든 것을 담당

two-level -> 최상위 스케쥴러와 그 하위 child 스케쥴러가 돌아간다. 주기적으로 정보를 주고 받으면서 mitigate

분산형

 

장단점은 각자 생각해볼것

 

---

 

shared cluster의 장점

flexible한 대응이 가능

자원 활용의 efficiency 상승

 

단점은?

아마존을 생각해보자.

inefficiency : 특정 workload에 최적화를 하지 않는다.

needs에 따라 각 서버에 자원을 분류해놓고 필요한 것을 할당한다고 해도

workload를 알고 설계하는 것과는 차이가 있다.

 

트위터와 구글을 모니터링한 결과를 보면 전체 시간 중에 CPU utilization이 대부분 20~30%에 머무르고 있다.

왜 utilization이 이렇게 낮을까. fluctuation에 따른 것으로 unpredictable한 상황에 대비해 자원을 충분히 확보해놓은 것이기 때문이다. 점유만 미리 해놓은 것이기 때문에 oversize된 자원을 할당받아 돌아가고 있는 것이 대부분

 

Autoscaling -> load balancing을 프로그래밍화, 자동으로 자원을 배분한다.

 

load prediction : 과거의 behavior를 보고 패턴이 지속될 것이라 예측하는 것 (past analysis)

과거에 발생하지 않은 것들에 대한 것은 prediction이 안된다.

 

moving window average

exponentially weighted average

markov chain predictor -> system을 state machine으로 보고 과거 데이터 기반으로 어떤 상황에서 transition이 일어나는지 분석, phase 변화에 따른 패턴을 예측한다.

 

wavelet transform

전체 utilization은 여러 component에 의해 결정되는 것이므로 각 component 별로 utilization을 decompose하여 각각에 대해 MC predictor를 돌려 다시 합친다.

 

classification predictor

여러 utilization pattern을 준비해두고 moving window에서 어떤 패턴이 가장 적합한 패턴이 될지를 분석해 추후 utilization을 파악한다.