지난 3월 대학생 시간표 도우미 프로젝트(한표)에 자동배포를 구현해보고 싶은 마음이 들었다. 이번 글에서는 처음 배워보는 다양한 기술(Travis-CI, AWS CodeDeploy 등)을 이용해 자동 배포를 적용하면서 겪었던 현상에 대해서 이야기를 하고자 한다.
아래 블로그를 참조해 구현을 하였다.
Travis-CI-AWS-CodeDeploy-Docker로 배포 자동화 및 무중단 배포 환경 구축하기 1
Travis-CI-AWS-CodeDeploy-Docker로 배포 자동화 및 무중단 배포 환경 구축하기 2
EC2 Micro를 통한 배포
램 1GB의 프리티어로 제공해주는 EC2 Micro는 서버를 열거나 빌드할 시 과부하가 오는 현상이 있었다. 이 때문에 계속적으로 원인을 찾다가 AWS CodeDeploy Agent의 Log를 확인하게 되었고 램 부족 현상이 발생한 것을 알게 되었다.
Micro에서는... 작은 Node Server조차 띄우지 못하다니... 충격적이었다.
이는 SWAP Memory를 지정해 해결했다.
Swap Memory란?
Swap Memory란 자원의 문제로 인해 램이 부족할 경우 HDD의 일정 공간을 마치 RAM처럼 사용하게 해주는 기술이다.
여러 블로그 글을 보면서 느낀 점은 메모리가 부득이하게 부족한 경우를 제외하고는 swap 자체를 쓰지 않는 것을 권장한다고 한다. 성능상으로 swap in, swap out이 성능을 무너뜨릴 수 있기 때문이다.
Swap Memory 적용
- dd 명령어를 통해 Swap Memory를 할당
sudo dd if=/dev/zero of=/swapfile bs=128M count=16- 스왑 파일에 대한 읽기 / 쓰기 권한 변경
sudo chmod 600 /swapfile- 리눅스 스왑 영역 설정
sudo mkswap /swapfile- 스왑 공간에 스왑 파일 추가
sudo swapon /swapfile- 절차 성공 확인
sudo swapon -s/etc/fstab/파일을 편집하여 스왑 파일 활성화
sudo vi /etc/fstab- 파일 끝에 다음 줄 추가 후 저장
/swapfile swap swap defaults 0 0회고
아무래도 Micro 인스턴스에서 Docker에 Server 2개를 돌리기에는 무리가 있다고 생각했다. 하지만 비용적인 측면에서 고려해봤을 때 사용자가 많이 없다면 Swap Memory를 통해 해결 후 충분히 개발용 서버로 사용 가능하다고 판단했다. 만약 Production으로 나가게 될 경우를 고려한다면 Scail-up을 통해 일정 기간(예비 수강 신청 기간, 수강 신청 기간)을 고려해 서버의 성능을 일시적으로 올릴 수 있다고 생각했다.
사실 지금껏 다른 외부 기관에서 준 Credit을 사용해 남부럽지 않게 서버를 사용해왔다. 금전적인 측면에 있어서 어쩔 수 없어 해당 인스턴스를 활용할 수 있는 방법을 찾아봤다. 나름 재밌던 경험이었고 얻어가는 점도 많았던 것 같다.
참조
