많은 클라우드 서비스 프로바이더들이 제공하고 있어서 거기서 거기인듯한 IssA형 클라우드지만 구글에서 제공하고 있는 Google Compute Engine(이하 GCE)에는 VM의 리부트 없이도 각종 업데이트의 적용이 가능한 라이브마이그레이션 이라는 특별한 기능이 있다.
국내에는 잘 알려져 있지 않은 이 라이브마이그레이션 기능에 대해 Qiita에 상세히 소개하는 기사가 올라왔기에 번역하여 소개해 보고자 한다. 번역을 흔쾌히 허락해 주신 사토 카즈노리씨에게 감사의 말씀을 전한다.
GCE의 라이브마이그레이션의 대단함에 대하여
Google Cloud Platform(GCP)의 영어 블로그에 GCE의 라이브마이그레이션 기능에 대한 해설 기사가 포스팅 되었다. 개인적으로도 몇건의 대규모 프로젝트에서 이 기능의 능력에 감동하여, 과연 구글은 구글이구나 라고 생각 하였고, GCP팀에서 실제 만든 사람들과 만나 보니 열정적으로 설명해 주였다. 해서, 위에 소개한 블로그기사 + 개인의 경험을 바탕으로 간단히 정리해 보고자 한다.
그럼, 지금부터의 내용은 개인으로서의 감상 입니다!
역자주 : 이 글의 필자인 사토 카즈노리씨는 일본 구글 클라우드 플랫폼 부문에서 Developer Advocate(테크놀러지 에반젤리스트)로 재직중이다.
Heartbleed버그 당시에도 VM재기동은 없었다
GCE에서는 2013년12월부터 라이브마이그레이션을 이용한 Transparent Maintenance (자동 메인터넌스)라고하는 운영을 개발하고 있다. 이것은 말하자면 VM을 멈추지 않고 동일한 존내의 다른 물리서버로 이동시켜주는 기술이다. 메인터넌스를 위해서 “VM이 정지하므로 재시동해 주세요”라는 메일을 더 이상 받지 않아도 되게 해 주는 기술인 것이다.
실제로 2014년 4월에 일어났던 Heartbleed버그때에도, 타사의 클라우드처럼 호스트OS의 패치를 적용시키기 위해 전VM을 재기동하는 사태는 GCE에서는 전혀 일어나지 않았고, VM리부트가 제로까지는 아니지만, 하드웨어 갱신이나 패치적용과 같은 메인터넌스 목적의 계획적 리부팅은 크게 줄었다.
구글의 데이터센터는 끊임 없이 메인터넌스 된다
구글에게 있어서, GCE를 정식서비스로서 공개할것인지 말것인지는 이 라이브마이그레이션 기능을 실현에 걸려 있었다고 말해진다. 왜냐하면 구글의 데이터센터는 언제나 하드웨어나 호스트OS의 메인터넌스가 벌어지고 있었기 때문이다. 예를들면,
- 서버, 네트워크,전원설비등의 갱신
- 호스트OS이미지, BIOS, 호스트의 시스템구성등의 변화
- 긴급 세큐리티 패치의 적용
등의 작업이다. 구글의 다양한 서비스는, 이렇게 빈번한 메인터넌스에도 견딜 수 있는 페일오버/다중화 설계가 되어져 있다. GCE에 있어서도, 라이브마이그레이션이 구현된것으로, 다른 구글서비스와 마찬가지로 항시 최신 인프라위에서 VM을 운용하는것이 가능하게 되었다.
여기에 구글최신의 SDN인프라인 Andromeda덕에 GCE인스턴스간 3Gbps통신과 같은 메리트도 덤으로 얻을 수 있다.
여기에 구글최신의 SDN인프라인 Andromeda덕에 GCE인스턴스간 3Gbps통신과 같은 메리트도 덤으로 얻을 수 있다.
고장의 사전감지시에도 마이그레이션
라이브마이그레이션은 계획적 메인터넌스뿐이 아니라, 하드웨어고장이나 소프트웨어 결함을 사전에 감지한 경우에도 사용된다. 구체적으로는,
- 네트워크카드의 상태가 좋지 않아 에러 발생율이 올라갔다
- 베터리나 전원이 가열되어 서버 온도가 상승했다
- 호스트OS의 결함이 발견되었다
- 메모리 소비가 비정상적으로 늘었다
와 같은 고장의 징후를 검출하여, 다운이 일어나가 전에 예방적으로 VM을 다른 서버로 이동시킨다. 마이그레이션후에는 GCE의 시스템로그에 타임스템프가 기록된다. 단, 유저측으로부터 명시적으로 마이그레이션을 기동하는것은 불가능하다.
동작중인 VM을 0.5초만에 이동, 패킷로스 제로
여기까지의 설명을 읽고, 다음과같은 의문을 가진 사람이 많을것이다:
- 타사VM의 라이브마이그레이션과 같이 몇초정도는 멈추지 않을까?
- 움직이는 VM을 다른 서버에 이동하게되면, 서비스가 멈춘다던지 네트워크가 끊기지는 않을런지?
이것은 나에게 있어서 큰 문제로, 솔직히, 나온지 얼마 되지 않았던 당시에는 반신반의 했었다. “걱정이 되어서 라이브마이그레이션을 끄고싶다”라는 의견도 당연하다(GCE에서는 라이브마이그레이션을 끄는것이 가능하다).
정말로? 라고 생각할지도 모르지만, 실제로 GCE에서 움직이는 엄청난수의 VM에 대하여 수많은 마이그레이션이 실시되었고, 문제 없이 운영되고 있다. Rightscale이 실시한 대규모 로드테스트에서도
로그파일이나 DB내부를 전부 살펴보아도 아무런 이상이 별견되지 않는다.
만약 구글이 마이그레이션을 실시하였다고 알려주지 않았다면 눈치챌 수 없었을것이다.
라고 평가하고 있다.
출처: Rightscale
실제 나 자신이 참가했었던 국내 적용사례에서도, GCE상에서 가동중인 DB클러스터에 대해서 국내 최고 수준의 실 트레픽을 퍼부으면서 마이그레이션을 진행하는 로드테스트를 실시해, DB에러나 접속끊김과 같은 장애는 일체 발생하지 않았다. 관측된것은 극히 일부분의 레플리케이션 지연 뿐이였다. 뭐 이런 기술이 다 있나… 라는 생각이 들 정도였다.
마이그레이션의 메커니즘
그럼, 이 마이그레이션은 어떠한 구조로 실현되고 있는것일까?
마이그레이션 시작 60초 전이 되면, VM상의 게스트OS에 대하여 마이그레이션 개시가 사전에 통지된다. 그 다음엔, 이동할 대상의 새로운 VM이 준비되고, 다음과 같은 3단계의 마이그레이션이 개시된다.
- 브라운아웃기간 : 새로운 VM이 기동된 상태로, 메모리상의 데이터등 VM의 내용을 새VM에 카피한다
- 블랙아웃기간 : 구VM의 모든 동작을 일순간만 정지시켜, 브라운아웃 대기중에 받은 네트웍 패킷을 새로운 VM에 전송한다
- 마이그레이션후의 브라운아웃기간 : 구VM은 이후에도 남겨, 블랙아웃 기간중에 받은 네트웍 패킷을 새로운 VM에 전송한다
먼저 언급한대로, 여기서 말하는 블랙아웃 기간은 나의 경험상 보통 0.5초 정도면 끝난다. 그 기간에 도착한 네트웍 패킷은 모두 새로운VM으로 도착하기 때문에 TCP연결도 문제 없이 유지되는 구조이다.
GCE는 여러모로 놀라워
이 GCE의 라이브마이그레이션은 타사의 크라우드서비스의 유저에게 있어서는 상당히 매력적인 기능의 하나로, 설명할 수록 놀라게 된다. 이것에의해 GCE가 정지하는 가능성이 제로가 되는것은 아니지만, 유저에게 있어 클라우드의 편리함이 하나 더 늘었다고 말할 수 있을것이다.
초당1만건의 리퀘스트를 손쉽게 처리해내는 GCE의 로드벨런서를 시작으로, 이번에 소개한 라이브마이그레이션등, 슬슬 “구글다운 클라우드”의 특색을 드러낸 GCE. 연내에는 또 하나, 이것 또한 과연 구글이다 라는 생각이 든 서비스가 나온다 하니 기대해 주었으면 한다.
이 기사는 개인적인 글 입니다. 여기서 언급한 것은 사적인 의견에 근거한 것이며 회사와는 관계가 없음을 밝혀둡니다.
