# WAL Buffers (Write-Ahead Logging Buffers)

## 1. 개요
**WAL Buffers**는 데이터베이스의 변경 사항을 디스크에 영구적으로 기록하기 전, 메모리 상에 임시로 저장하는 전용 버퍼 영역이다. 이는 **WAL(Write-Ahead Logging)**, 즉 데이터 페이지를 실제 데이터 파일에 쓰기 전에 변경 이력을 먼저 로그 파일에 기록하는 메커니즘의 핵심 구성 요소이다. **WAL Buffers**는 빈번한 디스크 I/O를 줄여 쓰기 성능을 최적화하는 동시에, 시스템 장애 발생 시 트랜잭션 로그를 통해 데이터를 복구함으로써 데이터 무결성을 보장하는 역할을 한다.

## 2. 동작 원리 및 메커니즘
데이터베이스에서 데이터 수정(`INSERT`, `UPDATE`, `DELETE`)이 발생하면, 변경 사항은 즉시 디스크로 가지 않고 다음과 같은 단계적 흐름을 거쳐 처리된다.

### 2.1 데이터 흐름도
`사용자 요청` $\rightarrow$ `WAL Buffers (로그 생성)` $\rightarrow$ `Shared Buffers (페이지 수정)` $\rightarrow$ `WAL Segment (디스크 플러시)`
*(참고: WAL의 핵심 원칙에 따라 데이터 페이지가 수정되기 전 또는 동시에 로그가 먼저 기록되어야 한다.)*

### 2.2 상세 프로세스
1. **변경 발생**: 트랜잭션이 데이터를 수정하면, 먼저 수정 내용에 대한 변경 이력인 **WAL Record**가 생성되어 **WAL Buffers**에 순차적으로 기록된다.
2. **페이지 수정**: 로그 기록 후, 메모리 내의 **Shared Buffers**(데이터 페이지를 캐싱하는 영역)에서 해당 페이지가 수정되어 **`Dirty Page`** 상태가 된다.
3. **플러시(Flush)**: 다음 조건 중 하나가 충족되면 **WAL Buffers**의 내용은 디스크의 **WAL Segment**(로그 파일)로 물리적으로 기록된다.
    - 트랜잭션이 `COMMIT` 될 때 (**지속성** 보장을 위해 필수적)
    - **WAL Buffers**가 가득 찼을 때
    - 특정 시간 간격(예: `wal_writer_delay`)이 경과했을 때
4. **체크포인트**: 이후 백그라운드 프로세스가 **Shared Buffers**의 **`Dirty Page`**를 실제 데이터 파일에 기록한다.

## 3. 주요 특징 및 역할
**WAL Buffers**는 데이터베이스의 **ACID** 특성 중 특히 원자성과 지속성을 구현하는 핵심 장치이다.

*   **공유 메모리(Shared Memory) 구조**: **WAL Buffers**는 모든 백엔드 프로세스가 접근할 수 있는 **공유 메모리** 영역이다. 여러 프로세스가 동시에 로그를 기록하려 하므로, 기록 순서를 보장하기 위한 락(Lock) 경합이 발생할 수 있다.
*   **원자성(Atomicity) 및 지속성(Durability) 보장**: 트랜잭션이 커밋되는 순간, 데이터 파일 자체가 수정되지 않았더라도 WAL 로그가 디스크에 기록되었다면 시스템 장애 후 재시작 시 로그를 재실행(**`Redo`**)하여 데이터를 완벽히 복구할 수 있다.
*   **I/O 효율성 증대**: 데이터 파일은 **`Random I/O`** 방식인 반면, WAL 로그는 **`Sequential I/O`** 방식이다. 변경 사항을 버퍼에 모았다가 한 번에 순차적으로 기록함으로써 디스크 헤더의 이동을 최소화하고 쓰기 처리량을 극대화한다.

## 4. 설정 및 최적화 (Tuning)
`wal_buffers` 설정은 시스템의 쓰기 부하량과 가용 메모리에 따라 조정해야 한다.

### 4.1 설정 가이드 및 성능 영향
| 설정 값 수준 | 성능 영향 | 권장 상황 | 비고 |
| :--- | :--- | :--- | :--- |
| **낮음 (Default)** | 빈번한 디스크 플러시 발생, 쓰기 지연 가능성 | 읽기 위주의 워크로드, 소규모 DB | PostgreSQL의 경우 `shared_buffers` 크기에 따라 자동 설정되나, 버전별로 최대 제한이 있을 수 있음 |
| **적정 (Tuned)** | I/O 효율 최적화, 트랜잭션 처리량 증가 | 일반적인 OLTP 환경, 중간 규모 DB | 보통 16MB ~ 64MB 사이에서 설정 |
| **과도함 (Excessive)** | 메모리 낭비, 성능 향상 폭 체감 감소 | 매우 높은 쓰기 부하, 대규모 서버 | 일정 수준 이상에서는 성능 향상이 미미함 |

### 4.2 설정 적용 예시
PostgreSQL의 `postgresql.conf` 파일에서 다음과 같이 설정할 수 있다.

```conf
# postgresql.conf 설정 예시

# 공유 버퍼 설정 (전체 메모리의 25% 권장)
shared_buffers = 4GB 

# WAL 버퍼 설정 (일반적으로 16MB ~ 64MB 설정)
# 너무 작으면 WALWriteLock 경합이 발생하고, 너무 크면 메모리 낭비가 발생함
wal_buffers = 64MB

# WAL 기록 관련 추가 설정
wal_level = replica
synchronous_commit = on
```

## 5. 체크포인트와의 상관관계
**WAL Buffers**와 체크포인트(Checkpoint)는 상호 보완적인 관계에 있다.

*   **체크포인트의 정의**: 메모리(**Shared Buffers**)의 **`Dirty Page`**를 디스크의 실제 데이터 파일로 물리적으로 동기화하는 작업이다.
*   **상관관계**: 
    - **WAL Buffers**에 기록된 로그가 많을수록, 체크포인트 사이의 간격이 길어질수록 장애 복구 시 읽어야 할 WAL 로그의 양이 많아져 복구 시간(Recovery Time)이 증가한다.
    - 복구 시에는 체크포인트 이후의 WAL 로그를 읽어 데이터 페이지에 다시 적용하는 **`Redo`** 과정을 통해 장애 직전의 상태로 데이터를 복원한다.
    - 체크포인트가 빈번하게 발생하면 디스크 I/O 부하가 급증하므로, `max_wal_size`와 `checkpoint_timeout`을 적절히 설정하여 **WAL Buffers**의 효율적인 플러시와 체크포인트 주기를 조율해야 한다.

## 6. 성능 병목 현상과 트러블슈팅
### 6.1 주요 병목 현상
**WAL Buffers**의 크기가 너무 작으면, 트랜잭션이 로그를 기록하려 할 때 버퍼 공간이 부족하여 **`WALWriteLock`** 대기 이벤트가 발생한다. 이는 모든 쓰기 트랜잭션이 디스크 플러시가 완료될 때까지 대기하게 만들어 전체적인 시스템 응답 속도를 저하시킨다.

### 6.2 해결 방법
1. **모니터링**: `pg_stat_activity` 뷰를 통해 대기 이벤트가 `WALWrite` 또는 `WALWriteLock`인지 확인한다.
   ```sql
   -- WAL 관련 대기 이벤트 모니터링 쿼리
   SELECT pid, wait_event_type, wait_event, state, query 
   FROM pg_stat_activity 
   WHERE wait_event_type = 'LWLock' 
     AND wait_event LIKE 'WALWrite%';
   ```
2. **설정 변경**: `wal_buffers` 값을 점진적으로 상향 조정한다.
3. **디스크 성능 개선**: WAL 로그가 저장되는 디스크를 고성능 NVMe SSD로 교체하거나, 데이터 파일 저장소와 물리적으로 분리하여 I/O 경합을 줄인다.

## 7. OS 커널 파라미터와의 연관성
**WAL Buffers**의 효율은 OS 레벨의 메모리 및 I/O 관리 설정에 영향을 받는다.

*   **Dirty Page Writeback**: OS 커널의 `vm.dirty_background_ratio` 및 `vm.dirty_ratio` 설정은 OS가 메모리의 **`Dirty Page`**를 디스크로 밀어내는 시점을 결정한다. 이 값이 너무 높으면 한꺼번에 많은 I/O가 발생하여 WAL 플러시 시점에 지연(Stall)이 발생할 수 있다.
*   **Disk Scheduler**: **`Sequential I/O`**가 중요한 WAL 특성상, OS의 I/O 스케줄러를 `deadline` 또는 `noop` (NVMe의 경우 `none`)으로 설정하여 불필요한 재정렬 오버헤드를 줄이는 것이 권장된다.

## 8. 요약 및 비교: Shared Buffers vs WAL Buffers
두 버퍼 모두 메모리 영역이지만, 목적과 관리 방식이 완전히 다르다.

| 구분 | Shared Buffers | WAL Buffers |
| :--- | :--- | :--- |
| **저장 내용** | 실제 데이터 페이지 (Table, Index) | 데이터 변경 이력 (Log Records) |
| **접근 방식** | **`Random Access`** | **`Sequential Access`** |
| **주 목적** | 데이터 읽기/쓰기 성능 향상 (캐싱) | 데이터 무결성 보장 및 쓰기 최적화 |
| **디스크 반영** | 체크포인트 시점에 반영 | 트랜잭션 커밋 시점에 즉시 반영 |
| **장애 시 역할** | 휘발됨 (데이터 손실 가능성) | 복구의 근거가 됨 (**`Redo`** 로그로 활용) |