로컬 RAM 풀링이 더 큰 머신을 구매하는 것보다 나은 이유

Source: Dev.to

우리는 모두 그런 경험을 해봤습니다.
무거운 빌드를 실행하거나 모델을 학습시키거나 방대한 데이터셋을 처리하고 있을 때, 갑자기 모든 것이 멈춥니다. htop을 확인해보니 죽음의 빨간 바, Swap이 보입니다. 32 GB MacBook이 숨을 헐떡이는 사이, 동료의 노트북은 한가하고 사무실 서버는 5 % 활용률로 조용히 돌아갑니다.

그 순간 전형적인 엔지니어(저 포함)의 본능은:

“더 큰 머신이 필요해.”

우리는 직관적으로 신용카드를 꺼내 64 GB 혹은 128 GB로 업그레이드하려 합니다. 최근에 나는 이 본능이 단지 비쌀 뿐 아니라 기술적으로도 역행한다는 것을 깨달았습니다.

기존의 상식

한 대의 머신에 RAM이 많을수록 성능이 좋다

로컬 메모리가 보통 가장 빠른 자원이기 때문에 사실처럼 느껴집니다. 하지만 분산 시스템을 구축하면서 힘들게 배운 함정이 있습니다.

단일 머신을 확장하면 벽에 부딪히는 이유

• 대역폭 병목 – 하나의 메모리 버스는 일정량 이상의 데이터를 전달할 수 없습니다.
• NUMA 패널티 – 멀티‑소켓 서버에서 “다른” CPU의 RAM에 접근하면 지연 시간이 크게 증가합니다.
• 폭발 반경 – 그 비싼 한 대의 머신이 다운되면 전체 워크로드가 함께 죽습니다.

옆에 있는 노트북이나 서버와 비교해 보세요. 각각 자체 메모리 컨트롤러, 버스, CPU를 가지고 있습니다. 메모리 대역폭은 넓게 확장할수록 선형적으로 증가합니다: 64 GB RAM을 장착한 두 대의 머신은 128 GB RAM을 장착한 한 대의 머신보다 대략 두 배의 총 대역폭을 가집니다.

“넓게 확장”이 어려운 이유

CPU(Kubernetes)와 스토리지(S3, 네트워크 드라이브)를 공유할 수 있는 훌륭한 도구가 있지만, 메모리는 언제나 박스 안에 갇혀 있습니다. 즉, 로컬 메모리만 사용할 수 있죠. 나는 이를 Stranded RAM이라고 부릅니다.

현재 사무실이나 데이터 센터 전체 RAM의 약 60–80 %가 프로비저닝되고, 비용이 지불되며, 전원이 켜져 있지만 실제로 필요로 하는 프로세스가 전혀 접근하지 못하고 있습니다.

마치 차고에 다섯 대의 차가 있는데, 현재 타고 있는 차가 연료가 부족해서 출근을 못 하는 상황과 같습니다.

MemCloud 소개

나는 이 제한을 깨기 위해 MemCloud를 만들었습니다. 아이디어는 로컬 네트워크에 있는 노트북, 데스크톱, Raspberry Pi 클러스터들의 RAM을 하나의 거대한 메모리 풀로 취급하는 것입니다.

MemCloud는 로컬 RAM을 대체하지는 않습니다(네트워크 지연은 현실입니다). 대신 메모리 계층 구조의 “웜(warm)” 레이어에 위치합니다:

원격 RAM은 여전히 NVMe SSD보다 5–10배 빠르므로 다음 용도에 이상적입니다:

• 빌드 캐시
• ML 임베딩
• 임시 컴파일러 아티팩트
• 분석용 스크래치 공간

몇 기가바이트 정도의 “웜” 데이터를 이웃 노드에 오프로드하면 로컬 머신이 한숨 돌릴 수 있습니다: 스와핑이 멈추고 UI가 다시 반응하게 됩니다.

활용 사례

• CI 파이프라인은 근무 시간 외에 사무실 워크스테이션에서 100 GB RAM을 빌릴 수 있습니다.
• 엣지 디바이스는 리소스를 풀링해 개별적으로는 감당할 수 없는 AI 모델을 실행할 수 있습니다.
• 팀은 거대한 인‑메모리 데이터셋을 각자 전체 복사본을 갖지 않아도 공유할 수 있습니다.

시작하기

MemCloud는 Rust로 작성되었으며, 이는 단일 거대 서버보다 협업형 피어‑투‑피어 스웜으로의 전환을 반영합니다.

• 📖 문서 읽기:
• 💻 코드 살펴보기:

“Out of Memory” 오류가 뜨는 상황에서 주변에 사용되지 않는 컴퓨터가 많다면, 이 문제가 왜 중요한지 알 수 있을 겁니다. 댓글로 메모리와 관련된 고민을 자유롭게 나눠 주세요!