DB 서버 성능의 핵심, 쿼리 튜닝보다 중요한 fsync와 PLP

솔직히 말해봅시다. 여러분의 서비스 DB가 느려졌을 때 가장 먼저 하는 일이 뭡니까? 십중팔구는 슬로우 쿼리(Slow Query) 로그를 뒤지거나 인덱스를 태웠는지 확인할 겁니다. 물론 중요합니다. 하지만 쿼리 튜닝을 아무리 해도 응답 속도가 나아지지 않고, CPU 사용률은 낮은데 I/O Wait만 치솟는다면?

그때는 여러분의 코드가 아니라 하드웨어, 특히 SSD가 범인일 확률이 90% 이상입니다.

LG CNS 시절 공공 프로젝트부터 지금의 SaaS 스타트업까지, 수많은 주니어들이 "SSD는 그냥 빠른 하드디스크 아닙니까?"라며 안일하게 접근하는 걸 봐왔습니다. 그 안일함이 트랜잭션 병목을 만들고, 결국 고객 이탈과 매출 하락으로 이어집니다. 오늘은 개발자가 낭만적인 코드 최적화 대신, 차가운 하드웨어 스펙인 fsync 지연(Latency)과 전원 손실 보호(PLP)를 왜 챙겨야 하는지, 그게 어떻게 우리 회사의 생존과 직결되는지 이야기해 보겠습니다.

1. 환상: "게이밍 SSD 썼으니까 빠르겠죠?"

현실: DB 서버에서는 최악의 선택일 수 있습니다.

많은 초기 스타트업이나 비용 절감에 목메는 팀들이 저지르는 실수가 있습니다. 바로 Samsung 990 Pro나 Crucial T500 같은 고성능 소비자용(Consumer) SSD를 서버에 꽂는 것입니다. 스펙표에 적힌 '최대 읽기/쓰기 속도'만 보면 훌륭해 보이니까요.

하지만 데이터베이스, 특히 MySQL(InnoDB)의 작동 방식은 게임 로딩과는 완전히 다릅니다.

InnoDB의 습관: 데이터 무결성을 위해 O_DIRECT 모드에서 끊임없이 fsync() 시스템 호출을 보냅니다. 쉽게 말해 "지금 메모리에 있는 데이터, 당장 디스크에 확실히 기록해!"라고 명령하는 겁니다.
소비자용 SSD의 한계: 쓰기 속도를 높이기 위해 RAM 버퍼를 쓰는데, 전원이 나가면 이 데이터가 날아갑니다. 그래서 fsync 명령이 떨어지면 버퍼를 비우고 낸드 플래시에 기록하느라 멈칫합니다.

이 '멈칫'하는 시간이 쌓이면 초당 수천 건의 트랜잭션을 처리해야 하는 DB는 그대로 멈춰 섭니다.

2. 증거: 숫자는 거짓말을 하지 않는다

PLP(Power Loss Protection)의 유무가 만드는 압도적 격차

최근 흥미로운 벤치마크 결과를 하나 봤습니다. 소비자용 SSD와 기업용(Enterprise) SSD의 fsync 지연 시간을 비교한 데이터입니다. 결과는 충격적일 정도로 명확합니다.

테스트 환경별 fsync 지연 시간 (단위: 마이크로초)
소비자용 (Samsung 990 Pro): 2,974.2 μs (약 3ms)
기업용 (Samsung PM-9a3): 1.6 μs (약 0.0016ms)

보이십니까? 약 1,800배 차이입니다.

기업용 SSD에는 PLP(전원 손실 보호) 기능이 있습니다. 내부에 커패시터(일종의 배터리)가 있어서 전원이 끊겨도 버퍼의 데이터를 안전하게 기록할 수 있습니다. 덕분에 fsync 호출이 와도 "안전하니까 걱정 마"라고 즉답하며 지연 없이 다음 작업을 처리합니다.

반면 소비자용 SSD는 그 안전장치가 없으니, 매번 물리적으로 기록하느라 3ms씩 시간을 잡아먹습니다. 1번이면 찰나지만, 1초에 1,000번 호출되면 시스템은 3초 동안 멍때리게 됩니다. 이게 바로 서비스 장애의 원인입니다.

3. 생존 매뉴얼: 당장 무엇을 해야 하는가?

여러분이 인프라 담당자거나 백엔드 개발자라면, 내일 출근해서 당장 다음 세 가지를 확인하십시오.

Step 1. 우리 DB 서버의 SSD 모델명 확인하기
클라우드를 쓴다면 인스턴스 타입이 '로컬 NVMe'인지, 네트워크 스토리지인지 확인하세요. 온프레미스라면 lsblk나 smartctl로 모델명을 찍어보세요.

소비자용(990 Pro 등)이다? -> 잠재적 시한폭탄입니다.
기업용(PM9a3, Intel D7 등)이다? -> 안심하셔도 좋습니다.

Step 2. InnoDB 설정 체크 (innodb_flush_method)
돈이 없어서 당장 하드웨어를 못 바꾼다면, 소프트웨어적으로 타협해야 합니다.
MySQL 설정에서 innodb_flush_method를 확인하십시오.

O_DIRECT: 가장 안전하지만, 소비자용 SSD에서는 쥐약입니다.
O_DIRECT_NO_FSYNC: fsync 호출 빈도를 줄여 성능을 비약적으로 높일 수 있습니다. (벤치마크상 호출 비율이 0.01046 -> 0.00172로 급감)

주의: O_DIRECT_NO_FSYNC는 과거에 파일시스템 호환성 문제가 있었으나, 최신 커널과 MySQL에서는 안정화되었습니다. 하지만 여전히 OS 크래시 시 데이터 손실 위험은 미세하게 존재합니다. 이 리스크를 감수하고 속도를 얻을지(스타트업의 생존), 비용을 들여 장비를 바꿀지(엔터프라이즈의 안정)는 비즈니스 결정의 영역입니다.

Step 3. 벤치마크 툴 fio로 직접 검증하기
남의 말만 믿지 마십시오. 직접 fio를 돌려보세요.

O_DIRECT + 쓰기당 fsync 옵션으로 테스트했을 때 지연 시간이 튀는지 확인하십시오.
Google Cloud의 Hyperdisk 같은 네트워크 스토리지조차 fsync 지연이 꽤 높게(700μs 이상) 나올 수 있습니다. 로컬 SSD가 무조건 답이 아닐 수도 있다는 뜻입니다.