2023. 6. 22. 09:59ㆍ카테고리 없음
회사 monorepo로 구성한 인스턴스를 git clone 받아와 빌드해서 배포하려니 계속 멈추고 인스턴스가 죽길래 모니터링을 봤더니
CPU를 95퍼 이상 사용하더니 계속해서 장렬하게 전사하고 있었습니다 ㅜㅜ
t2.micro를 쓰고 있고 메모리(1GB)의 저사양이라 yarn build시 계속해서 CPU 100퍼를 찍고 먹통이 되고 멈추는데 (이전에 devOps분들이 관리해줘서 무지한ㅜ)
모노레포로 프로젝트 세팅을 해서 그런가 yarn berry가 foreach로 각각 빌드하면서 메모리 소모가 심하구나! 하면서 yarn berry로 구성한 monorepo탓을 강하게 하면서! 멀티레포로 옮기고 다시 빌드를 해도 똑같았습니다 ㅜㅜ
(사실 모노레포의 장점도 많지만 저희 회사의 도메인도 많지 않고 three.js를 패키지로 만들고 사용하려니 next.js에서 렌더링 이슈랑 맞물려 웹 애플리케이션에서 패키지를 다시 깔아서 사용하는 등 오버스펙인가 고민을 하던 차..이긴했습니다..)
yarn create next-app은 ec2에 띄우기 성공! 하지만 프로젝트 세팅하면 터지므로 해결책을 찾아봤습니다.
1. local에서 build -> Github push -> EC2 인스턴스에서 pull
사양이 구린 ec2 인스턴스에서 yarn build하지 않고! 빵빵한 내 맥북 프로에서 빌드 후 github로 빌드된 코드(.next폴더) 까지
push후 ec2에서 pull받도록 한다
=> 이것도 github 업로드 용량이 100mb이하라 실패 가능..
2. memory swap
메모리가 1GB라는 물리적인 한계지만 이 부족한 부분을 디스크를 대신 사용하도록 설정함으로써 해결 -> 이를 메모리 스왑! 이라고 합니다.
sudo dd if=/dev/zero of=/mnt/swapfile bs=1M count=2048
sudo mkswap /mnt/swapfile
sudo swapon /mnt/swapfile위 명령어 수행후 아래 명령어 수행하면 swap memory에 2GB 잡힌 걸 확인할 수 있습니다.
> free -h
이렇게 하면 스왑 메모리가 잡히고 빌드 문제가 해결 될 수 있는데 이런 가상 메모리(스왑 메모리)를 쓰면 퍼포먼스 이슈가 생길 수 있으므로 임시 방편으로 사용하라고 권장합니다. (참고 : https://progdev.tistory.com/26)
2. 더 높은 ec2 사용
자원이 안좋으면 스케일업.. 비용이 올라가지만 사실 가장 확실한 방법인 것 같다...기존 인스턴스를 지우고 새로 생성 해준다.