#4 Large Scale Storage

다시 상기할 것들 : 

 

- JBOD (Just Bunch of Disks) : 세로로 꽂는 디스크들의 집합체

예시 Project Olympus

 

- flash storage에서 케이블링을 통한 expansion (마치 한 보드 안에서 PCIe 케이블 상으로 연결된 것처럼 느끼게 함)

JBOF (Just a bunch of flash disks)

 

- Disaggregated Rack

JBOD, JBOF 처럼 나머지 부품들을 나눠서 전체 서버를 구성

Software defined Hardware라고도 한다.

 

2U sled에 1 PetaByte 용량의 디스크 확보, 요즘은 단일 rack 하나로 20 PB 정도의 디스크 사용이 가능하다.

 

rough comparison (DRAM : Flash : Disk)

비용은 100 : 3 : 1 

random access 일 경우 access latency 1 : 5000 : 1000000

 

디스크는 random access의 경우 헤드가 물리적으로 스핀하는 디스크를 읽어야하기 때문에 시간이 오래걸리는 것이고

sequential하게 읽는다면 flash와 비슷한 수준까지 나온다.

 

flash는 latency 위주가 아닌 다른 aspect 위주의 변화를 추구한다.

cost는 낮추고, bandwidth와 capacity를 늘린다. 다만 단일 cell의 write에 따른 수명은 떨어지게 된다.

이것을 발전이라고 볼 수 있는가?

 

무조건 QLC가 SLC보다 좋다고 하기보다는 DRAM과 Disk 사이에 여러 옵션을 제공한다고 생각하면 될 것이다.

궁극적으로 지속된다면 HDD는 사장되고 Flash가 그 시장을 먹을 것으로 전망

---

지난 수업 때 들었던 Flash Cell 구조 복습

 

전자가 floating gate에 들어가 있지 않은 것이 '1'이라고 하는 이유

예전에는 ROM에서 mechanically connected 된다면 1, 아니면 0이라고 하는 상태였다.

퓨즈가 연결되어서 1이라는 컨셉이 여전히 살아있기 때문

 

2개의 bit을 저장한다는 것

-> 전자 status를 좀더 세분화화여 관리

 

read/write latency 증가

capacity 증가

가격 감소

 

bandwidth는 PCIe의 발전, nvme 프로토콜의 발전으로 증가

 

빠르지만 less dense한 SLC

느리지만 dense한 MLC

 

density가 2배로 됐는데 가격은 왜 2배 이상 줄었을까? 규모의 경제 (mass production)

읽고 쓰는 것에 있어 reliability의 구분

 

0을 쓴다 -> 전자를 넣는다 (전류가 흐르지 않는다)

1을 쓴다 -> 전자를 빼서 fatory default로 만든다 (전류가 흐를 수 있는 상태가 된다)

 

0을 쓰는 방법 -> cell을 읽는 것과 비슷하지만 더 강한 전압을 건다.

전자가 insulator를 뚫고 들어온다.

 

쓰고 있는 원리가 똑같으면 왜 MLC일 때 lifecycle이 줄어들까?

- binary 형태의 programming (한번 write하고, 두번째에 세부조정 필요) -> mechanical write 횟수가 많다

- insulator 기능이 점차 약해짐에 따라 blob의 크기가 커져 비트 구분 사이의 간격이 점차 줄어든다 (MLC일 때의 간격이 애초에 더 좁으므로 더 짧음)

 

program cycle / erase cycle 중에서 erase cylce만 세는 이유?

결국 한 번 program하면 다음 값으로 새로 쓰기 전에 erase가 한 번 이루어진다.

왜 그래야 하는가?

 

쓸때는 개별적으로 할 수 있지만 뺄 때는 substrate가 한 덩어리로 크게 있기 때문에 한 번에 빠진다.

 

각각으로 하도록 구조를 변경하면 안되는가?

결국 cell도 물리적인 강도가 필요하다. substrate가 개별 cell의 전자의 바다 뿐 아니라 물리적 지지까지 해내기 위해서는 꽤 깊은 상당한 부분을 substrate로 채워야 한다.

 

만약 이를 여러 cell이 공유하게 한다면 이를 완화할 수 있다.

 

---

page가 모여서 block, block이 모여서 chip, chip이 모여서 channel, channel을 컨트롤 하는 것이 contoller

 

page는 read/write가 이루어지는 최소단위

하나의 페이지는 kB 급의 단위, 주로 2kB, 4kB가 많다. -> 이유는 파일 시스템 단위가 4kB이기 때문

그럼 왜 파일 시스템 단위는 4kB인데?

파일 시스템이 만들어질 당시 4kB 미만의 파일이 대부분을 차지하였던 특성으로 인해

빈 공간을 많이 남기지 않으면서, 관리할 때 너무 복잡하지 않게 하는 단위

 

결국 workload에 따라 달라질 수는 있다.

SSD도 추세에 맞춰서 발전한다.

 

erase 단위는 공정의 영향을 많이 받는다. 

 

---

Reliability

- insulator는 wear out된다.

- 전압을 걸 때 주변의 cell에 영향을 미친다.

 

FTL 복습 (Flash Translation Layer)

플래시가 HDD를 사용하는 장비에서도 호환될 수 있도록 해주는 논리적 매핑장치

 

logical block address를 physical block과 page #로 매핑

각 block 내에서는 write point를 들고 있다.

 

read는 간단 (매핑 따라가서 읽어온다)

기존 값이 있던 매핑에 새로운 값을 적을 때는 write point에 새로운 값을 적고, 매핑을 교체한 뒤, 기존 매핑이 있던 block info table의 valid page count를 1 줄인다.

물론 매핑도 새로운 곳으로 교체한다.

 

새로운 block을 쓰는 것이면 erased 표기를 false로 바꿔준다.

 

충분히 여러번 새로운 곳에 write가 일어나게 되면 valid page count가 낮아진 block이 생긴다.

이러면 공간이 낭비되는 것이기 때문에 이 valid한 page들만 다른 곳으로 옮긴 뒤, block 단위의 erase를 실행한다.

이렇게 확보한 block은 차후 write가 필요할 때 쓰일 것이다.

 

이러한 특성으로 인해 유저가 일으키지 않은 추가적인 write가 일어난다. -> write amplification

 

flash controller를 flash와 붙여서 팔거나 / 따로 팔거나

삼성은 붙여서 판다.

이에 따른 장점은? 

QLC의 불안정한 특성을 잡기 위해서는 controller의 역할이 중요하다.

이를 잡아내기 위해서는 flash의 특성과 공정의 한계를 잘 알고 있어야 한다.

 

cable

SATA, SAS, PCIe

싸게 할 때는 SAS, 비싸게 연결하는 것은 PCIe

규격은 외울 필요는 없다.

 

이 위에서 돌아가는 프로토콜이 NVMe (NVM Express)

SSD에 특화되어 있는 프로토콜이라 고속 전송이 가능하다.

구조는 NIC 카드와 비슷

 

Doorbell (레지스터에 값을 쓰는 행위)

DMA를 통해서 값을 읽어온다.

다 끝났을 때는 interrupt를 날려서 처리

 

---

데이터 센터 레벨이면 JBOD, JBOF 등으로 엄청나게 많은 저장장치가 있을 것이다.

고장도 많이 날텐데 이것들 관리는 어떻게 할 것인가?

 

분산 파일 시스템

실제 데이터를 들고 있는것이 하나가 아닌, 수백, 수천에 걸쳐서 나누어져 있다.

 

Centralized 분산 시스템

메타데이터를 관리하는 마스터 서버들이 있다.

client는 원하는 데이터가 어딨는지 질의한다.

마스터 서버는 그 위치 chunk 단위(64MB)를 대답하고 (translation) client는 해당 정보를 활용해 chunk 서버에 접근한다.

 

문제는 무엇일까?

- 클라이언트가 소수의 마스터 서버에 집약되는 문제가 있다. (병목 현상)

레플리카를 두어 로드 밸런싱을 하더라도 부담될 수 있는 양이다.

 

구글은 왜 이런 구조로 두었을까?

위치 query보다 무거운 read/write는 마스터에서 일어나지 않기 때문이다.

때문에 병목 현상이 그렇게 큰 문제가 되지 않는다.

 

실제로는 데이터 관리 알고리즘이 더 큰 문제이다.

chunk 관리 서버의 생존, 동시성 처리 문제 등등

Paxos 등의 해결책 (절반보다 많이 살아남으면 데이터 보존, 복구 가능)

 

---

 

Ceph

마스터 서버 없이 관리

PG (placement group)

OSD (object storage devices)

 

hash값과 마스킹을 통해 pgid를 산출, 이러한 규칙에 따라서만 보관한다. 때문에 따로 query를 할 필요가 없는 것

hash collision 문제는? pgid bucket 안에서 해당하는 것을 따로 찾는 과정이 있다.

 

pseudo-random distribution 함수를 통해 OSD에 분배

hash를 엔간히 잘못 짜지 않는 이상 특정 PG에 몰리지는 않지만 특정 OSD에 몰리는 경우는 있다.

 

문제?

앞의 중앙 처리만큼 다이나믹한 load 밸런싱에 특화되어있지는 않다.

아예 안하는 것은 아니나 매핑이 고정되어 있는 만큼 한계가 있다.

 

---

fault tolerent 측면 여러 copy를 두어 관리

구체적으로 어디 둘것인가?

 

가장 간단한 방법? random.

여러 개 중에서 임의의 3개의 서버를 선택, 복사본을 저장, 관리한다. 

 

문제는 동시에 3개 이상의 서버가 죽어버리면 발생할 수 있다.

온갖 조합의 copyset이 존재한다면 높은 확률로 1개 이상의 데이터는 장애 조합에 들어맞을 것이다.

이러면 우리는 그 데이터를 잃게된다.

 

해결? copyset을 미리 정해두면 어떨까? (MinCopyset) -> minimize copyset #

이러면 데이터를 잃을 확률은 적어지나.... (장애 조합과의 교집합 적어짐)

잘못하면 많은 데이터를 한번에 잃는다.

큰 장애 발생시까지의 예상 기간이 길다면 선택할만할 것이다.

 

---

RAID (Redundant arrays of inexpenesive disks)

자세한 내용은 https://zetastring.tistory.com/121 참조

 

위에서 소개한 것들은 주로 SW 단계의 솔루션이다.

전통적으로 HW 단계의 솔루션이 있었다.

 

RAID는 copy본을 만드는 기법 중 하나

데이터를 분산하고 연산하는 것이 꼭 한 서버 내에서만 있을 필요는 없다.

동적 디스크 대상 redundancy를 부여하는 방법

 

RAID-0 -> redundancy 없는 것

RAID-1 -> 단순히 copy하나를 만든다.

RAID-4, 5-> parity bit을 전담하도록 하는 disk를 따로 하나 두어 관리

4와 5의 차이는 parity 연산에 병목이 발생한다는 것

parity 전담 disk는 다른 disk에서 write 연산이 있더라도 항상 한번씩 write 연산이 발생하게 되므로 부담이 많이 일어난다.

parity bit을 골고루 분산시킨 RAID-5에서는 이러한 집중적인 write가 일어나지 않도록 할 수 있다.

 

PCIe 슬롯에 RAID 카드 -> 꼭 고장이 났을 때만 실행되는 것이 아니다.

특정 디스크의 비트가 flop되거나 일부분만 바뀌는 경우에

read/write를 할 때마다 복구가 되어야 하는지를 판단하여 parity를 사용하여 지속적으로 계산 및 복구한다.

 

이 때문에 RAID-5가 사용되면 디스크가 아무리 많더라도 해당 연산 때문에 성능이 깎이는 경우가 많다.

 

RAID-6

동시에 두 개의 디스크가 고장이 난다면?

또는 고장이 overlap 된 상태라면?

 

parity bit을 하나 더 둔다.

 

이를 발전시킨 것이 Erasure Codes for distributed storage systems

k개의 data disk, m개의 coding disk

물리적인 k+m개의 disk에 흩어져있다.

아무 k개의 disk에서 동시 장애가 발생하더라도 복구가 가능하도록 하는 알고리즘을 사용

 

---

이러한 정책들을 세울 때 고려하는 것들

 

- 얼마나 많은 오류를 동시에 견딜 수 있어야 하는가?

- storage space overhead (추가적인 저장장치 요구)

- network IO, disk IO bandwidth

- 수리할 때 필요한 디스크의 수

 

주로 1 fault at a time (굉장히 관대한 전제)을 예상하며, 2 fault at a time까지도 전제하는 경우도 있으나 ssd는 그렇게까지 많이 고장나지는 않는다.

 

주로 read할 때는 그냥 읽고, write할 때는 parity까지 write하는 정책을 사용한다.

 

---

Data Hotness

특정 시간 내에 얼마나 자주 access되는가?

hot data와 cold data에 맞춤형으로 서비스를 해야하겠지? 라는 생각이 자연스럽게 들 것이다.

모든 것을 다 빨리 할 수 있다면 참 좋을텐데 가격이 미친듯이 나올것이다.

설계는 workload(working set)을 보고 판단하는 것이 좋다.

ex) 갑자기 miss ration가 확 올라간다 -> cache 사이즈가 workload보다 작아 eviction이 지나치게 많이 일어난다.

 

cold data를 위해서는 비용을 많이 투자할 필요가 없다. 

자주 access되지 않기 때문에 싸게, 장기간 보존될 것이기에 keep만 하는 형태로만 있으면 된다.

 

근데 cold data는 flash로 하는 것이 대세라고 한다?

flash가 HDD보다 비싼데 왜 이걸로 하는거임?

 

전력을 비교하면 HDD가 월등히 많이 쳐먹는다.

때문에 capex, opex를 모두 고려하면 flash로 정보를 보관하는 것이 유지하는데 이상적이다.

 

-> hot data와 cold data를 비교할  때, 전력이 기준으로 들어간 TCO를 생각하는 것은 정보의 accessibility는 유지되면서 정보는 최대한 효율적으로 보관되어야 하기 때문이다.

극단적으로 마그네틱 테이프에 하면 가장 저렴할텐데도 이렇게 하지 않는것은 accessibility를 생각하기 때문이다.

 

---

유저 레벨에서는 저장된 데이터에 어떻게 접근할까?

 

가장 익숙한 것은 파일 시스템 hierarchy structure로 구성

 

block storage : 많이 다루진 않는다. 파일 시스템 내부에서 access하는 방식

 

object storage : 디렉토리가 하나, 또는 두 개만 있는 시스템이라고 생각

bucket

uuid를 가지고 직접 접근

 

파일 시스템과의 차이는 무엇인가?

Bucket Name / Object Name으로 찾는 방식인데

파일 시스템을 이렇게 쓸 수도 있다.

다만 이렇게 똑같이 쓴다고 하더라도 파일 시스템은 메타 데이터가 복잡하게 관리된다.

Object 스토리지는 단순한 레이어만 관리하면 되기 때문에 메타데이터가 단순해진다.

 

key - value store

특정 key를 넣으면 해당하는 value가 튀어나오는 식 (put, get API만 존재)

조금 더 advanced 형태의 key value search가 가능

 

자세한 사항은 https://tech.gluesys.com/blog/2021/04/20/storage_9_intro.html 참조

 

---

서버 내 디스크 내에 있는 정보를 어떻게 가져올까

Remote Direct Memory Access

 

DMA 알고 있지?

CPU 개입 없이 디스크에서 메모리로 읽어오는 것 / 메모리에서 디스크로 읽어오는 것

DMA 엔진 사용

 

이걸 remote로 하는 것이다.

원격에 있는 CPU를 건드리지 않고 원격의 디스크에 접근해서 쌍방향 통신이 가능

핵심은 데이터가 존재하는 서버의 CPU 개입 없이 입출력이 된다는 것

 

RDMA over Commodity Ethernet 등

데이터 센터에서 정말 자주 쓰임, AI 같은 곳에서는 기본 소양

문제가 되는 것 : 속도를 높이려고 TCP를 사용하지 않아 flow control이 되지 않는다.

 

NVMe over Fabric

원격의 flash를 로컬에 있는 것처럼 취급하는 기술

RDMA를 사용해서 가속화할 수 있다.

 

ReFlex

결론 : 로컬에서 NVMe over Fabric 같은 것을 했는데

소프트웨어만 바꿔줬더니 원격에 있는 SSD라도 로컬에 있는 SSD에 준하는 성능을 뽑아낼 수 있다는 것이다.

온갖 가속화 기법을 활용 (batching 등)