[그림으로 배우는 리눅스 구조] 9. 블록 계층

 

https://www.yes24.com/Product/Goods/122109062

그림으로 배우는 리눅스 구조 - 예스24

 

 9장에서는 블록 계층에 대해 설명한다. 블록 계층은 SSD, HDD 등 저장 장치에 대한 커널 기능으로, 보통

파일 시스템(디바이스 파일) - > 블록 계층 -> 장치 드라이버 -> 장치 순으로 이루어지는데, 여기에서 블록 계층은 다양한 종류의 장치에 대응하도록 발전하였다.

 

1. 하드 디스크의 특징

 

 하드 디스크의 구성 요소를 위 그림을 보면서 살펴 보자.

• 플래터 : 자기 디스크로, 데이터를 자기 정보로 표현해서 저장함.
• 섹터 : 플래터에서 데이터를 저장하는 단위로, 512B 또는 4KiB 단위다.보통 섹터는 반지름과 원둘레 방향으로 분할되고, 각각에 연속된 번호가 할당된다.
• 자기 헤드 : 자기 헤드를 이용해서 섹터에 접근한 후 읽거나 쓸 수 있다.
• 스윙 암 : 자기 헤드는 플래터의 반지름 방향으로 이동할 수 있다. 해당하는 트랙(원둘레)에 스윙 암이 이동하면, 이후 플래터를 회전시켜 원하는 섹터에 헤드를 옮길 수 있다.

 앞서 보았듯, 원하는 섹터에 접근하기 위해서는,

1. 스윙 암을 이용해서 자기 헤드를 반지름 방향으로 이동시켜 원하는 트랙에 맞춘다.
2. 플래터를 회전시켜 원하는 섹터에 맞춘다.

 이러한 과정은 기계적인 처리(회전, 이동)이다. 하지만 그에 비해 파일 시스템에서 내리는 명령은 기계적인 처리 시간에 비해 훨씬 빠르다. 그렇다면 어떻게 해야 이러한 기계적 처리 속도를 줄일 수 있을까? 다음 아이디어를 사용한다.

회전은 이동보다 빠르다!

 

 회전이 이동보다 빠르므로, 즉 일단 스윙 암으로 원하는 트랙까지 옮기면 그 다음에 회전 속도는 훨씬 빠르기 때문에, "같은 트랙에서 연속된 데이터(연관된 데이터)를 잘 배치하는것' 이 중요하고, 데이터를 읽거나 쓸 때 한꺼번에 동작시키는 것이 중요하다(참조 지역성의 원리). 또한 가능한 연속된 데이터의 암 이동 거리는 작아야 한다.

 

2. 블록 계층의 기본 기능

 블록 계층은 초기에 하드 디스크 특징을 의식해서 만들엇고, 그러한 대표적인 기능이 입출력 스케줄러(I/O scheduler)와 미리 읽기(readahead)이다.

 

 입출력 스케줄러는 블록 장치의 접근 요청을 일정 시간 보류했다가 다음과 같은 최적화 처리를 해서 디바이스 드라이버에 입출력 요청을 호출한다.

• 합치기(merge) : 연속된 섹터의 입출력 요청을 하나로 합침.
• 정렬(sort) : 연속하지 않은 섹터의 입출력 요청을 섹터 번호 순서로 재정렬

 보통 합치기 -> 정렬 하지만 정렬 -> 합치기 순으로 스케줄링할 수도 있다.

 정렬해야하는 이유는, 보통 플래터가 회전하는 순으로 섹터 번호가 정해지기 때문에 정렬을 한다면 시작 번호에만 헤드를 이동시키고 그 이후로는 플래터를 돌리면 빠르게 데이터를 가져오거나 쓸 수 있다.

 

 미리 읽기는 블록 장치의 어떤 영역을 읽을 때 가까운 미래에 지금 접근한 영역 근처에 접근할 가능성이 높다고 추측해서 후속 영역을 미리 읽고 '페이지 캐시'에 보관하는 기능이다. 예를 들어, 0~2 섹터를 읽으려고 한다면 3~5 영역도 미리 읽어서 페이지 캐시에 저장해둔다. 보통 하드 디스크에서는 '순차적' 접근이 일어날 경우가 많으므로, 이런 경우에 미리 읽기의 효과가 뛰어나다.

 

3. 블록 장치의 성능 지표와 측정 방법

 블록 장치의 성능 지표는 크게 throughput, latency, IOPS가 있다. 이 성능 지표를 (1) 프로세스 하나가 블록 장치에 접근해서 블록 입출력을 호출할 때와 (2) 다수의 프로세스가 병렬로 입출력을 호출할 때로 시나리오를 나누어 알아보자.

 

 (1) 프로세스 하나가 입출력을 호출할 때

 throughput이란, 단위 시간 당 데이터 전송량이다. 예를 들어 1GiB 데이터를 전송하는데 10초가 걸렸다면 throughput은 100MiB/s 이고, 5초가 걸렸다면 200MiB/s이다. 이러한 지표는 큰 데이터를 전송할 때 유용하다.

 latency란, 입출력 1회 당 걸린 시간으로 저장 장치의 응답 성능으로, 보통 관계형 데이터베이스 같은 시스템에서 사용자가 레코드 1개를 읽을 때의 시간 등으로 유용하게 쓰인다. 예를 들어 A프로세스는 레코드를 1개 읽어오는 레이턴시가 10밀리초(10ms)라는 의미로 쓰인다.

 IOPS란, I/O per second의 약자로, 초당 처리 가능한 입출력 횟수를 의미한다. 예를 들어 10밀리초에 5개의 레코드를 차례로 읽어올 수 있다면 IOPS는 500(record/s) 이다.

 

 (2) 병렬로 입출력을 호출하는 경우

 2개의 프로세스가 각각 데이터를 요청한다고 가정해보자. 그렇다면 장치가 병렬 접근이 가능하다는 가정 하에 throughput과 latency는 각각 2배, 1/2배가 될 것이다. 하지만 항상 linear scale로 증가/감소할까? 그렇지 않다. 왜냐하면 데이터는 버스(bus)나 p2p(point to point) 식으로 이동하는데, 이 이동 수단의 한계라던가, 장치 자체에서의 데이터 전송 능력 한계 때문에 정직하게 linear scale로 성능이 향상되지는 않는다.

 IOPS 역시 병렬성을 지원하면 증가하는데, 단독 프로세스일때의 iops를 더한 것보다 병렬성을 적용했을 때의 iops가 더 효율적이다. 그 이유는 무엇일까? iops는 '다수'의 레코드를 주고 받는 것이므로 프로세스와 의 통신 시간 만큼 장치가 명령을 기다려야 한다. 하지만 병렬성을 적용한다면, 기다리는 시간에 context switch를 해서 다른 프로세스의 데이터를 전송해주면 되므로, 결론적으로 병렬성을 적용했을 때 더 뛰어난 iops를 기대할 수 있다.

 

 (3) fio 로 성능 측정

 fio에서 다음과 같은 인수를 통해 성능 측정을 할 수 있다. 예를 들어 다음 명령으로 1GiB 짜리 testdata에서 4KiB씩 총 4MiB 데이터를 읽어오는 과정에서 fio를 출력해보자.

$ fio --name test --readwrite=randread --filename testdata --filesize=1G --size=4M --bs=4K --output-format=json

 

 다음은 출력 과정의 일부고, bw_byte는 바이트 단위 throughput, iops를 볼 수 있고,

 

 다음에서는 latency를 알 수 있다.

 

 책에서는 HDD에 대한 성능 평가 지표를 제공하는데, 필자의 노트북에는 HDD가 없어 실험이 불가능하다..

 책의 내용을 정리하면, 입출력 스케줄러를 사용할 때 IOPS가 높아지고 레이턴시가 감소한다.(입출력 요청이 잘 정렬되기 때문) 또한 미리 읽기를 사용하면 2배 이상의 throughput을 기록한다고 정리되어 있다.

 

 4. SSD의 등장

 SSD는 데이터 저장에 플래시 메모리를 사용한다. 즉 전자회로적인 특성을 응용하기 때문에 기계적인 동작(느림)이 전혀 필요 없기 때문에, 읽기와 쓰기가 모두 전기적인 동작으로 종료된다. 따라서 하드 디스크보다 빠르게 데이터에 접근할 수 있다.

 SSD는 SATA(SAS), NVMe 라는 접속 방식의 차이가 있는데, SATA 방식은 HDD와 동일한 인터페이스를 사용하고, NVMe는 고속 인터페이스를 이용한다. 따라서 NVMe SSD(대부분의 데스크탑이 이 방식을 쓴다)이 차원이 다른 속도를 보여준다. 그러나 비싸다는 단점이 있다. 

 NVMe SSD의 큰 장점은, IOPS가 정말 크기 때문에 CPU에서 멀티 입출력을 효율적으로 스케줄링한다면 최대의 성능을 뽑아낼 수 있다. 하지만 쿼드코어, 옥타코어가 나온 지금에서도 빠른 병렬 입출력 요청이 쉽지 않다. 이를 위해 현대의 입출력 스케줄러는 멀티 큐(multi-queue) 방식을 도입해서, 다수의 CPU에서 동작하는 방법으로 확장성을 향상했다.

 이후에 설명하겠지만 하드웨어 성능이 올라가면 올라갈수록 블록 계층에서 발생하는, 입출력 요청을 모아뒀다가 재정렬하는 입출력 스케줄러의 처리가 문제가 되는데, 최적화에서 오는 속도 향상보다 늘어난 레이턴시 때문에 결과적으로 느려지는 현상이 증가한다. 따라서 최신 OS에서의 SSD는 입출력 스케줄러를 무시하는게 일반적이다.