AWS EC2 인스턴스 종류 바꾸기 (업그레이드/다운그레이드)

웹서버로 사용하는 서버의 부하가 생각보다 낮아서 t2.small을 t2.micro로 변경하는 작업을 했다.
개념적으로 생각해보면, 성능이 좋은 컴퓨터에서 하드 2개를 떼어서 성능이 좀 더 낮은 컴퓨터에 옮겨달아 그대로 사용하는 방법이다.
이것이 가능하려면 인스턴스간에 호환이 되는지 사전에 꼭 확인해봐야 한다. 호환이 안된다면 인스턴스를 새로 생성해서 scp 명령어를 이용해 필요한 파일들을 서버간에 전송하는 삽질이 필요하다. 물론 기본으로 깔린 프로그램이 아닌 것들은 전부 다 새로 깔고 세팅도 새로 해줘야 한다. 새 컴퓨터를 사서 단순히 하드를 옮겨다는 것이 불가능하고, 새로 세팅을 전부 해주고 파일만 옮겨야 하는 상황이 되는 것이다.

• 가상화 유형. Linux AMI는 PV(반가상화) 또는 HVM(하드웨어 가상 머신)의 두 가지 유형의 가상화를 사용합니다. PV AMI에서 시작한 인스턴스를 HVM 전용의 인스턴스 유형으로 크기 조정할 수 없습니다. 자세한 내용은 Linux AMI 가상화 유형 단원을 참조하십시오.
• 네트워크. 일부 인스턴스 유형은 EC2-Classic에서 지원되지 않으며 VPC에서 시작해야 합니다. 따라서 기본이 아닌 VPC가 아닌 한 EC2-Classic의 인스턴스를, VPC에서만 사용할 수 있는 인스턴스 유형으로 크기 조정할 수 없습니다. 자세한 내용은 VPC에서만 사용할 수 있는 인스턴스 유형 단원을 참조하십시오.
• 플랫폼. 모든 Amazon EC2 인스턴스 유형은 64비트 AMI를 지원하지만, 다음 인스턴스 유형만이 32비트 AMI를 지원합니다: t2.nano, t2.micro, t2.small,t2.medium, c3.large, t1.micro, m1.small, m1.medium, c1.medium. 32비트 인스턴스의 크기를 조정하는 경우는 상기 인스턴스 유형만 사용 가능합니다.

참고문서: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html

우선 간단하게 요약을 하면 다음과 같은 과정으로 진행된다.

1. 새로운 인스턴스를 생성한 뒤 멈추기
2. 기존 인스턴스를 멈추고 Elastic IP, Volume을 새 인스턴스로 옮겨달기
3. 새 인스턴스에서 volume mounting 확인하기

Create new instance

호환이 된다는 자신이 있으면 일단 새로 사용할 인스턴스를 생성한다. 당연히 기존에 사용하던 것과 같은 종류의 OS를 선택한다.
인스턴스 생성시 기본볼륨이 자동으로 생성되는데 나중에 그냥 지우면 되니 이전에 사용했던 설정 그대로 인스턴스만 바꿔서 생성 클릭클릭. (혹시 기본 인스턴스 없이 생성 가능한 방법이 있나요? 없을 것 같은데..)
Availability zone이나 아이피 대역은 같게 해줄 것!

Strip everything away from the new instance

• 기본 동작이 running으로 되어있다면 일단 인스턴스를 stop 시켜준다.
• 그 다음으로 volume을 detach 시켜서 terminate시켜버린다. 루트볼륨이라 detach 시킬때 경고창이 뜨지만 가뿐히 무시하고 과감하게 떼어내 삭제. 어차피 기존 서버에서 사용하던 볼륨들을 사용할거니까.

Strip everything away from the old instance and transfer to the new instance

이번에는 예전 인스턴스에서 모든 걸 뜯어내 벌거숭이 새 인스턴스에게 붙여줄 차례다. 여기 시작하기전에 불안하면 snapshot이라도 떠두시길… (무슨 배짱인지 모르지만 필자는 안 뜨고 그냥 진행했다.)

• Instances에서 예전 인스턴스를 일단 멈춘다. 멈춰야 떼어낼 수 있다.
• Volumes에서 예전 인스턴스에 부터있던 볼륨을 선택해 Detach volume을 실행해 떼어낸다. 떼어내기 전에 아래 정보창에서 “Attachment information”에서 디바이스명을 확인해주는 센스. 그대로 갖다붙여야 하는데 이걸 까먹으면 설정을 새로 해줘야 할수도 있다.
• 떼어낸 볼륨들을 선택해 Attach volume을 실행해 새 인스턴스에 붙여준다. Device name을 정확하게 입력한다. 필자는 이걸 틀렸는지 마운트를 새로 해줘야 했다.
• Elastic IPs로 가서 현재 사용중인 아이피를 선택하고 Disassociate address를 실행해 예전 인스턴스에서 떼어낸다.
• Associate address를 실행해 새 인스턴스에 붙여준다. 랜선을 뽑아서 새 컴퓨터에 끼우는 작업이라고 생각하면 된다.
• 붙일 걸 다 붙였으면 Instances로 가서 새 인스턴스를 Start 시켜준다.

Connect to your new instance and check mounted drives

잘 작동하나 확인할 차례다. 필자는 SSD하나, 업로드파일을 담는 HDD하나 이렇게 볼륨을 2개 붙여서 사용중이었다. 볼륨 1개만 사용한다면 이 과정이 필요 없을 듯 하다. 두근두근거리며 putty로 접속해봤다.

• ec2-user@123.123.123.123 이런 식으로 예전과 똑같이 접속하면 된다. Security group, access key, Elastic IP를 그대로 사용했으니 외부에서 접속할 때는 달라질 게 아무것도 없다. (이때 접속이 안되면 나도 몰라요….)
• lsblk라고 치니까 아래 그림처럼 xvdb 볼륨이 마운트가 안 된 걸로 뜬다.
• 혹시 드라이브가 인식이 안된건가? 덜컥 겁이 나서 sudo file -s /dev/xvdb 확인해보니 다행히 파일시스템이 읽힌다.
• 그렇다면 마운트 고고 sudo mount /dev/xvdb /hdd 이렇게 마운트 시키고 다시 lsblk 명령어로 확인. 마운트가 됐다!
• 웹브라우저로 접속해보니 mysql_connect 에러가 뜬다. sudo /etc/init.d/mysqld restart 해주니까 모든게 정상적으로 작동한다.

Comments

이렇게 작업하는데 총 7분 걸렸다. (이 포스트를 쓰는 데 시간이 훨씬 오래 걸렸다.) 이렇게 하면 되지 않을까 머릿속으로 시뮬레이션 한 뒤 처음 해본 것 치고 서버 다운타임이 정말 짧았다. 다시 하면 3분 이내에 가능할 것 같다.

남들이 보기에는 코딱지만한 t2.small에서 코딱지반토막만한 t2.micro로 간 것처럼 보이겠지만, 개인적인 용도에서 한달에 만원 이상 아낄 수 있는 전략이라 나름 의미가 있다고 본다. 서비스가 커지면 인스턴스 종류를 조절하기보단 클라우드워치로 서버 부하를 자동 모니터링하다가 스크립트로 인스턴스 개수 자체를 조절해 로드밸런싱을 할 것 같다.

앞으로 RI로 t2.micro를 1년 예약 걸어놓고, 이용자가 너무 많이 몰리는 시기에만 한시적으로 on-demand로 t2.small을 사용하려고 한다. 이게 바로 진정한 ‘클라우드’ 서비스가 아닌가 싶다. 말로만 클라우드라고 갖다붙여놓은 카x24사의 서비스를 생각하면 한숨이 절로 나온다….