Kubernetes 공식 블로그가 빠른 로컬 SSD를 활용한 노드 Swap 실험을 소개했습니다. 메모리를 사용하다 유휴 상태로 머무는 작업을 디스크로 내보내 파드 밀도를 높이는 접근입니다. 이번 글은 Swap 지원이 새로 정식 출시됐다는 공지가 아닌 운영 분석입니다. Kubernetes 공식 발표
Swap은 RAM 부족을 무제한으로 해결하는 장치가 아닙니다. 다시 필요한 페이지를 읽을 때 디스크 지연과 I/O가 발생합니다. 평균 지연이 괜찮더라도 일부 요청의 긴 대기 시간이 문제가 될 수 있어요.
이 글의 목차
유휴 메모리와 지금 필요한 메모리는 다릅니다
프로세스가 확보한 메모리 전체가 항상 활발히 읽히는 것은 아닙니다. Swap은 일부 메모리 페이지를 저장장치로 옮겼다가 필요할 때 다시 가져오는 기능입니다. 오래 기다리는 브라우저나 실행 환경에서는 유휴 상태가 있을 수 있어요. 반대로 계속 읽고 쓰는 작업 집합을 디스크로 밀어내면 반복적인 입출력 때문에 지연이 크게 늘어날 수 있습니다.
따라서 메모리 사용량 숫자 하나만 보고 Swap에 적합한 워크로드라고 판단하지 않습니다. 시작할 때 많이 쓰는지, 대기하다 다시 활성화되는지, 항상 큰 작업 집합을 유지하는지 구분합니다. CPU 사용률이 낮아 보여도 메모리를 자주 읽는 작업일 수 있으므로 실제 요청과 메모리 접근 패턴을 함께 살펴야 합니다.
빠른 SSD도 RAM과 같은 자원은 아닙니다
NVMe SSD는 느린 디스크보다 유리한 조건을 제공할 수 있지만 RAM을 대체하지는 않습니다. Swap을 읽고 쓰는 작업은 앱 데이터와 로그의 I/O를 경쟁할 수 있고, 여러 파드가 동시에 깨어나면 부하가 겹칠 수 있습니다. 평상시에는 괜찮았던 응답이 특정 순간에 길어지는지 보는 이유입니다. 평균뿐 아니라 느린 상위 구간의 요청을 함께 확인합니다.
또한 Swap에는 원래 메모리에 있던 내용이 저장될 수 있습니다. 노드 저장장치의 암호화와 접근 통제, 폐기 정책을 검토해야 합니다. 지원 버전과 cgroup 구성, 워크로드별 허용 정책도 제품 문서에 맞춰 확인합니다. 단순히 호스트에서 Swap을 켜는 명령을 실행하는 것과 Kubernetes가 의도한 정책으로 관리하는 상태는 구분해야 합니다.
유휴 상태를 끝내는 순간을 시험합니다
평가 대상이 에이전트용 브라우저라면 세션 생성, 일정 시간 대기, 동시 재개를 나눠 시험할 수 있습니다. 같은 동시성과 요청으로 Swap 없는 구성과 비교하고, 재개 직후의 지연과 실패율을 기록합니다. 안정적으로 실행 가능한 세션 수가 늘어도 사용자 대기 시간이 허용 범위를 벗어나면 밀도 개선만으로 운영 도입을 결정하기 어렵습니다.
원인 판단을 위해 페이지 인·아웃, 디스크 대기, CPU와 메모리 압박을 같은 시간축에 놓습니다. 과도한 페이지 교체가 계속되면 파드 수나 자원 제한을 조정할 중단 기준이 필요합니다. 아래 명령은 노드의 현재 Swap과 메모리 정보를 읽는 출발점이며, 지원 설정이나 성능 적합성을 판정하는 전체 시험을 대신하지 않습니다.
swapon --show
free -hswapon 목록이 비어 있으면 이 명령에서 확인되는 활성 Swap 항목이 없는 상태입니다. 이 출력만으로 파드별 Swap 허용 정책이나 지연 영향을 판단하지 않습니다.
실험 노드에서 볼 지표
- 지연의 평균과 상위 구간, 페이지 인·아웃을 함께 측정합니다.
- Swap과 애플리케이션이 같은 디스크 자원을 경쟁하는지 확인합니다.
- 민감한 메모리 내용의 저장과 디스크 암호화 정책을 검토합니다.
한 종류의 워크로드부터 자원 제한과 복구 기준을 정해 시험합니다. 메모리 증가 비용과 I/O 비용을 같은 조건에서 비교합니다.
발표문 기준일: 2026-10-05 · 확인일: 2026-10-24
