로그 한 줄에 디스크 쓰기 49KB? systemd-journald 쓰기 증폭 논란

리눅스 서버 운영자라면 로그가 디스크에 어떻게 쌓이는지 평소에 크게 신경 쓰지 않는다. 그런데 systemd-journald가 로그 한 줄을 기록할 때 실제 데이터 크기와 비교해 훨씬 많은 디스크 쓰기를 유발한다는 문제 제기가 다시 불거졌다. Debian 13, 커널 6.12.57, systemd 257.9 환경에서 보고된 이 이슈는 로그 한 줄을 남기는 데 ext4에서 49KB 이상, btrfs에서는 110KB 이상의 디스크 쓰기가 발생한다고 지적한다. 초당 두 줄 정도의 로그를 남기는 가상머신에서 디스크가 약 50 IOPS를 소화하고 있었다는 관찰도 함께 제시됐다.

무엇이 문제로 지목됐나

보고자는 journald를 디스크에 로그를 기록하는 모드로 설정하고, 가상머신에서 일정한 로그 스트림을 계속 흘려보내는 방식으로 상황을 재현했다. 재현 과정의 파일시스템은 XFS였고, 여기에 ext4와 btrfs에서 측정한 쓰기량 수치가 덧붙여졌다. 핵심 주장은 간단하다. 실제로 기록되는 텍스트의 양에 비해 디스크에 실제로 쓰이는 바이트가 수십 배에 이르며, 이는 전통적인 syslog가 같은 로그를 남길 때의 쓰기량과 자릿수 자체가 다르다는 것이다. 다시 말해 기대 동작은 '로그 쓰기가 syslog와 비슷한 규모여야 한다'는 것인데, journald는 그 기준에서 크게 벗어난다는 지적이다.

이 문제는 새로운 것이 아니다. 보고자는 과거의 이슈 #15292와 사실상 동일한 사안이라고 못 박는다. 당시에는 'iotop 측정이 정확하지 않다'는 취지로 논의가 마무리됐는데, 보고자는 그 반박을 미리 차단한다. iotop이 커널의 쓰기 병합(write coalescing) 이전 값을 보여줄 수 있다는 점은 인정하면서도, 이번에는 커널의 여러 병합 메커니즘을 모두 거친 이후에도 트래픽이 관찰됐기 때문에 '커널이 IOPS를 부풀린 것'이 아니라 journald 자체가 느리고 비효율적이라는 주장이다.

왜 이런 증폭이 생기나

이런 쓰기 증폭의 배경에는 journald가 사용하는 바이너리 저널 포맷이 있다. 저널 파일은 단순한 평문 로그가 아니라 각 항목을 구조화된 필드로 저장하고, 필드 값의 중복을 줄이기 위한 해시 테이블과 인덱스, 그리고 항목 간 연결을 위한 자료구조를 함께 유지한다. 검색과 필터링, 부팅 단위별 조회 같은 기능을 빠르게 제공하기 위한 설계지만, 그 대가로 항목 하나를 추가할 때마다 인덱스와 메타데이터 영역이 함께 갱신된다. 보고자가 '파일 크기가 실제로 담긴 내용보다 몇 배 크다'고 표현한 부분이 바로 이 오버헤드를 가리킨다. 파일시스템 계층에서는 여기에 블록 단위 정렬, 저널링, btrfs 같은 CoW(Copy-on-Write) 파일시스템의 특성이 더해지면서 실제 물리 쓰기량이 한층 커진다. btrfs 수치가 ext4의 두 배 이상으로 나온 것도 이런 파일시스템별 동작 차이로 설명할 수 있다.

보고자는 성능뿐 아니라 안정성에도 의문을 제기한다. 비정상 종료 후 저널이 손상되는 경우를 여러 차례 겪었다며, 복원력이 뛰어난 포맷이라고 보기 어렵다고 주장한다. 구조화된 인덱스를 유지하는 포맷일수록 쓰기 도중 전원이 끊기면 정합성이 깨질 여지가 있다는 점에서, 이 지적은 포맷 설계의 트레이드오프와 맞닿아 있다.

실무자가 새겨둘 점

실무 관점에서 이 사안은 특히 IOPS가 제한된 클라우드 인스턴스, 쓰기 수명이 걸린 SSD, 로그가 폭증하는 컨테이너 호스트에서 무시하기 어렵다. 초당 몇 줄의 로그가 수십 IOPS를 잡아먹는다면, 로그가 많은 워크로드에서는 디스크 대역폭과 저장장치 마모가 예상보다 빠르게 누적될 수 있다. 완화책은 이미 존재한다. journald를 휘발성 모드(Storage=volatile)로 두어 tmpfs에 기록하게 하거나, 영구 저장이 필요하면 SystemMaxUse·RuntimeMaxUse와 회전 주기를 조정하고, 동기화 강도를 낮추는 설정으로 물리 쓰기 빈도를 줄일 수 있다. 로그를 원격 수집기로 바로 넘겨 로컬 디스크 기록을 최소화하는 구성도 흔히 쓰인다.

다만 이 보고는 어디까지나 한 사용자의 문제 제기이며, 측정 방법과 조건이 완전히 표준화되지 않았다는 한계를 함께 봐야 한다. 재현 환경의 파일시스템과 수치를 낸 파일시스템이 서로 다르고, 커널 병합 이후를 측정했다는 주장에 대한 systemd 개발진의 검증된 반박이나 확인은 이 자료만으로는 판단하기 어렵다. 과거 동일 이슈가 측정 정확성 문제로 종결됐던 전례가 있는 만큼, 결론을 내리기 전에 자신의 환경에서 iostat 등으로 물리 쓰기량을 직접 측정해 보는 편이 안전하다. 로그가 성능 병목이 될 만한 시스템을 운영한다면, 이 논쟁의 결론을 기다리기보다 저장 정책부터 점검해 두는 것이 현실적인 대응이다.