AWS EC2를 사용하다가 보면 알 수 없는 이유로 서버에 접속이 불가능 해지는 경우가 종종 있다.
나의 경우는 지금까지 두가지 케이스를 경험했는데,
1. public key 가 변조되어 접속할 수 없음.
2. port 22가 닫혀있음.
잘 사용해왔고, 정상접근이 어제까지만 해도 가능했던 서버였는데 갑자기 이런 경우가 발생할 수 있다.
접근권한을 잃게 된 서버에 대해서는 AWS에서 해결방법이 딱히 없다.
아마 free-tier나 고객지원 서비스를 사용하지 않는 경우에는 그런 것 같다. 나의 경우에는 현재 free-tier를 사용하고 있기 때문에, 내가 가이드를 읽고 문제 해결을 하였다.
1번의 경우는 해킹으로 의심되는 사항으로 나의 ssh key가 변조되어 서버 접근권한을 잃은 경우였다. 그때도 2번의 해결방법과 비슷하게 서버를 복구하였다. 오늘은 2번의 경우를 해결하는 방법을 서술할 것이다.
원인 (불명확)
일단 이번의 장애원인은 정확하게 잘 모르겠다. ssh key가 변조되지 않은 경우이며 22번 포트에 접근할 수 없기 때문에 서버가 죽어서 장애가 발생한 것으로 추정된다. (정확한 에러 원인은 aws에서 확인해주지 않는 이상 모를 것 같다. 알게 된다면 해당 포스트를 업데이트하도록 하겠다.)
ssh를 하였을 때에는 다음과 같은 에러를 보게 되었다.
ssh: connect to host **** port 22: Connection refused
22번 포트를 명시적으로 닫지 않는 이상 위와 같은 에러메세지는 보기 힘들 것이다.
서버에 직접 접근하여 에러 로그를 확인할 수는 없으니, AWS 콘솔에 로그인하여 system log를 확인한다.
로그를 확인하는 방법 👇🏻
AWS Console -> Instances -> (보고자하는 instance에서 우클릭) -> Instance Setting -> Get System Log
명시적으로 에러로그를 확인할 수 있다면, 그리고 해결책이 제시되는 경우라면 아래와 같이 서버를 새로 띄우는 번거로운 작업을 하지 않아도 된다. 하지만 나의 경우에는 System Log가 서버 복구를 하는 것에 전혀 도움이 되지 않았기에 아래의 방법으로 서버를 살렸다.
해결방법
간단하게 설명하자면, 새로운 instance를 띄우고 그 instance에 예전 volume을 붙여서 필요한 파일을 새 instance로 복사하는 작업을 할 것이다. ssh key를 복구할 수 없는 경우의 복구방법과는 조금 다르다.
1. 복구하고자 하는 서버 instance를 중지한다. (Instances > Actions > Instance State > Stop)
아래의 서버 정보를 저장하는 것을 추천한다.
- 서버스펙
- IAM Role
- Subnet Id
2. 복구하고자 하는 서버의 volume을 detach 한다. (Elastic Block Storage > Volumes > Actions > Detach Volume)
3. 이전 서버와 동일한 스펙의 새로운 instance를 시작한다. (Instances > Launch Instance)
- 새로운 서버를 띄울 때, 새로운 ssh private key를 생성한다.
- 기존의 키를 사용해도 상관은 없지만 (떼어낸 volume에서 ssh key파일을 복사하고 권한을 수정해주는 작업을 추가적으로 해야 한다), 나는 번거로운 작업을 생략하고 싶어서 그냥 새로 생성했다.
4. 새로운 instance에 detach 해온 volume을 붙인다.
- mount point: /dev/sdf
- root device인 /dev/xvda에는 직접 mount 되지 않는다. 이유는 새로 생성한 instance가 이미 새로운 volume으로 해당 경로를 사용 중이기 때문이다.
5. 현재 /dev/sdf 라는 경로에 붙어있는 volume을 현재 실행 중인 instance에 mount 한다.
- lsblk ( 현재 파일시스템의 파티셔닝을 확인할 수 있는 명령어)
- volume을 mount할 임시 폴더를 생성한다.
- 방금 생성한 임시 폴더에 volume을 mount 한다
sudo mkdir /mnt/tempvol
sudo mount /dev/xvdf1 /mnt/tempvol // amazon linux를 사용하고 있어서 해당 명령어 사용함
6. 필요한 파일들을 /mnt/tempvol 에서 새로운 instance volume으로 가져온다.
7. 언마운트해준다.
sudo umount /mnt/tempvol // unmount
8. 예전 서버의 volume을 현재 서버에서 detach 시킨다. (Elastic Block Storage > Volumes > Actions > Detach Volume)
새로운 instance에 이전에 필요한 파일들을 다 가져온 상태로 서버 이전 작업은 마무리되었다.
이제 추가적인 작업들을 본격적으로 해야한다.해당 서버의 용도에 맞게 이전에 사용하고 있었던 외부 연동 서비스, 배포 설정, 등과 같이 서버 이전에 영향을 받을 만한 설정들을 조금씩 수정해야 한다.
EC2를 사용하면서 느낀점은, 쉽게 가벼운 서버를 사용할 수 있어서 좋지만, 예기치 못한 에러 발생에 대한 지원은 잘 되지 못하는 것 같다. (아무래도 free-tier니까). 사용자가 조금씩 노하우가 쌓여가도록 도와주는 친절한 서비스인 것 같다. 😂🔫