일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 회고
- 코딩봉사
- CJ UNIT
- java
- 소프티어
- 시나공
- 문제풀이
- 스프링
- 백준 알고리즘
- programmers
- C++
- 코틀린
- 1과목
- 알고리즘
- MYSQL
- 코딩교육봉사
- 정보처리산업기사
- 백준알고리즘
- kotlin
- 데이터베이스
- softeer
- 프로그래머스
- python
- 공부일지
- 파이썬
- 자바
- SQL
- 백준
- BFS
- SW봉사
- Today
- Total
JIE0025
[AWS] EC2 프리티어 메모리 부족으로 발생한 빌드 실패와 해결과정 본문
✅ 개요
클론 프로젝트의 첫 배포 당시, 빌드를 실패했었고
이번에 새로 배포를 하면서 이 문제를 아주 간단한 방법으로 해결했다.
상황은 다음과 같다.
📆 2월 배포 상황
t2-micro 프리티어를 사용했다.
빌드 중 58% --> ASCIIDOC 빌드에서 fail이 났다.
당시에뭐가 문제인지 알지 못해서 프리티어 사용을 포기하고 t2-small로 업데이트 해봤는데, 빌드가 성공했다.
프리티어를 사용하지 않아서 발생하는 요금이 생각보다 커서, EC2 인스턴스를 제거해버렸다.
결국 t2-micro와 t2-small의 차이점에서 발생하는 성능상 이점 때문에 가능했다고 판단만 해둔 상태
>> t2-micro의 RAM은 1GB이다
>> t2-small의 RAM은 2GB이다
📆 6월 재배포 상황
재배포하는 상황에서도 58%에서 빌드가 되지 않았는데
이때 잠시 생각해보니
굉장히 쉽게 해결할 수 있었다.
👩💻 Asciidoc build를 할 필요가 있는가?
이번에 내가 해당 프로젝트를 배포하고자 하는 이유는
팀원분이 아래처럼 말씀을 해주셨기 때문이고,
"포트폴리오에 사용할 배포링크가 살아있었으면 좋겠다"
해당 링크가 정상적으로 작동만 하면 된다.
이말은 전체 빌드를 안해도 된다는 말이 되기도 한다.
asciidoc build fail이 서버 실행 자체에는 전혀 영향을 주지 않는다.
결국 asciidoc build를 안하거나,
아니면 docker를 이용하면 될것 같은데....
개인적인 일정 때문에 바빠서 도커는 사용하지 않았고,
그냥 간단하게 asciidoc 빌드를 제거하는 옵션을 사용했다.
asciidoc이 test와 연관이 깊어서
test 빌드 옵션도 함께 제거했다.
./gradlew build -x test -x asciidoctor
-x : Exclude, 특정 작업을 수행하지 않게 지시
✅ 여기서 자연스럽게 의문이 발생하고, 다양한 생각을 하게 된다.
1️⃣ Asciidoctor 빌드 상황에서 t2.micro는 실패하는데, t2.small에서 성공한다면
둘 사이의 유일한 차이점인 RAM과 어떤 관계가 있는걸까?
▶ 서버 메모리가 부족해서, 빌드하다가 메모리에 과부하가 걸린것
QueryDsl 같은 작은것에서도 빌드가 안될 수 있다...
2️⃣ 서버 실행과 연관이 있는 의존성이었다면... 저렇게 해결하면 안된다
다른 해결 방법이 있는가?
램이 1GB이면 스프링부트의 gradle을 통한 빌드작업에서 서버의 가용성에 문제가 발생할 수 있다.
✔️ Swap File을 이용하기
아래 글을 보니 나와 비슷한 상황이 있었고,
Swap file을 이용하여 해결하는 방법도 존재한다.
RAM의 메모리가 부족하므로, 리눅스의 HDD 공간을 RAM처럼 사용하는 방법이다.
https://sundries-in-myidea.tistory.com/102
https://aws.amazon.com/ko/premiumsupport/knowledge-center/ec2-memory-swap-file/
✔️ 로컬 빌드, Docker 사용...
역시 빌드를 Ec2 자체에서 하는것보단 빌드하고 옮겨서 사용하는 방법이 권장되는것 같다.
이게 더 간단한것 같다
다시 배포를 해보다보니 이런저런 것들을 또 발견하고 알게 되는 것 같다
jar를 로컬에서 빌드하고, ec2로 옮기는 방법이 가장 합리적인것 같다는 결론이다.
references
https://velog.io/@kakasoo/CRA-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%B6%80%EC%A1%B1%EC%9C%BC%EB%A1%9C-%EC%9D%B8%ED%95%9C-build-%EC%97%90%EB%9F%AC
https://developheo.com/troubleshooting-aws-ec2-springboot-build-error-not_enough_space/
https://okky.kr/questions/1148112