AWS EC2 인스턴스를 사용하다 보면 아래와 같은 상황이 발생할 수 있습니다.
-
복잡한 환경설정을 구성하다가 패키지가 꼬여버린 상황
-
명령어를 잘못 입력하여 시스템의 일부가 망가진 상황
-
현재 상황상 급하게 특정 시점의 서버 환경으로 되돌려야하는 상황
이외에도 개발을 진행하다 보면 다양한 상황이 발생할 수 있습니다.
기존의 온프레미스(On-Premise) 환경에서는 위와 같은 상황에 대처하기가 매우 힘들었습니다.
시간과 인력 및 비용이 굉장히 많이 드는 작업이었습니다.
하지만 클라우드 환경이 보급되면서 위와 같은 상황 대처를 할 수 있는 편리한 도구들을 제공하기 시작했습니다.
AWS 플랫폼은 기존에 서버 개발자가 모두 수작업으로 해야 했던 많은 일들을 간편하게 제어할 수 있는 도구들을 제공하는 것입니다.
대표적인 클라우드 컴퓨팅 플랫폼인 AWS EC2에서는 서버를 하나의 인스턴스로 구분짓습니다.
이 인스턴스는 우리가 알고 있는 서버 컴퓨터라고 생각할 수 있습니다.
따라서 이 서버에는 하드 디스크가 존재하고 그 안에 운영체제가 설치되어 있습니다.
이를 좀더 쉽게 표현하면 아래와 같습니다.
-
서버 컴퓨터 → AWS EC2 인스턴스
-
하드 디스크 → EC2의 Elastic Block Store
-
운영체제 → Amazon Machine Image(Windows 및 Linux 지원)
앞서 설명한 여러 상황들로 인해 EC2 인스턴스가 사용이 불가한 상황이 되었을 때 이를 복원하는 방법을 알아봅니다.
스냅샷을 복원하여 기존의 EC2 인스턴스에 적용하기
스냅샷은 EC2의 하드 디스크라고 할 수 있는 Elastic Block Store를 특정 시점 그대로 백업한 것입니다.
이 스냅샷이 존재해야 특정 시점으로 EC2 인스턴스를 되돌릴 수 있습니다.
AWS 콘솔 > EC2를 선택하고 왼쪽 탭에서 스냅샷 탭을 선택합니다
복원하려는 스냅샷을 선택한 후 볼륨 생성을 누릅니다.
스냅샷을 볼륨으로 생성해야 EC2 인스턴스에 적용할 수 있습니다.
생성을 누르면 볼륨이 만들어집니다. 이때 생성되는 볼륨의 아이디를 잘 기억해놓습니다.
vol-0d4779e1328a5b399
루트 디바이스
스냅샷을 적용하려는 EC2 인스턴스를 먼저 중지시킵니다.
EC2 인스턴스가 망가져서 SSH 접속조차 안되는 경우 루트 디바이스를 아예 새로운 볼륨으로 바꿔야 합니다.
루트 디바이스를 다른 볼륨으로 바꾸려면 EC2 인스턴스를 중지시켜야 합니다.
루트 디바이스에 새로운 볼륨을 적용할 때 위의 네모박스 안에 있는 루트 디바이스 이름이 중요합니다.
해당 루트 디바이스 이름으로 적용해야 새로운 볼륨이 루트 볼륨이 될 수 있습니다.
인스턴스를 중지했으면 이제 망가진 루트 디바이스 볼륨을 분리할 차례입니다.
마찬가지로 루트 볼륨을 분리하기 위해서는 EC2 인스턴스가 중지상태여야 합니다.
위의 EBS ID를 눌러서 볼륨탭으로 넘어갑니다.
볼륨탭에서 작업 > 볼륨 분리를 선택합니다.
위에서 생성한 스냅샷으로 -> 볼륨 생성 (Commit SnapShot_20200911_Restore)
복구한 볼륨 생성 완료
이제 연결할 새로운 볼륨 (새로 복원된 볼륨) 을 선택하고 작업 > 볼륨 연결을 누릅니다.
인스턴스는 아까 중지한 인스턴스를 선택합니다.
디바이스에는 아까전에 확인한 루트 디바이스 이름을 적어줍니다. (/dev/xvda 계속 바뀜)
루트 디바이스 이름은 각각 인스턴스마다 다릅니다.
반드시 기억했다가 적어주어야 루트 볼륨으로 인식됩니다.
연결이 끝났으면 이제 EC2 인스턴스를 다시 시작하면 됩니다. (성공)
출처: https://show-me-the-money.tistory.com/63?category=666205 [개발자, Trend를 파헤치다.]
'[AWS]' 카테고리의 다른 글
쿠버네티스란? (0) | 2020.09.16 |
---|---|
AWS EKS - Create Kubernetes cluster on Amazon EKS | the easy way (0) | 2020.09.16 |
천만 사용자를 위한 AWS 클라우드 아키텍처 진화하기 (0) | 2020.09.11 |
지원 종료 (End of Support) 된 소프트웨어의 클라우드 이전 방안 (0) | 2020.09.08 |
API 호출 처리 흐름 (0) | 2020.09.04 |
댓글