CacheLib + FDP 실측 사례 (Meta)

[!tldr] 업무 관점 takeaway 우리 미션의 가장 직접적인 외부 레퍼런스. Meta가 자사 KV 캐시 라이브러리 CacheLib에 FDP를 적용한 결과 WAF 3.5 → ~1.0 (SSD 100% 사용률에서). latency/throughput 저하 없이. CacheLib의 BigHash(랜덤 쓰기) + BlockCache(순차 쓰기) 패턴이 [[LMCache-개요|LMCache]]와 매우 유사하므로 — 우리에게도 같은 효과가 재현될 것이라는 강력한 사전 증거.

결과 한 줄

SSD 100% utilization 워크로드:

  WAF (FDP 없음): ~3.2 ~ 3.5
  WAF (FDP 있음): ~1.0
  개선율: 약 3× WAF 감소

부작용:
  latency/throughput: 차이 없음 (저하 X)
  Application-level WAF: 추가 증가 없음

출처: Samsung Getting Started with FDP v4 (Samsung GOST 팀, 실습 가이드, p.27).

왜 LMCache와 유사한가

측면	CacheLib	LMCache
워크로드 종류	KV 캐시 (Meta 추천/소셜 서비스)	KV 캐시 (LLM 추론)
데이터 lifetime	매우 다양 (long-tail, hot/cold)	매우 다양 ([[KV-Cache\|prefix vs single-query]])
Write 패턴	random + 일부 순차 (BigHash + BlockCache)	random + chunk batched
SSD utilization	100% 운영	비슷 (공간 최대 활용)
Eviction	LRU 기반	LRU/LFU/FIFO/MRU 선택 가능

중요: CacheLib의 KV 워크로드 ≠ LLM의 KV Cache (모듈 명칭이 같다고 내용물도 같진 않음). 하지만 저장소 입장에서 보이는 I/O 패턴(lifetime 불균일 + high utilization + random write)이 매우 유사 → 결과 재현 가능성 높음.

CacheLib 내부 구조 (참고)

CacheLib
├── BigHash       — random write 중심, 작은 객체
└── BlockCache    — sequential 중심, 큰 객체

이 둘이 같은 SSD에 섞이면 WAF 폭증. FDP RUH를 BigHash/BlockCache 별도로 부여하면 분리 → WAF ~1.0.

→ LMCache에서도 chunk lifetime별로 RUH 분리하면 같은 효과 기대.

측정 환경 (참고)

SSD: FDP 지원 NVMe SSD
워크로드: CacheLib production trace replay
측정 도구: nvme fdp stats ([[WAF#측정-방법]])

의외의 연결

[!note] BigHash ↔ Single-query KV Cache BigHash가 풀던 "작은, 랜덤, 짧은 수명" 패턴 = LMCache의 single-query KV Cache. BlockCache가 풀던 "큰, 순차, 긴 수명" 패턴 = LMCache의 prefix cache. 각 카운터파트에 같은 RUH 매핑 전략을 그대로 가져올 수 있다.

[!important] 재현 가설은 단정이 아니다 CacheLib 결과 = 우리 결과 보장 아님. 워크로드 강도, [[HC-SSD]] 미디어 차이, [[LMCache-Local-Disk-Backend|LMCache의 OS 경로 차이]]가 변수. 그래서 baseline 측정이 필요하고, 그게 [[단기-Task-목록|Task 1]]·[[Mission|Phase 2]]의 일.

결과 한 줄​

왜 LMCache와 유사한가​

CacheLib 내부 구조 (참고)​

측정 환경 (참고)​

의외의 연결​

관련 페이지​

결과 한 줄

왜 LMCache와 유사한가

CacheLib 내부 구조 (참고)

측정 환경 (참고)

의외의 연결

관련 페이지