AWS 용량 대책

• EBS는 콘솔에서 키운 뒤 OS 안에서 growpart와 resize2fs(또는 xfs_growfs)까지 해야 df에 보인다.
• EBS와 RDS 모두 줄이는 건 숫자 수정이 아니라 새로 만들어 이사하는 일이다.
• 그래서 처음엔 작게 잡되, 남은 용량 알림부터 걸어 둔다.

디스크가 차고, 인스턴스 타입을 키우고, RDS 스토리지를 늘리는 일들은 되돌리기 어렵거나(특히 축소) 다운타임이 생기는 경우가 많다. 처음엔 콘솔에서 숫자만 바꾸면 df도 따라올 줄 알았는데, EBS는 볼륨만 키우고 끝나면 게스트 안에서는 예전 크기 그대로다. 그 헷갈림부터 정리한다.

초기 용량 — 내가 잡던 감각

“나중에 늘리면 되지”로 작게 가도 되지만, 늘리는 작업 자체에 재부팅·파티션 확장·(RDS면) 마이그레이션이 따라올 수 있다.

• 앱/웹 EC2: OS·로그·임시 파일 여유를 두고 EBS를 잡는다. 키우기는 비교적 쉽고 줄이기는 어렵다.
• DB(RDS): allocated storage는 늘리기만 되고 줄이기가 안 된다. 초기값을 너무 크게 잡지 않되, FreeStorageSpace 같은 모니터링을 먼저 건다.
• 트래픽이 들쭉날쭉하면 CPU/메모리와 디스크를 한꺼번에 키우기보다, 병목이 어디인지부터 본다.

EBS 늘리기 — 콘솔 다음이 OS

콘솔에서 볼륨 크기를 키운 뒤에도, 게스트 OS 안의 파티션/파일시스템이 따라오지 않으면 df로는 그대로다. 그래서 “볼륨 수정 → OS에서 파티션 확장” 두 단계로 본다.

Linux면 보통 lsblk로 디바이스를 확인한 뒤 growpart(또는 parted)로 파티션을 늘리고, ext4면 resize2fs, xfs면 xfs_growfs로 파일시스템을 확장한다. NVMe·디바이스 이름이 기대한 것과 다른 경우가 많으니, 먼저 마운트 포인트가 가리키는 블록 장치를 확인한다.

# 디바이스와 파티션 확인
lsblk
df -hT

# 파티션 1번을 늘린다 (디바이스 이름은 lsblk 결과로)
sudo growpart /dev/nvme0n1 1

# ext4면
sudo resize2fs /dev/nvme0n1p1
# xfs면 (마운트 지점을 넘긴다)
sudo xfs_growfs -d /

df -hT

콘솔에서 크기를 바꾼 뒤에는 같은 볼륨을 다시 수정하려면 6시간을 기다려야 한다. 조금씩 여러 번 늘리기보다 한 번에 넉넉하게 늘리는 편이 낫다.

용량/네트워크를 건드리다 보면 DNS·라우팅이 잠깐 꼬여 could not resolve host: github.com 같은 오류가 나기도 한다. 그때는 디스크보다 /etc/resolv.conf, VPC DNS, 보안 그룹·NACL에서 DNS(53)가 막혔는지부터 본다.

EBS 줄이기

실수로 확장해 버린 경우, 돌이키기가 매우 어렵다. 줄이려면 보통 더 작은 볼륨을 새로 만들고 데이터를 옮긴 뒤 교체한다. 스냅샷만으로 “크기만 축소”는 기대하기 어렵다. 내가 했던 순서는 이렇다.

작은 볼륨을 같은 AZ에 만들어 인스턴스에 붙이고, 포맷한 뒤 rsync -aHAX로 원본에서 통째로 복사한다. 루트 볼륨이면 인스턴스를 멈추고 교체한 뒤, /etc/fstab의 UUID가 새 볼륨과 맞는지 꼭 본다. 여기서 틀리면 부팅이 안 된다.

RDS

스토리지 확장은 콘솔/CLI에서 allocated storage를 올리는 방식이다. 엔진·설정에 따라 적용 중 성능 영향이 있을 수 있으니, 트래픽 적은 시간대에 하는 편이 마음이 편하다. Storage autoscaling을 켜 두면 임계치에 가까워질 때 알아서 늘리기도 한다.

줄이기는 “숫자만 줄이기”가 아니라 프로비저닝된 스토리지가 더 작은 새 DB 인스턴스를 만들고 데이터를 이사하는 흐름이다. 덤프/복원, 읽기 복제본 승격, DMS 등 프로젝트에 맞는 수단을 고른다.

데이터가 작으면 덤프와 복원으로 충분했다. 서비스를 오래 멈출 수 없으면 복제를 걸어 두고 따라잡은 뒤에 엔드포인트만 바꾼다. 옛 인스턴스는 최종 스냅샷을 남기고 지운다.