리눅스 커널이 스왑(swap)을 다시 설계하고 있다 - swap_ops와 플래시 시대의 스왑

스왑이 다시 화두가 된 이유

스왑(swap)이라는 단어, 들어보셨죠? 메모리가 부족할 때 디스크의 일부를 임시 메모리처럼 쓰는 기능이에요. 옛날 HDD 시절에는 "스왑이 일어나면 컴퓨터가 엄청 느려진다"는 인식이 강했어요. 그래서 많은 서버 운영자들이 스왑을 아예 꺼버리기도 했죠.

그런데 시대가 바뀌었어요. SSD, NVMe, 그리고 최근에는 CXL 메모리 같은 다양한 저장장치가 등장하면서, 스왑의 역할도 달라지고 있어요. 리눅스 커널 메일링 리스트에서 최근 swap tables, flash-friendly swap, swap_ops 같은 굵직한 제안들이 동시에 논의되고 있는데, LWN에서 이 흐름을 정리한 기사를 냈어요. 한 번에 변하는 게 아니라 여러 갈래로 스왑 서브시스템 전체가 재설계되는 중이에요.

기존 스왑 구조의 한계

현재 리눅스의 스왑은 디스크가 회전판이던 시절에 설계됐어요. 그래서 가정이 좀 오래됐어요. 예를 들어 순차 접근이 랜덤 접근보다 빠르다는 가정이 있는데, SSD에서는 그 차이가 거의 없거든요. 또 스왑 공간을 관리하는 자료구조도 메모리에 큰 배열을 그대로 들고 있는 식이라, 시스템 메모리가 커질수록 부담이 커져요.

이번에 제안된 swap tables는 이걸 해결하기 위한 새 자료구조예요. 페이지 테이블처럼 트리 구조로 스왑 정보를 관리해서, 필요한 부분만 메모리에 올리고 나머지는 효율적으로 다루는 거예요. 메모리 사용량도 줄고, 락 경합도 줄어들 수 있어요.

flash-friendly swap이 뭐냐면

SSD나 NVMe 같은 플래시 저장장치는 HDD와 동작 방식이 완전히 달라요. 블록 단위로 지워야 쓰기가 가능하고, 같은 셀에 너무 자주 쓰면 수명이 닳아요(write amplification). 그래서 "플래시에 친화적인 쓰기 패턴"이 따로 있어요.

기존 스왑은 페이지 하나씩 무작위로 쓰고 지우는 일이 많아서, 플래시 입장에서는 비효율적인 패턴이었어요. flash-friendly swap 패치는 스왑 쓰기를 더 큰 단위로 묶고, 가급적 순차적으로 배치해서 SSD의 가비지 컬렉션 부담을 줄이는 방향이에요. F2FS 파일시스템이 플래시에 맞춰 설계됐던 것과 비슷한 철학이라고 보시면 돼요.

swap_ops로 추상화하기

또 하나 흥미로운 제안이 swap_ops예요. 지금까지 스왑은 "디스크의 특정 영역에 페이지를 쓴다"는 식으로 코드가 박혀 있었어요. 그런데 요즘은 스왑 대상이 다양해졌어요. zswap(메모리 안에서 압축해서 보관), zram(램디스크에 압축 저장), 그리고 미래에는 CXL 메모리 같은 원격 메모리까지도 스왑 대상이 될 수 있어요.

swap_ops는 이런 다양한 백엔드를 함수 포인터 테이블로 추상화해요. VFS가 다양한 파일시스템을 같은 인터페이스로 다루는 것처럼, 스왑 서브시스템도 다양한 저장 매체를 통일된 방식으로 다루게 만드는 거예요. 이러면 새로운 저장장치가 나와도 기존 코드를 크게 안 건드리고 추가할 수 있어요.

클라우드와 컨테이너 시대의 스왑

사실 이런 변화의 배경에는 클라우드 환경의 압박이 있어요. 쿠버네티스 같은 컨테이너 환경에서는 메모리를 빡빡하게 운영하면서도 OOM Killer가 마구잡이로 프로세스를 죽이는 건 막고 싶거든요. 적절한 스왑이 있으면 일시적인 메모리 압박을 부드럽게 흡수할 수 있어요.

구글, 메타, 페이스북 같은 곳에서는 이미 자체적으로 스왑 튜닝을 많이 해왔어요. 메타가 발표한 Transparent Memory Offloading이나, 메모리 압박을 측정하는 PSI(Pressure Stall Information) 같은 기능들이 다 이 흐름의 일부예요. 이번 swap 재설계도 그 연장선이에요.

한국 개발자에게는

바로 코드를 건드릴 일은 없겠지만, 운영 측면에서는 알아두면 좋아요. 그동안 "스왑은 끄는 게 정답"이라고 알려진 관행이 있었는데, 이제는 상황에 따라 다르거든요. 특히 컨테이너 워크로드를 운영한다면 zswap이나 zram을 활용한 메모리 압축 스왑을 고려해볼 만해요. 디스크 스왑보다 훨씬 빠르고, OOM을 줄일 수 있어요.

또 NVMe SSD를 쓰는 환경이라면, 새 커널이 정식 릴리스되는 시점에 스왑 정책을 재검토하는 게 좋아요. 예전 기준으로 짜둔 swappiness 값이 새 구조에서는 다른 의미가 될 수 있거든요.

마무리

스왑 같은 오래된 기능도 시대에 맞춰 끊임없이 재설계되고 있다는 게 흥미로워요. 메모리 계층이 다양해질수록 "어디에 둘 것인가"라는 문제가 더 중요해지고 있어요.

여러분 서버 환경에서는 스왑을 활성화해 두시나요, 아니면 끄시나요? 그 이유는 뭔가요?