DFS 캐싱과 일관성

Jan 23, 2026 · Updated Jan 27, 2026

핵심 개념

DFS 캐싱은 네트워크 트래픽과 디스크 I/O를 줄이기 위해 클라이언트에 데이터를 캐싱하고, 캐시된 복사본과 서버의 마스터 복사본 간 일관성을 유지하는 메커니즘이다.

동작 원리

캐시 위치

캐시 위치 비교

디스크 캐시

신뢰성 ✓ 느린 접근

메모리 캐시

빠른 접근 휘발성

현대 구현은 주로 메모리 캐시를 사용한다.

캐싱 단위

블록 단위: NFS 방식. 필요한 블록만 캐시 (4KB, 8KB)
파일 단위: OpenAFS 방식. 큰 청크(64KB) 또는 전체 파일 캐시
큰 단위 → 히트율 상승, 미스 페널티 증가, 일관성 문제 증가

캐시 업데이트 정책

정책	설명	장점	단점
Write-Through	쓰기 즉시 서버 반영	신뢰성 높음	쓰기 성능 저하
Delayed Write	나중에 서버 반영	빠른 쓰기, 중복 쓰기 최적화	신뢰성 낮음
주기적 Flush	정기적으로 변경 블록 전송	균형잡힌 접근	지연 존재
Write-on-Close	파일 닫을 때 전송 (OpenAFS)	서버 트래픽 최소화	닫기 지연

NFS는 데이터에 주기적 flush, 메타데이터는 동기적 write (구조 손상 방지)를 사용한다.

캐시 일관성 (Cache Consistency)

캐시와 서버 마스터가 불일치할 수 있는 문제를 해결하는 두 가지 접근법:

클라이언트 주도 (Client-Initiated): 클라이언트가 서버에 유효성 검사 요청. 빈번한 검사 → 부하 증가
서버 주도 (Server-Initiated): 서버가 충돌 감지 시 클라이언트에 콜백 알림 전송 (OpenAFS). 충돌 시 캐싱 비활성화

서버 주도 일관성 관리

1 Client A

파일 F를 읽기 모드로 캐시

2 Client B

쓰기 모드로 열기 요청

3 충돌 감지

서버가 동시 접근 감지

4 해결

콜백 전송 or 캐싱 비활성화

클러스터 기반 DFS의 일관성

HDFS: append-only, 단일 writer → 일관성 단순
GFS: 랜덤 쓰기, 동시 writer 허용 → 복잡한 일관성 보장

예시

Write-Through = 공유 문서에 글 쓸 때마다 바로 저장
Write-on-Close = 문서 작업 완료 후 닫을 때 저장

Write-on-Close 시나리오

1 open()

파일을 캐시에 복사

2 write()

로컬 캐시에만 쓰기

3 write()

로컬 캐시에만 쓰기

4 close()

이 시점에 서버로 전송

Write-on-Close 사용 시, 같은 파일을 여러 클라이언트가 동시에 열면 일관성 문제가 발생할 수 있다.