Delivery 프로젝트 기능 구현을 마무리 하고 배포 단계에서 CI/CD를 할 것인지 의논하였으나 프로젝트 규모가 작아 그냥 배포만 하기로 결정하였다. 그런데 배포 과정에서 예상치 못한 오류를 만났으니... 트러블 슈팅을 정리해보자
첫 번째 문제는 우리의 프로젝트 파일에 gradle-wrapper.jar
파일이 포함되지 않아서 발생했다. 이 파일이 존재하지 않으면 간단히 Gradle Wrapper를 초기화해서 파일을 생성해주면 된다. ec2 환경이니 gradle 설치부터 해주어야 한다.
우분투 기반의 EC2에서 그냥 apt install로 gradle을 설치하면 4.X의 낮은 버전이 설치된다. 우리 프로젝트는 JDK 17, Gradle 8.12.1 버전을 사용하므로 버전을 맞추기 위해 수동으로 설치해주어야 했다.
//gradle 설치
sudo wget https://services.gradle.org/distributions/gradle-8.12.1-bin.zip
// 압축 해제
sudo unzip -d /opt/gradle gradle-8.12.1-bin.zip
// 환경 변수 설정
export PATH=$PATH:/opt/gradle/gradle-8.12.1/bin
gradle 설치 후 권한을 부여하고 wrap을 실행한다.
sudo chmod 777 gradle-wrapper.properties
sudo chmod 777 gradlew.bat
gradle wrap
...이렇게 하면 된다고 하는데 우리의 조그마한 t2.micro가 wrap 명령어 사용과 함께 CPU 사용률 100%를 찍고 뻗어버렸다. Gradle Daemon을 종료하고 시도한다던가 하는 방법을 GPT가 추천하긴 했지만 이 시점에 제출이 얼마 남지않아.. 시간이 얼마 없었으므로 gradle-wrapper.jar
파일을 그냥 로컬에서 직접 쏴서 때려 넣어버렸다. 아무튼 그렇게 해서 빌드는 성공했다.
이제 docker compose up 명령어로 서버와 DB, 레디스를 띄웠는데.... CPU 사용률이 또 100%를 찍고 뻗어버렸다. 요청을 보내도 무한 로딩에 걸리질 않나 SSH 접속도 안되질 않나
문제 해결을 위해 인스턴스 종료 후 재시작한 뒤, docker-compose.yml
파일에 리소스 설정을 추가해주었다. t2.micro는 vCPU 1개, RAM 1GB를 제공하므로 이에 맞춰서 각각의 컨테이너의 CPU와 메모리 사용량을 제한하였다.
deploy:
resources:
limits:
cpus: "0.5" # 최대 CPU 50% 사용
memory: "400M" # 최대 400MB RAM 사용
리소스 설정 후 재시작하니 잘 작동하여 배포가 성공적으로 이루어짐을 확인하였다!