EC2 인스턴스 메모리 부족 문제 해결기

최근 EC2 인스턴스에서 여러 마이크로서비스를 운영하던 중 메모리 부족으로 SSH 접속이 불가능한 상황이 발생했다.

 

단순히 인스턴스를 재부팅하는 응급조치로는 근본적인 문제를 해결할 수 없었기 때문에,

원인 분석과 함께 스펙 업그레이드 및 추가 대안을 검토해보았다 !

---

📌 문제 상황

운영 중인 EC2 인스턴스(t3.medium)에서 서비스가 불안정해지고 SSH 접속이 끊겼다.
top 명령어를 확인했을 때, 메모리 사용량은 이미 포화 상태였다.

• 사용 중인 메모리: 3791.7 MiB / 3.8 GiB
• 남은 메모리: 101.9 MiB
• 주요 프로세스에서 java가 다수의 메모리를 사용 중
• 시스템 응답 속도가 느려지고 SSH 접속조차 어려운 상황 발생

✅ 원인

• EC2 인스턴스 유형: t3.medium (2 vCPU / 4GB RAM)
• 실행 중인 서비스 수: 약 13개
• 문제의 핵심: Java 기반 마이크로서비스들이 JVM 힙 메모리를 각자 크게 사용하면서 전체 메모리 부족(OOM)이 발생

---

🔧 해결 방법

1. EC2 인스턴스 중지

메모리가 포화된 상태라 SSH로 접근이 어려웠기 때문에, AWS 콘솔에서 인스턴스를 직접 중지(Stop)했다.
이 과정에서 EBS 볼륨이 삭제되지 않도록 ‘Delete on Termination’ 옵션을 반드시 확인했다.

 

2. 인스턴스 유형 변경

인스턴스를 중지한 후, 콘솔에서 다음 경로로 이동

EC2 > 인스턴스 > 인스턴스 선택 > 작업 > 인스턴스 설정 > 인스턴스 유형 변경

• 변경 전: t3.medium (2 vCPU / 4GB)
• 변경 후: t3.large (2 vCPU / 8GB)

 

3. 인스턴스 시작

인스턴스 유형 변경 후 다시 시작(Start) 하면, 설정한 인스턴스 유형으로 부팅됩니다.

이 상태에서 SSH 접속도 정상적으로 가능해졌고, 서비스도 안정적으로 동작했다

---

🔥 추가적인 근본 대안

스펙 업그레이드는 가장 빠르고 확실한 해결책이지만, 비용이 증가한다는 단점이 있다.

장기적으로는 다음과 같은 최적화 방안도 고려해야 한다 ! 

 

 

(1) JVM 메모리 최적화

• 각 서비스 실행 시 -Xmx, -Xms 옵션을 조정해 불필요한 메모리 점유를 최소화

java -Xms256m -Xmx512m -jar service.jar

 

(2) 서비스 구조 점검

• 항상 실행할 필요 없는 서비스는 On-Demand 실행으로 전환하거나, 모듈 통합을 고려

(3) 스왑 메모리 설정

• 물리 메모리가 부족한 경우를 대비해 스왑 파일을 생성해 Out-of-Memory 상황을 완화

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

 

(4) 모니터링 도입

• Prometheus + Grafana, Micrometer 등을 통해 각 서비스별 메모리 사용량을 시각화해 병목 서비스 파악

---

💡 마무리

이번 경험을 통해 단순 재부팅은 응급조치일 뿐, 근본 해결책이 될 수 없다는 점을 다시금 느꼈다.
메모리 부족 문제를 해결하기 위해 스펙 업그레이드를 진행했지만, 앞으로는 JVM 튜닝, 서비스 구조 최적화, 모니터링을 통해 지속적으로 안정적인 서버 환경을 만들어 나가야 할 것이다.