[트러블 슈팅] AWS EC2 서버 멈춤 및 CPU 상승 이슈

서승·2025년 5월 11일

aws cpu ec2 멈춤 상승

테스형

목록 보기

17/25

테스트 플랫폼 : 테스형 서비스 구축 과정 시 Github Action을 통한 AWS EC2 Docker 자동화 파이프라인 구축에서 일어난 트러블 슈팅

1. Spring Boot App 이미지 로드 실패

배포를 완료하고 프론트 주소에 접속하였더니 ..

텅 -..

API 서버와 연동이 잘 안된건지 DB서버에 연결이 잘 안된건지 .
Docker 컨테이너는 잘 돌아가니 연결문제인 것 같다.
보안 그룹도 이상이 없다.

콘솔을 확인해보니

TypeError: NetworkError when attempting to fetch resource.

즉 네트워크 요청 에러이다.

알고보니 Mysql 컨테이너와 API 서버 컨테이너가 계속해서 재시작 중 이었다.

docker logs -f tst-be

app.jar 파일이 없다는 로그

COPY --from=builder /app/build/libs/myapp-0.0.1-SNAPSHOT.jar app.jar

Dockfile에서 코드는 jar을 기대하지만, 테스트를 위해서 로컬에서 빌드 후 파일을 보면

seuo@seoseung-ui-MacBookAir tst-be % ls build/libs/ tst-0.0.1-SNAPSHOT-plain.war tst-0.0.1-SNAPSHOT.war`

war로 추출되고 있었던 것 ..

build.gradle 로 들어가서

plugins {
    id 'java'
-   id 'war'
    id 'org.springframework.boot' version '3.4.5'
    id 'io.spring.dependency-management' version '1.1.7'
}

_id 'war' 을 지워주고
외부 톰캣에 대한 종속성을 제거한다.
생성 파일 이름도 코드에서 기대하는 app.jar 로 만들어주기위해

bootJar {
  archiveFileName = 'app.jar'
}

코드를 추가해준다.

app.jar로 추출된 모습.

app.jar → bootJar로서 모든 의존성을 포함, 곧바로 java -jar app.jar 로 실행 가능
tst-0.0.1-SNAPSHOT-plain.jar → 기본 jar 태스크 산출물, 의존성 미포함

Dockfile 코드도 수정해준다.

COPY --from=builder /app/build/libs/app.jar app.jar

다시 배포하니 더 이상 재시작이 안되는 모습

-해결-

2. 메모리 부족으로 인한 서버 멈춤 및 CPU 초 상승

어라 ..
배포를 하고 몇분이 지나면 서버가 멈추고 응답이 없다.
모니터링으로 CPU 상황을 보니 100까지 우상향으로 달리고 있다 !!

혹시나 하고 .. 확인하여보니 아마 용량 문제였던 것 .
아무래도 마이크로 서버에 4개의 도커 컨테이너를 띄우는 게 버거울 것이긴 할터이다. .

t2.micro 를 사용하는 내겐 과금은 버거운 일 ..
1GB 정도 느리지만 SWAP을 사용하여 타개해보고자 한다.
EC2 서버에 접속하여서 SWAP 설정을 해준다.

하지만 이 방법을 사용하면 속도가 조금 느려질 수 있다는 것을 감안해야한다.

#!/bin/bash

# 1GB 스왑 파일 생성 및 설정

SWAPFILE=/swapfile

# 스왑 파일 생성
echo "Creating 1GB swap file..."
sudo fallocate -l 1G $SWAPFILE || sudo dd if=/dev/zero of=$SWAPFILE bs=1M count=1024

# 권한 설정
sudo chmod 600 $SWAPFILE

# 스왑 영역 초기화
sudo mkswap $SWAPFILE

# 스왑 활성화
sudo swapon $SWAPFILE

# /etc/fstab에 등록 (재부팅 후에도 유지)
echo "$SWAPFILE none swap sw 0 0" | sudo tee -a /etc/fstab

# 결과 출력
echo "Swap setup complete. Current swap usage:"
free -h

설정은 완료하였고 ..
다시 빌드 해보겠다 ....

빌드 성공 ... 과연 ..

CPU 사용률은 18에서 16으로 떨어지며

4개의 컨테이너 모두 잘 돌아가고 있긴 한 모습이다. .
방심하지 말고 게속 모니터링 해주자 .

사용률이 갑자기 치솟는 모습 ..
아 아아 안돼 ㅜ ㅜ .. !

docker stats 를 통해 각 컨테이너 메모리 사용량을 확인해보았다.

컨테이너	사용량	제한	비율	비고
tst-be	209.5MiB	768MiB	27.27%	Spring Boot 애플리케이션 (JVM)
mysql-db	202.5MiB	512MiB	39.55%	MySQL 기본 설정 부담
nginx-proxy	636KiB	957.4MiB	0.06%	매우 적음
redis	1.2MiB	128MiB	0.94%	매우 적음