몇 가지 PaaS 를 비교해봤습니다

새로운 일을 하려는데 서버호스팅 신청이나 서버 설치 등 각종 잡일이 하기 싫어서 몇 가지 paas를 비교해봤습니다.

테스트에 사용한 어플리케이션은 자바 1.6과 Play프레임워크 1.2.41를 이용한 것으로 플레이를 받으면 함께 들어있는 샘플 중에 yabe라는 이름으로 되어 있는 간단한 블로그입니다.

배포

히로꾸

플레이를 정식으로 지원하는 히로꾸는 git으로 소스를 푸쉬하기만 하면 바로 적용됩니다. 비교해 본 네가지 중에서 편의성은 제일입니다. 아마존의 Elastic Beanstalk도 git 배포를 지원2한다니 좀 솔깃하긴 합니다.
Getting Started with Play! on Heroku/Cedar
몇 일전에는 자바 템플릿도 지원하기 시작했습니다. 스프링 MVC나 플레이로 이뤄진 어플리케이션 템플릿을 제공해서 클릭 한 번인가 두번으로 어플리케이션을 만든 후 clone 받기만 하면 바로 개발 시작입니다.

닷클라우드

플레이를 지원한다고 되어 있으나 히로꾸처럼 소스 그대로 배포해서 될게 아니라 war 형태로 만들어 배포하는 방식입니다. play 커맨드로 직접 war를 만들어 배포해도 되겠으나 닷클라우드 모듈을 통해 별다른 작업 없이 배포가 가능합니다.

클라우드 파운드리

가상화의 최강자라 할 수 있는 VMware에서 하는 서비스답게 실서비스와 똑같은 환경을 Micro Cloud Foundry라는 이름의 vm 이미지를 제공해서 로컬에서 테스트 할 수 있도록 해놨습니다. 개발과 테스트 환경으로는 이게 최고3가 아닌가 합니다. 여기도 war 형태로 배포를 해야하는 상태이지만 닷클라우드 같은 배포 모듈은 아직 없습니다. 그리고 디비 설정 방법이 독특해놔서 그런지 자동으로 디비 설정을 잡아 주는 모듈이 나와 있습니다.

성능

각 서비스가 무료로 제공하는 기본 스펙 안에서 테스트를 해보았습니다. 모두 동일한 설정의 동일한 어플리케이션입니다.

구글의 페이지스피드나 GTmetrix 로 페이지 로드 테스트를 해보면 히로꾸와 닷클라우드는 비슷한 점수를 받고 클라우드파운드리가 가장 좋은 점수를 받고 있습니다. 히로꾸와 닷클라우드 모두 동일한 항목에서 점수를 받지 못 하는 것을 볼 수 있는데요. 최적화를 직접 해줘야 하는건 아닐텐데 왜 그러나 모르겠습니다.

그리고 PYLOT이라는 스트레스 테스트 툴로 로그인 후 글쓰기를 하고 다시 글을 보는 액션을 하도록 했습니다. 실행 에이전트 수를 늘려가면서 테스트를 해보았습니다. 세 서비스 모두 비슷한 성능을 보여주다가 에이전트를 30개 정도로 늘리니 히로꾸를 제외한 두 서비스에서는 디비 커넥션을 가져오지 못 해서 500 에러를 내고 맙니다. 고 그 중에 클라우드파운드리가 제일 심한데 아직 베타이니 봐줘야겠다 싶습니다. 디비 커넥션 pool 설정을 좀 해주면 어떨지 모르겠습니다. 그냥 초기 설정 그대로를 가지고 테스트 한 것이라 설정을 해준다면 결과가 좀 다를 수도 있겠습니다.

결론

안정적인 성능과 다양한 옵션을 제공하고 사용도 편리한 히로꾸와 베타이지만 괜찮은 성능을 보여주어 베타 이후가 기대되는 클라우드파운드리를 사용하기로 결정했습니다. 거기다 뱀웨어라는 브랜드 밸류도 한 점 보탰습니다.


  1. 몇 일 전에 2.0으로 업그레이드 된게 함정 

  2. http://aws.typepad.com/aws/2012/03/aws-elastic-beanstalk-build-php-apps-using-git-based-deployment.html 

  3. 아직 베타라는게 함정 

Advertisements

우분투에서 ssh 접속이 거부 당한다면

우분투의 open-ssh 패키지의 기본 설정을 가지고 외부 ssh 서버에 접속할 경우 항상 커넥션이 리셋되어 회사 방화벽에서 포트를 막았겠거니 하면서 지냈습니다.

Read from socket failed: Connection reset by peer

그렇게 지내다 업무를 위해 사용할 필요가 생겨 SE팀에 문의를 하니 포트는 막지 않고 있다고 하니 이게 무슨 문제인가 하고 debug 모드로 접속을 해보았습니다. 연결이 이루어지고 인증을 하는 과정에서 문제가 있던 것입니다.

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2

debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1

debug1: SSH2_MSG_KEXINIT sent

Read from socket failed: Connection reset by peer

열심히 뒤진 끝에 힌트를 잡았습니다.

ssh client problem: Connection reset by peer

  • Limit cipher list length by using ‘-c ’ in the ssh command line, e.g. ‘-c aes256-ctr’
  • Limit HostKeyAlgorithms list by adding to ~/.ssh/config:

직접 해보니 HostKeyAlgorithms 옵션의 문제입니다. 가르침에 따라 옵션의 주석을 풀고 알고리즘을 모두 추가해 놓았습니다.

HostKeyAlgorithms ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-ctr hmac-md5 none

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

히로꾸나 gihub 모두 문제 없이 연결이 됩니다.