쿠버네티스 1.34 정식 스왑 지원과 고속 SSD를 활용한 워크로드 집적도 개선

노드 스왑의 정식 도입

쿠버네티스 프로젝트에서 노드 단위 스왑 메모리 지원 기능이 1.34 버전부터 정식 출시 상태에 도달했다. 클러스터 운영 환경에서 노드는 중앙처리장치보다 물리 메모리 한계에 먼저 부딪히는 문제가 흔히 발생해 왔다. 특히 초기 기동 시 많은 메모리를 점유한 뒤 대기 상태로 머무르는 에이전트 인공지능 워크로드가 늘어나면서 유휴 메모리 낭비가 심화되었다.

새롭게 정식 지원되는 노드 스왑은 비활성 상태인 익명 메모리를 디스크로 내보내 물리 메모리 공간을 확보할 수 있도록 돕는다. 초고속 비휘발성 메모리 익스프레스 기반 로컬 솔리드 스테이트 드라이브와 결합하면 입출력 지연 시간을 줄이면서 노드당 수용 가능한 파드 수를 크게 확장할 수 있다.

기존 제약과 해결 배경

과거 쿠버네티스 환경에서는 스왑 메모리 사용이 공식적으로 권장되지 않았다. 기존 리눅스 제어 그룹 버전 1 체계에서는 물리 메모리와 디스크 스왑 사용량을 분리하지 않고 단일 한도로 합산 관리했기 때문이다. 이로 인해 컨테이너의 실제 물리 메모리 소비량을 정확히 예측하거나 격리하기 어려워 클러스터 안정성이 저하되는 문제가 있었다.

또한 회전식 자기 디스크 기반 저장장치의 느린 페이징 속도로 인한 심각한 지연 시간 발생도 걸림돌이었다. 쿠버네티스 1.34의 스왑 지원은 제어 그룹 버전 2를 필수 기반으로 삼아 디스크 스왑 사용량을 물리 메모리와 독립적으로 추적 관리한다. 여기에 초고속 로컬 저장장치가 결합하면서 지연 시간 불이익을 최소화하고 메모리 급증을 완충할 수 있게 되었다.

세 가지 워크로드 성능 검증

스왑 기능의 효용성은 지속적 통합 및 배포 커널 빌드, 헤드리스 브라우저 샌드박스, 격리된 파이썬 실행 환경 등 세 가지 워크로드 벤치마크를 통해 검증되었다. 리눅스 6.1.1 커널 빌드 테스트에서는 비스왑 환경의 최소 메모리 제한이 600메가바이트였으나, 로컬 드라이브 스왑을 적용하자 300메가바이트로 50퍼센트 절감되었으며 실행 시간도 433초에서 374초로 단축되었다.

헤드리스 크로미엄 브라우저 환경에서는 표준 실행 환경 기준으로 동시 파드 수가 비스왑 환경 512개에서 스왑 활성화 시 768개로 늘어났다. 보안 샌드박스인 지바이저 적용 환경에서는 80개에서 160개로 2배 증가했고, 카타 컨테이너 기반 초소형 가상머신 환경에서는 40개에서 50개로 25퍼센트 개선되었다. 데이터 분석 작업을 수행한 격리 파이썬 환경의 경우 80개 세션에서 240개 세션으로 동시 실행 용량이 3배 늘어났다.

설정 방법과 운영 고려사항

클러스터 관리자는 노드 에이전트 설정 파일에서 스왑 비활성화 강제 옵션을 해제하고 메모리 스왑 동작을 제한적 스왑으로 지정하여 해당 기능을 활성화할 수 있다. 구글 쿠버네티스 엔진과 같은 클라우드 환경에서는 로컬 드라이브 프로필과 연계하여 노드 메모리 스왑을 구성하는 방식을 지원한다.

워크로드 적용 시에는 요청량보다 제한량을 높게 설정하는 버스터블 서비스 품질 정책을 적용해야 스왑 공간이 효과적으로 분배된다. 노드는 유휴 메모리 사용량에 맞춰 고속 스왑 공간을 자동으로 할당하며, 활성 상태의 프로세스는 반응성을 유지할 수 있도록 관리한다.

적용 한계와 시스템 제약

스왑 기능은 순간적인 메모리 급증을 완충하고 유휴 메모리를 보관하는 용도이지 활성 물리 메모리를 대체하는 수단이 아니다. 리눅스 커널 빌드 시험에서 메모리 제한을 200메가바이트까지 과도하게 낮추자 활성 작업 세트가 디스크로 밀려나 입출력 대기 시간이 길어지며 전체 실행 시간이 40퍼센트 이상 지연되었다.

또한 고집적 상태에서 관측되는 파드별 지연 시간 증가는 스왑 저장장치의 입출력 병목보다는 다수 파드가 중앙처리장치 자원을 두고 경쟁하면서 발생한다. 따라서 실제 서비스 환경을 설계하는 관리자는 무조건적인 최대 집적도 설정보다 목표 지연 시간에 맞추어 노드 수용 용량을 조절해야 한다.