류프리

온프레미스 데이터센터가 기업 IT 투자 순위에서 뒤로 밀리고 있다는 것은 잘 알려진 사실이다. 기업 IT가 클라우드로 이동하고 있는 것이다. 그리고 이런 흐름을 숫자로 확인하는 보고서가 나왔다.

시너지 리서치의 최근 조사에 따르면, 2015년 2분기부터 2017년 2분기까지 전통적인 데이터센터 하드웨어와 소프트웨어에 대한 투자는 18%가 하락했다. 같은 기간에 퍼블릭 클라우드 지출은 35%가 증가했다. 전체적인 데이터센터 장비 시장은 5% 성장해 300억 달러 이상의 규모를 기록했다.

시너지 리서치 그룹의 최고 애널리스트 존 딘스데일은 “클라우드 서비스 매출이 연간 40% 이상 계속 증가하고, 기업 SaaS 매출도 30%, 검색 및 소셜 네트워킹 매출은 20% 이상 증가했다는 점에서 퍼블릭 클라우드 인프라에 대한 지출이 계속 강세를 보이는 것은 당연한 일이다”라고 밝혔다.

Synergy Research

반면에 온프레미스 비즈니스는 계속 감소하고 있으며, 3대 업체인 시스코, HPE, 델 EMC는 퍼블릭 클라우드 인프라 시장을 두고 경쟁을 벌이고 있다. 퍼블릭 클라우드 시장에서는 네트워크 장비가 강점인 시스코가 우세를 보이며, 프라이빗 클라우드 시장에서는 델 EMC가 선두를 차지하고, HPE와 마이크로소프트가 그 뒤를 잇고 있다.

시너지 리서치의 보고서는 또 ODM(Original Design Manufacturers)의 브랜드명 없는 서버 장비 시장이 활성화되고 있다고 밝혔다. ODM 시장은 실질적으로 유명 장비 시장보다 더 큰데, 많은 기업이 구글과 페이스북의 방식을 따르고 있기 때문이다. 구글과 페이스북은 델 EMC나 HPE의 좀 더 비싼 서버 대신 이른바 ‘화이트 박스’ 서버를 구축해 사용한다.

딘스데일은 “이들 중 일부는 새로운 서비스나 애플리케이션에 사용되지만, 많은 수가 기업의 자체 데이터센터 투자로 인한 것이다. 퍼블릭 클라우드 구축은 ODM과 화이트 박스 솔루션 시장의 빠른 성장에서 퍼블릭 클라우드 구축이 한몫했으며, 따라서 데이터센터 인프라 시장은 점점 더 경쟁이 치열해지고 있다”고 설명했다.

시너지 리서치는 시스코와 델 EMC, HPE, 마이크로소프트 외에 IBM, VM웨어, 화웨이, 레노버, 오라클, 넷앱을 주요 업체로 언급했지만, 순위는 밝히지 않았다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/t/34/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C/106515#csidxb473feb0680d86cab701ba56654021f 

이식성과 호환성은 같은 말이 아니다. 이식성은 비즈니스의 문제이고 호환성은 기술 문제이다.

컨테이너는 이식성(Portability)과 민첩성을 보장하겠다고 약속한다. 애플리케이션을 개발자의 노트북에서 내부 데이터센터로 옮기고, 별다른 수고없이 외부의 서로 다른 클라우드 서비스 업체로 옮길 수 있다고 한다. 컨테이너는 새로운 맞춤형 소프트웨어 버전을 구성해 얼마 전에 계약한 납품 기일을 신속하게 맞출 수 있도록 해주고, 심지어 고객에게 셀프 서비스도 제공할 수 있다. 컨테이너는 가상머신보다 더 빨리 시작하고, 더 쉽게 옮길 수 있다. 그렇지 않은가?

목표인 것은 맞지만, 이식성과 호환성은 같은 것이 아니다. 이식성은 비즈니스 문제이고, 호환성은 기술 문제이기 때문이다. 이식성은 서로 다른 환경에서 호환성을 계획해야만 구현할 수 있다. 컨테이너를 도입하는 것만으로는 애플리케이션의 호환성을 보장받지 못한다. 왜 그럴까? 컨테이너는 애플리케이션과 그 애플리케이션의 모든 운영체제 의존 요소를 패키징하는 세련된 방법일 뿐이기 때문이다.

즉 이식성을 제대로 구현하기 위해서는, 그리고 궁극적으로 비즈니스의 민첩성을 구현하기 위해서는 계획이 필요하다. 여기서는 성공적인 이식성을 구현하기 위한 즉각적인 방안을 소개한다.

1. 표준 운영 환경
이 환경에는 컨테이너 호스트, 컨테이너 이미지, 컨테이너 엔진, 컨테이너 오케스트레이션이 포함되어 있어야 한다. 이 모든 구동부는 정렬되고 표준화되어야 하며, 함께 버전을 맞추고 테스트한 것이어야 한다. 업그레이드 역시 하나의 유닛으로 함께 계획해야 하는데, 이들 요소 간의 상호 의존성이 크기 때문이다. 인프라의 정합성은 컨테이너를 구축하거나 실행하는 모든 환경에서 보장되어야 하며, 개발자의 노트북, 테스트 서버, 가상머신 역시 마찬가지이다. 표준 운영 환경에서는 항상 똑같이 테스트하고 인증 받은 요소를 모든 곳에서 사용할 것을 권장한다.

Scott McCarty

표준 애플리케이션 정의는 여러 환경에 걸쳐 배치 자동화를 구축하는 데 필수적인 요소이다.

2. 표준 애플리케이션 정의
애플리케이션 정의에 있어서는 여러 가지 기술 선택지가 있다. 도커 컴포즈(Docker Compose), 쿠버네티스 오브젝트(Kubernetes Objects), 오픈시프트 템플릿(OpenShift Templates), 헬름 차트(Helm Charts) 등이 그것이다. 각각은 장단점이 있으니 잘 살펴보고 애플리케이션 정의 하나를 선택하자. 서로 다른 애플리케이션 정의 간에는 번역하지 않는다. 이는 한 환경의 기능이 지원되지 않거나 같은 방식으로 지원되지 않은 문제를 유발할 뿐이다.

예를 들어, 개발자가 도커 컴포즈로 구축한 애플리케이션을 프로덕션에서 쿠버네티스 오브젝트로 재구축하면 안된다. 비록 기술적으로는 가능할지 몰라도 이는 두 가지 경험, 두 가지 투자, 두 가지 버그, 두 가지 학습, 두 가지 문서화, 두 가지 문제 해결 방안 등등으로 악화된다. 최선의 방안을 한 가지 기술을 선택하고, 필요하다면 나중에 재평가해 더 나은 것으로 기술을 빨리 바꾸는 것이다.

3. 데이터 스토리지, 환경 설정, 기밀
이들 요소는 컨테이너 이미지나 애플리케이션 정의에 내장하는 것이 아니라 환경으로 제공해야 한다. 예를 들어, 개발자 노트북 상의 데이터 저장에는 신용카드 정보가 포함되지 않기를 원할 수도 있고, 프로덕션 데이터베이스 패스워드가 컨테이너 이미지에 내장되지 않기를 원할 수도 있다.

다른 한편으로, 만약 두 클라우드 서비스 업체 간을 이동한다면, 데이터를 옮기면서 동기화를 유지해야 한다. 이는 세 가지 서로 다른 수준으로 구현할 수 있는데, 블록과 파일, 트랜잭션이다. 데이터 스토리지는 컨테이너에 따라 바뀌지 않으며, 대부분 컨테이너 플랫폼은 이 작업을 처리해주지 않는다.

블록 스토리지 복제는 보통 DRBD나 SRDF, 셰프 등의 기반 기술로 처리한다. 파일 복제는 보통 RSync, 글러스터 지오 리플리케이션(Gluster Geo Replication)을 사용하거나 저지연 환경에서는 GFS2나 GPFS를 사용한다. 트랜잭션 계층에서는 데이터베이스의 일부가 되어야 하며, 각 기술마다 완전히 다르다. MySQL은 자체 트랜잭션 리플리케이션(Transaction Replication)을, 몽고DB는 자체 GRRS(Geographically Redundant Replica Sets)을 사용하며, 오라클 데이터베이스는 여러 가지 옵션을 제공한다. JBoss 데이터그리드도 자체 크로스 데이터센터 리플리케이션(Cross-Datacenter Replication)을 사용한다.

애플리케이션의 이식성을 보장하는 데는 좀 더 확장된 계획이 필요하다. 컨테이너는 이식성을 약속하지만, 호환성이 낮은 수준(컨테이너 이미지, 호스트, 엔진, 오케스트레이션), 높은 수준(애플리케이션 정의), 데이터와 환경설정, 보안 관리(동기화, 역할 기반 액세스 등) 세 가지를 고려해야만 가능하다.

Scott McCarty

애플리케이션 정의는 환경 간을 옮겨 다니지만, 환경 설정과 데이터는 환경에 의해 결정된다.

단순명료한 애플리케이션으로 시작하는 것이 좋다. 컨테이너 호스트와 이미지, 엔진, 오케스트레이션, 그리고 애플리케이션 정의를 표준화하라. 데이터와 환경설정, 보안을 어떻게 관리할지 파악하라. 하나의 애플리케이션이 성공하면, 다른 워크로드로 확장하는 것이 좋다. 모든 워크로드가 쉽지는 않을 것이다. 하지만 이들 문제를 해결하고 나면, 민첩성과 이식성을 구현하고, 애플리케이션을 더 빨리 전달하고 이를 여러 클라우드 서비스 간에 더 쉽게 이전할 수 있을 것이다.  editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106358#csidxe2cf6194cf59d3f96356dc205bec532 

클라우드 컴퓨팅 도입은 오늘날 비즈니스의 주요 원동력으로 빠르게 자리잡아가고 있다. 비용을 절감하고 애질리티를 증대시키기 위해 애플리케이션들이 온-프레미스 데이터 센터를 벗어나고 있기 때문이다.

Credit:GettyImages

아마존 웹 서비스(AWS), 마이크로소프트 애저(Azure), 그리고 구글 클라우드 플랫폼 등 주요 클라우드 업체 셋은 보안과 데이터 주권에 대한 초기 우려들을 각자 나름의 방식으로 해결하려 했다. 그리고 매우 규제가 엄격한 기업을 제외한 거의 모든 기업이 이들의 솔루션을 도입했다.

이러한 변화는 IaaS 시장을 포화 상태로 만들었고, 2016년 기준 IaaS 시장 규모는 무려 250억 달러에 이르렀다고 가트너는 최근 통계를 통해 밝혔다. 가트너는 IaaS 시장 규모가 내년이면 450억 달러 수준으로 성장할 것으로 예측했다.

IaaS는 써드파티 제공자가 하드웨어, 소프트웨어, 서버, 스토리지 등 핵심 인프라를 고객을 대신하여 호스팅 및 관리해주는 서비스 모델이다. 주로 고도의 확장적 환경에서 애플리케이션을 호스팅하고, 고객들은 실제 사용하는 인프라에 대해서만 요금을 지불하는 형식으로 이루어지고 있다.

AWS는 2006년 클라우드 서비스 공급을 시작한 이후 줄곧 시장에서 지배적 위치를 점해 왔다. 2017년 2월 시너지 리서치(Synergy Research) 보고서에 따르면 AWS의 시장 점유율은 40%에 육박하는데 MS, 구글, IBM의 점유율을 모두 합한 것이 23% 정도인 것을 고려하면 AWS의 시장 지배력을 짐작할 수 있다.

그러나 AWS의 이런 우위에도 불구하고, 마이크로소프트는 ‘클라우드 우선’ 정책을 적극적으로 펼친 CEO 사티아 나델라의 리더십 하에 빠르게 글로벌 클라우드 네트워크를 구축하며 IaaS 시장에서의 입지를 굳혀 나갔다. 또한 인터넷 거인 구글 역시 구글 클라우드 플랫폼(GCP) 하에 퍼블릭 클라우드 서비스 및 IaaS 비즈니스를 구축해 나갔다.

그렇다면 이들 세 기업의 클라우드 서비스는 어떤 차이가 있을까? 그리고 어떤 IaaS 플랫폼이 우리 기업에 가장 적합한지를 어떻게 판단할 수 있을까?

기능 및 서비스
클라우드 선택은 결국 개별 고객의 요구, 워크로드 등에 의해 좌우된다. 사실 많은 기관에서는 비즈니스 오퍼레이션별로, 혹은 사용례 별로 각기 다른 서비스를 이용하는 멀티 클라우드 방식을 채택하고 있다.

그렇지만 이러한 기업들의 클라우드 솔루션 도입 방식에도 각각 차이점이 있으며, 이런 차이점을 만드는 요소들을 이해한다면 엔드 유저 입장에서도 어떤 방식이 가장 적합한지를 판단하기 쉬워질 것이다.

AWS, 마이크로소프트 애저, 그리고 구글 클라우드 플랫폼은 유동적인 컴퓨트, 스토리지, 네트워킹과 관련해서는 대체로 유사한 기능을 보인다. 세 서비스 모두 공용 클라우드의 공통적 요소들을 지니고 있다. 셀프서비스와 인스턴트 프로비저닝(instant provisioning), 오토스케일링(autoscaling), 그리고 여기에 덧붙여 보안, 컴플라이언스, 신원 관리 기능 등이 그것이다.

세 기업 모두 클라우드 서비스에 투자를 아끼지 않는 기업들이며 이를 지원할 수 있는 든든한 모기업을 지니고 있다. 덕분에 이들 기업은 좀 더 정교하고 성숙한 애널리틱스 서비스를 제공할 수 있게 되었다. 예를 들어 AWS(엘라스틱 맵 리듀스), 애저(HD인사이트), 구글(Dataproc) 모두 하둡 클러스터를 지원한다.

컴퓨트, 스토리지, 데이터베이스뿐 아니라 애널리틱스, 네트워킹, 모바일, 개발자 툴, 매니지먼트 툴, IoT, 보안, 그리고 기업 애플리케이션에 이르기까지, AWS는 100여 개 분야를 아우르는 가장 폭넓은 서비스를 제공하는 기업이다. 하지만 이는 어느 정도는 AWS가 가장 오래된 시장 참여자이기 때문이기도 하다.

세 업체 모두 머신러닝 툴은 물론 사물 인터넷, 서버리스 컴퓨팅(AWS의 람다(Lambda), 애저 및 구글의 펑션(Functions) 등)과 같은 첨단 기술을 겨냥한 기능들을 추가했다. 고객들은 자신의 요구에 맞는 클라우드를 선택해 모바일 앱을 만들거나, 고기능 컴퓨팅 환경을 조성할 수 있게 됐다.

세 업체 모두 고유의 인터넷 전문성에 기반을 둔 강력한 머신러닝 기능을 제공함은 물론이다.

AWS는 2015년 4월 아마존 머신러닝(Amazon Machine Learning) 서비스를 출시해 개발자들의 머신러닝 모델 생성에 도움을 주었다. 그리고 지난 2016년에는 이미지 인식이 가능한 새로운 머신러닝 서비스(AWS 레코그니션)와 텍스트를 음성으로 변환하는 학습 모델(폴리), 그리고 알렉사를 구동하는 엔진(렉스)을 발표하기에 이르렀다.

구글은 오픈소스 텐서플로(TensorFlow) 딥러닝 라이브러리에 기반하여 머신러닝 모델을 제작할 수 있도록 지원하는 클라우드 머신러닝 엔진(Cloud Machine Learning Engine)을 제공한다. 또한 구글은 자연어 처리, 번역 및 컴퓨터 비전 등의 작업을 위해 규격 API 서비스를 제공하기도 한다.

마이크로소프트의 애저 머신 러닝 스튜디오(Azure Machine Learning Studio)는 알고리즘 작성, 테스트 및 설치를 위한 전문 개발자용 솔루션이자 규격 API를 위한 시장이기도 하다.

요즘 트렌드라 할 수 있는 컨테이너의 인기를 반영하여 세 업체 모두 도커(Docker) 서비스를 지원하고 있다.

세 기업 모두 파트너십을 수용하는 자세를 보이고 이로 인해 고객들 역시 다양한 앱 및 서비스를 자신의 클라우드 환경에서 시험해 볼 수 있다.

구글을 예로 들면 SAP, 피보탈, 랙스페이스와 같은 탄탄한 업체들과의 제휴를 수차례 발표하기도 했다.

컴퓨트, 스토리지, 데이터베이스, 그리고 네트워킹
컴퓨트에서 AWS의 메인 옵션은 EC2 인스턴스다. EC2 인스턴스의 장점은 다양한 옵션을 맞춤 개발할 수 있다는 것이다. 또한 앱 설치를 위한 엘라스틱 빈스톡(Elastic Beanstalk)이나 EC2 컨테이너 서비스, AWS 람다 및 오토스케일링 같은 서비스도 제공한다.

한편 애저의 컴퓨트 옵션은 보다 가상 머신(VM)에 치중해 있으며 클라우드 서비스 및 리소스 매니저 등 클라우드에 애플리케이션을 설치하기 위한 다른 툴도 함께 제공한다.

구글의 확장적 컴퓨트 엔진(Compute Engine)은 구글 데이터 센터의 VM을 제공한다. 빠른 부팅과 지속적인 디스크 스토리지, 그리고 일관된 성능을 보장하며 고객의 요구에 맞춰 유연하게 커스터마이징 할 수 있다.

세 업체 모두 관계형 데이터베이스를 지원하는 것도 공통점이다. 애저의 SQL 데이터베이스, 아마존의 릴레이셔널 데이터베이스 서비스(Relational Database Service), 레드시프트(Redshift)와 구글 클라우드 SQL, 그리고 NoSQL 데이터베이스 및 애저 도큐먼트DB, 아마존 다이나모DB(DynamoDB), 구글 빅테이블(Bigtable) 등이 그것이다.

AWS 스토리지에는 심플 스토리지(Simple Storage, S3), 엘라스틱 블록 스토리지(EBS), 엘라스틱 파일 시스템(EFS), 임포트/엑스포트(Import/Export) 대용량 데이터 전송 서비스, 글레시어(Glacier) 아카이브 백업 및 온-프레미스 환경과 통합되는 스토리지 게이트웨이(Storage Gateway) 등이 포함된다.

마이크로소프트의 서비스에는 핵심 애저 스토리지 서비스, 애저 블롭(Blob) 블락 스토리지, 테이블(Table), 큐(Queue), 파일 스토리지 등이 포함된다. MS 사는 또한 사이트 리커버리(Site Recovery), 임포트/엑스포트(Import/Export), 애저 백업(Azure Backup) 등도 제공한다.

세 기업 모두 전반적으로 훌륭한 네트워킹 기능을 보장하며 자동화된 서버 로드 밸런싱과 온-프레미스 시스템에 대한 연결성을 약속한다.

원문보기: 
http://www.ciokorea.com/news/35680#csidx86dbcd8322f14c39a50155fab59a92c 

서비스 형태의 플랫폼(Platform-as-a-service, PaaS)은 서비스 제공업체가 고객에게 플랫폼을 제공함으로써 고객이 일반적으로 소프트웨어 개발 프로세스에 필요한 인프라를 구축하고 유지할 필요 없이 비즈니스 애플리케이션을 개발, 실행, 관리할 수 있도록 하는 클라우드 컴퓨팅 유형이다.

서비스 형태의 인프라(IaaS), 서비스 형태의 소프트웨어(SaaS)와 같은 다른 클라우드 서비스와 마찬가지로 PaaS는 클라우드 서비스 제공업체의 호스팅 인프라를 통해 제공된다. 사용자는 일반적으로 웹 브라우저를 사용해 PaaS에 접속한다.

Getty Images Bank

PaaS가 제공되는 경로에는 퍼블릭, 프라이빗 또는 하이브리드 클라우드가 있다. 퍼블릭 클라우드 PaaS의 경우 클라우드 제공업체가 서버, 스토리지 시스템, 네트워크, 운영 체제, 데이터베이스 등 애플리케이션을 호스팅하는 데 필요한 모든 주요 IT 구성 요소를 제공하며, 고객은 소프트웨어 개발을 관리한다.

프라이빗 클라우드에서 PaaS는 고객 방화벽 내, 일반적으로 구내 데이터 센터에 소프트웨어 또는 어플라이언스 형태로 제공된다. 하이브리드 클라우드 PaaS는 위 두 가지 유형의 클라우드 서비스를 혼합해 제공한다.

PaaS는 소프트웨어 개발을 위한 조직의 IT 인프라 전체를 대체하는 것이 아니라 애플리케이션 호스팅 또는 자바 개발과 같은 핵심 서비스를 제공한다. 일부 PaaS에는 애플리케이션 설계, 개발, 테스트 및 배포까지 포함되기도 한다. 또한 웹 서비스 통합, 개발 팀 협업, 데이터베이스 통합 및 정보 보안도 PaaS 서비스에 포함될 수 있다.

다른 유형의 클라우드 서비스와 마찬가지로 PaaS 고객은 사용량에 따라 비용을 지불하지만 일부 제공업체는 월 정액 요금제로 플랫폼 및 플랫폼에 호스팅되는 애플리케이션 접근 기능을 제공한다.

PaaS의 비즈니스 혜택과 동력
PaaS의 가장 큰 장점 가운데 하나는 서버와 데이터베이스가 포함된 인프라를 구축하고 유지하느라 시간과 비용을 투자할 필요 없이 새로운 애플리케이션을 만들고 배포하기 위한 환경을 확보할 수 있다는 것이다.

따라서 애플리케이션 개발 및 전달 속도를 높일 수 있고, 이는 경쟁 우위를 얻을 방법을 물색하거나 신속하게 제품을 출시해야 하는 기업에게 큰 이점이 된다.

또한 PaaS는 새 언어와 운영 체제, 데이터베이스 및 기타 개발 기술 사용을 신속하게 테스트할 수 있다. 이를 위한 지원 인프라를 마련할 필요가 없기 때문이다. 아울러 PaaS는 툴을 더 쉽고 빠르게 업그레이드할 수 있게 해준다.

PaaS를 사용하면 엔터프라이즈 소프트웨어 개발자는 애플리케이션에서 클라우드 기술을 사용할 수밖에 없으므로 현대적인 원칙을 받아들이고 클라우드 인프라(IaaS) 플랫폼을 더 잘 활용하게 된다.

PaaS를 사용하는 조직은 애플리케이션 및 데이터를 직접 관리할 수 있으므로 클라우드 인프라 또는 애플리케이션을 사용할 때 자주 거론되는 통제력 상실은 큰 문제가 되지 않는다.

일반적인 PaaS 응용 사례
애플리케이션 개발과 테스트를 위한 호스팅 환경을 제공하는 것은 PaaS의 가장 일반적인
용도 가운데 하나다. 그러나 그 외에도 엔터프라이즈에서 PaaS를 사용하는 이유는 많다.
시장조사 업체 가트너는 다음을 포함한 다양한 PaaS 사용 사례를 언급했다.

API 개발 및 관리 : 기업은 PaaS를 사용해서 애플리케이션 프로그래밍 인터페이스와 마이크로서비스를 개발, 실행, 관리, 보호할 수 있다. 여기에는 새 API 및 기존 API를 위한 새 인터페이스 만들기, 종단간 API 관리가 포함된다.

비즈니스 분석/인텔리전스 : 기업은 PaaS를 통해 제공되는 툴을 사용, 데이터를 분석해서
비즈니스 통찰력과 행동 패턴을 찾아 더 현명한 의사 결정을 내리고 제품의 시장 수요와 같은 미래를 더 정확히 예측할 수 있다.

비즈니스 프로세스 관리(BPM) : 조직은 PaaS를 사용해 다른 클라우드 요소와 마찬가지로 서비스로 제공되는 BPM에 접근할 수 있다. BPM에는 데이터, 비즈니스 규칙 및 서비스 수준 협약을 포함한 프로세스 관리를 위해 필요한 IT 구성 요소가 통합되어 있다.

통신 : PaaS는 통신 플랫폼을 위한 전달 메커니즘 역할도 할 수 있다. 이를 통해 개발자는 음성, 비디오, 메시징과 같은 통신 기능을 애플리케이션에 추가할 수 있다.

데이터베이스 : PaaS 제공업체는 조직 데이터베이스 구축 및 유지와 같은 서비스를 제공할 수 있다. 시장조사 업체 포레스터 리서치는 데이터베이스 PaaS를 “데이터베이스 프로비저닝과 관리를 자동화하고 개발자와 비기술 인력이 사용할 수 있는 안전하고 확장 가능한 주문형 셀프 서비스 데이터베이스 플랫폼”으로 정의한다.

사물인터넷 : IoT는 향후 PaaS 사용에서 큰 부분을 차지할 것으로 전망된다. 다양한 IoT 배포에서 사용될 광범위한 애플리케이션 환경과 프로그래밍 언어 및 툴을 지원하게 된다.

마스터 데이터 관리 : 기업이 소유한 핵심 비즈니스 데이터를 관리하는 프로세스, 거버넌스, 정책, 표준 및 툴을 포괄하며 데이터를 위한 단일 참조 지점(single point of reference)을 제공한다. 이러한 데이터에는 고객 거래에 관한 정보 등의 참조 데이터, 의사 결정을 지원하기 위한 분석 데이터가 포함될 수 있다.

PaaS 기술과 제공업체
PaaS에는 서버, 네트워킹 장비, 운영 체제, 스토리지, 미들웨어, 데이터베이스 등 여러 기본 클라우드 인프라 구성 요소가 포함된다. 이러한 모든 요소는 서비스 제공업체가 소유 및 운영한다.

PaaS에는 개발 툴, 프로그래밍 언어, 라이브러리, 데이터베이스 관리 시스템 및 제공업체의 기타 툴과 같은 리소스도 포함된다.

주요 PaaS 벤더로는 아마존 웹 서비스, 마이크로소프트, 구글, IBM, 세일즈포스닷컴, 레드헷, 멘딕스(Mendix), 허로쿠(Heroku)가 있다. 일반적으로 사용되는 언어, 라이브러리, 컨테이너 및 관련 툴은 대부분 모든 주요 PaaS 제공업체 클라우드에서 사용 가능하다.

이러한 업체들 중 소프트웨어 개발 툴 분야의 선두 제공업체가 여럿 있는 것은 우연이 아니다. 가트너는 현재 약 200개의 PaaS 제공업체가 있는 것으로 추산한다.

PaaS 위험
PaaS는 클라우드 기반 서비스인 만큼 따르는 위험도 다른 유형의 클라우드와 대체로 비슷하다. 정보 보안이 대표적인 예다. PaaS는 네트워크 및 서버와 같은 공유 리소스 사용 개념을 기반으로 한다. 따라서 이 환경에 데이터를 보관하다가 무단 접근 또는 해커 등의 공격으로 인해 이 데이터가 누출될 수 있다는 보안 측면의 위험이 있다.

그러나 다른 한편으로 주요 클라우드 제공업체들은 일반적인 기업 데이터 센터에 비해 이와 같은 유출을 더 효과적으로 차단해왔으며 초기에 많은 IT 전문가들이 우려했던 것과 같은 정보 보안 위험은 발생하지 않았다.

PaaS를 이용하면 기업은 인프라와 운영에 적절한 접근 제어를 비롯해 기타 보안 프로비전 및 정책을 마련하는 작업을 서비스 제공업체에 맡기게 된다. 애플리케이션을 위한 자체 보호 기능을 제공하는 것은 기업의 책임이다.

조직은 특정 서비스 제공업체의 인프라 및 소프트웨어에 의존하므로 PaaS 환경에서는 잠재적인 벤더 종속 문제가 있다. 따라서 IT 부서는 선택하고자 하는 PaaS가 현재와 미래의 IaaS 및 SaaS 환경과 호환되는지 여부를 따져봐야 한다.

PaaS의 또 다른 위험은 서비스 제공업체의 인프라 환경이 어떤 이유로 다운되어 서비스에
영향을 미칠 수 있다는 점이다. 또한 제공업체가 개발 전략, 프로그래밍 언어 또는 기타 영역을 변경할 경우 어떻게 될지도 생각해야 한다.

이러한 장애물로 인해 PaaS 도입이 계속 막히는 것은 아니다. 기업이 프로그래밍에 전념하는 동안 벤더는 플랫폼을 담당하므로 PaaS는 더 높은 유연성을 제공한다. editor@itworld.co.kr

원문보기: 
http://www.itworld.co.kr/news/106437#csidxecb1ddfcd657380a773e1e25abf882a 

□ 하이퍼바이저의 역할

하이퍼바이저는 VMM(Virtual Machine Monitor)라고도 불리며, 크게 Type1(Native), Type2(Hosted)로 나눌수가 있습니다.

□ 하이퍼바이저의 종류

① Type1 (네이티브 방식)

네이티브 방식은 호스트 OS가 필요 없는 구조이며, 물리 컴퓨터의 하드웨어상에서 직접 동작을 합니다. 게스트 OS 모니터로 호스트의 하드웨어에서 직접 실행하는 구조입니다. 이러한 구조의 장점으로는 호스트 OS와의 연동이 필요 없으므로, 명령어 전환에 대한 오버헤드가 적어서 빠른 속도를 제공할 수 있으며, 물리 컴퓨터의 리소스를 바로 컨트롤하기 때문에 유연합니다. 단점으로는 자체적으로 관리 기능을 가지고 있지 않기 때문에 별도의 관리 컨설이 필요합니다. 아래 그림은 Type1 (네이티브 하이퍼바이저)의 개념도인데, 하이퍼바이저층과 하드웨어층 사이에 호스트 OS가 존재하지 않습니다.

[ Type 1 (네이티브 하이퍼바이저) 개념도 I ]

[ Type 1 (네이티브 하이퍼바이저) 개념도 II ]

② Type2 (호스트형 방식)

기존의 OS환경에서 실행되는 소프트웨어 응용 프로그램입니다. 하이퍼바이저가 물리 컴퓨터상의 호스트 OS 위에서 동작을 합니다. 이 구조의 장점으로는 게스트 OS 종류에 대해서 제약사항이 없다는 것으로, Windows에서 FreeBSD까지 다양한 게스트 OS들이 동작할 수 있으며, 컴퓨터도 데스크톱, 노트북 형태에서도 동작을 합니다. 단점으로는 물리 컴퓨터의 하드웨어를 에뮬레이트 하기 때문에 오버헤드가 큽니다.

[ Type 2 (호스트형 하이퍼바이저) 개념도 I ]

[ Type 2 (호스트형 하이퍼바이저) 개념도 II ]

하이퍼바이저 또는 버추얼 머신 모니터(VMM)라고 하는 소프트웨어가 호스트 OS 위에 설치되며, 이를 통해서 사용자들은 어플리케이션 윈도우내에서 다양한 Guest OS를 실행할 수 있습니다. 호스트형 가상화는 물리 컴퓨터의 하드웨어를 에뮬레이트하기 때문에 오버헤드는 크지만, Guest OS 종류에 대한 제약이 없어서, 거의 대부분의 OS(Windows, Linux, etc.)에서 동작시킬 수 있습니다.

[ 호스트형 가상화 개념도 ]

호스트형 가상화의 장점으로는 사용자가 호스트 OS를 수정하지 않고도 VM 아키텍처를 설치할 수 있습니다. 가상화 소프트웨어는 호스트OS에 의존하여 장치 드라이버 및 기타 저수준 서비스를 제공할 수 있습니다. 이로 인하여 VM의 설계가 간소화되고 배포도 쉬워집니다. 호스트형 가상화의 단점으로는 성능이 하이퍼바이저나 VMM을 사용하는 가상화에 비해서 낮을 수 있습니다. 예를 들면, 응용 프로그램에서 하드웨어 액세스를 요청하면 4개의 매핑 계층을 통과해야 하기 때문에 성능이 크게 저하됩니다.

호스트형 가상화 소프트웨어 종류는 VMware의 VMware Workstation, VMware Server, VMware Player, 마이크로소프트의 Virtual Server 2005 R2, Virtual PC, SUN의 VirtualBox, Parallels의 Parallels Workstation등이 있습니다.

서버의 가상화는 많은 회사들이 안고 있는 하드웨어의 관리, 재난에 의한 시스템의 신속한 복구등 여러가지 문제를 해결해줄 수 있는 방법으로 각광을 받고 있습니다. 이런 서버의 가상화는 크기 두가지로 분류할 수 있습니다. 하나는 하이퍼바이저(Hypervisor)형과 또 하나는 호스트(Hosted)형 가상화로 나눌 수 있습니다.

① 하이퍼바이저(Hypervisior)형

하이퍼바이저형 가상화는 VMM(Virtual Machine Monitor)을 물리 컴퓨터의 하드웨어상에 직접 동작을 시키는 방법으로 호스트 OS가 필요없습니다. 호스트 OS에 할당할 리소스가 필요없기에 호스트형 가상화에 비해 오버헤드가 적고 물리 컴퓨터 리소스의 관리가 유연한게 특징입니다만, 자체적으로 관리기능을 갖고 있지 않기에 별도의 관리콘솔이 필요합니다. 이런 하이퍼바이저형 가상화 소프트웨어에는VMware의 ESX/ESX i Server, itrix의 XenServer, Oracle의 VM Server, 썬의 xVM Server, 마이크로 소프트의 Hyper-V, Virtual Iron의 Virtual Iron, Parallels의 Parallels Server등이 있습니다. 하이퍼바이저(Hypervisor)형 가상화에는 전가상화와 반가상화로 나뉩니다.

(a) 전가상화(Full-Virtualization)

전가상화는 게스트 OS(Guest OS)와 네이티브 하드웨어(Native Hardware) 사이를 중재하는 가상 머신을 사용합니다. VMM(Virtual Machine Monitor)이 게스트 OS와 기반 하드웨어 사이를 중재하기 때문에 보호를 받고 있는 특정 명령어들은 기반 하드웨어를 OS가 소유한 것이 아니라 하이퍼바이저를 통해서 공유되기 때문에 하이퍼바이저 내에서 트랩핑과 핸들링이 되어야합니다. 전체 가상화는 하드웨어 에뮬레이션보다는 빠르지만 하이퍼바이저 중재 때문에 실제 하드웨어 보다 성능이 낮아집니다.

일반적인 응용 프로그램에서는 하이퍼바이저를 거치지 않고 바로 실행이 되지만, OS 레벨의 명령은 Binary Translation을 거쳐 하이퍼바이저를 통해서 하드웨어로 전달이 됩니다. Gust OS는 커널을 수정하지 않아도 되며, 하이퍼바이저의 존재 또한 모릅니다. OS 레벨의 명령은 하이퍼바이저에서 담당하며, 이를 변환(Binary Translation)하여 하드웨어로 전달하게 됩니다.

[ 전가상화 개념도 ]

전가상화는 하드웨어를 완전히 가상화하는 방식으로 게스트 OS에 대한 수정이 필요없고, Windows에서 Linux까지 다양한 OS를 이용할 수 있다는 장점이 있습니다. 단점은 OS 레벨의 명령 수행시에는 Binary Translation이 발생하는데, 이 과정에서 상당한 오버헤드가 발생합니다. 이러한 이유로 가상화 되지 않은 시스템에 비해서 성능저하가 발생합니다.

(b) 반가상화(Para-Virtualization)

전가상화와 유사한 부분이 많습니다. 차이점은 Guest OS의 커널이 하이퍼바이저에 맞게 수정을 해야 합니다. 반가상화는 전가상화와 마찬가지로 일반적인 명령어는 하이퍼바이저를 거치지 않고 바로 실행이 되며, OS 명령어의 경우에는 하이퍼바이저에 전달이 되지만 바이너리 전환(Binary Translation)이 발생하지 않으며, 이로 인하여 재컴파일이나 트래핑(trapping)을 할 필요가 없습니다.

반가상화의 장점은 바이너리 전환(Binary Translation)이 발생하지 않으며, 가상화 되지 않은 시스템과 동일한 성능을 낸다는것입니다. 반가상화 단점으로는 반가상화를 실현하기 위해서는 게스트 OS의 커널 일부분을 수정해야 한다는 점입니다. 따라서 윈도우와 같이 소스 공개가 되어있지 않은 OS의 경우에는 Guest OS로 사용할 수 없습니다.

[ 반가상화 개념도 ]

중앙 처리 장치(CPU), 기억 장치, 입출력 등 단일 플랫폼상의 서버 자원을 사용자가 여러 도메인이나 서버 애플리케이션으로 분할해 사용할 수 있는 기술입니다. 서버 가상화의 장점은 물리적으로 1대의 시스템상에서 각기 다른 OS의 서버 애플리케이션을 효율적으로 운영 가능하며 비용 절감 및 서버 자원의 효율적인 활용이 가능합니다.

서버 가상화를 통하면 CPU나 서버 등 물리 자원에 얽매이지 않고 가상의 단위로 분리하여 시스템을 활용할 수 있습니다. 예를 들어 한 대의 서버를 여러 대의 서버가 있는 것처럼 나누어 각기 다른 운영체제를 올려 활용하거나 여러 대의 서버를 한대의 서버처럼 활용할 수 있기 때문에 자원 활용률을 높일 수 있고 관리의 편의성도 크게 향상할 수 있습니다.

서버 가상화를 통해 구현할 수 있는 강점은 서버 통합으로 서버 활용도를 높일 수 있다는 것입니다. 일반적인 데이터 센터는15% 정도의 낮은 활용도를 보입니다. 이 때문에 활용도를 개선하는 것이 불 필요한 데이터 센터 서버 확장을 줄일 수 있는 방법입니다. 서버 가상화 기술은 운용 체계와 물리적 하드웨어를 분리시켜 구동함으로써 다양한 OS 인스턴스들을 하나의 물리 서버에서 실행할 수 있도록 합니다. 이를 통해 하나의 서버에 다양한 애플리케이션들을 구동할 수 있도록 하여 서버 수용량을 최적화하고 데이터 센터 내에 필요한 서버 수를 줄일 수 있습니다. 최근에는 간편한 애플리케이션 배포, 프로비저닝 및 인프라스트럭처의 관리까지 포괄적으로 포함되어 있는 통합 솔루션이 시장에 나와 있습니다.

서버 가상화의 단점으로는 고객의 운영 툴과 스토리지 공유장비, 신규서버 등 초기 도입 비용이 비쌉니다. 서버 가상화의 다양한 방식으로는 하드웨어를 파티션으로 나누어 각기 다른 OS를 설치하는 방식과 다중 OS와 하드웨어 사이에 가상화의 계층을 두는 방식등이 있습니다.

[ 서버 가상화 ]

데스크톱 가상화는 애플리케이션 가상화에서 한 발 앞서 나간 이야기입니다. VDI(Virtual Desktop Infrastructure)는 서버에 아예 통째로 클라이언트 OS 환경 자체를 올려놓고 이를 원격의 단말을 통해 활용하는 것입니다. 광의의 SBC(Server Based Computing) 라고 할 수 있습니다. 서버 가상화처럼 서버를 가상화하여 여러 개의 가상 머신들을 만드는데, 이 가상 머신에 서버 OS들을 설치하는 것이 아니라 클라이언트 OS, 즉 윈도7, 윈도XP, 리눅스 등을 설치합니다. 사용자는 원격의 PC나 노트북에서 이곳에 접근하여 활용합니다. 사용자가 접속하는 PC는 고사양 또는 저사양을 가릴 필요가 없습니다. 여기까지는 프리젠테이션 가상화와도 매우 유사합니다. 차이점은 최종 사용자의 입장에서는 VDI는 마치 자기 PC를 사용하듯이 모든 데스크톱 환경을 영유하는 것입니다.

IT 조직에 있어 데스크탑의 관리는 시간과 비용이 많이 소모되는 일상적인 작업입니다. 그러나 데스크탑 가상화는 가상화 기술을 통해 데이터 센터로부터 최신 데스크탑 환경을 보다 손 쉽게 업그레이드 할 수 있습니다. 관리 측면에서 비용을 절감하면서 사용자에게 더욱 빠른 지원이 가능하다는 장점이 있으며, 사용자들 또한 일일이 지원을 기다릴 필요 없이 최신의 데스크탑 환경을 유지하면서 업무에 집중할 수 있게 됩니다.

[ 가상 데스크탑 시스템 개념도]

애플리케이션 가상화는 애플리케이션 자체를 가상화 운영체계와 묶어서 서버에 가지고 있다가 이 애플리케이션을 사용하기 원하는 PC나 다른 서버에 애플리케이션 자체를 전송합니다. 애플리케이션 가상화에서 이용하고자 하는 애플리케이션은 가상 시스템 파일, 가상 레지스트리를 가진 가상 OS(Virtual OS)와 하나로 패키징됩니다. 이를 샌드박싱한다고 하는데, 샌드박싱에 의해 가상화된 애플리케이션은 해당 클라이언트 또는 해당 서버로 내려와서 그 곳의 자원을 활용하여 실행됩니다.

예를 들어 MS 파워포인트를 애플리케이션 가상화 환경에서 이용하게 되면 이 MS 파워포인트는 VOS(Virtual OS)와 결합한 상태로 요청되는 사용자에게 보내집니다. 따라서 실행되는 PC, 서버의 하드웨어 자원은 애플리케이션을 구동할 수 있는 정도의 사양은 확보해야 합니다. 관리자의 설정에 따라 작업 종료후에도 애플리케이션이 PC나 서버에 남아 있을 수도 있고, 제거될 수도 있습니다.

인터넷에 애플리케이션 가상화 관련 자료를 검색하다보면, 애플리케이션 가상화와 프리젠테이션 가상화를 같은 의미로 설명하는 곳이 있는데, 서로 다른 의미를 가지고 있습니다. 먼저, 애플리케이션 가상화는 서버에서 사용자 PC로 애플리케이션이 다운로드되어 실행되는 것이고, 프리젠테이션 가상화는 애플리케이션을 중앙 서버에 설치하고 가상의 인터페이스만 네트워크를 통해 보내는 기술입니다. 사용자가 애플리케이션을 사용하면서 키보드를 입력하거나 마우스를 클릭한 정보가 네트워크를 통해서 서버로 보내지게 되며, 스크린은 사용자 디바이스에 업데이트된 정보를 전달하게 되어 실제로는 어떠한 데이터도 사용자 디바이스에서 저장되지 않는 형태입니다.

프리젠테이션 가상화는 N(클라이언트) : 1(서버)로 구성이 된다면, 애플리케이션 가상화 환경에서는 1(클라이언트) : 1(서버)로 구성이 된다는 것입니다. 프리젠테이션 서버, 즉 과거 SBC 환경에서 가상화가 공유에 초점을 맞췄다면, 애플리케이션 가상화는 보안과 사용자별 독립성을 보장하는 가상화입니다. 프리젠테이션 가상화 환경에서는 사용하는 애플리케이션에 장애가 일어날 경우 다른 사용자도 사용할 수 없게 됩니다. 하지만 애플리케이션 가상화에서는 이러한 한계가 없습니다.

 □ 특징 및 장점