블로그 이미지
주로 인재개발원 등의 사이버학습을 정리, 요약하는 상시학습 블로그입니다. 깨비형
« 2017/09 »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Archive»

체험 블로그 마케팅 서비스 OLPOST

Category»

Notice»

Statistics Graph

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 환경에 쉽게 전개할 수 있다. 

신고