서론: 서비스가 예고 없이 멈추는 이유
AWS Lightsail이나 소형 클라우드 인스턴스(RAM 1GB~2GB)를 운영하다 보면 가장 자주 마주치는 문제가 바로 ‘메모리 부족으로 인한 DB 다운’ 현상입니다.(AWS Lightsail에서는 아직 이 현상을 확인하지는 않았어요) 리눅스 커널은 가용 메모리가 고갈되면 시스템 보호를 위해 특정 프로세스를 강제로 종료하는 OOM(Out of Memory) Killer를 작동시키는데, 대개 그 타겟은 메모리 점유율이 높은 MySQL이나 MariaDB 엔진이 됩니다.
물론 서버 사양을 올리는(Scale-up) 것이 가장 좋지만, 비용을 효율적으로 관리해야 하는 개인 프로젝트나 테스트 서버에서는 부담이 될 수 있습니다. 이때 하드디스크의 일부를 가상 RAM처럼 사용하는 Swap(스왑) 공간을 설정해두면, 일시적인 트래픽 증가에도 서버가 즉시 멈추지 않고 버텨낼 수 있습니다.
현재 스왑 상태 확인 (Before)
본격적인 작업에 앞서, 현재 시스템의 메모리와 스왑 상태를 확인합니다. 기본 설정 상태라면 스왑 영역이 0으로 표시될 것입니다.
Bash
# 메모리 상태 확인 (-h: 사람이 읽기 편한 단위로 표시)
free -h[체크포인트] 결과 화면의 Swap: 항목을 확인하세요. 0B 또는 0으로 표시된다면 현재 서버는 메모리 부족 시 바로 프로세스를 종료하게 되는 위험한 상태입니다.
스왑 파일 생성
가장 먼저 시스템 내에 스왑 공간으로 활용할 1GB 크기의 빈 파일을 할당합니다. dd 명령어를 사용하며, 1MB씩 1024번 기록하여 정확히 1GB를 만듭니다.
Bash
# /swapfile이라는 이름으로 1GB 용량의 파일 생성
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024
보안을 위한 권한 설정
스왑 파일에는 시스템의 민감한 데이터가 기록될 수 있으므로 보안 설정이 매우 중요합니다. root 계정 외에는 이 파일에 접근할 수 없도록 권한을 엄격히 제한해야 합니다.
Bash
# 소유자(root)에게만 읽기/쓰기 권한 부여
sudo chmod 600 /swapfile
스왑 영역 초기화 및 활성화
파일 생성이 완료되었다면, 이 파일을 리눅스가 스왑 공간으로 인식할 수 있도록 포맷하고 시스템에 활성화 명령을 내립니다.
Bash
# 1. 생성한 파일을 스왑 영역으로 포맷
sudo mkswap /swapfile
# 2. 시스템 스왑 공간으로 활성화
sudo swapon /swapfile
설정 결과 확인 및 모니터링
스왑 용량이 정상적으로 추가되었는지 확인합니다. free -h 명령어의 결과에서 Swap 항목의 숫자가 늘어났는지 체크해 보세요.
Bash
# 전체 메모리 및 스왑 상태 확인
free -h
# 현재 활성화된 스왑 파일 목록 확인
swapon -s결과 화면에서 1.0G 정도의 스왑 용량이 확보되었다면 성공입니다.
swapon -s 명령어가 안먹힘, 패키지 설치가 안 되어 있어서 상황 발생… 이럴 땐 당황하지 말고
sudo apt-get install util-linux로 패키지를 설치해 주시면 해결됩니다.
재부팅 후 자동 활성화 설정
위의 설정은 서버를 재부팅하면 사라지는 일시적인 설정입니다. 서버가 켜질 때마다 자동으로 1GB 스왑을 잡을 수 있게 /etc/fstab 파일에 영구 등록해야 합니다.
Bash
vi visudo /etc/fstab(참고: /etc/fstab은 일반 vi로 열어도 되지만 안전을 위해 권한을 확인하세요.)
파일 맨 하단에 다음 내용을 한 줄 추가하고 저장합니다.
/swapfile swap swap defaults 0 0
💡 엔지니어의 노트: 편리함 뒤에 숨은 최후의 방어선
대용량 메모리(16GB~128GB)가 표준인 빅데이터 시대에 살다 보니, 저조차 Swap의 중요성을 간과하곤 했습니다. 하지만 저사양 클라우드 환경에서는 이야기가 다르죠.
물론 스왑이 물리 RAM만큼 빠르진 않지만, 새벽 3시에 서버 다운 알람을 받고 깨는 것보다는 백 배 낫습니다. 제가 사용하는 Lightsail 인스턴스는 용량이 참 ‘작고 귀엽기 때문에’, 최소한의 생명줄로 딱 1GB만 추가하고 시작하려 합니다
마무리하며
이제 1GB의 든든한 가상 메모리 보호막이 생겼습니다. 이제 웬만한 부하 상황에서도 DB가 갑자기 종료되어 서비스가 중단되는 사태는 막을 수 있을 것입니다. 인프라 운영은 언제나 ‘최악의 상황’을 대비하는 것에서 시작한다는 것을 잊지 마세요.
“이 글의 영문 버전은 [이곳]에서 확인하실 수 있습니다.”