[IO 09] 스토리지 스택 커스터마이징 (전문)

본 장은 전문 난이도입니다. 애플리케이션의 read/write 패턴을 다듬는 것(이 트랙의 다른 챕터)과 별개로, 스토리지 스택 자체를 바꾸는 결정이 있습니다. 예를 들어 특수 목적 파일시스템, 커널 모듈, 벤더 NVMe 드라이버·펌웨어 튜닝, 커스텀 blk 계층 등이 여기에 해당합니다.

무엇이 달라지는가

스택 하단을 건드리면 지연 분포·처리량·장애 모드가 함께 바뀝니다. 유저 공간 최적화와 달리 커널 업그레이드·하드웨어 교체·클라우드 하이퍼바이저와 강하게 결합됩니다.

이득이 나올 수 있는 경우

극단적 IOPS/latency 목표: 표준 스택이 큐 깊이·스케줄러 정책에서 한계를 보일 때.
전용 하드웨어: 스토리지 컨트롤러·NIC와 공동 튜닝이 필요할 때.
데이터 레이아웃 특수성: append-only, 대형 순차 스캔 등 워크로드 특화가 명확할 때.

리스크(짧게 나열)

업그레이드: 커널 마이너 업에서 모듈 ABI가 깨질 수 있습니다.
디버깅: 크래시가 서드파티 모듈로 귀결되면 지원이 느립니다.
보안 표면: 커널 코드는 권한이 큽니다(Tr.11).
관측: 기본 메트릭만으로는 큐 적체 원인이 안 보일 수 있습니다.

flowchart LR
  subgraph app ["앱"]
    A["I-O 패턴"]
  end
  subgraph stack ["스택"]
    B["파일시스템"]
    C["블록 계층"]
    D["드라이버·디바이스"]
  end
  app --> stack