BFQ Write Throttling: 쓰기 요청이 읽기를 굶기는 문제를 해결한 방법

논문은 실험 결과를 정리하며 이런 문장을 남겨요. “리눅스에서, 그리고 아마 다른 어떤 운영체제에서도 마찬가지로, 높은 I/O 지연과 낮은 처리량의 원인 중 하나는 쓰기 요청이 읽기 요청을 굶기는 경향이다.” 예산과 가중치를 아무리 정교하게 계산해도 이 문제는 저절로 풀리지 않는데, BFQ+는 어떻게 이걸 해결했을까요?

쓰기가 읽기를 굶기는 구조적 이유

디스크 장치는 대개 쓰기 요청을 받으면 즉시 완료를 알려요. 실제로는 내부 캐시에 요청을 저장해두고, 나중에 조용히 실제 매체로 플러시하는 방식이기 때문이에요. 이 구조 자체가 이후에 도착하는 읽기 요청을 뒤로 밀어내는 경향을 만들어요. 논문은 여기에 한 가지 문제를 더 얹는데, 여러 파일시스템에서는 읽기 작업 자체가 부수적으로 쓰기 요청을 유발하기도 한다는 점이에요. 접근 시간(atime) 갱신이 대표적인 예로, 파일을 읽기만 했는데도 메타데이터를 갱신하는 쓰기가 함께 발생해서 문제를 한층 더 키워요.

BFQ+가 고른 해법: 쓰기 (과)과금 계수

BFQ+가 이 문제에 접근한 방식은 새로운 스케줄링 규칙을 만드는 대신, 기존 예산 계산 안에 계수 하나를 끼워 넣는 쪽이었어요. 섹터 하나를 쓸 때마다 활성 애플리케이션의 예산을 1이 아니라 쓰기 (과)과금 계수만큼 차감하도록 바꾼 거예요. 결과적으로 쓰기 위주 애플리케이션은 같은 양의 예산을 훨씬 빨리 소진하게 되고, 그만큼 디스크 사용권이 읽기 요청에 상대적으로 더 자주 돌아가요. 논문이 실험으로 확인한 값은 10이었는데, 이 계수를 10으로 설정했을 때 높은 처리량과 낮은 지연 시간을 동시에 확보하는 데 효과적이었다고 밝혀요.

이 해법의 장점은 단순함에 있어요. 별도의 큐를 새로 만들거나 스케줄링 순서 규칙을 바꾸지 않고, 이미 존재하던 “섹터 수만큼 예산을 차감한다”는 기존 계산식에 곱셈 계수 하나만 추가했을 뿐이에요. 그런데도 효과는 뚜렷하게 나타나요.

원래 BFQ가 이 휴리스틱 없이 치른 대가

원래 BFQ에는 이 write throttling이 없었어요. 그 결과가 어떻게 나타났는지는 순차 읽기+쓰기 혼합 워크로드(5r5w-seq)에서 드러나요. bash 기동 시간 벤치마크에서 BFQ는 CFQ보다도 더 나쁜 지연 시간을 기록했는데, 논문은 그 이유를 두 가지로 짚어요. 하나는 반응성을 높이는 low-latency 휴리스틱이 빠져있었기 때문이고, 다른 하나는 바로 이 write throttling이 빠져있었기 때문이에요. 순수 읽기 워크로드에서는 쓰기 요청 자체가 거의 없다 보니 이 휴리스틱의 영향이 미미하지만, 읽기와 쓰기가 섞인 워크로드에서는 차이가 명확하게 갈렸어요.

집계 처리량 측면에서도 비슷한 패턴이 보여요. 순차 읽기+쓰기 워크로드(5r5w-seq)에서 BFQ+가 BFQ보다 살짝 더 높은 처리량을 기록한 것도, 논문은 write throttling과 함께 순차 쓰기가 순차 읽기보다 원래 느리다는 특성이 겹친 결과라고 설명해요. 반대로 랜덤 읽기+쓰기 워크로드(5r5w-rand)에서는 write throttling이 없는 원래 BFQ가 오히려 더 높은 처리량을 냈는데, 그 이유는 단순해요. 쓰기를 전혀 억제하지 않았기 때문에 얻은 이득이지만, 논문은 이 작은 이득이 다른 모든 벤치마크의 반응성 저하로 상쇄되고도 남는다고 지적해요.

결국 트레이드오프는 어디서든 발생한다

Write throttling은 “쓰기 요청 하나가 예산에서 차지하는 비중을 늘린다”는 아주 단순한 아이디어지만, 이 논문 전체를 관통하는 설계 철학을 가장 압축적으로 보여주는 사례이기도 해요. 순수 처리량 극대화와 지연 시간 최소화는 항상 상충하고, BFQ+가 하는 일은 그 사이의 균형점을 계수 하나하나로 세밀하게 조정하는 거예요. 이 균형점들이 실제로 어떤 수치로 나타나는지는 BFQ+와 BFQ, CFQ를 나란히 돌린 벤치마크 결과를 직접 비교해봐야 체감할 수 있어요.