An Overview of CloudFoundry

몇달전부터 CloudFoundry.org를 애용하고 있다.

CloudFoundry는 VMware에서 Ruby로 만든 오픈소스 PaaS (Platform as a Service)이다. 용어에 Platform이 들어가기 시작하면 너도 나도 다른 생각을 하는 경우가 부지기수니 PaaS 라는 용어는 사용하지 않고 CloudFoundry에 집중하도록 하겠다.

CloudFoundry가 이용자(개발자)에게 주는 핵심가치는 편리함이다. CloudFoundry를 사용할 경우 아래와 같은 (개발자 입장에서) 귀찮은 작업들로부터 해방될 수 있다.

관계형 데이터베이스(MySQL, PostgreSQL) 설치/운영
NoSQL 무리들(Redis, MongoDB) 설치/운영
MQ(Rabbit) 설치/운영
웹사이트 주소가 중요하지 않을 경우, 도메인 등록
웹서버의 가상호스트 설정
웹서버와 어플리케이션 서버간의 프록시 설정
트래픽에 따라 웹어플리케이션 서버 개수 줄이거나 늘리기
배포

위 항목들을 살펴보라. 통채로 보면 지긋지긋하게 보일 수 있겠지만 각 항목 하나씩만 본다면 어려운 것이 없다. 그러나 묘하게 사람 귀찮게 하는 일들이다.

MySQL 을 설치했다 치자. 디비이름도 결정해야 하고 계정이름과 비밀번호도 결정해야 한다. 결정한 뒤에는 어딘가 적어둬야하고 웹서버코드에 옮겨놓거나 설정파일로 뗀다거나 등의 작업을 해야한다.

지인들과 사용할 기능 위주의 웹페이지를 만들었다고 치자. 이런 경우라면 호스트명이 중요하진 않다. 어디 빌붙어사는 느낌이 팍팍나는 our-rooms.cloudfoundry.com 뭐 이런거면 어떤가? 돌아가면 됐지. 그러나 CloudFoundry 가 해주는 것처럼 이용자에게 서브도메인을 자동으로 발급해주는 제품을 사용하지 않는다면, 비록 1분만에 작업이 끝나더라도 그 작업을 해야한다.

DNS 레코드 수정하는 것도 귀찮은 작업이지만, 웹서버에 가상호스트 설정하는 것 또한 귀찮은 작업이다. 웹프로그램 하나 만들때마다 Nginx server 블럭이 하나 추가된다. 물론 다른 호스트꺼 복사해서 붙여서 호스트명과 WAS 프록시 주소만 바꾸면 된다. 그리고 nginx -s reload. 이것 역시 30초도 안걸리는 작업이다. 하지만 그 작업을 해야한다.

트래픽이 늘어나서 WAS 2개를 추가했다. nginx upstream 블럭에 서버 두 줄 추가하면 된다. 편집기로 nginx 설정파일을 열었는데 새로 추가한 WAS 서버 호스트랑 포트가 잘 기억이 나지 않기도 하고, 서버 10대중 3대를 빼는거라면 빼야할 서버 3개가 무엇인지 정확히 파악하느라 일시적인 스트레스를 받기까지 해야한다.

CloudFoundry는 시스템엔지니어와 말 한마디도 섞지 않으면서 서비스 오픈까지 하고 싶은 개발자를 위한 제품이다. 시스템엔지니어 업무들 일부분이 통합되고 자동화된 것이다.

그러므로 자신이 만드는 서비스가 시스템 특성이나 설정을 많이타는 특수한 과업을 견뎌내야하는 상황이라면 CloudFoundry 를 검토하지 말것을 추천한다. CloudFoundry 는 개발자가 딱히 신경쓰지 않아도 될 부분들로부터 자유를 주겠다는 것이지, 중고급 시스템 엔지니어 인건비를 절감해주겠다는 제품이 아니다. 시스템 엔지니어가 눈감고 졸면서 처리할 수 있는 일들을 자동화해주는 것이다.

다음에는 CloudFoundry 구성요소와 설치에 대한 이야기를 이어서 하겠다. CloudFoundry 설치에 대한 내용을 Overview와 함께 풀게되면 포스트의 특정 파트만 하드코어해지는 문제가 생기므로.