AWS EC2에서 EBS 볼륨 확장 및 메모리 부족 문제 해결 (swap)
개인 프로젝트로 데이터 수집/적재 파이프라인을 구성하던 중,
AWS EC2 프리티어 인스턴스를 사용하면서 두 가지 큰 문제를 겪었다.
- 디스크 용량이 부족해서
.vscode-server가 제대로 설치되지 않거나 Remote 연결이 불안정함 - 메모리가 부족해서 작업 중에 EC2가 먹통이 되는 현상
특히 메모리 부족은 VS Code Remote로 접속한 후 타자 입력도 안 되고, 세션이 끊기는 상황까지 발생했다.
결국 디스크(EBS)와 메모리(RAM) 문제를 모두 해결해야 안정적으로 개발 환경을 유지할 수 있었다.
문제를 해결하기 위해 찾아보던 중,
이 블로그 글에서 프리티어 인스턴스의 메모리 제약과 스왑 설정에 대한 내용을 참고할 수 있었다.
이를 기반으로 디스크를 먼저 확장하고, 이후 메모리 부족 문제를 스왑 설정으로 해결하는 순서로 진행했다.
⚠ 문제 1. EBS 디스크 부족
EC2를 프리티어로 생성하면 기본 디스크 용량이 8GB로 설정되어 있다. 처음에는 괜찮았지만, Docker로 Airflow를 설치하고 기타 개발 환경을 구성하는 과정에서 디스크가 예상보다 빨리 소진되기 시작했다.
1
df -h
1
/dev/root 8G 7.5G 0.5G 95% /
용량이 95% 이상으로 차오르면서, 작업 중 예기치 않게 설치 오류나 환경 구성 실패가 발생했다. 특히 .vscode-server 설치가 안되는 문제가 생기면서, VS Code Remote 연결이 불안정해지는 현상도 경험했다.
💡 해결: EBS 볼륨 확장
1. 콘솔에서 디스크 용량 확장
먼저 AWS EC2 콘솔에 접속해서, 루트 디바이스로 연결된 EBS 볼륨의 용량을 확장해주었다. 좌측 메뉴에서 스토리지 항목으로 이동한 후, 사용 중인 인스턴스의 루트 볼륨을 선택 → 수정 버튼을 클릭해 20GB로 변경했다.
변경 사항을 저장하면 EBS 볼륨 자체는 확장되지만, 이 상태로는 리눅스 OS에서는 여전히 이전 크기(8GB)까지만 사용할 수 있다. 그래서 리눅스 내부에서 별도로 파티션을 확장하는 작업이 필요하다.
2. 리눅스에서 파티션 및 파일시스템 확장
먼저 현재 디스크 구조를 확인한다.
1
lsblk
결과:
1
2
nvme0n1 20G
└─nvme0n1p1 8G
물리 디스크 자체는 20GB로 확장되어 있지만, 파티션(nvme0n1p1)은 여전히 8GB까지만 할당되어 있는 상태다. 이 파티션을 확장하려면 growpart와 resize2fs를 사용한다:
1
2
3
4
5
# 파티션 확장
sudo growpart /dev/nvme0n1 1
# 파일시스템 확장 (ext4 기준)
sudo resize2fs /dev/nvme0n1p1
확장 후 다시 디스크 사용량을 확인하면 다음과 같은 결과가 나온다:
1
df -h
1
/dev/root 20G 7.5G 12G 38% /
디스크 용량이 정상적으로 확장되었고, 이제는 Docker나 Airflow 같은 도구를 설치하거나, VS Code Remote로 접속할 때처럼 시스템 자원을 요구하는 작업들도 문제없이 수행할 수 있게 되었다.
⚠ 문제 2. 메모리 부족
디스크는 해결했지만, 여전히 작업 도중 EC2가 멈추는 현상이 있었다. 특히 VS Code Remote SSH로 접속 후 조금만 작업해도 렉이 심해지고, 결국 타자 입력조차 먹지 않았다. 결국 연결이 끊기고, 다시 접속을 시도해도 SSH가 제대로 되지 않는 상황까지 이어졌다.
직접 확인해보니, EC2 프리티어 인스턴스(t2.micro)는 RAM이 1GB밖에 되지 않는다. 처음에는 개발 초기이니 충분할 거라고 생각했지만, Python 실행, 의존성 설치, VS Code Remote 환경 등이 겹치면서 금세 한계에 도달했던 것이다.
참고: AWS 프리티어에서 제공하는 t2.micro는 vCPU 1개, RAM 1GB로 개발 초기에는 충분하지만, Python 실행, 의존성 설치, VS Code 연결 등이 겹치면 금방 한계에 도달한다. (출처: https://diary-developer.tistory.com/32)
아래는 실제로 문제가 발생했을 당시 메모리 상태를 확인한 결과다.
1
free -m
1
2
3
total used free shared buff/cache available
Mem: 995 980 15 8 20 7
Swap: 0 0 0
RAM이 거의 가득 찬 데다, 스왑(Swap) 공간도 설정되어 있지 않은 상태였다. 이처럼 메모리 여유 공간이 10MB 안팎으로 줄어들면, 리눅스 커널은 프로세스를 강제로 종료하거나, 전체 시스템을 멈춰버리기도 한다. 실제로도 이 시점에서 EC2가 먹통이 되면서 정상적인 개발 작업이 불가능했다.
💡 해결: 스왑(Swap) 공간 설정
리눅스에서는 디스크 공간 일부를 스왑(Swap)으로 지정해, 메모리가 부족할 때 임시 메모리처럼 사용할 수 있다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 1. 2GB 스왑 파일 생성
sudo fallocate -l 2G /swapfile
# 2. 권한 설정
sudo chmod 600 /swapfile
# 3. 스왑 영역 초기화
sudo mkswap /swapfile
# 4. 스왑 활성화
sudo swapon /swapfile
# 5. 재부팅 시에도 자동 적용되도록 설정
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
적용 결과 확인
1
free -m
1
2
3
total used free shared buff/cache available
Mem: 995 550 300 10 145 400
Swap: 2047 20 2027
스왑이 정상적으로 활성화되었고, 사용 가능한 메모리도 여유 있게 확보되었다. 이후로는 VS Code Remote 연결 중 끊김, 먹통 현상이 발생하지 않았다.
마무리
특히 프리티어 환경에서는 자원이 워낙 작기 때문에, 디스크 확장과 스왑 설정이 안정적인 개발 환경을 위한 필수 작업이라는 것을 깨달았다.