Kudu tablet server 의 WAL 디렉터리 용량을 어떻게 잡을지, 그리고 WAL 디렉터리가 데이터 디렉터리와 비슷한 크기까지 불어나는 현상을 어떻게 읽을지 정리한다.
Kudu 는 WAL 디렉터리를 한 개만 가질 수 있다. 데이터 디렉터리(--fs_data_dirs)는 여러 개를 나열할 수 있지만 --fs_wal_dir 은 단일 경로이고, 여러 디스크로 나눠 담을 수 없다. 그래서 WAL 은 전용 디스크 한 장을 배정하고, 그 디스크의 fsync 지연이 낮아야 한다. Cloudera 하드웨어 요구사항 문서도 tablet server 항목에 "1 disk for write-ahead log (WAL)" 로 적고 SSD 권장을 붙인다.
용량보다 지연이 먼저다. WAL 쓰기는 쓰기 경로의 직렬 구간이라 이 디스크가 느리면 tablet server 전체 쓰기 처리량이 그만큼 눌린다.
공식 문서가 "몇 GB" 로 고정값을 주지는 않는다. 사용량이 데이터 총량보다 태블릿 수·쓰기량·flush 지연에 더 좌우되기 때문이다. 대략적인 하한은 다음처럼 계산한다.
WAL 최소 용량 ≈ 태블릿 수 × WAL 세그먼트 크기 × 보존 세그먼트 수 × 여유율
WAL 세그먼트 크기는 --log_segment_size_mb 로 기본 8MB 이고, 세그먼트는 미리 할당(preallocate)된다. tablet server 당 권장 태블릿 수인 1000개를 기준으로 하면 단순 계산으로 8GB 정도지만, 실제로는 flush 지연·follower 따라잡기·대량 적재 구간에서 보존 세그먼트가 늘어나므로 이 숫자에 맞춰 잡으면 위험하다. 운영에서는 전용 SSD/NVMe 200GB 이상을 잡고, 쓰기 부하가 크면 500GB 이상을 본다. (확인 필요 — 이 권장 용량 구간은 공식 문서 값이 아니라 운영 경험치다.)
관련 상한 플래그로 --log_max_segments_to_retain 과 --log_min_segments_to_retain 이 있으나, 이 값들은 정상 GC 가 도는 상황에서의 보존 개수이지 강제 삭제 수단이 아니다.
| 플래그 | 기본값 | 의미 |
|---|---|---|
--fs_wal_dir_reserved_bytes |
-1 | WAL 파일시스템에서 Kudu 가 쓰지 않고 남겨 둘 바이트. -1 은 해당 디스크 용량의 1% |
--fs_data_dirs_reserved_bytes |
-1 | 데이터 디렉터리에 대한 같은 설정 |
기본값이 0(예약 없음)이 아니라 -1(1% 예약) 이라는 점이 중요하다. 다른 프로세스와 디스크를 공유하는 배치라면 이 값을 명시적으로 올려 두는 편이 안전하다.
--fs_wal_dir_reserved_bytes=10737418240
WAL 세그먼트는 "더 이상 재생(replay)할 필요가 없어야" 지워진다. 어느 태블릿이 그 구간의 로그를 아직 필요로 하면 GC 대상이 되지 않는다. 필요로 하는 사유는 크게 둘이다.
첫째, MemRowSet 이 아직 디스크로 flush 되지 않았다. flush 가 밀리면 그 시점 이전 WAL 을 지울 수 없다. maintenance 스레드 부족, compaction 적체, I/O 포화가 모두 여기로 이어진다.
둘째, 팔로워 복제본이 따라오지 못했다. 리더는 뒤처진 팔로워가 복제해 갈 로그를 붙들고 있어야 하므로, 특정 태블릿의 복제가 지연되면 그 태블릿 WAL 이 계속 쌓인다.
태블릿 하나하나가 독립적인 WAL 을 가지므로, 같은 데이터양이라도 태블릿 수가 많으면 WAL 총량은 그만큼 커진다. 결과적으로 WAL 디렉터리가 데이터 디렉터리와 비슷한 크기가 되는 것 자체는 비정상이 아니다.
curl -s http://<tserver>:8050/maintenance-manager
curl -s http://<tserver>:8050/tablets
kudu cluster ksck <master-addresses>
du -sh /var/lib/kudu/tserver/wals
df -h
maintenance-manager 에서 flush·compaction 작업이 대기만 하고 실행되지 않는지, tablets 페이지에서 특정 태블릿의 로그 인덱스 범위가 넓게 벌어져 있지 않은지 본다. ksck 로 따라잡지 못한 복제본이 있는지 확인한다.
tablet server 로그에서 GC 가 막힌 사유를 직접 찾을 수도 있다.
grep -i "log gc\|anchor" /var/log/kudu/kudu-tserver.INFO | tail -50
--log_force_fsync_all 로만 조정한다. 인터넷에 도는 /api/v1/tablets/<id>/flush 같은 REST 엔드포인트나 --durability 플래그는 Kudu 에 존재하지 않는다.