Disk I/O 바운드 서버를 위한 페이지 캐시(Page Cache)

"웹 개발자를 위한 대규모 서비스를 지탱하는 기술"의 내용을 재구성했습니다.

 

페이지 캐시란?

OS는 디스크 액세스를 줄이기 위해 메모리를 활용합니다.

프로세스 A가 데이터를 읽고 난 후, 더 이상 그 데이터가 필요 없어졌다고 해서 OS는 메모리에서 바로 해제하지 않습니다.

메모리에 데이터를 그대로 남겨두는데, 이것이 바로 페이지 캐시입니다.

 

이 덕분에 프로세스 B가 데이터를 필요할 때 디스크를 다시 읽지 않고 메모리에서 바로 가져올 수 있게 됩니다.

 

* OS의 파일 시스템마다 디스크 읽는 방법이 다를텐데?

리눅스에는 ext3, ext2 같은 여러 파일 시스템이 있고 각각 디스크를 읽는 방법이 다르지만, VFS(Virtual File System)가 어떤 파일 시스템을 사용하든 페이지 캐시를 동일하게 제공해준다고 합니다.

 

페이지 캐시 특징

페이지 캐시의 가장 큰 특징은 두 번째 이후의 데이터 접근부터 빨라진다는 점입니다. OS를 계속 가동시켜두면 캐싱된 페이지는 메모리가 허락하는 한 디스크의 데이터를 메모리에 계속해서 캐싱합니다.

 

페이지 캐시는 LRU(Least Recently Used) 구조로 동작합니다. 최근에 읽은 부분이 캐시에 남고 과거에 읽은 부분이 메모리에서 내려갑니다. 따라서 DB를 계속 구동시키면 캐시가 점점 최적화되어 가므로, 기동 직후보다 시간이 지날수록 부하와 I/O가 줄어들게 됩니다.

 

Linux는 메모리가 비어있으면 적극적으로 페이지를 캐싱한다는 것입니다. 가능한 한 남아있는 메모리를 페이지 캐시로 활용하려고 합니다. 그러다가 프로세스가 메모리가 필요할 때, 오래된 캐시를 버리고 프로세스의 메모리를 확보해줍니다.

 

페이지 캐시 사용량 확인하기

실제로 페이지 캐시 사용량을 확인하려면 리눅스의 sar 명령어를 사용할 수 있습니다.

* sar(System Activity Reporter) 명령어는 CPU, 메모리, 디스크 I/O, 네트워크 등 시스템 자원 사용 정보를 수집하고 리포팅하는 모니터링 도구(from GPT) 이다.

 

"sar -r 1 10000" 는 1초마다 메모리 사용 현황을 10000번 반복해서 출력하는 명령어 입니다.

sar -r 1 10000 (1초마다 시스템 사용 현황을 10000번 반복해서 출력)

 

여기서 kbcached 값이 페이지 캐시되고 있는 양인데, 단위는 KB입니다. 사진에서는 393Gi 만큼의 메모리가 페이지 캐시로 사용되고 있습니다. 이는 "캐시에 393Gi나 사용하고 있다"는 의미가 아닙니다. 메모리가 비어있는 곳에 OS가 조금씩 디스크를 캐싱하고 있는 것일 뿐입니다.

 

더 간단하게는 free -h 명령어로 확인할 수 있습니다.

free -h

 

메모리 503Gi 중 캐시로 399Gi를 사용하는 것을 한눈에 볼 수 있습니다.

이렇게 메모리를 늘리면 캐시에 사용할 수 있는 용량이 늘어나고, 캐시에 사용하는 용량이 많아질수록 많은 데이터를 캐싱하여 디스크를 읽는 횟수(I/O 횟수)를 줄일 수 있습니다.

 

서버 특징에 따라 필요한 자원의 차이

따라서, 페이지 캐시를 이해하면 Application 서버와 DB 서버를 확장할 때 필요한 자원이 다르다는 것을 알 수 있습니다.

• Application 서버 확장: CPU 부하 분산이 목적
• DB 서버 확장: I/O 성능 향상을 위해 메모리 스케일 업이 우선

리눅스 서버의 메모리를 늘리면 디스크의 내용이 모두 메모리에 캐시되어 실제 디스크 I/O 부하를 낮출 수 있습니다.

많은 데이터양을 페이지 캐시로 메모리를 통해 캐싱하지 못할 때, 더 이상 메모리를 스케일 업 하지 못할 때 비로소 DB를 확장하는 전략을 고려할 수 있습니다.

 

즉, 디스크 I/O 바운드한 DB서버에서는 처리할 데이터양에 비례해 메모리를 증설하는 것이 I/O 부하를 줄이는 데에 효과적인 전략이 될 수 있습니다.

 

DB 샤딩과 페이지 캐시의 관계

메모리를 더 이상 증설하지 못해서 DB 서버를 확장할 때는 샤딩 키 선택이 매우 중요합니다. 데이터를 분할해 각각의 DB 서버에 위치시키면 각 메모리에 올라가는 데이터가 겹치지 않기 때문에 I/O 부하를 줄이는 데에 더욱 효과적입니다.

 

여기서 핵심은 데이터가 정말 고루 분산되도록 샤딩 키를 설계하는 것입니다. 만약 데이터가 한쪽으로 쏠리면 특정 DB 서버의 페이지 캐시만 과부하가 걸리고, 다른 서버의 메모리는 충분히 활용되지 못하는 상황이 발생합니다. 반대로 균등하게 분산된다면 더 많은 데이터가 각 DB 서버의 메모리에 페이지 캐시되어 디스크 I/O를 효과적으로 줄일 수 있습니다.

 

DB 서버 재부팅 시 주의사항

대규모 데이터를 다루는 DB 서버를 부팅할 때는 조심해야 합니다. 메모리에 캐싱되어 있던 페이지 캐시는 모두 초기화되고, 모든 DB 액세스 요청은 디스크 I/O를 발생시켜 DB 서버가 다운될 수 있습니다.

 

그래서, DB 서버를 부팅한 후에는 자주 사용하는 DB 파일을 cat 명령어로 한 번 조회하는 것입니다.

cat /var/lib/mysql/frequently_used_table.ibd > /dev/null

 

이렇게 하면 디스크에서 메모리로 데이터를 미리 올려놓을 수 있습니다. 이를 "캐시 워밍(Cache Warming)"이라고도 부릅니다.

 

당연히 I/O 관련 부하 테스트를 할 때에도 페이지 캐시가 쓰인다는 것을 고려해야 합니다. 첫 번째 테스트와 두 번째 테스트의 결과가 다르다면, 그것은 코드의 문제가 아니라 페이지 캐시가 동작하고 있기 때문일 수 있습니다.

 

 

마치며

특히 페이징 캐시는 디스크 I/O 기반인 Elasticsearch 에서도 자주 쓰이기 때문에, Elasticsearch에서도 페이징 캐시를 위한 메모리를 남겨두기 위해 JVM Heap 메모리를 전체 시스템 메모리의 절반 이하로 설정할 것을 권장하기도 합니다.

 

트래픽이 몰림에 따라 언제 scale out 을 하고, scale up 을 하는지 기준이 모호했었는데, 페이징 캐시가 언제 유용한지 어느 상황에 적용할 수 있는지 알게 되었습니다.