단기 Task 목록 — 선정된 5개

[!tldr] 업무 관점 takeaway 전체 Task 풀(21개)에서 추려낸 단기 3 + 중기 2 = 5개. 핵심 우선순위 = Task 1 (L2 latency histogram). 이게 없으면 우리 모든 가설(WAF → latency → TTFT 인과 사슬)을 데이터로 추적할 수 없다. Task 1 → 2/3 병렬 → 4/5 병렬 순서로 진행. 총 ~20주, 단축 가능.

한 눈에

Task	카테고리	난이도	Samsung 연관	기간	선행
1. L2 latency histogram	관측	중하	높음 (분석 기반)	3주	-
2. `storage describe` CLI	운영	하	중	2.5주	Task 1 권장
3. fs_connector O_DIRECT	I/O 최적화	중	높음 (NVMe 직결)	2.5주	-
4. L2 health check	신뢰성	중	높음 (SSD 신뢰성)	5주	Task 1 필수
5. Device-aware policy	정책	중상	매우 높음	7주	Task 1 필수

[단기 3개]                          [중기 2개]
┌─────────────────┐                ┌──────────────────┐
│ Task 1: 관측 추가  │──── 데이터 ────→ │ Task 4: 헬스체크 │
│ Task 2: 진단 CLI  │                │                 │
│ Task 3: O_DIRECT │                │ Task 5: Device-  │
└─────────────────┘  ←── 기반 ────  │       aware Policy │
                                    └──────────────────┘

Task 1 — L2 어댑터 단계별 Latency Histogram

왜 가장 먼저인가: TTFT 인과 사슬에서 어떤 단계가 병목인지 데이터로 분리 못함 → 우리 모든 가설이 측정 불가. FDP/HC-SSD 효과를 upstream PR에 넣으려면 "어디서 얼마나 줄어드는가" 측정 데이터가 필수.

현재 한계:

l2_throughput.py는 GB/s만 측정 (submit→complete 전체를 하나로 묶음)
병목이 큐 대기인지 실제 I/O인지 구별 불가

채택 설계 — adapter-aware 2+N 단계 모델

어댑터마다 단계 수가 다르므로 균일 4단계 강제 대신:

공통 (모든 어댑터):
  SUBMITTED ──[queue_wait_ms]──► DISPATCHED ──[processing_ms]──► COMPLETED

raw_block 전용 추가 (PR #2):
  DISPATCHED ──► IO_SUBMITTED ──[disk_io_ms]──► IO_COMPLETED ──► COMPLETED

추가할 이벤트 타입:

# PR #1에서 추가
L2_STORE_DISPATCHED       = "l2.store.dispatched"
L2_LOAD_TASK_DISPATCHED   = "l2.load_task.dispatched"
# PR #2에서 추가 (raw_block 전용)
L2_STORE_IO_SUBMITTED     = "l2.store.io_submitted"
L2_STORE_IO_COMPLETED     = "l2.store.io_completed"
L2_LOAD_TASK_IO_SUBMITTED = "l2.load_task.io_submitted"
L2_LOAD_TASK_IO_COMPLETED = "l2.load_task.io_completed"

코드 현황 (2026-05-22 확인)

인프라는 완비. 새로 추가할 부분만 남음:

항목	경로	상태
EventBus	`lmcache/v1/mp_observability/event_bus.py`	✅ 완비
기존 이벤트 타입	`…/mp_observability/event.py` L41-56	✅ 6개 정의됨
템플릿 subscriber	`…/subscribers/metrics/l2_throughput.py`	✅ 복붙 가능
Store publish 지점	`…/storage_controllers/store_controller.py` L505, L588, L608	✅
Load publish 지점	`…/storage_controllers/prefetch_controller.py` L739, L765	✅

EventBus.publish()는 deque.append() + 백그라운드 drain — 핫패스 영향 없음.

PR 분할 계획

PR	범위	주요 파일	규모
#1	`*_DISPATCHED` 이벤트 + 각 어댑터 worker 진입부 publish + `l2_latency.py` subscriber + 테스트	`event.py`, `local_disk_backend.py`, `raw_block/core.py`, `l2_latency.py`, `tests/`	~400줄
#2	raw_block 전용 IO_SUBMITTED/COMPLETED (subscriber optional 처리)	`raw_block/core.py` or `rust_raw_block_backend.py`, `l2_latency.py`	~200줄
#3	(선택) `docs/design/v1/mp_observability/` 계약 업데이트 + 버킷 튜닝	`docs/design/`	~150줄

PR #1 체크리스트

event.py: L2_STORE_DISPATCHED, L2_LOAD_TASK_DISPATCHED 추가
local_disk_backend.py: async_save_bytes_to_disk / batched_async_load_bytes_from_disk 진입부에 DISPATCHED publish
raw_block/core.py: worker thread 진입부에 DISPATCHED publish
subscribers/metrics/l2_latency.py 신규 — l2_throughput.py 패턴 기반
- pending dict: (adapter_index, task_id) → (queue_submit_ts,)
- 히스토그램 2개: lmcache_mp.l2_queue_wait_ms, lmcache_mp.l2_processing_ms
- attribute: l2_name, direction (store/load)
테스트: tests/v1/mp_observability/subscribers/metrics/test_l2_latency.py

기대 효과:

어댑터별/단계별 병목 정량 데이터
FDP/io_uring 작업 효과 직접 측정 → upstream PR 근거
Task 2/4/5의 입력

기간: 3주 (PR #1: 1~1.5주, PR #2: 1주, PR #3: 0.5주)

관련: [[LMCache-Async-Loading]], [[TTFT-ITL]], [[Mission]]

Task 2 — `lmcache storage describe` CLI

왜 필요한가: 현재 lmcache describe는 L1(메모리)만 보여줌. L2(NVMe 등)는 깜깜이. 운영자가 "지금 디스크 얼마 차 있나, 최근 latency는?"를 알 표준 도구 없음.

할 일:

lmcache/cli/commands/describe.py에 add_l2_storage() 메서드 추가 (add_l1_storage() 패턴)
- 어댑터 타입/인덱스/설정
- get_usage() (현재/총/사용률)
- in-flight ops (store/lookup/load)
- 최근 p99 latency (Task 1의 histogram 활용)
- 백킹 디바이스 정보 (raw_block/dax/fs 경로 식별자)
출력: 사람용 테이블 + -json
단위/통합 테스트

⚠️ 구현 경로 수정: storage.py 신설이 아님. describe.py가 이미 존재하며 L1만 보여주는 상태 → 같은 파일에 L2 섹션 추가.

기대 효과:

Samsung SSD 활용도 즉시 확인
트러블슈팅 표준 첫 명령
"Samsung SSD 운영 가이드"의 핵심 명령으로 등장 가능

기간: 2.5주

관련: [[LMCache-아키텍처|Controller API]]

Task 3 — fs_connector O_DIRECT 메타데이터 경로

왜 필요한가: fs_connector.py:111의 TODO: save_chunk_meta=True면 O_DIRECT 강제 비활성. NVMe에서 [[O_DIRECT]]는 page cache 우회로 메모리 효율/latency 안정성 좌우. 메타데이터 한 가지 때문에 전체 데이터 경로의 이점을 잃는 구조.

할 일:

메타데이터 직렬화를 4KB-aligned 블록으로 패딩
alignment 위반 시 처리 경로
save_chunk_meta=True + O_DIRECT=True 동시 가능 경로
기존 비-O_DIRECT 경로는 fallback 유지
단위 테스트 (비정렬/정확정렬/다중청크)
마이크로 벤치마크: O_DIRECT × save_chunk_meta 4조합

기대 효과:

LMCache + NVMe에서 page cache 오염 제거
p99 latency 안정 ([[Garbage-Collection|page cache flush 변동]] 제거)
"Samsung SSD에서 metadata 활성화 + O_DIRECT 동시 가능"이라는 차별점
[[Mission|"Storage Stack 최적화 — block alignment"]] 직접 실현

기간: 2.5주

관련: [[O_DIRECT]], [[LMCache-Local-Disk-Backend]]

Task 4 — L2 어댑터 Latency/Capacity Health Check

왜 필요한가: health_monitor/checks/에 remote_backend_check.py 하나뿐. 디스크 가득 차도, latency 10배 튀어도(SSD 노화, GC 폭발 등) LMCache는 감지 못함. Samsung SSD가 신뢰 컴포넌트가 되려면 SSD 측 이상을 LMCache 레벨에서 조기 감지 필요.

할 일:

~~l2_capacity_check.py — get_usage().usage_fraction 폴링~~ ✅ 완료 — Samuel Shen #3320(2026-05-21 머지): l2_usage_bytes gauge + get_usage() 배선 완료. Grafana 패널 추가됨.
- 90% → WARN, 95% → CRITICAL 경보 로직만 미구현 (남은 작업)
l2_latency_check.py — Task 1 histogram의 p99를 baseline(rolling median) 대비 비교
- 3× 이상 지속 spike → 경보
HTTP API: /health/l2
OTel metric: lmcache_mp.l2_health_status
baseline 윈도우/임계는 config 노출
통합 테스트: fake latency/capacity 데이터

기대 효과:

"SSD 노화 → LMCache가 침묵하게 느려짐" 시나리오를 데이터로 감지
Samsung SSD 표준 health 가이드라인
Prometheus alertmanager 연동 즉시 가능

기간: 5주 선행: Task 1 필수

관련: [[LMCache-Async-Loading]], [[기여-포인트-맵|기여 포인트 운영가시성]]

Task 5 — Device-aware Prefetch/Store Policy

왜 필요한가: 현재 DefaultPrefetchPolicy는 등록 순서로 결정, DefaultStorePolicy는 모든 어댑터에 동일 쓰기. 어댑터 특성(raw_block ~50µs vs s3 ~50ms = 1000×)을 정책이 무시. Samsung SSD가 클러스터에 있어도 "fast tier 우선" 결정을 표현할 수단 없음.

할 일:

AdapterDescriptor에 메타데이터 추가
- latency_class: Literal["fast","medium","slow"]
- durability_class: Literal["volatile","persistent","replicated"]
- capacity_tier: Literal["hot","warm","cold"]
각 L2 어댑터 config에 필드 노출
TieredPrefetchPolicy: 같은 key 있으면 fast tier 우선
TieredStorePolicy: hot tier 동기 쓰기, warm/cold tier 비동기 미러링
단위 + 통합 테스트
설계 문서: docs/design/v1/distributed/storage_controllers/

기대 효과:

Samsung SSD + S3 환경에서 SSD가 항상 우선
"fast tier로 TTFT X% 빨라진다" 측정 가능
Task 1 데이터로 검증
LMCache 공식 문서 "tiered storage" 섹션 신설 가능

기간: 7주 선행: Task 1 필수 (Task 4와 병렬 가능)

관련: [[LMCache-Async-Loading|AdapterDescriptor]], [[GPU-Direct-Storage|fast tier 후보]]

진행 순서 / 의존성

주차 1-3:    Task 1 (가장 먼저)
주차 4-5.5:  Task 2 + Task 3 병렬
주차 6-13:   Task 4 + Task 5 병렬 (둘 다 Task 1 데이터 사용)

총 ~20주. 병렬 진행으로 wall time 단축 가능.

의외의 연결

[!note] 단기 3개는 모두 측정/관측 가능성 작업 우리는 아직 검증 단계. "바꾸기 전에 보이게 만든다" 가 단기 전략. Task 1/2/3 모두 가설을 수치화하는 도구를 만드는 작업.

[!note] Task 5가 가장 Samsung 친화 Device-aware policy = 우리 SSD를 "fast tier"로 명시할 수 있게 하는 표준. 단순한 코드 변경이 아니라 upstream 인터페이스 자체를 우리에게 유리하게 형성하는 작업.

한 눈에​

Task 1 — L2 어댑터 단계별 Latency Histogram​

채택 설계 — adapter-aware 2+N 단계 모델​

코드 현황 (2026-05-22 확인)​

PR 분할 계획​

PR #1 체크리스트​

Task 2 — lmcache storage describe CLI​

Task 3 — fs_connector O_DIRECT 메타데이터 경로​

Task 4 — L2 어댑터 Latency/Capacity Health Check​

Task 5 — Device-aware Prefetch/Store Policy​

진행 순서 / 의존성​

의외의 연결​

관련 페이지​

한 눈에

Task 1 — L2 어댑터 단계별 Latency Histogram

채택 설계 — adapter-aware 2+N 단계 모델

코드 현황 (2026-05-22 확인)

PR 분할 계획

PR #1 체크리스트

Task 2 — `lmcache storage describe` CLI

Task 3 — fs_connector O_DIRECT 메타데이터 경로

Task 4 — L2 어댑터 Latency/Capacity Health Check

Task 5 — Device-aware Prefetch/Store Policy

진행 순서 / 의존성

의외의 연결

관련 페이지