IaaS 구현에 필요한 진실
Techs( younjin.jeong@gmail.com, 정윤진 )
IaaS 의 구조설계를 하게되는 경우, 전체 아키텍처에 가장 크게 영향을 미치지만 사실 별로 필요 없는 것이 2가지가 있다. 이 2가지는 많은 고객들이 아마존을 통해 경험한 사용성에 근간을 두고 있지만, 실제 아마존에서도 바로 이 부분 때문에 심각한 장애를 겪고 있다는 사실을 인지하고 있는 사람은 드물다. 이 2가지가 무얼까? 바로, Live Migration 과 EBS 서비스이다.
이 두가지는 IaaS 구현에 있어 각 클러스터의 크기를 제한하는 역할을 한다. 이 크기의 제한에 대한 핵심은 바로 이 두가지의 기능이 "Shared Storage" 를 필요로 하기 때문에 발생하는 것이다. Compute 클라우드 구현에 있어 이는 엄청나게 중요한 가치를 가지는데, 바로 이 부분 때문에 스토리지에 대한 비용이 급상승하고, 전체 클라우드 구성이 제한을 갖게 되며, 심각한 경우에는 일부 고객의 VM이 특정 하이퍼바이저 클러스터에만 생성되는 문제를 야기하기도 한다.
첫번째로, Live Migration 에 대해 살펴보자. 이 개념은 바로 가상화 기반의 Compute 클라우드에 위치한 VM이 어떠한 이유에서든 물리적으로 다른 위치 또는 클러스터 내의 다른 서버로 옮겨주는 기능을 말한다. 이는 서비스에서 "언제나" VM이 365일 24시간 죽지 않아야 한다는, 일종의 Availability 개념으로 이해 될 수 있다. 또한, 클라우드 내의 어떠한 서버에서든지 VM의 "이동"이 자유로워야 한다는 요구사항 때문에 발생한 것이기도 하다.
image from: http://vcommevirtuel.typepad.com/blog/
서비스 운영 중 하이퍼바이저가 사망하시는 경우는 충분히 발생 할 수 있다. 어떠한 이유에서든 하이퍼바이저를 동작하는 가상 서버의 사망은, 곧장 그 서버 위에서 동작하는 모든 VM들이 타격을 입게 된다는 말과 동일하다. 따라서 고객은 이러한 경우를 대비하여 Live Migration 을 IaaS 구현 요구사항에 넣는다.
결론부터 말하자면, 이는 완전히 잘못된, 또는 엄청난 제한을 가지게 되는 아키텍처를 만들어 낸다. 이 제약 사항 이라는 것은 바로 공유 스토리지가 필요하다 라는 부분이며, 이로 인해 얼마나 큰 사이즈의 스토리지를 어떠한 형태로 얼마나 많은 서버에 공유해야 하는가 하는 문제에 당면하게 된다. VM 하나, 하이퍼바이저 서버의 장애 한대를 피하기 위해 공유 스토리지가 붕괴하면 더 많은 수의 하이퍼바이저가 붕괴하는 구조의 선택이 필요해 지게 된다는 말이 된다는 것이다. 이제는 다시 공유 스토리지를 이중화 해야 하나 하는 고민에 빠지게 되며, 더 심각한 것은 (수 대의 하이퍼바이저 + 공유스토리지 ) 로 이루어진 하이퍼바이저 클러스터 한 덩이가 장애 대응의 최소 유닛이 된다는 점이다.
한가지 더, 대부분의 하이퍼바이저는 Live Migration 을 위해 양쪽 서버가 모두 정상적으로 동작해야 한다는 요구사항을 가진다. 사실 서버가 잘 동작하고 있는데 VM을 옮겨야 하는 이유는 전체 서비스 퍼포먼스를 위한 오케스트레이션 밖에 없다. 이는 무슨 말인가? Live Migration 의 전제조건은 클러스터 내의 모든 서버가 정상인 상태에서만 정상적으로 동작하는 기능이다 라는 말이다.
따라서 최초의 요구사항이었던 Availability 관점에서, 이는 필요 없는 기능이 된다. 애초에 모든것이 정상 동작하는 경우라면 Live Migration 을 해야 할 이유가 없다. 오케스트레이션은 클라우드 스택의 VM 분배 알고리즘이 충분히 똑똑하다면 Provisioning 단계에서 적절히 분산하여 처리해 주면 되는 일이다. 결론적으로, Live Migration 은 필요 없는 기능이 된다.
서비스를 구현할 때 이보다 더 중요한 것은, 바로 VM은 언제나 잘못 될 수 있다 라는 생각을 가지는 것이다. 잘못되면 동일한 역할을 하는 VM을 새로 만들고, 기존의 VM을 중지시켜 지워버리면 될 일이다. 이게 보다 클라우드에 맞는 서비스 구조 설계가 된다.
두번째로, EBS 와 같은 기능이다. 사실 아마존은 처음부터 EBS 서비스를 내놓지는 않았다. 기본적으로 클라우드의 VM은 몇대의 가상 서버를 사용하여 원하는 형태로 구성된 VM이 동작하는 환경과는 완전히 다른데, 그 중의 하나가 바로 이 디스크의 사용에 대한 부분이다. EBS 를 사용하지 않는 일반 VM의 디스크는 마치 메모리처럼 휘발성을 가진다. "영원히" 저장되는 기존의 물리 서버의 로컬 디스크와는 완전히 다른 것이다. 따라서 이러한 사용성을 보완하기 위해 개발한 것이 바로 EBS 서비스가 된다.
아마존의 EBS 서비스는 DRBD를 기반으로 한 것으로 보인다. 실제 어떠한 구현 기술이 사용되었건 간에, 이는 기본적으로 하이퍼바이저와 네트워크로 연결된 별도의 (가상화된)스토리지에 데이터를 쓰는 것이다. 가상화란 무엇인가. 물리 서버 한대로 구성할 것을 여러대의 가상 서버를 사용하는 것이기에, 네트워크, 디스크, 프로세서 등 모든 자원을 나누어 사용한다. 따라서 일반 Public 클라우드를 사용할 때 누구인지는 모르지만 다른 사람의 VM이 나의 VM과 동일한 하이퍼바이저에서 동작하고, 둘 다 EBS를 사용하는 경우는 필연적으로 발생한다. 헌데 만약 이 다른사람이 서비스를 클라우드에 올려보려고 디스크에 대한 벤치마킹을 dd 같은 도구를 사용하여 진행 중이라면, 그 하이퍼바이저 내의 모든 EBS 사용 고객은 심각한 성능 문제를 겪게 될 수 밖에 없다.
아마존은 이러한 사실을 알면서 왜 이 기능을 EBS에 넣었을까? 바로 Legacy 패턴, 즉 VM을 기존의 물리적 서버와 동일한 환경으로 사용하고 싶어하는 고객들이 많았기 때문이다. 따라서 그들은 각 고객의 인스턴스와 가상화된 볼륨의 매핑을 위해서 제법 복잡한 시스템을 구현하여 서비스에 성공했지만, 이로 인한 장애도 빈번하게 발생하게 된다.
EBS는, 역설적으로 데이터의 중요성이 높다면 반드시 사용하지 말아야 하는 서비스가 된다. 어떠한 데이터가 반드시 영원히 저장되어야 하고, 자주 변경된다면, 이러한 데이터는 EBS를 통해 저장하면 안된다. 아마존은 EBS를 기반으로 RDS 서비스도 구현하고 있기는 하지만, 이들 역시 성능과 사이징에 대한 제한이 있다. 이는 주제를 벗어난 좀 다른 이야기이지만, 클라우드에서 RDS와 같은 서비스를 사용하고자 한다면 반드시 Sharding 과 같은 기술을 고려해야 한다. IaaS 입장에서 RDS와 같은 서비스를 구현하고자 한다면, 이는 기존의 Compute 클라우드와 구분된 별도의 PaaS 형태로 독립적으로 구축해야 할 것이다.
아무튼, EBS를 IaaS 구현시 고려사항에 넣게 되면 문제가 매우 복잡해 진다. 사실 EBS가 필요한 이유는 인스턴스에서 "영원히 데이터가 저장되어야 하는 로컬디스크" 때문이다. 하지만 인스턴스 자체가 영원하지 않다고 생각해 버리면, 구현과 운영이 힘들며 아키텍처에 심각한 제한 사항을 유발하는 EBS 와 비슷한 기능을 구현해야 할 이유가 별로 없다.
이런식으로 생각 할 필요가 있다. 인스턴스를 처음 만들때 필요한 정보를 다운로드 받아 구성하도록 하고, 여기에 문제가 발생했을때 인스턴스를 그냥 없애버린다. 그리고 새로 만들면 된다. 이런 기능을 위해 이미지 서비스가 존재하고, Chef 나 Puppet, 또는 일반 스크립트등을 적절히 사용하면 된다. 아울러 무언가 지속적으로 저장되어야 하는 데이터들, 이를테면 AD 서버나 Exchange 서버를 클라우드에 올리고 싶은 경우도 있을 것이다. I/O 가 중요하거나, 저장되어야 하는 데이터가 매우 중요하다면 EBS를 쓰지 말고 하이브리드 형태로 구현하는것을 권고한다. AD나 Exchange는 그 사용량이 폭발적으로 늘어날 가능성이 있는 서버들이 아니다. 중요하고, 항상 동작해야 하는 Oracle 과 같은 서비스들은 클라우드가 지향하는 인프라의 개념과는 완전히 다름을 인지해야 한다.
오히려 클라우드가 필요한 부분은 이미지 서비스, 영상 서비스, 미들웨어와 같은 언제든 사용량이 폭발적으로 증가 할 수 있는 서비스여야 한다. 이러한 서비스들은 클라우드에 매우 적합하며, 바로 넷플릭스스 서비스가 성공할 수 있는 이유이기도 하다. 렌더링이나 인코딩과 같은 기존의 병렬 또는 분산처리 시스템을 클라우드에 올리는 것도 좋다. 이들은 계산을 위해 "임시로" 로컬 디스크를 사용하지만, 더 중요한 것은 프로세싱 파워이기 때문에 I/O 로 인한 문제가 발생할 확률이 적다.
이러한 클라우드의 사용성에 비추어 보면, EBS는 Compute 클라우드와 직접 밀착되어야 하는 무엇은 아니다. Live Migration 과 EBS는, 함께 일하는 클라우드 아키텍트의 말을 빌리자면 "Fancy" 한 기능 이상의 무엇도 아니다. 클라우드의 컨셉에 맞는 서비스 설계는 이러한 사항들로 인해 매우 중요하다. 별로 빠르지도고, 그다지 안전하지도 않은 EBS 비슷한 시스템의 구현은 완전히 다른 방법으로 접근해야 하는 것이다.
강력한 프로세싱 파워를 원하는 고객을 위해, 아마존은 HPC 클라우드를 별도로 제공한다. 마찬가지로, 강력한 I/O 를 원하는 부분은 분명히 있다. 그렇기에 지속적인 저장공간을 Compute 용 인스턴스에 반드시 붙여야 한다면, I/O를 위한 별도의 서비스 오퍼링을 만드는 것이 훨씬 현명할 것이다. 높은 I/O 성능이 필요한 서비스는 보통 높은 프로세서 성능과, 많은 메모리를 함께 요구하게 되는 경우가 많다. 따라서 하이퍼바이저에 얼마만큼의 인스턴스를 올려 줄 것인가 하는 고민과 함께, EBS형태의 서비스가 필요한 고객 또는 서비스를 위한 별도의 고비용 아키텍쳐를 준비하는 것이 옳다고 생각한다.
( younjin.jeong@gmail.com, 정윤진 )
IaaS 의 구조설계를 하게되는 경우, 전체 아키텍처에 가장 크게 영향을 미치지만 사실 별로 필요 없는 것이 2가지가 있다. 이 2가지는 많은 고객들이 아마존을 통해 경험한 사용성에 근간을 두고 있지만, 실제 아마존에서도 바로 이 부분 때문에 심각한 장애를 겪고 있다는 사실을 인지하고 있는 사람은 드물다. 이 2가지가 무얼까? 바로, Live Migration 과 EBS 서비스이다.
이 두가지는 IaaS 구현에 있어 각 클러스터의 크기를 제한하는 역할을 한다. 이 크기의 제한에 대한 핵심은 바로 이 두가지의 기능이 "Shared Storage" 를 필요로 하기 때문에 발생하는 것이다. Compute 클라우드 구현에 있어 이는 엄청나게 중요한 가치를 가지는데, 바로 이 부분 때문에 스토리지에 대한 비용이 급상승하고, 전체 클라우드 구성이 제한을 갖게 되며, 심각한 경우에는 일부 고객의 VM이 특정 하이퍼바이저 클러스터에만 생성되는 문제를 야기하기도 한다.
첫번째로, Live Migration 에 대해 살펴보자. 이 개념은 바로 가상화 기반의 Compute 클라우드에 위치한 VM이 어떠한 이유에서든 물리적으로 다른 위치 또는 클러스터 내의 다른 서버로 옮겨주는 기능을 말한다. 이는 서비스에서 "언제나" VM이 365일 24시간 죽지 않아야 한다는, 일종의 Availability 개념으로 이해 될 수 있다. 또한, 클라우드 내의 어떠한 서버에서든지 VM의 "이동"이 자유로워야 한다는 요구사항 때문에 발생한 것이기도 하다.
Live Migration
서비스 운영 중 하이퍼바이저가 사망하시는 경우는 충분히 발생 할 수 있다. 어떠한 이유에서든 하이퍼바이저를 동작하는 가상 서버의 사망은, 곧장 그 서버 위에서 동작하는 모든 VM들이 타격을 입게 된다는 말과 동일하다. 따라서 고객은 이러한 경우를 대비하여 Live Migration 을 IaaS 구현 요구사항에 넣는다.
결론부터 말하자면, 이는 완전히 잘못된, 또는 엄청난 제한을 가지게 되는 아키텍처를 만들어 낸다. 이 제약 사항 이라는 것은 바로 공유 스토리지가 필요하다 라는 부분이며, 이로 인해 얼마나 큰 사이즈의 스토리지를 어떠한 형태로 얼마나 많은 서버에 공유해야 하는가 하는 문제에 당면하게 된다. VM 하나, 하이퍼바이저 서버의 장애 한대를 피하기 위해 공유 스토리지가 붕괴하면 더 많은 수의 하이퍼바이저가 붕괴하는 구조의 선택이 필요해 지게 된다는 말이 된다는 것이다. 이제는 다시 공유 스토리지를 이중화 해야 하나 하는 고민에 빠지게 되며, 더 심각한 것은 (수 대의 하이퍼바이저 + 공유스토리지 ) 로 이루어진 하이퍼바이저 클러스터 한 덩이가 장애 대응의 최소 유닛이 된다는 점이다.
한가지 더, 대부분의 하이퍼바이저는 Live Migration 을 위해 양쪽 서버가 모두 정상적으로 동작해야 한다는 요구사항을 가진다. 사실 서버가 잘 동작하고 있는데 VM을 옮겨야 하는 이유는 전체 서비스 퍼포먼스를 위한 오케스트레이션 밖에 없다. 이는 무슨 말인가? Live Migration 의 전제조건은 클러스터 내의 모든 서버가 정상인 상태에서만 정상적으로 동작하는 기능이다 라는 말이다.
따라서 최초의 요구사항이었던 Availability 관점에서, 이는 필요 없는 기능이 된다. 애초에 모든것이 정상 동작하는 경우라면 Live Migration 을 해야 할 이유가 없다. 오케스트레이션은 클라우드 스택의 VM 분배 알고리즘이 충분히 똑똑하다면 Provisioning 단계에서 적절히 분산하여 처리해 주면 되는 일이다. 결론적으로, Live Migration 은 필요 없는 기능이 된다.
서비스를 구현할 때 이보다 더 중요한 것은, 바로 VM은 언제나 잘못 될 수 있다 라는 생각을 가지는 것이다. 잘못되면 동일한 역할을 하는 VM을 새로 만들고, 기존의 VM을 중지시켜 지워버리면 될 일이다. 이게 보다 클라우드에 맞는 서비스 구조 설계가 된다.
두번째로, EBS 와 같은 기능이다. 사실 아마존은 처음부터 EBS 서비스를 내놓지는 않았다. 기본적으로 클라우드의 VM은 몇대의 가상 서버를 사용하여 원하는 형태로 구성된 VM이 동작하는 환경과는 완전히 다른데, 그 중의 하나가 바로 이 디스크의 사용에 대한 부분이다. EBS 를 사용하지 않는 일반 VM의 디스크는 마치 메모리처럼 휘발성을 가진다. "영원히" 저장되는 기존의 물리 서버의 로컬 디스크와는 완전히 다른 것이다. 따라서 이러한 사용성을 보완하기 위해 개발한 것이 바로 EBS 서비스가 된다.
이 EBS가 아니다.
아마존의 EBS 서비스는 DRBD를 기반으로 한 것으로 보인다. 실제 어떠한 구현 기술이 사용되었건 간에, 이는 기본적으로 하이퍼바이저와 네트워크로 연결된 별도의 (가상화된)스토리지에 데이터를 쓰는 것이다. 가상화란 무엇인가. 물리 서버 한대로 구성할 것을 여러대의 가상 서버를 사용하는 것이기에, 네트워크, 디스크, 프로세서 등 모든 자원을 나누어 사용한다. 따라서 일반 Public 클라우드를 사용할 때 누구인지는 모르지만 다른 사람의 VM이 나의 VM과 동일한 하이퍼바이저에서 동작하고, 둘 다 EBS를 사용하는 경우는 필연적으로 발생한다. 헌데 만약 이 다른사람이 서비스를 클라우드에 올려보려고 디스크에 대한 벤치마킹을 dd 같은 도구를 사용하여 진행 중이라면, 그 하이퍼바이저 내의 모든 EBS 사용 고객은 심각한 성능 문제를 겪게 될 수 밖에 없다.
아마존은 이러한 사실을 알면서 왜 이 기능을 EBS에 넣었을까? 바로 Legacy 패턴, 즉 VM을 기존의 물리적 서버와 동일한 환경으로 사용하고 싶어하는 고객들이 많았기 때문이다. 따라서 그들은 각 고객의 인스턴스와 가상화된 볼륨의 매핑을 위해서 제법 복잡한 시스템을 구현하여 서비스에 성공했지만, 이로 인한 장애도 빈번하게 발생하게 된다.
EBS는, 역설적으로 데이터의 중요성이 높다면 반드시 사용하지 말아야 하는 서비스가 된다. 어떠한 데이터가 반드시 영원히 저장되어야 하고, 자주 변경된다면, 이러한 데이터는 EBS를 통해 저장하면 안된다. 아마존은 EBS를 기반으로 RDS 서비스도 구현하고 있기는 하지만, 이들 역시 성능과 사이징에 대한 제한이 있다. 이는 주제를 벗어난 좀 다른 이야기이지만, 클라우드에서 RDS와 같은 서비스를 사용하고자 한다면 반드시 Sharding 과 같은 기술을 고려해야 한다. IaaS 입장에서 RDS와 같은 서비스를 구현하고자 한다면, 이는 기존의 Compute 클라우드와 구분된 별도의 PaaS 형태로 독립적으로 구축해야 할 것이다.
아무튼, EBS를 IaaS 구현시 고려사항에 넣게 되면 문제가 매우 복잡해 진다. 사실 EBS가 필요한 이유는 인스턴스에서 "영원히 데이터가 저장되어야 하는 로컬디스크" 때문이다. 하지만 인스턴스 자체가 영원하지 않다고 생각해 버리면, 구현과 운영이 힘들며 아키텍처에 심각한 제한 사항을 유발하는 EBS 와 비슷한 기능을 구현해야 할 이유가 별로 없다.
이런식으로 생각 할 필요가 있다. 인스턴스를 처음 만들때 필요한 정보를 다운로드 받아 구성하도록 하고, 여기에 문제가 발생했을때 인스턴스를 그냥 없애버린다. 그리고 새로 만들면 된다. 이런 기능을 위해 이미지 서비스가 존재하고, Chef 나 Puppet, 또는 일반 스크립트등을 적절히 사용하면 된다. 아울러 무언가 지속적으로 저장되어야 하는 데이터들, 이를테면 AD 서버나 Exchange 서버를 클라우드에 올리고 싶은 경우도 있을 것이다. I/O 가 중요하거나, 저장되어야 하는 데이터가 매우 중요하다면 EBS를 쓰지 말고 하이브리드 형태로 구현하는것을 권고한다. AD나 Exchange는 그 사용량이 폭발적으로 늘어날 가능성이 있는 서버들이 아니다. 중요하고, 항상 동작해야 하는 Oracle 과 같은 서비스들은 클라우드가 지향하는 인프라의 개념과는 완전히 다름을 인지해야 한다.
오히려 클라우드가 필요한 부분은 이미지 서비스, 영상 서비스, 미들웨어와 같은 언제든 사용량이 폭발적으로 증가 할 수 있는 서비스여야 한다. 이러한 서비스들은 클라우드에 매우 적합하며, 바로 넷플릭스스 서비스가 성공할 수 있는 이유이기도 하다. 렌더링이나 인코딩과 같은 기존의 병렬 또는 분산처리 시스템을 클라우드에 올리는 것도 좋다. 이들은 계산을 위해 "임시로" 로컬 디스크를 사용하지만, 더 중요한 것은 프로세싱 파워이기 때문에 I/O 로 인한 문제가 발생할 확률이 적다.
이러한 클라우드의 사용성에 비추어 보면, EBS는 Compute 클라우드와 직접 밀착되어야 하는 무엇은 아니다. Live Migration 과 EBS는, 함께 일하는 클라우드 아키텍트의 말을 빌리자면 "Fancy" 한 기능 이상의 무엇도 아니다. 클라우드의 컨셉에 맞는 서비스 설계는 이러한 사항들로 인해 매우 중요하다. 별로 빠르지도고, 그다지 안전하지도 않은 EBS 비슷한 시스템의 구현은 완전히 다른 방법으로 접근해야 하는 것이다.
강력한 프로세싱 파워를 원하는 고객을 위해, 아마존은 HPC 클라우드를 별도로 제공한다. 마찬가지로, 강력한 I/O 를 원하는 부분은 분명히 있다. 그렇기에 지속적인 저장공간을 Compute 용 인스턴스에 반드시 붙여야 한다면, I/O를 위한 별도의 서비스 오퍼링을 만드는 것이 훨씬 현명할 것이다. 높은 I/O 성능이 필요한 서비스는 보통 높은 프로세서 성능과, 많은 메모리를 함께 요구하게 되는 경우가 많다. 따라서 하이퍼바이저에 얼마만큼의 인스턴스를 올려 줄 것인가 하는 고민과 함께, EBS형태의 서비스가 필요한 고객 또는 서비스를 위한 별도의 고비용 아키텍쳐를 준비하는 것이 옳다고 생각한다.
( younjin.jeong@gmail.com, 정윤진 )