[Dev] 23.05.01. EC2 인스턴스는 왜 자꾸 터지는가? (feat. SWAP)
지난 밤, 성공적으로 https를 위한 인증서를 발급하고 설정하여 도메인에 https 접속이 되는 것을 확인하고 서버를 그대로 돌려둔 채로 잠들었다. 그런데 아침에 일어나서 도메인에 접근하려고 했더니 장렬히 실패하는 모습을 보게 되었다. EC2 console에 로그인해서 살펴보니 위 이미지에서 처럼 상태 검사에 실패한 상황을 마주했다. 안그래도 다음에 하고 싶었던 작업이 바로 이와 관련된 것이었는데, 마침 게시글을 작성하기 위한 소스를 친절하게 직접 터져주는 것으로 제공해주었다.
이전에도 비슷하게 CPU 사용률이 치솟아서 문제가 있었던 경우가 몇 번 있었다. 인스턴스의 모니터링 항목에서 보면 CPU 사용률이 치솟았고, 그때를 기점으로 상태 검사에 실패했다고 나와있다. 게다가 인스턴스에 접근하려고 하면 Connection timed out 메시지만을 보게 된다.
이때는 인스턴스 재시작으로는 해결이 안된다. 인스턴스를 중지한 뒤, 다시 시작하면 다시 인스턴스에 접근할 수 있다. 중지는 상대적으로 시간이 조금 더 걸리는 기분이다. 문제는 이런 상황을 계속해서 반복해왔고, 그대로 두면 계속해서 반복적으로 일어날 것이라는 점이다. 인스턴스의 IP와 연결된 도메인을 계속 열어두고 싶은데, 상황이 반복되는 것은 안될 일이다.
SWAP 메모리 설정
구글 검색창에 "ec2 프리티어(free tier) cpu"를 검색하면 볼 수 있는 많은 블로그에서 비슷한 유형의 문제를 접한 사람들을 볼 수 있었고, 또한 이들은 공통적으로 swap 메모리를 설정하여 문제를 해결하려는 시도를 한다.
Swap. 이 친구를 가장 처음 본 것은 EC2 인스턴스 내에서 프로젝트를 clone하여, 그 자리에서 build 했을 때였다. 그때도 CPU 사용률이 100%로 치솟아서 build가 중단되지도 않고, 인스턴스에는 접근조차 할 수 없었다. 그때의 문제의 원인을 파악하기 위해 검색했을 때 발견했던 것이 swap이었다.
Swap 메모리 설정과 관련해서 AWS 지식 센터에서는 EC2 인스턴스에서 swap 메모리를 할당하는 방법을 설명하고 있다.1
참고: 휘발성 스토리지 인스턴스 스토어 볼륨에만 스왑 공간을 만드는 것이 가장 좋습니다.
Note: It's a best practice to create swap space only on ephemeral storage instance store volumes.문제는 설명 중간에 위와 같이 언급하고 있다는 점이다. 이것이 왜 문제가 되는가 하면, 프리티어로 사용하고 있는 t2.micro 는 인스턴스 볼륨을 생성할 수 없기 때문이다.
실제로 인스턴스를 생성할 때 가상 서버 유형을 선택해서 확인해보면, 프리티어로 사용할 수 있는 t2.micro의 경우에는 인스턴스 스토어 볼륨이 없지만 프리티어로 사용할 수 없는 d2.xlarge의 경우에는 있는 것을 알 수 있다. 이 인스턴스 스토어가 바로 메시지에서 언급하고 있는 휘발성 스토리지이다. 이런 인스턴스 스토어는 EBS처럼 별도로 추가하여 붙이는 것은 불가능하고, 인스턴스를 생성할 때에 추가하는 것이라고 한다.2
하지만 필자는 지금 현재의 상태로는 문제를 타개할 방법이 swap 메모리를 설정하는 방법 뿐이고, 제한된 상황 속에서의 연습이라고 생각하고 현 인스턴스에 그대로 메모리를 설정해보려고 한다.
Swap space 계산 3 4
AWS 지식센터에서는 swap space를 계산할 때 참조할 페이지 두 개를 소개한다. 해당 페이지에서는 swap이 무엇인지에 관해서도 아래와 같이 간단히 언급하고 있다.
리눅스는 물리적 RAM을 'pages'라고 하는 메모리의 덩어리로 나눈다. Swapping은 메모리 page가 하드 디스크에 있는 'swap space'라고 하는 미리 구성된 공간에 복사되어 해당 메모리 page를 해방시키는 프로세스이다. 물리적인 메모리와 swap space의 사이즈 총 합이 바로 사용 가능한 가상 메모리의 크기이다.
참고한 첫 번째 페이지에서는 다음과 같이 언급하고 있다.
- 오래된 Unix type OS의 경우에는 물리적인 메모리의 2~3배의 swap space를 필요로 한다.
- 근래의 기기의 경우는 그렇게 많이 필요로 하지 않지만, 다음의 rule을 따른다.
- Desktop system에는 시스템 메모리의 두 배에 해당하는 swap space를 사용한다.
- Server에 대해서는 물리적인 메모리의 절반 가량으로, 사용가능한 swap의 크기보다 작다.
- 오래된 desktop(128MB)에 대해서는 가능한 많이 사용하되, 최대 1GB까지 가능하다.
참고한 두 번째 페이지에서도 RAM 크기의 최대 두 배라고 언급하면서 표까지 제시하고 있다.
현재 필자가 AWS 프리티어 계정으로 사용하고 있는 t2.micro의 RAM은 1GB이므로, swap space로 2GB를 할당해주고 싶다.
Swap file 생성
AWS 지식센터에 더하여 한 블로그를 함께 참고했다.5
# 메모리 크기 조회
free명령어 'free'를 사용하면 메모리를 조회할 수 있다. EC2 인스턴스에 접속하여 명령어를 사용해보면 위와 같이 swap에 0이 할당되어 있는 것을 볼 수 있다. 이제부터 AWS 지식센터에서 설명한 방법을 따라가고자 한다.
## dd 명령어로 swap file 생성
sudo dd if=/dev/zero of=/swapfile bs=128M count=16- if : 지정한 file을 입력 대상으로 설정한다.
- of : 지정한 file을 출력 대상으로 설정한다.
- bs : block size의 줄임말이며, 단위는 byte이다. 즉 128MB block 16개이므로, 총 2GB를 swap space로 설정하고자 하는 것이다. 지정한 block size는 인스턴스에서 사용 가능한 메모리의 크기보다 작아야하며, count 값과 함께 잘 조정하여 swap space의 크기를 결정한다.
# swap file의 권한 수정
sudo chmod 600 /swapfile생성한 swap file의 권한을 수정해준다. 600은 나에게만 읽고 쓰는 권한을 주겠다는 의미이다. 읽기(4)/쓰기(2)/실행(1) 에 각 자리는 나/그룹/전체 에 해당한다. 나를 제외한 그룹과 전체에는 어떤 권한도 주지 않게 된다.
# linux swap 영역 설정
sudo mkswap /swapfile생성한 swap file을 swap 영역으로 설정해준다.
# swap space에 swap file 추가
sudo swapon /swapfileSwap space에 swap file을 추가하여, 즉시 사용할 수 있도록 한다.
# Procedure(절차) 가 성공적인지 확인
sudo swapon -s현재까지의 절차가 성공적인지 확인하는 단계이다. 정상적으로 수행되었다면 swap file이 나타나면서 그 size와 현재 사용량에 대한 정보를 확인할 수 있다. 현재 단계까지만 설정하여도 swap이 정상적으로 작동하지만, 재부팅 이후에는 swap이 사라진다고 한다. 따라서 다음의 작업을 이어서 해준다.
# vi editor로 file을 수정
sudo vi /etc/fstab
# /home/ubuntu 위치에서 한다면
sudo vi ../../etc/fstab
마지막 줄에 추가
/swapfile swap swap defaults 0 0/etc/fstab을 vi editor로 열어 마지막 줄에 추가해주면 재부팅 이후에도 swap file이 정상적으로 mount 되어 사용할 수 있게 된다고 한다.
free -h마지막으로 다시 free 명령어로 확인해보면 처음에는 0이었던 swap이 2.0GB가 되어 있음을 확인할 수 있다.
만약에 /etc/fstab 을 수정하지 않는다면 어떻게 되는지 알고 싶은가? 필자는 궁금해서 해봤다. 인스턴스를 재부팅하게 되면 swap file이 사라지고, 시작하기 전과 동일하게 swap total이 0이 되는 것을 보게 될 것이다. 오래 걸리는 것은 아니니까 궁금하면 해보는 것도 좋겠다.