[AWS] AWS lightsail ssh 접속 불가 문제

18일부터 23일까지 서비스가 터졌다 흑흑

 

2023년 9월 18일 새벽 2시경부터 ssh 접속이 불가능한 문제가 발생했다.

 

OS 업데이트 중 실패하여 발생한 문제로 파악하고,

매일 0시에 스냅샷을 백업하게 설정해 두었기 때문에 크게 생각하지 않고 복구 작업에 들어갔다.

 

그러나 17일, 16일... 12일까지 저장된 모든 스냅샷을 이용해 새 인스턴스를 만들었지만 

전부 ssh 접속이 불가능했다.

 

문제는 ssh 접속뿐만 아니라 대부분의 서비스(apache, mysql 등)이 동작하지 않고 있었다.

 

부팅 자체가 실패했는가? 에 대해서는 서버 모니터링 시스템에선 정상적으로 트래픽이 들어오고 있었기 떄문에

부팅은 성공했지만 일부 서비스 구성에 실패한 것으로 보인다.

 

서버 복구를 위해 어떤 일들을 했는지 정리해보고 같은 문제를 겪고 있는 사람들에게 도움이 되었으면 해 작성해 본다.

 

1. sfw 방화벽 해제

nmap -Pn [YOUR_IP] -p 22

포트 스캐닝을 위해 위 명령어를 사용한 결과 22, 80, 3306 등 기존에 사용중인 포트들이 모두 filtered 로 되어 있었다.

 

방화벽에 장애가 생긴 것으로 판단하고, OS단의 방화벽을 모두 해제하고 lightsail panel의 firewall도 모두 해제해 줘 보았다.

 

https://repost.aws/ko/knowledge-center/lightsail-resolve-ssh-console-errors

Lightsail 브라우저 기반 SSH 콘솔 오류 해결

AWS 가이드에 나온 것 처럼 아래 스크립트를 Startup script 에 추가했다.

 

sudo ufw disable
sudo iptables -F
sudo mv /etc/hosts.deny /etc/hosts.deny_backup
sudo touch /etc/hosts.deny
sudo systemctl enable sshd
sudo systemctl restart sshd

 

그러나 여전히 ssh를 포함한 모든 포트가 filtered 로 표시되었다.

 

2. AWS 기술 지원

 

https://us-east-1.console.aws.amazon.com/support/plans/home#/

https://us-east-1.console.aws.amazon.com/support/plans/home#/

 

기술 지원을 받으려면 Support plan에 가입해야 한다.

 

이때까지만 해도 큰 문제는 아닐 것으로 판단해 가장 저렴한 Developer Plan으로 가입해 기술 지원을 요청했다.

 

3. 하이브리드 활성화 및 플릿 매니저로 ssh 접속

https://repost.aws/ko/knowledge-center/add-lightsail-to-systems-manager

Systems Manager에 Lightsail 인스턴스 추가

 

하이브리드 활성화 후 플릿 매니저로 라이트세일 인스턴스 콘솔에 접근할 수 있다고 한다.

 

그러나 아무리 시도해도 플릿 매니저에 인스턴스가 나타나지 않았다.

(Startup script가 정상적으로 동작하지 않는 듯 하다)

 

4. 원격 지원

 

모든 방법이 통하지 않아 감사하게도 1회성 원격 지원을 해 주셨다.

 

1~3번 방법을 다시 진행하고, 이후 lightsail 인스턴스를 ec2로 내보내서 다시 인스턴스를 생성했다.

 

그 후 AWS 내부 도구를 사용해 문제의 인스턴스를 진단한 결과, 

AWS 인스턴스가 사용하는 서비스인 cloud-init 서비스 구동에 문제가 생긴 것을 발견했다.

cloud-init[896]: IsADirectoryError: [Errno 21] Is a directory: '/var/lib/cloud/instance'
cloud-init[896]: ------------------------------------------------------------
[FAILED] Failed to start Initial cloud-init job (metadata service crawler).
See 'systemctl status cloud-init.service' for details.

 

인스턴스 복구 및 서비스 정상화는 어렵다고 판단되었다.

 

5. 볼륨 분리 및 정상 인스턴스에 마운트

 

물론 인스턴스 자체를 살릴 수 있다면 좋겠지만, 그것은 불가능해졌으므로 데이터라도 살리기로 했다.

 

ec2로 내보낸 스냅샷으로 새로운 인스턴스(1번)를 만들고,

또 하나의 새로운 인스턴스(2번)를 만든다.

 

그리고 1번 인스턴스에서 볼륨을 분리한 다음, 그 볼륨을 2번 인스턴스에 추가한다.

 

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-using-volumes.html

Make an Amazon EBS volume available for use on Linux - Amazon Elastic Compute Cloud

 

위 가이드를 참조해 1번 인스턴스의 볼륨을 2번 인스턴스에서 접근할 수 있게 되면

sftp 를 이용해 필요한 1번 인스턴스의 데이터를 뽑아올 수 있게 된다.

 

결국 데이터만 뽑아온 후 서버는 다시 구축하고, 다시 그 데이터를 밀어넣는 식으로 서비스를 복구할 수 있었다.

 

의문

아무리 시스템이 심각하게 손상되었다고 하더라도,

그 시점 이전의 스냅샷으로 새로운 인스턴스를 만든다면 문제가 없어야 하는 것 아닌가 라는 의문이 가시질 않는다.

 

만약 그 시점 이전에도 문제가 있었다면, 일부 서비스에 문제가 발생하거나 재부팅할 경우 시스템이 마찬가지로 정상 부팅 되지 말아야 한다.

 

9월 18일 2시가 문제 발생 시점이므로,

9월 17일, 16일, 15일 ... 스냅샷은 당연하게도 정상적으로 부팅 가능해야 한다.

 

이에 다시 한번 문의하여 내가 알고 있는 스냅샷의 개념이 틀린 것인지를 확인해보았다.

 

다만 추가적으로, 문제가 발생하기 전인 9월 18일 02:00 KST 이전에 생성된 Snapshot을 통해서도 정상적인 복구가 불가능한 부분에 대하여 재차 문의를 주셨습니다. 또한 Snapshot의 작동 방식에 대하여 확인을 요청주셨습니다.
**님의 공유해드린 내용과 같이 LightSail에서 Snapshot은 해당 LightSail 인스턴스에 대한 전체 AMI을 생성하며, 이를 통해서 같은 크기 또는 더 큰 크기의 LightSail 인스턴스를 생성할 수 있습니다. 
Snapshot을 생성하게 되면 생성 시점의 인스턴스에 존재하는 모든 데이터를 저장하며 이를 통해 해당 새로 생성된 인스턴스는 Snapshot을 생성한 시점의 인스턴스가 가진 OS 설정, 볼륨 데이터 등을 모두 그대로 따르게 되어 있습니다. 

이전에 Chime meeting을 통해서 **님과 같이 9월 18일 이전에 생성된 Snapshot을 사용하여, 인스턴스를 생성해보았으며 해당 인스턴스의 Console 로그를 확인해본결과 아래와 같은 메시지를 발견할 수 있었습니다. 
======
[+] 공유드리는 에러메시지

cloud-init[896]: IsADirectoryError: [Errno 21] Is a directory: '/var/lib/cloud/instance'
cloud-init[896]: ------------------------------------------------------------
[FAILED] Failed to start Initial cloud-init job (metadata service crawler).
See 'systemctl status cloud-init.service' for details.


======

위는 Cloud-init과 관련된 Error 메시지로 여러한 이유 (* python 관련 의존성 패키지를 이용한 Cloud-init 작업 실패등) 등으로 발생할 수 있습니다. 이와 같이 9월 18일 이전에 생성된 스냅샷을 통해서도 생성한 인스턴스에서 
위와 같은 에러가 발생하는 경우, 해당 스냅샷이 생성된 시점의 인스턴스에 이미 관련한 부분에 대한 문제가 진행된 상태였는지 의심해 볼 수 있습니다. 

저 또한 동일한 ubuntu OS를 이용하는 lightsail Instance를 생성하여 특정 시점을 기준으로 스냅샷을 생성 후 인스턴스를 손상 시키는 작업을 진행했습니다. 이러한 과정 후 이전에 생성한 스냅샷으로 정상적으로 인스턴스가 복구되는지
확인해 보았으며, 결론적으로 스냅샷을 통해 문제가 발생하기 이전의 시점으로 정상적으로 복구가 가능했습니다. 또한 추가적으로 AWS 내부에서 리포트된 LightSail 서비스 단에서 버그가 있는지 조사해보았으나, 특이 사항을 발견할 수 없었습니다. 

AWS 서포트 엔지니어는 고객님의 OS단에 대한 접근 가능한 어떠한 권한도 없기 때문에 이러한 상황에 있어서 서포트에 제한이 존재할 수 있는 점 진심으로 양해 부탁드리며, 현재로서는 9월 18일 이전과 이후에 해당 인스턴스에 대한 
어떠한 작업이 있었는지 확인할 수 없는 상황에서 스냅샷을 사용하여 정상적으로 복구하지 못하는 이유로 위와 같은 부분이 의심 되어집니다. 

보내드린 내용이 도움이 되셨기를 바라며, 케이스 지원에 있어서 여러 제약이 있었음에도 불구하고 여러 정보를 공유해주시고 양해해주셔서 진심으로 감사드립니다. 
즐거운 연휴 보내시기 바라며 관련하여 추가 질문이 있으신 경우 언제든지 알려주세요. 

최선을 다해서 지원해드리겠습니다.

감사합니다.

 

정리해보면 고객의 인스턴스 데이터를 직접 들여다볼 수는 없기 때문에 확실한 원인은 진단 불가능하다는 것이고,

의심가는 부분은 스냅샷 생성 시점 이전에 이미 문제가 발생했다는 것이다.

 

AWS 내부적으로 스냅샷 생성 후 OS를 손상시킨 후, 해당 스냅샷으로 복구했을 경우 정상 복구되었다고 알려주신 것을 보면 유력한 원인이기는 하다.

 

다만 이미 OS/특정 서비스가 손상된 9월 13일 0시~ 18일 0시에는 어떻게 정상적으로 서비스 되었었는지,

심지어는 재부팅해도 정상 작동 되었었는지는 지금까지도 너무 궁금하지만 알 방법은 없다.

 

정리

라이트세일 서비스에 실패가 발생했다면 먼저 위의 설명을 따라해 보자.

 

그래도 안된다면 'ec2 내보내기-> 볼륨 추출 및 정상 인스턴스에 부착-> 데이터 추출 및 신규 서버 세팅'이 사용자가 할 수 있는 최선의 방법인 것 같다.

 

만약 기술 지원을 받으려면 Support plan에서 최소 '비즈니스 플랜'을 선택하는 것을 권장한다.

 

물론 $100로 비싸긴 하지만, 개발자 플랜은 'AWS 영업 시간 내 + 12시간 이내' 답변이라,

회사를 다니는 사람의 경우 질문/답변 타이밍이 맞지 않아 커뮤니케이션 딜레이가 너무 큰 것 같다...