2017.06.21

AWS 대신 다른 클라우드를 선택할 13가지 이유

Peter Wayner | InfoWorld

아마존 웹 서비스는 확실한 선두 주자다. 최초의 클라우드 중 하나인 AWS가 현재 가장 앞서나가는 데는 그럴 만한 이유가 있다. AWS는 가상이라는 지붕 아래에 다 열거하기가 불가능할 정도로 풍부한 옵션과 서비스를 제공한다. 수십 가지 시스템 유형, 수십 가지 데이터 저장 방법, 수백, 수천 가지의 소프트웨어 패키지 중에서 입맛대로 골라 자기만의 환경을 구성할 수 있다. 이것이 AWS가 클라우드 시장에서 절대 강자인 이유다.

그렇다고 경쟁이 멈춘 것은 아니다. AWS의 좋은 대안이 많을 뿐만 아니라 이 대안들은 빠른 속도로 발전하고 있다. 지금이야 일단 AWS를 고려하지만 미래에는 그 양상이 바뀔 수도 있다.

따라서 무조건 AWS를 선택하기보다는 먼저 아마존 클라우드가 지금은 물론 미래에도 자사가 추진하는 프로젝트와 잘 맞는지부터 생각해야 한다. 여기서는 지금 AWS가 아닌 다른 대안을 선택하는 것이 더 타당한 13가지 시나리오와 조만간 AWS를 버리고 다른 클라우드를 선택할 만한 이유를 정리해봤다.

Credit: GettyimageBank

베어 메탈 성능을 원하는 경우
클라우드의 장점인 유연성은 가상화에 기반하지만 그 가상화에는 대가가 따른다. 바로 모든 I/O 요청을 살피고 이를 적절한 가상머신에 보내는 역할을 할 소량의 코드가 필요하다는 점이다. 이 작은 코드 덩어리들이 모이면 커진다.

이를 겨냥해 조이언트(Joyent)는 자사 시스템에서 이 중간 단계를 잘라내 도커 컨테이너를 위한 “베어 메탈” 성능을 제공한다는 점을 수시로 강조한다. 조이언트는 트리톤(Triton)을 개발, 가상머신에서 I/O 작업 속도를 늦추는 여러 가지 계층을 없애는 데 성공했다. 본지의 테스트 결과에서도 가격 대 성능비가 더 우수한 것으로 확인됐다.

전용 시스템을 원하는 경우
클라우드에서 우리가 “머신”이라고 부르는 것은 대부분 더 큰 머신의 일부 조각에 불과하다. 사람들은 곧잘 자기만의 온전한 “박스”를 얻었다고 생각하지만, 실상은 개별적인 머신인 척하는 공유 서버에 접근하고 있을 뿐이다. 그렇다면, 클라우드의 이웃들을 신뢰하는가? 클라우드 프로그래머들이 모든 버그를 완전히 잡았다고 확신하는가? 편집증이 있는가?

IBM 클라우드는 고객이 선호하는 사양으로 구성할 수 있는 독립적인 베어 메탈 박스를 제공한다. RAM 용량, SSD, 프로세서 코어를 직접 선택한다. 그러면 어디선가 그 시스템이 조립되고, 기본 임대 기간 한 달 동안 그 시스템은 오로지 나 혼자만의 것이 된다. 시간 단위로 임대해야 하는 경우에는 표준 구성 중에서 선택하면 된다.

웹 페이지가 몇 개뿐인 경우
과거 공유 호스팅 방식이 등장했던 초창기, 사람들은 유닉스 머신의 계정을 구입해 아파치로 구동되는 소수의 웹 페이지를 운영했다. 물론 컴퓨터 하나에서 실행됐고 확장도 되지 않았지만 소규모 웹사이트에는 어차피 그런 유연성이 필요 없었다. 단순했던 그 시절에 탄생한 워드프레스(WordPress), 드루팔(Drupal)을 비롯한 간소한 옵션을 사용해 조용히, 잘 운영되고 있는 사이트가 아직도 아주 많다.

정적 웹 페이지를 제작하는 사람들도 여전히 있다. CPanel을 실행하는 이 공유 서버는 지금도 완벽하게 유효한 옵션이며 클라우드보다 더 간소하고 더 효율적인 경우가 많고, 대부분의 경우 훨씬 더 저렴하다. 얼마 되지 않는 PHP나 클래식 웹 페이지를 운영하는 정도라면 가장 저렴하게 데이터를 전달하는 방법은 예전의 공유 서버를 통한 방법이다.

플랫폼이 아니라 솔루션을 원하는 경우
문서를 편집하거나 스프레드시트를 작성해야 하는 사람들에게 오피스 365의 인기는 식을 줄 모른다. G 스위트(G Suite)도 나름의 팬 클럽이 있다. 아마존은 플랫폼, 즉 기회다. 솔루션이 아니다. 경우에 따라서는 브라우저 확장을 구축하고 모든 요소를 구글이나 마이크로소프트 시스템에 문서로 저장하는 것이 최선의 문제 해결 방법일 수도 있다.

각자 이러한 온라인 앱을 활용할 수 있는 방법은 다양하다. 필요한 모든 기능을 갖춘 솔루션이 이미 클라우드에 있어 즉시 이용할 수 있다면, 굳이 자기만의 서버를 임대해서 자기만의 인프라를 구축할 이유는 없다.

코드를 많이 쓰고 싶지 않은 경우
앱 엔진(App Engine)은 구글의 기발한 아이디어 중 하나다. 엄격한 구조를 사용해서 기본적인 파이썬 코드(또는 Node.js, 자바, 루비, C#, PHP, 고)를 작성하면 확장과 데이터 저장, 구성, 로드밸런싱 등은 구글이 알아서 해준다. 여러 구글 자원을 엮는 몇 줄짜리 코드만으로 꽤 복잡한 애플리케이션도 아주 쉽게 구축할 수 있다. 사용자 수가 많아질 경우 구글이 그에 맞게 확장하고 사용한 리소스에 따라 비용을 청구한다.

스마트한 분산 데이터베이스를 원하는 경우
지금까지 클라우드 데이터 스토리지 시장은 비일관성에 대한 걱정 없이 정보를 안전하게 보관하는 데 만족하는 사람들이 주도해왔다. 이들은 “최종 일관성(eventual consistency)”이라는 말을 즐겨 사용하는데, 그게 가장 내세울 수 있는 점이기 때문이다.

하지만 이제는 양상이 바뀌고 있다. 구글 클라우드 스패너(Google Cloud Spanner)는 높은 확장성을 갖춘 복제 데이터 저장소로, 모든 노드에 걸쳐 강력한 일관성을 제공한다. 모든 노드가 연계 작동하면서 일관성을 유지한다. 강력한 일관성과 전역 복제가 필요하다면? 구글을 이용하면 된다.



2017.06.21

AWS 대신 다른 클라우드를 선택할 13가지 이유

Peter Wayner | InfoWorld

아마존 웹 서비스는 확실한 선두 주자다. 최초의 클라우드 중 하나인 AWS가 현재 가장 앞서나가는 데는 그럴 만한 이유가 있다. AWS는 가상이라는 지붕 아래에 다 열거하기가 불가능할 정도로 풍부한 옵션과 서비스를 제공한다. 수십 가지 시스템 유형, 수십 가지 데이터 저장 방법, 수백, 수천 가지의 소프트웨어 패키지 중에서 입맛대로 골라 자기만의 환경을 구성할 수 있다. 이것이 AWS가 클라우드 시장에서 절대 강자인 이유다.

그렇다고 경쟁이 멈춘 것은 아니다. AWS의 좋은 대안이 많을 뿐만 아니라 이 대안들은 빠른 속도로 발전하고 있다. 지금이야 일단 AWS를 고려하지만 미래에는 그 양상이 바뀔 수도 있다.

따라서 무조건 AWS를 선택하기보다는 먼저 아마존 클라우드가 지금은 물론 미래에도 자사가 추진하는 프로젝트와 잘 맞는지부터 생각해야 한다. 여기서는 지금 AWS가 아닌 다른 대안을 선택하는 것이 더 타당한 13가지 시나리오와 조만간 AWS를 버리고 다른 클라우드를 선택할 만한 이유를 정리해봤다.

Credit: GettyimageBank

베어 메탈 성능을 원하는 경우
클라우드의 장점인 유연성은 가상화에 기반하지만 그 가상화에는 대가가 따른다. 바로 모든 I/O 요청을 살피고 이를 적절한 가상머신에 보내는 역할을 할 소량의 코드가 필요하다는 점이다. 이 작은 코드 덩어리들이 모이면 커진다.

이를 겨냥해 조이언트(Joyent)는 자사 시스템에서 이 중간 단계를 잘라내 도커 컨테이너를 위한 “베어 메탈” 성능을 제공한다는 점을 수시로 강조한다. 조이언트는 트리톤(Triton)을 개발, 가상머신에서 I/O 작업 속도를 늦추는 여러 가지 계층을 없애는 데 성공했다. 본지의 테스트 결과에서도 가격 대 성능비가 더 우수한 것으로 확인됐다.

전용 시스템을 원하는 경우
클라우드에서 우리가 “머신”이라고 부르는 것은 대부분 더 큰 머신의 일부 조각에 불과하다. 사람들은 곧잘 자기만의 온전한 “박스”를 얻었다고 생각하지만, 실상은 개별적인 머신인 척하는 공유 서버에 접근하고 있을 뿐이다. 그렇다면, 클라우드의 이웃들을 신뢰하는가? 클라우드 프로그래머들이 모든 버그를 완전히 잡았다고 확신하는가? 편집증이 있는가?

IBM 클라우드는 고객이 선호하는 사양으로 구성할 수 있는 독립적인 베어 메탈 박스를 제공한다. RAM 용량, SSD, 프로세서 코어를 직접 선택한다. 그러면 어디선가 그 시스템이 조립되고, 기본 임대 기간 한 달 동안 그 시스템은 오로지 나 혼자만의 것이 된다. 시간 단위로 임대해야 하는 경우에는 표준 구성 중에서 선택하면 된다.

웹 페이지가 몇 개뿐인 경우
과거 공유 호스팅 방식이 등장했던 초창기, 사람들은 유닉스 머신의 계정을 구입해 아파치로 구동되는 소수의 웹 페이지를 운영했다. 물론 컴퓨터 하나에서 실행됐고 확장도 되지 않았지만 소규모 웹사이트에는 어차피 그런 유연성이 필요 없었다. 단순했던 그 시절에 탄생한 워드프레스(WordPress), 드루팔(Drupal)을 비롯한 간소한 옵션을 사용해 조용히, 잘 운영되고 있는 사이트가 아직도 아주 많다.

정적 웹 페이지를 제작하는 사람들도 여전히 있다. CPanel을 실행하는 이 공유 서버는 지금도 완벽하게 유효한 옵션이며 클라우드보다 더 간소하고 더 효율적인 경우가 많고, 대부분의 경우 훨씬 더 저렴하다. 얼마 되지 않는 PHP나 클래식 웹 페이지를 운영하는 정도라면 가장 저렴하게 데이터를 전달하는 방법은 예전의 공유 서버를 통한 방법이다.

플랫폼이 아니라 솔루션을 원하는 경우
문서를 편집하거나 스프레드시트를 작성해야 하는 사람들에게 오피스 365의 인기는 식을 줄 모른다. G 스위트(G Suite)도 나름의 팬 클럽이 있다. 아마존은 플랫폼, 즉 기회다. 솔루션이 아니다. 경우에 따라서는 브라우저 확장을 구축하고 모든 요소를 구글이나 마이크로소프트 시스템에 문서로 저장하는 것이 최선의 문제 해결 방법일 수도 있다.

각자 이러한 온라인 앱을 활용할 수 있는 방법은 다양하다. 필요한 모든 기능을 갖춘 솔루션이 이미 클라우드에 있어 즉시 이용할 수 있다면, 굳이 자기만의 서버를 임대해서 자기만의 인프라를 구축할 이유는 없다.

코드를 많이 쓰고 싶지 않은 경우
앱 엔진(App Engine)은 구글의 기발한 아이디어 중 하나다. 엄격한 구조를 사용해서 기본적인 파이썬 코드(또는 Node.js, 자바, 루비, C#, PHP, 고)를 작성하면 확장과 데이터 저장, 구성, 로드밸런싱 등은 구글이 알아서 해준다. 여러 구글 자원을 엮는 몇 줄짜리 코드만으로 꽤 복잡한 애플리케이션도 아주 쉽게 구축할 수 있다. 사용자 수가 많아질 경우 구글이 그에 맞게 확장하고 사용한 리소스에 따라 비용을 청구한다.

스마트한 분산 데이터베이스를 원하는 경우
지금까지 클라우드 데이터 스토리지 시장은 비일관성에 대한 걱정 없이 정보를 안전하게 보관하는 데 만족하는 사람들이 주도해왔다. 이들은 “최종 일관성(eventual consistency)”이라는 말을 즐겨 사용하는데, 그게 가장 내세울 수 있는 점이기 때문이다.

하지만 이제는 양상이 바뀌고 있다. 구글 클라우드 스패너(Google Cloud Spanner)는 높은 확장성을 갖춘 복제 데이터 저장소로, 모든 노드에 걸쳐 강력한 일관성을 제공한다. 모든 노드가 연계 작동하면서 일관성을 유지한다. 강력한 일관성과 전역 복제가 필요하다면? 구글을 이용하면 된다.



X