AWS EC2를 사용하다 보면 인스턴스의 성능을 최적화하거나 비용을 절감하기 위해 인스턴스 유형을 변경하는 경우가 많습니다. 하지만 이번 경험은 제게 인스턴스 유형 변경 시 CPU 아키텍처가 바뀌면 심각한 문제가 발생할 수 있다는 점을 상기시켜 주었습니다.
문제 상황
기존 EC2 인스턴스는 r5a.large (AMD 기반) 유형을 사용 중이었습니다. 성능 개선을 위해 r6i.large (Intel 기반)으로 인스턴스 유형을 변경했습니다. 변경 후 인스턴스를 시작했는데, 예상치 못한 문제가 발생했습니다:
- SSH 접근 불가: 인스턴스가 시작되었지만 SSH로 접속이 불가능했습니다.
- Emergency Mode: AWS 직렬 콘솔(Serial Console)을 통해 접속했을 때 인스턴스가 Emergency Mode로 부팅되어 있었습니다.
시도했던 해결 방법
문제를 해결하기 위해 여러 방법을 시도했지만, 결국 실패하고 다른 접근 방식을 선택해야 했습니다.
1. Emergency Mode에서 로그 확인
journalctl -xb부팅 중 네트워크 관련 오류 및 sshd 서비스가 제대로 실행되지 않았다는 점을 확인했습니다.
2. 네트워크 및 SSH 복구
Emergency Mode에서 네트워크와 SSH를 복구하려고 시도했습니다:
ip link set eth0 up dhclient eth0 systemctl start sshd그러나 네트워크와 SSH 서비스가 완전히 복구되지 않았습니다.
3. 파일 시스템 및 부트로더 복구
다음 명령을 통해 부트로더와 커널을 복구하려고 했습니다:
sudo yum reinstall kernel sudo dracut -f sudo grub2-mkconfig -o /boot/grub2/grub.cfg sudo grub2-install /dev/xvda하지만 여전히 문제가 해결되지 않았습니다.
4. 볼륨 교체 및 AMI 복구
- 볼륨 교체: 문제의 루트 볼륨을 스냅샷으로 생성한 뒤, 새로 생성한 인스턴스에 연결하여 복구를 시도.
- AMI 복구: 기존 볼륨을 기반으로 새로운 AMI를 생성하고 다른 인스턴스에서 실행.
여러 시도에도 불구하고 인스턴스는 Emergency Mode를 벗어나지 못했습니다.
최종 해결 방법
모든 복구 시도가 실패하자, 다음과 같은 방법으로 문제를 해결했습니다:
- 애플리케이션 복제:
- 문제의 애플리케이션과 데이터를 로컬 환경으로 복제.
- 새로운 서버 생성:
- 새로운 EC2 인스턴스를 생성하고 애플리케이션을 재배포.
- 서비스 재개:
- 새 인스턴스에서 정상적으로 서비스를 운영할 수 있었습니다.
결론 및 교훈
이번 경험을 통해 두 가지 중요한 교훈을 얻었습니다:
1. CPU 아키텍처 변경 시 주의
- AMD에서 Intel로, 또는 ARM(r6g)에서 Intel(r6i)로 CPU 아키텍처가 변경될 때 부트가 실패할 가능성이 높습니다.
- 특히 부트로더나 커널이 해당 아키텍처를 지원하지 않는 경우 문제가 발생합니다.
2. AMI를 미리 생성하자
- 인스턴스 유형 변경 전에는 반드시 AMI를 생성해두는 것이 중요합니다.
- AMI는 문제 발생 시 빠르게 복구할 수 있는 가장 안전한 방법입니다.