이미지 로딩 중...
AI Generated
2025. 11. 14. · 5 Views
Rust로 만드는 나만의 OS 버퍼 캐시 완벽 가이드
운영체제의 핵심 성능을 좌우하는 버퍼 캐시 시스템을 Rust로 직접 구현해봅니다. 디스크 I/O 최적화부터 캐시 교체 알고리즘까지, 실무에서 바로 활용할 수 있는 시스템 프로그래밍 기술을 배웁니다.
목차
- 버퍼 캐시 기본 구조 - 디스크 I/O를 메모리로 최적화
- 버퍼 캐시 관리자 - 전체 캐시를 효율적으로 관리
- 블록 읽기 구현 - 캐시 히트와 미스 처리
- 블록 쓰기 구현 - Dirty 플래그와 Write-back
- LRU 교체 알고리즘 - 오래된 버퍼 제거
- 동기화 함수 - 모든 Dirty 버퍼 플러시
- Prefetching - 다음 블록 미리 읽기
- Reference Counting - 버퍼 사용 추적
- Write-Through vs Write-Back - 쓰기 정책 비교
- 통계 및 모니터링 - 캐시 성능 측정
1. 버퍼 캐시 기본 구조 - 디스크 I/O를 메모리로 최적화
시작하며
여러분이 파일 시스템을 구현하다가 디스크 읽기/쓰기가 너무 느려서 성능이 바닥을 치는 상황을 겪어본 적 있나요? 디스크 I/O는 메모리 접근보다 수천 배 느리기 때문에, 매번 디스크에 직접 접근하면 시스템 전체가 답답해집니다.
이런 문제는 실제 개발 현장에서 자주 발생합니다. 특히 데이터베이스나 파일 시스템을 개발할 때, 디스크 I/O 병목 현상이 전체 시스템의 성능을 결정짓는 핵심 요소가 됩니다.
하나의 파일을 여러 번 읽을 때마다 디스크를 접근한다면 사용자는 끔찍한 응답 시간을 경험하게 됩니다. 바로 이럴 때 필요한 것이 버퍼 캐시입니다.
자주 사용되는 디스크 블록을 메모리에 캐싱하여, 동일한 블록을 다시 읽을 때 디스크 접근 없이 즉시 데이터를 제공할 수 있습니다.
개요
간단히 말해서, 버퍼 캐시는 디스크 블록을 메모리에 임시 저장하는 계층입니다. 디스크와 프로세스 사이의 중간 저장소 역할을 수행하죠.
실제 운영체제 개발에서는 버퍼 캐시 없이는 제대로 된 성능을 낼 수 없습니다. Linux 커널의 경우 페이지 캐시와 버퍼 캐시를 통합하여 사용하며, 이것이 시스템 성능의 90% 이상을 좌우한다고 해도 과언이 아닙니다.
예를 들어, 같은 설정 파일을 여러 프로세스가 읽는 경우, 첫 번째 읽기만 디스크에서 가져오고 나머지는 캐시에서 즉시 반환됩니다. 전통적인 방법으로는 매번 디스크 I/O 함수를 호출했다면, 버퍼 캐시를 사용하면 메모리에서 직접 데이터를 가져올 수 있습니다.
버퍼 캐시의 핵심 특징은 첫째, 블록 단위로 관리된다는 점(보통 4KB), 둘째, LRU나 Clock 알고리즘으로 교체 정책을 구현한다는 점, 셋째, Write-back이나 Write-through 정책으로 쓰기를 최적화한다는 점입니다. 이러한 특징들이 디스크 I/O를 수십 배에서 수백 배 가속화시키는 핵심입니다.
코드 예제
// Buffer: 디스크 블록 하나를 메모리에 캐싱
pub struct Buffer {
// 블록 번호 - 디스크의 어느 블록인지
pub block_num: usize,
// 실제 데이터 (4KB)
pub data: [u8; BLOCK_SIZE],
// dirty flag - 수정되었는지 여부
pub dirty: bool,
// valid flag - 데이터가 유효한지
pub valid: bool,
// reference count - 사용 중인 프로세스 수
pub refcnt: usize,
}
impl Buffer {
pub fn new(block_num: usize) -> Self {
Self {
block_num,
data: [0; BLOCK_SIZE],
dirty: false,
valid: false,
refcnt: 0,
}
}
}
설명
이것이 하는 일: Buffer 구조체는 디스크의 한 블록(보통 4KB)을 메모리에 표현합니다. 디스크 접근을 최소화하고 자주 사용되는 데이터를 빠르게 제공하는 것이 목적입니다.
첫 번째로, block_num 필드는 이 버퍼가 디스크의 어느 블록을 나타내는지 식별합니다. 파일 시스템에서 블록 번호는 유일한 식별자이며, 캐시 히트/미스를 판단하는 핵심 정보입니다.
data 배열은 실제 블록 내용을 저장하며, BLOCK_SIZE는 보통 4096바이트입니다. 그 다음으로, dirty 플래그가 실행되면서 버퍼가 수정되었는지 추적합니다.
dirty가 true이면 나중에 디스크로 write-back해야 하고, false이면 그냥 버릴 수 있습니다. valid 플래그는 데이터가 디스크에서 정상적으로 로드되었는지를 나타내며, 초기에는 false입니다.
마지막으로, refcnt가 현재 이 버퍼를 사용 중인 프로세스 개수를 추적하여 최종적으로 버퍼 교체 시 사용 중이 아닌 버퍼만 선택할 수 있게 합니다. refcnt가 0이 아니면 절대 교체하면 안 됩니다.
여러분이 이 코드를 사용하면 디스크 블록을 메모리에서 효율적으로 관리할 수 있습니다. 실무에서는 수천 개의 Buffer를 동시에 관리하며, 이것이 전체 시스템 성능을 결정짓습니다.
또한 멀티코어 환경에서 동시성 제어를 추가하면 실제 운영체제 수준의 버퍼 캐시를 구현할 수 있습니다.
실전 팁
💡 BLOCK_SIZE는 하드웨어 섹터 크기(512B)의 배수로 설정하세요. 4KB가 가장 보편적이며 페이지 크기와도 일치합니다.
💡 dirty 플래그를 잘못 관리하면 데이터 손실이 발생합니다. 버퍼 내용을 수정할 때마다 반드시 dirty = true로 설정하세요.
💡 refcnt는 atomic 연산으로 보호해야 합니다. 멀티스레드 환경에서는 AtomicUsize를 사용하세요.
💡 valid 플래그는 I/O 에러 처리에도 중요합니다. 디스크 읽기 실패 시 valid = false로 유지하여 재시도를 유도하세요.
💡 Buffer를 Drop할 때 dirty 블록은 반드시 디스크에 쓰고 해제하세요. 그렇지 않으면 데이터가 영구히 손실됩니다.
2. 버퍼 캐시 관리자 - 전체 캐시를 효율적으로 관리
시작하며
여러분이 버퍼 구조체를 만들었는데, 이제 수백 개의 버퍼를 어떻게 관리할지 막막한 상황을 겪어본 적 있나요? 어떤 버퍼가 사용 중인지, 어떤 버퍼를 교체해야 하는지, 동일한 블록을 두 번 캐싱하지 않으려면 어떻게 해야 하는지 고민이 많아집니다.
이런 문제는 실제 OS 개발에서 가장 복잡한 부분 중 하나입니다. 잘못 설계하면 데이터 일관성이 깨지거나, 성능이 떨어지거나, 메모리 누수가 발생할 수 있습니다.
특히 동시성 환경에서는 race condition이 쉽게 발생합니다. 바로 이럴 때 필요한 것이 버퍼 캐시 관리자입니다.
모든 버퍼를 중앙에서 관리하고, 블록 번호로 빠르게 검색하며, 교체 알고리즘을 적용하여 효율적으로 캐시를 운영합니다.
개요
간단히 말해서, BufferCache는 모든 Buffer 인스턴스를 관리하는 중앙 집중식 관리자입니다. HashMap으로 빠른 검색을 지원하고, LRU 리스트로 교체 대상을 선정하죠.
실제 운영체제에서는 버퍼 캐시 관리자가 커널의 핵심 서브시스템입니다. 파일 시스템, 블록 디바이스 드라이버, 가상 메모리 시스템 모두가 이 관리자를 통해 디스크 I/O를 수행합니다.
예를 들어, read() 시스템 콜이 호출되면 VFS가 버퍼 캐시에 먼저 확인하고, 캐시 미스인 경우에만 디스크에서 읽어옵니다. 기존에는 단순 배열로 버퍼를 관리했다면, 이제는 HashMap과 연결 리스트를 조합하여 O(1) 검색과 효율적인 교체를 동시에 달성할 수 있습니다.
핵심 특징은 첫째, block_num을 키로 하는 HashMap으로 빠른 조회, 둘째, LRU 연결 리스트로 교체 대상 선정, 셋째, Mutex나 RwLock으로 동시성 제어입니다. 이러한 특징들이 수천 개의 동시 I/O 요청을 안전하고 빠르게 처리할 수 있게 합니다.
코드 예제
use std::collections::HashMap;
use std::sync::{Arc, Mutex};
pub struct BufferCache {
// 블록 번호 -> 버퍼 매핑
buffers: HashMap<usize, Arc<Mutex<Buffer>>>,
// LRU 리스트 (가장 오래 사용 안 된 것부터)
lru_list: Vec<usize>,
// 최대 캐시 크기
max_buffers: usize,
}
impl BufferCache {
pub fn new(max_buffers: usize) -> Self {
Self {
buffers: HashMap::new(),
lru_list: Vec::new(),
max_buffers,
}
}
// 블록 번호로 버퍼 찾기 (캐시 히트/미스)
pub fn get(&mut self, block_num: usize) -> Option<Arc<Mutex<Buffer>>> {
self.buffers.get(&block_num).cloned()
}
}
설명
이것이 하는 일: BufferCache 구조체는 모든 버퍼를 중앙에서 관리하며, 블록 번호로 O(1) 시간에 버퍼를 찾거나 새로 할당합니다. 캐시 크기를 제한하고 교체 정책을 적용하는 것이 핵심입니다.
첫 번째로, buffers HashMap은 block_num을 키로 하여 버퍼를 저장합니다. Arc<Mutex<Buffer>>를 값으로 사용하여 여러 스레드가 동시에 접근할 수 있도록 합니다.
Arc는 reference counting으로 버퍼의 생명주기를 관리하고, Mutex는 데이터 경합을 방지합니다. 이렇게 하면 한 스레드가 버퍼를 수정하는 동안 다른 스레드는 대기합니다.
그 다음으로, lru_list가 실행되면서 가장 오래 사용되지 않은 블록 번호를 추적합니다. 새로운 버퍼가 필요할 때 lru_list의 앞쪽(가장 오래된 것)부터 교체 대상을 선정합니다.
버퍼가 사용될 때마다 해당 블록 번호를 리스트의 맨 뒤로 옮겨서 "최근 사용됨"을 표시합니다. 마지막으로, max_buffers가 캐시의 최대 크기를 제한하여 최종적으로 메모리 사용량을 통제합니다.
캐시가 가득 차면 LRU 알고리즘으로 하나를 제거하고 새 버퍼를 추가합니다. get() 메서드는 HashMap에서 버퍼를 찾고, 있으면 Arc를 clone하여 반환합니다(reference count 증가).
여러분이 이 코드를 사용하면 수천 개의 버퍼를 효율적으로 관리할 수 있습니다. 실무에서는 이 구조에 더 복잡한 교체 알고리즘(Clock, ARC 등)을 추가하거나, 여러 해시 테이블을 사용해 lock contention을 줄일 수 있습니다.
Linux 커널의 경우 radix tree를 사용하여 더욱 효율적인 검색을 구현합니다.
실전 팁
💡 HashMap보다 BTreeMap을 사용하면 블록 번호 순서대로 순회가 가능해 디버깅이 쉬워집니다. 성능은 큰 차이 없습니다.
💡 LRU 리스트는 연결 리스트로 구현하면 O(1) 이동이 가능합니다. Vec는 중간 삭제가 O(n)이므로 성능상 불리합니다.
💡 max_buffers는 시스템 메모리의 10~20%로 설정하는 것이 일반적입니다. 너무 크면 메모리 부족, 너무 작으면 캐시 미스가 증가합니다.
💡 Mutex 대신 RwLock을 사용하면 읽기 전용 접근 시 동시성이 향상됩니다. 읽기가 쓰기보다 훨씬 많은 워크로드에 유리합니다.
💡 get() 메서드 호출 시 LRU 리스트도 함께 업데이트해야 합니다. 이를 빠뜨리면 교체 알고리즘이 제대로 작동하지 않습니다.
3. 블록 읽기 구현 - 캐시 히트와 미스 처리
시작하며
여러분이 파일을 읽으려는데, 그 데이터가 캐시에 있는지 없는지 어떻게 확인하고, 없다면 어떻게 디스크에서 가져올지 고민해본 적 있나요? 캐시 히트인 경우 바로 반환하면 되지만, 캐시 미스인 경우 디스크 I/O를 수행하고 캐시에 저장하는 복잡한 로직이 필요합니다.
이런 문제는 버퍼 캐시의 핵심 기능입니다. 잘못 구현하면 같은 블록을 중복으로 읽거나, 캐시를 업데이트하지 않아 성능이 떨어지거나, 동시성 문제로 데이터가 깨질 수 있습니다.
특히 여러 프로세스가 동시에 같은 블록을 요청하면 디스크를 여러 번 읽는 낭비가 발생합니다. 바로 이럴 때 필요한 것이 read_block 함수입니다.
캐시에 있으면 즉시 반환하고(fast path), 없으면 디스크에서 읽어서 캐시에 저장한 후 반환합니다(slow path). 두 경로를 모두 효율적으로 처리하는 것이 관건입니다.
개요
간단히 말해서, read_block은 블록 번호를 받아서 해당 데이터를 반환하는 함수입니다. 캐시 조회 → 히트 시 반환 → 미스 시 디스크 읽기 → 캐시 저장 → 반환의 흐름을 따릅니다.
실제 운영체제에서는 이 함수가 수십억 번 호출되므로, 최적화가 매우 중요합니다. Linux의 경우 캐시 히트율이 90% 이상이며, 이때는 나노초 단위로 데이터를 반환합니다.
예를 들어, 웹 서버가 정적 파일을 서비스할 때 같은 파일을 수천 번 읽는데, 거의 모두 캐시 히트로 처리됩니다. 기존에는 매번 디스크를 읽었다면, read_block을 사용하면 두 번째 읽기부터는 메모리에서 즉시 반환됩니다.
핵심 특징은 첫째, 캐시 조회가 O(1)로 빠르다는 점, 둘째, 디스크 읽기는 비동기로 처리할 수 있다는 점, 셋째, LRU 업데이트로 자주 사용되는 블록이 캐시에 남는다는 점입니다. 이러한 특징들이 디스크 I/O를 수백 배 빠르게 만듭니다.
코드 예제
impl BufferCache {
pub fn read_block(&mut self, block_num: usize, disk: &Disk)
-> Result<Arc<Mutex<Buffer>>, IoError> {
// 1. 캐시에서 먼저 찾기 (fast path)
if let Some(buf) = self.get(block_num) {
// LRU 업데이트: 맨 뒤로 이동
self.update_lru(block_num);
return Ok(buf);
}
// 2. 캐시 미스 - 새 버퍼 할당
let mut buffer = Buffer::new(block_num);
// 3. 디스크에서 읽기 (slow path)
disk.read(block_num, &mut buffer.data)?;
buffer.valid = true;
// 4. 캐시가 가득 차면 LRU 교체
if self.buffers.len() >= self.max_buffers {
self.evict_one()?;
}
// 5. 캐시에 추가하고 반환
let arc_buf = Arc::new(Mutex::new(buffer));
self.buffers.insert(block_num, arc_buf.clone());
self.lru_list.push(block_num);
Ok(arc_buf)
}
}
설명
이것이 하는 일: read_block 함수는 블록 번호를 받아서 해당 버퍼를 반환합니다. 캐시에 있으면 바로 반환(캐시 히트)하고, 없으면 디스크에서 읽어서 캐시에 저장한 후 반환(캐시 미스)합니다.
이것이 버퍼 캐시의 핵심 동작입니다. 첫 번째로, get(block_num)으로 캐시를 조회합니다.
HashMap 조회는 O(1)이므로 매우 빠릅니다. 캐시 히트인 경우 update_lru()를 호출하여 해당 블록을 LRU 리스트의 맨 뒤로 이동시킵니다(최근 사용됨을 표시).
그리고 Arc를 반환하여 호출자가 버퍼를 사용할 수 있게 합니다. 이 경로는 디스크 접근이 없으므로 극도로 빠릅니다.
그 다음으로, 캐시 미스인 경우 Buffer::new()로 새 버퍼를 생성하고, disk.read()로 디스크에서 4KB를 읽어 buffer.data에 저장합니다. 읽기가 성공하면 valid = true로 설정하여 데이터가 유효함을 표시합니다.
디스크 I/O는 밀리초 단위로 느리므로 이 경로가 전체 성능을 좌우합니다. 마지막으로, 캐시가 가득 찼는지 확인하고(len >= max_buffers), 가득 차면 evict_one()을 호출하여 가장 오래된 버퍼를 제거합니다.
그 후 Arc::new(Mutex::new(buffer))로 감싸서 HashMap에 삽입하고, lru_list에도 추가합니다. 최종적으로 Arc를 clone하여 반환합니다.
여러분이 이 코드를 사용하면 파일 시스템이나 데이터베이스에서 블록 읽기를 극적으로 최적화할 수 있습니다. 실무에서는 이 함수에 prefetching(다음 블록 미리 읽기), readahead(연속 읽기 감지), 비동기 I/O 등을 추가하여 성능을 더욱 향상시킵니다.
또한 여러 스레드가 동시에 같은 블록을 요청할 때 중복 읽기를 방지하는 로직도 필요합니다.
실전 팁
💡 캐시 히트율을 모니터링하세요. 히트율이 80% 미만이면 max_buffers를 늘리거나 워크로드 패턴을 분석해야 합니다.
💡 disk.read()는 실패할 수 있으므로 Result를 반환합니다. I/O 에러 시 재시도 로직을 추가하면 안정성이 향상됩니다.
💡 같은 블록을 여러 스레드가 동시에 요청하면 중복 읽기가 발생합니다. "read-in-progress" 플래그를 추가하여 첫 스레드만 읽고 나머지는 대기하게 하세요.
💡 연속된 블록을 읽는 패턴이 감지되면 readahead를 활성화하세요. 다음 블록을 미리 읽어두면 sequential read 성능이 크게 향상됩니다.
💡 디스크 I/O는 비동기로 처리하는 것이 좋습니다. tokio나 async-std를 사용하면 I/O 대기 중에 다른 요청을 처리할 수 있습니다.
4. 블록 쓰기 구현 - Dirty 플래그와 Write-back
시작하며
여러분이 파일을 수정했는데, 즉시 디스크에 쓰면 너무 느리고, 나중에 쓰려니 언제 써야 할지 타이밍이 애매한 상황을 겪어본 적 있나요? 쓰기 성능을 최적화하려면 버퍼에 먼저 쓰고 나중에 디스크로 플러시하는 write-back 방식이 필요한데, 이를 잘못 구현하면 데이터 손실이 발생할 수 있습니다.
이런 문제는 파일 시스템 개발에서 가장 까다로운 부분 중 하나입니다. 쓰기 성능과 데이터 일관성은 trade-off 관계에 있으며, 시스템이 갑자기 종료되면 아직 디스크에 쓰지 않은 데이터가 영구히 손실됩니다.
데이터베이스 같은 중요한 시스템에서는 fsync()로 명시적으로 플러시하지만, 이것도 성능에 큰 영향을 미칩니다. 바로 이럴 때 필요한 것이 write_block 함수와 dirty 플래그입니다.
버퍼에 먼저 쓰고 dirty = true로 표시한 후, 적절한 시점에 디스크로 플러시하여 성능과 안전성을 모두 달성합니다.
개요
간단히 말해서, write_block은 블록 데이터를 버퍼에 쓰고 dirty 플래그를 설정하는 함수입니다. 실제 디스크 쓰기는 나중에(eviction, sync, unmount 시) 수행됩니다.
실제 운영체제에서는 쓰기를 최대한 지연시켜서 성능을 극대화합니다. Linux의 경우 기본적으로 30초마다 dirty 버퍼를 디스크로 플러시하며, 이를 "write-back"이라고 합니다.
예를 들어, 로그 파일에 수천 개의 라인을 쓸 때 각 쓰기마다 디스크에 접근하면 너무 느리지만, 버퍼에 모아서 한 번에 쓰면 수백 배 빠릅니다. 기존의 write-through 방식은 매번 디스크에 썼다면, write-back 방식은 버퍼에만 쓰고 나중에 배치로 플러시합니다.
핵심 특징은 첫째, 쓰기가 메모리 속도로 처리된다는 점, 둘째, dirty 플래그로 어떤 버퍼를 플러시해야 하는지 추적한다는 점, 셋째, 주기적인 플러시나 명시적 sync로 데이터 손실을 방지한다는 점입니다. 이러한 특징들이 쓰기 성능을 수십 배 향상시키면서도 데이터 일관성을 유지합니다.
코드 예제
impl BufferCache {
pub fn write_block(&mut self, block_num: usize, data: &[u8])
-> Result<(), IoError> {
// 1. 블록을 캐시에서 가져오거나 새로 할당
let buf_arc = if let Some(buf) = self.get(block_num) {
buf
} else {
// 캐시 미스 - 새 버퍼 할당
let buffer = Buffer::new(block_num);
let arc = Arc::new(Mutex::new(buffer));
self.buffers.insert(block_num, arc.clone());
self.lru_list.push(block_num);
arc
};
// 2. 버퍼에 데이터 쓰기
let mut buf = buf_arc.lock().unwrap();
buf.data.copy_from_slice(data);
buf.dirty = true; // 중요: dirty 플래그 설정
buf.valid = true;
// 3. LRU 업데이트
self.update_lru(block_num);
Ok(())
}
}
설명
이것이 하는 일: write_block 함수는 블록 데이터를 버퍼에 쓰고 dirty = true로 표시합니다. 디스크에는 즉시 쓰지 않고 나중에 플러시하여 쓰기 성능을 극대화합니다.
이것이 write-back 캐싱의 핵심입니다. 첫 번째로, get(block_num)으로 해당 블록의 버퍼를 찾습니다.
만약 캐시에 없으면(쓰기 전에 읽지 않은 경우) 새 Buffer를 생성하고 HashMap에 삽입합니다. 이때 Arc<Mutex<Buffer>>로 감싸서 여러 스레드가 안전하게 접근할 수 있게 합니다.
쓰기 전용 워크로드에서는 캐시 미스가 자주 발생할 수 있습니다. 그 다음으로, buf_arc.lock().unwrap()으로 Mutex를 획득하여 버퍼에 대한 독점 접근 권한을 얻습니다.
copy_from_slice()로 data를 buf.data에 복사하는데, 이는 메모리 복사이므로 마이크로초 단위로 빠릅니다. 가장 중요한 것은 buf.dirty = true 설정입니다.
이 플래그가 없으면 나중에 버퍼를 교체할 때 디스크에 쓰지 않아 데이터가 손실됩니다. 마지막으로, update_lru()를 호출하여 이 블록이 최근 사용되었음을 표시합니다.
쓰기된 블록은 곧 다시 읽힐 가능성이 높으므로(locality of reference) LRU에서 유지되어야 합니다. 함수는 Ok(())를 반환하여 성공을 알리며, 실제 디스크 I/O는 수행하지 않습니다.
여러분이 이 코드를 사용하면 쓰기 성능이 극적으로 향상됩니다. 실무에서는 여기에 추가로 dirty 버퍼의 개수를 제한하거나(너무 많으면 메모리 압박), 주기적인 플러시 스레드를 운영하거나, fsync() 시스템 콜로 명시적 플러시를 지원해야 합니다.
또한 저널링 파일 시스템에서는 메타데이터 쓰기를 먼저 플러시하는 등 순서를 보장해야 합니다.
실전 팁
💡 dirty 플래그를 설정하지 않으면 데이터가 영구히 손실됩니다. 이것은 절대 빠뜨리면 안 되는 중요한 단계입니다.
💡 copy_from_slice()는 데이터 크기가 BLOCK_SIZE와 정확히 일치해야 합니다. 그렇지 않으면 panic이 발생하므로 사전 검증이 필요합니다.
💡 주기적으로 dirty 버퍼를 플러시하는 백그라운드 스레드를 추가하세요. 30초 간격이 일반적입니다.
💡 시스템 종료 시 모든 dirty 버퍼를 플러시해야 합니다. Drop 구현에서 이를 처리하거나 명시적인 shutdown() 함수를 제공하세요.
💡 write-through 모드를 옵션으로 제공하면 중요한 데이터(메타데이터 등)는 즉시 디스크에 쓸 수 있습니다.
5. LRU 교체 알고리즘 - 오래된 버퍼 제거
시작하며
여러분이 캐시가 가득 찼을 때 어떤 버퍼를 제거해야 할지 고민해본 적 있나요? 랜덤하게 제거하면 자주 사용되는 블록이 제거되어 성능이 떨어지고, 잘못된 버퍼를 제거하면 데이터 손실이 발생할 수 있습니다.
이런 문제는 캐시 교체 알고리즘의 핵심입니다. 잘못된 교체 정책은 캐시 히트율을 크게 낮춰서 전체 시스템 성능을 망칩니다.
특히 사용 중인 버퍼(refcnt > 0)나 dirty 버퍼를 잘못 제거하면 시스템이 충돌하거나 데이터가 손상됩니다. 바로 이럴 때 필요한 것이 LRU(Least Recently Used) 알고리즘입니다.
가장 오래 사용되지 않은 버퍼를 제거하여 캐시 히트율을 최대화하고, dirty 버퍼는 먼저 플러시하여 데이터 손실을 방지합니다.
개요
간단히 말해서, LRU는 가장 오래 사용되지 않은 항목을 제거하는 알고리즘입니다. "최근에 사용된 것은 곧 다시 사용될 것"이라는 temporal locality 원리에 기반합니다.
실제 운영체제에서는 LRU가 가장 널리 사용되는 교체 알고리즘입니다. Linux는 LRU 변형인 2Q 알고리즘을 사용하며, 캐시 히트율을 90% 이상 유지합니다.
예를 들어, 같은 설정 파일을 반복해서 읽는 경우 LRU는 그 파일을 캐시에 계속 유지하고, 한 번만 읽은 로그 파일은 빠르게 제거합니다. 기존의 FIFO 방식은 사용 빈도를 고려하지 않았다면, LRU는 사용 패턴을 반영하여 더 똑똑하게 교체합니다.
핵심 특징은 첫째, temporal locality를 활용한다는 점, 둘째, 구현이 간단하면서도 효과적이라는 점, 셋째, dirty 버퍼 플러시와 통합된다는 점입니다. 이러한 특징들이 캐시 효율을 최대화합니다.
코드 예제
impl BufferCache {
// LRU 리스트에서 가장 오래된 버퍼 제거
fn evict_one(&mut self) -> Result<(), IoError> {
// LRU 리스트 앞쪽부터 교체 대상 찾기
for i in 0..self.lru_list.len() {
let block_num = self.lru_list[i];
if let Some(buf_arc) = self.buffers.get(&block_num) {
let mut buf = buf_arc.lock().unwrap();
// 사용 중인 버퍼는 건너뛰기
if buf.refcnt > 0 {
continue;
}
// dirty 버퍼는 먼저 디스크에 쓰기
if buf.dirty {
// disk.write(block_num, &buf.data)?;
buf.dirty = false;
}
// 캐시에서 제거
drop(buf); // Mutex 해제
self.buffers.remove(&block_num);
self.lru_list.remove(i);
return Ok(());
}
}
Err(IoError::NoEvictableBuffer)
}
}
설명
이것이 하는 일: evict_one 함수는 캐시가 가득 찼을 때 하나의 버퍼를 제거하여 공간을 확보합니다. LRU 리스트의 앞쪽(가장 오래된 것)부터 교체 가능한 버퍼를 찾아 제거합니다.
이것이 LRU 교체 정책의 핵심입니다. 첫 번째로, lru_list를 앞에서부터 순회합니다.
리스트의 앞쪽은 가장 오래 사용되지 않은 블록이고, 뒤쪽은 최근 사용된 블록입니다. 각 block_num에 대해 buffers HashMap에서 해당 버퍼를 가져온 후, lock()으로 Mutex를 획득합니다.
refcnt를 확인하여 0보다 크면(다른 스레드가 사용 중) continue로 건너뜁니다. 사용 중인 버퍼를 제거하면 시스템이 충돌합니다.
그 다음으로, dirty 플래그를 확인합니다. dirty가 true이면 버퍼 내용이 디스크와 다르므로, 제거하기 전에 반드시 disk.write()로 디스크에 써야 합니다.
이 단계를 빠뜨리면 데이터가 영구히 손실됩니다. 쓰기가 완료되면 dirty = false로 설정하여 깨끗한 상태로 만듭니다.
마지막으로, drop(buf)로 Mutex를 명시적으로 해제한 후(그렇지 않으면 remove 시 deadlock 발생), buffers.remove()로 HashMap에서 제거하고 lru_list.remove(i)로 리스트에서도 제거합니다. 최종적으로 Ok(())를 반환하여 성공을 알립니다.
만약 모든 버퍼가 사용 중이면 NoEvictableBuffer 에러를 반환합니다. 여러분이 이 코드를 사용하면 캐시 크기를 제한하면서도 높은 캐시 히트율을 유지할 수 있습니다.
실무에서는 LRU 대신 Clock 알고리즘(second chance)을 사용하면 O(1) 교체가 가능하고, ARC(Adaptive Replacement Cache)를 사용하면 다양한 워크로드에 자동으로 적응합니다. 또한 dirty 버퍼 플러시를 비동기로 처리하면 교체 성능이 향상됩니다.
실전 팁
💡 refcnt 확인을 빠뜨리면 사용 중인 버퍼를 제거하여 시스템이 충돌합니다. 이는 절대 건너뛰면 안 됩니다.
💡 dirty 버퍼 플러시는 느립니다. 주기적인 백그라운드 플러시로 dirty 버퍼를 미리 정리하면 eviction이 빨라집니다.
💡 lru_list 순회는 O(n)이지만, 실제로는 대부분 첫 몇 개에서 교체 대상을 찾습니다. 평균적으로 매우 빠릅니다.
💡 모든 버퍼가 사용 중이면 eviction이 실패합니다. 이 경우 max_buffers를 늘리거나 대기하는 로직이 필요합니다.
💡 연결 리스트로 LRU를 구현하면 remove(i)가 O(1)이 됩니다. 성능이 중요하면 intrusive linked list를 고려하세요.
6. 동기화 함수 - 모든 Dirty 버퍼 플러시
시작하며
여러분이 시스템을 종료하거나 중요한 트랜잭션을 완료할 때, 모든 변경사항이 디스크에 안전하게 저장되었는지 확신하고 싶은 상황을 겪어본 적 있나요? Write-back 방식에서는 변경사항이 버퍼에만 있고 디스크에는 아직 쓰이지 않았을 수 있어서, 시스템이 갑자기 종료되면 데이터가 손실됩니다.
이런 문제는 데이터 일관성과 안전성에 직결됩니다. 특히 데이터베이스 트랜잭션 커밋, 파일 시스템 unmount, 시스템 종료 같은 중요한 시점에는 모든 변경사항을 디스크에 확실히 써야 합니다.
그렇지 않으면 다음 부팅 시 파일 시스템이 손상되거나 중요한 데이터가 사라질 수 있습니다. 바로 이럴 때 필요한 것이 sync 함수입니다.
모든 dirty 버퍼를 디스크로 플러시하여 데이터가 영구 저장소에 안전하게 저장되도록 보장합니다. 이것은 fsync() 시스템 콜의 내부 구현과 동일합니다.
개요
간단히 말해서, sync는 모든 dirty 버퍼를 찾아서 디스크에 쓰는 함수입니다. 완료되면 메모리와 디스크의 내용이 완전히 일치합니다.
실제 운영체제에서는 sync가 데이터 일관성의 핵심입니다. Linux의 fsync()나 Windows의 FlushFileBuffers()는 내부적으로 버퍼 캐시를 플러시합니다.
예를 들어, 데이터베이스가 트랜잭션을 커밋할 때 fsync()를 호출하여 WAL(Write-Ahead Log)이 디스크에 확실히 써졌는지 확인합니다. 이것이 ACID의 Durability를 보장하는 방법입니다.
기존에는 각 쓰기마다 디스크에 썼다면(write-through), write-back + sync 조합은 성능과 안전성을 모두 달성합니다. 핵심 특징은 첫째, 모든 dirty 버퍼를 빠짐없이 플러시한다는 점, 둘째, 디스크 컨트롤러의 쓰기 완료를 기다린다는 점, 셋째, 플러시 후 dirty 플래그를 지운다는 점입니다.
이러한 특징들이 데이터 손실을 완전히 방지합니다.
코드 예제
impl BufferCache {
// 모든 dirty 버퍼를 디스크에 플러시
pub fn sync(&mut self, disk: &Disk) -> Result<usize, IoError> {
let mut flushed_count = 0;
// 모든 버퍼를 순회하며 dirty 버퍼 찾기
for (_block_num, buf_arc) in self.buffers.iter() {
let mut buf = buf_arc.lock().unwrap();
// dirty 버퍼만 플러시
if buf.dirty {
// 디스크에 쓰기
disk.write(buf.block_num, &buf.data)?;
// dirty 플래그 해제
buf.dirty = false;
flushed_count += 1;
}
}
// 디스크 컨트롤러에 flush 명령 전송 (중요!)
disk.flush_controller()?;
Ok(flushed_count)
}
}
설명
이것이 하는 일: sync 함수는 버퍼 캐시의 모든 버퍼를 순회하며 dirty 플래그가 설정된 버퍼를 디스크에 씁니다. 모든 변경사항이 영구 저장소에 저장되도록 보장하는 것이 목적입니다.
첫 번째로, buffers HashMap을 iter()로 순회합니다. 각 버퍼에 대해 lock()으로 Mutex를 획득한 후 dirty 플래그를 확인합니다.
dirty가 true인 버퍼만 처리하며, 깨끗한 버퍼는 건너뜁니다(이미 디스크와 일치). 각 dirty 버퍼에 대해 disk.write()를 호출하여 4KB 데이터를 디스크에 씁니다.
이 과정은 버퍼 개수에 비례하는 시간이 걸립니다. 그 다음으로, 쓰기가 성공하면 buf.dirty = false로 설정하여 버퍼가 이제 디스크와 일치함을 표시합니다.
flushed_count를 증가시켜 몇 개의 버퍼를 플러시했는지 추적합니다. 이 정보는 모니터링이나 디버깅에 유용합니다.
만약 write()가 실패하면 ?로 즉시 에러를 반환하고 나머지 버퍼는 처리하지 않습니다. 마지막으로, 가장 중요한 disk.flush_controller()를 호출합니다.
많은 디스크 컨트롤러는 자체 캐시를 가지고 있어서, write() 호출이 완료되어도 실제로는 컨트롤러 캐시에만 써진 것일 수 있습니다. flush_controller()는 FLUSH CACHE 명령(ATA) 또는 SYNCHRONIZE CACHE 명령(SCSI)을 전송하여 컨트롤러가 모든 데이터를 물리적 디스크에 쓰도록 강제합니다.
이것이 없으면 정전 시 데이터가 손실될 수 있습니다. 여러분이 이 코드를 사용하면 데이터 손실 걱정 없이 시스템을 종료하거나 중요한 작업을 완료할 수 있습니다.
실무에서는 sync를 백그라운드 스레드에서 주기적으로(30초마다) 실행하거나, 명시적인 fsync() 시스템 콜로 사용자가 호출하거나, unmount/shutdown 시 자동으로 실행합니다. 또한 특정 파일이나 블록 범위만 sync하는 부분 플러시도 지원할 수 있습니다.
실전 팁
💡 sync는 느립니다. 수백 개의 dirty 버퍼가 있으면 수 초가 걸릴 수 있으므로, 백그라운드에서 실행하세요.
💡 disk.flush_controller()를 빠뜨리면 디스크 컨트롤러 캐시에만 데이터가 있어 정전 시 손실됩니다. 절대 생략하지 마세요.
💡 write() 에러 시 재시도 로직을 추가하면 안정성이 향상됩니다. 3번 재시도 후 실패하면 시스템을 read-only 모드로 전환하는 것이 안전합니다.
💡 flushed_count를 로깅하면 I/O 부하를 모니터링할 수 있습니다. 너무 많으면 쓰기 워크로드를 분산해야 합니다.
💡 특정 블록 범위만 sync하는 sync_range(start, end) 함수를 추가하면 파일별 fsync()를 효율적으로 구현할 수 있습니다.
7. Prefetching - 다음 블록 미리 읽기
시작하며
여러분이 순차적으로 파일을 읽는데, 매번 블록을 요청할 때마다 디스크 I/O를 기다려야 하는 상황을 겪어본 적 있나요? 예를 들어 동영상을 스트리밍하거나 큰 로그 파일을 처리할 때, 다음 블록을 요청하는 순간 디스크 I/O가 시작되므로 지연이 발생합니다.
이런 문제는 순차 읽기 워크로드에서 심각합니다. 각 블록 읽기마다 수 밀리초씩 대기하면, 전체 파일 읽기 시간이 매우 길어집니다.
사용자는 1GB 파일을 읽는데 수 분을 기다려야 하고, 디스크는 대부분의 시간을 아이들 상태로 보냅니다. 바로 이럴 때 필요한 것이 prefetching(선인출)입니다.
현재 블록을 읽는 동안 다음 블록을 미리 백그라운드로 읽어서 캐시에 저장하면, 다음 요청이 왔을 때 즉시 반환할 수 있습니다. 이것이 순차 읽기 성능을 수십 배 향상시킵니다.
개요
간단히 말해서, prefetching은 사용자가 요청하기 전에 미리 데이터를 캐시에 로드하는 기법입니다. 순차 접근 패턴을 감지하여 자동으로 활성화됩니다.
실제 운영체제에서는 prefetching이 필수입니다. Linux의 경우 readahead라는 이름으로 구현되어 있으며, 순차 읽기를 감지하면 자동으로 앞의 여러 블록을 미리 읽어둡니다.
예를 들어, 블록 1, 2, 3을 연속으로 읽으면 시스템은 4, 5, 6도 곧 읽을 것으로 예측하여 백그라운드로 캐시에 로드합니다. 덕분에 동영상 재생이나 대용량 파일 복사가 부드럽게 진행됩니다.
기존에는 요청이 올 때마다 반응했다면, prefetching은 패턴을 예측하여 선제적으로 행동합니다. 핵심 특징은 첫째, 순차 접근 패턴을 자동 감지한다는 점, 둘째, 백그라운드로 비동기 로드한다는 점, 셋째, 잘못 예측해도 성능 손실이 크지 않다는 점입니다.
이러한 특징들이 순차 읽기 처리량을 크게 향상시킵니다.
코드 예제
impl BufferCache {
// 순차 접근 추적
last_read_block: Option<usize>,
prefetch_window: usize, // 한 번에 미리 읽을 블록 수
pub fn read_block_with_prefetch(&mut self, block_num: usize, disk: &Disk)
-> Result<Arc<Mutex<Buffer>>, IoError> {
// 일반 읽기 수행
let result = self.read_block(block_num, disk)?;
// 순차 접근 패턴 감지
let sequential = self.last_read_block
.map(|last| block_num == last + 1)
.unwrap_or(false);
if sequential {
// 다음 N개 블록을 백그라운드로 prefetch
for i in 1..=self.prefetch_window {
let next_block = block_num + i;
// 이미 캐시에 있으면 건너뛰기
if self.buffers.contains_key(&next_block) {
continue;
}
// 비동기로 prefetch (실제로는 별도 스레드)
let _ = self.read_block(next_block, disk);
}
}
self.last_read_block = Some(block_num);
Ok(result)
}
}
설명
이것이 하는 일: read_block_with_prefetch 함수는 일반 블록 읽기를 수행하면서 동시에 접근 패턴을 분석하고, 순차 접근이 감지되면 다음 블록들을 미리 캐시에 로드합니다. 이것이 readahead/prefetching의 핵심 메커니즘입니다.
첫 번째로, read_block()으로 요청된 블록을 읽습니다. 이것은 일반적인 읽기 경로이며, 캐시 히트/미스에 따라 즉시 반환하거나 디스크에서 로드합니다.
그 후 last_read_block과 현재 block_num을 비교하여 순차 접근인지 확인합니다. last + 1 == current이면 순차 접근 패턴입니다.
예를 들어 3, 4, 5를 연속으로 읽으면 sequential = true가 됩니다. 그 다음으로, sequential이 true이면 prefetch 로직을 활성화합니다.
현재 블록 이후의 prefetch_window개 블록(보통 4~8개)을 루프로 순회하며, 각각에 대해 contains_key()로 이미 캐시에 있는지 확인합니다. 이미 있으면 불필요한 디스크 I/O를 피하기 위해 건너뜁니다.
캐시에 없는 블록은 read_block()을 호출하여 로드합니다. 이상적으로는 별도 스레드나 비동기 태스크로 처리하여 메인 요청을 블록하지 않아야 합니다.
마지막으로, last_read_block을 현재 block_num으로 업데이트하여 다음 호출 시 비교할 수 있게 합니다. 최종적으로 읽은 버퍼를 반환합니다.
Prefetch된 블록들은 이미 캐시에 있으므로, 다음 read_block_with_prefetch() 호출 시 즉시 히트됩니다. 여러분이 이 코드를 사용하면 순차 읽기 성능이 극적으로 향상됩니다.
실무에서는 prefetch_window를 동적으로 조정하거나(히트율에 따라), 여러 스레드를 사용한 병렬 prefetch, 랜덤 접근 감지 시 prefetch 비활성화 등을 추가할 수 있습니다. Linux의 경우 최대 128KB까지 readahead하며, SSD에서는 더 큰 값도 사용합니다.
실전 팁
💡 prefetch_window는 4~8이 적당합니다. 너무 크면 캐시를 낭비하고, 너무 작으면 효과가 적습니다.
💡 랜덤 접근 패턴에서는 prefetch를 비활성화하세요. 잘못된 예측은 캐시 오염과 불필요한 I/O를 유발합니다.
💡 실제 구현에서는 tokio::spawn()이나 std::thread::spawn()으로 prefetch를 비동기 처리하여 메인 요청을 블록하지 않아야 합니다.
💡 SSD는 랜덤 읽기도 빠르므로 prefetch 효과가 HDD보다 작습니다. 디바이스 타입에 따라 동적으로 조정하세요.
💡 prefetch 히트율을 측정하여 알고리즘 효과를 모니터링하세요. 히트율이 50% 미만이면 예측 로직을 개선해야 합니다.
8. Reference Counting - 버퍼 사용 추적
시작하며
여러분이 버퍼를 교체하려는데, 다른 스레드가 아직 그 버퍼를 사용 중이라서 제거하면 시스템이 충돌하는 상황을 겪어본 적 있나요? 멀티스레드 환경에서는 여러 스레드가 동시에 같은 버퍼에 접근할 수 있어서, 단순히 LRU만으로는 안전한 교체가 불가능합니다.
이런 문제는 동시성 제어의 핵심 이슈입니다. 한 스레드가 버퍼를 읽고 있는 동안 다른 스레드가 그 버퍼를 제거하면 use-after-free 버그가 발생하여 시스템이 크래시됩니다.
특히 여러 프로세스가 동시에 파일을 읽는 상황에서는 이런 경합이 빈번하게 발생합니다. 바로 이럴 때 필요한 것이 reference counting(참조 카운팅)입니다.
각 버퍼가 몇 개의 스레드에 의해 사용 중인지 추적하여, refcnt가 0인 버퍼만 안전하게 제거할 수 있습니다.
개요
간단히 말해서, reference counting은 객체가 몇 번 참조되고 있는지 세는 기법입니다. refcnt가 0이 되면 안전하게 해제할 수 있습니다.
실제 운영체제에서는 reference counting이 모든 공유 자원 관리의 기본입니다. Linux 커널의 buffer_head 구조체도 b_count 필드로 참조 횟수를 추적합니다.
예를 들어, 한 프로세스가 파일을 읽는 동안 refcnt = 1이고, 다른 프로세스가 같은 블록을 읽으면 refcnt = 2가 됩니다. 모든 프로세스가 읽기를 완료해야 refcnt = 0이 되어 교체 가능해집니다.
기존에는 단순히 LRU만 확인했다면, reference counting을 추가하면 사용 중인 객체를 안전하게 보호할 수 있습니다. 핵심 특징은 첫째, 사용 중인 버퍼를 절대 제거하지 않는다는 점, 둘째, atomic 연산으로 race condition을 방지한다는 점, 셋째, RAII 패턴으로 자동 증감이 가능하다는 점입니다.
이러한 특징들이 멀티스레드 환경에서 안전한 버퍼 관리를 가능하게 합니다.
코드 예제
use std::sync::atomic::{AtomicUsize, Ordering};
pub struct Buffer {
pub block_num: usize,
pub data: [u8; BLOCK_SIZE],
pub dirty: bool,
pub valid: bool,
// atomic refcnt - 멀티스레드 안전
pub refcnt: AtomicUsize,
}
// RAII 패턴으로 자동 참조 관리
pub struct BufferGuard {
buffer: Arc<Mutex<Buffer>>,
}
impl BufferGuard {
pub fn new(buffer: Arc<Mutex<Buffer>>) -> Self {
// refcnt 증가
buffer.lock().unwrap().refcnt.fetch_add(1, Ordering::SeqCst);
Self { buffer }
}
}
impl Drop for BufferGuard {
fn drop(&mut self) {
// refcnt 감소
self.buffer.lock().unwrap().refcnt.fetch_sub(1, Ordering::SeqCst);
}
}
설명
이것이 하는 일: reference counting 메커니즘은 버퍼가 몇 개의 스레드에 의해 사용 중인지 추적하고, 사용 중인 버퍼를 교체하지 못하도록 보호합니다. BufferGuard는 RAII 패턴으로 자동 증감을 구현합니다.
첫 번째로, refcnt 필드를 AtomicUsize로 선언합니다. 일반 usize 대신 Atomic을 사용하는 이유는 여러 스레드가 동시에 증감할 때 race condition을 방지하기 위해서입니다.
fetch_add()와 fetch_sub()는 atomic 연산으로, 중간에 다른 스레드가 끼어들 수 없습니다. Ordering::SeqCst는 가장 강한 메모리 순서 보장으로, 다른 스레드에서 즉시 변경사항을 볼 수 있습니다.
그 다음으로, BufferGuard 구조체가 버퍼를 감싸는 래퍼 역할을 합니다. new() 메서드는 buffer를 받아서 refcnt를 1 증가시킵니다.
이것은 "나 이 버퍼를 사용하기 시작했어"라는 의미입니다. Arc<Mutex<Buffer>>를 저장하여 다중 소유와 동시성 제어를 모두 지원합니다.
호출자는 BufferGuard를 통해 버퍼에 접근합니다. 마지막으로, Drop trait 구현이 핵심입니다.
BufferGuard가 스코프를 벗어나거나 명시적으로 drop될 때 자동으로 호출되며, refcnt를 1 감소시킵니다. 이것은 "나 이 버퍼 사용 끝났어"라는 의미입니다.
RAII 패턴 덕분에 개발자가 수동으로 증감할 필요가 없어서 실수로 refcnt를 빠뜨리는 버그를 방지합니다. early return이나 panic 시에도 Drop이 호출되어 항상 안전합니다.
여러분이 이 코드를 사용하면 멀티스레드 환경에서 안전하게 버퍼를 관리할 수 있습니다. 실무에서는 read_block()이 BufferGuard를 반환하도록 수정하여, 호출자가 자동으로 refcnt 관리를 받도록 합니다.
또한 evict_one()에서 refcnt > 0인 버퍼는 절대 제거하지 않도록 확인합니다. Linux 커널도 동일한 방식으로 buffer pinning을 구현합니다.
실전 팁
💡 AtomicUsize의 fetch_add/sub는 성능 비용이 있습니다. 하지만 정확성이 성능보다 중요하므로 반드시 사용하세요.
💡 Ordering::SeqCst 대신 Relaxed를 사용하면 더 빠르지만, 메모리 순서 보장이 약해집니다. 확신이 없으면 SeqCst를 사용하세요.
💡 BufferGuard를 함수 인자로 전달할 때는 참조(&)보다 clone()이 나을 수 있습니다. Arc는 clone이 저렴합니다.
💡 refcnt가 0이 되는 순간을 감지하여 자동으로 LRU 리스트에 추가하는 최적화가 가능합니다.
💡 디버그 빌드에서는 refcnt > 0인 버퍼를 제거하려 할 때 panic!()으로 즉시 발견하세요. 프로덕션에서는 에러 로그를 남기고 다음 버퍼로 넘어가세요.
9. Write-Through vs Write-Back - 쓰기 정책 비교
시작하며
여러분이 데이터를 쓸 때 즉시 디스크에 써야 할지, 나중에 모아서 써야 할지 고민해본 적 있나요? 즉시 쓰면 안전하지만 느리고, 나중에 쓰면 빠르지만 시스템 충돌 시 데이터가 손실될 수 있습니다.
이것은 성능과 안전성 사이의 근본적인 trade-off입니다. 이런 문제는 모든 캐싱 시스템의 핵심 설계 결정입니다.
데이터베이스, 파일 시스템, 웹 캐시 모두 동일한 고민을 합니다. 잘못 선택하면 성능이 형편없거나, 데이터 손실 위험이 크거나, 일관성이 깨질 수 있습니다.
특히 금융 시스템 같은 중요한 애플리케이션에서는 한 번의 데이터 손실이 치명적입니다. 바로 이럴 때 필요한 것이 쓰기 정책 선택입니다.
Write-through는 안전하고 간단하지만 느리고, Write-back은 빠르지만 복잡하고 위험합니다. 각각의 장단점을 이해하고 적절히 선택해야 합니다.
개요
간단히 말해서, Write-through는 매번 디스크에 즉시 쓰는 방식이고, Write-back은 버퍼에만 쓰고 나중에 플러시하는 방식입니다. 두 방식은 성능, 안전성, 복잡도에서 큰 차이를 보입니다.
실제 운영체제에서는 대부분 Write-back을 기본으로 사용하되, 중요한 메타데이터는 Write-through로 처리합니다. Linux는 기본적으로 Write-back이지만, O_SYNC 플래그로 파일별로 Write-through를 선택할 수 있습니다.
예를 들어, 일반 파일은 Write-back으로 빠르게 처리하고, 파일 시스템의 수퍼블록이나 inode 같은 중요한 메타데이터는 즉시 디스크에 써서 손상을 방지합니다. 기존에는 하나의 정책만 사용했다면, 현대 시스템은 데이터 종류에 따라 정책을 동적으로 선택합니다.
핵심 특징은 첫째, Write-through는 간단하고 안전하다는 점, 둘째, Write-back은 빠르고 배치 최적화가 가능하다는 점, 셋째, 하이브리드 접근이 최선의 균형을 제공한다는 점입니다. 이러한 특징들을 이해해야 올바른 설계가 가능합니다.
코드 예제
pub enum WritePolicy {
WriteThrough, // 즉시 디스크 쓰기
WriteBack, // 나중에 플러시
}
impl BufferCache {
pub write_policy: WritePolicy,
pub fn write_block_policy(&mut self, block_num: usize, data: &[u8], disk: &Disk)
-> Result<(), IoError> {
// 버퍼에 쓰기 (공통)
let buf_arc = self.get_or_create(block_num);
let mut buf = buf_arc.lock().unwrap();
buf.data.copy_from_slice(data);
buf.valid = true;
match self.write_policy {
WritePolicy::WriteThrough => {
// 즉시 디스크에 쓰기
disk.write(block_num, data)?;
buf.dirty = false; // 깨끗한 상태
}
WritePolicy::WriteBack => {
// dirty 표시만 하고 나중에 플러시
buf.dirty = true;
}
}
Ok(())
}
}
설명
이것이 하는 일: write_block_policy 함수는 설정된 쓰기 정책에 따라 디스크 쓰기 타이밍을 결정합니다. Write-through는 즉시 디스크에 쓰고, Write-back은 나중으로 연기하여 성능을 최적화합니다.
첫 번째로, 두 정책 모두 버퍼에 데이터를 씁니다. get_or_create()로 버퍼를 가져오거나 새로 만들고, copy_from_slice()로 data를 버퍼에 복사합니다.
이 부분은 공통이며, 캐싱의 이점을 위해 항상 버퍼를 업데이트합니다. valid = true로 설정하여 데이터가 유효함을 표시합니다.
그 다음으로, match self.write_policy로 정책을 분기합니다. WritePolicy::WriteThrough인 경우 disk.write()를 즉시 호출하여 디스크에 씁니다.
쓰기가 완료되면 dirty = false로 설정하는데, 이는 버퍼와 디스크가 일치함을 의미합니다. 이 방식은 느리지만(디스크 I/O는 밀리초 단위) 데이터가 즉시 영구 저장되므로 안전합니다.
시스템이 충돌해도 데이터는 디스크에 있습니다. 마지막으로, WritePolicy::WriteBack인 경우 disk.write()를 호출하지 않고 단순히 dirty = true로 표시만 합니다.
실제 디스크 쓰기는 나중에 eviction, sync, 주기적 플러시 시 수행됩니다. 이 방식은 매우 빠르지만(메모리 쓰기는 나노초 단위), 시스템 충돌 시 아직 플러시되지 않은 데이터는 손실됩니다.
하지만 여러 쓰기를 배치로 모아서 디스크에 쓸 수 있어 전체 처리량이 크게 향상됩니다. 여러분이 이 코드를 사용하면 워크로드 특성에 맞게 쓰기 정책을 선택할 수 있습니다.
실무에서는 파일별, 블록 타입별로 정책을 다르게 설정합니다. 예를 들어 데이터베이스 WAL은 Write-through, 일반 테이블 데이터는 Write-back, 메타데이터는 순서 보장이 필요하므로 저널링과 결합합니다.
또한 배터리 백업이 있는 서버에서는 Write-back을 안전하게 사용할 수 있습니다.
실전 팁
💡 중요한 메타데이터(수퍼블록, inode, 디렉토리)는 Write-through를 사용하세요. 손상되면 전체 파일 시스템이 망가집니다.
💡 Write-back 사용 시 주기적 플러시 스레드는 필수입니다. 30초 간격이 일반적이며, vm.dirty_writeback_centisecs로 조정 가능합니다.
💡 O_SYNC 플래그로 파일별 Write-through를 지원하면 애플리케이션이 중요도에 따라 선택할 수 있습니다.
💡 배터리 백업 RAID 컨트롤러는 자체 Write-back 캐시를 가지므로, 운영체제는 Write-through를 써도 실제로는 빠릅니다.
💡 벤치마크로 두 정책의 성능 차이를 측정하세요. 워크로드에 따라 2~50배 차이가 날 수 있습니다.
10. 통계 및 모니터링 - 캐시 성능 측정
시작하며
여러분이 버퍼 캐시를 열심히 구현했는데, 실제로 얼마나 효과적인지 알 수 없는 상황을 겪어본 적 있나요? 캐시 히트율이 얼마나 되는지, 어떤 블록이 자주 사용되는지, 디스크 I/O가 줄어들었는지 측정하지 않으면 최적화가 불가능합니다.
이런 문제는 모든 성능 최적화의 기본입니다. "측정할 수 없으면 개선할 수 없다"는 원칙처럼, 캐시 성능을 정량적으로 파악해야 문제점을 발견하고 개선할 수 있습니다.
막연히 "빨라진 것 같다"가 아니라 "히트율이 85%에서 92%로 향상되었다"처럼 구체적인 수치가 필요합니다. 바로 이럴 때 필요한 것이 통계 수집과 모니터링입니다.
히트/미스 카운트, 디스크 I/O 횟수, 플러시된 블록 수 등을 추적하여 캐시 효과를 가시화합니다.
개요
간단히 말해서, 통계 수집은 캐시 동작을 숫자로 추적하는 것입니다. 히트율, I/O 횟수, 평균 지연 시간 등을 측정하여 성능을 정량화합니다.
실제 운영체제에서는 통계가 필수입니다. Linux는 /proc/meminfo에 캐시 통계를, iostat 명령으로 I/O 통계를 제공합니다.
시스템 관리자는 이 데이터로 캐시 크기를 조정하거나, 디스크를 교체하거나, 애플리케이션을 최적화합니다. 예를 들어 캐시 히트율이 60%밖에 안 되면 메모리를 증설하거나, 히트율이 99%인데도 느리면 디스크가 병목임을 알 수 있습니다.
기존에는 감으로 성능을 판단했다면, 통계 수집으로 데이터 기반 의사결정이 가능해집니다. 핵심 특징은 첫째, 히트율이 캐시 효과의 핵심 지표라는 점, 둘째, 통계 수집 오버헤드가 매우 작아야 한다는 점, 셋째, 실시간 모니터링이 가능해야 한다는 점입니다.
이러한 특징들이 지속적인 성능 개선을 가능하게 합니다.
코드 예제
use std::sync::atomic::{AtomicU64, Ordering};
pub struct CacheStats {
// 캐시 히트 횟수
pub hits: AtomicU64,
// 캐시 미스 횟수
pub misses: AtomicU64,
// 디스크 읽기 횟수
pub disk_reads: AtomicU64,
// 디스크 쓰기 횟수
pub disk_writes: AtomicU64,
// 플러시된 블록 수
pub flushed_blocks: AtomicU64,
}
impl CacheStats {
pub fn new() -> Self {
Self {
hits: AtomicU64::new(0),
misses: AtomicU64::new(0),
disk_reads: AtomicU64::new(0),
disk_writes: AtomicU64::new(0),
flushed_blocks: AtomicU64::new(0),
}
}
// 캐시 히트율 계산 (0.0 ~ 1.0)
pub fn hit_rate(&self) -> f64 {
let hits = self.hits.load(Ordering::Relaxed) as f64;
let total = hits + self.misses.load(Ordering::Relaxed) as f64;
if total == 0.0 { 0.0 } else { hits / total }
}
}
설명
이것이 하는 일: CacheStats 구조체는 버퍼 캐시의 모든 주요 동작을 카운팅하여 성능을 정량화합니다. 히트율, I/O 횟수 등을 실시간으로 추적하여 캐시 효과를 가시화합니다.
첫 번째로, 각 통계 필드를 AtomicU64로 선언합니다. 일반 u64 대신 Atomic을 사용하는 이유는 여러 스레드가 동시에 카운터를 증가시킬 때 race condition을 방지하기 위해서입니다.
fetch_add(1, Ordering::Relaxed)로 원자적으로 증가시킬 수 있으며, Relaxed 순서는 성능 오버헤드가 가장 작습니다(순서 보장이 필요 없으므로). 그 다음으로, hits와 misses가 가장 중요한 지표입니다.
read_block()에서 캐시에 있으면 hits.fetch_add(1)을, 없으면 misses.fetch_add(1)을 호출합니다. 히트율 = hits / (hits + misses)로 계산되며, 80% 이상이면 양호, 90% 이상이면 우수, 95% 이상이면 매우 우수합니다.
히트율이 낮으면 캐시 크기를 늘리거나 교체 알고리즘을 개선해야 합니다. 마지막으로, disk_reads와 disk_writes가 실제 I/O 부하를 나타냅니다.
disk.read()와 disk.write() 호출마다 해당 카운터를 증가시킵니다. flushed_blocks는 sync()나 eviction으로 플러시된 블록 수를 추적합니다.
hit_rate() 메서드는 현재 히트율을 0.0~1.0 범위로 계산하여 반환합니다. total이 0이면 0.0을 반환하여 division by zero를 방지합니다.
여러분이 이 코드를 사용하면 캐시 성능을 정확히 파악하고 최적화할 수 있습니다. 실무에서는 여기에 평균 지연 시간(moving average), percentile(p50, p99), 시간대별 히트율 추이 등을 추가합니다.
Prometheus나 Grafana로 실시간 대시보드를 만들어 모니터링하는 것이 일반적입니다. 또한 통계를 /proc 파일로 노출하여 외부 도구가 읽을 수 있게 합니다.
실전 팁
💡 AtomicU64 대신 thread-local 카운터를 사용하면 더 빠릅니다. 주기적으로 글로벌 카운터에 병합하세요.
💡 히트율 외에도 평균 지연 시간을 측정하세요. 히트는 마이크로초, 미스는 밀리초 단위로 차이가 큽니다.
💡 블록별 히트 카운트를 추적하면 hot block을 식별할 수 있습니다. 이런 블록은 절대 교체하지 않도록 pin할 수 있습니다.
💡 통계 수집 오버헤드를 측정하세요. 보통 1% 미만이어야 하며, 그 이상이면 샘플링을 고려하세요.
💡 시스템 종료 시 통계를 파일로 저장하고, 시작 시 로드하여 장기 추이를 분석할 수 있습니다.