학습(공부)하는 블로그 :: '컴퓨터 활용/클라우드 컴퓨팅' 카테고리의 글 목록
 

 

Notice»

Recent Post»

Recent Comment»

Recent Trackback»

03-19 10:55

 
 

[15강] 공공 클라우드

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 16. 14:44 | Posted by 깨비형
반응형

1. 공공 클라우드 컴퓨팅 서비스의 필요성

 

  ○ 최근의 ICT 기술 중에 가장 각광 받고 있는 분야 중의 하나가 바로 클라우드 컴퓨팅이다.

 

  ○ 시장조사기관인 IDC의 2009년부터 2013년까지의 클라우드 컴퓨팅 서비스에 대한 전망 보고서에 의하면, 전체 ICT 관련 지출의 10%인 442억 달러가 클라우드 서비스 지출 비용으로 소요된다고 예상하였다.
    ▷ 특히, 클라우드 서비스 관련 매출의 성장세는 다른 전통적인 ICT 제품에 비하여 여섯 배 이상이 될 것 이라고 전망하였다.
    ▷ 또한, 미국, 일본, 영국, 독일 등의 선진국들은 탄소량 배출 감소를 위한 Green ICT의 구현과 예산을 절감하고 새로운 성장 동력을 발굴하기 위하여 클라우드 컴퓨팅 기술을 도입하고 적용하는데 적극적이다.

 

  ○ 이에 비하여 우리나라는 2009년에 이르러서야 정부 및 민간 차원에서 클라우드 컴퓨팅 도입을 위한 움직임에 들어가기 시작하였다.
    ▷ 이와 같은 문제점을 인식하고 정부에서는 클라우드 컴퓨팅과 관련하여 주도적인 역할을 수행하기 위해서 각종 연구와 정책에 대한 수행하고 있다.
    ▷ 본 마지막 강의는 이러한 움직임에 대응하기 위하여, 국가적으로 클라우드 컴퓨팅 기술을 공공부문에 적용할 수 있는 분야를 발굴하여, 적용 가능한 시나리오로 제안하였던 내용을 소개한다.

 

  ○ 선행조건
    ▷ 클라우드 컴퓨팅을 공공부문에 적용하기 위해서는 가장 먼저 선행되어야 할 작업이 바로 관련 법률 및 각종 제도의 정비가 선행되어야 한다.
    ▷ 또한 클라우드 컴퓨팅 환경을 고려한 SLA 관련 표준이 필요하다.
      -  특히 공공부문에 적용하기 위해서는 하드웨어 플랫폼의 경우 공공부문의 제품을 활용하고, 해당 소프트웨어만 민간 업체의 서비스 혹은 솔루션을 사용하기 때문에 이 부분에 대한 고려가 필히 반영되어야 한다.
      - 보안에 관련된 이슈의 경우, ‘공공기관의 개인정보보호에 관한 법률’ 등과 같은 기존의 법률들을 이용해 적용이 가능하나 KISA의 정보보호관리체계인증과 정보보호 안전진단제도 경우에는 정비가 필요하다.
    ▷ 또한, 클라우드 컴퓨팅과 관련된 민간 기업을 육성하고, 좀 더 나은 서비스를 제공받기 위해서는 다양한 업체들의 서비스를 선택할 수 있어야 한다.
      -  이런 환경을 구축하기 위해서는 클라우드 컴퓨팅과 관련된 각종 기반 기술들을 표준화해야 한다.
    ▷ 이밖에도 클라우드 컴퓨팅과 관련된 전문적인 인력을 양성하기 위한 새로운 학과의 신설이나 기존에 존재하는 학과들을 활용한 특화된 전문가 과정 등의 개설을 고려해야 한다.

 

 

2. 공공 클라우드 컴퓨팅 서비스의 유형

 

  ○ 공직자 통합 메일 시스템의 SaaS로의 전환이 필요한 이유
    ▷ 기존의 공직자 통합 메일 시스템의 경우 한번 구축되고 난 후에는 최소 2~3년에서 5~6년 동안은 버그 수정 및 기능 개선만이 이루어지는 경우가 대부분이다. 이와 같이 상업용(실제 사용료는 무료)으로 제공되는 각종 서비스들은 사용자의 요구 및 새로운 기술에 적극적으로 대처하고 있지만, 부처에서 운영하고 있는 메일 서비스들은 몇 년 전의 제품을 사용하고 있는 경우가 대부분이다.
    ▷ 현재, 공직자 통합 메일 시스템의 사용률이 매주 저조하다. 이는 통합 메일 시스템을 구축할 당시에 사용자의 아이덴티티 (기존 메일 주소 사용 보장 여부)를 전혀 고려하지 않았다는 점이다.
    ▷ 정부에서 제공하는 소프트웨어 및 하드웨어에 대한 구성원의 불신감 때문이다. 대부분의 공공 부문의 메일 시스템은 새로운 제품을 도입하는 경우 기존 보관 중의 메일의 전환이 지원되지 않거나, 전환되더라도 불편한 경우가 대부분이었다.
    ▷ 전환을 수행하더라도 기술적인 제약 조건이 거의 없으며, 기존 업무에 큰 영향을 미치지 않기 때문에, 전환을 수월하게 수행할 수 있다. 또한, 클라우드 컴퓨팅 기술의 공공부문 적용에 대한 다양한 적용 결과를 얻을 수 있다.

 

  ○ 공직자 통합 메일 시스템의 SaaS기반으로의 전환 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  사용자 선호도를 조사한다.
      -  Open 메일 시스템 아키텍쳐를 결정한다.
      -  업체 선정 절차를 시행한다.
      -  Private Cloud 기반에 메일 시스템을 구현한다.
      -  개발 완료 테스트를 시행한다.
      -  기존 메일 시스템 이전 작업을 시행한다.
      -  시범 운용을 추진한다.
      -  운용 및 유지보수를 진행한다.

 

 

  ○ 예상 효과 및 문제점
    ▷클라우드 컴퓨팅 전환으로 인한 정부 통합 메일 시스템의 활용도를 증가할 수 있다.
    ▷각 부처 및 공공기관에서 운용하던 메일 서비스의 통폐합으로 인하여 예산 절감의 효과 및 탄소 배출을 줄일 수 있는 그린 ICT 기술의 구현이 가능하다.
    ▷클라우드 컴퓨팅의 도입을 위한 공공부문에서의 최초의 선례를 제시함으로써, 향후 클라우드 컴퓨팅 기술의 도입에 발판을 마련할 수 있다.

 

  ○ 전자결재 및 문서관리 시스템의 SaaS로의 전환이 필요한 이유
    ▷ 정부의 각 부처 및 모든 하위 기관에서 활용 중인 모든 응용 프로그램들 중에서 가장 많이 사용되는 시스템이기 때문에 SaaS 기반으로 전환하는 경우 전환에 따른 파급 효과가 크며, 적용과 관련되어 다양한 경험적인 결과를 얻을 수 있다.
    ▷ 다양한 행정 정보 시스템들 중에서 각 조직별 단위화가 가능한 시스템이다.

 

  ○ 전자 결재 및 문서 관리 시스템의 SaaS기반으로의 전환 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  사업 추진에 따른 기초 예비 조사를 한다.
      -  요구사항 수렴 및 분석을 한다.
      -  Open Document 및 Open 전자결재 시스템 구조를 결정한다.
      -  참여 업체 선정 절차를 시행한다.
      -  광역 ICT 센터 기반의 Private Cloud 형 전자결재 및 문서관리 시스템을 구현한다.
      -  개발 완료 테스트를 시행한다.
      -  기본 문서자료를 이전한다.
      -  시범 운용을 시행한다.
      -  운용 및 유지보수를 진행한다.

 

 

  ○ G-Apps의 정의
    ▷ 각 부처 및 기관을 위한 SaaS 기반의 응용 프로그램들을 민간 기업들이 등록하고, 해당 응용 프로그램을 부처 및 공공기관에서 도입하여 사용하는 형태의 공공부문 전용의 오픈 마켓을 의미한다.

  ○ G-Apps의 구축이 필요한 이유
    ▷ 기존에 활용중인 각종 프로그램을 한꺼번에 SaaS 기반으로 전환하는 것은 기존에 활용중인 응용 프로그램과 다른 형태의 인터페이스로 인하여 구성원의 불편을 야기할 수 있다.
    ▷ 전 세계적으로 공공 부문에서 기존에 사용하던 모든 응용 프로그램을 SaaS로 전환한 사례가 없다. 미국의 경우에도 간단한 응용 프로그램부터 적용하고 있는 단계이다.
    ▷ 현재 수행하고 있는 구매 방식의 경우 정확한 수요 조사 방식이 아닌 단순하게 근무하고 있는 총인원의 수 혹은 보유 개인용 PC의 단순 수량을 기준으로 하고 있기 때문에 일정 부분 예산 낭비에 대한 위험 요소를 내포하고 있다.
    ▷ 사용하지 않는 불필요한 소프트웨어 기능에 대한 예산 소요가 발생하고 있다.

 

  ○ G-Apps의 구축 절차
    ▷아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  G-Apps의 도입에 따른 기초 조사를 시행한다.
      -  G-Apps를 위한 Open Market에 대한 요구사항 수집 및 분석을 시행한다.
      -  G-Apps를 위한 Open Market을 구현한다.
      -  Open Market을 시험하고, 운용한다.
      -  G-Apps 등록 및 도입한다.

 

 

  ○ G-Apps의 구축 에 따른 예상효과
    ▷클라우드 컴퓨팅 도입에 따른 효과에 관한 다양한 연구 결과에 의하면, 기업용 응용 프로그램을 클라우드 컴퓨팅 기술로 5 년간 적용하는 경우 기존 환경에 비하여 1/3 수준으로 비용을 절감할 수 있으며, e-메일과 같은 개인용 응용 프로그램의 경우에도 5배에서 10배에 해당하는 비용 절감을 가져올 수 있다고 한다.
    ▷SaaS 기반의 소프트웨어 적극적은 활용으로 재택 근무의 활성화를 유도할 수 있으며, 엄청난 탄소 절감 효과 및 비용 절감 효과를 가질 수 있다.

 

  ○ GAP의 정의
    ▷ 정보화 프로젝트에 효과적으로 활용할 수 있는 서비스 지향적인 공공부문 개발 플랫폼 (PaaS)인 Governmental Application Development Platform (GAP)을 의미한다.
    ▷ 아마존의 EC2와 S3의 개념을 도입한 것으로서 구축되어 있는 공공 정보 데이터베이스를 활용하여 공공부문과 연관된 각종 서비스들을 누구나 개발하고, 사용 할 수 있도록 지원하는 개발 플랫폼이다.
    ▷ GAP은 SOA 개념을 적용하여, 모든 공공부문의 업무들을 BPM을 적용하여 비즈니스 프로세스들로 정의하고, 비즈니스 프로세스들을 조합하여 사용자에게 서비스를 제공할 수 있도록 지원한다.
    ▷ 지원되는 언어로는 Java와 C++이며, 공통기능 서비스의 경우 오픈 API를 제공하며, GAP을 통하여 생성되는 모든 문서들은 오픈 문서 기반으로 저장된다.

 

  ○ GAP의 구축이 필요한 이유
    ▷ 공공부문의 정보화의 경우 양적으로는 엄청난 성장을 이루었으나, 전자정부 이용실태에 의하면 전자정부서비스의 이용율은 41.1%에 불과한 실정이다.
    ▷ 또한 스위스국제경영개발원의 세계경쟁력보고서에 의하면 우리나라 정부의 행정효율성은 2008년에 37위 등 에 그치는 등 ICT 인프라에 비하여 저조한 평가를 받고 있다.
    ▷ 행정정보와 관련된 정보화 시스템을 설계, 구현하는 경우, 가장 큰 문제는 서비스를 제공 받는 사용자의 입장보다는 개발하는 사람의 관점에서부터 시작되기 때문이다.
    ▷ 국가 정보화 기본 설계 (Natioanl EA)의 부재로 인하여 부처 간의 중복 투자로 인한 예산 낭비 등의 문제가 야기되고 있다.

 

  ○ GAP의 구축 절차
    ▷ 아래의 그림에 도시 된 것과 같이 다단계의 과정으로 진행된다.
      -  클라우드 컴퓨팅 기반의 범국가적인 EA를 수립한다.
      -  요구사항 수집 및 분석을 시행한다.
      -  공공부문의 전 업무에 대한 BPM 시행과 GBP을 도출한다.
      -  기존의 구축된 데이베이스의 통합 및 재배치를 시행한다.
      -  오픈 아키텍쳐 형태의 ESB 기반의 GAP의 설계 및 구축한다.
      -  운용 및 민간부문에 단계적인 개방 절차 시행

 

  ○ 예상 효과
    ▷ GAP은 공공부문 정보 서비스를 개발하는데 필요한 모든 기반 기술을 제공하는 시스템이다.
    ▷ 공공부문 정보 서비스 개발에 필요한 대부분의 핵심 기능들은 GAP에서 오픈 API형태로 제공되기 때문에 모든 정보화 사업의 개발 시간 및 개발 비용의 감소를 유발할 수 있으며, 이로 인하여 예산 절감 효과를 가져 올 수 있다.
    ▷ 공공 데이터베이스와 오픈 API를 활용한 다양한 형태의 공공 부문 정보 서비스들이 개발되게 될 것이다.

 

  ○ K 및 W-Cloud Center의 정의
    ▷ Korea Cloud internet data Center (이하 K-Cloud Center)는 기존의 정부통합전산센터를 클라우드 컴퓨팅 기술을 접목하여 변환한 것을 의미한다.
    ▷ 광역 기반(Wide Area)의 Cloud internet data center (이하 WCloud Center)는 기존의 단위 지방자치단체별로 분산, 관리되었던 모든 시스템을 정부통합전산센터와 비슷한 광역 기반 IDC Center들을 건립한 후, 클라우드 컴퓨팅 기술을 접목하여 변환한 것을 의미한다.

 

  ○ K 및 W-Cloud Center의 구축이 필요한 이유
    ▷ 정부통합전산센터를 구축하여 중앙 부처 및 관련 공공기관의 모든 시스템 자원을 대전 및 광주로 통합하여 운용하고 있으나, 실질적인 통합이 아닌 장소 집약적인 통합만이 이루어져 있기 때문에, 통합에 따른 예산 절감이나 중복 투자 등의 기본적인 문제가 해결되지 않고 있다.
    ▷ 각 지방자치단체 및 기타 공공기관의 경우 각종 시스템 자원을 보관하고 있는 전산실의 열악한 환경 및 체계적인 관리 인력 부족으로 인하여 다양한 위험에 직면하고 있다.

 

  ○ 추진 절차
    ▷ 정부통합전산센터를 클라우드 컴퓨팅 기술을 적용하여 K-Cloud Center로 전환을 수행하고, 이후 모든 시스템 자원의 구매 및 활용은 K-Cloud Center에서 대행한다.
    ▷ K-Cloud Center는 모든 시스템 자원을 통합하여 하나의 거대한 가상 시스템을 구성하고, 가상화 기술을 적용하여 각각의 정보 시스템에 할당하는 방식을 사용한다.
    ▷ W-Cloud Center의 구축은 경기권, 강원권, 충청권, 전라권, 경북권, 경남권 등의 6개 광역권을 기준으로 하여, 각 광역권에 2개의 센터를 두는 방향으로 추진한다.
    ▷ 운영되는 방식은 K-Cloud Center와 동일한 방식을 사용한다.

 

  ○ 예상 효과
    ▷ K 및 W-Cloud Center의 구축으로 인하여 각 부처와 공공기관에서 운용하고 있는 잉여 시스템 자원들의 구매 비용 및 유지보수 비용을 절감이 가능하다. 또한 각 부처 및 공공기관의 갑작스런 시스템 자원의 요구에도 즉각적으로 대처가 가능함으로써 잉여 자원의 미확보로 인하여 발생할 수 있는 위험을 최소화 할 수 있는 장점이 있다. 또한 각 부처 및 공공기관은
각종 시스템 자원을 직접 운영할 필요가 없기 때문에 이에 대한 유지보수 비용을 절감할 수 있다.
    ▷ K 및 W-Cloud Center의 설립은 부처 및 공공기관에서 직접적으로 시스템 자원의 유지보수에 대한 부담을 감소시킬 수 있으며, 또한 관련 직원들을 다른 분야에 재배치할 수 있기 때문에 좀 더 효율적인 인력 활용이 가능하다는 장점이 있다.
    ▷ 전문화된 인력들의 관리로 기존에 비하여 전체적으로 시스템 자원의 운용의 안정성이 향상되고, 갑작스런 장애에도 즉각적이면서도 효과적인 대처가 가능하게 되었다. 또한, 기존의 정부통합전산센터들로만 한정 되었던 각종 데이터베이스들의 분산 백업 작업들이 지역적으로 최소 12군데 이상의 W-Cloud Center로 분산되어 백업되고 관리되고 있기 때문에 훨씬 더
안정적이고 강건한 데이터 백업 시스템을 구축할 수 있게 된다.
    ▷ 각 부처 및 공공기관별로 분산 관리되었던 각종 ICT자원들은 K 및 WCloud Center로 통합 관리된다. 통합 운영에 각 부처에서 개별적으로 잉여 시스템을 따로 준비할 필요가 없기 때문에 전체적으로 보유하는 시스템 자원의 감소를 가져올 수 있으며, 이에 따른 부가적인 효과로써 전체적인 탄소 배출량을 감소시킬 수 있게 된다.

 

  ○ 1단계에서는
    ▷ 관련 법규 및 제도 등을 제정 및 정비를 시행하면서 클라우드 컴퓨팅 기술을 적용하기 위한 1차 시범 사업을 수행한다.

 

  ○ 2단계에서는
    ▷ 1단계에서 시행한 1차 시범 사업을 통하여 얻어진 각종 지식과 경험을 바탕으로 본격적으로 클라우드 컴퓨팅으로 전환하는 사업을 단계적으로 시행한다. 또한, 정부종합센터의 클라우드 컴퓨팅 기반의 인터넷 데이터 센터로의 전환을 수행한다.

 

  ○ 3단계에서는
    ▷ 클라우드 컴퓨팅 기반의 소프트웨어를 공공부문에 판매하고 구매를 수행할 수 있도록 지원하는 "G-Apps"를 구축하며, 서비스 지향 PaaS 플랫폼인 GAP(Governmental Application development Platform)를 구축한다. 또한 2단계에서 시행하였던 클라우드 컴퓨팅 전환 사업을 전 중앙부처로 확대한다.

 

  ○ 4단계에서는
    ▷ 광역 자치 단체 기반으로 각 지방 자치 단체의 모든 서버 및 스토리지 시스템과 같은 시스템 자원을 하나로 통합하여 광역 기반의 클라우드 컴퓨팅 기반의 인터넷 데이터 센터를 구축하며, 서비스 지향 PaaS 플랫폼인 GAP(Governmental Application development Platform)를 구축 활용하는 다양한 프로모션을 진행한다. 또한, 2단계에서 시행하였던 클라
우드 컴퓨팅 전환 사업을 1차 지방자치단체들에게 적용한다.

 

  ○ 5단계에서는
    ▷ 기 구축된 클라우드 컴퓨팅 기반의 인터넷 데이터 센터로 전환된 정부통합전산센터와 광역기반 인터넷 데이터 센터를 유기적으로 통합하여 운영하며, 2단계에서 시행되었던 전환 사업을 모든 자치단체에게 적용하도록 한다. 또한, GAP 및 GAP을 통하여 공공 및 민간 분야에서 제공하는 다양한 공공부문의 서비스를 활용하게 된다.

 

 

3. 클라우드 기반의 스마트오피스 업무환경

 

  ○ 스마트 오피스 정의 : 통신망으로 클라우드에 원격 접속하여 장소에 관계없이 업무를 처리할 수 있도록 하는 것

 

  ○ 스마트 오피스 유형 : 어플리케이션 가상화, 데스크탑 가상화, 클라우드 스토리지 가상화

 

  ○ 스마트 오피스 도입효과 : 언제 어디서든 편리하게 업무처리 가능, 저탄소 업무환경 구현 가능, 외부 정보유출 방지, 관리의 자동화, 효율화 용이

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
:

[14강] 클라우드 오해

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 16. 10:15 | Posted by 깨비형
반응형

1. 클라우드 컴퓨팅 서비스에 대한 오해

 

  ○ 클라우드 컴퓨팅 서비스에 대한 일반인의 다양한 정의와 의식을 갖고 있다. 이는 클라우드가 기업 및 개인의 모든 요구 조건을 만족 시켜 줄 수 있다는 생각과 일부 서비스 제공자의 과대 광고로 오해하고 있다.

 

  ○ 본 장에서는 이러한 클라우드 컴퓨팅 서비스에 대한 오해 할 수 있는 요소들에 대하여 설명한다. 다음의 9가지 요소가 일반적으로 쉽게 오해하고 있는 내용들이다.
    ① 단 한 가지“클라우드 서비스 모델”만 존재한다.
    ② 돈만 있으면 된다.
    ③ 클라우드 서비스는 업무량을 줄여준다.
    ④ 프라이빗 클라우드와 퍼블릭 클라우드 서비스를 아주 매끄럽게 융합시킬 수 있다.
    ⑤ 퍼블릭 클라우드와 프라이빗 클라우드는 영원히 매끄럽게 융합시키지 못하게 될 것이다.
    ⑥ 클라우드 서비스는 항상 비용을 절감시켜준다.
    ⑦ 클라우드 공급업체는 보안을 보장할 수 있다.
    ⑧ 가상 머신을 운용하고 있다면, 클라우드 컴퓨팅을 이용하고 있는 것이다.
    ⑨ 클라우드 컴퓨팅은 기술이 전부다.

 

  ○ 오해 1 단 한가지 "클라우드 서비스 모델"만 존재한다.
    ▷ 클라우드 서비스 모델은 기본적으로는 IaaS, PaaS, SaaS 형태로 나누지만 이외에도 다양한 방식의 모델이 존재한다.
    ▷ 특히 요즘은 하나 이상의 방식이 복합적으로 연동하는 형태로 서비스 하는 곳이 많이 늘어나는 추세다.

 

  ○ 오해 2 돈만 있으면 된다.
    ▷ 각기 시간과 능력이 있는 개발자라면 순수 가상 서버를 구성하는데 아무런 문제도 없을 것이다. 하지만, 사업을 해야 하는 입장에서는 운영체제, 여러 가지 애플리케이션, 그리고 데이터베이스 연결을 설치해서 구성하는 일이 매출 발생에 방해가 될 수도 있다.
    ▷ 그리고 만약에 보안, 데이터 포맷 혹은 양질의 데이터에 대한 표준이 있을 정도의 큰 기업일 지라도, 다른 누군가가 그 일을 해야 하는 것은 마찬가지다.
    ▷ 클라우드 기반 서버가 안전하지 않을 수도 있고, 회사의 표준을 충족시키지 못하거나, 전체 IT 환경에 통합되지 않을 수도 있다.
    ▷ 많은 IaaS(Infrastructure as a Service)가 기업 애플리케이션의 필요성을 충족시켜주지 못하고 있다.
    ▷ 아마존은 최근 자동 확장(Auto-scaling), 감시, 그리고 부하 분산 등이 포함된 새로운 기능의 공개 베타 버전을 발표했다. 하지만, 아마존의 새로운 기능들이 방향은 제대로 잡았으나, 구성 관리, 라이프 사이클 관리 등의 필요 기능은 없는 것처럼 보인다고 평가했다.

 

  ○ 오해 3 클라우드는 업무량을 줄여준다.
    ▷ 장기적으로, 아마 그럴 수도 있다. 하지만 그렇게 되려면, 어떤 클라우드 컴퓨팅 모델이 맞는지, 어떤 애플리케이션 또는 서비스가 안성맞춤인지, 그리고 적정 수준의 보안, 컴플라이언스, 그리고 가동시간을 보장하는 방법 등을 알아내야만 한다.
    ▷ 어떤 업체가 제공하는 서비스나 제품의 성능을 감시하기 위해서는 시간이 들어간다는 것을 명심하라.
    ▷ 상용으로 대량 생산되는 애플리케이션을 운용할 때는, 다중화(Redundancy), 신뢰성, 성능과 지연시간에 대해 많은 생각을 한다. 고객들은 애플리케이션을 클라우드로 이전하기 전에 그런 요구사항들이 충족되고 있는지를 우선 확인할 필요가 있다.
    ▷ 클라우드 기반 시스템들이 자동으로 스스로를 관리하는 이상적인 상황을 “희망 사항”이며, 이를 위한 연구, 개발이 지속적으로 진행되고 있다.
    ▷ 또한, 모든 애플리케이션이 클라우드에 적합한 것도 아니다. 예를 들어 클러스터 서버에 의존하는 애플리케이션들은 다른 고객들과 자원을 공유하는 클라우드 환경에 적합하지 않다. 왜냐하면 이런 애플리케이션들은 동일한 구성의 서버와 서버들 간의 대용량 전용 대역폭을 필요로 하는데, 이를 클라우드 공급업체가 항상 보장할 수는 없기 때문이다. 다시 말하지만, 이런 문제들에 대한 심각한 고려가 사전에 이루어져야 한다.

 

  ○ 오해 4 프라이빗 클라우드와 퍼블릭 클라우드 서비스를 아주 매끄럽게 융합시킬 수 있다.
    ▷ 어떤 클라우드 기획자들은 양쪽의 장점만을 설명하고 있다. 내부 데이터센터가 제공하는 통제권과 클라우드가 제공하는 낮은 가격과 유연성, 거기다가 드래그 앤드롭(Drag and Drop) 애플리케이션, 스토리지, 그리고 요구형 서버까지 존재한다.
    ▷ 특히 내부 데이터베이스에 의존하고 있으며 끊임없이 변하는 액세스 권한을 가지고 있는 수천 명의 사용자를 지원하는 복잡한 다계층(Multitier) 애플리케이션은 정말로 쉽지 않다.
    ▷ 현재 프라이빗 클라우드와 퍼블릭 클라우드 간에 애플리케이션을 이전하기 위해서는 많은 재구성 작업을 수작업으로 해야 하며, 기술적인 문제도 많다.
    ▷ 또한 고객이 프라이빗/퍼블릭 클라우드 양쪽 모두에서 동일한 플랫폼을 사용하고 있다면, 통합작업이 좀 더 쉽기는 하지만, 개방형 가상화 포맷(Open Virtualization Format) 같은 더 복잡한 환경을 위한 표준화 노력은 상호호환성 문제를 덜어주기에는 아직 초보 단계이다.
    ▷ 핵심 요구조건은 양쪽 환경을 지원할 수 있는 보안 인프라 데이터를 복제(Replicate)하거나 프라이빗/퍼블릭 클라우드를 통해서 액세스할 수 있는 안전하고 비용 효율적인 방법, 요구조건에 따라 서비스가 동작하고 있는지, 그리고 그렇지 않을 경우 이를 수리하기 위해 따라야 할 적절한 절차를 보장하는 통합 소프트웨어라고 한다.
    ▷ 내부 클라우드라면, 동일 클라우드 안에 있는 정책 데이터베이스에 액세스할 수 있을 것이나, 민감한 보안 데이터를 외부 클라우드에 호스팅하거나 내부 보안 데이터에 대한 외부 액세스 허용하는 것은 고객들이 꺼려할 수도 있다.

 

  ○ 오해 5 퍼블릭 클라우드 서비스와 프라이빗 클라우드 서비스는 영원히 매끄럽게 융합시키지 못하게 될 것이다.
    ▷ 공급업체들은 하이브리드 클라우드 서비스 모델의 제시와 함께 매끄러운 통합 서비스 제공을 위해 민첩하게 움직이고 있다.
    ▷ 예를 들면, 클라우드 컴퓨팅 서비스 제공 업체는 클라우드 서비스 통합을 12~18개월 내에 이 기능을 고객들에게 제공할 수 있을 것으로 예상하고 있다.
    ▷ 클라우드 컴퓨팅 서비스가 폭넓게 보급되기 전까지는, 퍼블릭/프라이빗 클라우드의 구성 사항, 데이터 모델, 그리고 설치 자동화 정책 등에 대한 표준화 작업을 하라고 권고한다.
    ▷ 표준화 작업을 수행하면, 지금 퍼블릭 클라우드를 활용할 수 있게 해주는 동시에 기술, 표준, 그리고 프로세스가 성숙해 가면 갈수록 두 클라우드 간에 자원을 더 많이 공유 할 수 있는 기반을 만들 수 있다.

 

  ○ 오해 6 클라우드 서비스 모델은 항상 비용을 절감시켜준다.
    ▷ 리눅스 같은 특정 플랫폼을 클라우드에서 운영하면, 비용 절감 외에는 얻는 것이 없다고 주장하고 있다. 전체 데이터센터의 경우에는 그냥 내부에 두는 것이 더 낫다는 것이다.
    ▷ 구글 앱스의 선임 제품 담당 책임자도 고도로 다중화된 아키텍처에서 저가 서버를 사용하여 얻는 절감 효과만을 고려하는 오류를 범했다고 지적했다.
    ▷ 또 다른 구글의 보고서에서 “구글이 자체 애플리케이션용으로 사용하는 것과 동일한 확장성을 갖는 애플리케이션 서버와 데이터베이스”를 사용함으로써 고객들이 별도로 데이터베이스와 애플리케이션 서버를 구매, 설치, 유지보수 그리고 확장하지 않음으로 해서 얻는 추가적인 절감 비용은 언급하지 않았다고 지적했다.
    ▷ 또 다른 예상하지 못한 사항은, 지금과 같은 라이선스 모델과 지원 모델 하에서는 고객들이 소프트웨어를 회사 내부가 아닌 클라우드에 설치함으로써 훨씬 더 많은 비용을 상용 소프트웨어 공급업체들에게 지불할 수도 있다는 것이다.

 

  ○ 오해 7 클라우드 공급업체는 보안을 보장할 수 있다.
    ▷ 클라우드 공급업체가 세상의 모든 보안 인증서를 가지고 있다 하더라도, 사용자의 특정 서버, 애플리케이션 그리고 네트워크가 안전하다는 보장은 없다.
    ▷ 신용카드 업계의 PCI DSS(PaymentCard Industry Data Security Standard:PCI 데이터 보안 표준)를 예로 들면, 소매업자나 신용카드 처리업체는 아마존이나 구글 같은 클라우드 공급업체가 제공하는 플랫폼 상에 자신들의 서버와 애플리케이션이 얼마나 잘 설치되어 있는지를 감사를 받는다.
    ▷ 클라우드 환경을 안전하게 만들기 위해서는 IT를 “외부에서 바라다보는 시각”을 유지해야 하며 사용자가 핵심적인 정보에 액세스하는 가능한 모든 경로에 대한 보안을 확보해야만 한다. 또 각 플랫폼을 보호하는 작업은 그리 어렵지 않았으나, 필요한 모든 보안 기술이 서로 어울려서 동작하도록 하는 작업이 어려웠다고 전해진다.
    ▷ 공급업체가 가령 동일한 데이터베이스에 대한 자신들의 테이블 스페이스(Table Space)를 각 고객들에게 줘버림으로써 비용 절감을 하지는 않았는지를 확인하기 위해서는 아키텍트들이 머리를 맞대고 앉아야 할지도 모른다고 지적했다. 만약 그렇게 되면 고객들이 다른 고객의 데이터를 볼 수 있게 된다.
    ▷ 클라우드 환경에서는 불안정한 네트워크에 가상머신(VM, VirtualMachine)을 연결시켜버릴 수도 있는 새로운 네트워크 카드(NIC: Networ Interface Card) 할당이 실제 환경에서보다 쉽다. 조직의 기존 파이어월은 새 NIC의 존재를 알 수 있는 방법이 없어서 이를 통과하는 트래픽을 감시할 수 없게 된다고 것. 이런 잠재적 위협 때문에 클라우드 공급업체의 보안 인프라를 맹목적으로 신뢰하는 것보다는 독립적으로 평가하는 것이 중요하다.

 

  ○ 오해 8 가상 머신을 운용하고 있다면, 클라우드 컴퓨팅을 이용하고 있는 것이다.
    ▷ 여러 대의 물리적 기기를 아우르는 논리 서버와 스토리지를 생성하는 가상화는 클라우드 컴퓨팅의 필수조건 중 한 가지이다. 하지만 가상 머신을 보유하고 있다는 것이 클라우드 컴퓨팅을 이용하고 있다는 의미는 아니다.
    ▷ 가상화의 모든 이점을 누리기 위해서는, IT 부서나 클라우드 공급업체도 필요에 따라 용량을 확대 또는 축소할 수 있는 능력, 선불 가격정책을 제공해서 사용자들이 필요에 따라 스스로 새로운 서버와 스토리지를 제공할 수 있게 해주어야만 한다.
    ▷ 특히, 특정 업무 전용으로 사전에 구성된 가상 서버 주문 같은 작업을 사용자가 직접 처리할 수 있도록 허용하는 것이 어떤 클라우드 고객들에게는 핵심적인 비용절감 목표일 수도 있다.
    ▷ 하지만 이런 셀프서비스는 VM웨어 Infrastructure 같은 소프트웨어를 운용한다고 해서 자동적으로 일어나지는 않는다.
    ▷ 예를 들면, 지멘스는 사용자들이 필요에 따라 프라이빗 클라우드에서 주문할 수 있는 가상 서버와 관련 서비스에 대한 표준 카탈로그를 만들기 위해“상당한 투자”를 해야만 했다.

 

  ○ 오해 9 클라우드 컴퓨팅은 기술이 전부다.
    ▷ 기술은 클라우드 컴퓨팅을 가능케 했다. 하지만, 비용 절감과 유연성을 실현하기 위해서는 제대로 된 프로세스도 필요하다.
    ▷ 클라우드 컴퓨팅의 기반이 되는 가상화는 고객들이 데이터와 애플리케이션을 물리적인 서버들 간에서 이동할 때에 매우 역동적으로 지원하고 있다. 아주 빈번하게 변경이 이루어진다면 지금 필요한 것은 이런 이동을 부드럽게 관리할 수 있는 능력이다.
    ▷ 실제로 이런 기능이 있으면 관리되지 않는 물리적 서버에서처럼 전기, 냉방 그리고 관리 시간을 잡아먹고 보안 상의 위협까지도 야기할 수 있는 미사용 또는 저사용 가상머신의 창궐을 막을 수 있다.
    ▷ 반면에 클라우드에서 표준 프로세스를 사용하면, 효율성이 증가한다. 가상화 같은 기술과 ITIL(Information Technology Infrastructure Library) 관리 프레임워크를 함께 사용함으로써, IT 관리와 행정 업무를 25~30% 까지 줄여줄 수 있다고 보도 되고 있다.

 

  ○ 클라우드 컴퓨팅 서비스에 대한 진실
      남은 것은 무엇인가? 클라우드는 근심 걱정 없는 마법의 컴퓨팅 나라가 아니라 이해와 제대로 관리하기 위한 힘든 일이 수반되는 복잡한 자원이라는 사실. 그리고 이건 오해가 아니다.

 


2. 소규모 기업이 클라우드 서비스를 이용하는 이유

 

  ○ 웹 사이트 호스팅부터 이메일, ERP까지 IT 기능을 아웃소싱 하는 것은 기업 규모에 관계없이 오래 전부터 보편화되어 왔다. 하지만 데이터베이스 서버나 파일 서버, 문서 스토리지, 애플리케이션 개발 등 중요한 IT 기능을 아웃소싱 하는 것에는 많은 기업들이 주저하고 있다.

 

  ○ 경험이 많은 IT 관리자는 최근 빈번하게 일어나는 서비스 중단이나 데이터 손실, 해킹 사건 등을 지적하며, 이로 인해 생산성 손실은 물론 소송이나 벌금, 심지어 기업의 파산으로 이어질 수 있다고 강조한다.

 

  ○ 하지만 기업 파이어월 외부로부터 얻을 수 있는 저렴한 비용의 인프라와 설비, 관리, 그리고 더 나은 서비스 가용성 등을 통해 얻을 수 있는 본질적인 이점이 있다는 것은 무시할 수 없는 사실이다.

 

  ○ 소규모 기업에서 클라우드 서비스로 현실화할 수 있는 절감 요소를 짚어본다.

 

   1. 인프라 절감
    ▷ 내부 IT 서비스를 위해 새로운 서버나 운영체제, 애플리케이션을 구매하는 대신 클라우드 서비스 업체에 매월 요금을 지불하기만 하면 된다.
    ▷ 운영체제와 애플리케이션을 갖춘 서버 한 대의 비용이 수천 달러에서 수만 달러에 이른다는 점을 생각하면, 엄청난 이점이 될 수 있다.
    ▷ 특히 전면적인 도입 전에 새로운 서비스를 테스트해 보고자 한다면, 이점은 더욱 커진다.

 

   2. 환경 설정과 관리 절감
    ▷ 만약 IT 직원이 새로운 운영체제와 애플리케이션에 익숙하지 않다면, 새로운 기능을 도입하는 것은 길고 힘든 과정이 될 수 있다.
    ▷ 클라우드 서비스 업체는 특정 애플리케이션을 지원하는데 있어서는 경험이 풍부한 관리자이다.
    ▷ 이것이 클라우드 기반 ERP가 인기있는 이유 중 하나이다.
    ▷ ERP는 도입이 까다롭기로 악명이 높은데, 하드웨어와 소프트웨어 모듈을 함께 돌아가게 하는 것도 어렵고, 소프트웨어를 적절하게 설정하는 것도 어렵다.
    ▷ 경험이 풍분한 인력을 갖춘 서드파티 클라우드 업체에게 모니터링이나 새로운 계정 설정, 패치 적용 같은 일상적인 업무는 너무나 쉬운 일이다.

 

   3. 설비 절감
    ▷ 클라우드 서비스 업체는 대규모의 현대식 데이터센테에 친환경 기능까지 갖추고 있으며, 이런 인프라를 여러 기업 간에 공유시켜 주기 때문에 같은 규모의 설비를 운영한다고 해도 클라우드 서비스 업체가 훨씬 더 저렴한 비용으로 운영할 수 있다.
    ▷ 여기에 일반적인 기업의 서버 활용도를 감안하면 격차는 더욱 커진다.

 

   4. 더 나은 성능과 기능
    ▷ 클라우드 서비스 업체는 다양한 기업에 서비스를 제공하기 때문에 대용량 고성능 시스템을 구매한다.
    ▷ 이들 시스템은 소규모 기업이 내부적으로 구동할만한 시스템보다 훨씬 성능이 뛰어나다.
    ▷ 또한 대부분의 소프트웨어 버전과 사이트 라이선스를 가지고 있기 때문에 소기업이 내부적으로 확보할 수 있는 것보다 더 저렴한 비용으로 기능을 이용할 수 있다.
    ▷ 또한 한두 명에 불과한 소기업의 IT 인력과 비교할 때, 성능을 최적화하는 방법을 더 잘 아는 인력을 보유하고 있을 가능성이 높다.

 

   5. 기업의 민첩성 향상
    ▷ 클라우드 서비스 업체는 쉽고 빠르게 서버와 서비스를 추가할 수 있으며, 이를 기업 내부 사용자뿐만 아니라 외부의 계약업체나 협력업체, 고객에게도 제공할 수 있다.
    ▷ 이는 소규모 기업이 내부적으로 구현하기 어렵거나 불가능한 수준의 유연성을 제공해, 소규모 기업의 고객의 요구나 핵심 비즈니스의 변화에 더 신속하게 대응할 수 있도록 해 준다.

 

   6. 장애 대비도 강화
    ▷ 클라우드 서비스 업체는 여러 곳의 데이터센터와 각 데이터센터마다 여러 회선의 인터넷 접속을 갖추고 있다. 물론 데이터센터 간의 데이터 복제도 지원한다.
    ▷ 여기에 더해 데이터 보호 수준도 높다. 단순 야간 백업을 넘어 지속적인 데이터 보호, 정전에 대비한 발전기, 특정 부품이 고장나도 돌아가는 고성능 서버 등을 갖추고 있다.

 

  ○ 이외에 여러 가지 이점을 언급하지 않더라도 클라우드 서비스가 제공하는 이점은 환상적이다. 물론 이런 이점은 클라우드 서비스 업체에 문제가 생겨 데이터가 손실될 가능성으로 상쇄될 수 있다. 하지만 이런 위험은 장애에 대비한 옵션을 추가하는 것으로 균형을 맞출 수 있다. 예를 들어 다른 클라우드 서비스 업체에 데이터를 백업하는 등의 방법을 이용할 수 있다. 마지막으로 클라우드로 이전하고자 하는 애플리케이션이 만에 하나 문제가 생겼을 때 비즈니스에 어떤 영향을 미치는지를 계산해 보아야 할 것이다.

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[15강] 공공 클라우드  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
:

[12강] 가상화 엔진

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 15. 19:16 | Posted by 깨비형
반응형

1. 가상화 엔진의 개념


  ○ 가상화 엔진

    ▷ 가상액세스(Virtual Access), 가상관리(Virtual Management), 가상자원(Virtual Resources) 의 3가지 모두에 대한 점진적인 향상이 이루어질 수 있는 기본 서비스를 제공한다.

    ▷ 여기에는 모든 지원 플랫폼들에 걸쳐서 공통된 가상화 역량을 제공하는 핵심 컴포넌트들 뿐만 아니라 플랫폼에 고유한 가상화 역량 및 확장성이 포함되어 있다.

    ▷ 아래 그림은 가상화 엔진 플랫폼의 기본 개념도 이다


  ○ 가상화 엔진 (플렛폼)의 목표

    ▷ 중요한 목표 중 하나는 모든 플랫폼에 걸쳐서 공개 표준의 사용자 요구의 지원을 위한 기반을 제공하는 것이다.

      - 가상화 엔진 플랫폼에서 제공되는 기능들은 오픈 인터페이스와 산업표준 체계를 사용함으로써 서드파티 (Third Part) 제품들도 상호 작동될 수 있도록 해준다.

      - 상호 연동성을 기반으로 설계된 플랫폼은 점진적으로 더 높은 수준의 비즈니스 지향의 관리 솔루션을 구축하기 위한 빌딩 블록으로서의 집합체의 성격을 본질적으로 가지게 된다.

    ▷ 또 다른 주요 목표는 사용자의 경험을 단순화시키는 것이다.

      - 초기의 관심사는 사용자들로 하여금 가상화를 주요한 관리 전략의 하나로써 좀 더 적극적으로 적용할 수 있도록 도와주어서 사용자들로 하여금 가상화 환경을 시각화하고 제어하는 것을 수월하게 해주는 것이다.

      - 가상화 엔진 플랫폼은 관리의 중앙 집중화와 자원들이 서버 플랫폼들에 걸쳐서 관리되는 방식에 있어서 일관성을 제공한다.

    ▷가상화 엔진 플랫폼은

      - 가상화에 대하여 진화하는 접근방법을 제공한다.

      - 고객들은 워크로드 관리, 자원의 발견 및 기타 등에 있어서 단순한 물리적 분할에서부터 진보된 형태의 소규모 분할에 이르기까지 다양한 방법으로 가상화의 도입을 시작할 수 있으며, 관리되는 가상화 환경의 범위는 하나의 하드웨어 박스에서부터 혼합 애플리케이션을 구동하는 멀티티어(multi-tier) 이기종 서버들의 집합 등으로 다양할 수 있다.

    ▷ 가상화에 대한 고객들의 투자는 

      - 다수의 시스템이 뭉친 스케일-아웃 형태에서 물리적으로 통합된 시스템인 스케일-업 형태로 나아갈수록 더욱 더 투자보호 효과가 높아진다.

      - 같은 종류의 가상화 서비스가 사용되어지므로 어떤 플랫폼으로 이전되든지 간에 기존의 관리 및 보안 부분을 새로 교체할 필요가 없어지게 된다.

    ▷ 간단히 가상화 엔진에 있어서 

        • 가상 관리 및 가상 액세스 서비스의 전반적인 개요와 구성요소들을 알아보고 향후 어떠한 모습으로 발전할 것인가를 간략히 살펴보기로 한다.


       1) 가상 관리(Virtual Management)

    ▷ 가상 관리 서비스에는 아래와 같이 고객들이 가상 시스템의 운영을 단순화하고 최적화시킬 수 있도록 도와주는 3가지 제품 요소들이 포함되어 있다.

        • Enterprise Workload Manager (EWLM)

        • Resource Dependency Service (RDS)

        • Director

(가상관리를 위한 가상화 엔진의 전체적인 그림)


  ○ EWLM을 이용한 전사적 워크로드 관리 방법

    ▷ EWLM은 오픈소스 기반의 애플리케이션 응답 측정용 표준(ARM, Application Response Measurement)을 사용하여 수행되고 있는 애플리케이션으로부터 성능 데이터를 얻는다.

      - ARM 표준을 지원하는 제품과 벤더는 빠르게 증가하고 있으며,

      - 이중에서 대표적인 제품으로는

      - 웹스피어 애플리케이션 서버(WAS), 

      - DB2 UDB,

      - 아파치 웹서버,

      - 마이크로소프트의 IIS 서버 그리고

      - 웹스피어 MQ

      - JMS 메시징 등이 있다.

    ▷ 워크로드 매니저에서 소개된 개념을 확장한 EWLM은 널리 인증된 기술을 적용하여 멀티 티어, 이기종 환경에서 사용자가 정의한 서비스 레벨 목표를 달성하기 위하여 워크플로우를 모니터링하고 관리해준다.


  ○ EWLM을 이용한 전사적 워크로드 관리 방법

    ▷ 아래 페이지 그림처럼 워크로드 관리는 개별 서버수준 WLM에서 파티션들간의 PLM을 거쳐서 전체 IT 인프라에 걸친 워크로드 개념인 EWLM으로 개념적으로 나 기술적으로 발전을 거듭해 오고 있다.


   ○ 자원 관계 서비스(RDS : Resource Dependency Service)

    ▷ 오늘날 IT 매니저가 당면하고 있는 주요한 이슈들 중의 하나인, 어떤 자원들이 존재하며 어떻게 이들 자원들이 서로 연관 지어져 있는가에 대한 이슈들을 다룬다 . RDS에 대한 전략은 스스로 표현 가능(selfdescriptive) 인프라스트럭쳐 컴포넌트(Manageable Resources라고도 불림) 에서 제공되는 정보를 사용하여 토폴로지를 구축하는 것이다.

    ▷ 관리 가능한 자원이 공식적으로 나오기 전까지 RDS는 다양한 기술들을 사용하여 기존 애플리케이션, 도구 및 IT 시스템들로부터 자원과 관계 데이터를 발견 및 추출할 것이다. RDS는 공개 표준을 사용하여 자원의 상태를 표시하며, 관리 가능한 자원들을 액세스하고 관리하는데 업계 표준을 활용하기 위해 지속적으로 진화 할 것이다.

    ▷ 따라서 RDS가 제공하는 서비스는 관리 가능한 자원이 기반이 되는 시스템 관리의 발전에 대한 첫걸음이 된다.

    ▷ 아래 그림은 RDS의 전체적인 개념을 쉽게 이해할 수 있도록 보여주고 있다.

      - 가상화 엔진에서 RDS는 기업 내에 존재하는 자원들간의 관계 및 의존성, 자원들의 속성 및 상태에 대한 정보를 그래픽한 뷰로 구축해주는 토폴로지 서비스를 제공한다.

      - 이러한 토폴로지는 가상화 엔진 콘솔 상에 표시된다.


   ○ 관리자 (Director)

    ▷ 가상화 엔진 플랫폼에서 Director는 하나의 단일 콘솔에서 IT 관리자는 원격지 시스템의 하드웨어 구성을 상세히 살펴볼 수 있고 프로세서, 디스크, 메모리와 같은 핵심 요소들에 대한 사용량과 성능을 모니터링 할 수 있다.

    ▷ 서버 시스템 기반 위에 하드웨어 및 가상 파티션을 관리할 수 있는, 공통되고 일관된 솔루션을 제공해준다. 고객들은 Director를 이용하여 분산된 환경에서 서버 및 저장공간 등을 원격 관리 콘솔을 구동시킴으로써 일괄적으로 관리할 수 있게 됨으로써 플랫폼에 고유한 관리 노력과 복잡한 인터페이스를 제거시켜 준다.

      - 따라서 자원 발견, 이벤트 로그 및 액션 플랜, 파일 전송, 인벤토리 수집, 프로세스 관리, 자원 모니터링 및 한계치 등을 포함한 수많은 이전의 수작업들이 자동화 되어진다.

      - 경고와 관련이 깊은 예측적이고 사전 대응적인 관리 기능들과 실시간 시스템 진단 기능은 서버의 가용시간을 최대화하고 다운타임으로 인한 비용을 최소화시켜 준다.


      2) 가상 액세스(Virtual Access)

  ○ 가상 액세스(Virtual Access) 서비스는 가상화된 자원들에 대하여 시각적인 면과 프로그래밍 측면 2가지 모두에서 일관된

인터페이스 액세스를 제공해준다.


  ○ 여기에는 아래의 3가지 요소가 포함된다.

       - VE Console,

       - Programmatic Interfaces,

       - 관리 가능한 자원(Manageable Resources)


  ○ VE 콘솔(VE Console)

    ▷ VE Console은 기업 수준에서 가상화된 인프라스트럭쳐에서 자원들을 관리하기 위한 웹 기반의 단일 인터페이스를 제공해준다.

    ▷ 대표적인 기능으로는 헬스 센터와 단일 지점 관리 두 가지를 꼽을 수 있다.

      - Health Center : 분산된 시스템과 스토리 관리 환경에 걸쳐서 모든 시스템 자원들의 헬스에 대한 통합 뷰 제공

      - 단일 지점 관리 : 가상화 엔진의 다양한 기능들과 Director를 포함하여 서버 시스템, 애플리케이션 및 스토리지 관리 콘솔을 수행할 수 있는 하나의 장소 다양한 관리 시스템들로부터 얻은 자원 정보를 이용해서 헬스 센터는 실시간으로 자원의 상태와 헬스를 그래프와 차트 형태로 나타내 준다. 관리자는 상태를 모니터링하고, 경고 정보를 받아서 문제 상황을 심도 있게

파헤치고, 적합한 조치를 취하고 다른 주요 시스템과 스토리지의 관리 기능을 헬스 센터를 통해 수행할 수 있다. 관리자는 또한 RDS를 통해 들어온 자원의 토폴로지 정보를 봄으로써 자원의 관계와 의존성을 이해할 수 있게 된다. 헬스 센터와 토폴로지 지원은 다른 콘솔을 실행할 수 있는 능력과 결합되어지면 구체적인 OS 지식이 없어도 어느 정도 개별적인 OS 관리를 할

수 있게 도와준다.


  ○ Programmatic Interfaces

    ▷ 가상화 엔진 플랫폼 서비스는 웹 서비스 기반의 SOA 접근방법을 이용하여 개발되었다.

    ▷ 표준 기반의 컴포넌트 수준의 인터페이스를 사용함으로써 가상화 엔진의 서비스는 어디서나 상호 연동성을 가지게 되었다.

    ▷ 하드웨어 및 소프트웨어 벤더들은 가상화 엔진의 이러한 서비스를 포함하거나 확장 또는 개발하여 재사용할 수 있게 된다.

    ▷ 가상화 엔진 플랫폼 서비스는 리소스 모델, 프로파일 및 액세스 프로토콜을 관장하는 프로그래밍 가능한 인터페이스를 사용할 수 있도록 진화하기 시작했다. 그러한 표준들에는 아래와 같이 3가지 레벨이 있다.

         웹 서비스 접근 인터페이스

         웹 서비스 지원 모델로 맵핑 인터페이스

         자원 모델링 인터페이스


  ○  관리 가능한 자원  (Manageable Resources)

    ▷ 가상화 엔진 서비스는 관리 가능한 자원을 이해하는 것이 많은 도움이 된다. 관리 가능한 자원이란 가상 인프라스트럭쳐의 빌딩 블록으로써 전사적 차원에서 자원이 발견되고 공유되며, 관리되어지고 프로비져닝 되어지도록 해주는 핵심 요소이다.

    ▷ 오늘날 시스템 자원들은 전형적으로 각기  독립적인 관리도구와 애플리케이션들에 의해 관리되고 있다. 관리 가능한 자원은 이러한 장애들을 극복하는데 도움을 준다.

    ▷ 자원 관리를 위해 업계 공개 표준인 웹 서비스를 이용하여 형성된 각각의 관리 가능한 자원은 해당 자원을 발견, 확인, 관리 및 사용하기에 필요한 정보를 자체 내에 내재하고 있다, 실제로 각 자원은 호출 가능한 서비스가 된다고 볼 수 있다.

 예를 들어 시스템 관리 애플리케이션은 웹 서비스를 사용해서 어떤 스토리지에 있는 데이터를 다른 스토리지로 옮기거나 OS를 리부팅 할 수 있다. 관리 가능한 자원은 그것이 나타내는 자원과의 상호 작용을 다룰 수도 있다. 자원에 대하여 작동할 뿐만 아니라 애플리케이션은 웹 서비스를 사용하여 자원들 간의 상세한 구성 정보, 상태 및 관계 등을 발견, 확인, 획득 및 이해할 수 있게 된다. 관리 가능한 자원들은 또한 그래픽컬한 사용자 인터페이스를 제공해준다.

    ▷ 아래 그림 처럼 관리 가능한 자원들은 시스템 자원들에 대한 스마트한 가상적 표현으로써, 벤더와 플랫폼에 중립적이면서 자기 스스로 표현할 수 있는 컴포넌트들이며, 어떤 애플리케이션에서도 표준 웹 서비스를 통해 동일한 방식으로 접근 및 사용될 수 있다.



      3) 가상화 엔진 플랫폼의 미래 발전 전망

         - 프로그래밍 가능한 인터페이스 사용의 확장과 관리 가능한 자원 풀의 구축에 더하여 한층 더 진보된 가상화 기술은 향후 가상화 엔진 플랫폼을 통해 모습을 드러낼 것이다.

         - 여기에 덧붙여 결함 또는 장애가 발생하더라도 최소한의 중단(초/분, 애플리케이션 종류에 따라) 후에 안정화된 재 시작을 모니터하고 관리할 수 있는 기능이 제공될 것이며, 애플리케이션을 다른 서버(또는 같은 서버내의 다른 파티션으로)로 옮겨갈 수 있는 기능도 함께 제공될 계획이다.

        - 이러한 통합 과정은 진보된 서비스와 자원들은 공개 표준의 웹 서비스 인터페이스를 통해 외부로 드러날 것이며, 비즈니스의 연속성과 진보된 가상화 기능 및 스토리지와 서버의 혁신적인 기능들이 하나로 통합되어 활용될 것이다.


  ○ 아래 그림 같이 다양한 서버의 가상화 기술을 연결하고 재사용하는 시스템 디자인에 대한 전체적인 접근을 통해 이루어질 것이며, 서비스 기반의 협업 프로세싱 인프라스트력쳐를 지원하는 미들웨어 소프트웨어와 하드웨어가 근본 바탕을 이룰 것이다. 



  ○ 우리는 지금까지 가상화가 무엇이며, 가상화가 왜 중요하며 그리고 어떤 기술들이 현재 또는 조만간에 사용 가능한지 살펴보았다. 또한 다양한 업계 선도적 가상화 기술들과 이와 관련된 가상화 오퍼링인 가상화 엔진에 대하여 또한 간략히 살펴보았다.

    ▷ 이를 통해 우리는 가상화가 새로운 것은 아니라는 결론을 얻을 수 있다. 왜냐하면 기존 자원들로부터 더 많은 것을 얻을 수 있도록 해주는 혁신적인 서버, 네트워크 및 스토리지 가상화 제품을 지속적으로 제공해 왔기 때문이다.

    ▷ 또한 기업들은 그동안 가상화를 통해 증가된 활용률, 더 높아진 가용성 및 확장성, 더 커진 유연성 및 더 낮아진 IT와 관리 비용 등의 혜택을 얻어 왔기 때문이다.

    ▷ 이제 협업 처리가 중요시되는 시기가 도래하게 되면 많은 기업들은 점차 복잡해지고, 고비용을 요구하면서도, 온 디맨드 비즈니스를 위한 핵심적인 역량인 상호 연동성과 유연성은 부족한 기존의 IT 환경으로는 새로운 비즈니스 환경을 감당할 수 없음을 직관적으로 깨닫게 될 것이다.

    ▷ 따라서 기업들은 진보된 가상화 역량들을 활용함으로써 기업들은 단순화되고 유연한 IT 인프라스트럭쳐를 이룰 수 있다.

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[15강] 공공 클라우드  (0) 2012.07.16
[14강] 클라우드 오해  (0) 2012.07.16
[11강] 스토리지 가상화  (0) 2012.07.13
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
:

[11강] 스토리지 가상화

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 13. 17:01 | Posted by 깨비형
반응형

1. 스토리지 가상화

 

  ○ 스토리지 가상화
    ▷ 스토리지 사용의 엄청난 증가 추세는 매일 매일의 스토리지 운영 및 데이터 관리에 많은 부담을 증가시켜왔다.
    ▷ 결과적으로 가용성과 프로비져닝에 대한 서비스 레벨을 만족시키는 것이 커다란 과제로 다가오고 있다.
    ▷ 이러한 부담을 없애기 위해서 기업들은 디스크와 테이프 스토리지 가상화 기술에 눈을 돌리기 시작했다.
    ▷ 스토리지 가상화는 온 디맨드 전략의 필수적 일부분으로써 애플리케이션에 거의 또는 전혀 영향을 미치지 않으면서도 하드웨어 인프라스트럭쳐에 변경을 가할 수 있게 해준다.
    ▷ 그럼으로써 관리를 용이하게 하고, 애플리케이션의 가용성을 증가시키고, 총 소유 비용을 낮출 수 있게 해준다.
    ▷ 스토리지 가상화의 4가지 주요한 형태로 분류 할 수 있다.
     1) 디스크 컨트롤러 가상화
     2) SAN 상의 스토리지 블럭가상화
     3) 파일 가상화
     4) 테이프 가상화

 

   1) 디스크 컨트롤러 가상화 (Disk Controller Virtualization) :
    ▷ 디스크 컨트롤러 가상화는 스토리지 서브시스템 또는 컨트롤러를 파티션으로 나누어 마치 여러 개의 스토리지 컨트롤러가 있는 것처럼 보이게 해준다.
      - 예를 들어, IBM의 System Storage DS8000 계열이 이런 기능을 제공한다.
    ▷ 예를 들어 아래 그림 처럼 디스크 컨트롤러 1개가 3개의 가상 스토리지 컨트롤러로 파티션 되어서 하나는 OLTP 워크로드를 수행하고, 하나는 BI(Business Intelligence) 워크로드를 수행하고 마지막 나머지 하나는 e-메일 서비스를 수행할 수 있다.
    ▷내부적으로는 논리적 파티셔닝(LPAR) 기술을 사용해서, 어떤 가상 디스크 컨트롤러의 성능이 다른 어떤 가상 디스크 컨트롤러가 수행하는 워크로드로부터도 영향을 전혀 받지 않게 해준다. 표준 애플리케이션을 하나 또는 그 이상의 파티션 자체에서 수행할 수 있게 된다.

 

   2) SAN 상의 스토리지 블럭 가상화
    ▷ 대부분의 사람들이 스토리지 가상화를 이야기할 때, 주로 SAN 상의 스토리지 블록 가상화를 가리킨다고 보면 된다.
      - 이러한 형태의 가상화는 사용자로 하여금 제각기 물리적으로 다른 스토리지 컨트롤러에 들어있는 유휴 디스크 조각을 모아서 가상 디스크를 생성할 수 있게 해준다.
      - 예를 들어 어떤 관리자가 디스크 컨트롤러 A로부터 300GB의 유휴디스크를, 컨트롤러 B로부터는 500GB를, 컨트롤러 C로부터는 200GB의 유휴 디스크를 모아서 1TB의 가상 디스크를 생성할 수 있다.
      - 결국 스토리지 블록 가상화는 제각기 다른 스토리지 컨트롤러들로부터 작은 용량의 유휴 디스크 공간을 모아서 하나의 큰 디스크 풀을 만들어서 어떤 서버도 사용할 수 있게 만들고, 디스크 스토리지의 활용률을 획기적으로 향상시킨다.
    ▷ 블록 가상화는 3가지 방법이 있다.
      - 어플라이언스 형태(예, IBM SAN Volume Contoller 또는 IBM SVC)
      - 지능적인 SAN 스위치(예, EMC의 Invista)
      - 스토리지 컨트롤러 자체에 임베디드된 형태(예, 히타치의 TagmaStore)
    ▷ 어플라이언스 또는 스위치는 서버와 스토리지 컨트롤러 사이에 위치한다.
    ▷ 임베디드된 가상화는 서버들과 다른 스토리지 컨트롤러 사이에 존재한다.
    아래 그림은 스토리지 블럭 가상화의 구조도 이다.


    ▷ 구조
      - 스토리지 가상화 솔루션들은 모두 가상 디스크에서 실제 디스크로의 위치에 대한 맵핑을 유지한다.
    ▷ 가상화 방법
      - 맵핑을 통해 하나의 물리적 위치에 대응하고 있는 가상 디스크를 다른 물리적 위치로 이동하여 대응 시킬 수 있다.
      - 이 때 서버 및 애플리케이션은 서로에게 아무런 영향을 끼치거나 받지도 않으면서 정상적으로 작동된다.
    ▷ 장점
      - 이러한 기능으로 인해 스토리지 관리자는 애플리케이션의 가용성에 아무런 영향을 미치지 않고서도 서버에서 스토리지의 데이터 맵핑을 자유롭게 재구성할 수 있게 해준다.
      - 블럭 가상화은 전체 기업 내에 걸쳐서 일관된 방법으로 서버들이 필요로 하는 고급 기능을 제공할 수 있다.
       ·예를 들어, 모든 서버들에 대하여 동일한 방법으로 스냅샷 카피 또는 리모트 카피와 같은 카피 서비스 기능을 제공할 수 있다.
      - 서버들은 수많은 스토리지 컨트롤러들 대신에 하나의 SAN 상의스토리지 가상화 솔루션하고만 인터페이스를 유지하면 된다.
      - 또한 사용자들은 각 스토리지 컨트롤러마다 하나씩 제공되는 디바이스를 모두 올릴 필요도 없이 단지 하나의 디바이스 드라이버만 로딩하면 된다(실제로 각 디바이스 드라이버 간에 충돌 여부가 발생하기도 한다).

 

   3) 파일 가상화
      - 파일 가상화는 이기종 서버간에 진정한 의미의 파일 공유를 가능하게 한다.(아래 그림 참조)
      - 즉 파일 가상화 기술을 이용함으로써 기업 내의 어떤 컴퓨터 또는 어떤 서버로부터라도 동일한 파일 네임을 사용하여 공통된 파일 그룹에 대한 접근이 가능하다.
       · 예를 들어, 파일은 리눅스가 돌아가는 컴퓨터에서 생성되었지만 윈도우가 돌아가는 다른 서버에서 동일한 파일 네임을 가지고 접근이 가능하다.
       · 이렇게 되면 서로 다른 서버들간에도 HA(Hardware Address)를 위한 클러스터가 가능할 수 있게 된다. 


   4) 테이프 가상화
    ▷ 테이프 가상화는 아래 그림 처럼 디스크를 이용하여 테이프 드라이브 자원인 것처럼 에뮬레이션 함으로써, 서버입장에서는 테이프 드라이브로 데이터를 백업 받는다고 간주하지만 실제로 디스크로 데이터를 백업 받게 되는 것이다.
    ▷ 또한 데이터의 일부분이 테이프에 비해 좀 더 빠른 하드디스크스토리지 캐쉬에 저장되기만 해도 마치 전체 데이터가 테이프 카트리지에 전부 저장된 것처럼 보이게 해주는 방식을 통해 데이터를 고속으로 백업 받을 수 있게도 해준다.

  ○ 네트워크 가상화
    ▷ 애플리케이션이나 서버를 네트워크 또는 다른 가상 자원들에게 물리적으로 연결하는데 사용되는 IT 자원들을 가상화하는 능력들의 집합체로 볼 수 있다.
    ▷ 여기서 가상화 가능한 네트워크 자원들에는
      - IP 어드레스,
      - 네트워크 어댑터,
      - LAN,
      - 대역폭 관리 등이 포함된다.

 

  ○ 장점
    ▷ 네트워크를 가상화함으로써 사용자는 IT 인프라스트럭쳐에 걸쳐서 좀 더 효율적이고, 비용 효과적이며, 안정적이며 가용성 있는 통신체계를 만들기 위해 네트워크 요소를 풀링하고 공유할 수 있다.
    ▷ 또한 가상화된 네트워크는 좀 더 유연해짐으로써 사용자들이 최소한의 다운 타임 또는 실시간으로 비즈니스의 니즈에 대처하는데 필요하도록 인프라스트럭쳐를 변경할 수 있게 해준다.

 

  1) 공유를 가능하게 하는 기술

    ▷ 가상 LAN (VLAN) 기술
      - 소프트웨어적으로 구현되며, 컴퓨터의 네트워크를 구성할 때 실제 연결되지 않았으나 마치 물리적으로 연결된 것처럼 행동하게끔 설정한다. VLAN은 사용자 A의 데이터가 공유 네트워크 상에서 사용자 B의 데이터와 서로 섞이지 않도록 보장하기 위해 가상화의 절연 기능을 이용한다.
      - IP-SEC 프로토콜
       · IP 네트워크를 단절되고 독립된 많은 가상 네트워크(VPNs)처럼 보이게 함으로써 IP 네트워크를 좀 더 효율적이고 안전하게 공유될 수 있도록 사용된다.
       · 네트워크의 2개의 논리적 끝단 사이에서 암호화된 데이터의 일치성을 보장해준다.
      - 터널링 기술
       · 다중 프로토콜 스위칭(MPLS)은 단절 기능을 제공해주는 터널링 기술이며 주로 성능 개선 목적으로 사용된다.

    ▷ 다중 호스팅을 지원하는 HTTP 서버
      - 활용률을 증대시키고 자동 복구를 지원하기 위해서, 고객들은 하나의 물리적 애플리케이션 서버가 다수의 가상 어플리케이션 서버인 것처럼 보이게 하기 위해 다수의 가상 로컬 IP 어드레스를 사용할 수 있다.

    ▷ 어댑터 가상화 기술
      - 서버에 붙은 물리적 네트워크 어댑터가 여러 개인 것처럼 보이게 하여 네트워크의 연결을 단순화 시켜서 서버들간의 네트워크 연결의 효율성을 향상시킬 수 있다. 대표적인 예로 System z의 OSA-express L2-L3 공유기술 또는 System p의 가상 이더넷 기술을 들 수 있다.

 

   2) 자원 풀링을 가능하게 하는 기술
    ▷ 아래의 기술들은 가상화의 단일화 기능을 이용하여 사용자로 하여금 네트워크 요소들을 하나로 묶어서 사용하게끔 해준다.
      - 다양한 형태의 IP 워크로드 밸런싱 기술
       · 여러 대의 애플리케이션 서버들을 마치 하나의 단일 애플리케이션 서버 또는 인스턴스 처럼 보이게 해준다.
       · 워크로드 밸런서는 내부적으로 다수의 애플리케이션 서버 풀에서 각 서버의 용량과 가용성 정도에 대한 정보를 실시간으로 수집하면서 애플리케이션 인스턴스들에 걸쳐서 워크로드를 밸런싱 하면서도 외부적으로는 하나의 단일화된 애플리케이션 앤터티를 네트워크에 보여준다.
       · 대표적인 사례로는 z/OS의 Sysplex Distributor, Cisco사의 콘텐츠스위칭모듈(CSM), 노텔/알테온사의 Load Balancer 등이 있다.
      - 네트워크어댑터 가상화 기술
       · 다수의 애플리케이션 네트워크 연결을 연관된IP 어드레스로 이동시킴으로써 동일한 인스턴스로 보이게 해준다.
       · 그렇게 함으로써 네트워크 양 끝단에서 동적 라우팅의 구성이나 라우터 디스커버리 프로토콜을 수행 할 필요 없이도 네트워크상에서 더 높은 가용성을 얻을 수 있게 한다. VIPA takeover, IP address takeover 및VRRP 등이 그러한 기술들의 좋은 사례들이다

 

   3) 에뮬레이션과 추상화
    에뮬레이션 또는 추상화(Abstraction) 기능을 통해 사용자들은 애플리케이션 서비스 영역에서 엔드-투-엔드 연결을 프로비져닝하고 관리하는 기능을 제공해 줄 수 있다.
    ▷ 사용자들은 에뮬레이션 기술을 사용하여 애플리케이션 프로그래머들로 하여금 각 애플리케이션이 SSL 기반 하에 돌아가도록 일일이 코딩하는 노력을 덜어줄 수 있다. 그러한 기술들은 애플리케이션 서버가 연결 지향의 보안 체계를 갖는 것처럼 보이게 해준다(예를 들어 SSL 또는 TLS 지원). 그러한 에뮬레이션은 소켓 프로그래밍 인터페이스 레이어의 아래에 위치한 TCP 레이어에서 수행되어진다.
    ▷ 대역폭 관리 소프트웨어는 특히 WAN 구간 및 TCP를 사용하지 않는 인터넷 링크(예를 들어 스트리밍 오디오 및 비디오 애플리케이션)에서 네트워크 성능을 관리할 수 있는 수단을 제공해준다. 해당 소프트웨어는 TCP/IP 스택에 상주하면서 대역폭의 할당을 제어하기 위해 정책 기반의 관리 기법을 사용한다. 대표적인 예로 z/OS의 하나의 구성요소인 IBM Service Policy Agent를 들 수 있다.
    ▷ 사용자들은 하나의 서버 내에서 서로 다른 논리적 파티션들이 하나 이상의 LAN으로 연결되어 있는 것처럼 행동하게끔 만드는데 가상화를 사용할 수도 있다. 이러한 형태의 가상화를 지원하는 기술들에는 HiperSockets과 가상 이더넷 LAN이 있다.
    ▷ 가상 네트워크 어플라이언스는 여러 가지 형태의 네트워크에 특화된 기능들을 하나로 엮어주는 네트워크 애플리케이션의 일종으로서 외관상 하나의 박스 안에 또는 가상서버상의 전속된 하나의 인스턴스 안에 상주할 수도 있다.

 

   4) 네트워크 자원들의 관리
    ▷ 가상화는 네트워크에 대하여 또 다른 차원의 관리와 제어를 요구한다.
      - 예를 들어 열개의 가상 서버들이 하나의 10GB 네트워크 어댑터를 공유하고 있다고 가정하면
       · 열대의 가상 서버들 중 어떤 하나가 소비할 대역폭을 제한할 수 있는 어떤 제어 메커니즘이 필요하게 된다.
       · 그러한 제어는 대역폭 사용 정책을 정의하거나 가상 네트워크 인프라 스트럭쳐 내에서 네트워크 정책을 강제할 수 있는 에이전트를 제공함으로써 강제로 이행될 수 있다.
    ▷ 네트워크 가상화를 위해 요구되는 관리와 제어 기능들은 온 디맨드 운영 환경(ODOE)의 일부로서 정의되고 있다.
       · 네트워크 자원 매니저(NRM, Network Resource Manager) 요소는 기본적으로 통합된 토폴로지 정보, 비즈니스 연속성(네트워크 자원의 자동 복구) 그리고 그러한 환경에서 가능한 프로비져닝 체제를 제공할 것이다.
       · 그리고 이러한 지원은 WSDM 기반의 인터페이스의 집합 형태로 결합될 것이다.

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[14강] 클라우드 오해  (0) 2012.07.16
[12강] 가상화 엔진  (0) 2012.07.15
[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[8강] 클라우드 컴퓨팅 도입전략  (0) 2012.07.11
:

[10강] 서버 가상화

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 13. 10:47 | Posted by 깨비형
반응형

1. 서버 가상화 시장

 

  ○'서버 가상화'란 하나의 컴퓨터에서 여러 개의 운영체제를 설치해 여러 개의 서버처럼 운용하는 기술로, 현재는 VM웨어, 마이크로소프트, 시트릭스(젠소스 인수) 등이 관련 시장을 주도하고 있다.

 

  ○가상화 기술은 하나의 서버를 여러가지 용도로 사용한다는 점에서 총 소유비용을 줄일 수 있고, 유지보수 등도 훨씬 더 간편케 해 급성장할 것으로 예상되는 시장이다.

 

  ○ 서버 가상화 시장
    ▷ 현재 VM웨어가 약 시장의 70%를 장악하고 있다고 평가되는 등 무서운 기세를 올리고 있다.
    ▷ 이 힘을 바탕으로 VM웨어는 미국 나스닥 시장에서 돌풍을 일으키며, 모 기업인 EMC의 현금원이 됐다. 그러나 VM웨어를 공략하는 업체들의 움직임도 발빠르다.
    ▷ 최근 시트릭스는 오픈소스 서버 가상화 솔루션 업체 젠소스를 인수해 VM 웨어에 도전장을 던진 바 있다. 시트릭스는 시트릭스 젠서버 등 젠소스 기술을 이용한 솔루션을 선 보이며 VM웨어와의 '맞짱'을 선언했다.
    ▷ 마이크로소프트는 VM웨어에서 돌아가는 서버들을 MS 포맷으로 전환할 수 있도록 해주는 '시스템센터 버추얼머신매니저' 을 발표하며 VM웨어를 견제하기 시작했다. MS는 윈도 서버 2008에 비리디안(코드명)이라는 가상화 솔루션을 탑재해 VM웨어와 경재하고 있다.
    ▷ 오라클은 전 세계 소프트웨어 시장의 2위이지만, 기업용 SW시장에서는 실질적으로 1위를 달리고 있다. 세계적인 기업 중 오라클 제품에 의지하지 않고 있는 기업이 거의 없을 정도다. 오라클은 오라클 VM이 자사의 DB, 미들웨어, 애플리케이션을 지원한다는 것을 명확히 하고 있다. 기존 오라클 제품을 이용하는 고객이나, 미래의 오라클 고객을 주 타겟으로 하겠다는 전략이다. 과연 오라클이 VM웨어의 독주를 막을 수 있을 지 주목된다.

 


2. 서버 가상화 개념

 

  ○ 서버 가상화는
    ▷ 하나의 서버에서 여러 개의 애플리케이션, 미들웨어 및 운영체제(OS)들이 제각기 서로 알 필요도 없고, 서로 영향을 미치지 않으면서 동시에 사용될 수 있도록 해준다.

 

  ○ 서버 가상화의 초기 형태에는
    ▷ 가상 메모리, 가상 I/O 그리고 에뮬레이션 등이 포함되었다.
    ▷ 이러한 초기 형태의 가상화 기술들은 곧 애플리케이션 및 서브 시스템의 가상화로 발전되어서 다수의 애플리케이션, 서브 시스템 또는 미들웨어 스택들이 하나의 운영 체제 아래에서 통제를 받으면서 수행될 수 있게 해준다.

 

  ○ 아래 그림은 서버 가상화의 여러 가지 형태를 간단히 설명해주고 있다.
    ▷ 서버 내의 가상화의 대표적인 예로는 Managed Runtime, 물리적 분할, 가상 머신, 논리적 파티셔닝, 가상 I/O를 들 수 있다.

 


3. 서버 가상화 기술

 

   1) Managed Runtime
      - 오랫동안 대형서버들은 단일 OS 시스템(또는 OS 이미지) 위에서 상용의 대규모이면서 높은 가용성이 요구되는 애플리케이션들이 서로 영향을 미치지 않으면서 돌아갈 수 있도록 독립적인 메모리 스페이스 영역과 CPU 자원을 별도로 할당하는 아키텍쳐 디자인을 유지해 왔다.
      -  위측의 그림 처럼 애플리케이션 중심의 단일 사용보다는 공유에 적합하도록 디자인된 좀 더 발전된 형태의 아키텍쳐는 애플리케이션과 미들웨어 사이에서 절연(Isolation) 효과와 데이터 정합성을 보장해준다.
      - 오늘날 Sun의 SPARC/Solaris와 같은 아키텍쳐들과 운영 체제들은 Managed Runtime 또는 컨테이너를 제공하려고 진화하고 있다.

 

   2) 물리적 분할(Physical Partitioning)
    ▷ 서버 가상화는 하드웨어 자원들이 물리적으로 분할이라는 하위 자원 단위로 분할되어 사용할 수 있게 해준다. 이때의 물리적 분할은 대개 CPU 프로세서와 I/O 디바이스를 경계로 이루어지며, 각 파티션은 최소한 1개 이상의 CPU 프로세서를 가져야 한다.
    ▷ 각 파티션은 물리적으로 완전 격리된 형태로 구성되며, 그래서 파티션들은 일반적으로 유연하지 못하고 전체 시스템을 재부팅 하기 전까지는 변경되지 못한다.
    ▷주 프레임에서 최초 소개되었던 물리적 파티션은 이제 서버들이 좀더 안정화되고 경량화되면서 장점를 잃어가고 있고 아주 소수의 시스템들만이 제공할 뿐이다.
    ▷분할은 크게 물리적 분할, 소프트웨어적 분할(주로 가상 머신) 그리고 논리적 분할 등으로 구분할 수 있다.

 

   3) 가상 머신(Virtual Machine)
    ▷ 1970년대 초반 가상 머신(VM)의 도래는 가상화의 새로운 장을 열었다.
    ▷ 가상 머신을 이용한 서버 가상화는 소프트웨어적 파티셔닝 또는 OS 이미지 가상화라고도 불리운다.
    ▷ 여기서 가상 머신은 일종의 단순화되고 변형된 모체 OS로써, 이런 OS 위에 우리가 알고 있는 리눅스, 윈도우와 같은 완전한 OS 시스템이 설치되어 돌아갈 수 있게 된다.
    ▷ 아래의 그림은 이러한 가상 머신의 개념을 간단히 보여 주고 있다.


      - 가상 머신 위에서 가동되는 개별 OS 이미지는 실제 디바이스와 에뮬레이션된 디바이스 모두를 액세스할 수 있다.
      - 아래의 그림에 간단히 보여 주고 있다.

 

      - 이런 가상 머신의 개념은 최근에 나온 것은 아니다.
      - 오늘날 가상 머신은 아주 치밀하고 가변적이어서, 실제 및 가상 자원들 모두가 공유될 뿐만 아니라 가상 머신들 사이에서 시스템 재시작 없이도 동적으로 스위칭 될 수 있도록 해준다.
      - 가상 머신을 통해 OS 이미지를 가상화하는 능력이 주어짐에 따라, 사용자들은 추가 하드웨어 구입 없이도 새로운 OS의 설치, 애플리케이션의 테스팅 및 업그레이드를 동일한 물리적 서버상에서 동시에 수행 시킬 수 있다.
      - 이를 통해 같은 물리적 서버상에서 다른 OS 이미지로 가동되는 운영 시스템들간에 아무런 영향을 끼치지 않고서도 새로운 애플리케이션들을 동시에 테스팅 할 수 있게 된다.

 

   4) 논리적 분할(Logical Partitioning)
      - 논리적 분할 은 가상 머신과 물리적 분할 사이에 있는 뛰어난 서버 가상화 기능이다.
      - 가상 머신과 함께 논리적 분할 은 IT 인프라스트럭쳐를 가상화하기 위한 전략에 있어서 핵심 요소가 된다.
      - 논리적 분할 은 별도의 모체가 되는 OS 없이 하이퍼바이저(Hybervisor)라는 펌웨어 수준에서 하나 또는 그 이상의 OS 이미지들이 하나의 물리적 서버 위에서 동작할 수 있도록 해준다
      - 이러한 각 논리적 파티션은 고정 혹은 가변적인 개수의 프로세서를 가질 수 있다.
      - 물론 논리적 파티셔닝을 통해 물리적 파티셔닝 기능을 구현할 수도 있다.
      - 참고로 1개의 단일 프로세서의 일부분을 할당하여 동적인 논리적 파티션을 만드는 것은 마이크로 파티셔닝(Micro Partitioning)이라 부른다.
      - 또한 논리적 파티션간에 자원 활용의 불균형이 존재하는 경우에는 시스템이 제공하고 있는 고급 파워 가상화 기능의 하나인 파티션 로드 매니저를 활용할 수도 있다.
      - 파티션 로드 매니저는 각 논리적 파티션들의 사용률을 실시간으로 파악하여 미리 정해진 사용률 정책을 기반으로 하여 워크로드가 낮은 파티션의 CPU 및 메모리 자원을 실시간으로 워크로드가 높아진 파티션으로 자동 재분배해 줌으로써 최적의 시스템 효율성을 추구하게 해준다.
    ▷ 하이퍼바이저의 아키텍처 구현 방식 사례: VMWare ESX의 구조도를 보여 주고 있다

 


   5) I/O 가상화
    ▷ 필요성
      - 가상 머신과 논리적 분할만으로는 서버 내 가상화의 공유 및 절연(Isolation) 기능을 완벽하게 구현할 수는 없다.
      - 이를 보완하기 위해 어댑터와 같은 I/O 자원들을 공유하거나 또는 가상 머신들 간에 혹은 논리적 파티션들간에 I/O 통신을 할 필요가 있다.
    ▷ 해결방법
      - 서버와 운영체제의 결합을 통해 I/O 가상화를 구현하기 위한 여러 가지 방법을 제공하고 있다.
    ▷ 시스템의 가상 I/O 서버(VIOS)
      - 특별한 목적의 가상 분할로서, 다른 파티션들에게 I/O 자원을 공급하는 역할을 한다.
      - 가상 I/O 서버는 물리적 자원을 소유하면서 다른 파티션들에게 I/O 자원의 공유를 허용해준다.
      - 사용자들은 가상 I/O 기술덕분에 물리적 어댑터를 특정 파티션에만 할당하고서도 다른 파티션들과 공유해서 사용할 수 있게 된다.
    ▷ 결과
      - 각 파티션마다 별도로 네트워크 어댑터, 디스크 어댑터 그리고 디스크 드라이브를 가져야 하는 요구사항이 제거됨으로써 전체적인 비용을 낮출 수 있게 된다.
    ▷ 가상 I/O 서버가 가지는 I/O 가상화의 기능에 따라 3가지로 분류된다.
      - 가상 SCSI,
      - 가상 이더넷,
      - 공유 이더넷 어댑터(Shared Ethernet Adapter)

 

     ★ 가상 이더넷 (Virtual Ethernet)
      - 대표적인 I/O 가상화의 하나로써 가상화의 애뮬레이션 기능을 이용하고 있다.
      - 각 파티션들간에 물리적인 네트워크 어댑터 없이도 메모리 버스를 통하여 통신이 가능하게 해준다.
      - 이것은 동일한 물리적 하드웨어상에서 돌아가는 솔루션의 계층 요소들끼리 메모리상에서 고속, 고효율의 통신이 가능하다는 것이다.
      - 이를 통해 사용자들은 별도의 물리적 어댑터를 사용하지 않고서 또 어댑터 구매에 따르는 관리 및 비용 부담 없이도 절연, 네트워크 이중화 그리고 향상된 보안 체계를 가질 수 있다.

 

     ★ 공유 이더넷 어댑터(SEA: Sharable Ethernet Adaptor) :
      - 공유 이더넷 어댑터는 파티션의 개수보다 물리적 어댑터의 개수가 적은 경우에 여러 파티션들이 물리적 이더넷 어댑터를 공유할 수 있도록 해준다.
      - 또한 가상 이더넷에서 실제 네트워크 어댑터로 네트워크 트래픽을 보내줌으로써 가상 이더넷과 실제 물리적 이더넷을 연결하여 주기도 한다.
      - 아래 그림은 공유 이더넷 어댑터를 통한 가상 통신의 흐름도를 보여주고 있다.

 


     ★ 가상 SCSI
      - 한 대의 서버를 여러 개의 파티션으로 나누어 구성할 경우 가장 문제가 되는 부분이 I/O 어댑터의 부족이며,
      - 특히 외장 디스크를 사용할 수 있게 해주는 파이버 채널 어댑터가 절실히 부족하게 된다.
      - 이를 해결하기 위해 가상 I/O 서버의 개념이 필요하다.
      - 가상 I/O 서버는 물리적인 디스크를 실제로 소유한 파티션으로서 디스크 볼륨이 필요한 파티션들에게(파이버 채널 어댑터가 없음) 논리적 디스크 볼륨의 형태로 디스크 볼륨을 할당해준다.
      - 즉, 가상 I/O 서버 파티션에서 만들어져 제공된 논리적 디스크 볼륨은 이를 이용하는 다른 파티션들에게 SCSI 디스크 형태로 나타난다.

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[12강] 가상화 엔진  (0) 2012.07.15
[11강] 스토리지 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[8강] 클라우드 컴퓨팅 도입전략  (0) 2012.07.11
[7강] 클라우드 컴퓨팅 SaaS  (0) 2012.07.10
:

[9강] 가상화 개념

컴퓨터 활용/클라우드 컴퓨팅 | 2012. 7. 12. 06:59 | Posted by 깨비형
반응형

1. 가상화의 정의와 개념


  ○ 정의

      - 컴퓨터에서 컴퓨터 자원의 추상화을 일컫는 광범위한 용어임

      - "물리적인 컴퓨터 리소스의 특징을 다른 시스템, 응용 프로그램, 최종 사용자들이 자원과 상호 작용하는 방식으로부터 감추는 기술"로 정의할 수 있다.

      - 이것은 다중 논리 리소스로서의 기능을 하는 것처럼 보이는 서버, 운영체제, 응용 프로그램, 또는 저장장치와 같은 하나의 단일 물리적 자원을 만들어 낸다.

      - 아니면 단일 논리적 자원처럼 보이는 저장장치나 서버와 같은 여러 개의 물리적 지원을 만들어 낼 수 있다.


  ○ 가상화 유래

      - 이 용어는 오래되었다. 1960년대 이후로 널리 쓰였으며, 전체 컴퓨터 시스템에서 개별 기능/구성 요소에 까지 컴퓨터의 다른 많은 면과 영역에 적용되어 왔다.

      - 모든 가상화 기술의 공통 주제는 주변에 막을 씌워 "기술적으로 자세한 부분을 숨기는 것"이다.

      - 가상화는 다른 물리적 위치에서 리소스를 한데로 합치거나 제어 시스템을 단순하게 하여 다중 송수신 접근과 같은 것을 통해 기반이 되는 기능 추가를 보이지 않게 하는 외부 인터페이스를 만들어 낸다.

      - 새로운 가상 플랫폼과 기술의 최근 발전은 이렇게 성숙한 개념에 다시 한번 집중하게 만들었다.


  ○ 가상화 기술은 실제 존재하는 물리적 자원들을 논리적 자원들의 형태로 표시하는 기술로서, 물리적 자원을 이용하는 사용자(구체적으로 애플리케이션 및 서비스를 가리킴)에게는 논리적 형태로만 나타난다. 아래 그림 처럼 가상화 기술이 이들 논리적 자원들과 실제 물리적 자원들에 대한 연결을 담당해 줌으로써, 가상화 자원을 이용하는 사용자는 더 이상 어떤 자원들이 사용되는지를 구체적으로 알 필요가 없어진다.

  ○ 앞의 그림에서 보여주고 있는 것과 같이

    ▷ 가상화라는 중간 계층을 이용하여 애플리케이션과 서비스를 실제적인 자원들과 분리하는 이러한 형태는 사용자로 하여금 동일한 자원을 공유하게 해주고, IT 자원들을 개별 자원이라기 보다는 논리적인 자원 풀로서 사용하고 다루게 해준다.

    ▷ 서버내의 자원 분할(Partitioning)은 가상화의 대표적인 사례로서, 커다란 하나의 서버 시스템을 다수의 작은 시스템으로 보이게 해줌으로써 서버 자원을 공유하게 해준다.

    ▷ 또한 스토리지 가상화 기술은 여러 개의 물리적 스토리지 시스템들에 남아 있는 유휴 디스크을 모아서 만든 디스크 풀에서 가상화된 디스크를 만들 수 있게 해준다. 이렇게 가상화된 디스크에 접근함으로써 애플리케이션 서버는 실제로는 최대 사용 가능한 공간이 300MB 밖에 안되는 상황에서도 마치 1TB의 스토리지가 단독으로 붙어 있는 것처럼 간주하여 실행될 수 있다.


  ○ 결론적으로 가상화 기술은 실제로 존재하는 물리적 자원들에 대한 중재자 역할을 해주는 기술로써 위의 경우에 적용해 보면 가상화 기술은 애플리케이션 서버의 스토리지 요구를 가로채서 여러 개의 스토리지 컨트롤러에 걸쳐 있는 유휴 공간을 찾아내 줌으로써 스토리지 용량에 대한 요구를 만족시켜 주는 것이다.



2. 가상화의유형


  ○ 가상화는 일반적으로 서버, 스토리지 및 네트워크와 같은 전통적인 단위 하드웨어 자원에 많이 적용되어 왔다. 그러나 가상화의 적용 범위는 아래 그림처럼 단순히 하드웨어 차원의 IT 리소스에만 한정되지 않고 애플리케이션, 미들웨어, 분산 시스템 및 가상화 자원들 자체를 포함하여 비실체적인 자원들에 대해서도 적용될 수도 있다.



  ○ 위 그림에서 보여 준 것과 같이 가상화 범위는 다양하다.


  ○ 즉 미들웨어를 통한 워크로드의 가상화에는 잡 스케쥴러(JobScheduler)가 이용될 수 있으며, 애플리케이션 레벨의 가상화에는 애플리케이션 서버가 스스로 인스턴스를 제어하여 워크로드를 관리할 수도 있다. 대표적인 사례로 전자에는 다양한 그리드 스케쥴러가 있고, 후자에는 WAS-XD 같은 웹 애플리케이션을 들 수 있다.


  ○ 향후 전통적인 자원 가상화의 추세는 여전히 개별 하드웨어를 중심으로 이루어져 가겠지만, 새로운 형태의 가상화 역량이 추가적으로 요구되고 있다. 새로운 가상화 역량에는 작은 다수의 시스템 집합에서 가상 시스템을 만들어내거나 플랫폼과 벤더의 경계를 넘어서서 단순화되고 일관된 방식으로 관리될 수 있는 가상 시스템을 구현하는 것이 포함되어 있다. 여기에는 앞 페이지의 그림에서 관리의 가상화, 전사적 차원의 가상화 등이 포함될 수 있다.


  ○ 가상화의 적용 범위로

      - Infrastructure 계층의 디바이스, 네트워크, Power 가상화

      - Hardware, 계층의 서버와 저장장치 가상화

      - Operating Systems 계층의 운영체제 가상화

      - Middleware, 계층의 Applicaton 가상화

      - Workload 계층의 업무의 가상화

      - Bussiness Appplication 계층의 Database 가상화 등이 있다.


  ○ 여기서는 서버, 스토리지 및 네트워크 등 주로 하드웨어 인프라 차원에서의 가상화 기술에 설명해 나가도록 할 예정이며, 기회가 될 경우에 추가적으로 나머지 레이어에 대한 가상화 적용 기술들을 소개할 계획이다.


  ○ 가상화는 자원의 공유(Sharing), 단일화(Aggregation), 에뮬레이션(Emulation) 그리고 절연(Insulation)이라는 4가지 기본적인 기능을 가지고 있다. 아래 그림은 가상화의 기능별 종류 및 이에 따르는 사례들을 보여주고 있다.


   1) 공유(Sharing) :

    ▷ 가장 대표적인 가상화의 기능으로서 다수의 많은 가상 자원들이 하나의 동일한 물리적 자원과 연결되어 있거나 가리키는 것을 말한다. 물리적 자원의 일부분을 가상화된 자원마다 할당하거나 혹은 물리적 자원에 대하여 타임 쉐어링 기법으로 공유하는 방식이 주로 사용된다.

    ▷ 이러한 형태의 가상화는 가상화 자원을 사용하는 여러 사용자들(애플리케이션 또는 서비스)이 물리적 자원을 공유하게 해주며, 이때 각 사용자는 마치 자기가 해당 자원을 혼자서만 사용하는 것과 같은 착각을 하게 된다.

    ▷ 대표적 사례로는 서버 내의 논리적 분할, 가상머신(VM), 가상 디스크, 가상 LAN(VLANs)을 들 수 있다.


   2) 단일화(Aggregation) :

    ▷ 공유의 반대되는 가상화 개념으로서, 가상 자원은 여러 개의 물리적 자원들에 걸쳐서 만들어질 수 있으며, 이를 통해 외견상 전체 용량을 증가시키고 전체적인 관점에서 활용과 관리를 단순화시켜 줄 수 있다.

    ▷ 예를 들어, 스토리지 가상화는 여러 개의 물리적 디스크 시스템에 남아있는 각각의 유휴 디스크들을 하나의 가상화된 디스크로 만들어 주는데, 이때 가상화된 디스크는 가상 디스크를 만드는데 사용 되어진 어떤 물리적 디스크보다도 더 커질 수 있다


   3) 에뮬레이션(Emulation) :

    ▷ 물리적 자원 자체에는 원래부터 존재하지 않았지만 가상 자원에는 어떤 기능들이나 특성들을 마치 처음부터 존재했던 것처럼 가질 수 있다. 예를 들어 IP 네트워크 상에서 가상 SCSI 버스를 구현하는 iSCSI 또는 물리적 디스크 스토리지상에 구현된 가상 테이프 스토리지 등이 여기에 속한다. 또 다른 형태의 에뮬레이션에는 여러 개의 제각기 다른 물리적 자원들을 표준 구성요소 형태인 것처럼 가상 자원으로 표시하는 것이 있다. 여러 종류의 이더넷(Ethernet) 인터페이스를 마치 하나의 특정한 표준 이더넷 인터페이스 모델로 나타내는 것이 그 예이다.


   4) 절연 (Insulation) :

    ▷ 가상화된 자원들과 물리적 자원들간의 상호 맵핑은 가상화 자원들 또는 가상화 자원들을 사용하는 사용자들에게 아무런 영향을 미치지 않으면서 물리적 자원들이 교체될 수 있도록 해준다 . 이것은 투명한 변경(Transparent Change)이라고 불리우며, 투명한 변경은 가상화에 있어서 하나의 부가적인 혜택이기도 하지만, 때때로 그 자체가 하나의 기술로서 중요한 의미를 갖기도 한다. 어떤 가상 프로세서가 결함이 발생하였거나 혹은 곧 발생하려는 물리적 프로세서에서 다른 정상적인 물리적 프로세서로 자동적으로 옮겨간다거나, 디스크의 결함을 사용자들로부터 숨기기 위해 다중디스크(Redundant Disk)를 사용하는 RAID 스토리지 컨트롤러가 대표적인 사례이다. 달리 말해 장애 방지(Failure Proof)의 효과라고 볼 수 있다.


  ○ 가상화의 혜택은 가상화를 도입하려는 사용자들의 목표나 접근 방법, 채택된 기술 및 기존 IT 인프라스트럭쳐의 종류에 따라 크게 달라진다. 대부분의 사용자들은 (심지어는 단순히 서버 통합에 가상화를 사용하는 경우에도) 아래에 언급된 혜택들을 어느 정도 가질 수 있다. 또한 사용자들이 그들의 IT 인프라스트럭쳐를 가상화하는데 더 많은 노력을 기울일 때, 얻을 수 있는 가상화의 혜택은 그만큼 비례해서 커지게 된다. 아래 그림처럼 가상화 도입 시 얻을 수 있는 혜택들을 구체적으로 열거해 보면 다음과 같다.


   1) 높아진 자원의 활용률 :

      - 가상화는 물리적 자원들과 자원 풀에 대한 동적인 공유를 가능하게 해주며, 이를 통해 더 높은 자원의 활용률을 얻을 수 있다. 특히 평균 워크로드가 전체 자원의 워크로드 보다 훨씬 적은 가변적인 워크로드 상황에서는 더 높은 효과를 얻을 수 있다.


   2) 낮아진 관리 비용 :

      - 가상화는 관리해야 하는 물리적 자원들의 대수를 줄여줌으로써 관리 인력의 생산성을 향상시킬 수 있다.

      - 또한 물리적 자원들의 복잡성을 숨겨주고,

      - 자동화, 정보화 및 중앙화를 통해 공통된 관리 작업을 단순화시키고,

      - 워크로드 관리의 자동화를 가능하게 해준다.

      - 가상화는 이기종 플랫폼 환경에서도 관리 도구를 공통으로 사용할 수 있게 해준다


   3) 사용의 유연성:

      - 가상화는 빠르게 변화하는 비즈니스니스를 만족시키기 위하여 자원들이 동적으로 재구성되고 활용 될 수 있도록 해준다.


   4) 향상된 보안

      - 가상화는 단순한 공유 메커니즘에서는 불가능한 분리와 격리를 가능하게 해서 데이터와 서비스에 대하여 통제되고 안전한 액세스를 제공한다.


   5) 높아진 가용성

      - 가상화는 사용자레벨에 아무런 영향을 주지 않고도 물리적자원이 제거되거나 업그레이드 또는 변경 될 수 있도록 지원해 준다.


   6) 증가된 확장성

      - 자원 분할 및 단일화(Aggregation)는 가상화된 자원이 개별 물리적 자원보다 더 작아지거나 혹은 더 커질 수 있게 해준다.

      - 이를 통해 물리적 자원의 구성 변경이 없어도 필요한 만큼의 적정한 확장성을 얻을 수 있다.


   7) 상호 운영성 및 투자의보호

      - 가상화 자원들은 기존 물리적 자원들간에서는 불가능한 인터페이스와 프로토콜 레벨에서의 호환성을 제공해 준다.


   8) 향상된 프로비져닝 (Provisioning)

      - 가상화는 자원의 할당을 개별 물리적 단위보다도 더 세밀한 조각 단위에서 가능하게 해준다


  ○ 가상화를 도입하려고 할 때 처음부터 전사적 차원에서 접근할 필요는 없다. 오히려 장기적인 IT 발전 방향에 대한 로드맵을 그린 다음 단계적으로 가상화를 기업 내에서 확산 시켜나가는 접근 방법이 필요하다. 이러 접근 방법에 맞추어 가상화를 도입하는 순서는 동질적 가상화에서 시작하여 이질적 가상화, 전사적 가상화를 거쳐 마지막으로 글로벌 가상화로 점점 범위를 확대하면서 기업 내의 역량이 이에 따라 갈수 있도록 보조를 맞추어 가는 것이 중요하다. 아래 그림은 가상화의 단계별 발전 과정을 모형화하여 보여주고 있다.



  ○ 먼저 동질적 가상화(Virtualize like resources)란 가상화의 도입을 처음으로 고려할 경우에 많이 발생하며, 조직 또는 부서 단위에서 동일한 또는 비슷한 자원들을 하나의 가상 풀로 묶는 것이다. 여기에는 스토리지 가상화가 대표적인 예이다.


  ○ 이질적 가상화(Virtulaize unlike resources)란 OS 또는 애플리케이션처럼 성격이 다른 자원들을 하나로 묶는 것으로 워크플로우 (Workflow:작업흐름도)와 관련 있는 모든 자원들을 가상화하는 단계를 말한다. 여기에는 트랜잭션 또는 워크플로우의 자동화가 필수적이며, 가상화 엔진 또는 그리드 구축이 구체적인 예이다.


  ○ 가상화가 기업 내에 어느 정도 진척이 되면 전사적 가상화(Virtualize the enterprise)의 단계로 넘어간다. 이 단계에서는 모든 자원들이 동적으로 관리가 되며 각 부서간에 사용량에 따른 비용 할당이 가능하게 된다.


  ○ 마지막 단계의 가상화는 기업의 경계를 넘어서서 비즈니스 파트너와 심지어는 고객까지도 가상화의 주체로 참여하는 글로벌 가상화(Virtualize outside the enterprise)로 이행한다.



3. 가상화의 기술 분류


  ○ 시장에서 실제로 활용되고 있는 다양한 가상화 기술들은 분류 방식에 따라 여러 가지로 나누어볼 수 있다.


  ○ 먼저 이전의 앞 가상화 적용 범위의 그림처럼 가상화 계층의 위치에 따라

    ▷ 하드웨어 가상화에서부터

    ▷ OS 가상화, 애플리케이션 가상화, 관리 가상화 등으로 단계적으로 나누어볼 수 있으며

    ▷ 혹은 가상화가 적용되는 물리적 범위를 기준으로 시스템 내부 가상화, 시스템 외부 가상화 등으로 나누어볼 수도 있다. 물론 이외에도 다양한 분류 방법이 있을 수 있다.


  ○ 여기서는 후자의 경우처럼 가상화가 시스템 내부에 구현되었는가 또는 시스템 외부간에 구현되었는가에 따라 시스템 내부 가상화와 시스템 외부 가상화로 크게 나누었으며 각각은 다시 서버 가상화와 스토리지 가상화로 좀 더 세밀히 나눌 수가 있다. 한편 네트워크 가상화는 특성상 분류가 어려워 별도의 가상화 항목으로 배치하였다. 이것을 정리하면 다음 페이지 그림과 같이 나타낼 수 있다.


  ○ 아래의 그림은 가상화에 대한 기술 분류를 보여 주고 있다.



  ○ 서버 가상화와 스토리지 가상화 그리고 네트워크 가상화를 각각 나누어 진다.


  ○ 이들을 공통적으로 지원하는 차세대 가상화의 대표적인 실체인 가상화 엔진(Virtualization Engine)이 필요하다. 이들 내용은 가상화 설명의 끝 단계에서 자세히 설명한다.


반응형
:
반응형

1. 클라우드 선정 절차


  ○ 서비스 재고 (1) : 서비스 유형

    ▷ 현재 기업 아키텍처의 필요사항을 충족시키기 위해 사용자가 선택할 수 있는 클라우드 컴퓨팅 유형 또는 카테고리는 수없이 존재한다.

    ▷ 따라서, 필요한 서비스 유형을 선택하여야 한다.

    ▷ 서비스 유형은 (3~6강 내용 복습)

      - SaaS(Software-as-a-Service: 서비스 형태로 제공되는 보안 기능),

      - TaaS(Testing-as-a-Service: 서비스 형태로 제공되는 테스트 기능)

      - PaaS(Platform-as-a-Service: 서비스 형태로 제공되는 플랫폼)

      - IaaS(Infrastructure-as-a-Service: 서비스 형태로 제공되는 인프라)

      -위의 모두 서비스의 종류에 관계없이 모두 각자의 상충요소(Tradeoffs)가 있고, 각자가 해결하려는 문제 영역이 있다. 어쨌든 사용자는 자신의 아키텍처를 판단 기준으로 삼아야 한다.


  ○ 서비스 재고 (2): 클라우드 서비스 카테고리

   ※ 다양한 클라우드 서비스 카테고리는 아래와 같이 분류된다.


     - 스토리지

   - 데이터베이스

   - 정보

   - 프로세스

   - 애플리케이션

   - 플랫폼

   - 통합

   - 보안

   - 관리/거버넌스(Governance)

   - 테스팅, 그리고

   - 인프라스트럭처



  ○ 서비스 재고 (3) : 서비스의 재 분류

   ※ 소분류

    ▷ 솔루션

      - 공급업체별로 정도로 특정 문제들만을 해결해주는 서비스

    ▷ 서비스는

      - 스토리지, 데이터베이스, 정보, 프로세스, 통합, 보안, 관리/거버넌스, 그리고 테스팅 서비스

   ※ 대분류

    ▷ 솔류션

      - 공급업체별로 독자적으로도 완벽한 플랫폼을 제공하는 서비스

    ▷ 서비스는

      - 애플리케이션, 플랫폼 그리고 인프라 서비스

      - 하나의 대분류 클라우드 컴퓨팅 서비스 업체가 여러 개의 소분류 자원으로 구성될 수 있음


  ○ 서비스 재고 (4) : 서비스 분류별 구성요소

    ▷ 프로세스의 경우,

      - 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 프로세스, 통합

    ▷ 데이터의 경우,

      - 서비스 구성요소는 애플리케이션, 플랫폼, 인프라, 스토리지, DB, 정보

    ▷ 서비스의 경우,

      - 서비스 구성요소: 애플리케이션, 플랫폼, 인프라, 그리고 정보

    ▷ 서비스 업체가 제공하는 것을 한 예의 가상 구조적 분류를 기준의 한예

      - 프로세스 : Appian Anywhere를 통한 프로세스 서비스.

      - 데이터 : 아마존 EC2(Elastic Computing Cloud)를 통한 인프라 서비스와 아마존 Simple DB를 통한 데이터베이스 서비스.

      - 서비스 : 아마존 EC2를 통한 인프라 서비스

       · 사용자는 데이터를 아마존 EC2 플랫폼뿐 아니라 아마존 Simple DB에 저장할 수도 있다.

       · 그 다음, 사용자는 가령, 해당 플랫폼 내에서 온디맨드(On-Demand) 방식으로 제공되는 애플리케이션(application) 서버를 이용해 아마존 EC2 플랫폼 상에서 서비스를 구축 및 호스팅할 수 있다.

       · 끝으로, 사용자는 이런 프로세스들이 운용될 플랫폼으로 Appian Anywhere를 사용할 수 도 있다.

       · 프로세스가 서비스와 연결되고, 서비스는 데이터에 연결된다는 점을 명심하라. 사용자는 여기서 단지 대상 플랫폼을 선정할 뿐이다.

    ▷ 예를 들면, 하나의 PaaS(Platform-as-a-Service) 공급업체가

      - 스토리지, 데이터베이스, 프로세스, 보안 그리고 테스팅 서비스를 한꺼번에 제공할 수도 있다.

      - 여러 개의 소분류 자원을 제공하는 하나의 대분류 클라우드 컴퓨팅을 사용하는 것이 더 편할 수도 있겠지만, 판단은 전적으로 사용자 아키텍처의 요구사항 몫이다.

    ▷ 요구사항 및 자체 아키텍처와의 완벽한 연결을 고려했을 때, 여러 개의 소분류 클라우드 솔루션을 선택하는 것이 사용자의 아키텍처와 더 잘 어울린다고 판단할 수도 있다.

    ▷ 그러므로 클라우드 컴퓨팅 서비스 업체 카테고리 후보를 다음과 같은 아키텍처상의 구성요소를 기준으로 생각하는 것이 도움이 된다.

    ▷ 더 많은 클라우드 컴퓨팅 공급업체가 관련된 좀 더 복잡한 예를 살펴보자.

      - 프로세스 : Appian Anywhere를 통한 프로세스 서비스와 세일즈포스닷컴을 통한 애플리케이션 서비스

      - 데이터 : 3Tera Cloudware와 아마존 EC2를 통한 인프라 서비스 그리고 아마존 Simple DB를 통한 데이터베이스 서비스

      - 서비스 : 아마존 EC2, 3Tera Cloudware를 통한 인프라 서비스와 세일즈닷컴을 통한 애플리케이션 서비스, 그리고 세일즈포스닷컴의 포스닷컴

(Force.com)을 통한 플랫폼 서비스

    ▷ 혹은, 다음과 같이 단일 클라우드 컴퓨팅 공급업체를 통해 간단한 방식을 택할 수도 있다.

      - 프로세스 : 아마존 EC2를 통한 프로세스 서비스

      - 데이터 : 아마존 EC2를 통한 인프라 서비스

      - 서비스 : 아마존 EC2를 통한 인프라 서비스

    ▷ 이뿐만 아니라, 사용자는 자신의 필요에 따라 구내 또는 클라우드에 설치할 수 있는 보안, 테스팅, 그리고 거버넌스 등 다른 핵심 아키텍처 구성요소도 고려할 필요가 있다.

    ▷ 이렇게 설명하는 이유는 사용자가 가지고 있는 구조적 선택사항에 대해 설명하고 아키텍처, 최종적으로는 기업의 요구조건 충족을 위해 필요한 만큼의 선택사항을 이용하여 최종 아키텍처를 형성하기 위해 선택사항들을 어떻게 조합할 수 있는지를 보여주기 위함이다.



2. 클라우드 이전 과정


  ○ 다음 페이지의 그림은 보여준 매핑 과정 후에, 사용자가 올바른 클라우드 컴퓨팅 카테고리, 그리고 마침내는 적합한 클라우드 컴퓨팅 서비스 업체를 찾아내 자신의 프로세스, 서비스, 그리고 데이터를 좋은 클라우드 컴퓨팅 후보로 선정된 서비스 업체로 이전할 때 활용할 수 있는 전체 과정을 나타낸 것이다.


  ○ 핵심 단계는 다음과 같다.

     ① 후보 플랫폼 목록 작성

     ② 후보 플랫폼 분석과 시험

     ③ 타깃 플랫폼 선정

     ④ 타깃 플랫폼 설치

 


  ○ 아래의 그림은 프로세스의 각 단계와 프로세스, 서비스 그리고 데이터들에 대한 요구조건을 파악하고,그 요구조건들을 적합한 기술에 매핑 과정을 도시하고 있다.



   1)1단계 : 후보 플랫폼 목록 작성

    ▷ 사용자는 자신의 ”미래”아키텍처에 적합할 것으로 보이는 클라우드 컴퓨팅 플랫폼 목록을 일부 또는 전체 작성할 필요가 있다. 이를 위해서는 어떤 플랫폼들이 있는지, 어떤 카테고리에 속해 있는지 그리고 어떤 기능을 하는지 사용자가 정확하게 이해하고 있어야만 한다.

    ▷ 클라우드 컴퓨팅 솔루션이 어떠해야 하는지를 정의하는 확고 부동한 규칙은 존재하지 않는다. 그러므로 많은 소프트웨어 공급업체들이 자신들의 솔루션이 진정한 클라우드 컴퓨팅 솔루션이든 아니든, 클라우드 솔루션을 가지고 있다고 말하는 경향이 있다.

    ▷ 예를 들면, 일부 소프트웨어 공급업체들은 자사의 소프트웨어가 웹을 통해서 구내 컴퓨팅 시스템으로 다운로드 될 수 있으므로 자신들이 On-Demand 방식 또는 클라우드 컴퓨팅 플랫폼이라고 주장하고 있다. 사실은 그렇지 않다. 결국, 이 단계는 단지 목록을 주고받는 게 아니라 옥석을 구분하는 과정이다.

    ▷ 클라우드 컴퓨팅에 통달하기 위해서는 각 공급업체들이 제공하는 게 무엇인지를 이해하고 있어야 하므로 시장 상황이 어떻게 돌아가고 있는지를 꿰뚫고 있어야 한다. 그러므로 다음 두 가지 질문에 답을 할 수 있어야 한다.

      ① 필요한 것이 어떤 카테고리인가?

      ② 그 카테고리에 속해 있는 클라우드 컴퓨팅 공급업체

    ▷ 누구를 목록에 포함시킬 것인가? 채택할 카테고리는 최종 논리 아키텍처와 이 프로세스 동안 밝혀낸 요구사항에 의해 결정된다.


 1 단계에서 몇 가지 일반적인 사항들 고려해야 한다. 즉 반드시 필요한 기본적인 계층과 각 계층에서 확인해야 할 사항이 있다(<그림> 참조). 기본적인 계층으로는 스토리지, 데이터베이스, 프로세스, 서비스, 보안, 거버넌스 그리고 관리 계층 등이 있다. 아래의 그림은 핵심 아키텍처에서 요구되는 스토리지, 데이터, 애플리케이션, 거버넌스, 보안, 서비스 그리고 프로세스들의 연관 관계를 보여 주고 있다.



  ○ 스토리지 (Storage)

    ▷ 아키텍처의 일부 또는 전체를 지원하는 파일 시스템의 저장, 공유, 그리고 관리를 가능케 해주는 클라우드 서비스이다.

    ▷ 이를 위해서는 흔히 스토리지 서비스만 제공하는 클라우드 컴퓨팅 서비스 업체나 IssS의 일부로 스토리지 서비스를 제공하는 공급업체의 SaaS를 사용한다.

    ▷ 여기서 확인해야 할 사항은 용량(Capacity)과 성능이다.

      - 용량은 아키텍처 지원을 위해 필요에 따라 스토리지를 확장할 수 있게 해주는 기능이다.

      - 성능은 기업의 원활한 운영에 도움이 되는 속도로 클라우드 컴퓨팅 서비스와 파일을 교환하는 기능을 말한다.

    ▷ 여기서, 성능 문제가 가장 중요한 문제이므로 반드시 테스트를 해야 한다.


  ○ 데이터베이스 (DataBase)

    ▷ 이는 플랫폼, DB 또는 인프라 서비스를 이용한 데이터의 저장과 검색 기능이다.

    ▷ 여기서 고려할 사항으로는 클라우드를 통해 전달되는 DB에서 사용자의 아키텍처가 필요로 하는 특성과 기능이 포함되어 있는 지이다.

      - 다시 말해 내장 함수(Stored Procedures)와 트리거(Triggers), API 함수, 표준 함수, 그리고 성능 등을 확인해야 한다.

    ▷ IaaS에 국한해서 보면, 클라우드 컴퓨팅 서비스 업체들은 대개 오라클이나 MySQL 같은 잘 알려진 DB 만 제공한다.

      - DaaS(Database-as-a-Service) 공급업체들은 대개 자체 개발한 데이터베이스를 사용하므로 업체 고유의 DB 인 경우가 많다.

    ▷ 여기서도 성능이 한 몫을 한다.

      - 구내에 설치된 기존 애플리케이션은 대개 데이터 입출력 집중형이므로, 여기서도 유사한 성능 문제가 존재함을 알게 될 것이다.

      - 여러 사용자가 공유하는 플랫폼의 입출력 오버헤드(Overhead)와 인터넷을 통해 다량의 데이터를 클라우드 컴퓨팅 업체와 기업이 교환할 때 발생할 수 있는 지연시간(Latency)를 고려해야 한다.

    ▷ 이 때문에 데이터베이스 DB 를 사용하는 프로세스와 서비스 가까이에 데이터베이스를 두기로 결정할 수도 있다.

      - 이는 데이터베이스의 성능과 신뢰성을 고려한 아키텍처의 핵심 원칙이다


  ○ 프로세스 (Process)

    ▷ 대부분의 경우, 프로세스, 플랫폼, 애플리케이션, 그리고 인프라 공급업체들 상에 존재할 수 있다.

    ▷ 고려할 사항은 프로세스 공급업체가 제공하는 프로세스뿐이다.

      - 사용자가 다른 구조적 구성요소(대개는 서비스와 데이터)를 프로세스에 묶어 주어야 한다.

      - 데이터와 서비스는 시스템 내부 혹은 다른 클라우드 컴퓨팅 공급업체에 있으므로 통합 작업이 이루어지고 있는 지를 확인해야 한다.

      - 프로세스의 신뢰성 확인도 역시 사용자의 몫이다.

    ▷ SaaS 경우

      - 공급업체들은 대개 사용자가 자신의 프로세스를 생성할 수 있는 플랫폼을 제공하지는 않지만, 자신들의 플랫폼에서 사전에 구축된 프로세스를 사용하는 것은 허용한다. 왜냐하면, 공급업체가 제공하는 사전에 구축된 프로세스를 사용하면되므로 사용자가 맞춤형 주문처리 프로세스를 만들 필요가 없기 때문이다.

    ▷ IaaS와 PaaS(Platform-as-a-Service) 경우

      - 대개의 경우 스토리지, 데이터베이스, 프로세스, 애플리케이션 서비스, 개발, 그리고 테스팅이 포함된 “완벽한 스택”을 제공하는 플랫폼을 다루고 있음을 의미한다. 프로세스들은 그런 플랫폼들의 한 구성요소일 뿐이다.

       · “완벽한 스택”공급업체들은 클라우드 컴퓨팅의 원스톱 쇼핑이므로, 이런 공급업체를 이용하고 싶은 생각도 들것이다. 어떤 PaaS 공급업체의 애플리케이션 개발 기능은 엄청 마음에 드는데, 제품을 관리하는 방식이나 제공하는 프로세스 엔진은 전혀 마음에 들지 않는 경우에는 절충을 해야만 할 것이다. 많은 경우, 간편성이 희생되더라도 기업의 아키텍처에 적합한 프로세스를 활용하기 위해서는 해당 프로세스를 처리하기 위해 다른 클라우드 컴퓨팅 공급업체나 심지어는 구내 소프트웨어를 이용하는 것이 더 낫다.


  ○ 서비스 (Service)

    ▷ 일반적으로 말해서, 웹 서비스 같은 서비스는 대부분의 클라우드 컴퓨팅 플랫폼에 존재 할 수 있다.

    ▷ 하지만, 소수의 클라우드 컴퓨팅 공급업체들(플랫폼, 프로세스, 그리고 인프라 서비스공급업체)만이 서비스를 생성해서 호스팅 할 수 있는 능력을 제공한다.

    ▷ 반면, 애플리케이션, 정보 서비스 공급업체들은 자신들이 호스팅 하는 사전 구축된 서비스에 대한 액세스는 허용하지만, 서비스 수정은 불가능하다.

    ▷ 가장 일반적인 문제는 성능이다.

    ▷ 웹 서비스 같은 서비스들은 (REST나 SOAP사용에 관계없이) 서비스를 호스팅하는 플랫폼이서비스에 컴퓨팅 자원을 충분히 제공하지 못하거나 플랫폼과 네트워크를 포화상태로 만들 정도로 서비스가 너무 많을 경우에 성능 문제를 일으키는 경향이 있다.

    ▷ 실제로 서비스를 사용하여 플랫폼을 테스트하고 나서 플랫폼, 사용하는 서비스 개수, 아키텍처의 성능을 최적화하기 위해 서비스를 설계한 방식 등을 조정해야 한다.


  ○ 보안 (Security)

    ▷ 필요한 요구조건을 기반으로 아키텍처를 보호하기 위한 전략과 모델을 만들어 보안을 처리해야 한다.

    ▷ 보안은 구내 또는 클라우드 컴퓨팅 플랫폼상에 존재하는 플랫폼도 아니고 소프트웨어도 아니다. 제대로만 구현하면, 구내든 아니면 클라우드 컴퓨팅을 통해서건 보안 기능이 제공되는 위치와 역할 분담에 상관없이 아키텍처의 구조적 속성(Systematic Attribute)이 될 것이다.

    ▷ 적절한 접근방식과 요소 기술을 선택한다.

      - 이런 노력이 ID 관리와 ID 관리를 지원하는 표준을 중심으로 이루어지고 있다.

      - SOA(Service-oriented Architecture)와 클라우드 컴퓨팅을 이용한 SOA 같은 더 복잡하고 분산된 아키텍처를 지원하는 차원에서 ID 관리에 대한 관심이 높아지면서, 이 영역을 더 잘 정의하기 위한 표준의 필요성이 대두되고 있다.

    ▷ 왜 ID 관리가 필요한가?

    ▷ 이런 표준들은 모든 조직의 ID 관리 시스템을 통합된 하나로 함께 묶어 모든 사용자들이 안전하게 알 수 있도록 하는 것을 목표로 하고 있다.

    ▷ 클라우드 컴퓨팅을 사용하는 순간부터 서비스들을 내부에서만 사용하던 시절은 막을 내린다.

    ▷ 서비스를 사용하는 사람(소비자)이나 서비스를 만드는 사람(공급자)이 서로 상대방을 알지 못하면 악의적인 행동이나 부정확한 행동을 감수해야 한다.

    ▷ 그 결과 대단히 비싼 대가를 치르게 될 수도 있다.

    ▷ 클라우드 컴퓨팅에서는 이것이 현실이다.


  ○ 거버넌스 (Gorvernace):

    ▷ 거버넌스 시스템은

      - 클라우드 컴퓨팅의 각종 정책을 구현, 관리, 집행한다.

      - 속성상 런타임(Runtime)이며, 대개는 구내에 존재한다.

    ▷ 중요한 요소는 성능이다.

      - 어떤 때는 정책을 집행하면 시간지연 문제가 발생하는 경우가 있다.

      - 이에 대한 성능 저하 요소가 있는 지를 판단해야 한다.

      - 또 다른 요소는 능력이다.

      - 클라우드를 통해 전달되는 서비스에 해당하는 자원들을 관리하기 위한 거버넌스 메커니즘의 능력이다.

      - 거버넌스 기술이 리포지토리(Repository) 내에서 원격 서비스를 추적할 수 있는 능력과 실행 중에 해당 서비스들을 감시할 수 있는 능력을 가지고 있는지를 의미한다.


  ○ 관리 (Management)

    ▷ 관리 기술

      - 클라우드 컴퓨팅을 이용한 서비스 구조는 분산되어 있는 경우가 많고, 복잡한 구조이다. 이러한 클라우드 컴퓨팅 구조를 총괄하는 기술이다.

    ▷ 클라우드 도입 시에 관리 기술 확인

      - 클라우드 공급업체의 관리기술이 대화형 인터페이스를 가지고 있는 지를 확인해야 한다.

      - 핵심은 “동작을 하는지 하지 않는지를 알 수 있는 수준”에서 구내 시스템과 클라우드 컴퓨팅 기반 시스템을 모두를 볼 수 있는 관리 시스템을 제공하는 지를 검토 해야 한다.

      - 이를 바탕으로, 최소한 시스템이 다운되었는지, 그 상태가 다른 시스템에는 어떻게 영향을 주고 있는지를 파악 할 수 있다.

    ▷ 좀 더 섬세한 수준, 즉 서비스, 프로세스, 데이터, 스토리지 별로 시스템을 볼 수 있는 관리 시스템을 확보하여 문제를 진단하고, 실제로 문제가 발생하기 전에 이를 감지할 수 있는 시스템을 갖는 것이 바람직하다.

    ▷ 관리와 거버넌스는 밀접하게 연계되어 있으며, 매우 유사한 패턴을 갖는다.


  ○ 2단계 : 후보 플랫폼 분석과 시험 (Test) -1

    ▷ 사전에 설정한 요구조건을 충족시키는지 분석 및 확인

      - 이 작업은 선정한 각 후보 플랫폼을 심층적으로 분석한 다음, 시험을 통해 수행한다.

    ▷ 클라우드 시험

      - 실제로는 클라우드 컴퓨팅 플랫폼의 포괄적인 능력을 시험한다는 점에서 구내 시험과 약간 다르다.

      - 좀 더 구체적으로 말하면, 구성요소들을 실제로 플랫폼 상에 설치하기 전에 해당 클라우드 플랫폼이 서비스, 데이터, 그리고 프로세스를 포함한 구조적 구성요소의 요구조건을 어떻게 수용하는지 검토하게 될 것이다.

    ▷ 성능 모델링 (Modeling)

    ▷ 모델링은 서로 다른 유형의 부하 상태에서 시스템이 어떻게 동작해야 하는지에 대한 시뮬레이션을 만들어 낸다. 대개 경량, 중급, 대량으로 구분한다.

      - 어떻게 정보가 흐르고 어떤 서비스가 호출되는지, 그리고 그런 사항들이 구내와 클라우드 기반 컴퓨팅 자원들에게는 어떤 영향을 주는 지 등 아키텍처를 모델링하는 것을 의미한다.


  ○ 2단계 : 후보 플랫폼 분석과 시험 (Test) - 2

    ▷ 성능 시험 (Testing)

      - 성능 실험이란 부하가 걸렸을 때 아키텍처가 어떤 성능을 제공하는 지를 결정하기 위해 테스팅을 진행한다는 것을 의미한다.

      - 클라우드 컴퓨팅에서 어느 정도의 성능을 기대할 수 있는지, 그리고 처리 능력 감소와 대역폭 확장 같은 상황들이 전체 성능에는 어떤 영향을 주는지 등에 대해 감은 잡을 수 있다. 성능 모델을 입증하는 동안에는 성능 테스팅을 사용해야 한다.

    ▷ 본 후보 프랫폼의 분석과 시험 의미

      - 클라우드 기반의 전체 아키텍처가 얼마나 잘, 그리고 얼마나 빨리 업무를 지원하는지를 평가하는 것이다.

      - 더 나가서, 끊임없이 증가하는 스토리지, 데이터베이스, 프로세스, 그리고 서비스 처리 부하 상태에서 시스템이 어떤 성능을 제공하는지도 측정해야 한다.

      - 이러한 과정을 통해서 네트워크, 데이터베이스, 그리고 서비스 같은 잠재적 병목 구간을 찾아서 이를 수용하거나, 대안을 찾거나 아니면 포기하고 다른 업체를 찾을 수도 있다.


  ○ 3단계 : Target 플랫폼 선정

    ▷ 클라우드 컴퓨팅 플랫폼을 선정

      - 일단 이 모든 분석과정과 보안과 거버넌스를 감안한 다음에 후보 시스템 목록을 종합해서 검증 시험을 완료된 후에 클라우드 컴퓨팅 플랫폼을 선정한다.

      - 요구조건 충족을 하였는가?

    ▷ 클라우드 컴퓨팅 공급업체가 어떠한 상태인가?

      - 공급업체의 생존력과 사용자의 클라우드 컴퓨팅 플랫폼을 지속적으로 지원할 가능성

      - 하드웨어, 소프트웨어, 그리고 네트워크 장애로부터 복구하는 능력

      - SLA(Service Level Agreement와 사용자의 아키텍처를 위해 어느 정도의 서비스 레벨이 지원되어야 하는 지에 대한 클라우드 공급업체와 사용자 간의 공감대

      - 클라우드 컴퓨팅 공급업체의 정책과 어떤 것이 위반 사항인지에 대한 완벽한 이해


  ○ 4단계 : Target 플랫폼 설치

    ▷ 실행단계

      - 사용자가 실제로 코드를 포팅하고, 데이터를 이전하며, 새로운 서비스, 프로세스 그리고 데이터베이스를 생성하며, 이 모든 서비스, 데이터베이스, 그리고 프로세스가 제대로 동작하는지를 테스트하고 검증하는 단계이다.

      - 이전과 개발을 중심으로 하는 접근방식을 택해야 한다.

      - 가장 중요한 것부터 시작해서 중요도가 가장 낮은 것의 순서로 아키텍처 중의 어떤 구성요소를 이동시키거나 클라우드 컴퓨팅 플랫폼에서 생성해야 할지를 결정해야 한다.

    ▷ 아키텍처의 구성요소를 클라우드 컴퓨팅 플랫폼으로 이동시킬 때, 제대로 기능하는 지를 확인하고 다음 구성요소로 넘어가기 전에 적절하게 테스트되었는지도 확인한다.

    ▷ 점진적인 접근방식이 문제도 없고 클라우드 컴퓨팅 플랫폼에 서비스, 데이터, 그리고 프로세스를 설치하는 사람들이 일에 치이지 않게 해 준다.

    ▷ 이런 접근방식은 일을 해나가면서 배울 수 있는 학습 효과도 제공하므로 프로세스가 진행됨에 따라 클라우드 컴퓨팅 플랫폼을 사용자의 아키텍처에 맞게 작동시키는 방법에 대한 지식도 크게 증진될 것이다.


  ○ 최종 단계 : 새로운 클라우드 컴퓨팅 플랫폼 수용

    ▷ 실행 및 운영 단계

      - 실제로 시스템을 클라우드로 옮겨서 그 시스템들을 업무에 맞게 동작시키는 작업이다.

      - 기획이나 분석보다는 실행 작업이지만, 관련된 작업 중 가장 까다로운 작업이 기도 하므로 위험부담도 가장 크다.

    ▷ 클라우드 컴퓨팅은 아직도 변화하고 있는 중이기 때문에 광고와 시장이 뜨거워짐에 따라 매주 새로운 공급업체가 등장하고, 기존 공급업체들은 시장을 장악하기 위해 더 많은 기능성을 추가하기에 여념이 없다.

    ▷ 클라우드 컴퓨팅 플랫폼은 지속적으로 수행해야 하는 작업이다. 즉 정기적인 업그레이드, 버그 수정, 그리고 플랫폼에 대한 다른 변경사항의 원인이 되는 소프트웨어 배포가 필요하다.

    ▷ 이런 변경사항들이 전체 시스템을 더 나은 방향으로 유도하고 이런 플랫폼 상에 존재하는 아키텍처 상의 구성요소를 훼손하는 일은 없어야 한다.

반응형

'컴퓨터 활용 > 클라우드 컴퓨팅' 카테고리의 다른 글

[10강] 서버 가상화  (0) 2012.07.13
[9강] 가상화 개념  (0) 2012.07.12
[7강] 클라우드 컴퓨팅 SaaS  (0) 2012.07.10
[6강] 클라우드 컴퓨팅 PaaS  (0) 2012.07.09
[5강] 클라우드 컴퓨팅 IaaS  (0) 2012.07.08
:
반응형

1. SaaS의 특징

 

  ○ SaaS란
    ▷ 기업 및 개인을 대상으로 응용 소프트웨어를 서비스로 제공하는 것을 말한다.
      - 예를 들어 노트북, PC, 스마트폰 등에 응용 소프트웨어가 설치되어 있지 않아도 인터넷을 통해 접속하여  응용소프트웨어를 사용할 수 있는 환경이다.
    ▷ 서비스로서의 소프트웨어를 뜻하는 말 이다. 사용자가 응용 소프트웨어를 구입하지 않아도 웹에서 응용 소프트웨어를 빌려 쓰는 서비스이다.
      - 이런 SaaS의 장점은 따로 회사 내에 구축비용이나 유지, 관리하는 비용이소요되지 않아 가격 경쟁력이  있다. 그래서 중소기업을 타켓으로 마케팅 하기 유리하다. 중소기업이 아무래도 업무환경에서나 업무의  질을 높이기 위한 투자능력이 떨어지기 때문이다. 최근 들어, 중소기업에서 대기업으로 영역이 넓혀 지고  있다.

 

  ○SaaS의 특징
    ▷ 자신의 PC나 기업/조직내의 서버에 소프트웨어를 설치 할 필요가 없다.
    ▷ Web 브라우저 등을 사용하고, 서비스를 제공하는 기업의 서버에 액세스하고, 그 기능만을 이용한다.
    ▷ 응용 소프트웨어의 도입 작업이 불필요하기 때문에 곧바로 이용을 개시할 수 있다.
    ▷ 응용 소프트웨어나 서버를 관리하는 수고를 줄일 수 있는 일도 특징이다.
    ▷ 응용 소프트웨어를 설치 한 서버는 SaaS의 제공 기업이 관리한다.
    ▷ 응용 소프트의 버전 업 등도 제공 사업자가 알아서 실시해 준다.

 

  ○SaaS와 같은 서비스로서는,
    ▷ 앞에서 언급한 것과 같이 ASP(어플리케이션·서비스·프로바이더)가 있다.
    ▷ ASP는 2000년 즈음에 주목 받았다. 당시는 인터넷 회선이 그만큼 빠르지 않았던 것과 사용자 마다  서비스 내용을 제공 하는 것이 어려웠다. 일부를 제외해 그만큼 보급하지 않았다.
    ▷ 이 결점을 보충한 것이, SaaS라고 할 수 있다.
    ▷ SaaS에서는 사용자의 요구에 맞추어 기능이나 설정을 제공 할 수 있다.
    ▷ 회선 사용료도 염가로 되어 있어, SaaS를 이용하기 쉬운 환경이 갖추어져 오고 있다고 말할 수 있다.

 

  ○ SaaS의 모델의 비지니스적 특징
    ① 가입(Subscription) 기반의 SaaS이다. 즉, 소비자가 매월 또는 매년 정해진 비용을 지불하는 모델이다.
    ② 거래(Transaction) 기반의 SaaS이다. 즉, 거래가 발생한 만큼 비용을 지불하는 일종의 종량제 모델이다.
    ③ 광고(Advertisement) 기반의 SaaS이다. 즉,PPC(Pay Per Click) e-비즈니스 모델처럼 관련 광고를 보는  대신 무료로 서비스를 이용하는 모델이다.

 

  ○ SaaS 모형의 주요 특징
    ① 사용자 요청에 따른 커스트마이징 없이 네트워크 기반 접속 및 관리되는 상업용 소프트웨어의 제공 서비스이다.
    ② 사용자가 사용하는 응용소프트웨어를 원격으로 웹(혹은 인터넷)을 통하여 중앙에서 관리활동이 이루어 진다.
    ③ 응용소프트웨어의 제공이 전형적으로 Architecture, Pricing, Partnering and Management Characteriss

        를 포함하는 1대1 모형이 아니라 Single Instance, Multi-Tenant Architecture를 포함하는 1대다 모형에 가깝다.

 

  ○ SaaS의 채택 이유
    ▷ SaaS의 빌려주는 서비스 특성상 한 번 고객을 확보하면 매년 지속적인 매출을 올리는 것이 가능하다.
    ▷ 실제로 중소 SW업체에서는 개발비용 외에 별도의 다른 비용이 크게 들지않아 영업이익률이 매우 높다.
    ▷ 게다가 ASP와 확연히 다른 것이, 웹 표준을 지켜 개발하기 때문에 확장성이 높고 다양한 브라우저에서도 동일한 서비스가 제공된다는 점과 웹 표준을 지원하는 여러 서비스들을 얼마든지 쉽게 지원 할 수 있다.
    ▷ 그리고 비용측면에서 SaaS가 우수해서 빠른 속도로 시장이 성장하고 있다. 처음에는 중소기업 중심으로 SaaS를 사용하다가 지금은 대기업에서도 관심을 보이고 있다.

 

  ○ 국내업체
    ▷ 국내업체에서도 최근 다우기술, 맨인소프트, 유니닥스, 유니온정보시스템, 키컴, 화이트정보통신 등은 자사의 솔루션을 SaaS 형태로 제공하기 시작했다.
    ▷ 가온아이
      - 가온아이의 서비스 유형은 웹 표준 개발 방식이 아니어서 아직 ASP에 가깝다고 볼 수 있다. 수만여 명의 이용자를 확보하고 있다.
    ▷ 다우기술에서 국내기술로 만든 SaaS 기반 업무관리 위한 SaaS방식의 솔루션 출시
      - ‘트윈캠프(www.twincamp.com)’이라는 팀 업무관리용 SaaS 서비스이다.
      - 업무관리 서비스로 만든 트윈캠프는 보통의 기업용 업무관리 솔루션에서 팀단위, 중소기업단위로 특화해서 개발한 제품으로 프로젝트 관리. 업무관리. 캘린더, 메일 게시판, 웹 자료실, 보고서, 주소록, 근태관리 등의 기능이 있어서 팀 단위에서 효율적인 업무관리가 될 수 있도록 개발된 업무관리 서비스 입니다.
      - 중소기업을 중심으로 상당한 호평을 받고 있는 제품입니다. SaaS가 구축비용과 유지비용이 들지 않다는 점을 살려서 중소기업이나 팀 단위에 적은 비용으로 서비스하고 있다. 업계에서 상당한 주목을 받고 있다. SaaS의 장점을 업무관리 솔루션에 성공적으로 접목시켰다.
    ▷ 유니닥스
      - 지식콘텐츠를 전자책(e북) 형태로 관리해 내외부의 승인된 사용자가 쉽고 편하게 열람할 수 있게 하는 솔루션을 SaaS 형태로 제공한다. 유니닥스는 IBM에 IT인프라스트럭처 맡겨 서비스 운영을 위한 특별한 노하우 없이 새로운 비즈니스 모델을 창출했다.
    ▷ 화이트정보통신
      - 인사관리 솔루션 대표 업체인 화이트정보통신도 SaaS 시장에 진출한다고 한다.
    ▷ 아직은 국내 업체가 자체기술이 부족해 SaaS를 해외업체와 제휴해 개발하고 있는 실정이지만 다우기술에서 만든 트윈캠프 처럼 국산 기술로 만든 SaaS 제품도 개발되고 있는 만큼, SaaS기술의 국산화에 기대해봐야 될 것 같다.

 

  ○ 국내 SW업체 : SaaS 신제품 출시 봇물
    ▷ SaaS의 특성상 한 번 고객을 확보하면 매년 지속적인 매출을 올리는 것이 가능하다. 특히 비용이 크게 들지 않아 영업이익률도 매우 높다.
    ▷ KT 비즈메카 플랫폼을 통해 그룹웨어를 SaaS 형태로 서비스하고 있는 가온아이는 현재 1500여 개의 고객사에서 4만여 명의 이용자를 확보하고 있다.
    ▷ SaaS 모델이 가온아이 매출에서 아주 큰 부분을 차지하고 있지는 않지만, 순 매출이기 때문에 이익에서 차지하는 부분은 크다.
    ▷ 실제로 세계적으로 가장 유명한 SaaS 회사인 세일즈포스닷컴은 올 1분기 순이익이 지난 해 동기보다 무려 13배 늘어났다. 또 SaaS는 초기 도입비용이 낮아 중소기업에 적당하다는 점도 장점이다.
    ▷ 대부분의 국산SW기업들은 대기업보다 중견중소 기업 시장을 대상으로 활동하고 있는데, IT투자 여력이 낮은 이들 중견중소기업 시장을 공략하기에 SaaS가 안성맞춤이기 때문이다.
    ▷ 한 SW 업체 사장은 "솔루션 영업으로 글로벌 업체와 경쟁하는 것에 너무 지쳤다"면서 "SaaS가 새로운 돌파구가 될 것으로 기대한다"고 말했다.

 

  ○ 국외업체 : 세일즈포스닷컴
    ▷ 설립
      - 세일즈포스닷컴은, 오라클사의 임원이었던 마크 베니오프(Marc Benioff)가, 업무 애플리케이션을 웹 서비스로 제공한다고 하는 기치 아래, 1999년 3월 8일에 설립하였다. 본격적인 SaaS 방식 클라우드 컴퓨팅 서비스를 제공하는 최초의 기업이라고 회자된다.
    ▷ 현황
      - 여러 지역을 커버하는 지역 거점을 마련하고 있다. 그 외에 토론토, 뉴욕, 런던, 시드니, 샌마테오 등에 주요 지사가 있다. 2008년 9월, 프레디맥(Freddie Mac)과 파니매(Fannie Mae)로 바뀌어, 패스티널(Fastenal)과 함께 S&P500를 구성하는 종목이 되었다.
      - 세일즈포스닷컴 서비스는 16가지 언어로 이용 가능하고, 2010년 10월 31일 현재 세계적으로 87,200개사에 도입되어 200만명 이상의 사용자가 있다.
      - 지금까지 영업 지원(SFA), 고객 관리(CRM) 소프트웨어의 SaaS벤더로서 실적을 쌓아왔다. 하지만 최근에는 우체국 회사나 주식회사 패스트 리테일링를 시작으로, Force.com(PaaS)으로 커스텀 애플리케이션을 구축하는 사례가 늘어나면서, 서비스를 적용하는 업무의 폭이 확장되고 있다.
      - 또한, Force.com에 대응되는 언어의 추가(VMForce(Java), Heroku(Ruby)), Database.com)가 발표되는 등, 플랫폼 기업을 목표로 하는 것과 동시에 서비스의 오픈화를 추진하는 입장을 밝히고 있다.
      - 현재 KT가 세일즈포스닷컴과 제휴을 했고, 예전에는 다우기술과 총판 계약하기도 했다.
    ▷ 제품 및 서비스
      - 세일즈포스닷컴의 서비스는 모두 인터넷으로 제공되는 클라우드 컴퓨팅 모델이다. 서비스는 SaaS형 애플리케이션인 Salesforce CRM과, PaaS형 Force.com 플랫폼으로 나눌 수 있다. Multi-Tenent를 적용한 SaaS 방식의 서비스를 제공하여, 서비스를 받는 많은 기업들에게 필요한 기능을 미리 다 갖추어 놓고 있다
    ▷Salesforce CRM(SaaS형 CRM)
      - 클라우드 컴퓨팅 모델의 통합 CRM(고객 관계 관리) 응용프로그램이다.
      - SFA(영업 지원 시스템), 마케팅, 서비스&지원, 대리점 관리, 모바일, 아이디어스, 콘텐츠 관리 응용프로그램과 함께, Google Apps나 Google AdWords와 제휴 응용프로그램도 제공한다.
      - 기능 제약에 따라 5가지 판본(Edition)이 있다.
    ▷AppExchange
      - AppExchange는 SaaS형 애플리케이션 시장으로, 2005년에 발표되었다.
      - 외부 개발자 등에 의해서 개발된 유상 및 무상의 애플리케이션이 공개되고 있어 기존의 환경에 설치하여 이용할 수 있다.
      - 2008년 9월 현재, 450개 이상의 ISV(독립계 소프트웨어 제공사) 등에 의해 800개 이상의 애플리케이션이 탑재되고 있으며 설치 실적은 65,000본 이상이다.
    ▷지원 언어
      - 세일즈포스닷컴의 서비스는 다음 16가지 언어를 지원한다.
      - 한국어, 영어, 일본어, 네덜란드어, 스페인어, 독일어, 프랑스어, 이탈리아어, 포르투갈어, 러시아어, 타이어, 덴마크어, 간체 및 번체, 스웨덴어, 핀란드어
    ▷Trust.salesforce.com
      - 보안에 관한 정보나 서비스 가동 상황을 공개하고 있는 사이트이다. 현재 및 과거 30일간 시스템의 가동 상황을 열람할 수 있다.

 

  ○ ASP와 SaaS 모두 인터넷을 통해 애플리케이션을 빌려 쓰는 개념으로 아래의 그림은 APS에서 SaaS로 변화하는 과정을 도시하고 있다. 1990년 ASP 시장이 형성되어 2003년 SaaS 시장으로 진화하고 있는 것을 보여주고 있다.

 

 


  ○ ASP (Application Service Provider) 개념은
    ▷ 응용소프트웨어 임대 애플리케이션 서비스 제공업체이다. 즉 웹 애플리케이션 호스팅 서비스를 하는 사업이다.
    ▷ 웹 애플리케이션 호스팅 서비스는 소프트웨어를 패키지 형태로 판매하지 않고 일정한 요금을 받고 인터넷을 통해 임대해 주는 서비스이다.
    ▷ 즉 인터넷과 같은 통신망을 통해 전사적자원관리(ERP), 제품정보관리(PDM), 그룹웨어, 전자상거래(EC), 전자문서교환(EDI) 등 하이엔드 애플리케이션은 물론 오피스 제품 등을 빌려주는 것이다.
    ▷ 소프트웨어의 여러 기능 중에서 사용자가 필요로 하는 서비스만 이용 가능하도록 제공하는 소프트웨어 서비스형 소프트웨어(SaaS)이다.
    ▷ 소프트웨어 유통 방식의 근본적인 변화를 설명하는 개념으로, 공급업체가 하나의 플랫폼을 이용해 다수의 고객에게 소프트웨어 서비스를 제공하고, 사용자는 이용한 만큼 돈을 지불한다.

 

  ○ 결론적으로 차이점을 설명하면
    ▷ SaaS는 ASP에서 진화된 서비스이다. (앞 페이지의 그림 참고)
    ▷ SaaS에서는 웹에서 단일한 플랫폼을 기반으로 동일한 버전의 애플리케이션을 모든 소비자에게 공급하기 때문에 ‘1대 다’ 서비스를 하는 것이 가능합니다. 이에 비해 ASP는 소비자의 요구에 따라 제공해줘야 하기 때문에 ‘1대 다’ 서비스하기가 어렵다.

 

  ○ 클라우드 컴퓨팅의 기존적인 서비스 분류
    ▷ 첫째, 하드웨어 인프라를 서비스로 제공하는 IaaS (Infrastructure As A Service),
    ▷ 둘째, 응용 개발 및 실행 플랫폼을 서비스로 제공하는 PaaS (Platform As A Service),
    ▷ 셋째, 응용 (Applications)을 서비스로 제공하는 SaaS (Software As A Service)로 나눈다.
   ※ IaaS는 앞장에서 언급한 것과 같이 서비스 형태로 제공되는 컴퓨팅 자원(서버, 스토리지, 네트워크)을 의미하는데 보통 운영체계 (Operating System), 가상화, 클러스터링과 같은 소프트웨어들이 포함된다. IaaS로 가장 잘 알려진 상용 서비스로는 Amazon 의 웹 서비스 (AWS)가 있으며 AWS는 컴퓨팅 서버를 제공하는 Elastic Compute Cloud (EC2) 서비스와 스토리지를 제공하는 Simple Storage Service (S3) 서비스가 포함된다.
   ※ PaaS도 앞장에서 언급한 것과 같이 응용 소프트웨어 개발을 위한 플랫폼을 응용 개발자들에게 서비스 형태로 제공하는 것을 의미하며 이러한 PaaS 서비스를 통해 응용 개발자들은 빠른 SaaS 응용을 개발하고 배치하여 고객에게 제공할 수 있다. PaaS의 대표적인 예는 구글의 AppEngine, AppScale 과 세일즈포스닷컴의 Force.com, EngineYard의 AppCloud 등이 있다.
   ※ 여기에서 언급하는, SaaS는 클라우드 서비스 중 가장 일반적인 유형으로 인터넷을 통해 엔드 유저에게 응용을 제공하는 것이다. 이러한 서비스는 Gmail과 같은 단순 웹 기반의 email에서 SugerCRM과 같은 CRM소프트웨어에 이르기까지 다양한 범위에 적용된다. SaaS 가 기존의 ASP(Application Service Provider)와 구분되는 가장 큰 특징은 하나의
소프트웨어 인스턴스로 여러 사용자 (tenant)에게 커스터마이징 된 어플리케이션을 제공해 주는 것으로서 이러한 기능을 멀티 테넌시(multitenancy)라고 한다. 멀티테넌시 제공으로 고효율, 저비용의 어플리케이션 제공이 클라우드 컴퓨팅 환경에서 가능하다.

 


2. SaaS의 플랫폼의 구조

 

  ○ SaaS 플랫폼은
    ▷ SaaS를 제공하기 위한 공통 기능들로 구성되며 일반적으로 SaaS를 개발하고 배치하기 위한 PaaS 플랫폼과 많은 부분을 공유한다.

  ○ SaaS의 응용 설정
    ▷ 테넌트가 어플리케이션 사용자 인터페이스, 데이터 스키마 및 워크 플로우 등을 개별적으로 설정 가능하게 하는 기능 블록이고, 멀티테넌트 실행환경은 rule engine, workflow processing, 메타 데이터 기반 테넌트별 코드 생성기를 포함한다.
 

  ○ Mash-up 환경
    ▷ Twitter나 Facebook 등의 open API 및 통신 사업자의 유무선 통신 관련 서비스 API 등과의 통합 매쉬업 환경을 제공한다.

 

  ○ 멀티테넌트 데이터 관리자
    ▷ 멀티테넌시를 위한 메타데이타와 테넌트별 데이타를 관리한다. 특히 고속의 서비스 생성 및 배치를 위한 메타데이타 캐쉬 및 테넌트별 데이터 보안을 위한 테넌트별 데이터 접근 제어 등을 지원한다.

 

  ○ SaaS 개발환경
    ▷ 멀티테넌트를 고려한 응용 개발자를 위한 UI 생성, 비즈니스 로직 생성 등의 통합 실행 환경을 제공한다.

 

  ○ 상용 SaaS 플랫폼 (PaaS)으로 가장 많이 사용되고 있는 것들
    ▷ Google의 AppEngine, MS의 Azure 등이 이 있으며, 현재 많은 기업이나 프로젝트에서 시도되고 있는 오픈 소스 기반의 PaaS 플랫폼으로 대표적인 것들은 Appscale, Stratos 등이 있다.

 

  ○ SaaS 플랫폼의 일반적인 구성

 

 

  ○ SaaS 방식으로 전달되는 소프트웨어의 핵심 특징
    ▷ 네트워크 기반으로 접근하고 관리하는 상업적으로 사용 가능한 소프트웨어
    ▷ 각 고객 사이트가 아닌 중앙의 위치에서 활동을 관리, 고객이 웹을 통해 애플리케이션에 접근하도록 함
    ▷ 애플리케이션 전달은 일반적으로 일대일 모델보다는 일대다 모델 (single instance, multi-tenant 아키텍처)에 가까우며, 여기에는 아키텍처, 가격, 파트너링, 관리 특성이 포함
    ▷ 중앙화된 기능 업데이트로 패치와 업그레이드 다운로드 필요를 없앰.

 

  ○서비스 형태
    ▷ 넷 네이티브 : 전용 응용 프로그램을 활용한 직접 개발하고 네트워크를 통해 다중사용자에게 서비스하는 ASP의 사업형태.
    ▷ 웹 네이티브 : 순수 웹 기반의 응용 프로그램을 개발하고 웹 서비스 또는 웹 애플리케이션 형태로 제공.
    ▷ 주문형 소프트웨어 : 상업용 소프트웨어의 인터넷을 통한 서비스.

 


3. 국내 외 SaaS 서비스의 사례

 

   ※ 해외에서 세일즈포스닷컴이 크게 확산되어 사용되고 있는 이유

 

1) 세일즈포스닷컴은 영업 활동에 꼭 필요한 영업 자동화(Sales Force Automation)를 지원한다.
    ▷ 많은 기업에는 필수적으로 영업 담당자가 존재한다. 이러한 영업 사원이 사용하여 효과를 볼 수 있는 서비스가 무엇이 있을까?
      - 대량의 이메일 마케팅은 마케팅 담당자가 고객 정보에 기반하여 일종이 광고를 하는 것이고 콜센터의 경우 지원 담당자가 고객의 불만/요구/문제를 해결해 줌으로서 새로운 기회를 만드는 과정이라고 볼 수 있다.
      - 다시말하면 영업 담당자가 활용할 수 있는 도구는 아니라는 말이다.
    ▷ 영업 담당자는 고객과의 관계를 통해 고객의 니드와 영업기회를 발굴하고 이를 효과적으로 지원하여 비즈니스 계약을 채결하는 주 목표로 한다.
    ▷ 세일즈포스닷컴은 이를 시스템화하여 영업 사원 개인의 역량이 아니라 기업의 역량을 영업 담당자에게 실어 주어 영업을 활성화하는 쳬계를 갖추고 있다.

 

2) 프로세스(Workflow)에 기반한 체계적인 관리를 통해 성과를 향상 시킨다.
    ▷ 국내 CRM이 크게 확산이 되지 못한 이유를 생각해 보자.
      - 국내 CRM은 고객 정보를 체계적으로 습득하고 관리하고 분류하여 매스 이메일 마케팅에 활용하여 왔다. 또한 그 정보를 콜센터를 통해 지원하거나 Outbound Call을 통해 전화 영업에 활용하여 왔다. 즉 프로세스가 없고 데이터 마이닝만 존재하는 CRM이 확산되었다.
    ▷ 세일즈포스닷컴은 영업 담당자가 시장에 접근하는 효율적인 프로세스를 제공하고 있다. 프로세스란 무엇인가 ?
      - 여러분들도 알다시피, 프로세스를 따르는데는 여러가지 불편한 점이 발생한다. 프로세스를 유지/발전시키기 위해서는 지금까지 관리하지 않았던 여러가지 정보를 입력하여야 해서, 영업 담당자의 경우 "영업하기도 바쁜데 무엇을 등록해서 관리하라는 것인가"하는 불만이 쌓이게 마련이다.
    ▷ 그러나, 프로세스를 구축하면 다양한 영업 활동이 가시화되어 체계적으로 관리가 가능하다. 이를 통해 기업은 회사 차원에서 영업 사원을 지원할 수 있고 불필요한 단계를 제거하거나 효과적으로 프로세스를 개선할 수 있다.
    ▷ 프로세스를 활용하면 단기적으로 효과는 약할지 모르나 중 장기적으로 효과가 극대화 되는데는 이러한 이유가 있다.
    ▷ 세일즈포스닷컴은 전세계적으로 CRM 구축을 진행하면서 마케팅/영업/지원 프로세스를 최적화하여 왔고 이를 홈페이지를 통해 제공하고 있다. 최적화된 프로세스를 적용하는 것이 바로 CRM 분야에서 선진 기법을 도입하는 것이라 할 수 있다.

 

3) 오픈 API를 통해 다양한 확장성을 제공한다.
    ▷ Enterprise 기업에서 새로운 시스템을 도입할 때 중요하게 생각하는 요소중의 하나는 기존의 도입된 시스템과 어떻게 조화를 이룰 것인가 하는 것이다.
    ▷ 기업은 추가 개발을 하거나 EAI, ESB 등의 시스템을 도입해서 이 문제를 해결해 왔다.
    ▷ 세일즈포스닷컴은 웹 서비스 기반의 오픈 API를 공개하여 고객, 파트너가 자유롭게 서비스를 사용/구현해 이 문제를 해결하도록 지원하고 있다.

      - 단순히 고객과 관련된 정보를 수집 축적하고 일정 관리를 하는 것이 최선일까?
      - 또한 이를 통해 미래를 예측하거나 관리하는 것이 최선일까?

  ○ 많은 기업들이 세일즈포스닷컴을 도입하면서 도입의 효과로 보는 것은 다음과 같을 것이다.
    ▷ 첫째. 영업 담당자 개인에 속해 있는 영업 정보를 회사의 자산화한다.
    ▷ 둘째. 영업 담당자의 일정을 확인하고 관리할 수 있다.
    ▷ 셋째. 영업 실적과 Forecast를 가시화하여 영업 담담자를 채찍질 할 수 있다.
    ▷ 위에서 언급한 효과는 회사 차원, 관리 차원의 효과이지 영업 담당자의 영업 활동에 필요한 효과가 아니라고 생각한다. 영업 정보를 공유하고 실적을 공유하기 위해서는 Excel로 관리하고 주간 보고를 받아도 된다.

 

   ※ 세일즈포스닷컴의 사용의 효과는 크게 다음 두 가지로 볼 수 있다.

 

  ○ 첫째. 프로세스에 기반한 업무의 가시화와 개선
    ▷ 세일즈포스닷컴은 CRM 활동에 필요한 다양한 프로세스를 홈페이지를 통해 공개하고 있다. 또한 해당 프로세스는 죽어 있는 프로세스가 아니라 기업에 적용하고 개선한 프로세스를 계속 update하여 Bestof-Best 프로세스로 관리하고 있다.
    ▷ 세일즈포스닷컴 도입시 이를 기업에 적용하여 시스템화 하여야 한다. 이를 위해 필요한 경우 세일즈포스닷컴의 컨설턴트의 도움을 받을 수도 있을 것이다.


  ○ 둘째. 세일즈포스닷컴에서 제공하는 다양한 기능의 효과적인 활용
    ▷ 세일즈포스닷컴은 마케팅, 영엽, 지원 등을 포괄하는 다양한 기능을 제공하고 있다.
    ▷ 세일즈포스닷컴을 도입한 국내의 많은 기업은 이들 기능을 충분히 활용하고 있지 못한 것 같다. List Price로 사용자당 연간 1500$나 하는 고가의 CRM을 도입하고도 세일즈포스닷컴이 제공하는 기능의 30%도 활용하지 못한다면 너무나 낭비적이지 않을까.

반응형
:
반응형

1. PaaS의 선택 이유


  ○ PaaS란(Platform as a Service)
    ▷ SW가 아닌 표준화된 플랫폼을 서비스로 제공하는 형태입니다.
    ▷ SaaS를 사용하다 보면 다른 어플리케이션들과 통합의 한계에 부딪치게
        됩니다. 그래서 SaaS를 제공하는데서 OpenAPI 형태로 통합할 수 있는
        플랫폼을 제공합니다.
    ▷ 예를 들어 구글은 구글앱스라는 SaaS 를 제공하고, 더 확장하여 앱스엔진
        이라는 PaaS 를 제공합니다.
    ▷ 구글 앱 엔진(Google App Engine) 등을 살펴 PaaS가 무엇인지에 대한
        아이디어를 얻는다.

  ○ PaaS가 불러오는 도전
    ▷ PaaS가 사용자에게 도전이 되는 이유는 무엇인가?
    ▷ 이들 플랫폼의 의심할 바 없는 역량과 생산성이 기업들에게는 많은 애플리
        케이션을 배치하고 나기까지는 구현할 수 없을지 모를 새로운 이슈들을
        불러올 것이기 때문이다.


 

  ○ PaaS의 선택이유
    ▷ PaaS는 서비스 제공업체가 자체 하드웨어 인프라에서 호스트하는 소프트
        웨어와 제품 개발 도구를 제공하는 클라우드 서비스 유형이다.
    ▷ PaaS라는 용어는 사용자 정의 애플리케이션을 빌드하고 실행하는 데

        활용할 수 있는 클라우드 기반 플랫폼에서 일반적으로 사용된다.
    ▷ PaaS 애플리케이션은 인터넷에 연결된 어느 곳에서나 액세스할 수 있는
        서비스와 웹 애플리케이션을 빌드하고 전개하는 데 필요한 모든 것을

        제공한다. 일반 사용자는 이러한 이러한 시스템을 다운로드하거나 설치,

        유지할 필요가 없다.
    ▷ PaaS 오퍼링에는 가상 서버 및 스토리지, 데이터베이스와 같은 일련의

        기본 서비스가 포함되어 있다. 사용자는 이러한 서비스를 통해 PaaS 플랫폼
        에서 이용할 수 있는 API나 도구를 사용하여 PaaS 플랫폼에서 애플리

        케이션을 빌드할 수 있다.

 

  다음은 가장 일반적으로 사용되는 PaaS 플랫폼이다.


  ○ Google App Engine
    ▷ Google의 인프라에서 웹 애플리케이션을 실행해 보도록 하자. Python이나

        Java™ 기술을 사용하여 웹 애플리케이션을 작성할 수 있다.


  ○ Microsoft® Windows® Azure
    ▷ 클라우드 애플리케이션과 서비스를 작성할 수 있는 Windows 기반 환경
        이다. Microsoft Visual Studio®를 사용하여 Azure 플랫폼에서 애플리

        케이션을 개발하고 전개할 수 있다. Azure는 CTP(Community Technology
        Preview)에서 사용 가능하며 2010년 1월까지 무료로 평가할 수 있다.


  ○ Force.com
    ▷ Force.com은 Salesforce.com에서 최근에 추진하는 플랫폼이다. 이 플랫폼은

        확장 가능한 애플리케이션을 신속하게 빌드할 수 있는 개발 플랫폼을
        제공한다. Eclipse 기반의 IDE를 사용하여 Force.com 구성요소와 애플리
        케이션을 이 플랫폼에서 빌드하고 버전화하고 전개할 수 있다.


  ○ Morph
    ▷ 이 플랫폼은 클라우드 컴퓨팅 인프라를 기반으로 다수의 웹 애플리케이션을
        호스트할 수 있는 MAP(Morph Application Platform)이라고 하는 완벽한
        환경을 제공한다.


  ○ Bungee Connect
    ▷ 클라우드용 웹 애플리케이션을 빌드할 수 있는 완전한 애플리케이션 개발
        및 전개 환경이다.


 

  ○ 일반적으로 사용되는 PaaS 플랫폼
    ▷ PaaS 플랫폼에서는 Google App Engine이나 Microsoft Azure와 같은
        인프라로 연결되는 인터페이스를 사용하여 확장 가능한 추상화를 제공한다.
    ▷ PaaS 제공업체에서 제공하는 애플리케이션 SDK(Software Development Kit)
        사용하여 애플리케이션을 작성하고 디버그할 수 있다.

 


2. PaaS의 기본 구조 분석

 

  ○ Google App Engine은
    ▷ 클라우드 기반 플랫폼으로 이 플랫폼을 이용하면 Google의 인프라에서
        웹 애플리케이션을 실행할 수 있다.
    ▷ App Engine에서 실행하는 애플리케이션은 Python이나 Java 프로그래밍
        언어로 작성할 수 있다.
    ▷ JVM(Java Virtual Machine) 기반의 애플리케이션을 실행하는 기능 덕택에
        가능성이 무궁무진하다고 할 수 있다.
    ▷ 사용자는 Java가 아닌 다음과 같은 여러 가지 언어로도 JVM에서 실행할
        수 있는 애플리케이션을 작성할 수 있다.
         - JRuby
         - Scala
         - Clojure
         - Groovy
         - Jython
         - Beanshell
    ▷ 사용자는 트래픽의 증가에 맞춰 애플리케이션의 규모를 쉽게 조정할
        수 있다. App Engine 개발자는 두 가지 가격 정책 중 하나를 선택할 수
        있다.
      · 무료 계정 스토리지 500MB와 월간 500만 페이지 뷰를 사용하는 애플리
        케이션을 작성하는 데 사용할 수 있다.
      · 유료 계정 무료 계정보다 더 많은 자원을 사용하는 애플리케이션을
        위한 계정이다. 사용자가 필요에 따라 예산을 할당할 수 있다. 사용자는
        애플리케이션에서 사용할 수 있는 최대 자원량을 언제든지 제어하여
        자원 소비량의 한계를 설정할 수 있다.


 

  ○ App Engine에서는 명확하게 정의된 API로 구성된 확장 가능한 추상화를
      이용하여 고유한 Google 애플리케이션을 구현할 수 있다. 이러한 API는
      API/SDK를 사용하는 Java 기반 프로그램이나 Python에서 사용할 수 있다.


  ○ 아래의 표는 Google App Engine을 활용한 서비스 내역이다.

서비스

제공업체

데이터 저장소

 대용량 데이터를 반구조화된 방식으로 저장할 수 있는 고성능 사설 데이터베이스 시스템인 Google의 Biglabel

캐싱

 고성능 분산 메모리 오브젝트 캐싱 시스템인 Memcache

인증

 사용자를 관리하고 인증하는 데 필요한 Google 계정

메일

 이메일을 전송하는 데 필요한 Google Mail(Gmail)


  ○Google App Engine 서비스의 구현 형태

 

 


  ○ App Engine 환경에서 애플리케이션에 적용되는 몇 가지 추가 제한사항은
      다음과 같다.
    ▷ 사용자는 Python이나 Java 기술을 이용하여 사용할 수 있는 표준 라이

        브러리의 서브세트만을 사용할 수 있다.
    ▷ CPU 요청량, 메모리, 파일의 크기 등에 대한 할당량이 정해진다.
    ▷ 애플리케이션에 전달되는 모든 요청은 30초 내에 리턴되어야 한다.
    ▷ 사용자는 해당 파일 시스템에 대한 액세스 권한을 갖고 있지 않으며 애플리
        케이션의 일부로 업로드 된 정적 파일만을 읽을 수 있다.
    ▷ App Engine 환경에서는 사용자가 스레드나 프로세스를 생성할 수 없다.
    ▷ App Engine에서 사용된 스토리지 백엔드는 스키마리스 키 값 데이터

        저장소인 BigTable이다.
    ▷ App Engine은 HTTP 요청에서 트리거 되는 코드만 실행할 수 있다.


  ○ 이러한 제한사항은 사용자의 애플리케이션에 국한되거나 그렇지 않을 수도
      있다.

 

  ○ App Engine은 확장 가능한 웹 애플리케이션을 빌드할 수 있는 가장 좋은

      방법이며 AppScale은 Google App Engine 환경을 에뮬레이트하는 프레임

      워크를 제공한다.

 

  ○ AppScale을 이용하면 App Engine 애플리케이션을 로컬에서 Amazon EC2
      및 Eucalyptus와 같은 클라우드 기반 인프라를 기반으로 투명하게 실행하고
      디버그할 수 있다.

 

  ○ AppScale은
    ▷ 캘리포니아 산타바바라 대학에서 Google App Engine API를 오픈 소스로
        구현한 것이다.
    ▷ AppScale은 Eucalyptus나 Amazon의 EC2(Elastic Compute Cloud)와
        같은 IaaS 클라우드에서 Google App Engine 애플리케이션을 쉽게 실행
        할 수 있게 하는 클라우드 컴퓨팅 플랫폼이다.
    ▷ 사용자는 AppScale을 이용하여 App Engine의 다양한 기능을 활용할 수
        있으며 자체 클러스터에서 App Engine 애플리케이션을 실행할 수도 있다.
    ▷ 또한, AppScale은 IaaS 플랫폼에서 투명하게 실행할 수 있다. RACELab
        팀은 다음과 같이 언급했다.

          "AppScale에 대한 우리의 목표는 사용자가 GAE 애플리케이션을
          Google의 사설 자원에서 전개하기 전에 미리 전개하여 테스트하고

          디버그하고 측정하고 모니터할 수 있고 하위 레벨 클라우드 패브릭과의
          상호 운영 및 런타임, 서비스 등과 같은 PaaS 구현물을 쉽게 확장하고
          조사할 수 있는 PaaS(Platform-As-A-Service) 클라우드 인프라를

          제공하는 데 있다."
  

○ AppScale 서비스 구현

 

3. PaaS의 서비스의 사례 이해

 

  ○ AppScale Architecture
    ▷ AppScale 환경은 네 개의 기본 구성요소로 이루어진다.
    ▷ AppScale은 Google App Engine에서 제공하는 기능을 보완하여 Google
        App Engine의 SDK를 강화하고 확장할 뿐만 아니라 SDK를 통해 공개된
        오픈 API를 구현한다.
    ▷ AppScale에 있는 다수의 구성요소를 통해 App Engine 애플리케이션을
        실행하는 데 필요한 시스템의 결함 허용치와 스케일링, 관리 및 전개를

        자동화할 수 있다.
    ▷ 애플리케이션을 수정하지 않아도 AppScale에서 Google App Engine

        애플리케이션을 전개하고 실행할 수 있다.
    ▷ AppScale이 Google App Engine과 경쟁하거나 이를 대체하는 것은 아니다.
    ▷ AppScale은 클라우드 인프라를 사용하는 실험용 프레임워크이며
        Google에서 내세우는 인프라만큼 규모가 크지는 않다.


 

  ○ AppScale의 네 가지 구성요소는 다음과 같다.
    ▷ AppServer
      ·  App Engine 애플리케이션을 실행하는 데 필요한 기본 구성요소이다.
      ·  AppServer는 로컬에서 App Engine 애플리케이션을 실행하는 데 필요한
         Google App Engine SDK를 확장한 것이다.
      ·  각 AppServer는 한 번에 하나의 애플리케이션만을 실행할 수 있다.
      ·  다수의 애플리케이션을 호스트하려면 여러 개의 AppServer를 추가해야 한다.


    ▷ AppLoadBalancer
      ·  이 구성요소는 사용자의 최초 요청을 분배하는 기능을 담당한다.
      ·  사용자가 정상적으로 로그인하면 로드 밸런서는 이 요청을 해당 AppServer로
         라우트하여 해당 애플리케이션에 대한 요청을 실제로 처리한다.
      ·  그 후에는 로드 밸런서가 더 이상 관여하지 않으며 사용자는 적절한
         AppServer로 라우트된다. 이런 점에서 이 로드 밸런서는 기존의 로드 밸런서와
         다소 차별된다.
      ·  이 로드 밸런서는 Ruby on Rails 애플리케이션이며 로드 밸런싱 기능은 오픈
         소스 웹 프록시인 nginx를 사용하여 제공된다.


    ▷ Database Master
      ·  데이터 저장소의 기본 인터페이스이다.
      ·  이 인터페이스를 통해 MySQL, Cassandra, Voldemort, MongoDB, HBase
         및 HyperTable용으로 구현된 사용 가능한 다양한 데이터 저장소에 액세스할
         수 있다.
      ·  CouchDB와 같은 기타 데이터베이스는 차후에 지원될 예정이다.


    ▷ Database slaves
      ·  하나 이상의 데이터베이스 슬레이브를 통해 분산된 확장 가능한 결함 허용

         데이터 관리 기능을 제공한다.

 

  ○ AppScale 구성요소
      ·  이 구성요소는 전개 환경에 있는 모든 AppScale 인스턴스를 설정, 초기화하고
         분해하는 과정을 제어하는 AppController를 사용하여 서로 통신한다.
      ·  또한, AppController는 App Engine 애플리케이션을 전개하는 기능과 App
         Engine에 대한 인증을 담당한다.


  ○ App Engine 애플리케이션 사용자는 SSL을 사용하여 AppServer와 상호 작용한다.

 

  ○ AppScale 환경에 대한 첫 번째 로그인 요청은 언제나 로드 밸런서로 전달되며

      그러면 사용자가 정상적으로 로그인할 때 로드 밸런서가 이 요청을 해당 애플리케이션에
      라우트한다.

 

  ○ 사용자가 액세스할 애플리케이션을 작성하는 개발자는 AppScale Tools 도구 세트를
      사용하여 AppScale과 상호 작용한다.

 

  ○ 이 도구 세트는 사용자가 AppScale 인스턴스를 설정하여 App Engine 애플리케이션을
      AppScale로 전개할 수 있는 기능을 제공한다.

 

  ○ 이 도구 세트는 Amazon EC2 도구와 개념이 비슷하다. 이 도구 세트에 있는 스크립트
      중 일부를 아래에 요약해 놓았다.

 스크립트

조치

appscale-run-instances

App Engine 애플리케이션과 함께 AppScale 인스턴스를 전개

appscale-upload-app

App Engine 애플리케이션을 실행 중인 AppScale 인스턴스를 업로드

appscale-describa-instances 

App Controller와 App Servers에서 활용도 통계를 가져옴

appscale-reset-pwd

루트 사용자와 개발자의 아호를 다시 설정함

appscale-terminate-instances 

모든 AppScale 인스턴스를 정리하고 삭제함

 

 

  ○ AppScale 아키텍처

 


 


  ○ AppScale에서는 노드라는 개념을 사용한다.
    ▷ 노드는 AppScale 이미지 인스턴스로 구성된 인스턴스이다.
    ▷ AppScale 전개는 하나 이상의 노드로 구성되며 일반적으로는 일곱 개의 노드로
        구성된다.
    ▷ 노드에는 다른 노드와 통신을 하는 데 필요한 AppController와 하나 이상의
        AppScale 구성요소가 포함되어 있다.
    ▷ AppLoadBalancer를 구현하는 노드를 헤드 노드라고 한다.
    ▷ AppScale 전개에는 헤드 노드 인스턴스가 하나만 있다.

 

  ○ 헤드 노드에 있는 AppController는 기본 제어기로서 다음과 같은 몇 가지 추가
      기능을 담당한다.
      ·  AppScale 전개를 모니터하여 장애 노드를 확인한다.
      ·  시스템 요구와 개발자의 선호도에 따라 AppScale 전개를 확장하거나 축소한다.
      ·  다른 노드에서 자원 사용량과 애플리케이션 정보를 주기적으로 수집한다.
      ·  장애 구성요소를 다시 시작하고 필요한 경우에는 노드를 다시 생성하는 기능을
         담당한다.
      · 아래 그림에는 AppScale 노드의 사용에 대한 사례이다.

 



  ○ AppScale 이미지 인스턴스를 GVM(Guest Virtual Machine)이라고도 한다.

 

  ○ 이 인스턴스는 오픈 소스 IaaS 클라우드인 Eucalyptus상에서 실행하거나
      Amazon 웹 서비스인 EC2 환경에서 실행할 수 있다.


  ○ 또한, 최신 Ubuntu 배포판을 사용하는 비가상화 시스템에서도 사용할 수 있다.

 

  ○ Eucalyptus에서는 Xen이나 KVM, VMware를 기본 가상화 계층으로 사용할 수 있다.


 

  ○ 아래 그림에는 Eucalyptus에서 전개된 AppScale 환경이 표시되어 있다.

 

  ○ Amazon EC2에서는 Xen을 기본 가상화 프레임워크로 사용한다. 아래의 그림은

      EC2에서 전개된 AppScale 환경이다.

 


  ○ AppScale의 장점
      AppScale은 Google App Engine 애플리케이션을 로컬에서 테스트하고 디버그할
      수 있는 유용한 방식이다. AppScale과 Eucalyptus는 클라우드 컴퓨팅을 조사하고
      연구하는 데 필요한 유용한 플랫폼을 함께 제공한다.
    ▷ 오픈 소스
       AppScale은 클라우드 컴퓨팅 플랫폼을 연구하기 위해 개발되었다. 소스 형태로

       자유롭게 사용할 수 있어서 내부를 살펴보거나 필요에 따라 클라우드 서비스 플랫폼을
       쉽게 확장할 수 있다. 이러한 플랫폼의 개발 속도는 매우 빠르다. 다양한 기능과
       개선사항들이 빠른 속도로 추가되고 있다.
    ▷ 실험용으로 유용
       AppScale은 클라우드 패브릭과 개념을 실험할 수 있는 유용한 플랫폼이다.
       AppScale 환경에서는 클라우드 기반 애플리케이션을 새로운 방식으로 실행하기가
       수월하다. 또한, 이 플랫폼은 사용하기 편리하며 확장이 수월하다.
    ▷ 사설 클라우드
       AppScale은 자체 인프라에서 실행하는 사설 테스트 클라우드로서 자체 방화벽 뒤의
       데이터센터에 Eucalyptus와 함께 설치할 수 있다. 보안과 환경을 완전히 통제할
       수 있다는 장점이 있다.
    ▷ App Engine 호환성
       일단, 테스트가 완료되면 AppScale 프레임워크에서 작성하고 실행하는 App
       Engine 애플리케이션을 실제 Google App Engine 환경에 쉽게 전개할 수 있다. 

반응형
:
반응형

1. IaaS의 서비스 개념 이해

 

  ○ IaaS란(Infrastructure as a Service)?
    ▷ 인프라스터럭쳐, 예를 들면 서버, 스토리지, 네트워크들을 서비스로 제공
        하는 형태입니다.
    ▷ SW를 서비스 하기 위해서는 IDC라는 공간과 그 공간안에서 서버나 스토
        리지, 네트웍 장비들이 필요하게 됩니다.
    ▷ 이런 것들을 클라우드 환경(가상화 환경)으로 만들어 필요에 따라 인프라
        자원을 사용할 수 있게 하는 서비스를 제공합니다.
    ▷ 지금까지 스토리지가 부족할 경우 물리적으로 하드디스크를 확장하는

        방식을 취했는데 IaaS 서비스를 통해 필요한 용량만큼 논리적으로 늘리기만
        하면 됩니다.
    ▷ 서버도 가상화된 환경으로 이용하여 물리적으로 늘릴 필요없이 필요한 만큼
        추가하면 됩니다.
    ▷ 예를들면 아마존의 EC3(웹서비스 가상화)나 S3(스토리지 가상화) 같은
        서비스 형태나 국내에서는 클루넷의 스토리지 가상화 서비스 같은 형태로
        보여지고 있습니다.

  ○ IaaS 클라우드에서는
    ▷ 가상 서버, 데이터 스토리지 및 데이터베이스와 같은 일련의 빌딩 블록이나
        기본 서비스를 제공한다.
    ▷ 사용자는 이러한 서비스를 조합하여 애플리케이션을 전개하고 실행할 수
        있는 플랫폼을 구성할 수 있다.
    ▷ 또한, 시스템을 편리하게 구축하거나 해체할 수 있다.
    ▷ IaaS 서비스는 SOAP나 REST 기반 메시지를 사용하는 API를 통해

       액세스할 수 있다.

 

  ○ IaaS 클라우드는
    ▷ 스크립트를 통해 자동화하거나 확장할 수 있는 환경이며 필요 시 프레임
        워크를 편리하게 작성할 수 있다.
    ▷ 완전한 애플리케이션 전개 환경을 빠르게 어셈블하는 기능은 오늘날의
        IT 부서에 매우 유익한 기능으로 필요에 따라 자원을 확장하거나 축소
        할 수 있도록 도움을 준다.
    ▷ 이러한 탄력성 외에도 서비스를 사용한 만큼 비용을 지불한다는 장점이
        있다.
    ▷ 사용자는 사용한 서비스에 대해서만 비용을 지불하며 더 이상 자원을
        미리 할당할 필요가 없다.

  ○ IaaS 시스템을 사용하게 되면 다양한 애플리케이션을 활용할 수 있다.
    ▷ 테스트와 스테이징
      - 완전한 테스트 환경과 스테이징 환경을 구축하여 사용할 수 있으며 필요
         없는 경우에는 해체할 수 있다.
      - 더 이상 환경을 준비하거나 하드웨어를 조달할 때까지 기다릴 필요가
        없다.
      - 테스트하고자 하면 언제든지 새로운 환경을 구축할 수 있으며 테스트가
        완료된 후에는 구축한 환경을 해체할 수 있다.
    ▷ 웹 애플리케이션 전개 환경
      - 사용자는 IaaS를 사용하여 웹 사이트를 실행할 수 있으며 필요 시에는
        자원을 확장하여 트래픽 증가량을 쉽게 처리할 수 있다.
      - IaaS 클라우드 서비스를 사용하여 특정 마케팅 캠페인이나 영업 전략을
        제공하는 임시 웹 사이트를 추가로 작성할 수도 있다.
    ▷ 스토리지 니즈
      - 엔터프라이즈에서는 클라우드 서비스를 파일이나 기타 고객 데이터를
        저장하기 위한 공간으로 사용할 수 있다.
    ▷ 대용량 데이터 처리
      - 클라우드 서비스의 기능을 사용하여 대용량 데이터 세트를 처리하고
        대규모 병렬 처리를 활용할 수 있다.
      - 필요 시에 대용량 데이터를 처리할 수 있는 그리드를 작성한 후, 처리가
        끝난 다음, 이 그리드를 해체할 수 있다.

 

2. IaaS의 대표적 사업자와 서비스 활용 내역

 

  ○ 아마존 웹 서비스 (Amazon Web Service)
    ▷ 2002년 7월 처음 소개됐을 때, AWS는 개발들이 아마존 데이터베이스에 있는
        제한된 양의 제품 정보에 접근할 수 있는 간단한 방법이었다.
    ▷ 대표적인 서비스 제품
      - 아마존 E - Commerce 서비스 (ECS)
      - Alexa 웹 정보 서비스 (AWIS)
      - 아마존 심플 큐 서비스 (ASQS)
    ▷ ECS는 가장 오래 운영 중인 서비스로 오랫동안 AWS로 불리기도 했다.

    ▷ 아래 사진은 아마존 웹 서비스 홈페이지(http://aws.amazon.com/ko/)


  ○ 아마존 E - Commerce 서비스
    ▷ ECS는 아마존의 제품 데이터베이스에 존재하며 개발자들로 하여금 아마존
        에서 팔렸던 적이 있거나 아마존 사이트를 그들의 온라인 상점으로 이용하는
        제3의 판매자들에 의해 팔린 제품에 대한 자세한 정보를 추출할 수 있도록
        한다. 개발자들은 ECS를 사용하여 전자 장바구니를 만들기도 하고 장바구니에
        담겨있는 제품을 Amazon.com 웹 사이트에 넘겨 요금을 산출할 수도 있다.
    ▷ 앞서 언급했듯이 ECS는 AWS로 알려져 왔다. 그 결과, ECS는 현재 4.0 버전
        이다. 이전 버전들은 AWS 1.0, AWS 2.0 그리고 AWS 3.0으로 불린다.

        하지만 AWS 3.0에서 ECS 4.0으로 전환은 이름이 바뀐 것 이상이다. 아마존에서
        제공하는 웹 서비스의 상당 부분을 다시 작업했기 때문이다. AWS 3.0과
        ECS 4.0은 현재 공존하고 있지만, AWS 3.0 사용은 디프리케이트
        (deprecate)되고 있다.
    ▷ ECS 4.0은 여섯 개 아마존 사이트의 제품 데이터베이스 정보를 제공한다.
      - Amazon.com (미국)
      - Amazon.de (독일)
      - Amazon.ca (캐나다)
      - Amazon.fr (프랑스)
      - Amazon.co.uk (영국)
      - Amazon.co.jp (일본)
    ▷ 개발자들은 그들의 필요에 가장 잘 맞는 데이터베이스를 사용할 수 있다.

        하지만 ECS 4.0을 사용하여 이용할 수 있는 정보는 단순한 제품 정보 이상

        이다. 아마존은 갖고 싶은 상품 목록(wish list)과 고객 리뷰 같은 기능도 제공
        한다.
    ▷ AWS 가입 ID를 등록하고 AWS 이용허용(주요 제한 사항은 같은 IP 주소에서
        1초에 한 번 이상 아마존 웹 서비스를 호출하지 못한다는 것이다)에 동의만
        하면 공짜로 ECS 4.0을 사용할 수 있다.

 

  ○ Alexa 웹 정보 서비스
    ▷ 온라인 시장 운영으로 잘 알려졌지만, Amazon.com은 알렉사 인터넷도

        운영한다. 알렉사 인터넷은 웹을 검색하고 항해하는 포털 사이트로 구글과

        아마존의 데이터와 기술을 합쳐놓은 것이다.
    ▷ 알렉사의 핵심 특징은 브라우저 확장 기능인 알렉사 툴바를 사용하여 브라
        우저의 활동을 모니터링함으로써 인터넷 사용과 트래픽 통계를 모으는 것
    ▷ AWIS를 이용하면 개발자들은 알렉사가 웹 사이트를 탐색하고 브라우저의
        활동을 모니터링할 때 모아놓은 정보에 다음과 같은 질의를 할 수 있다.
      - 기본 웹 사이트 정보(도메인을 누가 소유하고 있는지, 사이트 순위는
        어떻게 되는지) ?
      - 누가 사이트(다른 웹 사이트)로 연결하는지 ?
      - 관련 사이트 ?
    ▷ 개발자들은 AWIS를 사용하여 웹을 검색할 수도 있으며 오픈 디렉터리
        (Open Directory)에 나열된 사이트를 탐색할 수 있다. 오픈 디렉터리는 무료
        웹 디렉터리로, 사이트를 주제별로 분류하고 구글 및 다른 회사들이 사용하는
        다수의 디렉터리의 토대를 제공한다.
    ▷ AWIS 사용 요금은 요청 당 0.00015달러이고 기본 요금은 없다.

 

  ○ 아마존 심플 큐 서비스
    ▷ ECS와 AWIS가 아마존에 접근하고 웹 사이트에 관한 구체적인 정보를 제공

        하는 반면, ASQS는 약간 다르다.
    ▷ Amazon.com의 데이터베이스에 접근하는 것이 아니라, ASQS는
        Amazon.com의 기술에 편승하는(piggyback) 애플리케이션을 개발할 수

        있도록 한다.

    ▷ 이름에서 알 수 있듯이, ASQS는 큐 시스템이다. 큐 시스템은 애플리케이션이
        메시징 패러다임을 사용하도록 한다.
    ▷ 각자에게 직접 메시지를 전하는 것이 아니라, queues라는 단순한 데이터

        베이스에 각자를 위해 메시지(데이터)를 남긴다.
    ▷ 이 경우, 큐는 아마존이 소유한 컴퓨터에서 실행되므로 신뢰성과 확장성이

        강조된다.
    ▷ 큐는 웹 서비스로 공개된다.
    ▷ ASQS는 특별한 서비스다. AWIS처럼 ASQS 사용 요금은 사용한 만큼 낸다.

 

  ○ Amazon의 AWS (Amazon Web Service) 서비스 적용
    ▷ 아마존이 웹 서비스 기능을 선보이는 것은 전자상거래 경쟁사인 이베이가

        거의 2년 동안 진행해 온 방식에 대응하기 위한 것이다. 이베이는 2000년 11월에
        자사의 API(Application Programming Interface)를 이용할 수 있도록 개발자를
        위한 프로그램을 선보였다.
    ▷ XML을 사용하기 때문에 제3자 업체는 이베이의 API를 이용해 해 자사 사이트에
        이베이의 제품 목록을 쉽게 가져올 수 있다.
    ▷ 아마존의 웹 서비스를 사용하기 위한 방법을 간단히 설명하면 다음과 같다.
      - 1단계는 아마존 웹 서비스를 운영하기 위한 개발자 프로그램인
        Developer’s Kit를 다운로드 받는다.
      - 2단계는 아마존닷컴의 웹 서비스에 엑세스할때마다 본인 확인을 해주는
        역할을 해주는 무료 개발자 토큰(Developer’s token)을 신청하여 받는다.
      - 마지막 단계는 사용자 또는 기업의 정보를 담은 지원서를 작성하면 된다.
    ▷ 아마존의 웹 서비스는 고객들이 아마존을 참조하는 대가로 웹사이트 운영자
        에게 수수료를 내도록 한 기존의 제휴 프로그램을 근간으로 해서 만들어졌다.
        하지만 기존의 제휴 프로그램은 개별 사이트에 단지 아마존에서 책이나
        제품에 대한 간단한 링크만을 배치하는 정도였다..
    ▷ 오라클이 엔터프라이즈 클라우드 인프라스트럭쳐 솔루션(Oracle Optimized
        Solution for Enterprise Cloud Infrastructure)을 발표했다.
    ▷ DW 어플라이언스와 미들웨어 어플라이언스를 발표했던 오라클이 솔라리스 혹은
        리눅스 기반의 IaaS(Infrastructure as a Service)를 위한 모든 라인업을 통합해
        고객들에게 제공하겠다고 나선 것.
    ▷ 오라클이 이번에 선보인 전략은 기존 DW 어플라이언스인 엑사데이터2나 미들웨어
        어플라이언스인 '엑사로직'처럼 하드웨어와 소프트웨어를 긴밀히 통합한 것과는 좀
        차이가 있다. 엑사데이터나 엑사로직의 경우 오라클이 강력한 시장 지배력을 보유한
        데이터베이스와 미들웨어를 하드웨어 통합했다는 장점이 십분 발휘되는 것과는
        대조적으로 x86 시장에서는 이런 소프트웨어의 강점이 발휘되기가 쉽지 않다.
    ▷ x86 가상화 소프트웨어 시장에서는 VM웨어와 마이크로소프트, 레드햇, 시트릭스
        등이 이미 광범위한 고객들을 확보하고 있고, 각 x86 벤더들은 이들 전문 업체들과
        초기부터 시스템 통합을 마쳤고, 자사의 각자 관리 소프트웨어와도 긴밀히 통합해
        왔다. 기존 고객들의 경우 오라클의 가상화 소프트웨어를 굳이 사용하지 않아도

        된다. 오라클의 가상화 제품이 시트릭스 기반이라고 하더라도 이미 내부적으로

        별도의 가상화 소프트웨어를 구매해 사용하는 기업 입장에서 또 다른 가상화 제품을

        도입할 필요가 있을 지 의문이 드는 대목이다.
    ▷ 이번 인프라는 썬의 유니파이드 스토리지와 네트워킹, 썬 블레이드 모듈러 시스템에
        오라클의 독자적인 가상화 제품인 '오라클 VM 서버', 솔라리스와 오라클 리눅스를
        통합한 것이다. 이런 전체적인 IT 자원들은 오라클 관리 소프트웨어로 통합 관리
        하겠다는 것이다.
    ▷ x86 시장에서의 입지 마련이 쉽지 않은 상황에서 오라클 나름의 통합 전략으로

        클라우드 인프라 시장에서 기회를 엿보겠다는 전략으로 풀이된다. 하지만 경쟁

        회사인 IBM이나 HP, 델, 시스코 등은 이미 1년 전부터 이 시장에서 동일한 통합

        제품으로 고객사들을 상당수 확보하면서 입지를 마련한 상황이기 때문에 오라클의

        뒤늦은 동일 전략이 얼마나 시장에서 파괴력을 가질지는 미지수다.

 


3. 국내외 IaaS 서비스의 사례
 

  ○ LGU+의 클라우드 N 서비스
    ▷ LG유플러스는 기업고객들의 IT인프라 강화를 위해 IaaS(Infrastructure as a
        Service) 기반의 통합관리 서비스 ‘클라우드 N(www.cloudn.co.kr)’을 출시하고
        기업 클라우드 시장 공략에 나섰다.

 


    ▷ 클라우드 컴퓨팅은 IT환경에 필요한 서버, 스토리지, 네트워크 등의 자원을 가상화
        기술을 이용해 인터넷으로 빌려 쓰고 사용한 만큼의 비용을 지불하는 형태로
        기업시장에서 매년 2배 이상의 성장이 전망된다. 이에 LG유플러스의 신규 및

        기존 서비스 이전 컨설팅을 바탕으로 가상화 인프라와 통합운영관리 시스템을

        결합한 차세대 기업용 클라우드 서비스인 ‘클라우드 N’ 서비스를 선보이게 된 것
        이다.
    ▷ ‘클라우드 N’은 기존의 가상화 서비스에 통합운영관리 시스템을 도입, 기업고객에
        최적화된 인프라와 솔루션을 제공해 고객이 IT인프라 자원을 필요한 만큼 언제
        든지 유동적으로 조절해 쓸 수 있다는 장점을 지닌다. 특히 도입부터 구축, 운영,
        보안까지 전문가의 컨설팅을 통해 기업고객의 기존 IT자원들을 활용해 가장
        경제적이고 효율적인 클라우드 서비스 환경구축을 지원토록 했다.
    ▷ 또 리소스 할당을 비롯 플랫폼의 제어 및 관제의 모든 프로토콜 및 사용량 통계
        및 모니터링 데이터 등을 표준화된 XML을 사용, 극대화된 이기종 시스템 및

        다양한 파트너와 상호 호환성과 확장성을 보장해 진정한 의미의 오픈 플랫폼을

        구현시켰다.
    ▷ LG ‘클라우드 N’은 통합운영관리 서비스의 가상 머신(VM)을 통해 고객이 서버를
       실제 구축하고 서비스 운영에 투입하는 시간을 기존 1~2일에서 1분 내외로
       대폭 단축시켜 기업고객의 업무효율성을 극대화했다. 이는 클라우드 N 서비스의
       경우 2000개 이상의 가상머신 및 풀 스냅샷을 1분 이내로 동시에 생성해 IT
       인프라 확장이 가능하기 때문이다.
    ▷ 또 웹방식의 통합 GUI(Graphical User Interface), API(Application
        Programming Interface)를 제공해 웹 브라우징이 가능한 스마트폰과 PC,

       태블릿PC 등 모든 기기에서도 통합운영관리시스템에 접속이 가능해 고객의

       이용편의성과 접근성을 한층 강화했다. 이와 함께 웹기반의 편리한 인터페이스와

       강력한 보안기능, 재해복구 서비스 등 통합운영관리 시스템을 활용해 안정적이고

       효율적인 고객 맞춤형 클라우드 서비스를 실현했다.
    ▷ 이외에도 IT인프라를 지역별, 서비스별 시스템으로 자유롭게 구성하고 운영/관리
        하는 토털 매니지드 서비스기 때문에 기업고객들의 실제 시스템 운영관리환경에
        가장 최적화돼 있을 뿐 아니라 기존 고객 시스템과 클라우드 시스템과의
        통합운영도 가능하다.
    ▷ 한편 LG유플러스는 통합운영관리 서비스를 기반으로 내년까지 분산처리,
        CDN(Contents Delivery Network) 등 다양한 솔루션과 결합한 PaaS(Platform
        as a Service) 서비스를 출시하고, 향후 초대용량 데이터 처리를 위한 고성능

        클라우드 컴퓨팅 서비스로 확대해 나갈 계획이다.

  ○ KT의 IaaS 베타 서비스
    ▷ KT는 서버 자원을 원하는 시점에 빌려쓰고 쓴 만큼 비용을 지불하는
        IaaS(Infrastructure as a Service) 베타 서비스에 나선다. 올해안에 상용화를

        하겠다고 밝히고 관련 가격도 공개했다.
    ▷ KT의 IaaS 서비스 명은 ‘uCloud CS(Computing Service)’로 KT는 기존 고객과
        신규 고객 10여곳들 대상으로 클로즈 베타 서비스를 시작하고 이를 통해 연내

        에는 상용화하겠다고 밝혔다. 이번에 공개한 ‘uCloud CS’는 기업에 필요한 서버,
        스토리지 등 IT 장비의 비용 부담을 덜어주기 위한 클라우드 기반의 인프라

        서비스이다.
    ▷ 그 외에 BS(Backup Service), SS(Storage Service), DS(Database Service)와
        같은 다른 서비스들도 함께 선보이기 위해 분주하다.
    ▷ ‘uCloud CS’는 서버를 임대하는 상품인 ‘CS  ▷Public’, ‘CS  ▷Dedicated’와 함께
        고객사 내 클라우드 기반의 IT인프라를 구축해 주고 컨설팅이나 유지보수를

        추가할 수 있는 ‘CS  ▷Private’등 세가지 상품으로 세분화, 고객이 니즈에 맞게 선택
        하도록 했다.
    ▷ KT가 내세우는 무기는 가격과 즉시성이다. 이용요금은 국내 최저가로 서비스

        한다는 계획이다. uCloud CS  ▷Public은 고객이 원하는 사양대로 맞춤식 주문이

        가능하며 주문 단위를 CPU 단위로 최소화해, 최저 월 3만원부터 다양한 가격을
        선보이고 있다.

 

 

반응형
: