Scarab Diagnostic Suite 현장 테스트 #013: Kubernetes Watch Cache 임계 구역 경계

이 현장 테스트는 Kubernetes를 대상으로 진행되었습니다.

해당 이슈는 Kubernetes #138728입니다:

https://github.com/kubernetes/kubernetes/issues/138728

이 이슈는 초기 이벤트(initial events) 주변의 watch cache 경로와 관련이 있었습니다.

유용한 진단 경계(diagnostic boundary)는 다음과 같습니다:

watch cache 일관성 작업 (watch cache consistency work) → 읽기 잠금 유지 시간 (read lock hold time) → 초기 이벤트 전달 (initial event delivery)

이것이 중요한 이유는 Kubernetes의 캐시 경로가 단순한 저장 세부 사항이 아니기 때문입니다.

캐시 경로는 저장된 상태(stored state)와 해당 상태를 관찰하는 클라이언트(clients) 사이에 위치합니다.

캐시 잠금(cache lock)이 유지되는 동안 너무 많은 작업이 발생하면, 시스템이 논리적으로는 여전히 올바를 수 있지만, 운영 경로(operational path)가 필요 이상으로 더 많은 비용을 발생시키거나, 더 많이 차단(blocking)되거나, 확장(scale)하기 어려워질 수 있습니다.

로컬 수정 후보(local repair candidate)는 의도적으로 좁게 설정되었습니다.

이는 watch cache를 재설계하지 않습니다.

더 넓은 저장 모델(storage model)을 변경하지도 않습니다.

WatchList 동작을 다시 작성하지도 않습니다.

패치는 watch-cache 읽기 잠금(read lock)이 유지되는 동안 발생하는 작업량을 줄이는 데 집중합니다.

순서가 있는 저장소(ordered stores)의 경우, 수정안은 간격 생성(interval construction) 동안 저렴한 스냅샷 경계(snapshot boundary)를 유지하되, 전체 순서 목록 구체화(full ordered list materialization)는 watcher 경로에 의해 간격이 소비될 때까지 지연(defer)시킵니다.

쉬운 말로 설명하자면:

잠금(lock) 하에서 필요한 캐시 경계를 가져옵니다.

안전하게 지연시킬 수 있다면, 그곳에서 무거운 목록 구체화(list materialization)를 수행하지 마십시오.

로컬 패치는 watch-cache 간격(interval) 구현과 그에 특화된 테스트에만 영향을 미쳤습니다.

관련 cacher 테스트, store 테스트, 전체 cacher 패키지 테스트 및 diff 위생(diff hygiene)에 대한 로컬 검증을 통과했습니다.

• 상태: 유지 관리자 검토를 위한 draft PR 오픈됨

현장 테스트 #013

• 프로젝트: Kubernetes
• 이슈 유형: watch-cache / 초기 이벤트(initial-events) 동작
• 경계: 잠금 하의 캐시 일관성 작업 vs 제한된 watcher 소비(bounded watcher consumption)
• 결과: 좁은 범위의 로컬 수정 후보 및 집중된 테스트 커버리지
• 상태: 로컬 증명 준비 완료; 아직 공개된 PR이나 코멘트는 없음

이번 현장 테스트가 중요한 이유는 Scarab이 주요 분산 시스템 (Distributed Systems) 플랫폼 내부에서 작동하는 모습을 보여주기 때문입니다.

버그의 형태는 단순한 충돌 (Crash)이 아니었습니다.

UI 이슈도 아니었습니다.

설정 불일치 (Configuration mismatch) 문제도 아니었습니다.

그것은 고압력 캐시 경로 (High-pressure cache path) 내의 기계적 경계 (Mechanical boundary) 문제였습니다.

시스템은 캐시의 진실성 (Cache truth)을 보존해야 하지만, 동시에 운영상의 진실성 (Operational truth)도 보존해야 합니다. 즉, 잠금 (Lock) 하에서 얼마나 많은 작업이 발생하는지, 상태 (State)가 어디에서 구체화 (Materialized)되는지, 그리고 해당 경로가 처리하는 워크로드 (Workload)에 대해 충분히 유계 (Bounded)된 상태를 유지하는지 등을 의미합니다.

이것이 바로 Scarab이 드러내도록 설계된 소프트웨어 진실성 경계 (Software truth boundary)의 종류입니다.

때때로 중요한 수리는 대규모 재작성 (Rewrite)이 아닙니다.

때로는 작업을 경계의 올바른 쪽으로 이동시키는 것일 수도 있습니다.