Read Amplification이란?
Read Amplification(읽기 증폭)은 애플리케이션이 실제로 요청한 데이터양보다 훨씬 더 많은 양의 데이터를 디스크나 스토리지에서 읽어야 하는 현상을 말합니다. 예를 들어 단 1KB짜리 레코드 하나를 조회하기 위해 시스템이 내부적으로 10MB를 읽어야 한다면, Read Amplification이 매우 크다고 할 수 있습니다. 이는 CPU 연산이 아니라 I/O 비용에서 발생하는 문제이기 때문에, 겉으로 드러나지 않지만 실제 서비스의 응답 속도를 크게 갉아먹는 숨은 비용이 됩니다.
도서관에서 책 한 권을 찾는 상황을 떠올리면 이해하기 쉽습니다. 책이 어디 있는지 정확히 아는 사서라면 서가 하나만 확인하면 되지만, 정리가 안 된 도서관이라면 여러 서가를 다 뒤져야 원하는 책을 찾을 수 있습니다. 이때 ‘뒤져야 하는 서가의 수’가 바로 Read Amplification에 해당합니다.
왜 발생하는가: LSM-Tree 예시
Read Amplification은 특히 LSM-Tree(Log-Structured Merge Tree) 구조를 쓰는 RocksDB, Cassandra, LevelDB 같은 스토리지 엔진에서 두드러집니다. 이 구조는 쓰기 성능을 높이기 위해 데이터를 여러 레벨(SSTable)에 나눠 순차적으로 저장하는데, 하나의 키를 조회할 때 최신 레벨부터 오래된 레벨까지 여러 파일을 순서대로 확인해야 할 수 있습니다.
- 레벨 0에 최근 쓰인 데이터가 여러 개 흩어져 있는 경우
- 원하는 키가 어느 레벨에 있는지 몰라 다수의 파일을 확인해야 하는 경우
- 압축(compaction)이 늦어져 파일 수가 쌓인 경우
이럴 때 하나의 GET 요청이 내부적으로 여러 개의 SSTable 파일을 열어보는 다중 I/O로 이어지고, 결과적으로 읽기 지연시간이 급격히 늘어납니다.
실무에서 왜 중요한가
Read Amplification은 Write Amplification, Space Amplification과 함께 스토리지 엔진 설계의 3대 트레이드오프 중 하나로 불립니다. 쓰기 성능을 높이면 읽기 성능이 희생되고, 반대로 읽기를 최적화하면 쓰기나 공간 효율이 떨어지는 식입니다. 그래서 RocksDB는 Bloom Filter를 활용해 불필요한 파일 조회를 건너뛰거나, Compaction 전략(Leveled vs Tiered)을 조정해 Read Amplification을 줄이는 방법을 제공합니다.
실무에서는 서비스의 읽기/쓰기 비율을 파악한 뒤, 이에 맞는 스토리지 엔진과 compaction 전략을 선택하는 것이 중요합니다. 단순히 ‘쓰기가 빠르다’는 이유만으로 LSM 기반 DB를 도입하면, 읽기 부하가 많은 서비스에서는 오히려 응답 속도 저하라는 역효과를 볼 수 있습니다. 결국 Read Amplification을 이해하는 것은 데이터베이스 선택과 튜닝에서 성능 병목을 미리 예측하고 방지하는 핵심 지식이라 할 수 있습니다.