나에게 흥미로운 내용이 또 한가지 있다면, 파일시스템 관련 즉, I/O 관련 이슈이다.
튜닝이 가능한 부분을 살펴보게 되기 때문일 것이다.
일주일뒤 확인하면 무료일듯...
이번에 4.12 커널 Mainline Window 가 나오면서,
고성능을 요구하는 하이퍼포먼스 이슈로 인해, CFG 를 대체할 만한
두개의 새로운 Block I/O Queueing Scheduler 가 포함되기로 했다고 한다.
그 우선은 BFQ ( Budget Fair Queueing ) scheduler 로의 회귀(?) 이다..
Budget ... 보기만해도 왠지 부럽지만 또 빡빡할거 같은 우울한 단어다...
그래, 우리 부서는 버짓이 굉장이 타이트해, 매니저얼굴도 제대로 못보며,
해외여행 해외출장 도 상당히 제한적인 상태이다.
( 외국계기업이면 외국엘 내보내줘야지 씨밤바들아 -_- )
무튼, 이 버짓이라는 용어는 상당히 의미심장하다.
리눅스 커널들이 상당히 여러방면으로 대규모 컴퓨팅에 이용되면서,
Multi block ( 여러개의 저장장치 ) 에 대한 I/O 스케쥴링이 요구되었는데,
기존 커널들에서는 이런 멀티플 블록에 대한 스케쥴링이 완벽하지 않았고,
그 스케쥴링시 마다 막상 멀티플 뷰에 대한 구현의 차이가 상당이 컸다고 한다.
(일례로, CFG 의 CPU consuming issue 등 이 있긴 했다. )
하지만 4.12 에서 두개의 스케쥴러가 추가되면서 이 부분을 줄이게 되었다고 한다.
조나단은 I/O scheduler 에 대한 고민이 왜 이제서야 대두되었는가 에 대해 일각에서
커널이 불안정하거나 완전성이 떨어지는 아이 아니냐는 의문이 있었으나,
사실 이 Multiple queue IO scheduler 에 대한 필요성 자체가 논의되기 시작한지 얼마 되지 않았기 때문이라고 설명했다.
High-End drive 의 경우 대체로 SSD(Solid-State-Disc) 인게 추세이고,
Spinning 에 대한 Access 문제가 없는 - 일반적인 판 회전형(플래터) 디스크의 문제 - 디스크이므로,
그 Request 작업의 순서에 대해서 특별히 민감할 부분이 없다고 알려져 있었기 때문이다.
하지만 높아지는 하이컴퓨팅 시스템과 지가 뭐하는지도 모르는 빌어먹을 빅데이타 따위들 때문에,
결국 이 SSD 형태의 디바이스 조차,
그 IO request 에 대한 순서를 정하는 부분에서 완전히 자유로울 수는 없었다고 한다.
IO 스케쥴러를 통해 최대한 서로 인접한 블럭을 Access 를 하고,
인접하게 데이타블록을 저장하는 것은,
전체적인 작업의 수를 줄이고, 우선순위의 상향을 가져오는 효과가 있기 때문에,
새롭고 향상된 스케쥴러에 대한 고민이 많았으나,
사실상 커널에 포함시키기 적합한 코드나 핵심 알고리즘의 부재 등의 어려움이 있었다고 한다.
4.11 버젼에 대한 window 에 근접하는 동안,
역시 성능은 Deadline I/O 스케쥴러!! 라며 이런 문제에 대해 심플한 해결책으로 제시되었으나,
사실상 이것은 해결책이라기 보다는 멀티큐 스케쥴러의 필요성을
오히려 증명하게 된 POC 용도로 쓰인 것이라고 한다.
이에 따라 4.12 에서는 멀티큐형 BFQ 를 포함하기로 하였으며,
(이게 멀티큐형태로 나오지 않으면 커널에 포함 안시켜준다고 하는등어려움이 조금 있었다고 한다....)
이 스케쥴러는 제한된 IO Throughput 범위 안에서 충분한 관찰을 통해,
각 프로세스마다 사용 가능한 트래픽(Budget) 을 책정하고,
그 책정된 값과 우선순위에 맞춰 모든 프로세스가 꼭 필요한 짧은 대기시간만으로
최대한의 대역폭 (throughput) 을 구현 하도록 스케쥴링 되는 것이라고 한다.
이녀석은 일정한 heuristics 에 의하여, 골고루 또는 필요한 device 에 Request 를 처리하도록 넘기면서,
아주 느린 디스크에서는 물론, SSD 에서도 큰 효율을 가져다 준다고 한다.
( 마치 L4 나 L7 레이어의 그것과 비슷하다 그냥 예다.)
사실상 IoT 나 기타 Mobile 장치에서 빠른 IO 를 처리하는 잇점을 가져다 준다고 하는데,
아이러니하게도 원래 BFQ 의 경우 꽤 오래 전부터 platter 와 Spinddle 기반의
회전형 디스크의 성능을 위해 고안되었을 뿐만 아니라,
(사실 이게 오래된건지, 혹은 새로 고안된거였는지 좀 알 수 없었다.
2.6 초기커널에서 들어본거같은데 찾기가 귀찮... )
리퀘스트에 대해 필요한 만큼과 허용된 만큼 우선순위를 처리하는 형태인데,
이런 짠돌이 형태의 스케쥴러가 멀티큐를 지원하면서 상당히 만족스러운 결과를 내었나 보다.
( 사실 보다 정확한 IO request 처리에 대한 알고리즘을 이해하려면,
IO request merging 에 대한 부분을 먼저 숙지해야 한다. )
이런 다양한 인고의 과정중, 재밌게도, 한개의 멀티큐 스케쥴러만으로는
모든 수요를 감당하기 어려웠던 것인지 커널에 또 다른 멀티큐 스케쥴러가 포함된다고 한다.
두번째 스케쥴러는 바로, Kyber IO scheduler 라고 한다...
사실 BFQ 가 CFQ 보다 훨씬 발전되고 성능이 좋은 스케쥴러임에도 불구하고,
구지 다른 스케쥴러가 같이 포함되야 했는지 커널개발자들의 고지식함을 안다면,
상당히 의아하고 재미있는 부분이 아닐 수 없는데,
다른 스케쥴러가 포함된 이유는 비교적 단순했다.
앞서 말했듯이 BFQ 의 경우, 저성능을 내는 Device 를 위해 고안되었기 때문에,
생각보다 훨씬훨씬 복잡한 형태로 구현이 되어있다고 한다.
또한, 비록 SSD 에서 조차도 좋은 성능을 낼 수 있음에도 불구하고,
사실 디바이스 자체의 성능이 좋은 경우 이런 복잡한 구현 자체가Overhead 일 경우가 있을 수 있기에,
효율을 매우 따지는 커널 개발자들에게 있어서 다소 불편한 부분이 될 수 있다는 점.
( 아 졸라 까다로워.. 역시 .. 나같은건 발톱의 때만도 못할 성격들 -_- )
아주 좋은 성능의 SSD 에서는 사실 Request queue merging 정도의 간단한
정책적 기반만 제공되도 충분할 수 있기 때문에 이에 알맞게 단순한 스케쥴러도 필요했고,
그래서 추가된 것이 Kyber 라고 한다.
이 Kyber 스케쥴러는 BFQ 에 비견하면 그냥 아주 한마리 들짐승과 같은
거칠고 투박한 녀석이라고 하는데
BFQ 에 비해 매우 간단하며, 불과 1000 라인도 안되는 간단한 코드로 구현 되었기 때문이다.
이건 거의 네트워크 스택과 비슷한 형태의 구조를 보이고 있다고 하는데,
간단하게 말해서, IO 관련 Request 는 Kyber scheduler 를 통하며,
동기와 비동기 를 관할하는 즉, 입력과 출력 이렇게 두가지 큐로 나눠 처리되는 형태이기 때문이다.
( RX/TX 같이 ... 꼭 설명 안하면 못알아 들을까봐 해준다 ... ㅠㅠ )
동기화가 필요할 경우, 즉, 읽기 같이 동일한 데이타에 대한 접근 동시성이 필요한 경우,
해당 Request 에 대해서는 리드 큐를 사용하여 처리한다.
Write 가 필요할 경우 바로 처리하지 않고, 특성상 비동기성으로
조금 더 있다가 업데이트를 해도 되기 때문에, Asynch(Write) 큐에서 처리된다.
따라서 프로세스는 어떤 IO Request 에 대해서
프로세스 본인이 읽고 쓰기에 대한 우선권을 따로 생각하지 않아도 된다.
커널의 스케쥴러가 알아서 필요에 맞춰 큐잉을 통해 스케쥴링을 해준다는 것이다.
이 Kyber 알고리즘의 핵심은, 이 큐에 대기되는 Length 를 매우 엄격하게 제한하여, ( Dispatch latency )
이 큐 자체의 대기열을 매우 짧게 유지한다는 컨셉이다.
Dispatch 대기시간이 짧으면 말 그대로 요청당 발생하는 Latency 가 짧아지게 되며,
이는 Priority 가 높은 요청에 대한 가장 빠른 완료를 보장하는 알고리즘인 셈이다.
이 스케쥴러는 대기열의 관리를 위해 이미 정해진 시간을 규칙으로 관리한다고 한다.
읽기의 경우 2ms 안으로, 쓰기의 경우 10ms 안으로 처리하도록 디자인 되어 있다.
( 물론 시간은 수정/튜닝 이 가능하다고 한다. )
역시 튜닝의 부분은 따로 이야기 될 이야기 이지만, 최대의 Throughput 에 적합하게
설계되어있다는 것을 감안할때, 단순하면서도 기발한 방법이지 않을까 싶다.
결국 이 두가지 스케쥴러는 모두 4.12 mainline window 에 포함되었고,
이는 사용자의 의도에 따라서,
* Interactive 하면서도 일정한 퍼포먼스를 요구하는
응답형 서비스가 필요한 경우에는 BFQ 를,
* 최대한의 워크로드 퍼포먼스가 중요한 서비스의 경우 Kyber 를,
각각 용도에 맞게 선택해 사용 할 수 있게 된다는 점이다.
어느쪽을 사용하든지, 커널의 Multiqueue Block IO 들의
기능적 격차를 줄이는 결과를 가져 올 것으로 보인다는
희망적 의견을 내비치며 필자는 이에 관한 기사를 마무리 한다.
확실한건 아닌데, 성능이 더 좋게 잘 동작하는것 같다고 하는 답변도 달려있다.
내려놓을 수 없는 부분이 바로 성능이라고 생각된다.
상당한 이득을 경험했을 때의 기억이 새삼 떠올랐다.
그때 엄청 감동이였는데... ㅎㅎㅎ
Disk I/O scheduler 에 대한 것은 언제나 놓지 않아야 한다고 본다.
어느덧 네시다 ㅠㅠ 제길... 오늘 회사 못나갈듯...
놀러나가야 하는데 징징징....