[Re18특집] 재시작시 RAM 데이터를 그대로 보존? – EC2 Hibernation 기능 출시
여기서 다루는 내용
· Intro
· Hibernation의 개념
· EC2 Hibernation 동작 테스트
· Outro
Intro
안녕하십니까, GS네오텍 최준승입니다.
12월 한달간 리인벤트 2018 특집을 간단히 꾸미려고 합니다.
중요한 업데이트만 대상으로 짧은 데모를 곁들여.
당최 이번에 업데이트된게 무엇인지 직관적으로 전달하는 것이 주목적입니다.
첫빠따는 가벼운걸로 시작하겠습니다.
Amazon EC2 Now Lets you Pause and Resume Your Workloads
여러분 노트북의 전원을 끄지 않고. 바로 덮고 나중에 열었을때. 모든 작업창이 그대로 유지되었던 경험 해보셨나요?
그 동일한 로직을 EC2 서버에서 지원한다고 생각하시면 됩니다.
바로 Hibernate 기능입니다.
Hibernate 기능이 뭔데?
Hibernation 동작 흐름은 아래와 같습니다.
※ https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Hibernate.html
- 시스템이 중지되었을때. RAM에 저장된 데이터를 스토리지에 저장합니다
- 시스템을 재시작했을때. 스토리지에 저장된 데이터를 로드하여 중지전 상태로 복원합니다
즉. 시스템은 분명 재시작됐지만. 재시작하지 않은것 같은. 마치 술은 먹었지만 음주운전은 아닌. 그런.
OS에서 지원하는 일종의 Feature라고 할 수 있겠죠.
단, AWS 환경에서 해당 기능을 사용하기 위해서는 몇가지 전제조건이 필요합니다. (’18/12 기준)
- Instance Type: C3, C4, C5, M3, M4, M5, R3, R4, and R5 Family
- AMI: Amazon Linux 2018.03 이상
- EBS: Root Volume은 반드시 암호화 상태 && RAM 컨텐츠 이상의 Free Space 필요
- EC2: Launch 시 Hibernate 옵션 활성화
이밖에도 몇가지 조건이 더 있긴 하지만 생략하고. 바로 동작 테스트로 넘어가 봅시다.
동작 테스트
테스트를 위해서 일단 루트 볼륨을 암호화해야 했습니다. 아래처럼
※ 루트 볼륨을 암호화하려면 일단 암호화 안된 버전의 AMI를 만들고. 암호화 버전의 AMI로 Copy 해야한다네요
..
그리고 EC2를 새로 만들때도 “Stop – Hibernate behavior” 옵션을 반드시 체크해줘야 합니다.
※ 아시다시피 이 옵션은 AWS 관리 콘솔 기준으로 EC2 Launch > STEP3 중간쯤에 등장합니다
확인할 것이 조금 더 남았습니다.
$ sudo yum install ec2-hibinit-agent Loaded plugins: priorities, update-motd, upgrade-helper Package ec2-hibinit-agent-1.0.0-2.0.0.amzn1.noarch already installed and latest version Nothing to do $ uname -a Linux ip-10-0-2-86 4.14.77-70.59.amzn1.x86_64 #1 SMP Mon Nov 12 22:02:45 UTC 2018 x86_64 GNU/Linux
hibernation agent가 최신인지. 그리고 해당 기능을 지원하는 커널 버전인지 확인해야 합니다.
저는 최신 버전의 Amazon Linux AMI를 사용했기 때문에. 별도 작업 없이도 모든 준비가 완료되었네요.
이제 진짜로 모든 준비가 끝났습니다.
:: 일반적인 EC2 STOP & START 동작
비교할만한 대별점이 필요하기 때문에. 일반적인 “STOP” & “START” 부터 수행해보겠습니다.
우선 “STOP” 전에 last 명령어를 한번 찍어보고.
$ last ec2-user pts/0 211.xx.xx.xx Wed Dec 12 06:56 still logged in reboot system boot 4.14.77-70.59.am Wed Dec 12 06:53 - 07:03 (00:09) reboot system boot 4.14.77-70.59.am Wed Dec 12 06:37 - 07:03 (00:25) wtmp begins Wed Dec 12 06:37:28 2018
EC2를 중지합니다. 기존과 동일한 “STOP” 액션입니다.
※ Instance State 액션에 기존과 달리 STOP에 두가지 선택지가 있는것을 확인할 수 있다
이제 다시 EC2를 “START” 하고 동일한 명령어를 찍어보겠습니다. 아래에서 위쪽 순으로 보셔야 합니다.
$ last
ec2-user pts/0 211.xx.xx.xx Wed Dec 12 07:05 still logged in
reboot system boot 4.14.77-70.82.am Wed Dec 12 07:04 - 07:05 (00:00)
ec2-user pts/0 211.xx.xx.xx Wed Dec 12 06:56 - down (00:07)
reboot system boot 4.14.77-70.59.am Wed Dec 12 06:53 - 07:04 (00:10)
reboot system boot 4.14.77-70.59.am Wed Dec 12 06:37 - 07:04 (00:26)
wtmp begins Wed Dec 12 06:37:28 2018
실제 리부팅이 발생했기 때문에. 해당 이벤트가 찍히는 걸 확인할 수 있습니다.
즉, 시스템엔 OS 재부팅이 발생했고 필요한 이에 따른 부트 로직이 수행되었을 겁니다.
:: EC2 STOP – Hibernate & START 동작
이번엔 새로 나온 기능을 테스트해보겠습니다. 우선 새로 나온 옵션으로 중지를 진행합니다.
※ 이번엔 위와 달리 STOP – Hibernate를 선택했다
동일하게 다시 EC2를 “START” 하고 Last 명령어를 찍어 보겠습니다.
$ last
ec2-user pts/0 211.xx.xx.xx Wed Dec 12 07:08 still logged in
ec2-user pts/0 211.xx.xx.xx Wed Dec 12 07:05 - 07:06 (00:00)
reboot system boot 4.14.77-70.82.am Wed Dec 12 07:04 - 07:08 (00:03)
ec2-user pts/0 211.xx.xx.xx Wed Dec 12 06:56 - down (00:07)
reboot system boot 4.14.77-70.59.am Wed Dec 12 06:53 - 07:04 (00:10)
reboot system boot 4.14.77-70.59.am Wed Dec 12 06:37 - 07:04 (00:26)
wtmp begins Wed Dec 12 06:37:28 2018
보시다시피. 터미널은 불가피하게 다시 붙었지만. reboot 이벤트는 발생하지 않았습니다.
만일 특정 프로세스가 올라와 있었다면. init 등에서 별도 구동 없이도 동일하게 해당 프로세스가 올라와 있었겠죠?
차이점이 이해가 가시나요?
정리
이 기능은 사전 조건도 많지만. 설정 후에도 몇가지 제약사항이 있습니다
- Hibernated 모드(STOP – Hibernate 로 중지한)인 EC2는 인스턴스 타입이나 크기를 변경할 수 없다
- Hibernated 모드(STOP – Hibernate 로 중지한)인 EC2는 스냅샷이나 AMI를 생성할 수 없다
- Hibernation 옵션이 활성화된 인스턴스에서는 스냅샷이나 AMI를 생성할 수 없다
생각보다 제약사항이 전후로 많네요.
이 기능을 어느곳에 활용할 수 있을지가 명확하게 떠오르지는 않는데요.
Reboot 과정에서 발생할 수 있는 경우의 수-리스크(?)를 없애고.
완벽하게 검증된 상태의 인스턴스를 준비해야 하는 상황이라면 한번쯤 활용할만한 기능이란 생각은 드네요.
결국 제공하는 기능을 어떻게 활용할지는 사용자의 영역이니까요.
필요한 환경이 있으시다면 적절히 활용하시길 바랍니다.
마칩니다. 끝!
최신 댓글