18강 / 20강

DB가 느린 진짜 이유 — fsync 와 WAL

안전하게 저장한다는 것의 비용

이상한 현상이 있습니다. NVMe SSD는 초당 50만 번 쓸 수 있다는데, 쇼핑몰 DB는 초당 수백 건의 주문밖에 못 넣습니다. 1000배 차이가 어디로 갔을까요?

답은 fsync입니다.

고등학생안전하게 저장한다는 것의 비용

DB 가 느린 이유를 제대로 아는 관리자는 드뭅니다.

DB 는 느리게 설계된 것이다 — 안전을 위해

무엇을 보장하려는가

"저장했다" 고 답했으면 진짜 저장된 것이어야 합니다. 전원이 그 순간 나가도요.

보장 없으면	일어나는 일
주문 접수 후 정전	주문이 사라진다
결제 후 정전	돈은 받고 기록이 없다

쇼핑몰에서 절대 일어나면 안 되는 일

그런데 여기 함정이 있습니다

파일에 쓰기를 해도 디스크에 안 갑니다. 운영체제가 메모리에 모아 뒀다가 나중에 씁니다.

동작	어디까지
`write()`	메모리(캐시)까지 ⚠
`fsync()`	디스크까지 ✔

write 만 하면 전원이 나갈 때 사라진다

그리고 fsync 가 비쌉니다

동작	시간
write	수 마이크로초
fsync	수 밀리초 — 1000배

안전의 값이 1000배다

"저장했다"는 말의 세 가지 뜻

📝

앱 버퍼

프로그램 메모리
죽으면 사라짐

🗄️

커널 페이지 캐시

write() 가 끝난 상태
전원 나가면 사라짐

💾

진짜 디스크

fsync() 가 끝난 상태
전원이 나가도 남음

write()는 커널에 넘겼다는 뜻일 뿐 디스크에 닿았다는 뜻이 아닙니다. 전원이 나가면 사라져요. 그래서 DB는 커밋할 때마다 fsync()를 부릅니다 — "진짜로 디스크에 박힐 때까지 기다려"라고요.

고등학생WAL — 두 번 쓰는 게 더 빠른 이유

DB 의 가장 영리한 아이디어입니다. 언뜻 보면 말이 안 되죠 — 두 번 쓰는데 빠르다니.

본체를 고치기 전에 로그에 먼저 적는다

왜 두 번 쓰는데 빠른가

12강의 순차와 랜덤을 떠올리세요.

쓰기	방식	속도
WAL	순차 — 파일 끝에 붙인다	빠르다
본체	랜덤 — 여기저기	느리다

순차 쓰기 한 번이 랜덤 쓰기보다 훨씬 싸다

그래서 이렇게 합니다

변경 내용을 WAL 에 순차로 쓰고 fsync
손님에게 "저장됐습니다"
본체는 나중에 천천히 반영

응답은 빠른 쓰기만 기다린다

비유 — 주문서와 장부

식당에서 주문을 받으면 —

순서	일
1	주문서에 갈겨 쓴다 (빠름)
2	손님에게 "접수됐습니다"
3	한가할 때 장부에 정리

주문서만 있으면 나중에 장부를 복원할 수 있다

정전이 나도 WAL 이 있으면 다시 재생해서 본체를 맞출 수 있습니다.

기록만 안전하면 결과는 나중에 만들 수 있다

이 발상이 곳곳에 있습니다

어디	이름
파일 시스템	저널링
분산 시스템	이벤트 로그
Redis	AOF

fsync 한 번의 값이 36번의 그냥 쓰기와 맞먹습니다.

Python 브라우저에서 실행

# fsync 유무가 처리량을 어떻게 가르나
NVMe_쓰기_us  = 25      # 그냥 쓰기
NVMe_fsync_us = 900     # 진짜 디스크에 박힐 때까지 (플러시 + 확인)

주문당_fsync = 1        # 커밋 한 번 = fsync 한 번

print(f"{'방식':<28}{'주문 하나':>12}{'초당 주문':>14}")
print("-" * 56)

경우 = [
    ("fsync 안 함 (위험!)",       NVMe_쓰기_us),
    ("커밋마다 fsync",            NVMe_fsync_us * 주문당_fsync),
    ("그룹 커밋 (10건 묶어서)",    NVMe_fsync_us / 10 + NVMe_쓰기_us),
    ("HDD 에서 커밋마다 fsync",   10_000),
]
for 이름, us in 경우:
    print(f"{이름:<28}{us:>10.0f}µs{1_000_000/us:>12,.0f}건")

print()
print("→ '안전하게 저장'의 값이 36배입니다.")
print("  그리고 여러 주문을 묶어서 한 번에 fsync 하면 대부분을 되찾을 수 있어요.")

WAL — 두 번 쓰는데 왜 더 빠른가

DB는 데이터를 고칠 때 먼저 로그에 적고 나서 진짜 데이터를 고칩니다. 이걸 WAL(Write-Ahead Log) 이라고 해요. 두 번 쓰는 셈인데 왜 더 빠를까요?

📜

WAL 쓰기

순차 쓰기
파일 끝에 이어 붙이기만

🎲

데이터 파일 쓰기

랜덤 쓰기
여기저기 흩어진 페이지

커밋 시점에는 순차 로그만 fsync 하면 됩니다. 랜덤 쓰기는 나중에 한가할 때 모아서 하고요. 12강에서 봤듯이 순차와 랜덤은 속도가 하늘과 땅 차이라, 두 번 쓰는 게 더 빠릅니다.

게다가 전원이 나가도 로그를 다시 읽어 복구할 수 있어요. 빠르고 안전한, 드문 조합입니다.

고등학생SQLite 에서 이걸 켜는 법

note 가 직접 해 볼 수 있는 설정을 보여 줍니다.

SQLite 는 기본이 가장 안전하고 가장 느린 설정

두 가지 설정

설정	기본	바꾸면
`journal_mode`	DELETE	WAL
`synchronous`	FULL	NORMAL

이 둘만 바꿔도 쓰기가 수십 배 빨라진다

무엇을 내주나

설정	정전 시
FULL	아무것도 안 잃는다
NORMAL + WAL	DB 는 안 깨지지만 최근 몇 건을 잃을 수 있다
OFF	DB 가 깨질 수 있다 ⚠

NORMAL 까지가 실무의 합리적 선 — OFF 는 안 된다

왜 NORMAL 이 안전한가

WAL 모드에서 NORMAL 은 —

WAL 은 순서대로 쓰인다
깨진 부분은 버리면 된다
DB 본체는 손상되지 않는다

"몇 건 잃음" 과 "DB 파괴" 는 완전히 다른 위험

비유 — 자동 저장

방식	정전 시
타이핑마다 저장	안 잃는다 · 느리다
1분마다 저장	최대 1분 잃는다 · 빠르다
수동 저장만	다 잃는다

"얼마를 잃어도 되나" 를 먼저 정하고 설정을 고른다

주문 DB 는 FULL, 로그 DB 는 NORMAL — 이렇게 나누는 것이 실무의 답입니다.

디스크 병목을 진단하는 순서

wa 가 20% 넘으면 디스크를 의심합니다.

bash 브라우저에서 실행

# ① wa 가 높은가?
top | head -6

%util 만 보지 말고 await 를 함께 봅니다.

bash 브라우저에서 실행

# ② 어느 디스크가 바쁜가 — await 와 aqu-sz 를 보세요
iostat -x

순차는 빠른데 랜덤이 느리면 DB가 고생합니다.

bash 브라우저에서 실행

# ③ 실제 성능을 재 본다 — 순차와 랜덤 둘 다
dd if=/dev/zero of=/tmp/seq bs=1M count=512
echo "=== 랜덤 4K ==="
sysbench fileio --file-test-mode=rndrw run

대응 방법

증상	대응
커밋이 많아 fsync가 병목	여러 건을 한 트랜잭션으로 묶는다 (그룹 커밋)
같은 데이터를 반복 조회	인덱스 · 앱 캐시 · Redis
로그 쓰기가 디스크를 잡아먹음	로그를 다른 디스크로, 또는 비동기 기록
백업이 낮에 돌아 서비스를 방해	새벽으로, `ionice`로 우선순위 낮추기
HDD에서 DB를 돌리는 중	SSD로 옮긴다. 가장 확실하고 가장 극적인 개선
디스크가 90% 이상 참	정리한다. SSD는 꽉 차면 쓰기가 급격히 느려진다 (12강)

루프 안에서 매번 commit() 하는 코드는 이 함정에 빠져 있습니다.

Python 브라우저에서 실행

# 그룹 커밋의 효과 — 주문 100건을 넣을 때
fsync_us = 900
쓰기_us  = 25
건수 = 100

낱개 = 건수 * (쓰기_us + fsync_us)
묶음 = 건수 * 쓰기_us + fsync_us

print(f"한 건씩 커밋 : {낱개/1000:>8.1f} ms   (fsync {건수}번)")
print(f"한꺼번에 커밋: {묶음/1000:>8.1f} ms   (fsync 1번)")
print(f"→ {낱개/묶음:.1f}배 빠름")
print()
print("주의: 묶으면 실패했을 때 전부 되돌아갑니다.")
print("     장바구니 담기처럼 개별성이 중요한 건 묶으면 안 돼요.")
print("     반면 로그 적재·일괄 업로드는 묶는 게 정답입니다.")

고등학생관리자가 가장 자주 만나는 코드 문제

note 의 마지막 경고 — 커밋을 어디에 두느냐입니다.

반복문 안에서 커밋하면 fsync 를 n 번 한다

숫자로 보면 끔찍합니다

방식	fsync	1만 건 처리
건마다 커밋	1만 번	50초
한 번에 커밋	1번	0.1초

500배 — 코드는 거의 같은데

비유 — 편지 부치기

방식	우체국 왕복
한 통 쓰고 바로 부치기	100번
100통 쓰고 한 번에	1번

쓰는 시간은 같고 왕복이 다르다

그런데 무작정 묶으면 안 됩니다

묶는 크기	장점	위험
1건	안전	느리다
100~1000건	균형 ✔	—
100만 건	가장 빠름	실패 시 전부 날아간다 · 락이 길다

묶음이 크면 실패의 대가도 커진다

그리고 락 문제

트랜잭션이 길면 다른 요청이 기다립니다. 11강의 암달의 법칙이 여기서 나와요.

긴 트랜잭션이 순차 구간을 늘린다 → 병렬화가 안 먹는다

실전 규칙

상황	묶는 크기
대량 적재 (배치)	1,000~10,000
사용자 요청 처리	요청 하나 = 트랜잭션 하나

배치는 묶고, 온라인은 짧게

🤔 확인 문제

NVMe SSD가 초당 50만 IOPS인데 DB가 초당 1,000건의 주문밖에 처리하지 못합니다. 가장 큰 이유는?

🤔 확인 문제

DB가 데이터를 고칠 때 WAL(로그)에 먼저 쓰고 나중에 데이터 파일을 고치는데, 두 번 쓰는데도 더 빠른 이유는?