#2 Datacenter HW

다시 상기 Datacenter Metric :

- Throughput

- Tail Latency : 일정 이상만 빠르면 된다. 무조건 빠르기만 한것이 능사는 아님

- Total Cost of Ownership

- Availability & reliability

- Power Usage Efficiency -> TCO에 포함되어 있는데 왜 다시 강조하는가? 비용을 깎자 이상의 의미가 있다.

전기 자원은 끌어올 수 있는 절대양이 한정되어있기 때문이다.

돈이 많으면, 서버든 사람이든 바로 구할 수 있으나, DC에 들어가는 전기양은 돈을 낸다고 해서 바로바로 구할 수 있는 것이 아니다.

-> 변전 설비 추가 구축 등 생각할 것이 많다.

저장 장치도 단기적으로는 HDD보다 비싸지만 전기 소모가 적은 SSD 같은 것을 추구하는 것이 이런 이유의 연장선

성능상의 이유가 아닌 전력 소모의 이유로 교체

전력은 구하기도 어렵고, 증량도 어렵다

 

번외)

- 추가 전력 소모 대비 성능 개선이 특정 수치 이하라면 효율적이지 못한것

- 쿨링은 어떻게 효율적으로 할 수 있는가?

 

기본적으로는 각 Rack에 Coolant Distribution Unit이 존재해서 액체가 서버에 집중된 열을 외부로 뺀다

외부로 뺀 열을 수냉/공냉으로 처리

최종 단계는 결국 환기

 

Microsoft는 바다로 직접 cooling

컨테이너 규모로 rack을 배치, 바다로 수장

우리나라 DC는 넣은 적이 있을까? No

환경 문제 + 바다에 넣는다면 유지보수를 포기한다는 선언과도 같기 때문에 잘 하지 않는다

데이터 센터 부품은 잘 고장나기 때문에 웬만해서는 바다로 넣지 않는다.

 

---

 

Cluster (POD : Point Of Deployment)

 

Rack 구조를 보면

주로 상단부터 Server Management Switch, Networking Switch, 서버(여러 대), Storage(JBOD) 구조다.

 

왜 Storage는 주로 아래 꽂히는가?

주요한 원인 : 서버를 꺼내기 편해서

서버는 그때그때의 workload, 장애 상황에 따라 교체가 잦다.

storage는 기본적으로 하나를 꽂아놓고서는 교체가 많지 않다.

때문에 교체가 불편한 최하단에 위치시켜서 server를 꺼내기 편하도록 위치하는 것이다.

+ 이러한 구조는 서버가 나가는 네트워크 스위치와 storage가 나가는 네트워크 스위치를 분리시킬 때 용이하다

 

전력 이중화, power supply unit 도 2개

하나가 고장나더라도 전력이 공급되도록

이중 한쪽만 꽂으면 과전류 등으로 인해 문제가 생기기도 한다.

 

Rack Management Card -> Rack에 들어가는 전력을 monitoring하는 것

PDU에 모니터링 장비가 붙어서 전력을 관리한다.

전선 하나가 fail 된다면 모니터링 장비로도 알아낼 수 있겠지만 서버 등 장비들이 충분한 전력을 받지 못해 꺼지는 것을 통해서도 알아챌 수 있다.

전선을 이중화, 삼중화하는 경우에는 양쪽 다 전류가 흐르는 것이 아닌 주 전력이 끊겼을 때 전류를 흘려보낸다.

보조 전선이 끊기는 것을 detect하는 설비는 없기 때문에 정기적인 정비가 필요하다. (물론 잘 안함....)

6개월에 한 번씩 power recycling (전체 껐다 켜기)로 검사하기도 한다.

 

번외)

- 1U, 2U, 4U 등 2의 거듭제곱이 일반적인 서버 규격이나, 3U도 존재하긴 한다. (공간 활용을 sales 포인트로 사용)

 

---

2-socket 서버

서버 한 판을 뜯어보면

중요한 unit에는 방열판 같은 것이 붙어있다. (CPU 구성)

CPU 옆으로는 DIMM이 붙는다.

PCIe 슬롯에 네트워크  카드를 넣고

PCH (Platform Control Hub) -> CPU 포트에 한계가 있어 CPU와 연결되어 스위치 역할을 해주는 것

VGA 카드

BMC (Board Management Card) -> 원격에서 서버 관리를 해줄 수 있게 하는 것 (펌웨어 관리, 온도 관리 등)

M.2 -> SSD 등을 꽂기 위한 PCIe보다 작고 쉽게 꽂을 수 있는 포트, 주로 고속 ssd 연결 사용

앞 쪽 부분은 SATA -> 저장장치 연결

 

---

하드웨어 규격은 표준화, workload 종류에 따라 서버는 세분화될 수 있다.

자체적으로 설계한 것을 쓰기도 한다 (Yosemite 페이스북 서버)

고집적 서버 : 42U 규모의 rack에 128개의 서버가 꽂혀있다. 

장점 -> 공간 활용 (compactness)

단점 -> 쿨링이 버겁다? 생각보다는 발열이 심하진 않다

 

독특한 점) 각각의 서버가 1 socket 서버이면서 서로 communication이 안될 정도로 따로 나눠 쓴다. 페이스북 특성상 workload 최적화는 이루어진 것이다.

read/write 중 read ratio가 높은 편, 메모리 중심의 independent한 request, 빠른 return 중시

작고 단순한 메모리 중심의 일을 할 수 있도록 최적화된 설계 -> 때문에 높은 연산이 요구되지는 않아 발열은 잡을 수 있다.

-> 연산 위주로는 꽝이라는 뜻

 

데이터 센터 관리를 로봇이 하도록 바뀌는 요즘 트렌드상 크기가 너무 작기 때문에 수정이 필요해보이긴 한다.

만약 사람이 관리한다면 페이스북 workload 상으로는 최선일듯하다.

 

---

Storage

규격이 정해져있어 여러개를 꽂을 수 있도록 되어있는 하드디스크

Just Bunch Of Disk -> 디스크가 거의 전부 (부팅을 위한 CPU 제외)

N+1 로터 팬 (공냉)

N+N redundant PSU (하나 당 보통 2개의 파워 서플라이 공급)

 

저장 장치이기 때문에 열 걱정은 적다

 

SAS / SATA 등으로 연결

22개의 HDD가 HSC (Hot-Swap Controller)에 연결되어 있는 구조

 

Flash

여러개의 flash disk를 m.2를 통해 연결해놓는다. 공간도 덜 잡아먹고, 열도 덜 발생하고, 전력 소모도 덜 하지만 비싸다.

서버 하나 딩 본인의 PCIe 연결 단자를 외부까지 extend하여 PCIe Switch에 연결함으로서, connectivity topology 차원에서는 내부에 꽂은 SSD와 차이가 없게끔한다.

PCIe 버스가 multiple 서버에 걸쳐서 구축이 된것

 

GPU

PCIe는 bandwidth제한이 있어 NVLink를 통해서 GPU끼리 통신한다.

원래는 추론용에는 메모리가 많이 필요 없었으나, 지금은 추론할 때도 parameter가 많아 DRAM 요구량이 늘었다.

 

왜 서버당 2 소켓 이상은 잘 꽂지 않을까?

보드 안에 4~8개 씩 CPU를 꽂는 경우도 있다. 이 경우엔 CPU 간 통신이 아주 중요한 경우로, 케이블 통신이 부담이 될 경우 채택한다. 주로 슈퍼 컴퓨터가 이렇게 사용했으나, board integration에서 탈출하려는 노력도 있다.

 

다시 질문으로 돌아가서, 요즘 코어가 여러개 필요한 경우의 연산은 아예 GPU로 돌리기 때문에 2 소켓 이상은 잘 하지 않는 것이다. facebook 같은 저연산, 다코어가 적합해보일 것 같은 경우도 차라리 메모리를 많이 꽂고 1U 서버를 쓰는 것이 가성비 상으로 좋다.

 

애초에 DC 규모가 커져버리면 서버 간 communication이 bottleneck이기 때문에 improvement가 적어진다. 

서버 내 communication이 전체적으로 미치는 benefit이 줄어들기 때문에 2 소켓 이상은 효과가 미미하다.

 

8 소켓은 GPU에 쓰임

2, 4 소켓 CPU는 잘 쓰인다. 가격도 exponential하게 상승한다. 2 소켓이 주로 dominant하고, 규모의 경제에 의해 2 소켓에 주로 다 상주해 있는 상태

 

페북이 1 소켓인 이유는 workload에 최적화 되어있기 때문, 페북 혼자만으로도 규모의 경제를 이끌어낼만큼 workload가 크기 때문에 가능하다.

 

---

 

지금까진 몇 소켓을 넣는지만 얘기했는데, 강력한 칩을 적게 쓰는 것과 약한 칩을 여러개 쓰는 것을 비교해보자.

 

인텔 Xeon과 Atom을 비교해보았다.

QPS 상으로는 Xeon이 뛰어나나, 가격은 Atom이 저렴하다. 때문에 가성비 측면에서는 Atom이 2배 정도 좋다.

그런데도 Atom으로 도배된 서버를 쓰지 않는 것은 다음의 이유 때문이다.

- tail latency 측면에서 latency variance가 Atom이 크기 때문에 load balancing을 정말 잘해야 평타다.

- 훨씬 더 큰 이유로는 software적인 이유로, 같은 프로그램을 짜더라도 이를 여러개의 core에 맞춰서 효율적으로 실행시키기 위해 적절하게 load를 분산시키는 것은 굉장히 어려운 일이다. 때문에 software engineering cost가 HW로 아껴지는 cost를 상회한다.

 

HW 아키텍쳐는 SW적으로 많은 노력을 들이지 않더라도 원하는 성능을 뽑아낼 수 있는 구조가 이상적이다.

 

---

 

Accelerator

Google TPU -> AI 목적으로 제작, 업그레이드 주기가 빠른편 (AI 발전에 맞춰서)

GPU에 비해 굉장히 빠른 속도를 낸다고 논문에 나와있지만, 실제로는 조금 다르다.

 

단순 throughput 상으로는 GPU가 우월하다. 다만 애초에 NVdia에서 GPU를 설계할때 99%의 request에 대한 응답이 일정 latency 안으로만 떨어지게끔 자원을 소모하도록 설계되었다. 잉여 자원이 있다 하더라도 놀게 놔둔다.

 

TPU는 애초에 설계상 latency를 고려에 두고 설계되었기 때문에 이를 비교하면 차이가 날 수 밖에 없다.

때문에 측정되는 workload에서만 더 좋은 것이다. 

 

Throughput Oriented GPU / Latency Oriented TPU

NVdia에서도 만들수는 있을 것이다.

 

---

 

FPGAs

단일 서버 내에서도 완벽하게 네트워크 카드가 구축이 되어 있지만, 외부에 카드를 하나 더 두어 외부로 나가는 회선을 물도록 함. CPU로 가지 않고 자체적으로 외부의 데이터를 받아서 처리하거나, CPU에 있는 데이터를 offload로 받아서 처리해준 뒤 결과를 외부로 보낸다. (Through Top of Rack Switch, TOR)

 

CPU 단까지 내려가서 일하는 것보다 FPGA HW단(acceleration 할 수 있는 computing 자원)에서 처리하도록 하는 것이 빠른 경우가 있다. (Bio 시뮬레이션 / Deep Neural Network / Web Search ranking / 데이터 compression)

 

---

Disaggregation

- 각 서버별로 용도에 따라 workload가 다름

- JBOD 처럼 컴퓨터의 부품을 외부화시켜도 큰 문제 없음

이를 종합해 서버의 각 부품을 조각내서 전부 하나의 거대한 보드인 sled로 만들면 어떨까에서 착안

-> 용도별로 각 부품 sled의 양, 밀도를 조절하는 방식

 

CPU만 집적 / 메모리만 집적 / flash / storage / network ...

이를 software defined hardware라고 부르기도 한다.

 

장점 : workload에 따라 할당 자원을 유동적으로 바꿀 수 있다.

단점 : 전선 외부화로 인한 에러 가능성 증가

 

실제 use-case가 상당히 많은데 문제는 없는가? 딱 봐도 메모리는 문제가 있어보이는데

 

CPU 안에는 cache가 있다. (SRAM L1 ~ L3)

그럼 DRAM은?

on - board에도 L1 DRAM이 있다.

RAM sled는 L2 DRAM의 역할을 하는 것이다. 때문에 latency가 그렇게 길지 않다.

 

Flash도 세분화할 수는 없을까? 이것도 하기도 한다. (SLC, MLC, TLC ...)

핵심적인 것은 촘촘하게 계층 구조를 유지하는 것

 

높은 사양의 네트워크 카드는 필요

 

우리나라는 주로 Rack에 10GB 급의 선을 쓰는데, 대부분의 operation이 하나의 서버 안에서만 돌아가기 때문이다. disaggregate도 쓰지 않는 경우 많다.

 

외국은 표준으로 100GB 급의 선을 쓰는데, HW flexibility가 요구되어 이러한 disaggregated 구조를 사용하는 경우가 많기 때문에 rack level의 networking이 고도화되었기 때문이다.