PaaS는 제공업체가 요청 시 하드웨어 및 운영 체제 서비스 뿐만 아니라 애플리케이션 플랫폼과 솔루션 스택을 전달하는 클라우드 서비스 유형이다. PaaS 서비스는 자원 할당, 스테이징 및 테스팅, 로드 밸런싱, 데이터베이스 액세스 및 플랫폼 라이브러리로 액세스를 비롯한 애플리케이션 배치와 연관된 IT 관리 측면의 대부분을 자동화한다. PaaS의 핵심 기능은 멀티테넌트 아키텍처이다. 즉, 여러 개의 관련되지 않은 애플리케이션이 동일한 하드웨어와 소프트웨어 인프라에서 실행할 수 있으며, 이로 인해 비용 절감 및 컴퓨팅 자원의 더 효율적인 사용이 나타난다. 개발자들은 배치와 IT 문제가 아니라 애플리케이션 자체에만 집중할 수 있다.

Java 개발자들은 PaaS 개발 모델을 학습하고 활용하기에 유리한 입장이다. 무엇보다도 PaaS 개념은 초기의 서버측 Java에 깊이 남아있다. 그 당시에 IT 조직은 "컨테이너"로서 애플리케이션 서버를 사용한 다음 공유 자원 환경에서 실행하기 위해 애플리케이션-아카이브 파일에 놓는 비전에 설득되었다(PaaS 선임자 사이드바 참조). 이러한 비전은 오늘날 보는 PaaS 서비스와 굉장히 유사하다.

하지만 초기의 Java 엔터프라이즈 애플리케이션의 PaaS 비전은 진행되지 않았다. Java 애플리케이션 서버는 관련되지 않은 여러 애플리케이션을 뜻대로 배치하거나 배치 취소할 정도로 안정적이지 못했다. 아카이브 구조는 Java 애플리케이션-개발 사이클로 오버헤드를 추가하게 되었다. PHP와 Ruby on Rails 개발자가 코드 행을 변경하고 차이점을 확인하기 위해 브라우저를 다시 로드할 수 있는 반면, Java 개발자들은 애플리케이션을 다시 컴파일하고 다시 패키지하며 다시 배치해야 했고 심지어 애플리케이션 서버를 자주 다시 시작해야 했다.

밝혀진 대로 PaaS 비전은 JVM보다 훨씬 더 앞선 가상화 기술의 새 세대가 출현해야만 현실화된다. Google App Engine을 선구자로 Java PaaS 서비스의 새로운 세대는 Java EE의 오래된 약속을 이루어준다. 그리고 이는 값비싼 하드웨어 및 시스템 관리 용량에 맞서서 투자를 늘리도록 요청하지 않고 수요에 따라 늘어나는 필요한 대로 지불하는(pay-as-you-need) IT 인프라를 제공한다.

필자는 이 기사에서 주도적인 세 가지 Java 공용 PaaS 오퍼링을 조사하여 접근방식, 강점 및 약점을 비교할 것이다. 이 세 가지 모두 다음을 비롯한 동일한 기본 기능 세트를 제공한다.

• 애플리케이션 WAR 업로드 및 배치하기
• 배치된 애플리케이션 버전화하기
• 환경 테스팅 및 스테이징
• 로그 파일에 온라인 액세스
• 자동화된 모니터링 및 사용 보고서

하지만 이러한 일반적인 기능을 넘어 몇 가지 중요한 차이점이 있다. 필자는 이러한 신흥 기술로 작업하는 필자의 자체적인 경험에서 끌어내어, 이를 비교하기 위한 프레임워크를 제공하고 독자가 이를 사용할 때 문제를 방지하는 데 도움을 주기 위한 잠재적인 임시 해결책을 논의할 것이다.

Google App Engine

Google App Engine(GAE)은 최초로 널리 채택된 Java PaaS 플랫폼이다. (Java 버전은 때로는 GAE의 Python 기반 PaaS 오퍼링과 차별화하기 위해 GAE/J라고 한다.) 또한 이는 아마도 시장에서 "가장 순수한(pure)" PaaS 오퍼링이다 — 개발자로부터 내재된 인프라를 거의 완전히 추상화한다는 면에서.

Java이지만 그렇게 Java는 아님

GAE는 2009년 이후로 개발 및 배치 환경으로 Java 플랫폼을 지원했다. 하지만, GAE의 Java 지원은 제한적이고 표준 준수적이지 않다. 수많은 제약으로 인해 이는 애플리케이션을 이용한다 — 이 중 대부분은 확장성을 유지보수하기에 충분함 — GAE는 특정 Java 플랫폼 API를 지원하지 않는다. 가장 눈에 띄는 것은 파일 쓰기 I/O(왜냐하면 GAE가 애플리케이션에 액세스 가능한 파일 시스템을 제공하지 않기 때문에) 및 많은 네트워크 I/O API(왜냐하면 GAE가 애플리케이션에서부터 나온 네트워크 연산에 심각한 제한사항을 부여하기 때문에)이다. GAE가 지원하는 "바람직한 리스트로 된" Java 플랫폼 API의 전체 목록은 참고자료를 참조한다.

자체적인 제한된 네트워크 I/O API를 지원하여, GAE는 다른 서비스로 연결하기 위한 애플리케이션의 용량을 제한한다. GAE는 명목상으로 다른 서버로 아웃바운드 연결을 작성하도록 허용한다. 하지만 GAE는 제어 중인 시스템에서 스레드 수를 유지하기 위한 노력으로 어느 애플리케이션이 시작한 연결이나 5 ~ 10초 후에 종료하도록 강제 실행한다. 이로 인해 GAE가 매시업 유형 애플리케이션에 신뢰할 수 없는 플랫폼이 된다. 이는 써드파티 웹 서비스 API를 활용하는 점점 늘어나는 애플리케이션에 대한 GAE의 가장 주된 제한사항이다.

게다가, 이러한 API 제한사항은 기존 애플리케이션 프레임워크를 사용하거나 GAE로 기존 애플리케이션을 이동해야 할 때 과제를 부여한다. 수 년간의 진화를 거친 후에 엔터프라이즈 Java 개발은 프레임워크에 크게 의존한다. 비록 Spring 및 Struts 등의 일부 대중적인 프레임워크는 GAE에서 바로 작업하지만, 다른 많은 프레임워크들은 작업하지 않거나 소스 코드로 패치가 필요하다. GAE에서 실행하도록 프레임워크 소스 코드를 수동으로 해킹하는 것은 절대 바람직한 생각이 아니다. 왜냐하면 업스트림 호환성을 깨뜨리는 기로를 작성하는 것이 필수적이기 때문이며, 이는 프레임워크로 디버그하기에 어려운 버그를 도입할 수도 있다. 좋은 예는 JavaServer Faces(JSF) 웹 프레임워크이다. 즉, 이는 GAE 환경에서 실행하도록 소스 코드 레벨 해킹을 요청한 다음 심지어 JSF 위에 많은 UI 라이브러리들이 GAE와 호환되지 않는다. (GAE를 지원하는 Java 프레임워크 목록은 참고자료를 참조한다.)

이와 마찬가지로, 이미 개발된 대규모 엔터프라이즈 애플리케이션은 GAE가 금지하는 API를 사용하는 경향이 있다. 이러한 애플리케이션을 GAE로 마이그레이션하는 것은 비용이 많이 들 수 있다. 왜냐하면, 문제를 식별하고 임시 해결책을 만들 뿐만 아니라 전부 다시 전체 애플리케이션에 대해 품질 보증을 해야 하기 때문이다.

GAE는 Java 플랫폼 API의 부분을 지원하지 않으므로 Java의 "한 번 쓰면 어디서나 실행"의 약속을 저버린다. 이는 많은 사람들을 위해 협상을 파괴하는 것이 아니라 잠재적 사용자가 인식해야 하는 점이다.

확장성과 성능

GAE는 확장성을 약속하고 제공하지만 반드시 원시 성능을 제공하지는 않는다. 웹 애플리케이션용 원시 성능은 웹 요청에 응답 시간으로 측정된다. 확장성은 얼마나 많은 사용자가 시스템에 액세스하는지 여부에 관계없이 일관된 응답 시간을 유지보수하기 위해 플랫폼의 기능을 참조한다. 예를 들어, 100명의 동시 사용자에 대해 3초의 응답으로 확장 가능한 시스템은 백만 명의 동시 사용자에 대해 3초 응답 시간이 있어야 한다.

GAE는 일관된 응답 시간이 측정되는 것처럼 훌륭한 확장성을 제공한다. 하지만 원시 성능은 보통 느리다. 필자 스스로의 일화적인 경험에서 보면 GAE는 데이터베이스 관련 요청에 응답하는 데 보통 1 ~ 3초의 시간이 걸린다.

이러한 특성은 애플리케이션 개발자에 명백한 함축성을 보여준다. 대부분의 시간 동안 유휴 상태인 웹 애플리케이션의 경우(즉, 대부분의 소규모 웹 애플리케이션) GAE 인프라에 대해 배치하는 것은 심지어 로우엔드 가상 사설 서버를 능가하는 성능 혜택이 나타나지 않을 것이다. 실제 성능 혜택은 로우엔드 서버 하드웨어의 용량을 훨씬 넘어 애플리케이션을 방대하게 확장해야 할 때 나온다.

낮은 트래픽 웹 사이트의 또 다른 성능 문제는 GAE가 시스템에서 높은 트래픽 웹 애플리케이션에 최적화하기 위해 메모리에서부터 비활성 JVM을 스왑한다는 것이다. JVM이 메모리에서부터 스왑되면, GAE는 다음 요청이 들어올 때 전체 애플리케이션을 시작하는 추가 시간을 소모해야 한다. 낮은 트래픽 웹 애플리케이션의 경우 이로 인해 낮은 성능을 초래할 수 있다(첫 요청에 5초 이상의 대기 시간). GAE는 더 일관된 성능을 위해 메모리에서 비활성 JVM을 치르고 유지하는 옵션을 개발자에게 제공한다. 하나의 팁: GAE 내에 크론(cron) 작업을 설정하여 JVM 활성 상태를 유지하도록 매 2 ~ 3분마다 자체 웹 사이트를 로드한다.

BigTable의 혜택과 제한사항

GAE의 핵심 혁신사항은 진정으로 확장 가능한 데이터 저장소의 사용인 Google BigTable이다. 대부분의 웹 애플리케이션은 데이터 백엔드로 관계형 데이터베이스를 사용한다. 하지만 관계형 데이터베이스는 크기 조정하기에 어려운 것으로 악명이 높다. 이 문제를 해결하기 위해 Google의 연구자들은 NoSQL 데이터베이스 영역에서 데이터 스토리지 솔루션 중 하나인 BigTable이라는 대안 데이터 저장 솔루션을 개발했다.

관계형 데이터베이스에서처럼 BigTable에서 데이터는 열과 행이 있는 테이블로 구성될 수 있고, 각 행은 고유 색인형 ID가 있다. 관계형 데이터베이스와는 달리 BigTable 테이블은 고정된 스키마가 없고 일반적으로 비정상화된다. 테이블의 각 행에 다른 열이 있을 수 있다. 우수 사례는 핵심 열을 통해 다른 테이블에 걸쳐서 다른 행을 연결하는 것이 아니라 행에서 많은 열을 가지는 것이다. 이는 데이터 모델의 설계를 위한 중요한 함축성을 가진다. 애플리케이션 개발자들은 정상화된 관계형 모델을 설계하는 것이 아니라 더 간편하게 검색하기 위해 중복된 정보를 각 행에 두도록 권장된다. IP 주소와 브라우저 에이전트가 모든 행에서 반복되어 공간을 차지하지만 벌크 처리를 간소화하는 웹 서버의 액세스 로그를 생각해보자.

BigTable의 혜택은 확장성이다. Google 엔지니어는 BigTable에서 데이터 쿼리의 응답 시간이 결과 데이터세트의 크기로만 결정된다고 주장한다. 결과가 천 개의 행으로 제한되는 한, 쿼리가 천 개의 행 테이블에 대한 것인지 아니면 천만 개의 행 테이블에 대한 것인지 간에 동일한 성능을 얻는다. 그 부분을 위해 GAE는 천 개의 행으로 각 쿼리의 리턴된 데이터세트를 제한한다.

비록 SQL 경력에서 나온 개발자들이 NoSQL 패러다임에 적응하는 것은 도전과제가 될 수 있지만, 점점 더 많은 IT 조직들이 Big Data 도전과제에 직면하고 있는 만큼 보유하기에 중요한 기술이다. 필자는 GAE가 Java 개발자들이 NoSQL을 학습하는 데 최선이며 가장 간편한 시작 지점이라고 생각한다.

하지만, BigTable이 GAE의 광범위한 확장성의 핵심이라고 하더라도 현재 구현 방식은 Java 개발자들이 이상적으로 보기에는 많이 부족하다. BigTable(및 일부 잠재적 임시 해결책)의 구체적인 결점은 다음과 같다.

• 데이터 쿼리에 대한 미약한 지원: Google Query Language(GQL)로 작성된 쿼리는 BigTable에서부터 데이터를 검색하는 데 사용된다. GAE는 쿼리에 연관된 데이터 열 모두가 색인화되도록 요청하고, 색인은 BLOB 또는 텍스트 열을 포함할 수 없다. GAE가 테이블당 100개의 색인만 허용하는 것을 제외하고는 문제가 없다. 이는 아마 표준 SQL 데이터베이스에는 충분하지만 BigTable과 같이 비정상화된 NoSQL 데이터베이스는 수 천개의 열을 잠재적으로 보유할 수 있으므로 100개의 색인은 많은 애플리케이션에 제한적일 수 있다. 설상가상으로 GAE는 더 이상 사용하지 않는 색인을 삭제하기에 간편한 방법을 제시하지 않는다.

  어느 색인을 작성하는지 결정하는 것은 GAE 개발자에게 엄청난 부담이다. 쿼리가 색인화되지 않은 열의 조합을 사용하는 경우 GAE에서 쿼리가 실행될 때 런타임 시에 예외만 발생할 것이다. 독자가 로컬 컴퓨터에서 애플리케이션을 테스트하면서 비록 SDK가 색인 구성 파일을 자동으로 생성하기 위한 도구를 제공하지만 모든 실행 경로를 철저하게 수동으로 테스트하지 않는 경우, 여전히 색인을 누락할 수도 있다. 자동화된 색인을 이미 배치된 애플리케이션에 병합하는 것은 또한 웹 애플리케이션 사용자가 잘못 구성된 색인에 도달할 때까지 오류 표시 없이 잠재적으로 오류 방지 처리이기도 하다.

  마지막으로 데이터베이스에서 제한 없는 텍스트 검색을 지원하지 않는 것은 — BigTable이 Google 제품임을 고려하는 경우 — 다소 놀랍다. Apache Lucene과 같은 검색 엔진 구현 방식을 텍스트 열을 색인화하고 검색하기 위해 애플리케이션으로 임베드할 수 있다(참고자료 참조). 하지만 표준 SQL LIKE 문이 간단한 텍스트 검색에 충분한 상대적으로 작은 웹 사이트에는 큰 골치거리이다.

• 데이터를 가져오고 내보내기 어려움: BigTable 관련 또 다른 주된 문제는 데이터를 가져오고 내보내기에 무력함이다. BigTable에 직접 액세스하기 위한 표준 API가 없기 때문에, 데이터 가져오기 및 데이터 내보내기 논리를 자체 애플리케이션 내의 서블릿에 써야 하고 데이터를 가져오거나 내보내기 위해 자체 웹 인터페이스를 사용해야 한다.

  GAE가 어느 웹 요청 스레드나 30초 이후에 종결하기 때문에 지속적 연결을 통해 BigTable로 대규모 데이터 세트를 업로드하는 것은 불가능하다. 일반적인 임시 해결책은 데이터 가져오기를 많은 부분으로 나누는 것이며 각 부분은 30초 이내로 업로드하고 처리하도록 요청한다. 그러면 모든 데이터를 가져올 때까지 이러한 태스크를 하나씩 실행하도록 JMeter 또는 Grinder 등의 자동화된 HTTP 드라이버를 사용할 수 있다. 말할 필요도 없이 이는 지루한 처리이다.

  BigTable로부터 데이터를 내보내는 것은 훨씬 더 문제가 많다. API가 1000개의 결과로 각 데이터 쿼리를 제한하기 때문에 내보내기 데이터는 30초 처리 제한시간 초과 제한조건이 허용하는 것보다 훨씬 더 작은 청크로 관리되어야 한다.

많은 개발자들에게 BigTable의 제한사항을 인식시키면서 GAE는 유료의 비즈니스 오퍼링을 통해 호스트된 MySQL 서비스로 액세스를 제공한다.

다른 서비스와 통합

GAE는 다른 Google 서비스와의 훌륭한 통합을 제공한다. 특히 애플리케이션은 Google Accounts와 통합할 수 있으므로 사용자는 Google 사용자 이름과 비밀번호를 사용하여 애플리케이션으로 로그인할 수 있다. 사용자 관리 시스템을 빌드하는 것이 모든 웹사이트가 해야 하는 중복 작업임을 고려하면 이로 인해 잠재적으로 시간을 많이 절약할 수 있다. 하지만, 단점은 모든 사용자가 Google 계정이 있는 것은 아니라는 것과 Google Accounts로 웹 사이트를 연결하는 것은 나중에 또 다른 PaaS 제공업체로 이동하는 것이 어려워질 것이라는 점이다.

GAE 애플리케이션도 GMail 서버를 통해 이메일 메시지를 전송하기 위해 간단한 API를 사용할 수도 있다. 비보호 SMTP 서버와 비교하면, GMail 서버는 수신자 ISP로 차단될 가능성이 훨씬 낮다.

Google Apps에서 도메인을 호스트하면, GAE 계정으로 Google Apps 계정을 연결하여 제어 하에 어느 서브도메인을 통해서도 액세스되는 애플리케이션을 구성할 수도 있다. 예를 들어, mydomain.com이 Google Apps로 호스트된 경우, mydomain.appspot.com이 아니라 www.mydomain.com으로부터 애플리케이션에 액세스 가능하게 될 수 있다.

Verdict

전체적으로 GAE는 올바르게 설계된 확장 가능한 PaaS를 제공한다. 소규모 웹 사이트에 여유로운 제한 없는 할당량도 매력적이다. 하지만, 완성된 Java 플랫폼에 대한 지원의 부재는 잠재적인 거래를 깨는 것이고, GAE에서 일부 컴포넌트는 여전히 제품 준비 상태가 아니라 실험적인 느낌이다.

위로

Amazon Elastic Beanstalk

Amazon Web Services의 상대적으로 새로운 오퍼링인 Amazon Elastic Beanstalk는 Amazon Elastic Computing Cloud(EC2) 인프라를 기반으로 관리된 Apache Tomcat 런타임 환경을 제공한다. EC2는 Infrastructure-as-a-Service(IaaS) 오퍼링이므로 이는 GAE보다 훨씬 더 높은 유연성을 제공한다. 하지만 교환 조건으로서 이는 애플리케이션을 관리하고 크기 조정하기 위해 더 많은 개발자 노력도 필요로 한다.

순수 Java Tomcat

Beanstalk 환경은 EC2 가상 서버에서 실행 중인 전체 Tomcat 서버를 지원한다. 이는 내재된 파일 시스템으로 액세스를 갖춘 순수 Java 환경이다. Tomcat의 대중성으로 인해 거의 모든 엔터프라이즈 Java 프레임워크는 Tomcat 배치를 지원한다. 이러한 프레임워크는 Tomcat WAR 파일로부터 시작되거나 부트스트랩될 수 있으며, 폭넓은 선택의 프레임워크와 라이브러리를 제공한다.

기본 Tomcat 런타임은 스레딩과 파일 또는 네트워크 I/O에서 제한사항이 없다. 네트워크 I/O 스레드는 이를 필요로 하는 한, 열린 상태로 유지될 수 있다. 독자는 내재된 가상 머신의 용량으로만 제한된다.

비교적 비싼 가격으로 크기 조정

Beanstalk는 새 EC2 인스턴스를 자동으로 시작하고 WAR 파일을 새로운 인스턴스로 배치하여 애플리케이션을 크기 조정한다. 모든 Beanstalk EC2 인스턴스는 로드밸런서보다 뒤떨어져 실행 되고 있다. 각 EC2 인스턴스에 사용 가능한 자원을 모니터하는 웹 기반 관리 콘솔을 사용할 수 있고, 기존 서버 로드가 사전 설정 제한을 초과할 때 로드 밸런서보다 뒤떨어져 새 서버 인스턴스를 자동으로 시작하기 위한 규칙을 설정할 수 있다.

로드 밸런싱된 웹 클러스터에서 일반적인 문제는 HTTP 세션을 처리하는 방법이다. 각 Tomcat 서버 노드는 클라이언트를 위해 세션 오브젝트를 작성하고 관리한다. 웹 요청이 여러 서버 노드에 걸쳐서 로드 밸런싱된 경우, 요청을 담당하는 서버 노드가 올바른 세션 오브젝트를 보유하도록 해야 한다. 이를 아카이브하는 간단한 방법은 로드 밸런서에 "스티키(고정된) 세션"을 사용하여, 뒤에서 각 서버로 유지보수된 세션 쿠키를 기억하도록 로드 밸런서를 요구하는 것이고 수신 쿠키를 기반으로 올바른 서버로 요청을 전달하는 것이다. "스티키 세션"은 Beanstalk 로드 밸런서 관리 콘솔에서 켜질 수 있다. 더 효율적인 장애 방지 솔루션은 서버 노드에 걸쳐 공유 메모리를 설정하는 것 또는 중앙 데이터베이스로 세션 오브젝트를 간단히 저장하는 것을 포함한다. 모든 서버 노드가 동일한 세션 상태 정보를 보유하기 때문에 이러한 옵션을 통해 로드 밸런서가 무작위 또는 가장 분주하지 않은 서버 노드로 요청을 전달할 수 있다. 하지만 이러한 모든 옵션은 애플리케이션 개발자의 노력이 필요하다. BigTable로 자동으로 세션 데이터를 저장하는 GAE와는 달리 Beanstalk는 독자가 모든 작업을 수행해야 한다.

아마 Beanstalk의 가장 큰 약점 중 하나는 가격이다. 특히, 어디서나 무료 호스팅을 받을 수 있는 소규모 웹 사이트의 경우에 그렇다. Amazon EC2가 새롭게 가입하면 "1년 무료" 프로그램을 제공하는 반면, Beanstalk의 표준 가격은 단일 노드 설정에만 매월 약 $40에 달한다. 이는 필요할 때 수 분 내로 자동으로 크기 조정할 수 있는 클러스터 준비 인프라에는 저렴한 가격이지만 애플리케이션이 때때로 트래픽 서지로 대부분 유휴 상태인 경우 GAE의 비슷한 것과 비교하면 비용이 많이 든다.

유연한 데이터베이스 선택

Elastic Beanstalk 플랫폼의 강점 중 하나는 데이터베이스 기술 선택의 유연성이다. 이는 다음 몇 가지 옵션을 제공한다.

• 관계형 데이터베이스: Amazon의 자체 Relational Database Service(RDS)를 통해, 다양한 관계형 데이터베이스를 배치할 수 있다. 이러한 데이터베이스 서버는 Amazon에서 관리되고 모니터되고, 데이터베이스로 데이터를 가져오고 데이터베이스에서부터 내보내기에 간편하다. 애플리케이션 내에서 필요한 모든 것은 RDS 서버로 데이터 소스를 겨냥하는 것이다. 하지만 각 RDS 인스턴스가 데이터베이스를 실행 중인 또 다른 전용 서버 인스턴스임을 주목하자 — 그리고 데이터베이스 인스턴스는 비교 가능한 EC2 인스턴스보다 비용이 30퍼센트 더 많이 든다. 비용이 올라갈 수 있으며, 많은 애플리케이션에 전용 데이터 서버가 필요하지 않다.
• NoSQL: RDS 서버 관련 한 가지 문제는 이것이 크기 조정하기 어려운 관계형 데이터베이스라는 점이다. Google BigTable과 유사한 NoSQL 접근방식을 선호하는 경우 Amazon SimpleDB로도 사용 가능하다. SimpleDB의 Java API를 통해 애플리케이션이 데이터에 간편하게 액세스할 수 있다.
• 독자 자체 데이터베이스 서버: EC2가 원시 가상 서버에 액세스를 제공하므로 독자 자체적인 데이터베이스나 개별 EC2 인스턴스에서 NoSQL 데이터 소스(Apache Cassandra 등)를 설정할 수 있고 자체 데이터베이스 서버로 Beanstalk 애플리케이션을 겨냥할 수 있다.

데이터베이스 선택에서 유연성, 특히 Amazon 관리된 관계형 데이터베이스를 사용하는 기능은 엔터프라이즈 개발자들이 매력적이라고 느낄 가능성이 높다.

다른 서비스와 통합

Amazon RDS 및 SimpleDB 외에도 Beanstalk 서버는 Simple Queue Service, S3 Storage, Simple Email Service(SES) 및 지불 API 등과 같은 다른 Amazon 서비스로 액세스가 있다. SES는 특히 흥미롭고 GAE에서 GMail API와 비교하기에 훌륭하다.

SES는 간단한 API가 있고, 이메일 메시지를 전송하기 위해 Amazon의 SMTP 서버를 사용하도록 허용한다. Amazon SMTP 서버를 사용하는 혜택은 자체적인 EC2 인스턴스에서 비보호 SMTP 서버를 설정하는 것이 아니라 Amazon 서버가 주요 ISP의 스팸 필터로 차단될 가능성이 낮다는 점이다. 이를 위해, SES는 이메일 볼륨의 증가를 제어하고 ISP 스팸 필터로부터 피드백을 수신하기 위해 풍부한 도구 세트를 제공한다. 이러한 모든 기능은 Beanstalk 애플리케이션에 사용 가능하므로 캠페인을 모니터하고 더 효율적인 전달을 위해 이메일 컨텐츠를 최적화할 수 있다.

Verdict

전체적으로, Amazon Elastic Beanstalk는 Tomcat 애플리케이션의 배치 및 크기 조정을 간소화한다. 하지만, 여전히 내재된 EC2 인프라의 유연성을 제공하여, 이로 인해 엔터프라이즈 애플리케이션에 적합하게 된다. 하지만, 낮은 트래픽 웹 사이트 또는 취미 개발자에게는 비용이 높다.

위로

CloudBees RUN@Cloud

CloudBees는 Java PaaS 분야에서 새로운 참가자이다. 이는 신입일 수 있지만, 이 배후의 사람들은 엔터프라이즈 Java 베테랑이다. (이는 JBoss의 이전 CTO인 Sacha Labourey로 시작되었고 JBoss 명성의 오픈 소스 Java 거물급의 Adrian Brock 및 Hudson 명성의 Kohsuke Kawaguchi를 고용했다.) PaaS 기술은 Stax Networks로부터 받아서 10년 이상 엔터프라이즈 고객에 호스트된 Java 애플리케이션을 제공하고 있다. CloudBees RUN@Cloud 서비스는 강력한 Stax 플랫폼을 기반으로 하고, 셀프 서비스 웹 포털을 통해 개별 개발자가 사용할 수 있다.

주요 제품들과 비교하면, RUN@Cloud는 관리된 확장성(GAE와 마찬가지로) 및 유연성(Amazon의 PaaS 서비스와 마찬가지로) 사이에 올바른 밸런스를 찾는 동시에 플랫폼을 통해 엔드투엔드 개발 라이프사이클 지원의 자체적인 전환을 추가하는 것을 목표로 한다.

강력한 Java 런타임

RUN@Cloud 서비스는 현재 EC2 인프라를 기반으로 하고 Beanstalk + RDS의 더 자동화된 버전으로 확인될 수 있다. Beanstalk과 마찬가지로, RUN@Cloud도 각 웹 애플리케이션에 대해 EC2 가상 서버에서 실행 중인 전용 Tomcat 인스턴스를 제공한다. 이는 파일 시스템 액세스, 네트워크 I/O 및 스레딩에 인위적인 제한 사항 없이 순수한 Java 환경을 제공한다.

소규모 독립 회사로서 RUN@Cloud의 강점 중 하나는 Amazon과 연결될 필요가 없다는 점이다. 이는 빠른 시일 내에 EC2를 보충하기 위해 다른 인프라 제공업체를 제공하도록 계획한다.

무료 확장 가능한 인프라

또한 Beanstalk과 유사하게 RUN@Cloud는 트래픽 서지에 부합하도록 요청 시 시작되는 서버 인스턴스와 로드 밸런서를 통해 크기 조정 가능한 인프라를 제공한다. 하지만 RUN@Cloud는 Beanstalk보다 자동화를 더 많이 제공한다. 예를 들어, RUN@Cloud는 "스티키 세션"을 사용하는 것이 아니라 관리 하에 데이터베이스로 세션을 저장하도록 해당 Tomcat 서버를 이미 구성했다. 이러한 관리형 세션 오브젝트 데이터베이스는 개발자에게 투명하다. — 이는 GAE와 매우 유사하다.

RUN@Cloud가 하나의 EC2 인스턴스에서 실행 중인 여러 Tomcat 서버를 관리하도록 공유 로드 밸런서를 사용할 수 있기 때문에, Tomcat 인스턴스당 하나의 EC2 인스턴스가 필요하지 않다. 그러므로 Beanstalk보다 훨씬 더 낮은 비용으로 낮은 트래픽 웹 사이트를 실행할 수 있다. 실제로, RUN@Cloud는 낮은 트래픽 애플리케이션 또는 취미 개발자와 학생에게 훌륭한 무료 사용 계층이 있다.

하지만 GAE와 마찬가지로, RUN@Cloud는 애플리케이션이 오랜 기간 동안 비활성화된 경우 자원을 보존하기 위해 메모리로부터 JVM을 스왑할 수 있다. 이로 인해 애플리케이션이 "준비"되면서 첫 번째 요청으로 응답이 느려질 수 있다.

호스트된 MySQL 관계형 데이터베이스

RUN@Cloud 서비스는 기본적으로 Tomcat 서비스와 함께 관리형 MySQL 서비스를 지원한다. 독자는 웹 기반 관리 콘솔을 통해 데이터베이스를 작성하고 관리할 수 있다. 그리고 데이터를 관리하기 위해 MySQL 클라이언트를 통해 데이터베이스 서버로 직접 연결할 수 있다.

Amazon RDS와 달리, RUN@Cloud 서비스는 여러 애플리케이션에 걸쳐서 공유 데이터베이스 서버를 배치한다. 각 애플리케이션은 자체 데이터베이스를 보유할 수 있지만 반드시 전용 서버를 가지는 것은 아니다. PaaS 플랫폼은 자동으로 데이터베이스를 배치하여 데이터베이스 서버의 풀의 활용을 최대화한다. 공유 데이터베이스 서버는 RDS와 비교하면 가상 서버의 더 효율적인 사용과 그로 인한 더 저렴한 비용이 잠재적으로 야기될 것이다.

다른 서비스와 통합

RUN@Cloud는 플랫폼 API와 내재된 인프라 제공업체가 지원한 서비스로 액세스를 제공한다. 특히, Amazon EC2에 배치된 RUN@Cloud 애플리케이션의 경우 이러한 애플리케이션은 모든 Amazon 웹 서비스 API로 전체 액세스를 보유한다. — 예를 들어, S3, SQS, SES — 이는 애플리케이션 내부에서부터 나온다.

하지만 RUN@Cloud가 정말 빛을 발하는 부분은 클라우드 기반 Continuous Integration 플랫폼인 DEV@Cloud와의 긴밀한 통합이다. DEV@Cloud는 소스 코드, 버전 제어 시스템(Subversion 및 GIT), 빌드 저장소(Apache Maven) 및 빌드 서버(jenkins, 이전에는 Hudson이었음)를 제공한다. 이를 통해 자체 컴퓨터가 아니라 클라우드에서 애플리케이션의 자동화된 빌드 및 테스트를 실행할 수 있다. 이러한 중앙 집중형 빌드 시스템 유형은 저장소에서 소스 코드가 항상 테스트되고 릴리스 가능한 상태가 되도록 보장하기 위해 애자일 소프트웨어 팀들이 널리 채택했다.

RUN@Cloud를 DEV@Cloud와 통합하여, CloudBees는 엔터프라이즈 Java 웹 애플리케이션의 전체 개발, 테스팅 및 배치 사이클을 관리할 수 있는 강력한 PaaS 서비스 세트를 제공한다. 독자는 자체 컴퓨터에서 소스 코드를 편집하기만 하면 되고, 나머지 작업은 최소 IT 오버헤드로 클라우드에서 자동화된 시스템으로 위임될 수 있다.

Verdict

CloudBees RUN@Cloud는 Amazon Elastic Beanstalk 및 RDS의 저비용(심지어 무료) 대안이다. 지속적인 빌드 시스템과의 통합으로 인해 개발 프로세스에서 모든 IT 기능을 자동화하려는 애자일 소프트웨어 개발 팀의 각광을 받게 된다.

위로

결론

실망스러운 몇 년 간을 보낸 후, Java PaaS 서비스가 마침내 전성기에 도달했다. 이 기사에서 검토하고 비교한 세 가지 서비스는 각각 고유한 접근방식이 있으므로, 결과적으로 고유한 강점과 약점이 있다.

만약 독자가 새 애플리케이션을 개발하는 중이고 GAE의 제한조건을 감수할 수 있다면 GAE는 훌륭한 무료의 선택이다. RUN@Cloud 및 Elastic Beanstalk는 애플리케이션 레벨에서 상호 교환 가능한 런타임이다. 표준 Java EE 애플리케이션은 수정되지 않은 두 플랫폼 중 하나에서 실행할 수 있다. RUN@Cloud는 시작하기에 비용이 저렴하고 구성하기에 간편하며, 지속적으로 통합된 개발 프로세스에 훌륭한 지원을 제공한다. 필자는 RUN@Cloud를 무료로 시작할 것을 제안한다. 독자가 CloudBees의 서비스에 만족하지 않으면 간편하게 Elastic Beanstalk로 이동할 수 있다는 사실도 유의하자.

참고자료

교육

• "Gartner Says 2011 Will Be the Year of Platform as a Service": 이 Gartner 출판부 발표문으로 입증된 것처럼 PaaS 관련된 열기가 계속 높아진다.
  
  
• "Consider PaaS in Your Cloud Strategy": Gartner 분석가인 Yefim Natis는 이 프리젠테이션에서 PaaS에 대한 케이스를 작성한다.
  
  
• Google App Engine for Java: GAE for Java는 최초의 Java PaaS 오퍼링 중 하나이다.
  
  
• Amazon Web Services: Amazon Web Services는 Elastic Beanstalk, Elastic Compute Cloud, Relational Database Service, SimpleDB 및 Simple Email Service 등의 상호 연결된 서비스 세트를 제공한다.
  
  
• CloudBees: CloudBees DEV@Cloud 및 RUN@Cloud 서비스 둘 다 소규모 웹 사이트를 위한 무료 계층이 있다.
  
  
• Java development 2.0: Andrew Glover의 developerWorks에서 기사 시리즈는 Google App Engine, BigTable 및 Amazon Elastic Beanstalk를 시작하는 방법을 다룬다.
  
  
• "Google App Engine for Java": GAE를 위해 Java 애플리케이션을 빌드하는 방법에 대한 Richard Hightower의 세 파트로 된 기사를 확인하자.
  
  
• The JRE Class White List: GAE에서 지원되는 Java 플랫폼 API의 Google의 공식적 목록.
  
  
• WillItPlayInJava: 대중적인 프레임워크에 대한 GAE의 지원 상태를 확인하자.
  
  
• 기술 서점에서 다양한 기술 주제와 관련된 서적을 살펴보자.
  
  
• developerWorks Java 기술: Java 프로그래밍과 관련된 모든 주제를 다루는 여러 편의 기사를 찾아보자.
  
  

제품 및 기술 얻기

• Apache Lucene: GAE 애플리케이션에서 검색 엔진을 사용하기 위해 BigTable 위에 Lucene을 사용하여 자체 텍스트 검색 엔진을 빌드할 수 있다.
  
  

토론

• developerWorks 커뮤니티에 참여하자.
  
  

필자소개

Michael Yuan 박사는 엔터프라이즈 컴퓨팅과 소비자 모바일 기술 분야에서 유명한 과학 기술자이다. 그는 소프트웨어 공학에 관한 다섯 권의 책의 저자이며, 상호 검토되는 저널 및 업계 저널 모두에서 40개 이상의 기사를 발표했다. Yuan 박사는 이용자 구동형 헬스케어의 떠오르는 부문의 개척자이다. Ringful Health에서 그의 작업은 월스트리트 저널, 뉴욕 타임즈 및 로스앤젤레스 타임즈 등의 국내 매체에서 널리 다루어져 인정받았다.

아티클 순위

의견

위로

목차

• Google App Engine
• Amazon Elastic Beanstalk
• CloudBees RUN@Cloud
• 결론
• 참고자료
• 필자소개
• 의견